作者丨吴海明
编辑丨马晓宁 李娜
15 分 35 秒对比 46.3 秒。在同一个 3D 世界杯虚拟乐园生成任务中，MiMo-V2.5-Pro-UltraSpeed 比标准版模型快了整整 20 倍。
测试中，MiMo-V2.5-Pro 与 UltraSpeed 同时接收指令，生成包含 3D 球场、48 支球队展馆及支持拖拽缩放点击功能的 3D 世界杯虚拟乐园。两者均交付了可运行页面，但等待时长截然不同。当万亿参数模型的推理时间从分钟级压缩至秒级，大模型产品形态将发生何种变革？
这引出了一个核心问题：同为万亿参数级模型，面对长代码生成任务，为何一个像“慢速外包”，另一个却更接近“实时搭档”？答案并非单纯的“模型更快”。
公开信息显示，MiMo-V2.5-Pro-UltraSpeed 基于 MiMo-V2.5-Pro-FP4-DFlash底层模型，拥有 1.02T 总参数、42B 激活参数，并支持 1M 上下文。官方数据显示，通过模型与系统协同设计，该模型在单个标准 8 卡通用 GPU 节点上，生成速度可突破 1000 tokens/s，峰值约 1200 tokens/s。
长期以来，大模型需在能力、上下文长度和推理速度之间做取舍：模型越大推理越慢，上下文越长延迟越高。UltraSpeed 旨在打破这一“不可能三角”。
01 从 3D 世界杯网站实测切入：同一道题，等待体验相差一个数量级
为验证 MiMo-V2.5-Pro-UltraSpeed 的速度提升效果，我们在 MiMo 官网分别调用 MiMo-V2.5-Pro 和 MiMo-V2.5-Pro-UltraSpeed，使用相同任务进行对比测试。
请生成一个 3D 世界杯虚拟乐园，包含 3D 球场、48 支球队的 3D 展馆，采用运动风格，需支持点击互动，输出为单文件 HTML。
该任务要求模型在单个 HTML 文件中完成 3D 场景构建、世界杯主题设计、48 支球队展馆布局、交互逻辑及视觉风格 等多重约束。这不仅考验长代码生成能力，更检验模型在复杂需求下的结构组织能力。此类任务是 Coding Agent 中典型的 Token 密集型场景：输出量大、结构严谨、格式复杂。若生成速度慢，用户等待感将被显著放大；且微小错误易引发 Bug，导致修改周期延长。
以下是两个模型的表现对比：
▎俯视图：基本命题完成度相当，呈现取向明显不同
左侧 MiMo-V2.5-Pro 生成的页面偏向“氛围型”：采用暗色星空背景，中央球场和环形展馆置于夜间宇宙舞台场景中，视觉重心集中于"2026 FIFA WORLD CUP"标识。页面顶部设搜索框和分组筛选，底部提供交互提示。整体沉浸感强，夜景、星点及发光元素构成了完整的 3D 展示空间；但部分展馆和文字标签较小，可读性偏弱，信息组织仅停留在概念演示阶段。
相比之下，MiMo-V2.5-Pro-UltraSpeed 生成的结果更偏“产品型”：同样包含中心球场、环形球队展馆、顶部标题栏及功能按钮，但画面更明亮，布局更规整。48 支球队展馆排列清晰，标签和筛选入口的可辨识度更高，用户能更快理解功能逻辑。值得注意的是，UltraSpeed 并未因追求速度而牺牲页面完整性，保留了所有关键模块和基础交互框架。
▎用户交互：基础操作完备，信息组织各有侧重
在 MiMo-V2.5-Pro 生成的网站中，用户拖拽后可切换至近景球场视角，空间关系稳定；点击阿根廷展馆后自动放大并弹出详细信息面板，涵盖 FIFA 排名、所属联盟、核心球员等内容，整体偏向沉浸式导览体验。
MiMo-V2.5-Pro-UltraSpeed 同样支持旋转、缩放和点击查看详情。视角切换后画面明亮，标签清晰。点击展馆后同样会拉进视野并展示核心信息。相比 Pro 版本，UltraSpeed 的交互氛围略弱，但信息组织更规整，可读性更佳。
综上，两个模型均一次性完成了长代码生成任务，交付了可交互的 3D 演示网站。差异主要体现在呈现取向：Pro 版本侧重沉浸感，UltraSpeed 强调结构与效率。鉴于二者同源，产出质量接近符合预期。真正的差距在于生成过程的速度。
▎UltraSpeed 以压倒性速度完成任务
在 Token 消耗和生成速度方面，UltraSpeed 的优势更为直观。
MiMo-V2.5-Pro 思考耗时 731.4 秒
MiMo-V2.5-Pro-UltraSpeed 思考耗时 33.1 秒，总耗时 46.3 秒，消耗 35827 tokens
MiMo-V2.5-Pro 总耗时约 15 分 35 秒，消耗 58563 tokens
MiMo-V2.5-Pro 消耗 58563 个 Tokens 生成网站，其中思考阶段耗时 731.4 秒，总耗时约 15 分 35 秒，生成 759 行代码。整个过程类似重型推理，模型花费大量时间规划后再逐步输出。
MiMo-V2.5-Pro-UltraSpeed 表现截然不同，仅消耗 35827 个 Tokens 便生成了 829 行代码。其思考阶段仅用 33.1 秒，平均速度达 581 tokens/s；生成阶段耗时 13.2 秒，平均输出速度达 980 tokens/s。这意味着在产出规模不低于 Pro 版本的前提下，UltraSpeed 以更少的 Token 开销和更短的等待时间完成了复杂前端任务。
对比表明，UltraSpeed 并非通过缩减内容换取速度，而是显著压缩了推理和生成链路。对用户而言，Pro 版本是“等一杯咖啡”，UltraSpeed 则是“眨几次眼，代码已成”。这种速度差距将彻底改变 Coding Agent 的开发体验。
▎速度定位明确：高速版名副其实
统计显示，UltraSpeed 在排除 Prompt 的 3156 Token 后，完成任务的 32671 Tokens总用时仅 46.3 秒，首响应低至 1.08 秒。其中，思考阶段耗时 33.1 秒（处理 19522 Tokens，均速 581 tokens/s）；正式输出阶段耗时 13.2 秒（生成 13149 Tokens，均速 980 tokens/s，峰值 1084 tokens/s）。关键在于，它未减少内容：最终代码超 800 行，完整保留了球场、展馆、交互等关键模块。对于长代码生成，这将等待时间从分钟级压缩至秒级。
▎功能优化测试：从风格偏离到精准 Debug
结合实际开发需求，我们进一步测试了 UltraSpeed 的 Debug 能力。
首先，要求模型在上述 3D 世界杯虚拟乐园中添加“世界杯历史馆”和“美加墨 2026 世界杯对战馆”。
请在主场馆旁边分别添加“世界杯历史馆”和“美加墨 2026 世界杯对战馆”，在世界杯历史馆中梳理完整的世界杯历史记录，在对战馆中展示赛程表等。
UltraSpeed 经 33.6 秒完成修改，新增了场馆，但风格发生较大变化。
UltraSpeed 新增了“世界杯历史馆”和"2026 对战馆”，并同步更新了导航按钮。历史馆设计为博物馆式建筑，对战馆采用未来感结构，补充了历史梳理和赛程等内容。该轮任务总计 34765 Tokens，输出 26142 Tokens，总用时约 33.6 秒，平均输出速度达 1029 tokens/s。虽然功能目标达成且吞吐量高，但整体视觉风格和交互语言未能延续第一版，更像重新组织的新页面。
随后进行第二轮 Debug，将第一版源码提供给模型，明确要求“在保留代码风格的前提下”增加新馆：
[源码]
请在保留这个代码风格的前提下，增加世界杯历史馆和 2026 赛程中心馆。
UltraSpeed 第二次 Debug，51.6 秒交付风格一致的新版本。
此次，UltraSpeed 未在原有视觉体系外重构，而是在保留中央球场、环形展馆、分组筛选及明亮运动风格的基础上，融入了新馆。新增历史馆采用金色穹顶和奖杯造型，赛程中心以蓝绿色几何建筑呈现，与原主题高度一致。
内容层面，模型补充了 22 届世界杯历史统计、传奇纪录、完整赛事表格及详细的赛程信息。此轮任务上下文和输出规模更大，总 Tokens 达 105568（输入含源码 60491 个），输出 45077 Tokens，但总用时仅 51.6 秒，平均输出速度达 1134 tokens/s。这次修改不仅增加了功能，更符合真实开发中“理解既有代码和风格基础上进行局部扩展”的要求。
这是 UltraSpeed 在 Coding Agent 场景中的核心价值：即便不能一次完美命中，但每一轮反馈、修改和再生成都能在几十秒内完成，使开发者能进入自然的连续协作节奏。
换言之，UltraSpeed 的意义不仅是“一次生成快”，更是让 生成—发现问题—补充约束—再次修改 的循环变得足够轻量。
02 为什么 UltraSpeed 能这么快？
理解速度差距需回归 UltraSpeed 的底层设计。其基于 MiMo-V2.5-Pro-FP4-DFlash模型，在保持 1.02T 总参数、42B 激活参数、1M 上下文的基础上，通过 FP4 混合量化、DFlash 块级投机解码和 TileRT 系统级优化，重构了万亿参数模型的推理链路。
简而言之：
FP4 让每一步读得少，DFlash 让总步数跑得少，TileRT 让 GPU 闲得少。
▎FP4：选择性压缩 Experts
在万亿参数模型中，显存带宽是核心瓶颈。MiMo 采取选择性量化策略：1) 仅对 MoE 的 Experts 进行 MXFP4（Microscaling FP4）量化；2) 注意力投影及其他关键模块保持高精度；3) 通过 FP4 QAT 在训练阶段适配低精度表示。
该策略直击要害：MoE 模型参数主要集中在 Experts，而每次推理仅激活部分。压缩 Experts 可显著降低显存和带宽压力；保留注意力等敏感模块则避免能力坍塌。
Hugging Face 模型卡显示，MXFP4 相比 FP8 在多项基准测试中未出现明显能力下降：
在通用 Agent 场景中，UltraSpeed 在 Claw-Eval (pass^3) 上得分 67.8（高于原版 63.8）；在 Humanity's Last Exam 上为 47.0（与原版 48.0 持平）。在 Coding Agent 场景，SWE-Bench Pro 得分为 58.8（略高于原版 57.2）；SWE-bench Verified 为 77.4（略低于原版 78.9，差距微小）。
这表明 MXFP4 路线是在 MoE 架构上做“定点减重”：压缩参数量最大的 Experts，保留关键路径高精度，在降低资源压力的同时将能力损失控制在极小范围，为后续优化奠定基础。
▎DFlash：块级并行投机解码
MXFP4 解决“每一步太重”，DFlash 解决“步数太多”。
传统自回归生成需逐 Token 推理。DFlash 采用块级并行投机解码：一个 5 层轻量 Draft 模型一次预测一个 Token Block，再由主干模型统一验证。
具体而言，DFlash 的块大小设为 8。Draft 模型不再逐 Token 生成，而是一次前向计算填充整个被掩蔽的 Token 块；随后主干模型一次性验证多个 Token，通过的保留，未通过的重新生成。
官方数据显示，在 WebDev (Coding) 测试中，每轮 8 个 Draft Token 平均有 6.30 个被接受。这意味着主干模型无需逐个生成 Token，前向计算次数大幅压缩。
此外，速度与任务类型相关，Coding 场景表现明显优于开放对话，说明 UltraSpeed 在代码生成、结构化输出及 Agent 任务中优势更易发挥。
▎TileRT：系统级优化释放 GPU 潜能
仅有 FP4 和 DFlash 不足以保证速度。1T MoE 模型部署在 8 卡 GPU 节点上，还面临 Kernel 启动、跨卡通信、数据搬运等系统瓶颈。
TileRT 解决了这“最后一公里”问题。其优化集中在系统执行层面：通过常驻内核减少反复启动开销；通过计算与数据搬运重叠压缩 GPU 等待时间。同时，针对 MXFP4 计算、DFlash 草稿生成等不同阶段设计异构流水线，配套定制编译引擎与计算核。
因此，UltraSpeed 的 1000 tokens/s 是一个系统工程指标，而非单纯的模型指标。
03 速度不是免费的：UltraSpeed 更适合时间敏感任务
速度伴随成本。UltraSpeed 的单价为 Pro 版本的 3 倍，是一种“时间优先”的选择。
小米官方模型价格
这意味着它并非所有场景的默认选项，不适合普通闲聊或对延迟不敏感的任务。但在 Coding Agent、长代码生成、多轮 Debug 等场景中，成本判断不能只看“每 Token 价格”，更要看“每轮迭代成本”。
若每轮等待十几分钟，Agent 难以融入真实工作流；若每轮几十秒完成，用户操作节奏将完全不同。模型从“我问你答”转变为“我指挥，你执行；我调整，你立刻改”。
衡量 UltraSpeed 的关键不在于“贵不贵”，而在于：当速度提升一个数量级时，节省的时间和迭代效率是否足以覆盖更高的 Token 单价。对于高频开发和实时协作场景，这笔账显然是成立的。
04 大模型从能回答走向能实时执行
过去一年，大模型竞争聚焦于准确性、推理能力和代码生成。但 MiMo-V2.5-Pro-UltraSpeed 标志着一个新分水岭：模型不仅要会做任务，还要能在极短时间内完成。
这不仅是速度指标，更是产品形态变革的前兆。
在传统聊天场景中，用户可接受数十秒甚至几分钟的思考时间。但在 Agent、代码生成、数据分析等场景，模型不再是答案生成器，而是执行单元。它需理解目标、拆解步骤、调用工具、修复错误，并在连续反馈中快速迭代。
用户不再需要“慢速外包”。过去生成复杂代码需长时间等待，再经历复制、运行、报错、修改的低效流程。而当首响应压至 1 秒左右、完整生成控制在 1 分钟内，模型便成为实时协作的开发搭档。
MiMo-V2.5-Pro 证明了模型可以完成复杂任务，UltraSpeed 则证明了复杂任务可以被快速完成。
MiMo 率先将万亿参数模型生成速度推至 1000 tokens/s 量级，这应成为行业基准线。只有更多模型在保持能力的同时降低推理成本、压缩响应时间，大模型才能真正从问答工具演变为实时执行的基础设施。届时，开发者思路不被等待打断，Agent 连续性不因延迟丧失，用户无需在能力与时间间权衡。这一天越早到来，生态受益越早。
附录：两个模型生成的网站源码链接:
https://pan.baidu.com/s/1E94bTRj_4zmxONCxxW2dUQ?pwd=wc7q
