標準 GPU で LLM 推論 3000 tokens/s/req — 数字の前提を運用者目線で読む

結論 — 3000 tokens/s は本物。ただし自分の請求書に今日は効かない

Kog AI が公開した "Real-time LLM Inference on Standard GPUs: 3,000 tokens/s per request" を読みました。8 枚の AMD MI300X で 1 リクエストあたり毎秒 3000 トークン、NVIDIA H200 8 枚でも 2100 トークン。専用アクセラレータではなく「標準 GPU」でこの数字、というのが売りです。結論から書くと、数字は本物だが、この速さをそのまま自分の推論コストやレイテンシに当てはめると判断を誤ります。理由は 3 つで、(1) これは batch size 1 の単一リクエスト速度、(2) モデルは 2B の小型、(3) スタックは完全自前で再現性が公開されていない、の順に効いてきます。

なお、この記事は AI が下書きを書き、私が一次情報（元記事）に当たって確認・編集してから公開しています。私が運用者として気にするのは「ベンチの数字が、自分のサーバの月次請求書とレイテンシにどう翻訳されるか」だけです。そこに絞って読みます。

数字の正体 — batch size 1 の単一リクエスト速度であって、集約スループットではない

最初に押さえるべきは、3000 tokens/s が「1 ユーザーの 1 リクエストを、batch size 1（同時処理する依頼を 1 件に絞った状態）でデコードする速さ」だという点です。複数リクエストをまとめて捌いたときの集約スループット（aggregate throughput、サーバ全体で毎秒さばけるトークン数）ではありません。ここを取り違えると、コスト試算が桁で狂います。

運用者がふだん最適化したいのは、たいてい集約スループットの方です。1 枚の GPU でどれだけ多くの同時ユーザーを薄く捌けるか、で 1 トークンあたりの単価が決まるからです。一方この記事の 3000 という数字は、1 人のために 8 枚の GPU をまるごと使い切ったときの単一ストリーム速度。体感レイテンシ（応答が返り始めてから読み終わるまでの速さ）の世界では劇的ですが、原価計算の世界とは軸が違います。速い車を 1 人で借り切った話であって、何人を同時に運べるかの話ではない、と読み替えると腹落ちします。

「公開された数字をどの軸で読むか」を毎回確かめる癖は、以前 謎の LLM「Hy3」が OpenRouter 利用ランキングで Claude を抜いた件を運用者目線で読んだとき にも書きました。ランキングもベンチも、測っている軸を確認しないと自分の意思決定には使えません。

どう出したか — PyTorch も Triton も捨て、monokernel で組み直した

この速さは、裏技の積み増しではなく「抽象化レイヤーを全部はがした」結果でした。記事は明確に、量子化なし・投機的デコーディングなし・枝刈りなし・KV キャッシュ圧縮なし、と書いています。よくある高速化テクニックを使わずに出した、という主張です。

代わりに効いているのは低レベルの作り込みです。中心は monokernel ランタイムで、デコード経路全体を 1 つの常駐 GPU プログラムにまとめ、カーネル起動のたびに発生する約 4.5 マイクロ秒のオーバーヘッドを消しています。さらに PyTorch も Triton もベンダーライブラリも経由せず、CUDA / HIP を手書きしてアセンブリまで降りる。GPU 間通信も KCCL という自前の集合通信層で約 3 マイクロ秒（ベンダー製は約 8 マイクロ秒）。アーキテクチャは Laneformer と呼ぶ改造版 Transformer で、Delayed Tensor Parallelism という手法で通信と計算を重ねています。25 層モデルでトークン 1 個あたりの予算が約 333 マイクロ秒、1 層あたり約 13.3 マイクロ秒という、息が詰まるほど薄い時間配分でした。

ここまで読んで私が連想したのは、Quake を 1997 年のツールチェーンでビルドし直す話を再現性で読んだとき の構図です。標準の抽象化を信じずに、自分で全部固定する。速度や再現性の急所は、結局「どこまで前提を自分の手に握ったか」に戻ってきます。ただし、その握り方は普通のチームには重すぎる、というのが次の論点です。

モデルは 2B・HumanEval 50% — これはフロンティアではなく「速さの実演」

見落としやすいのは、計測対象が Laneformer 2B という小型 dense モデルだという点です。FP16、コンテキスト長 4096、Nemotron データセットで 6 兆トークン学習、HumanEval（コード生成の標準ベンチ）は 50%。記事自身が「この preview は速さを観測可能にするためのもので、フロンティアのコーディング助手を提供するものではない」と断っています。

つまり 3000 tokens/s は「2B モデルを 8 枚の GPU で殴ったらこれだけ出る」という実演であって、80B〜1.6T パラメータの MoE（Mixture of Experts、巨大モデルを部分的に動かす方式）のような実用級モデルでの数字ではありません。大型モデルでの性能は projected（見込み）と書かれていて、まだ実測ではない。再現性も live playground（playground.kog.ai）での体験に限られ、外部ハードでの完全な再現手順は公開されていません。私が自分の本番に「明日入れられるか」で見ると、現時点の答えは「入れられない」です。技術デモとしての価値と、運用に載せられるかは別だ、と切り分けておきます。

根拠の弱い数字を鵜呑みにしない感覚は、5 つのフロンティア LLM が事実判定の 67% で割れる話 を書いたときと同じです。出典に当たって、前提を確認してから判断に使う。

運用者として持ち帰る 3 つ

結局、運用者がこの発表から実務に持ち帰れるのは数字そのものではなく、読み方の枠組みです。私は 3 つに整理しました。

1 つ目、ベンチの数字は必ず「単一リクエスト速度なのか集約スループットなのか」を確認する。体感レイテンシを語る数字と、原価を語る数字は別物です。2 つ目、計測モデルのサイズと品質（ここでは 2B / HumanEval 50%）を必ず併記して読む。同じ手法が実用級モデルで成り立つ保証はありません。3 つ目、再現条件（ハード構成・スタックの公開有無）を見て「明日載せられるか」を判断する。8 枚の MI300X と完全自前カーネルが前提なら、ほとんどの個人開発者・小規模チームにとっては当面は観賞用です。

自前推論のコストを本気で下げたい人は、こういう派手な単一リクエスト記録より、Embedding コストを 1/70 にした地味な工夫 の方向の方が、たいてい請求書には早く効きます。派手なベンチは未来を見せ、地味な最適化は今月を助ける。両方を別の引き出しに入れておくのがちょうどいい塩梅です。

まとめ — 速さの天井を知り、原価の軸と混ぜない

Kog AI の 3000 tokens/s は、抽象化を全部はがせばここまで行けるという、推論速度の天井を見せてくれる良い実演でした。monokernel と自前通信層で 1 層 13.3 マイクロ秒まで削る作り込みは、純粋に読み物として面白い。

そのうえで運用者として持ち帰るのは、「batch 1 の単一リクエスト速度」「2B モデル」「再現条件未公開」という 3 つの前提です。この前提を外して数字だけ受け取ると、自分の集約スループットや原価の判断に紛れ込みます。速さの記録は記録として楽しみ、月次の請求書は別の物差しで詰める。私の本番推論は今日も地味な最適化で回っていますが、天井がどこにあるかを知っておくのは、悪くない投資でした。