这是「泽安不加班」的第 7 篇原创。
大家好，我是泽安，见字如面～
上个月写 Qwen3.8-27B 私有化部署那篇，被问得最多的一个问题：本地跑 27B，速度到底怎么样？并发速度到底能不能忍？当时我的回答是，能干活，但真不算快。一条长代码生成出来，得盯着进度条等。
所以我把提速当成一个正经项目来搞：不换卡、不改模型，就看能不能把生成速度提上去。
网上搜了一圈，最火的是 DeepSeek 开源的 DSpark，宣传很诱人：无损推测解码，最快能到 3 倍。我差点就信了，但动手前留了个心眼： 3 倍是在什么条件下跑的？我的服务是几十路请求一起压的，能一样吗？
于是我做了一件事：同一台机器、同一个模型，把三种配置挨个测了一遍。并发从 4 一路压到 64，长代码和短对话两个典型场景。
结论先放这： 网上没骗你，但只讲了一半。DSpark 确实能接近翻倍，但它只赢一种情况；真正稳赢、而且一分钱不花的，是另一个“免费”方案。
先用人话讲清楚：这两种“提速”到底在干嘛
大模型生成文字，是一个词一个词往外挤，每挤一个词，整个模型就要完整算一遍，慢就慢在这。
推测解码的思路：派一个又快又小的“草稿员”先猜一串词，主模型再一次性批量“验收”，猜对的收下，猜错的扔掉重来。验收一串和验收一个，花的力气差不多，等于把好几次计算并成一次，速度就上来了。关键是，每个词最后还是过主模型这一关，猜错的重来，所以 无损，不是拿质量换速度，是纯赚 。
这条路有两个实现：
- MTP ：主模型出厂自带的“多 token 预测头”，草稿员长在模型里，免费，零下载。
- DSpark ：DeepSeek 开源的推测解码，相当于在外面“雇”一个 2.7GB 的专职小模型当草稿员，一次赌 7 个，赌得更深。他需要下载、要搬运、还占显存。
环境先交代：A800 双卡、Qwen3.8-27B（FP16），和上一篇是同一套环境。
上一篇qwen38 私有化部署文章： Qwen3.8-27B 私有化实测：数据不出内网，它开始替我干活了（附部署教程）
测法上我坚持三条，缺一条数据都不算数：
1. 【参数配置要一致】 除了推测解码那部分，其余参数逐字对齐，连前缀缓存都不能漏，不然基线白占便宜，算出的收益是虚的。DSpark 因为草稿模型要多占约 3GB 显存，它那台容器的显存利用率单独从 0.90 让到 0.80，这是方案本身的开销，不算偏袒谁。
2. 【AB 必须串行跑】 显存都拉到接近满，两个容器没法同时挂，停一个、起一个。
3. 【并发 4 压到 64，场景分开看】 长代码和短对话，都测试下，他们对提速的敏感度也不同。
三份对照，我都是用 docker 容器跑的，推理框架是 vLLM 0.27.1 的官方镜像（内网环境换成你们内网拉好的同名镜像即可）。先看你原来的启动命令，也就是什么都不开的基线：
docker run -d --name qwen-base \
--runtime nvidia --gpus '"device=4,5"' \
-v /data/Qwen3.8-27B:/model \
-p 8686:8000 --ipc=host \
vllm/vllm-openai:v0.27.1 \
--model /model \
--dtype bfloat16 \
--tensor-parallel-size 2 \
--max-model-len 200000 \
--max-num-seqs 64 \
--gpu-memory-utilization 0.90 \
--enable-prefix-cachingMTP 的开法：把上面的命令复制一份，容器名和端口改成 mtp 的（8687），然后追加这一行，其余一字不动：
--speculative-config '{"method":"mtp","num_speculative_tokens":3}'DSpark 就要分三步了，这也是它比 MTP 折腾的地方：
第一步，把草稿模型弄到手。 注意一定要下 vLLM 兼容格式（
Doopeworld/Qwen3.8-27B-DSpark-vLLM
）。原版那个是给 SGLang 用的格式，直接喂 vLLM 会加载失败，我第一次就栽在这。下载：
export HF_ENDPOINT=https://hf-mirror.comhuggingface-cli download Doopeworld/Qwen3.8-27B-DSpark-vLLM \
--local-dir Qwen3.8-27B-DSpark-vLLM
第二步，起容器时把草稿目录也挂进去。 和基线比，DSpark 容器多一行草稿挂载，显存利用率要从 0.90 让到 0.80（给草稿腾位置），再加 --trust-remote-code 加载它的自定义结构：
docker run -d --name qwen-dspark \
--runtime nvidia --gpus '"device=4,5"' \
-v /data/Qwen3.8-27B:/model \
-v /data/Qwen3.8-27B-DSpark-vLLM:/draft_model \
-p 8688:8000 --ipc=host \
vllm/vllm-openai:v0.27.1 \
--model /model \
--dtype bfloat16 \
--tensor-parallel-size 2 \
--max-model-len 200000 \
--max-num-seqs 64 \
--gpu-memory-utilization 0.80 \
--enable-prefix-caching \
--trust-remote-code \
--speculative-config '{"method":"dspark","model":"/draft_model","num_speculative_tokens":7,"draft_sample_method":"probabilistic"}'压测我写成了并发扫描脚本，从 4 扫到 64 自动出汇总表，纯 Python 标准库，服务器上不用装任何东西。
长代码提示词：
写一个完整的 Python 脚本：读取一个包含 10 万行 JSON 的日志文件，按用户 ID 聚合统计各用户的请求次数、平均耗时与错误率，并把结果输出为 CSV。要求包含命令行参数解析、错误处理与单元测试示例。
短对话提示词：
用三句话介绍深圳这座城市的特点。
结果：网上只讲了一半
先看长代码场景（这是 27B 私有化最常干的活，一次要生成几千 token）：
表里最扎眼的是并发 4 那颗星：DSpark 冲到 91.3 tok/s，比不开快了 91%，接近翻倍。网上那些「3 倍」的基准，基本都出自低并发、长输出这种理想工况。没说谎，但只讲了最好听的一半。
并发一起来，画风突变。到 32 路，DSpark 先跌破基线，倒亏 8%；过了 40 路基本翻不了身，48 路亏 21%，56 路亏到最深的 31%，64 路还是亏 28%。原因也不复杂：草稿员自己也占算力、占显存。单路没人抢，它能赌赢；几十路一起挤，它猜得跟不上，抢资源倒是积极，那点加速全被吃回去了。
而免费自带的 MTP 全程没掉链子：8 到 16 路稳在 +87% 到 +93%，几乎翻倍，峰值跟 DSpark 最亮眼那下打平；40 路还有 +26%，56 路还有 +12%，到 64 路才回落到 +6%。一分钱不花、一个文件不用下载，这才是这轮里性价比最高的方案。
再看短对话，接近 Agent 一轮工具调用，结论更干脆：
MTP 从 4 路的 +67% 一路平缓下滑，40 路以后基本贴着基线走，48 到 64 路始终在一个百分点内波动，属于测量噪音，高并发没崩。
DSpark 从 12 路起就低于基线，20 路亏三成，56 路最深亏到 57%，64 路只剩基线一半左右。拿它跑 Agent 这类短平快的活，基本可以不考虑。
说点大实话
测试完后，最大的感受不是“翻倍了”，而是“差点被带偏”。
DSpark 是个好东西，DeepSeek 这波开源也是真材实料，在它的理想工况（资源充足、低并发、长输出）里，它确实是最快的那个。但现实世界的私有化服务，大多是几十路请求一起压上来的。 对绝大多数人来说，答案是那个不起眼的免费选项：MTP。 一行配置、零下载零成本，8 到 16 并发区间几乎翻倍。这大概是我折腾推理优化以来，性价比最高的一次改动。
再往深说一层：你当初为了“数据不出内网”买的机器，潜力其实还没榨干。 先别急着买新卡，把推理侧这些无损优化做一遍，往往比换硬件划算得多。
还有一句话，想送给跟我一样爱折腾的人： 优化之前，先想清楚你的负载长什么样。 单路党、并发党、Agent 党，答案是三个不同的方案。别人的作业，抄之前先看看人家的卷子是不是和你同一张。
你的私有化模型平时是几个并发在跑？主要喂给 Agent 还是给人用？评论区报个数，咱们可以对一下答案。
注：本文基于个人真实使用体验，仅代表个人观点。Qwen3.8-27B、MTP、DSpark 均为开源模型或框架能力，部署方式与效果可能随硬件，版本而变化，请以官方信息为准。
我是泽安，一个专门在真实工作里折腾 AI 工具、努力早点下班的博主。我们下期见～
能看到这里，咱们已经是自己人了。先谢谢你耐心读完！
想第一时间收到更新，记得给「泽安不加班」加个星标⭐
最后祝咱们这些职场牛马：用好 AI，少走弯路，早点下班～
热门跟贴