MoE

一个万亿参数的模型，在 8 张消费级 GPU 上每秒吐出 1000 个 token——这件事本身并不新鲜，因为类似数字过去只在论文 demo 或特制硬件上见过。但小米 MiMo 团队和 TileRT 推出的 MiMo-V2.5-Pro-UltraSpeed，用的是商品化 GPU、开源推理框架、没有定制芯片。这就有意思了。 更关键的是，实现这个速度的路径不是"把量化做狠一点"或"投机解码多猜几个 token"这么简单。它触及了一个更根本的问题：当推理系统逼近硬件物理极限时，模型架构和推理引擎必须从设计阶段就开始同步进化，而不是各自优化完再拼到一起。 这篇拆解 MiMo × TileRT 做了什么，以及"Speed Scaling"作为新范式到底意味着什么。 万亿参数推理为什么特别难 先说背景。MoE（Mixture of Experts）架构让万亿参数模型在训练端变得可行——每次前向传播只激活一小部分参数，推理时的计算量远低于密集模型。但推理端有一个不太一样的瓶颈：显存带宽。 一个 1T 参数的 MoE 模型，即使只激活几百亿参数，完整的权重还是得住在 GPU 显存里。用 FP16 加载需要 2TB 显存，8 张 80GB H100 只有 640GB，根本装不下。即使用 FP8（1TB），仍然超出单节点容量。 这意味着推理速度的瓶颈不在计算，而在数据搬运——每生成一个 token，GPU 都要从显存读取相关权重，读取速度直接决定生成速度。业界称之为"Memory-Bound"场景，token/s 的上限 = 显存带宽 / 每 token 需要读取的字节数。 所以，要让 1T 模型跑快，核心就两件事：减少每次搬运的数据量，和减少搬运次数。 第一层：FP4 选择性量化——不是所有参数都值得用低精度 减少数据量最直接的方法是量化。MiMo-V2.5-Pro 采用的是 OCP Microscaling (MXFP4) 格式——一种 Microsoft 主导的 FP4 标准，在极低比特下保持数值稳定性。 但关键不是"全模型 FP4"。如果暴力把所有层都压到 4 bit，模型在复杂推理、代码生成等任务上会出现明显退化。MiMo 的做法是选择性量化： ...