⼀、问题不在模型，在于 Agent 的提示词已经涨到了另⼀个量级

把大模型装进桌面设备，第一反应通常是“模型够不够大” 。但当我们真正把 BoCoder 的编码工作流跑在本地时，卡住体验的并不是模型能力，而是一次请求要吞下多少上下文。

一次典型的 Code Agent 调用，输入并不是用户敲下的那一行自然语言，而是层层叠加的结果：平台级系统提示词、 Agent 角色提示词、可用 skill 的摘要清单、工具与函数调用的 schema、检索回来的工程上下文、当前打开的文件片段，再加上多轮对话历史。这些内容单看每一项都不算多，叠在一起就轻松进入万级 token，长任务里 32k 起步、逼近 128k 也很常见。

与此同时，桌面级设备的 decode 速度只有几十tok/s。这两个数字放在一起，体验就变得难以接受：模型生成一个八百 token 的补丁需要十几秒的等待，而一个完整的工程任务往往要连续触发代码检索、文件分析、方案生成、补丁编写、测试修复、结果总结等十余轮模型调用。每一轮几十秒的等待，沿着 Agent 链路一路叠加，最终变成用户对着光标发呆的几分钟。

更麻烦的是，这个瓶颈会随上下文变长而恶化。后文的实测数据会显示，同一台设备上，模型在 4k 上下文时还能跑到 68 tok/s，到了 Agent 真正的工作区间（64k–128k）就只剩 45 tok/s 上下——恰好是 Agent 最需要速度的地方，硬件最跟不上。

这正是我们把投机解码（speculative decoding）落到桌面终端算力上的原因：不是为了在 benchmark 上多跑几个点，而是要让桌面级显卡设备真正具备可用的 AI Coding 能力。

投机解码对我们并不是一项新技术。博云的数据中心级推理引擎 AIOS BMP 已经在多个项目中把投机解码用在了真实业务负载上。这次我们做的，是把这套已经验证过的方案搬到桌面级算力，并结合博云自己的加速手段，把桌面推理引擎的速度再抬高一档——而且精度不受损。

⼆、投机解码改变的是 decode 循环本身

大语言模型生成文本时存在一个根本性瓶颈：GPU 拥有强大的计算能力，但自回归生成本质上是顺序执行的，因此大部分算力都处于闲置状态。每个 token 都需要一次完整的前向传播，每一步都要重新加载权重并同步内存。这种“内存访问 + 逐步依赖”的组合会推高延迟 、压低硬件利用率。

投机解码把目标模型（target model）与一个轻量级草稿机制结合 ：草稿机制快速给出多个后续token， 目标模型在一次前向传播中并行验证这些草稿，接受与自身预测一致的最长前缀，并从该前缀继续推理。

它真正改变的是 decode 循环 。标准自回归生成中，生成500个token大约意味着 500 次target forward ；投机解码则让草稿模型先提出多个候选， 由目标模型一次性验证，一次验证若能接受多个token，原本需要多次target forward 的生成就被压缩进一次验证 。因此投机解码加速的不是单次 target forward，而是减少 target forward 的次数。

它的收益由两个因素决定：draft model 的额外成本，以及 draft token 被接受的平均长度。接受得多，额外成本被摊销，吞吐提升明显；接受得少，draft model 就变成纯开销。这个特性让投机解码特别适合结构化、低熵 、约束强的输出任务——而代码生成正是这类任务的典型代表。代码输出受到语法 、缩进、类型、变量命名和上下文 API 的多重约束，后续token 的分布通常比开放式创作集中得多，只要draft 与target 足够匹配，接受率就能维持在较高区间。

还有一点对代码场景尤其重要：标准投机解码是输出无损的。验证阶段保持与目标模型一致的输出分布 ，被接受的token 与目标模型自己会生成的token 一致 。换句话说，开启加速不会让模型“变笨” ，这是它与量化、剪枝等以精度换速度的手段的本质区别。

三、从小模型草稿到 block-diffusion 草稿

早期投机解码通常拿一个更小的自回归模型当 draft model。这个小模型比目标模型便宜，但它本身仍然是逐token 生成 ——生成 4 个 draft token 就需要 4 次顺序 draft forward。每步成本降低了，草稿阶段的串行性却没有消除。对低延迟推理来说这很关键： 目标模型的串行 decode 只是被部分转移到了 draft model 上，整个循环仍未真正展开成并行计算。

Block-diffusion decoding 的思路不同。它的核心不是“再找一个更小的语言模型” ，而是把草稿生成改造成 block-level denoising 问题 。目标模型在 prefill 或 decode 过程中已经算出了 hidden states ，草稿模块以这些 hidden states 为条件输入，在一个 token block 内同时预测多个候选位置 。它不是从token history 重新理解上下文，而是在目标模型中间表示的条件下，对一组 masked positions 做并行补全。

