我们用小米大模型做了个 3D 世界杯网站，没想到 46 秒就搞定了

“MiMo-V2.5-Pro-UltraSpeed 的推理速度世界第一。”

作者丨吴海明

编辑丨马晓宁 李娜

15分35秒 vs 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。

过去，大模型通常需要在能力、上下文和速度之间做取舍：模型越大，推理越慢；上下文越长，延迟越高；Agent 步骤越多，用户等待越久。UltraSpeed 要挑战的，正是这个长期存在的不可能三角关系。

01

从 3D 世界杯网站实测切入：

同一道题，等待体验相差一个数量级

为了验证 MiMo-V2.5-Pro-UltraSpeed 的速度提升到底有多明显，我们在 MiMo 官网分别调用了MiMo-V2.5-Pro和MiMo-V2.5-Pro-UltraSpeed，用同一个任务做了对比测试。

请生成一个 3D 世界杯虚拟乐园，3D 球场，48 支球队的 3D 展馆，运动风格，3D 网站，可以点击互动，单文件。记住，给我一个 3D 网站的 html 文件。

这个任务要求模型在单个 HTML 文件里完成3D 场景、世界杯主题、48 支球队展馆、交互点击、运动风格视觉设计等多重约束，换句话说，它既考验长代码生成能力，也考验模型在复杂需求下的结构组织能力。这类任务也正是 Coding Agent 中最典型的 token 密集型场景：输出长、结构强、格式复杂，而且一旦生成速度慢，用户的等待感会被迅速放大。此外，也容易因为极小的错误导致bug，进一步引发更长的修改周期和用户等待时间。

一起来看看两个模型的表现：

• 俯视图：两个 MiMo 模型都完成了“单文件 3D 世界杯虚拟乐园”的基本命题，但取向明显不同

MiMo-V2.5-Pro 构建

3D 世界杯虚拟乐园的俯视图

MiMo-V2.5-Pro-UltraSpeed 构建 3D 世界杯虚拟乐园的俯视图

左侧 MiMo-V2.5-Pro 生成的页面更偏“氛围型”：整体采用暗色星空背景，中央球场和环形展馆被放置在类似夜间宇宙舞台的场景中，视觉重心集中在中央的“2026 FIFA WORLD CUP”标识，页面顶部提供搜索框和分组筛选，底部也给出了拖拽旋转、滚轮缩放、点击展馆查看详情等交互提示。整体沉浸感较强，夜景、星点、环形布局和发光元素共同构成了一个完整的 3D 展示空间；但部分展馆和文字标签较小，整体可读性偏弱，页面信息组织仅完成概念演示。

相比之下，MiMo-V2.5-Pro-UltraSpeed 生成的结果更偏“产品型”：它同样生成了中心球场、环形球队展馆、顶部标题栏、右上角功能按钮以及底部字母筛选栏，画面更明亮，布局也更规整。48 支球队展馆被更清晰地排列在球场外围，球队标签、分组筛选和场景结构的可辨识度更高，用户能更快理解页面的功能逻辑。尤其值得注意的是，UltraSpeed 并没有因为生成速度更快而牺牲页面完整性：球场、展馆、标签、筛选入口和基础交互框架都被保留下来。

• 用户交互：两个模型都补上了拖拽旋转、滚轮缩放、点击展馆查看详情等基础操作

MiMo-V2.5-Pro 构建 3D 世界杯虚拟乐园的缩小和拖拽视图

MiMo-V2.5-Pro-UltraSpeed 构建 3D 世界杯虚拟乐园的缩小和拖拽视图

MiMo-V2.5-Pro 构建 3D 世界杯虚拟乐园的

局部放大视图

MiMo-V2.5-Pro-UltraSpeed 构建 3D 世界杯虚拟乐园的局部放大视图

用户在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 秒（935 秒），生成了759行代码。整个过程像一次重型推理和长时间代码生成：模型先花了较长时间规划，再逐步输出完整 HTML、CSS 和 JavaScript。

