每秒 2,122 个 token，离任务真正完成还有多远

9 月 27 日，NaiveAI 发布 Naive-N0.5-Flash 技术文章。面向强化学习采样轨迹优化单路解码的 NaiveRT，结合融合式 DFlash 草稿模型进行推测解码，报出每秒 2,122 个 token。条件同样重要：八张 GPU、41 个 HTML/SVG 请求中表现最好的一个一秒窗口、关闭思考，并且不计输入预填充时间。这是开发方自己的测量结果，SlateMoth 尚未独立复现。 [1]

值得追问的是，这个数字覆盖了用户等待的哪一段。解码峰值描述一次请求的部分过程，不能直接回答代码修改、报告撰写或 Agent 任务多久完成。评估模型时把这几件事分开，才能公平理解一项有潜力的工程成果。

我们建议设置三只时钟。第一只从提交请求计到收到首段可用输出，包含调用者实际经历的等待与输入处理；第二只测量首段输出到完整回答结束的剩余生成时间；第三只覆盖从提交任务到通过验收的全过程，包括工具调用、测试及必要的重试。改善其中一段，并不意味着总耗时会按同等幅度缩短。

举个假设的代码修改任务：读取项目并等到首段输出花了 12 秒，生成花了 8 秒，测试花了 40 秒。即使生成加快四倍，总耗时也只是从 60 秒降到 54 秒，节省 10%。这些是示意数字，不是 NaiveAI 的实测结果。先知道时间花在哪里，才能判断一个速度提升对完整流程的意义。

短暂的峰值也没有回答：长回答期间是否一直这么快，多个用户同时请求时又会怎样。应索取预期负载下的完整响应耗时和延迟分布。单次请求速度与服务总吞吐量也要分开看：每秒服务更多请求，与让一个人的任务更早完成，解决的是不同问题。

模型卡列出总参数量 3090 亿、激活参数量 155 亿。其 FP8 部署说明写明，权重约占 315 GB，推理还需额外 GPU 内存；稀疏注意力设计仍保留完整 KV 缓存。这些信息提醒我们：不能把激活参数量理解成整套模型只需同等规模稠密模型的内存。 [2]

做部署判断，应记录实际权重与精度、硬件与互连、运行时版本、上下文长度和并发请求，再测该配置的内存占用与失败情况。减少每一步参与计算的参数有价值，但不等于每一种部署都会变小。量化、卸载或更换推理引擎，应视为需要重新评估的配置，不能直接沿用原来的峰值。

还有一条需要讲清的发布边界：技术文章称 NaiveRT 已开源，同时写明相关源码内容将在 10 月 12 日前提供。9 月 28 日核查时，文章所链 NaiveRT 仓库返回 404，因此我们未能在该地址审阅运行时和基准脚本。这既不证明结果虚假，也不意味着模型权重没有开放；它限定的是当前可核验的范围。 [1] [3]

在材料可访问、实验可重复以前，应把该速度当作附有条件的开发方自报结果。关闭思考进行的速度测试，也不能直接证明需要长时间推理的任务会有同样表现。质量和耗时应放在实际使用的模式下一起测。

从一小组有代表性的任务开始，在运行前定义成功条件。代码修改可以要求目标行为正确、回归检查通过且没有改动无关文件；文档工作可以要求关键事实齐全、引用确实支持结论。记录整次尝试，把失败和返工也算进去，不只留下最好看的一次结果。

比较时固定任务集、工具权限与验收规则，再更换模型或服务配置。记录首段输出时间、总耗时、任务验收通过率，以及每个通过验收任务的成本。纳入长短输入、正常并发和重复运行。一个很快的样本足以让人继续研究，却不足以代表所有用户的体验。

解码加速最有价值的场景，是生成本身确实占据主要等待时间。较长、主要串行的生成工作，只要质量保持，可能明显受益；如果流程主要耗在检索、慢工具或人工审阅上，收益就可能小得多。这并不削弱工程成果，而是帮助团队决定先在哪里测试。

NaiveAI 的报告提出了一个值得验证的具体假设：不同的推理实现，可能缩短生成密集型工作的耗时。我们阅读了它公开的方法说明，没有运行模型或复现峰值。接下来应关注可审阅的运行时代码、可重复的配置，以及代表性任务上的结果。真正能支撑采用决策的，是系统在自己的工作负载上，多快交付一个合格结果。