本地单卡748 token/s：Bonsai2+Ninfer+KVMem极值实践

一次把三件利器拼在一起

国庆前，B站UP主基于“沈三叔”大佬公开的技术文档和部署方案，在16G显存的本地环境里跑通了一个压缩版大模型，当时解码速度逼近400 token/s、预填充约2500 token/s，已经相当惊艳。国庆期间上游连续迭代，作者在10月初回来后重新上手，发现新版本做了一件关键的事——把 Ninfer 推理引擎、Bonsai 压缩模型和 KVMem 显存卸载 三者结合到了一起。

这个组合带来的不是简单的线性叠加，而是一次意料之外的性能跃迁：解码峰值冲到了 748 token/s，预填充（作者口中的“预填充/玉田冲”）最高达到 3.8K token/s。相比此前的近400，解码速度几乎翻倍。作者坦言“到现在也不知道这个数字是怎么出来的”，因为单看每个组件的收益，提升大概只有10%—15%，但组合之后产生了明显的协同效应。

翻倍速度的来源：投机解码的化学反应

速度跃迁的核心，在于解码层面的多预测头融合。原有方案里用的是 MTP 与 D-Flash 两种预测头，在显存较充裕时 D-Flash 的命中收益更高，这也是此前拿到近400 token/s 的基础。新版本把 D-Flash（二代）、MTP 与 N-gram 投机解码混合到一起后，情况发生了变化。

作者特别强调：D-Flash2 和 N-gram 放在一起不是简单相加或加成，而是产生了翻倍级别的效果。这类投机解码（speculative decoding）的本质是用小代价预测多个 token、再由主模型批量验证，命中率越高、每步验证产出的有效 token 越多。多种预测机制在同一条流水线上互补，命中率被整体抬升，于是单并发速度被拉到了七字头。

值得强调的是，这是**单路（单并发）**成绩。作者反复提醒：不要和服务器多并发吞吐去比，Ninfer 这类专为通义千问^广告类模型设计的引擎，天生就有 llama.cpp 等通用方案两倍左右的速度优势，单并发下跑出740+已经非常可观。

投机解码（Speculative Decoding）是一种加速大语言模型推理的技术范式，核心思想是"用小模型猜、用大模型验"。具体流程是：先由一个轻量级的草稿模型（draft model）或预测头快速生成若干候选 token，再交由主模型一次性并行验证，接受与主模型分布一致的部分、拒绝不符合的部分。由于验证多个 token 的计算量远小于逐个自回归生成，整体吞吐量得以大幅提升。命中率是投机解码的关键指标：命中率越高，每次验证轮次产出的有效 token 越多，加速比就越大。MTP（Multi-Token Prediction）、D-Flash、N-gram 分别是不同来源和粒度的预测机制——N-gram 利用已生成文本的局部重复模式做廉价预测，MTP 和 D-Flash 则是模型层面的多头或辅助解码结构。将多种机制叠加使用，相当于在不同场景下总有一种机制命中率较高，从而整体抬升平均命中率，这也是此次组合产生非线性加速的根本原因。

KVMem 带来的部署弹性

另一条主线是 KVMem。它的作用是把 KV 缓存池从显存卸载到系统内存，从而把宝贵的显存腾出来。对16G显存的本地玩家来说，这意味着可以尝试更大的量化模型，而不至于被显存卡死。

一个此前的难点是 KVMem 与 Ninfer 原本互不兼容——两者在编码和缓存处理上存在冲突。作者推测上游是直接协调了 KVMem 作者、或自行打通了这层兼容性，总之让两件事可以同时成立。这给部署带来了极大的想象空间：作者正在尝试把一个正常量化的 Q2/Q3 模型装进这套环境，用混合投机解码配合 Ninfer 的高速引擎，看能否在内存承载 KV 的前提下依然跑出不俗的速度。

他给出的参照是：此前用 llama.cpp 配合 KVMem 起普通模型大约能到一百多 token/s，而把 KV 放内存原本以为会很慢，但结合投机解码后未必，这正是值得继续探索的方向。

KV 缓存（Key-Value Cache）是 Transformer 模型在自回归推理时用于存储注意力机制中间结果的数据结构。每生成一个新 token，模型需要访问此前所有 token 对应的 Key 和 Value 向量，将它们缓存在显存中可以避免重复计算，代价是随上下文长度线性增长的显存占用。在长上下文场景下（如 32K、180K），KV 缓存往往比模型权重本身还大，成为本地部署最主要的显存瓶颈。KVMem 通过将这部分数据卸载（offload）到系统内存（DRAM），以带宽换显存容量——内存带宽低于显存，理论上会引入延迟，但配合投机解码后每轮验证产出更多 token，摊薄了单次访存的时间成本，使实际速度下降幅度远小于预期。

实践中的坑：雷霆大思考与异常压缩

这套方案落地并非一帆风顺，作者在构建室文档里逐步记录了踩过的坑。最典型的是 “雷霆大思考” 相关的异常：

