MiMo-V2.5-Pro UltraSpeed で 1T モデルが 1000 tokens/s — 数字の前提を運用者目線で読む

まず結論 — 「1T で 1000 tokens/s」は decode 速度の話で、batch とレイテンシは別腹

Xiaomi の MiMo チームが 2026 年 6 月、1 兆パラメータ規模の MoE モデル「MiMo-V2.5-Pro」を UltraSpeed モードで動かし、デコード速度 1000 tokens/s 超（ピークで約 1200 tokens/s）を達成したと発表しました。結論から言うと、この数字は「1T モデルでここまで出たのは初めて」という意味では確かにすごいのですが、運用者が本当に知りたい batch size やリクエストあたりのレイテンシ、トークン単価は、今回の発表文からは直接読み取れません。だから速報の見出しを真に受ける前に、何の速度なのかを一段だけ分解しておきます。

発表は MiMo の公式ブログ Pushing 1T-Parameter Model Generation Speed to 1000 TPS にまとまっています。私はこの手の「tokens/s」系の数字を見るたび、まず「単一ストリームの decode 速度なのか、複数リクエストをまとめた集約スループットなのか」を確認する癖がついています。以前まったく別件で、集約スループットを単一リクエスト速度と読み違えてキャパシティ見積もりを 1 桁外したことがあり、それ以来この種の発表には妙に慎重になりました。

数字の出どころ — MXFP4・DFlash・TileRT の三段重ね

1000 tokens/s は単一の魔法ではなく、独立した 3 つの最適化を積み重ねた合計です。重みの量子化（MXFP4）、投機デコード（DFlash）、そして専用ランタイム（TileRT）。効くレイヤーが違うので、速くなる理由も別々に読む必要があります。

ここを「ひとつのブレークスルー」として丸めて理解すると、自分の環境に当てはめたときの期待値を間違えます。たとえば自前で量子化だけ真似ても、投機デコードとランタイムが揃っていなければ同じ倍率は出ません。逆に言えば、3 つのうちどれが自分のワークロードに効くかを見極めれば、全部入りを待たずに一部だけ取り込む判断もできます。以下、順番に読みます。

なぜ速いか① メモリ帯域を削る MXFP4 — Experts だけを量子化する

decode が遅い最大の理由はメモリ帯域です。MiMo は MXFP4（ブロック単位で指数を共有する 4bit 浮動小数点フォーマット）を MoE の Experts 部分にだけ選択的に適用し、attention などそれ以外は元の精度を保つ、というやり方を採っています。1T 規模では FP8 や FP16 の重みがメモリ容量と帯域を強く圧迫するので、ビット幅を下げた重みがメモリを速く通り、それがそのまま decode 速度に効く、という理屈です。

MoE（Mixture of Experts、トークンごとに一部の専門家だけを使う構成）では、毎ステップで全パラメータを読むわけではなく、アクティブな Experts のぶんだけを読みます。「総量は巨大・アクティブは一部」という構造の意味は、以前Liquid の LFM2.5 8B-A1B を読んだときに整理しました。その読み込む側の Experts 重みを 4bit に落とせば、毎ステップのメモリ移動量がそのまま減ります。量子化で品質をどこまで保てるかは別途検証が要りますが、MiMo は FP8 比較で「ほぼ同等」としています。どこまで攻められるかという幅で言えば、1bit まで落としたBonsai Image 4B の話と並べて読むと、量子化のレンジ感が掴みやすいはずです。

なぜ速いか② DFlash 投機デコードと「受理長」という workload 依存の罠

2 つ目は DFlash speculative decoding（投機デコード、安価な機構で先のトークンを推測し、本体モデルでまとめて検証する手法）です。投機デコードの基礎は 2022 年の Leviathan らの論文 Fast Inference from Transformers via Speculative Decoding がよく引かれ、出力分布を変えずに 2〜3 倍の高速化が得られる、という枠組みでした。DFlash は 1 回の forward pass でマスクされたブロックごとまとめて予測する設計になっています。

