一句话定位
Spexis 是一个多卡 LLM 推理框架，它把「投机解码」从一种单序列的加速技巧，重新定义成一条新的并行维度——投机并行（speculative parallelism，SP）。它基于 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 里的编译产物抽出来复用：
git clone https://github.com/mlsys-seo/spexis.git && cd spexis
pip install -U pip setuptools wheel packaging setuptools-scm jinja2 ninja cmake
pip download --no-deps "vllm==0.8.4" -d /tmp/vllm-wheel
export VLLM_PRECOMPILED_WHEEL_LOCATION=$(ls /tmp/vllm-wheel/vllm-0.8.4*.whl)
export VLLM_USE_PRECOMPILED=1
pip install -e . --no-build-isolation
pip install "transformers==4.57.6" "ray[cgraph]==2.53.0" accelerate
python -c "import spexis; print(spexis.__version__)"
包名是 spexis，可以和上游 vLLM 共存；环境变量仍是 VLLM_*，自定义算子命名空间仍是 torch.ops.vllm，所以原有启动脚本不用大改。
投机需要两份产物：每个流水切分对应的训练好的早退模型 exit_1_<pp>/（PP=2 用 exit_1_2，PP=4 用 exit_1_4），以及目标模型的 embedding 权重 embed_tokens.bin——第一级在 CPU 上查表而不是常驻 GPU：
python 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-ver 2.5 \
--pipeline-parallel-size 2 \
--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 这类方案才是更直接的起点。而如果你需要开箱即用的生产 serving，Spexis 目前的定位（研究原型、产物尚未全部放出、方言限定 Llama/Qwen）意味着更现实的用法是：把它当作一条思路借鉴——把投机在时间维度的重叠，迁移到多卡的并行维度上去。
参考链接
- Spexis: Speculative Lookahead Scheduling for LLM Inference（arXiv 摘要页）: https://arxiv.org/abs/2609.34370
- 论文全文 HTML（含成本模型、前瞻调度细节）: https://arxiv.org/html/2609.34370v1
- 官方代码仓库 mlsys-seo/spexis（安装、CLI 选项、要求）: https://github.com/mlsys-seo/spexis
- SciRate 收录页（提交与发表信息）: https://scirate.com/arxiv/2609.34370
