DeepInferのベンチマークを読む: V4.1-Flashの性能

DeepInferのV4.1-Flashベンチマークは引用しやすく、解釈しにくい。毎秒トークン数という値はエンジンの性質ではない。エンジン、モデル、バッチ、コンテキスト長、ハードウェア構成、ワークロードの組み合わせの性質だ。チャートは1つの旅の地図であり、あなたの旅の保証ではない。

単位の罠

サービングの議論には3種類の速度が登場し、互いに置き換えられるものではない。

あるシステムが高いtokens/s/GPUと低いtokens/s/userを同時に持つことはある。decodeチャートが示しているのはまさにそれだ。並列度が上がると集計スループットは上がり、各ユーザーのストリームは遅くなる。どちらの数値もエンジンの「速度」ではない。

エンドツーエンドのレイテンシには、ネットワーク、キューイング、トークナイズ、スケジューリング、APIのオーバーヘッドが加わる。どれもチャートには入っていない。decodeの100 ms/stepはTTFTが100 msという意味ではなく、325 tokens/s/userは応答が325 msという意味でもない。

Prefill: バッチがスループットを買い、レイテンシがその代金を払う

prefillはプロンプトを処理し、KV cacheを構築する。バッチを大きくすると重みの読み出しが償却され、GPU利用率が上がるので、スループットが上がる。だが1ステップあたりの時間も長くなるため、レイテンシも上がる。

DeepInferのprefillチャートはSM100 4基、コンテキスト131,072トークンを使う。ラベルは4,096から65,536までのバッチサイズだ。曲線は最初急に上がり、その後なだらかになる。

• バッチあたり4,096トークンでは、スループットはおよそ60k tokens/s/GPU、1ステップは約68 ms。
• 16,384では、スループットはおよそ81k、1ステップは約200 ms。
• 65,536では、スループットはおよそ89k、1ステップは約730 ms。

ピークより曲がり角のほうが重要だ。SLOが厳しければ曲線の左側に立ち、スループットで代金を払う。オフラインのバッチ評価なら右側に立って、長いステップを受け入れられる。どちらが正しいかはチャートではなく、ワークロードが決める。

prefillチャートが何を測っているかにも注意したい。非キャッシュ入力のスループットだ。プロンプトの大半がキャッシュヒットなら、prefillの仕事はずっと小さく、この曲線はボトルネックにならない。キャッシュヒット率は別の変数であり、欠けているKV cacheシステムが最大化しようとする変数でもある。

Decode: 並列度がスループットを買い、インタラクティブ性がその代金を払う

decodeは1ステップにつきリクエストあたり1トークンを生成する。並列リクエストが増えるほど、GPUは1ステップでより多くの有用な仕事をするので、集計スループットは上がる。だが各リクエストはトークン間の待ち時間が長くなるため、ユーザーあたり速度は下がる。

DeepInferのdecodeチャートはSM100 64基、コンテキスト131,072トークン、nextn=3 fixed、トークンあたりのdraft受容率75%を使う。ラベルはDPランクあたりのリクエスト数だ。

• ランクあたり8リクエストでは、集計スループットはおよそ2.6k tokens/s/GPU、各ユーザーは約325 tokens/s。
• ランクあたり64リクエストでは、スループットはおよそ15.5k、各ユーザーは約248 tokens/s。
• ランクあたり256リクエストでは、スループットはおよそ26k、各ユーザーは約103 tokens/s。

形はサービングの古典的なトレードオフだ。チャット製品なら左側を選ぶかもしれない。バッチ要約やオフラインのエージェント処理なら右側だろう。チャートが有用なのは、単一点ではなくフロンティア全体を示しているからだ。

examplesのREADMEには、decodeスループットの背後にある計算式が載っている。

decode throughput = avg_SPS × decode_num_requests × (1 + nextn) / cp

これは「全受容前提の計算」だ。実際の受容率にかかわらず、すべてのdraftトークンが受け入れられると仮定する。チャートはその結果に0.75の受容率を掛けている。テキストが予測しにくければ実値は下がり、予測しやすければ上がりうる。

75%という前提

投機的デコードはdraftトークンを提案し、バッチでまとめて検証する。利得は受け入れられるdraftの数に依存する。decodeチャートはトークンあたり75%の受容率を仮定しており、これは1ステップあたり平均約3.25トークンの受容長になる。

この仮定は予測しやすいテキストには妥当で、自由形式の推論、珍しい識別子を含むコード、高度に技術的な文章には妥当しにくい。DeepSeek自身の本番データでは、DSpark構成での受容長は3.2〜3.3程度なので、チャートの仮定は恣意的ではない。それでも仮定であり、あなたのワークロードの性質ではない。

関連するDSparkの最適化、可変長検証も負荷依存だ。DeepSeekは本番動作点で+4〜7%のスループットを報告する一方、低並列では小さな損失があるとしている。「投機的デコードは無料」というメンタルモデルが誤りである好例だ。利得は受容率と、検証に回せる余力の大きさに依存する。

評価スコアが測っているもの

評価スクリプトはサービングのベンチマークではない。3つのオフラインタスクでモデルの品質を測る。

• AIME 2026: 30タスク、各32サンプル、Pass@1 99.9%。
• GPQA Diamond: 198タスク、各8サンプル、Pass@1 93.4%。
• HLE-Full: 2,500タスク（テキスト2,158、画像342）、各1サンプル、Pass@1 42.6%。

Pass@1は、1つのサンプルが正しい確率だ。タスクあたり32サンプルなら、AIMEの99.9%は960回のロールアウトの平均になる。HLEの1サンプルはそれよりずっとノイズが多い。評価用READMEは、反復実行で差が出うること、Pass@1の値はcoverage_completeがtrueのときのみ有効だと警告している。

これらの数字は、デフォルト構成でモデルがこれらのベンチマークで十分な能力を持つことを示す。別のエンジンより速い、安い、信頼できるとは示さない。それには同じハードウェア、コンテキスト、ワークロードでのサービングベンチマークが必要で、できれば第三者が実行したものが望ましい。

読解チェックリスト

推論のベンチマークを見たら、こう問う。

1. 単位は何か。 tokens/s/GPUか、tokens/s/userか、ms/stepか。
2. ワークロードは何か。 コンテキスト長、入力/出力比、キャッシュヒット率、リクエストの到着パターン。
3. ハードウェアは何か。 GPU/NPUの型番、台数、インターコネクト、メモリ、そして単一ノードかクラスタか。
4. バッチ/並列度は何か。 高並列でのスループットのピークは、レイテンシ重視の製品には無関係かもしれない。
5. 何が含まれているか。 エンジンだけか、KV cache、ルーティング、APIオーバーヘッドを含むサービングスタック全体か。
6. 何を仮定しているか。 draftの受容率、キャッシュヒット率、量子化、tensor/pipeline並列。
7. 誰が実行したか。 ベンダー自身の測定か、独立したラボか、コミットハッシュ付きの再現か。
8. 比較は何か。 同じモデル、同じハードウェア、同じワークロード、同じSLOか。

3つ以上が満たせない主張は、調達の数値ではなく方向性のシグナルとして扱う。

戻るならチャートの読み取り値、進むなら欠けているサービス層へ。