ここで運用者が一番見るべき数字は acceptance length（受理長、1 回の検証でまとめて確定できるトークン数）です。MiMo の報告では coding で 6.30、math/reasoning で 5.56、agent で 4.29 と、用途によってはっきり差があります。受理長が大きいほど速くなるので、coding の 6.30 を見て期待した人が、agent ワークロードで 4.29 しか出ずに「思ったより伸びない」と感じる、という落とし穴があります。あなたの本番トラフィックが agent 寄りなら、coding ベンチの速度倍率はそのまま当てにできません。投機デコードは「速くなる確率を買う技術」で、当たりやすさは入力の素直さ次第だ、というのが私の読み方です。

なぜ速いか③ TileRT ランタイム — オーバーヘッドを μs スケールに畳む

3 つ目は TileRT という専用ランタイムで、パイプライン全体を microsecond スケールで回すと説明されています。量子化で帯域を、投機デコードで forward pass 回数を減らしても、カーネル起動やスケジューリングのオーバーヘッドが太いと、その節約が食い潰されます。TileRT はその実行時オーバーヘッドを薄く保つ役回りです。

この 3 段目は地味ですが、運用者にとっては再現性に直結する部分でもあります。量子化フォーマットや投機デコードの考え方は公開知識で真似られても、microsecond 級まで詰めたランタイムは一朝一夕には組めません。つまり「同じ MXFP4 と投機デコードを使えば同じ 1000 tokens/s が出る」とは限らない、という保険の読み方をしておくのが安全です。動かない時にだけ効いていたことに気付く、縁の下の最適化です。

運用者として確認したいこと — batch / レイテンシ / コスト / 再現性

速報を自分の意思決定に使う前に、私が確認したい点は 4 つあります。batch size、リクエストあたりのレイテンシ、トークン単価、そして再現性です。

まず batch。発表文に batch size の前提が書かれていないため、1000 tokens/s が単一ストリームの体感速度なのか、複数同時リクエストの集約値なのかが判別できません。ここが決まらないと、ユーザー 1 人が感じる速さにも、サーバー 1 台の収容力にも換算できない。単一リクエストの速度という文脈では、以前読んだ標準 GPU で 2B モデルを 1 リクエスト 3000 tokens/sとは、モデル規模も前提もまるで違う数字なので、横並びで比べないほうがいいです。

次にコスト。速さは嬉しいものの、運用の財布に効くのは結局トークン単価と総コストです。速いモデルでも呼ぶ回数が多ければ請求は膨らむので、まずコストを「呼ばない」で抑える三段防御のような設計を土台に置いてから、推論速度の話を乗せる順番だと思っています。最後に再現性。UltraSpeed は 2026 年 6 月 9 日から 23 日まで、単一の 8-GPU ノードで動く API トライアルとして公開されています。手元のワークロードで受理長と実効スループットを自分で測れる、この期間が一番の答え合わせになります。

持ち帰り — 三段に分けて、自分の workload で測り直す

最後に判断の順番を整理します。「1T で 1000 tokens/s」を見たら、まず MXFP4（帯域）・DFlash（forward pass 回数）・TileRT（実行オーバーヘッド）の三段に分解する。次に、自分のワークロードが coding 寄りか agent 寄りかで受理長が変わることを思い出し、ベンチの倍率をそのまま当てにしない。最後に batch とレイテンシの前提が書かれていないことを踏まえ、トライアル期間に自分の入力で測り直す。

この 3 ステップを踏むだけで、速報の数字に振り回されずに「自分にとって速いのか」を判断できます。なお、この記事も AI が下書きを書き、私が数字の出どころと前提を確認・編集したうえで公開しています。速いという見出しは気持ちいいのですが、運用者の仕事は気持ちよさの裏側にある前提を読むことのほうだ、と毎回自分に言い聞かせています。