NaiveAI 宣称每秒 2100 token：编程能力与实际速度如何？

2100 token/s，意味着编程任务完成得更快吗？

NaiveAI 推出的 Naive-N0.5-Flash 是一款面向编程任务的开放权重模型，宣称最高生成速度可达 2100 token/s。不过，峰值吞吐量不等于实际任务中的稳定速度，也不等于更短的交付时间。

这篇写好标智库技术笔记将编程基准、生成吞吐量和端到端耗时分开讨论，重点看这些指标能说明什么，以及还不能说明什么。

模型背景：基于 MiMo-V2.5 继续训练

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 道纯文本题：

• 较低难度组：从 MATH-500 随机抽取 10 道题。
• 中等难度组：从 GPQA-Diamond 随机抽取 10 道题。
• 高难度组：从 HLE-Diamond 随机抽取 10 道题。

所有实验的最大补全长度均为 256K token，记录生成吞吐量、补全 token 数和端到端响应时间。

需要区分的是：这里测试的是数学、知识与推理题的生成速度，不能直接将结果视为真实软件项目的开发效率。

吞吐量统计口径并不一致

Naive-N0.5-Flash 在两种思考配置下报告的吞吐量均接近或超过 1000 token/s。

但 NaiveAI 的数据采用服务端测量，另外两个模型的数据采用 OpenRouter 统计。由于测量口径不同，不能据此计算精确的速度倍数，也不能把这些结果直接等同于宣传中的最高 2100 token/s。

端到端耗时：中位数更短，平均值未全面领先

端到端响应时间更接近用户实际等待的时间：

Naive-N0.5-Flash 的响应时间中位数明显更低，但平均耗时与 DeepSeek 接近。

在高难度题组中，Naive-N0.5-Flash 的平均耗时为 89.8 秒，高于 DeepSeek 的 79.7 秒。因此，不能把较低的整体中位数理解为每一道题都完成得更快。

为什么中位数只有 3.1 秒，平均却要 45.3 秒？

关键在于部分请求产生了超长推理。

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

在全部 30 道题中，它的补全长度中位数约为 3200 token，平均值却超过 5.1 万 token。这说明少数请求产生了异常长的推理过程，显著拉高了平均值。

这也是模型速度评估中容易忽略的一点：

高吞吐量与短等待时间不是同一回事。即使每秒生成的 token 更多，只要总生成量大幅增加，单个任务仍可能耗时较长。

对编程选型有哪些参考价值？

现有结果显示，Naive-N0.5-Flash 的速度表现值得关注，编程基准也有一定竞争力。但在据此做技术选型之前，仍需注意三项限制：

1. 样本量小：每个难度只有 10 道题，不足以代表广泛任务表现。
2. 未评判答案正确率：速度实验不能证明模型回答得更准确，也无法比较达到同等答案质量所需的时间。
3. 应用开发测试信息不完整：现有材料只说明进行了相同提示词的应用构建测试，没有给出完整结果，无法据此判断实际交付质量。

对于开发者，更稳妥的做法是在自己的任务集上分别记录吞吐量、端到端耗时、输出长度与结果质量，尤其关注复杂任务是否出现超长推理。

目前的数据足以支持进一步试用，但不足以证明 Naive-N0.5-Flash 能在真实项目中，以更短时间完成同等质量的工作。