辨析 MiMo-V2.5-Pro-UltraSpeed 的速度突破及其对 AI 开发范式的影响
在万亿参数大模型的激烈竞争中，业界曾长期信奉一个“不可能三角”：模型越大，推理越慢；上下文越长，延迟越高；Agent 步骤越多，用户等待越久。然而，MiMo 团队近期推出的 MiMo-V2.5-Pro-UltraSpeed 似乎正在试图打破这一铁律。
通过一组公开的 3D 世界杯虚拟乐园生成任务实测，该模型展示了将万亿参数模型的推理时间从分钟级压缩到秒级的可能性。这不仅是一次性能指标的刷新，更可能重塑 Coding Agent 和实时协作场景下的开发范式。
一、核心事件：同一任务，速度相差 20 倍
为了验证 UltraSpeed 的速度提升，测试人员在 MiMo 官网使用同一提示词（Prompt），分别调用了标准版 MiMo-V2.5-Pro 和高速版 MiMo-V2.5-Pro-UltraSpeed，要求生成一个包含 3D 球场、48 支球队展馆、支持拖拽缩放点击的单文件 HTML 网站。
测试结果显示，两者虽然都交付了可运行的页面，但在等待时长和 Token 开支上存在显著差异：
| 指标 | MiMo-V2.5-Pro (标准版) | MiMo-V2.5-Pro-UltraSpeed (高速版) |
|---|---|---|
| 总耗时 | 15 分 35 秒 (935 秒) | 46.3 秒 |
| 思考阶段耗时 | 731.4 秒 | 33.1 秒 |
| 生成代码行数 | 759 行 | 829 行 |
| Token 总开支 | 58,563 tokens | 35,827 tokens |
| 平均输出速度 | - | 约 980 tokens/s (峰值 1084 tokens/s) |
可以看到，UltraSpeed 不仅将完成时间压缩了整整 20 倍，且在产出规模更大（代码行数更多）的情况下，Token 消耗反而更少。这种速度差距对于需要反复生成、运行、修改的 Coding Agent 场景而言，直接改变了开发体验：从“等一杯咖啡”变成了“眨几次眼，代码已经铺开”。
二、技术解析：如何打破“不可能三角”？
公开信息显示，UltraSpeed 的底层模型是 MiMo-V2.5-Pro-FP4-DFlash。它并非简单地将模型缩小，而是在保持 1.02T 总参数、42B 激活参数、1M 上下文 的基础上，通过三项核心技术重构了推理链路：
1. FP4 混合量化：定点减重
在万亿参数 MoE（混合专家）模型中，显存带宽往往是推理速度的核心瓶颈。MiMo 没有选择粗暴地将全模型量化，而是采取了更精细的选择性策略：
- 只压缩 Experts： 仅对 MoE 的 Experts 做 MXFP4（Microscaling FP4）量化，因为这是参数量最大的部分。
- 保留关键精度： 注意力投影（如
o_proj）和其他敏感模块保持更高精度，避免能力坍塌。 - 训练适配： 通过 FP4 QAT（量化感知训练），在训练阶段就适配低精度表示。
官方数据显示，这种策略并未带来明显的性能断崖。例如在 SWE-Bench Pro 测试中，UltraSpeed 得分 58.8，略高于原版的 57.2；在 Claw-Eval 上达到 67.8，也高于原版的 63.8。
2. DFlash 块级投机解码：从“逐字猜”到“按块猜”
传统自回归生成需要逐 token 推理，输出 1000 个 token 理论上要走约 1000 步。DFlash 采用了一种块级并行的投机解码机制：
- 机制： 一个 5 层轻量 draft 模型一次预测一个 token block（块大小设为 8），再由 MiMo 主干模型统一验证。
- 效率： 在 WebDev (Coding) 测试中，每轮 8 个 draft token 中平均有 6.30 个被接受。这意味着主干模型不必每个 token 都亲自生成，前向计算次数被大幅压缩。
- 场景优势： 数据显示，Coding 场景的加速效果明显高于开放对话场景，说明其在代码生成和结构化输出中更具优势。
3. TileRT 系统级优化：打通最后一公里
有了 FP4 和 DFlash，还需要高效的系统执行才能发挥性能。TileRT 解决了 1T MoE 模型部署中的系统瓶颈：
- 常驻内核： 减少计算内核反复启动带来的开销。
- 计算与数据重叠： 压缩 GPU 等待数据的时间。
- 异构流水线： 针对 MXFP4 Expert 计算、DFlash 草稿生成、主干模型验证等不同阶段设计定制编译引擎与计算核。
因此，UltraSpeed 在单个标准 8 卡通用 GPU 节点上推过的 1000 tokens/s 速度，是一个系统工程指标，而非单纯的模型指标。
三、开发范式转变：从“答案生成”到“实时执行”
UltraSpeed 的意义不仅仅在于“一次生成快”，更在于它让 生成—发现问题—补充约束—再次修改 的循环变得足够轻。
在后续的 Debug 测试中，当要求模型在原有 3D 世界杯乐园中添加“世界杯历史馆”和“美加墨2026对战馆”时：
- 第一轮修改： 耗时 33.6 秒，平均输出速度 1029 tokens/s，但风格与原网页不一致。
- 第二轮修正： 提供源码并明确要求保留风格后，耗时 51.6 秒，平均输出速度达到 1134 tokens/s，成功在原视觉体系中扩展了新功能。
这种几十秒内完成一轮迭代的速度，使得开发者可以自然地进入连续协作节奏。模型从“我问你答”的工具，转变为“我指挥，你执行；我调整，你立刻改”的实时搭档。
四、成本与适用场景辨析
当然，速度并非免费。UltraSpeed 的单价为 Pro 版本的 3 倍。这意味着它不是所有场景的默认选择，也不适合普通闲聊或对延迟不敏感的任务。
但对于高频开发、实时协作和对响应速度敏感的 Agent 场景，成本判断不能只看“每 token 价格”，还要看“每轮迭代成本”。如果每一轮都要等十几分钟，Agent 很难进入真实工作流；而如果每一轮都能在几十秒内完成，节省下来的时间和迭代效率足以覆盖更高的 token 单价。
结语
MiMo-V2.5-Pro-UltraSpeed 率先将万亿参数模型的生成速度推到了 1000 tokens/s 量级。这不仅是技术上的突破，更是大模型产品形态变化的前兆。
当模型不再只是“能回答”，而是能够“实时执行”时，开发者不会因为等待而打断思路，Agent 不会因为延迟而失去连续性。只有更多模型在保持能力的同时把推理成本降下来、把响应时间压下去，大模型才能真正从回答问题的工具，变成实时执行的基础设施。
注：本文事实依据来源于 MiMo 官方公开信息及实测数据，源码链接参考：https://pan.baidu.com/s/1E94bTRj_4zmxONCxxW2dUQ?pwd=wc7q