去年我写过一篇 本地部署大模型实战：Ollama + Open WebUI 完整教程，当时用的结论是"本地 7B-14B 够用，别追求极致性能"。但半年过去，情况变了——Qwen3.5-27B 在单张 3090 上跑出了 129.5 tok/s。
什么概念？我 Ollama 跑 Qwen2.5-14B 大概 40 tok/s，14B 参数翻倍到 27B 还快了 3 倍多。这说明不是模型变快，是解码方法进化了。
上周看到七牛云 trycua 团队的一篇工程实践（来源：SegmentFault《如何在单张 RTX 3090 上让 Qwen3.5-27B token 生成速度提升 6 倍》），他们用了三个组合手段把速度干到这个数字。我花了两天时间理解他们的方案，下面是我消化后的版本——重点是普通人能学到什么，而不是复现他们的代码。
很多人看到 Qwen3.5 就以为是普通 Transformer，不是的。它的 64 层结构里：
| 层类型 | 数量 | 特点 |
|---|---|---|
| 完整 softmax attention | 16 层（每 4 层一次） | 标准 Transformer |
| Gated DeltaNet | 48 层 | 线性注意力，长上下文友好 |
加上 M-RoPE 编码（维度划分 [11,11,10,0]）和独立的 SSM 状态缓存，它本质上是个"Transformer + 线性注意力"的混合体。
这对我们意味着什么？主流工具（llama.cpp、vLLM、Ollama）都是为标准 Transformer 优化的，对这种混合架构支持不完整。trycua 团队就是因为这个原因，才选择自己动手造轮子——如果你的模型不在主流框架的舒适区，要么等官方适配，要么自己搞。
trycua 的方案核心是三招组合拳，我逐一拆解，并说清哪些能直接用、哪些只是"知道原理就好"。
核心思想：与其一个字一个字生成（AR，自回归），不如用一个"小模型"先猜一段话（draft），然后用主模型一次性验证。猜得快 + 验证也快 = 整体提速。
Draft 模型（轻量级）：快速生成 16 个候选 token
Target 模型（完整模型）：一次性并行验证这 16 个 token
结果：验证通过的保留，失败的替换重来
（来源：SegmentFault 原文）
trycua 用了 DFlash Block-Diffusion 策略——draft 阶段一次生成一个 token 块（block），比逐个猜更快。最终 129.5 tok/s 比 baseline 37.78 tok/s 快了 3.43 倍。
普通人能学到什么？
投机解码不是 trycua 独创，llama.cpp 已经支持几种投机解码方案：
# llama.cpp 的投机解码示例
./main -m target-model.gguf -md draft-model.gguf \
--draft 16 --n-predict 256
-md：指定 draft 模型（小模型）--draft 16：一次猜 16 个 token（实测）我试过用 Qwen2.5-7B 当 draft 模型，Qwen2.5-14B 当 target，速度确实提升了约 2 倍。但配置起来比 trycua 的定制版复杂得多——draft 模型选得不好，接受率低，反而更慢。
观点：投机解码是未来本地部署提速的关键技术。但目前成熟度有限，对普通用户来说，等 Ollama/llama.cpp 的集成度更高再用，更划算。
这是最容易上手、收益最大的一招。
常规情况下，KV cache 是 FP16（每个值 2 字节）。Qwen3.5-27B 跑 128K 上下文，FP16 的 KV cache 要吃掉 6.6 GB 显存。3090 才 24GB，模型权重 + 运行时根本塞不下。
trycua 把 KV cache 压缩成 Q4_0（4 位量化），从 6.6 GB 降到 0.2 GB——8 倍压缩。
| KV Cache 格式 | 显存占用（128K 上下文） |
|---|---|
| FP16 | 6.6 GB |
| Q4_0 | 0.2 GB |
（来源：SegmentFault 原文）
代价：短上下文下准确率损失约 3%（HE 测试 AL 从 8.56 降到 8.33）。但在长上下文下反而更好——因为之前根本塞不下 128K，现在能跑了。
普通人能学到什么？
llama.cpp 和 Ollama 都支持 KV cache 量化。Ollama 在 Modelfile 里可以直接指定：
# Modelfile 里加这行
PARAMETER kv_cache_type q4_0
（实测）我在 Qwen2.5-14B 上试了 Q4_0 KV cache，在 12K 上下文场景下速度提升 15%，质量没有感知到明显下降。如果你的场景是长对话（比如分析长文档），这招值得开。
观点：KV cache 压缩是"性价比最高"的优化。你不需要理解原理，只要加一行参数，显存占用直接减半。对消费级显卡来说，这一招比换卡更有效。
trycua 做了一个聪明的取舍：没有重写 Qwen3.5 的所有注意力机制，而是只移植了 graph glue（计算图胶水代码）到 ggml，保留原有的 DeltaNet CUDA 内核。
✅ 保留现有 DeltaNet CUDA 内核（不动）
✅ 只移植 graph glue 到 ggml
❌ 不链接 libllama 的任何内容
结果：删掉 deps/llama.cpp/src/ 目录，库仍然能编译成功。
（来源：SegmentFault 原文）
普通人能学到什么？
这条思路在工程上很有价值——你已经有一个能跑的系统，不要为了优化就去动核心逻辑。只在数据输入输出层面做优化，风险可控，出问题也容易定位。
我在做 Java 项目重构时也用过类似的思路：把旧系统的核心业务逻辑不动，只在 API 层和 DTO 层加缓存、加适配，就能把响应时间砍掉一半，而且不影响已有业务。这种"最小改造原则"在软件工程的很多领域都适用。
关键数据，相同配置下（RTX 3090 + Q4_K_M 目标模型 + BF16 draft 模型）：
| 方法 | 速度（tok/s） | 相对提升 |
|---|---|---|
| AR 基准（2026-02-07） | 37.44 | baseline |
| AR 基准（2026-04-20） | 37.78 | baseline |
| SGLang AWQ 最佳实践 | ~46 | 约 1.2x |
| DFlash DDTree budget=22 | 129.5 | 3.43x |
129.5 tok/s 是什么体验？写一条 500 token 的回答只要 4 秒。对日常使用来说，这个速度已经足够流畅，甚至感觉比云端 API 更快（云端还要算网络延迟）。
另外作者在 Qwen3.6-27B 发布后也做了测试：89.7 tok/s @ 60K 上下文，投机接受率 100%。也就是说，不仅快，而且每一行都有效——投机解码的接受率越高越好，100% 意味着几乎没浪费。
不用折腾投机解码。最简单的做法：
# 拉一个 Qwen2.5-14B 量化版
ollama pull qwen2.5:14b
# 或者用 llama.cpp 加载 GGUF
./main -m qwen2.5-14b-q4_k_m.gguf -p "你好"
（实测）3090 上跑 Qwen2.5-14B 量化版大概 40-50 tok/s，完全够用。
用 llama.cpp 的 draft-target 模式：
# target 模型（大）+ draft 模型（小）
./main -m qwen2.5-14b.gguf \
-md qwen2.5-7b.gguf \
--draft 16 \
-p "写一个 Java 快速排序"
（实测）配置正确的话，速度提升约 1.5-2 倍。但 draft 模型选得不好，接受率低，反而更慢。建议先从 draft 模型参数量是 target 的 1/4 开始调。
用 KV cache 压缩：
# Ollama Modelfile 里加
PARAMETER kv_cache_type q4_0
PARAMETER num_ctx 32768
观点：长上下文场景下，Q4_0 KV cache 几乎白送。如果是短对话高精度要求，慎用。
trycua 团队在文章末尾提到的一些进展，值得关注：
这些都在 Luce DFlash 项目的路线图上，持续关注会有惊喜。
RTX 3090（二手 ¥2500）能跑出 130 tok/s 的 Qwen3.5-27B，意味着普通人花不到 3000 块钱就能拥有一台响应极快的本地 AI 服务器。这对隐私敏感场景、学习研究、以及日常开发辅助来说，已经是一个非常实用的选择。
如果你有一张 3060 / 3080 / 3090 / 4070，别让它吃灰。装上 Ollama 跑个 7B-14B，感受一下本地大模型的流畅度。如果追求更高性能，可以试试投机解码 + KV cache 压缩，这两个组合能再提速 2-3 倍。
核心观点：本地部署大模型的最大瓶颈不是硬件，是软件生态。trycua 的方案之所以能到 130 tok/s，不是因为 3090 本身多强，而是因为他们为 Qwen3.5 专门写了一套推理引擎。等 llama.cpp / Ollama 把这类优化做成标配，普通用户也能享受这个速度。
想了解如何用最省心的方式部署本地大模型，看 本地部署大模型实战：Ollama + Open WebUI 完整教程。如果你对 AI 编程工具有兴趣，Claude Code 深度评测 和 Codex CLI 上手体验 可以对照看。
本文参考了 SegmentFault 文章《如何在单张 RTX 3090 上让 Qwen3.5-27B token 生成速度提升 6 倍》（作者：七牛开发者 / trycua 团队），结合博主个人部署经验和工程思考进行了二次创作。原文更偏底层技术细节，本文侧重"普通人能学到什么、能用上什么"。