本地大模型又跑出一个很容易上头的数字。
5 月 8 日，Reddit r/LocalLLaMA 上一位用户发布测试：在单张 RTX 5090 上运行 Gemma 4 26B A4B ，配合 DFlash speculative decoding，输出速度从约 228 tok/s 提升到约 578 tok/s 。
接近 600 tok/s ，而且是一张消费级显卡。
如果只看这个数字，很容易得出一个激动人心的结论：本地 Agent 终于要起飞了。
但这条消息真正值得关注的，不是“本地模型又快了”，而是它把另一个问题推到了台前：当速度不再是最明显的短板，本地 Agent 的瓶颈会迅速转向 长上下文、工具调用稳定性和尾延迟 。
换句话说，本地 Agent 的竞争重点，正在从“能不能跑得快”，变成“长任务里能不能稳得住”。
578 tok/s，先别只看标题
这次测试的配置比较清楚：
- GPU： RTX 5090，32GB VRAM
- 推理框架： vLLM 0.19.2rc1
- 主模型： cyankiwi/gemma-4-26B-A4B-it-AWQ-4bit
- Draft 模型： z-lab/gemma-4-26B-A4B-it-DFlash
- 测试负载： 256 input tokens / 1024 output tokens
- 并发： 1
- 请求速率： 1
- speculative tokens 测试范围： 0 到 15
图表：DFlash 前后速度对比
在不开 DFlash 的情况下，基线成绩约为 228 output tok/s ，平均端到端延迟约 4455 ms 。
开启 DFlash 后，作者给出的最佳实用配置是：
- num_speculative_tokens=13
- max_num_batched_tokens=8192
- 578 output tok/s
- 平均端到端延迟约 1738 ms
- 约 2.56 倍 加速
这个结果确实漂亮。
对本地模型来说， 228 tok/s 已经是很强的交互速度；再推到 578 tok/s ，体感上会从“响应很快”变成“几乎在追着你输出”。
但这里有一个前提：这是一组短上下文、单并发、固定输出长度的 benchmark。它适合观察速度上限，却不能直接等同于真实 Agent 工作流。
DFlash 做的事：让小模型先猜，大模型再批改
DFlash 属于 speculative decoding。
它的基本思路并不复杂：不要让大模型每次只生成一个 token，而是让一个更轻的 draft model 先预测一段候选 token，再交给目标模型一次性验证。候选猜得越准，大模型需要“亲自生成”的步骤就越少，速度也就越快。
流程图：DFlash speculative decoding 工作流
DFlash 的特殊之处在于，它不是按自回归方式一个 token 一个 token 地草拟，而是用 block diffusion 方式一次预测一整块 token。
根据 vLLM Speculators 文档和 Z Lab 项目页的介绍，DFlash 会利用目标模型的 hidden states，让 draft model 在一个并行前向过程中生成候选块，然后由目标模型验证。
Z Lab 给出的官方表述是：DFlash 试图突破传统 speculative decoding 中 draft model 仍然串行生成的限制；在 Qwen3-8B 上，官方称最高可达到 6 倍 lossless acceleration ，并比 EAGLE-3 快约 2.5 倍 。
放到这次 Gemma 4 + RTX 5090 的测试中，Reddit 作者观察到的是约 2.56 倍 的实际提升。
这不是魔法，更像是本地推理进入下一阶段的信号：模型量化、显存带宽、推理框架之外，推理算法本身也开始成为关键变量。
为什么 Gemma 4 26B A4B 适合这类测试
这次结果能跑出来，Gemma 4 26B A4B 本身也很关键。
它不是一个普通 dense 26B 模型，而是 MoE 路线：总参数规模约 26B ，但每个 token 激活约 4B 参数。
这让它特别适合单卡本地推理。
对生成阶段来说，系统面对的不是完整 dense 26B 的持续计算压力，而更接近一个激活规模较小的模型。再叠加 AWQ 4-bit 量化和 RTX 5090 的 32GB VRAM ，本地部署的可行性就明显提高了。
此前 datapnt 在 4 月 17 日发布的部署笔记中，也记录过类似方向：用 RTX 5090 跑 Gemma 4 26B A4B，作为私有、支持工具调用的 vLLM endpoint，并配置到 96k context 。那篇文章给出的 decode 速度约 196 tok/s ，与这次 Reddit 测试不开 DFlash 时的 228 tok/s 处在同一量级。
所以， 578 tok/s 不是凭空出现的奇迹，而是在一个已经比较成熟的组合上继续加速：MoE 架构、4-bit 量化、RTX 5090、vLLM，再加 DFlash。
真正的问题是：这个组合在真实 Agent 场景里，还能保持多少收益。
冷水来自评论区：长上下文不是短跑赛道
这次讨论最有价值的部分，反而出现在评论区。
有高赞评论提醒：DFlash 的吞吐表现很好，但在高上下文长度下会明显掉速。这里的“高上下文”，大约指 20k context 以上。
另一位用户给了更具体的真实场景反馈：他在约 35k context 、需要输出长 tool call 的提示中测试，开头速度能到 400 tok/s ，但很快掉到 200 tok/s ，后面还出现工具调用格式异常和循环输出。相比之下，不开 DFlash 的基线约 140 tok/s decode ，虽然慢一些，但任务完成更稳定。
示意图：速度瓶颈转向长上下文
这正是本地 Agent 和普通聊天机器人的分水岭。
普通聊天可以在几百到几千 token 的上下文里完成；Agent 真正工作时，往往要读代码、读文档、保留历史步骤、调用工具、接收工具返回，再继续规划下一步。
上下文长度很快就会进入 20k、35k、甚至 50k+ 。
这时，短 prompt benchmark 里的 tok/s 数字仍然有参考价值，但已经不是唯一指标。长上下文下的速度曲线、缓存策略、尾延迟、结构化输出稳定性，都会直接影响 Agent 是否可用。
对 Agent 来说，快而不稳，甚至可能比慢一点更麻烦。因为一次 malformed tool call、一次循环输出、一次错误 patch，都可能让整条工作流中断。
本地 Agent 的指标体系正在变化
过去讨论本地模型，大家最关心的是三个问题：
能不能装进显存？
每秒能吐几个 token？
成本比云端低多少？
这些问题仍然重要，但已经不够了。
如果本地 Agent 真要承担长任务，新的指标会变成：
- 20k+ context 后吞吐是否还能稳定
- p95 / p99 尾延迟是否可控
- 工具调用格式是否可靠
- prefix caching 是否能复用固定上下文
- 长流程中是否容易循环、跑偏或输出损坏
其中 prefix caching 会越来越重要。
很多 Agent 场景里，系统提示、工具说明、项目文件摘要、代码库上下文并不是每一轮都完全变化。如果这些前缀上下文能被有效缓存，长上下文成本才可能被压下来。
否则，再高的短上下文 tok/s，也很难覆盖真实工作流里的上下文膨胀。
这也是为什么“578 tok/s”应该被理解为一个很强的速度信号，而不是完整的本地 Agent 胜利宣言。
这条消息的真实含义
Gemma 4 + RTX 5090 跑到 578 tok/s ，说明单张消费级 GPU 的本地推理能力已经非常接近“可交互、可服务、可接入工具链”的阶段。
这对本地 Agent 是利好。
它意味着个人开发者、小团队、私有部署场景，可以更认真地考虑本地模型作为 Agent backend，而不是只把它当作离线玩具。
但它也提醒我们：本地 Agent 真正要过的关，不是短 prompt 里跑出多高的 tok/s，而是在长上下文、多工具、多轮任务里保持稳定。
短上下文速度解决的是“等得烦不烦”。
长上下文稳定性解决的是“能不能把活干完”。
这两件事不是一个层级的问题。
所以，这次 578 tok/s 最适合被看作一个转折点：本地模型的速度焦虑正在缓解，长上下文焦虑开始变成主角。
接下来真正值得看的，不是谁在短测试里刷新了 tok/s，而是谁能在 20k+、50k+、工具调用、多文件工作流 里，把速度、稳定性、成本和可控性一起做平衡。
如果这个问题被解决，本地 Agent 才会从“能跑起来的个人玩具”，变成真正能长期放在桌面上工作的基础设施。
到那时， 578 tok/s 可能只是序章。
真正重要的比赛，会从“谁说得快”，转向“谁记得久、干得稳、出错少”。
原文与参考链接
- Reddit 原帖：Gemma 4 26B Hits 600 Tok/s on One RTX 5090
- vLLM DFlash 文档
- Z Lab DFlash 项目页
- datapnt：Deploying Gemma 4 26B A4B on an RTX 5090