MiMo-V2.5-Pro-UltraSpeed的表现则明显不同，花费35827个 tokens生成了829行代码，代码行数更多；同时，思考阶段仅用33.1秒，平均速度达到581 tokens/s，生成阶段耗时13.2秒，平均输出速度达到980 tokens/s。也就是说，在产出规模不低于 Pro 版本的情况下，UltraSpeed 用更少的 token 开支和更短的等待时间，完成了同一类复杂前端任务。

两个 MiMo 模型的对比最能说明 UltraSpeed 的定位：它不是简单把回答“压短”来换速度，而是在长代码任务中显著压缩了推理和生成链路。对用户来说，Pro 版本是“等一杯咖啡”的节奏，UltraSpeed 更接近“眨几次眼，代码已经铺开”。对于需要反复生成、运行、修改的 Coding Agent 场景，这种速度差距会直接改变开发体验。

• UltraSpeed 的速度表现，基本把“高速版”的定位打到了明面上

从统计看，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 在 3D 世界杯乐园中新增了“世界杯历史馆”和“2026 对战馆”，页面顶部也同步加入了“主场馆/历史馆/对战馆”的导航按钮。历史馆被设计成带有“HALL OF HISTORY”标识的博物馆式建筑，对战馆则采用蓝色透明的未来感结构，并补充了世界杯历史梳理、2026 赛制、分组、赛程和城市等内容。这轮任务总计 34765 tokens、输出 26142 tokens，总用时约 33.6 秒，平均输出速度达到 1029 tokens/s，说明它在长代码修改任务中依然能保持很高吞吐。不过，这一版虽然完成了“新增场馆”的功能目标，但整体更像重新组织了一版功能更丰富的新页面，并没有延续第一版网页的视觉风格和交互语言。

因此，我们又进行了第二轮 Debug，将第一版源码重新提供给模型，并明确要求“在保留这个代码风格的前提下”增加历史馆和赛程中心馆：

[源码] 请在保留这个代码风格的前提下，增加世界杯历史馆和 2026 赛程中心馆

UltraSpeed 第二次 Debug，51.6 秒

交付风格一致的新需求版本

这次，UltraSpeed 没有再重新组织一套全新的页面，而是在原有 3D 世界杯虚拟乐园的视觉体系中，继续加入“世界杯历史馆”和“2026 赛程中心”：中央球场、环形 48 支球队展馆、底部分组筛选、顶部功能按钮和整体明亮的运动风格都被保留下来。新增历史馆采用金色穹顶、金色立柱和奖杯造型，与原页面的世界杯主题保持一致；赛程中心则以蓝绿色几何建筑呈现，旁边保留了球队展馆的环形排布和标签系统。

内容层面，模型补充了 22 届世界杯历史统计、四大传奇纪录、1930—2022 年完整赛事表格，以及 48 队、12 组、104 场、39 天、16 座主办城市、赛制说明和小组对阵等赛程信息。这一轮任务的上下文和输出规模更大，总 tokens 达到 105568，输出 45077 tokens，更多的 token 花费在带有源码的输入 60491 个，但总用时仍只有 51.6 秒，平均输出速度达到 1134 tokens/s。更关键的是，这次修改不只是“加了功能”，而是开始符合真实开发中的要求：在理解已有代码和既定风格的基础上，完成局部扩展和 Debug。

这是 UltraSpeed 在 Coding Agent 场景中的核心价值，模型不是每次都能一次性完美命中需求，但当每一轮反馈、修改和再生成都能在几十秒内完成时，开发者就可以更自然地进入连续协作节奏。

换句话说，UltraSpeed 的意义不只是“一次生成快”，而是让生成—发现问题—补充约束—再次修改这一循环变得足够轻。

02

为什么 UltraSpeed 能这么快？

要理解这个速度差距，需要回到 UltraSpeed 的底层设计。