下图展示了一个候选token block 在单轮解码中的组织方式 。图中的Target Decode Token（也称anchor）是已经提交的 token，后面的 MASK 位置代表需要草稿模块并行预测的未来token 。draft 模块基于目标模型 hidden states 构造自己的 context K/V，再让这些 query positions 去 attend 已有上下文。

这就是 block-diffusion decoding 能进一步加速的关键 ：普通投机解码已经减少了target forward 次数，但草稿阶段若仍逐  token 自回归 ，draft latency 就会限制整体收益； block-diffusion 把多个 draft positions 合并进一次 draft forward，让草稿阶段本身也接近批量计算。 目标模型随后一次性验证这组候选，接受与自身预测一致的最长前缀。

从工程角度看，这是一种外接式的 block-level drafter 。它不像 MTP 或 Medusa 那样要求目标模型内部带有额外的 multi-token prediction heads，也不同于 n-gram speculative decoding 那样只依赖上下文重复。它通过独立的 draft checkpoint 接入目标模型，同时复用目标模型的 hidden states，让候选token 更贴近目标模型分布。这种形态对本地推理格外友好——不需要重训目标模型，换模型时换 checkpoint 即可。本文实测使用的 DFlash 就是这一路线的实现，下文统一以 DFlash 指代所启用的推理加速。

四、它不解决什么: prefill 与 decode 的分工

既然痛点是“提示词长达上万 token”，就必须说清楚一件事 ：投机解码加速的是 decode，不是 prefill。

一次请求的首 token 延迟（TTFT） 主要由 prefill 决定，也就是模型读完那上万token 输入所花的时间；这部分开销投机解码并不能降低。真正让它在 Agent 场景仍然成立的，是两者在多轮链路中的成本结构完全不同：

• prefill 可以摊薄。 Agent 的长提示词有大量稳定前缀——平台系统提示词、 skill 摘要、工具 schema 在整个会话里几乎不变。借助前缀缓存与 KV 复用，这部分只需要支付一次，后续轮次命中缓存即可。

• decode 无法摊薄。 每一轮的输出都是全新的 token，都要重新逐个生成。一个工程任务十余轮调用、 累计数千token 输出，这笔成本一次都省不掉。

所以在 Coding Agent 这条链路上， prefill 是一次性的入场费 ，decode 才是反复累加的那一项。这也解释了为什么 decode优化的收益会在 Agent 场景中被显著放大——单轮省下的秒数，会沿整条链路叠加。

五、实测：长上下文与真实代码任务

易于接入不等于一定有稳定的端到端收益，实际加速还会受到上下文长度、 draft 接受率和本地推理实现的影响。为验证这种外接式 drafter 在本地环境中的真实表现，我们在 HP ZGX Nano G1n AI Station 上测试了长上下文与真实代码任务下的 output token throughput。在目标模型、上下文配置与生成任务完全一致的前提下，分别运行 target-only 基线与启用 DFlash 的配置 ，比较两者的 decode 吞吐差异。

测试所用的代码任务并非合成样例，而是来自项目中的真实源码。这样做是为了让测试贴近 coding 产品方向中的实际负载 ：模型需要阅读已有代码、理解边界条件、给出重构建议 ，或生成可落地的测试代码。这类任务比普通闲聊更依赖上下文理解，也更容易暴露投机解码在真实输出分布下的接受率与吞吐表现。

长上下文吞吐

Qwen3.6-35B-A3B 在 4k 到 128k 范围内均观察到稳定加速。基线吞吐从 68.30 tok/s 一路下滑至 44.93 tok/s；启用 DFlash后同样随上下文增长下降，但始终位于更高的吞吐区间， 128k 场景下仍有 81.39 tok/s ，约为基线的 1.81 倍 。全区间加速比落在1.81×（128k）到 2.15×（4k） 之间。 16k 处出现小幅回升（135.72 tok/s ，高于 8k 的 126.78 tok/s），来自该点上接受长度的波动，不影响整体趋势。

这里更值得注意的不是加速倍数，而是绝对吞吐落在哪一侧 。Agent 的上下文常态不是 4k 而是 32k 起步：在64k–128k 区间，基线只有 54.15 和 44.93 tok/s， 已经进入用户明显感到卡顿的区域；开启 DFlash 后是 99.93 和 81.39 tok/s ，重新回到流畅区间。投机解码在这里的意义，是把长上下文下的桌面推理从“不可用区”拉回“可用区”。

