拓冰网站定制 
一句话定位Spexis 是一个多卡 LLM 推理框架它把「投机解码」从一种单序列的加速技巧重新定义成一条新的并行维度——投机并行speculative parallelismSP。它基于 vLLM v0.8.4 做 Python 层 fork论文 2026 年 9 月 28 日挂上 arXiv编号 2609.34370投的是 EMNLP 2026 main代码在 GitHub 开源仓库名mlsys-seo/spexis。核心宣言是比起拿它只加速 token 生成Spexis 让投机和正常执行并行跑从而在不增加 KV 缓存占用的前提下引入新并行度缓解多卡推理的瓶颈。相比「流水线 张量并行最优组合」的基线最高提速 34%。它要解决的痛点PP / TP 各自的墙多卡推理目前主要靠两种切法。张量并行TP在通信上开销大跨卡 all-reduce 随并行度上升吞掉收益流水线并行PP的经典做法是 micro-batch——把大 batch 拆成 N 份让 N 个流水级各自有事做。问题出在 KV 缓存。PP 的 micro-batching每个 micro-batch 都需要独立的 KV 缓存批次越多、激活的缓存副本越多显存容量很快见顶这就是论文里说的「memory-capacity bottleneck」。于是并发上不去吞吐被卡住。Spexis 的观察是如果投机执行能够复用正常执行的那份 KV 缓存而不是另开一份那么同一个显存预算下就能塞进更大的 batch吞吐自然上去。这正是 SP 的设计前提。核心做法让投机和验证在不同流水级重叠Spexis 用的是自投机self-speculation模型的前若干层负责起草draft其余层负责验证verify这本身就是正常执行路径的一部分。具体调度如图示那样一个两卡两级流水线第一级产出 draft token 之后立刻在第一级开始对这些 token 做投机执行同时第二级正在做验证。也就是说投机计算和正常模型计算在时间上重叠而不是串行等待。两个关键收益显存友好。投机执行不申请独立 KV 缓存共享正常执行的那份支持更大 batch吞吐更高——直接绕开 PP micro-batch 的多份缓存问题。压低 TP 需求。既然多了一条并行轴来分摊所需 TP 度可以降低随之下降的是 TP 的通信开销。这条路的可行性取决于 draft token 的接受率而且它依赖一个经验规律前面的 draft token 接受率显著更高。论文引用的 EAGLE 工作报告首个 draft token 最高接受率 85%Spexis 自己的评测里这个数字是 78%。正因为「开头几步猜得准」投机才能和 TP、PP 组合起来而不至于白烧算力。论文还给出了一个稳态成本模型用来比较三种轴。在最简形式下SP 的稳态有效 batch size 为B_eff* B / (N - Θ(N-1))其中 B 是单次能处理的最大序列数N 是流水级数Θ 是投机准确率。这个式子直观说明Θ 越高、N 越大SP 的等效批量相对 PP 的B/N越有优势。前瞻调度两招把浪费压下去光有并行轴还不够Spexis 加了两个基于预测的调度手段论文版本号里分别对应--spexis-ver 2.0和2.5。第一招置信度引导的选择性投机。自投机模型里draft token 的置信度常被用来估计接受概率。Spexis 不显式预测接受率而是按置信度排序、丢掉排名最低的一批 token只对剩下的做投机。做法是每个 batch 丢掉固定比例 α评测里 α 取 0.15–0.3。逻辑是每批里置信度最低的那一小撮本来就几乎不可能被接受丢掉它们反而提升了整体投机准确率作者通过剖析保留部分的接受率和投机延迟联立求出最优 α。第二招剩余长度感知的调度。SP 靠共享 KV 缓存省内存但内存压力还会从别处来——新请求不断到达。Spexis 预测每个运行中序列的剩余输出长度据此推算未来若干解码步的 KV 占用决定要不要推迟新请求的调度避免把正在跑的序列连同其缓存驱逐出去。有意思的是它不预测精确长度而是用序数阈值预测判断剩余长度是否低于 4、8、16、32、64 个 token或者超过 64。实现是一个三层 MLP输入 draft 层的隐状态输出 5 个阈值对应的置信度分数。每个阈值挑一个置信度截断点使得「预测低于该阈值」时精度很高——论文报告这一精度达 83%同时保持合理召回。有了它Spexis 估算未来 64 个解码步的 KV 用量权衡两件事早一点接纳新请求带来的吞吐收益对比驱逐运行序列造成的重算代价。论文明说重算代价通常更大但早接纳的收益有时能覆盖所以这个 trade-off 是显式建模的。基准与边界提速相较「PP TP 最优组合」基线最高 34%。硬件需要 NVIDIA GPU、CUDA 12.4在 A40、H100 SXM、A100 SXM、L40S 上测过。卡数至少两张卡——SP 要求pipeline_parallel_size 2。软件Python 3.11、PyTorch 2.6.0容器pytorch/pytorch:2.6.0-cuda12.4-cudnn9-devel。模型目前只保留论文实验需要的部分Llama / Qwen 系列。定位作者自己标注这是研究原型不是生产级 serving stack。怎么跑起来Spexis 是 vLLM v0.8.4 的纯 Python fork不用从源码编 CUDA kernel而是把官方 wheel 里的编译产物抽出来复用gitclone https://github.com/mlsys-seo/spexis.gitcdspexis pipinstall-Upip setuptools wheel packaging setuptools-scm jinja2 ninja cmake pip download --no-depsvllm0.8.4-d/tmp/vllm-wheelexportVLLM_PRECOMPILED_WHEEL_LOCATION$(ls/tmp/vllm-wheel/vllm-0.8.4*.whl)exportVLLM_USE_PRECOMPILED1pipinstall-e.--no-build-isolation pipinstalltransformers4.57.6ray[cgraph]2.53.0accelerate python-cimport spexis; print(spexis.__version__)包名是spexis可以和上游 vLLM 共存环境变量仍是VLLM_*自定义算子命名空间仍是torch.ops.vllm所以原有启动脚本不用大改。投机需要两份产物每个流水切分对应的训练好的早退模型exit_1_pp/PP2 用exit_1_2PP4 用exit_1_4以及目标模型的 embedding 权重embed_tokens.bin——第一级在 CPU 上查表而不是常驻 GPUpython tools/extract_embed_tokens.py\--model/path/to/Llama-3.3-70B-Instruct\--output/path/to/exitmodels/Llama-3.3-70B-Instruct/embed_tokens.bin然后两卡离线推理examples/spexis_offline_inference.py接--exit-model-dir或者走 OpenAI 兼容服务spexis serve /path/to/Llama-3.3-70B-Instruct\--enable-spexis --spexis-ver2.5\--pipeline-parallel-size2\--exit-model-dir /path/to/exitmodels/Llama-3.3-70B-Instruct\--exit-model-type llama\--length-predictor-path /path/to/length_predictor几个开关的含义--spexis-ver 1.0只有投机并行2.0加置信度丢弃2.5再加长度感知调度需要--length-predictor-path三者累积论文用的是2.5。每个流水级配一个--exit-layer和一个--exit-models条目不投机的级写字符串None。--drop-ratio控制每轮丢弃的最低置信度比例需 2.0--cpu-embedding-path指向 embedding 权重。想复盘就开--enable-log和--logdir写 JSONL 的逐迭代指标。注意仓库里提到早退模型exit_1_pp/当时还没随代码放出标注为「release is in progress」——所以想复现需要自己训练这份 draft 权重。和同类方案比取舍在哪放进现有的投机解码版图看Spexis 的位置比较特殊。普通投机解码 / Medusa / EAGLE主线目标是减少生成步数用 draft 模型或额外解码头一次猜多个 token。它们作用在单序列的时间维度上不改变多卡的并行结构。Spexis 借用了自投机的机制但把它当作并行维度使用重心从「少走几步」挪到「让多卡的空闲被填满」。LayerSkip 一类的早退 自投机同样是拿前几层起草、后几层验证。Spexis 的差异在于把验证放进流水线的下一级让起草和验证跨卡重叠并且不额外申请 KV 缓存再叠加前瞻调度去控制内存压力。SpecExec 一类面向消费级设备的大规模并行投机关注的是把参数 offload 场景下的投机做宽。Spexis 面向的是多卡服务器侧处理的是 PP / TP 的瓶颈与显存容量约束。代价也很清楚你需要为每个目标模型、每个流水切分训练一份早退模型还要额外训练一个长度预测器--spexis-ver 2.5的 α、置信度截断点都得在实际硬件上剖析标定换配置要重来。仓库自己定性为研究原型模型的覆盖面也只有 Llama / Qwen。适合谁用适合正在做多卡推理服务、并且已经撞上「PP 加 micro-batch 后 KV 缓存吃满、TP 通信又贵」这堵墙的团队或研究者手里有 2 张以上 GPU能接受为每个部署配置额外训练早退模型和长度预测器的成本用 Spexis 换来的是更大的等效 batch 和最高 34% 的吞吐提升。如果你跑的是单卡、或者只是想把单条序列生成得更快这一层的收益有限——普通投机解码或 EAGLE 这类方案才是更直接的起点。而如果你需要开箱即用的生产 servingSpexis 目前的定位研究原型、产物尚未全部放出、方言限定 Llama/Qwen意味着更现实的用法是把它当作一条思路借鉴——把投机在时间维度的重叠迁移到多卡的并行维度上去。参考链接Spexis: Speculative Lookahead Scheduling for LLM InferencearXiv 摘要页: https://arxiv.org/abs/2609.34370论文全文 HTML含成本模型、前瞻调度细节: https://arxiv.org/html/2609.34370v1官方代码仓库 mlsys-seo/spexis安装、CLI 选项、要求: https://github.com/mlsys-seo/spexisSciRate 收录页提交与发表信息: https://scirate.com/arxiv/2609.34370 Spexis 是什么：vLLM 上提速 34% 的投机并行轴
一句话定位Spexis 是一个多卡 LLM 推理框架它把「投机解码」从一种单序列的加速技巧重新定义成一条新的并行维度——投机并行speculative parallelismSP。它基于 vLLM v0.8.4 做 Python 层 fork论文 2026 年 9 月 28 日挂上 arXiv编号 2609.34370投的是 EMNLP 2026 main代码在 GitHub 开源仓库名mlsys-seo/spexis。核心宣言是比起拿它只加速 token 生成Spexis 让投机和正常执行并行跑从而在不增加 KV 缓存占用的前提下引入新并行度缓解多卡推理的瓶颈。相比「流水线 张量并行最优组合」的基线最高提速 34%。它要解决的痛点PP / TP 各自的墙多卡推理目前主要靠两种切法。张量并行TP在通信上开销大跨卡 all-reduce 随并行度上升吞掉收益流水线并行PP的经典做法是 micro-batch——把大 batch 拆成 N 份让 N 个流水级各自有事做。问题出在 KV 缓存。PP 的 micro-batching每个 micro-batch 都需要独立的 KV 缓存批次越多、激活的缓存副本越多显存容量很快见顶这就是论文里说的「memory-capacity bottleneck」。于是并发上不去吞吐被卡住。Spexis 的观察是如果投机执行能够复用正常执行的那份 KV 缓存而不是另开一份那么同一个显存预算下就能塞进更大的 batch吞吐自然上去。这正是 SP 的设计前提。核心做法让投机和验证在不同流水级重叠Spexis 用的是自投机self-speculation模型的前若干层负责起草draft其余层负责验证verify这本身就是正常执行路径的一部分。具体调度如图示那样一个两卡两级流水线第一级产出 draft token 之后立刻在第一级开始对这些 token 做投机执行同时第二级正在做验证。也就是说投机计算和正常模型计算在时间上重叠而不是串行等待。两个关键收益显存友好。投机执行不申请独立 KV 缓存共享正常执行的那份支持更大 batch吞吐更高——直接绕开 PP micro-batch 的多份缓存问题。压低 TP 需求。既然多了一条并行轴来分摊所需 TP 度可以降低随之下降的是 TP 的通信开销。这条路的可行性取决于 draft token 的接受率而且它依赖一个经验规律前面的 draft token 接受率显著更高。论文引用的 EAGLE 工作报告首个 draft token 最高接受率 85%Spexis 自己的评测里这个数字是 78%。正因为「开头几步猜得准」投机才能和 TP、PP 组合起来而不至于白烧算力。论文还给出了一个稳态成本模型用来比较三种轴。在最简形式下SP 的稳态有效 batch size 为B_eff* B / (N - Θ(N-1))其中 B 是单次能处理的最大序列数N 是流水级数Θ 是投机准确率。这个式子直观说明Θ 越高、N 越大SP 的等效批量相对 PP 的B/N越有优势。前瞻调度两招把浪费压下去光有并行轴还不够Spexis 加了两个基于预测的调度手段论文版本号里分别对应--spexis-ver 2.0和2.5。第一招置信度引导的选择性投机。自投机模型里draft token 的置信度常被用来估计接受概率。Spexis 不显式预测接受率而是按置信度排序、丢掉排名最低的一批 token只对剩下的做投机。做法是每个 batch 丢掉固定比例 α评测里 α 取 0.15–0.3。逻辑是每批里置信度最低的那一小撮本来就几乎不可能被接受丢掉它们反而提升了整体投机准确率作者通过剖析保留部分的接受率和投机延迟联立求出最优 α。第二招剩余长度感知的调度。SP 靠共享 KV 缓存省内存但内存压力还会从别处来——新请求不断到达。Spexis 预测每个运行中序列的剩余输出长度据此推算未来若干解码步的 KV 占用决定要不要推迟新请求的调度避免把正在跑的序列连同其缓存驱逐出去。有意思的是它不预测精确长度而是用序数阈值预测判断剩余长度是否低于 4、8、16、32、64 个 token或者超过 64。实现是一个三层 MLP输入 draft 层的隐状态输出 5 个阈值对应的置信度分数。每个阈值挑一个置信度截断点使得「预测低于该阈值」时精度很高——论文报告这一精度达 83%同时保持合理召回。有了它Spexis 估算未来 64 个解码步的 KV 用量权衡两件事早一点接纳新请求带来的吞吐收益对比驱逐运行序列造成的重算代价。论文明说重算代价通常更大但早接纳的收益有时能覆盖所以这个 trade-off 是显式建模的。基准与边界提速相较「PP TP 最优组合」基线最高 34%。硬件需要 NVIDIA GPU、CUDA 12.4在 A40、H100 SXM、A100 SXM、L40S 上测过。卡数至少两张卡——SP 要求pipeline_parallel_size 2。软件Python 3.11、PyTorch 2.6.0容器pytorch/pytorch:2.6.0-cuda12.4-cudnn9-devel。模型目前只保留论文实验需要的部分Llama / Qwen 系列。定位作者自己标注这是研究原型不是生产级 serving stack。怎么跑起来Spexis 是 vLLM v0.8.4 的纯 Python fork不用从源码编 CUDA kernel而是把官方 wheel 里的编译产物抽出来复用gitclone https://github.com/mlsys-seo/spexis.gitcdspexis pipinstall-Upip setuptools wheel packaging setuptools-scm jinja2 ninja cmake pip download --no-depsvllm0.8.4-d/tmp/vllm-wheelexportVLLM_PRECOMPILED_WHEEL_LOCATION$(ls/tmp/vllm-wheel/vllm-0.8.4*.whl)exportVLLM_USE_PRECOMPILED1pipinstall-e.--no-build-isolation pipinstalltransformers4.57.6ray[cgraph]2.53.0accelerate python-cimport spexis; print(spexis.__version__)包名是spexis可以和上游 vLLM 共存环境变量仍是VLLM_*自定义算子命名空间仍是torch.ops.vllm所以原有启动脚本不用大改。投机需要两份产物每个流水切分对应的训练好的早退模型exit_1_pp/PP2 用exit_1_2PP4 用exit_1_4以及目标模型的 embedding 权重embed_tokens.bin——第一级在 CPU 上查表而不是常驻 GPUpython tools/extract_embed_tokens.py\--model/path/to/Llama-3.3-70B-Instruct\--output/path/to/exitmodels/Llama-3.3-70B-Instruct/embed_tokens.bin然后两卡离线推理examples/spexis_offline_inference.py接--exit-model-dir或者走 OpenAI 兼容服务spexis serve /path/to/Llama-3.3-70B-Instruct\--enable-spexis --spexis-ver2.5\--pipeline-parallel-size2\--exit-model-dir /path/to/exitmodels/Llama-3.3-70B-Instruct\--exit-model-type llama\--length-predictor-path /path/to/length_predictor几个开关的含义--spexis-ver 1.0只有投机并行2.0加置信度丢弃2.5再加长度感知调度需要--length-predictor-path三者累积论文用的是2.5。每个流水级配一个--exit-layer和一个--exit-models条目不投机的级写字符串None。--drop-ratio控制每轮丢弃的最低置信度比例需 2.0--cpu-embedding-path指向 embedding 权重。想复盘就开--enable-log和--logdir写 JSONL 的逐迭代指标。注意仓库里提到早退模型exit_1_pp/当时还没随代码放出标注为「release is in progress」——所以想复现需要自己训练这份 draft 权重。和同类方案比取舍在哪放进现有的投机解码版图看Spexis 的位置比较特殊。普通投机解码 / Medusa / EAGLE主线目标是减少生成步数用 draft 模型或额外解码头一次猜多个 token。它们作用在单序列的时间维度上不改变多卡的并行结构。Spexis 借用了自投机的机制但把它当作并行维度使用重心从「少走几步」挪到「让多卡的空闲被填满」。LayerSkip 一类的早退 自投机同样是拿前几层起草、后几层验证。Spexis 的差异在于把验证放进流水线的下一级让起草和验证跨卡重叠并且不额外申请 KV 缓存再叠加前瞻调度去控制内存压力。SpecExec 一类面向消费级设备的大规模并行投机关注的是把参数 offload 场景下的投机做宽。Spexis 面向的是多卡服务器侧处理的是 PP / TP 的瓶颈与显存容量约束。代价也很清楚你需要为每个目标模型、每个流水切分训练一份早退模型还要额外训练一个长度预测器--spexis-ver 2.5的 α、置信度截断点都得在实际硬件上剖析标定换配置要重来。仓库自己定性为研究原型模型的覆盖面也只有 Llama / Qwen。适合谁用适合正在做多卡推理服务、并且已经撞上「PP 加 micro-batch 后 KV 缓存吃满、TP 通信又贵」这堵墙的团队或研究者手里有 2 张以上 GPU能接受为每个部署配置额外训练早退模型和长度预测器的成本用 Spexis 换来的是更大的等效 batch 和最高 34% 的吞吐提升。如果你跑的是单卡、或者只是想把单条序列生成得更快这一层的收益有限——普通投机解码或 EAGLE 这类方案才是更直接的起点。而如果你需要开箱即用的生产 servingSpexis 目前的定位研究原型、产物尚未全部放出、方言限定 Llama/Qwen意味着更现实的用法是把它当作一条思路借鉴——把投机在时间维度的重叠迁移到多卡的并行维度上去。参考链接Spexis: Speculative Lookahead Scheduling for LLM InferencearXiv 摘要页: https://arxiv.org/abs/2609.34370论文全文 HTML含成本模型、前瞻调度细节: https://arxiv.org/html/2609.34370v1官方代码仓库 mlsys-seo/spexis安装、CLI 选项、要求: https://github.com/mlsys-seo/spexisSciRate 收录页提交与发表信息: https://scirate.com/arxiv/2609.34370