公开信息显示，UltraSpeed 的底层模型是MiMo-V2.5-Pro-FP4-DFlash。它不是简单把模型砍小，而是在1.02T 总参数、42B 激活参数、1M 上下文的基础上，通过FP4 混合量化、DFlash 块级投机解码和 TileRT 系统级优化，把万亿参数模型的推理链路重新拆了一遍。

简单说：

FP4 让每一步读得少，DFlash 让总步数跑得少，TileRT 让 GPU 闲得少。

FP4：只压缩最该压缩的 Experts

在万亿参数模型上，显存带宽是推理速度的核心瓶颈。MiMo 没有把全模型粗暴压到 4-bit，而是选择性量化： 1) 只对 MoE 的Experts做 MXFP4 （Microscaling FP4）量化； 2) 注意力投影（包括o_proj）和其他关键模块保持更高精度； 3) 通过 FP4 QAT （Quantization-Aware Training）在训练阶段就适配低精度表示。

这个策略很直接：MoE 模型的大部分参数集中在 Experts，而每次推理只激活其中一部分。压缩 Experts，能显著降低显存和带宽压力；保留注意力等敏感模块，则尽量避免能力坍塌。

官方在 Hugging Face 发布的模型卡显示，MXFP4 相比 FP8 在多项 benchmark 上并没有带来明显的能力断崖：

在通用 Agent 场景中，MiMo-V2.5-Pro UltraSpeed (Ultra Fast) 在 Claw-Eval (pass^3) 上拿到67.8，高于原版 MiMo-V2.5-Pro 的63.8；在 Humanity's Last Exam 上为47.0，与原版48.0基本持平。到了 Coding Agent 场景，UltraSpeed (Ultra Fast) 在 SWE-Bench Pro 上达到58.8，略高于原版的57.2；在 SWE-bench Verified 上为77.4，低于原版78.9，但差距不大。

这说明 MiMo 的 MXFP4 路线不是简单牺牲精度换速度，而是在 MoE 架构上做“定点减重”：压缩参数量最大的 Experts，同时保留注意力等关键路径的高精度，由此在降低显存和带宽压力的同时，将能力损失控制在较小范围内，也为后续 DFlash 投机解码和 TileRT 系统优化打下基础。

DFlash：一次猜一块，而不是一个 token 一个 token 猜

MXFP4 解决的是“每一步太重”，DFlash 解决的是“步数太多”。

传统自回归生成需要逐 token 推理。输出 1000 个 token，理论上就要走约 1000 步。DFlash 采用块级并行投机解码：一个 5 层轻量 draft 模型一次预测一个 token block，再由 MiMo 主干模型统一验证。

具体地，DFlash 的块 (block size) 设为 8，其 drafter 不再逐 token 自回归生成，而是通过一次前向计算，直接填充整个被掩蔽的 token 块 (masked block)；随后，MiMo 主干模型会一次性验证多个 token，通过验证的 token 被保留，未通过的部分则从对应位置重新生成。

根据官方的 Acceptance Length，在 WebDev (Coding) 测试中，每轮 8 个 draft token 中平均有 6.30 个被接受。这意味着主干模型不必每个 token 都亲自生成，前向计算次数被大幅压缩。

此外，速度也和任务类型有关，Coding 场景明显高于开放对话场景，说明 UltraSpeed 在代码生成、结构化输出、Agent 任务中更容易发挥优势。

TileRT：把理论加速跑到真实 GPU 上

有了 FP4 和 DFlash，并不等于速度一定能跑出来。1T MoE 模型部署在 8 卡 GPU 节点上，还会遇到 kernel 启动、跨卡通信、数据搬运、expert 路由和流水线调度等系统瓶颈。

TileRT 解决的是这部分“最后一公里”。

TileRT 的优化主要集中在系统执行层面：一方面，它通过常驻内核减少计算内核反复启动带来的开销；另一方面，通过计算与数据搬运重叠，尽量压缩 GPU 等待数据的时间。同时，TileRT 还会针对 MXFP4 Expert 计算、DFlash 草稿生成、主干模型验证等不同阶段设计异构流水线，并配套定制编译引擎与计算核，以适配 MXFP4 量化和 DFlash 投机解码带来的动态执行特征。

