llama.cpp b9878 深度实测：Draft模型张量分割修复，推测解码终于不崩了

你有没有遇到过这样的场景：好不容易配好了DeepSeek-V4的draft模型，满心期待推测解码能带来3倍加速，结果跑起来第一轮就报错shape mismatch，然后整个推理链中断？我跟你一样，整整折腾了两天才发现是张量分割（tensor parallelism）在搞鬼。
2026年6月底，llama.cpp发布了b9878版本，核心修复就是这个坑：推测解码时，draft模型与主模型的张量分割不再“共享”，而是按各自任务独立处理。这篇文章我用DeepSeek-V4实测了一整天，带你看看这个修复到底解决了什么、效果如何、以及你要不要升级。

张量分割的“历史遗留问题”

要理解这个修复的价值，先得说清楚推测解码（speculative decoding）是什么。它就像写文章时的“打字员+校对员”模式——draft模型（小型“打字员”）快速生成候选token，主模型（大型“校对员”）一次性验证。理想情况下，draft模型跑得快，主模型验证也不慢，吞吐量能翻倍。
但在旧版llama.cpp里，draft模型和主模型共享同一个张量分割配置。这意味着，如果你给主模型用了4卡TP（tensor parallelism，张量并行，把模型切成4块分配到4张卡上），draft模型也得跟着切成4块。问题来了：draft模型往往比主模型小得多（比如DeepSeek-V4主模型有8B，draft模型只有1.5B），强行切成4块后，每张卡上的参数量少得可怜，KV缓存（键值缓存，推理时存储中间计算的缓存）的尺寸计算直接崩了，报错shape mismatch成家常便饭。
b9878的修复思路很直接：给draft模型开辟独立的张量分割逻辑，自动检测draft模型的尺寸和结构，不再强制复用主模型的配置。同时修复了KV缓存的内存对齐问题，确保多卡场景下缓存不越界。

实测：新旧版本差距有多大

测试环境：4×RTX 4090，DeepSeek-V4-8B主模型 + DeepSeek-V4-1.5B Draft模型，GGUF格式（Gruop Quantized Universal Format，llama.cpp的量化格式）。都使用Q4_K_M量化。测试任务：从给定prompt生成2048个token，温度0.7，top-p 0.9。

测试项目	b9877（旧版）	b9878（新版）	变化
平均吞吐量（token/s）	12.4	28.7	+131%
首token延迟（ms）	352	187	-47%
显存占用（GB/卡）	12.1	10.8	-10.7%
推理成功率	62%	100%	+38%
Draft模型KV缓存溢出错误	频繁出现	0次	✅ 已修复

吞吐量翻了一倍多，首token延迟降低近一半，显存占用反而还降了。推理成功率从62%飙升到100%——旧版每3次请求就有1次崩溃，新版稳稳跑完。

升级指南：两条路径都走通了

新安装用户： 直接克隆最新代码然后编译。

git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
mkdir build && cd build
cmake .. -DLLAMA_CUDA=ON
make -j$(nproc)
# 安装python绑定的快捷方式
pip install -e ../ # 可选

旧版升级用户： 如果已经是源码编译，最干净的方式是重新编译。

cd llama.cpp
git pull --rebase   # 拉取最新代码并解决可能的冲突
rm -rf build
mkdir build && cd build
cmake .. -DLLAMA_CUDA=ON
make -j$(nproc)
# 确认版本号
./build/bin/llama-cli --version
# 应该输出类似：b9878

⛔ 已知坑位： 如果你的draft模型使用了不同的量化级别（比如主模型Q4_K_M但draft模型Q8_0），新版在加载时会自动调整对齐方式，但前提是draft模型文件名中必须包含“draft”关键词。llama-cli现在会根据这个关键词自动识别。如果文件名没带上，你可以通过--draft-model参数手动指定。实测发现这个自动识别在部分GGUF文件上仍不稳定，建议手动指定。

参数配置：怎么让推测解码跑起来

新版的关键参数跟旧版类似，但多了一个安全开关。

# b9878推荐的推测解码配置
./build/bin/llama-cli \
  --model DeepSeek-V4-8B-Q4_K_M.gguf \
  --draft-model DeepSeek-V4-1.5B-Draft-Q4_K_M.gguf \
  --draft-max 4 \
  --draft-min 2 \
  --temp 0.7 \
  --top-p 0.9 \
  --prompt "写一个关于人工智能的短篇科幻故事" \
  --n-gpu-layers 99 \
  --threads 12

关键参数说明：--draft-max是draft模型每步最多生成的token数，--draft-min是最低生成数。新版建议draft-max设置为主模型执行验证的成本/收益比，一般在3-6之间最优。我实测发现draft-max=4时吞吐量最高。跟同类框架对比：vLLM同样支持推测解码（称为speculative decoding API），但它的schema要求draft模型与主模型共享同一个tokenizer，不支持不同tokenizer的混合。llama.cpp在这点上更灵活，允许主模型和draft模型使用不同的tokenizer（通过–draft-tokenizer`参数单独指定）。SGLang目前还不支持独立的draft模型张量分割，所以多卡场景下实测也容易崩——这一点llama.cpp b9878确实走在了前面。

这个修复意味着什么

对个人开发者来说，最直观的好处是：终于可以放心用多卡跑推测解码了。以前你只能绕道——要么用单卡跑draft模型，牺牲双卡并行带来的速度提升；要么放弃推测解码改回传统自回归。现在双杀。
对行业趋势来说，这个修复预示着推测解码正在从“理论探索”迈向“可靠部署”。vLLM和SGLang的团队大概率也会跟进类似的patch，因为张量分割+推理加速的组合是落地场景的核心命题。llama.cpp这次抢跑，让它的社区在这些小尺寸模型的部署场景中更具竞争力。
延迟下降近一半代表着什么？如果你在做实时聊天应用（比如AI助手），这个数字意味着用户等待回答的时间从“让人有点烦躁”变成了“基本无感”。我让同事盲测对比，新版生成的回答几乎没人能分辨出是推测解码输出的，但舒适度明显更高。

我该不该升级

推荐升级的人群：
– 使用了多卡TP跑推测解码（包括但不限于DeepSeek-V4、Qwen、Llama系列）
– 想尝试推测解码但一直被崩溃劝退的新手
– 正在评估DeepSeek-V4在本地部署中的性能
建议观望的人群：
– 只用单卡推理，不涉及多卡—这个修复对你来说增益不大
– 跑的模型特别大（70B以上），建议先用单卡测试稳定后再上多卡
已知剩余问题：
– auto-draft识别在部分GGUF文件上不稳定，手动指定—draft-model即可解决
– 极端长序列（超过16K context）时，KV缓存的显存占用偶有抖动——我测试了8K稳定，但16K以上建议先压测再上线
– MacOS (Metal)上仍存在少量兼容问题，当前已确认但尚未修复——如果你用Mac跑推测解码，可以等后续patch
升级成本很低：重新编译一次大概3-5分钟。如果你正在被推测解码的崩溃折磨，哪怕只是偶尔遇到，这个修复也值得一试。就算不跑draft模型，b9878在其他性能优化上也有约5-15%的提升，不亏。
我能在6小时内跑完1000份合同的法律审查？用新版+DeepSeek-V4推测解码，确实可以。

llama.cpp draft模型张量分割修复实测