• 输出 stop 却不吐正文：思维链跑完后既没撞思维预算的墙，显存也没爆，模型输出了 stop 就停住，不进入正文生成。作者此前自己打了一个补丁，思路是利用引擎里现成的分支——一旦检测到 stop，就强制跳转到正文分支继续生成，在不破坏原有逻辑的前提下“打补丁”。后来上游也发布了更优雅的前端侧解决方案，作者复测多轮确认问题得到缓解，最终选择迁移到上游新基线（因为它还顺带修了其它问题）并重新编译。
• 莫名其妙的提前压缩：设置了180K上下文，按理应到80%—90%才触发压缩，但实际跑到20%—30%就压缩一次，导致推理成果丢失、反复研究反复压缩，形成死循环。作者怀疑这种异常压缩是死循环的诱因之一，但病因未明，公开征集社区思路。

这两个问题既来自引擎实现，也可能与 27B 原始模型本身的长思考特性（32K 思考仍得不出结果）叠加量化后放大有关。

"雷霆大思考"指的是具备长思维链（Chain-of-Thought）能力的模型在推理时进入超长内部思考循环的状态。这类模型（如 DeepSeek^广告-R1 系列）在训练时被鼓励在输出正文前进行充分的内部推理，但在量化压缩后，原本帮助模型"知道何时停止思考"的能力可能退化，导致思维链无限延伸而不进入正文生成阶段。上下文压缩（context compression）则是另一项应对长上下文的工程手段：当上下文长度接近设定上限时，系统自动对历史内容进行摘要或裁剪，以腾出空间继续生成。理想情况下压缩应在接近容量上限时触发，但如果压缩逻辑与模型的思考状态检测存在冲突，就可能在推理进行到一半时错误触发，导致思维链中间结果被裁掉、模型需要重新推理，进而陷入"推理→压缩→重推理"的死循环。

该怎么公平地看待 Bonsai 这类压缩模型

抛开速度，作者花了很大篇幅讨论对 Bonsai 这类极致压缩小模型的评价。他提出了几个“不公平”的视角，核心观点很值得玩味：

一是比较对象错了。 拿它和能在本地跑的 MoE、Q2/Q3 的27B比质量确实落后，但如果和一两年前更大的模型比，它在很多能力上并不差。把50多G的模型压到5—7G还能保持相当的逻辑、代码与多轮对话能力，本身就是了不起的工程。

二是它的特点就是“傻快”。 作者实测一道知乎式题目16秒一轮、平均235 token/s，查bug这类任务基本没问题。速度本身就是效率，单并发740+的体验在交互场景下非常爽。

三是模型不是越大越好。 从年初 Agent 范式兴起后，行业逐渐意识到能力、定位、工具调用与框架配合比单纯堆参数更重要。给一个小模型配上合适的框架、技能和环境，能显著放大它的实际作用——网页端只能聊天，放进 DSH、Code Buddy 这类框架里就能干活。

四是极致压缩的技术方向有长期意义。 如同视频、音频压缩，把大模型压缩到可进手机、可进边缘设备的量级，对AI普及和商业化影响深远。作者乐观地认为，未来8G显卡配合这类量化技术，有可能干出今天上百B千亿模型的活。

把小模型用好：框架、提示词与行为干预

作者观察到 Bonsai 有明显的行为特征：懒、想尽快交差、不爱主动搜索、不爱调用工具。在简洁模式下它更容易陷入“雷霆大思考”——因为手边没有可用工具，只能逼自己一直想；而在工具充裕的标准模式下，它更容易把注意力收敛到调用工具或输出正文上。

由此他提出两点工程化思路：

1. 给它轻量但清晰的环境。 DSH 对小模型可能比传统重型框架更友好，系统提示和约束更轻。相比之下，一些框架动辄塞几十K到上百K的提示词、规范和工具，会把小模型本就有限的注意力“冲得稀巴烂”。
2. 用提示词和技能做行为干预。 比如明确告诉它“到某个节点就不能再思考，必须落盘、进入正文”，哪怕只写三五个字也要把循环接下去；再比如通过技能触发让它去联网检索——实测它被明确要求后其实搜得挺准，只是不愿主动做。

作者还提到自己有一整套代码工作规范（他称之为“SDV”），强调审题、拆解、规划、落证据、审核、测试、防幻觉、可回退的闭环，在这套规范下不同模型产出的质量会趋于接近。大模型内部已固化了工程规划和迭代冲动，小模型没有这种内化能力，因此更需要靠外部框架“扬长避短”。

小结

这期实践的价值不在于单个数字，而在于展示了 Ninfer + Bonsai + KVMem 这套组合的弹性：投机解码融合带来单卡单并发740+ token/s 的极值，KVMem 把 KV 卸载到内存释放显存承载更大量化模型，整体为本地部署提供了更大的腾挪空间。另一边，雷霆大思考、异常提前压缩等问题仍待社区共同攻关。对想复现的玩家，作者建议直接把相关技术文档与构建流程交给AI阅读、再按自己的环境逐步照做。