编程模型测速不能只看每秒输出量

dev.to · AI#编程模型#性能评测#模型选型

Editor brief · 编辑速览

文章分析开放权重模型 Naive-N0.5-Flash 的编程基准及最高 2100 token/s 宣传，区分能力分数、生成吞吐量与端到端耗时。速度实验使用推理题且各模型统计口径不同，不能直接推导真实开发效率或精确速度倍数。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

2100 token/s 很吸引人，但程序员更关心的是：同样一项任务，能不能更早拿到可用结果？NaiveAI 的开放权重编程模型 Naive-N0.5-Flash 展现了较高的生成吞吐量，部分编程基准也有竞争力，可现有数据还不能证明它能更快交付同等质量的代码。

这份技术笔记最有用的地方，是把编程能力、生成速度和实际等待时间拆开看。尤其是少数请求产生的超长推理，足以让「每秒输出很快」和「任务完成很快」走向不同的结论。

Naive-N0.5-Flash 基于小米 MiMo-V2.5 继续训练，并搭配 NaiveAI 自研的 NaiveRT 推理引擎。

底座 MiMo-V2.5 采用稀疏混合专家架构，总参数量为 3100 亿，激活参数量为 150 亿，预训练规模为 48 万亿 token。可以把它理解为：模型包含大量参数，但处理输入时只动用其中一部分。

NaiveAI 又进行了多阶段训练，将模型适配到 DeepSeek Sparse Attention 层，新增训练量约为 3.25 万亿 token。其中约 3 万亿 token 的训练，采用固定的 100 万 token 上下文长度和恒定学习率。这交代了训练投入，不能单凭它判断真实开发效果。

已披露的编程基准中，对比对象是 DeepSeek V4.1 Flash 1017 和 GLM-5.3-Flash。Naive-N0.5-Flash 在 NL2Repo-Bench 上最高，在 DeepSWE v1.1 和 Agent’s Last Exam 中则位于两者之间。

因此，比较稳妥的结论是它在部分编程任务中具有竞争力。原文没有列出具体分数，这些成绩也不是后面的速度实验重新测得的，不能把两组结果拼成「编程更强且交付更快」的完整证据。

速度实验使用 Naive-N0.5-Flash 的 ultrafast 模式，每个模型配置测试 30 道纯文本题：

所有实验的最大补全长度均为 256K token，记录生成吞吐量、补全 token 数和端到端响应时间。端到端耗时就是从发起请求到拿到完整响应的等待时间，比单看输出速率更贴近使用感受。

Naive-N0.5-Flash 在两种思考配置下，报告的吞吐量都接近或超过 1000 token/s。不过，NaiveAI 使用服务端测量，另外两个模型使用 OpenRouter 统计。测量口径不同，不能据此算出精确的速度倍数，也不能把这些结果当作最高 2100 token/s 的验证。

更关键的是，测的是数学、知识和推理题，并非真实软件项目。实验没有评判答案正确率，也就无法比较达到相同答案质量需要多久。

问题出在输出长度的分布上。

全部 30 道题中，Naive-N0.5-Flash 的补全长度中位数约为 3200 token，平均值却超过 5.1 万 token。少数请求生成了特别长的推理内容，拉高了平均值，也解释了响应时间中位数只有 3.1 秒、平均值却达到 45.3 秒的现象。

开启思考后，它在高难度题组中平均生成约 10.85 万个补全 token，约为 GLM 对应配置的 9 倍、DeepSeek 对应配置的 11 倍。

每秒生成更多 token，并不保证完成一次任务用时更短。

它的响应时间中位数明显更低，但平均耗时与 DeepSeek 接近。在高难度题组中，Naive-N0.5-Flash 平均耗时为 89.8 秒，反而高于 DeepSeek 的 79.7 秒。多数请求较快，与部分复杂请求等待较久，可以同时成立。

这份笔记对指标的拆分是合理的。吞吐量描述生成速率，端到端耗时描述等待，结果质量决定这些等待有没有价值。做编程工具选型，三者需要一起看。

但现有证据仍偏初步：每个难度只有 10 道题，速度实验没有正确率，应用构建测试也只说明使用了相同提示词，没有给出完整结果。尤其缺少真实开发任务下、同等质量要求下的耗时对照。

相较于只看峰值速度，记录自己任务上的输出长度、耗时和质量，更有选型价值。不过，这是一种评估建议，原文没有提供对照数据证明它能带来多少收益。当前材料支持进一步试用，尚不足以支持直接替换现有编程模型。