让 35B 模型跑到 200 tok/s：Qwen3.6 MTP 加速详解与云端调用捷径

本地部署过大模型的人都有这种体会：模型越强，等得越久。当推理速度长期卡在每秒几十个 token，再聪明的大脑也让人着急。不久前，开发者 FraQtl 在 Hugging Face 上放出了 Qwen3.6-35B-A3B-Hi-Fi-MTP-runtime，这个版本在 A100-80GB 上跑出了接近 200 token/s 的生成速度，加速比达到 1.49 倍。透过它，我们能窥见一种让大模型真正“快起来”的工程路径。

自回归模型为什么慢

传统大语言模型采用 Next-Token Prediction，每次只预测下一个词，然后把预测结果拼回上下文，再预测下一个。这种串行方式让 GPU 每一次都不得不把整份模型参数重跑一遍，大量计算资源浪费在重复的激活搬运上。就像写文章每写一个字都要重新翻遍词典，效率自然高不了。

MTP：一次猜一串，再统一验证

MTP（Multi-Token Prediction）的思路很直接：在每个位置同时预测多个后续 token，而不是一个一个往外蹦。具体实现上，它用一套轻量级的草稿模块快速生成一串候选 token，再让主模型一次性校验这些猜测。只要大部分猜对了，就相当于用一次前向传播换来了多个 token 的产出。这种“批量猜测、集中验证”的机制，正是 MTP 版本获得可观加速的根本原因。

模型配置与技术细节

Qwen3.6-35B-A3B-Hi-Fi-MTP-runtime 基于 unsloth 的 Qwen3-Next-80B-A3B-Instruct-GGUF（BF16）进行量化。FraQtl 采用了 Hi-Fi Q4_K_M 方案，同时特别将 MTP 模块的精度保留在 Q8_0，以保障预测质量。上下文长度设置为 4K，最大预测深度 64 个 token，测试工具为 llama.cpp 的 llama-server。

核心规格一览：

基础模型：unsloth/Qwen3-Next-80B-A3B-Instruct-GGUF (BF16)
量化方法：Hi-Fi Q4_K_M，MTP 模块覆盖 Q8_0
MTP 块：blk.40，专门保留给投机解码
上下文长度：4K
最大预测 token 数：64
量化矩阵：imatrix_codemath_v1_256k.dat
测试硬件：NVIDIA A100-80GB

实测数据：加速效果有多明显

在 A100-80GB 上，该模型的解码速度达到 198.96 token/s，而关闭投机解码的基准速度是 133.61 tok/s，提升约 49%。平均接受率 75.99%，意味着主模型验证 MTP 模块产出的 token 时，超过四分之三被直接采纳。三次不同随机种子（42、1337、2024）的重复测试显示，接受率稳定在 75.85%~76.14%，加速比在 1.472× 至 1.502× 之间，一致性很好。

分领域来看，数学推理任务加速效果最突出，达到 1.529 倍，接受率也最高（78.07%）。这很可能因为数学推导的步骤清晰、逻辑链条确定，草稿模块更容易猜中。代码生成接受率稍低，为 73.69%，加速比 1.451 倍。通用知识类居中。结构越规范、确定性越强的文本，MTP 的收益就越明显。

K 值调优：不是预测越多越好

n_max（单次预测 token 上限）是 MTP 的关键参数。FraQtl 专门分析了不同 K 值的表现：

K 值	接受率	速度 (tok/s)	加速比
3	73.0%	173.8	1.30×
4（推荐）	76.0%	199.0	1.49×
6	47.3%	153.0	1.14×
8	35.7%	109.8	0.82×

规律很清晰：预测数越多，接受率越低。K=8 时，速度反而跌到不用 MTP 以下的水平，因为频繁的预测失败带来了额外的回退开销。综合看来，K=4 是当前的最佳平衡点。

运行前必须避开的几个坑

第一，务必使用 chat 端点。直接用原始 prompt 调 /completion 接口，接受率会降到约 63%，加速比只剩 1.30×。正确的姿势是走 /v1/chat/completions，或手动套用 Qwen 的 chat 模板。

第二，对硬件和上下文敏感。以上数据均在 A100-80GB、4K 上下文中测得。若使用 24GB 显存的消费级显卡或需要更长上下文，加速效果会打折扣。

第三，暂时离不开 llama-server。截至 2026 年 5 月，llama-cpp-python 仍未暴露 MTP 草稿路径，所以必须用 llama-server 运行。LM Studio 从 0.4.14 版本起支持 MTP，但需确保底层版本不低于 2.15.0。

本地启动命令

环境要求：支持 CUDA 的 NVIDIA GPU，llama.cpp 主分支（commit 2f6c815dc 或更新），并已编译支持 Qwen 3.5/3.6 NextN MTP loader。

bash

llama-server \
 -m qwen36-35b-a3b-hi-fi-mtp-runtime.gguf \
 -ngl 999 -c 4096 \
 --spec-type draft-mtp \
 --spec-draft-n-max 4 --spec-draft-n-min 1

API 调用时可在请求体中传入投机参数：

json

{
  "messages": [{"role": "user", "content": "用 Python 写一个快速排序函数"}],
  "max_tokens": 256,
  "temperature": 0,
  "speculative": { "type": "draft-mtp", "n_max": 4, "n_min": 1 }
}

没有 A100 怎么办？通过 4SAPI 直接调用 Qwen 3.6

如果手头没有高端 GPU，或者不想折腾复杂的本地部署，还可以走另一条路：借助模型网关来调用托管版的 Qwen 3.6。目前 4SAPI 已经接入了该模型，它提供一套兼容 OpenAI 接口的标准化访问层，开发者只需将请求的 base URL 指向 https://4sapi.com，使用平台分配的密钥，并在 model 字段中指定 qwen3.6-35b-a3b，就能直接发起对话请求，代码无需做额外适配。

换句话说，你仍然可以用熟悉的 Chat Completions 接口调用 Qwen 3.6，同时获得与本地类似的高速推理体验，而无需自己维护 GPU 服务器。调用示例如下（Python）：

python

import requests

headers = {
    "Authorization": "Bearer 你的4SAPI密钥",
    "Content-Type": "application/json"
}
payload = {
    "model": "qwen3.6-35b-a3b",
    "messages": [{"role": "user", "content": "解释一下 MoE 架构"}]
}
resp = requests.post("https://4sapi.com/v1/chat/completions",
                      headers=headers, json=payload)
print(resp.json()["choices"][0]["message"]["content"])

这样，无论本地硬件条件如何，都可以快速体验到 MTP 加速带来的流畅输出。对于需要高频调用或多项目切换的开发者，统一的网关也能简化密钥管理与模型切换的复杂度。

小结

Qwen3.6-35B-A3B-Hi-Fi-MTP-runtime 展现了多 Token 预测在工程上的实在收益：通过一个精心量化的草稿模块，在数学、代码及通用领域均实现了接近 50% 的吞吐提升，且稳定性经得起不同随机种子的考验。K 值调优、chat 模板的正确使用，以及硬件适配，是落地时需要盯住的几个关键点。

如果你拥有 A100 级别的资源，本地跑 llama-server 能带来极致的控制力；而如果你更倾向于开箱即用，通过 4SAPI 的云端接入则提供了一条零部署成本的捷径。两种方式背后，MTP 的思路本身也预示着推理加速的一个重要方向——与其和串行瓶颈硬碰硬，不如换一种“批量猜测”的解题思路。