Gemma4-26B-A4B 的整体趋势与 Qwen3.6 一致：长上下文会拉低 decode throughput，但 DFlash 在所有测试长度上都保持正收益 。其加速比呈现先降后升的形态——从 4k 的 1.75× 逐步下探到 32k 的 1.44×，随后在 64k 、128k 回升到 1.60× 和1.80×.在最长的 128k 上下文下，基线已跌至 22.74 tok/s，而 DFlash 仍能维持 40.88 tok/s。

真实代码任务

为验证脱离构造 prompt 后加速是否依然有效，我们从实际工程中选取了三类 TypeScript 代码任务。三类任务均获得正向收益：代码 review 与测试生成分别提升 29.11 和 29.48 tok/s，结果非常接近；preset 逻辑重构的增量最大，提升 43.64 tok/s ，达到 111.38 tok/s 。三项任务的 DFlash 平均吞吐为 102.02 tok/s ，相比 67.94 tok/s 的平均基线提升 34.08 tok/s，平均相对提升约50%。

这说明加速不只对固定 、低随机性的构造输入有效，在需要阅读真实代码并生成结构化回答的任务中同样能带来可见的decode 加速。

上面是同一 prompt 下的实时侧边对比：让模型 review modelName.ts  中的两个函数、找出边界情况 、给出安全的重构方案并补上 Vitest 测试。固定输出 1400 token 、3 次运行取中位数，左侧基线 68.25 tok/s ，右侧启用 DFlash 后 105.78 tok/s，实测加速 1.55 倍。同样的十秒，右侧已经写到“Key Observations & Issues" ，左侧还停在代码摘录阶段。

为了说明为什么不同代码任务的收益不同，实验同时记录平均接受长度。接受率说明候选 token 中有多少比例被 target 接受，而平均接受长度能直接表示一次 target verification 实际推进了多少个 token。对 coding workload 来说，这个指标比单纯的 accept rate 更有解释力。

这组真实代码任务中，preset 逻辑重构的收益最高，从 67.74 tok/s 提升到 111.38 tok/s，约为 1.64 倍。最直接的解释来自接受率和平均接受长度：同样是 768 个输出 token，preset 逻辑重构在最佳配置 draft_n_max=3 下提交了 711 个 draft token，其中 530 个被 target 接受，接受率达到 74.54%，平均接受长度为 2.23；代码 review 和测试生成的接受率约为 52%，平均接受长度分别为 2.10 和 2.06。preset 任务的接受率更高，说明其输出中有更多结构稳定、局部可预测的段落，例如分支条件分析、配置项归纳、重构建议列表和 TypeScript 伪代码。投机解码在这类输出中更容易连续命中 target 的后续 token，因此一次 target verification 可以摊销更多 output token。

小结

从实验结果看， DFlash 在 HP ZGX Nano G1n AI Station 上具备明确的工程收益 。Qwen3.6-35B-A3B 在 4k 到 128k 上下文中保持 1.8 到 2.2 倍的 output throughput 提升；Gemma4-26B-A4B 的加速比在中段回落但在长上下文回升 ，全区间保持正向加速。真实代码任务的提升幅度更保守 ，稳定在 1.43 到 1.64 倍之间——但这个数字更贴近 coding 场景的真实负载，也因此更有参考价值。

六、从数据中心到桌面：同一套方案，换了一个更合适的战场

前面提到，投机解码对博云并不是新东西 。AIOS BMP 作为面向数据中心的推理引擎， 已经在多个项目中把投机解码用在了真实业务负载上——集群规模的 GPU 资源 、高并发请求、多模型多租户调度，推理加速在那里解决的是单位算力能服务多少请求。

这些项目积累下来的工程经验（target/draft 的配对管理、验证循环的实现、加速开关对上层的透明化），是我们敢把同一套方案直接搬到桌面终端的底气。

桌面不是数据中心的缩小版， 它的约束完全不同：单用户、单请求、显存有限 、延迟敏感 。所以这次搬迁并不是把服务端配置调小，而是针对桌面工况重新做了适配与加速调优。

有意思的是：这套方案换到桌面之后，收益不是被稀释了，而是被放大了。 原因在于两种场景的瓶颈结构完全不同。

• 数据中心追求的是吞吐。 服务端会把多个请求合并成大 batch，一次权重加载可以同时服务很多条序列 ，GPU 的计算单元本来就被并发请求填得比较满。此时系统离 memory-bound 更远，投机解码能“捡回来”的空闲算力有限，验证阶段还要和其他请求争抢计算资源， 收益空间被压缩。