因此，UltraSpeed 的 1000 tokens/s 不是单纯模型指标，而是一个系统工程指标。

03

速度不是免费的：

UltraSpeed 更适合时间敏感任务

当然，速度不是免费的。

UltraSpeed 的速度也对应更高的调用成本：UltraSpeed 的单价为 Pro 的 3 倍，因此，它是一种“时间优先”的选择。

小米官方的模型价格

同时，这意味着它不是所有场景下的默认选择，也不一定适合普通闲聊、低频问答或对延迟不敏感的任务。而于 Coding Agent、长代码生成、多轮 Debug、网页搭建和实时协作来说，成本判断不能只看“每 token 价格”，还要看“每轮迭代成本”。

如果每一轮都要等十几分钟，Agent 再聪明也很难进入真实工作流；但如果每一轮都能在几十秒内完成，用户的操作节奏就会完全不同。

模型从“我问你答”，变成“我指挥，你执行；我调整，你立刻改”。

从这个角度看，UltraSpeed 真正需要衡量的不是“贵不贵”，而是：当模型速度提升一个数量级时，节省下来的时间和迭代效率，是否足以覆盖更高的 token 单价。对于高频开发、实时协作和对响应速度敏感的 Agent 场景，这笔账很可能是成立的。

04

大模型从能回答走向能实时执行

过去一年，大模型能力竞争的主线，更多是在“答得准不准”、“推理强不强”和“代码会不会写”之间展开。但到了 MiMo-V2.5-Pro-UltraSpeed 这个模型上，一个新的分水岭开始变得清晰：模型不只是要会做任务，还要能在足够短的时间里把任务做完。

这不是一个简单的速度指标问题，而是大模型产品形态变化的前兆。

在传统聊天场景里，用户可以接受模型思考几十秒，甚至几分钟，因为交互本质上还是“提问—等待—回答”。但一旦进入 Agent、代码生成、网页搭建、数据分析、自动化办公这些场景，模型就不再只是一个答案生成器，而是一个执行单元。它需要理解目标、拆解步骤、调用工具、生成代码、修复错误，并在用户的连续反馈中快速迭代。

用户不再需要把大模型当成一个“慢速外包”。过去让模型生成一段复杂代码，常常要经历长时间等待；等它输出完，再复制、运行、报错、修改，整个过程仍然像传统开发流程的低速版本。而当首响应压到 1 秒左右、完整生成压到 1 分钟以内，模型就开始接近一种新的工作方式：它可以成为实时协作的开发搭档。

如果每一轮都要等十几分钟，Agent 再聪明也很难进入真实工作流；但如果每一轮都能在几十秒内完成，用户的操作节奏就会完全不同。模型从“我问你答”，变成“我指挥，你执行；我调整，你立刻改”。

从这个角度看，MiMo-V2.5-Pro 和 MiMo-V2.5-Pro-UltraSpeed 的对比，不只是同源模型之间的性能差异，而是大模型发展方向的一次缩影：前者证明了模型可以完成复杂任务，后者进一步证明了复杂任务可以被快速完成。

我们很期待其他的模型也能进一步赶上来。

MiMo 率先把万亿参数模型的生成速度推到了 1000 tokens/s 量级，但这不应该是少数玩家的专属能力，而应该成为整个行业的基准线。只有更多模型在保持能力的同时把推理成本降下来、把响应时间压下去，大模型才能真正从回答问题的工具，变成实时执行的基础设施。到那时，开发者不会因为等待而打断思路，Agent 不会因为延迟而失去连续性，用户也不再需要模型的能力和时间中进行权衡。这一天越早到来，整个生态就越早受益。

*附录：两个模型生成的网站源码链接:

https://pan.baidu.com/s/1E94bTRj_4zmxONCxxW2dUQ?pwd=wc7q