• 桌面面对的是延迟。 桌面场景基本是单用户、单请求， batch 长期为 1。每生成一个 token 都要把整套权重从显存搬一遍，却只服务这一条序列——算力大量闲置，典型的 memory-bound。而投机解码的本质，正是用闲置的并行算力去换串行的等待时间：一次前向传播验证多个候选 token，把本来白白浪费的计算利用起来。

换句话说，桌面场景恰好提供了投机解码最需要的条件：算力有余、 带宽吃紧 、延迟敏感。这也解释了为什么我们在桌面设备上能稳定观察到 1.5 到 2 倍的 decode 加速——这不是移植带来的意外收获，而是这项技术本来就该在这种工况下发挥作用。再加上前面说过的输出无损特性，桌面用户拿到的是速度翻倍、精度不变。

七、落地产品： BoStudio + BoCoder

技术只有进入真实调用链 ，才能从实验室里的 tok/s 变成用户可感知的响应速度。我们把这套推理加速能力集成到BoStudio，并进一步接入 BoCoder 的编码工作流，形成从本地模型运行、推理加速到 Coding Agent 消费能力的完整链路。

在这套组合中，两个产品承担不同层次的职责：

• BoStudio 负责模型与推理运行时。 它管理本地 target model 与 draft checkpoint 的配对和加载 ，启动支持 block-diffusion speculative decoding 的推理服务，并向上层提供统一的模型调用入口 。推理加速被封装在服务端，调用方不需要理解 hidden states 、draft block 或验证循环等底层细节。

• BoCoder 负责工程上下文与Agent 工作流。 它覆盖从需求理解、任务拆解、多 Agent 编排，到代码、测试和预览交付的完整流程，并支持桌面端和命令行两种使用方式。接入 BoStudio 后， BoCoder 可以把代码阅读、方案分析、代码生成和测试生成等请求发送给本地模型服务。

这一集成的关键价值是对应用透明。用户在 BoStudio 中选定模型，系统自动完成 draft checkpoint 的配对与加载； BoCoder侧无需任何改动，开发者仍然以自然语言描述目标 ，Agent 的任务规划、工具调用和结果交付方式都不因投机解码而改变。整个加速对上层工作流是一个开关，而不是一组需要理解的推理参数。

当然也有取舍。draft checkpoint 会占用额外显存，在显存紧张 、又需要撑满超长上下文 KV cache 的场景下，需要在“更快的decode”和“更长的上下文”之间做权衡；另外 ，若输出任务的随机性很高 （如开放式创作），接受率下降会压缩收益空间。这两种情况下，关闭加速反而是更合适的选择。

八、对用户意味着什么

回到文章开头的那个场景 。tok/s 是工程指标，用户真正感知的是“我要等多久” 。把前面的实测吞吐换算成时间，这件事会直观得多。

以单轮输出 1400 token 为基准（与上文对比视频中的实测设置一致），三类真实代码任务的单轮 decode 耗时如下：

单看一轮，六到八秒的差距还只是“稍微快一点” 。但 Coding Agent 的一次工程任务要连续触发代码检索、文件分析、修改方案、补丁生成、测试修复和总结等十余轮模型调用——按平均值折算， 12 轮调用的 decode 总耗时从约 4 分 07 秒降到约 2 分 45秒，节省接近 1 分 25 秒。 decode 阶段每一轮省下的时间，会沿整条 Agent 链路一路叠加，这正是单轮 1.5 倍加速在多轮任务中被放大的地方。

上下文越长，这个差距越明显。同样是 1400 token 的一轮输出 ，Qwen3.6-35B-A3B 在 64k 上下文下从 25.9 秒降到 14.0秒；到 128k 时，基线需要 31.2 秒，而 DFlash 只需 17.2 秒——从“打断心流的等待”回到“还能接受的停顿”。

表中时间由实测 decode 吞吐按固定输出长度折算，仅覆盖 decode 阶段，不含 prefill、工具调用与外部 IO 等待；实际端到端耗时会高于此处数值，但两种配置之间的差值主要来自 decode，可作为体验差异的参考。

尤其在本地部署场景中，更高的单请求吞吐不仅意味着回答更快，也意味着同一台设备可以更从容地承载多步骤、长输出的编码任务。

从 AIOS BMP 在数据中心的多个项目中验证投机解码，到把这套方案搬上桌面、 由 BoStudio 承接本地模型与推理运行时、BoCoder 承接工程上下文与Agent 执行，我们把这项加速能力真正接进了桌面上的编码工作流。对用户而言，变化不是多出一组需要理解的推理参数，而是代码理解、生成、测试和多轮协作，能够更快地向前推进——让一台桌面级显卡设备，真正跑得动 AI Coding。

欢迎访问https://bocoder.com/bostudio 了解产品更多信息