MLPerf によって測定される 1 秒あたりのトークンとは何ですか? また、LLM ではどのように使用されますか?

ハードウェアガイド » ベンチマーク » MLPerf によって測定される 1 秒あたりのトークンとは何ですか? また、LLM ではどのように使用されますか?

言語モデルを扱う方なら、「1秒あたりのトークン数」という言葉を何度も耳にしたことがあるでしょう。しかし、実際の環境でそれが何を意味するのか、そして何よりもMLPerfがどのようにそれを測定するのかを詳しく説明されることはほとんどありません。この記事では、トークンとは何か、推論において1秒あたりのトークン数という指標がなぜそれほど重要なのか、そしてDatabricksやMLPerfベンチマークなどのプラットフォームが、この指標をサイズ測定、比較、スケールにどのように活用しているのかを分かりやすく説明します。 さらに、メーカーからの具体的な数値や、クラウドから地上へのパフォーマンスの期待値も記載しています。.

この問題は軽微なものではありません。業界では、データ センターとエッジでの LLM パフォーマンスを評価するために、1 秒あたりのトークンを標準化しています。 査読済みの MLCommons スイートである MLPerf は、ハードウェアとソフトウェアを比較するためのベンチマークとなっています。並行して、Databricksなどの事業者は既に、1秒あたりのトークン数に基づいてモデルエンドポイントを直接プロビジョニングしています。数値とユースケースを踏まえながら、これを詳しく見ていきましょう。

トークンとは何ですか? LLM でなぜ重要なのですか?

言語モデルは、個々の文字や単語をそのまま処理するのではなく、トークンと呼ばれる単位で処理します。 トークンは通常約 4 文字、つまり平均で 0,75 語の長さです。この比率は言語とモデルのトークナイザーによって異なりますが、簡単な参考として役立ちます。10 語のテキストは 13 ～ 14 個のトークンで移動します。

正確なセグメンテーションはモデルによって異なります。 各LLMは独自のトークナイザーを使用し、単語を完全なトークンまたはサブワードに分割します。オンラインツールを使えば、例えばLlamaが特定のフレーズをどのようにトークン化するかを確認できます。一見些細なことのように思えますが、このばらつきはレイテンシやコンピューティングコストに影響を与えます。

生成速度について話すとき、それは通常、1 秒あたりの単語数ではなく、1 秒あたりのトークン数で表されます。 これにより、言語、コンテキストの長さ、出力スタイルにわたってメトリックが均一化されます。推論コストと必要な容量を正確に計算することができます。

なぜ RPS ではなく 1 秒あたりのトークンでパフォーマンスを測定するのでしょうか?

従来のAPIサービスはRPS（1秒あたりのリクエスト数）に重点を置いています。LLMでは、このアプローチは不十分です。 2つのリクエストは、入力トークンと出力トークンに応じて、非常に異なる時間がかかる可能性があります。つまり、実際のペイロードは「呼び出し回数」ではなく、トークンで提供されます。

変動の主な要因は2つあります。1つ目は、入力コンテキストの長さです。 短いプロンプトにはトークンが数個しか含まれないかもしれませんが、概要ドキュメントではトークンが数百または数千に急増する可能性があります。一方、出力の長さ: 要約すると通常はトークンが少なくなり、長い記事や説明を生成すると、出力のデコードが最もコストのかかる部分であるため、時間がかかります。

したがって、推論エンドポイントを現実的にスケーリングするには、トークンの観点から考えると役立ちます。 たとえば、Databricks は、サービング エンドポイントに 1 秒あたり一定範囲のトークンをプロビジョニングし、スケーリングに基づいて時間単位で課金します。こうすることで、全体像を把握できない RPS に惑わされることなく、容量を実際の負荷に合わせることができます。

DatabricksとMLPerfが1秒あたりのトークンを測定する方法

Databricks は、RAG の代表的な負荷を基準として、次のように要約しています。 2048個の入力トークンと256個の出力トークン両方のフェーズ (事前入力とデコード) を組み合わせ、デフォルトでは、リクエストごとにバッチ サイズ 1 のスループットとレイテンシのバランスを最適化し、複数の同時リクエストをシミュレートします。

このルールでは、数値は次のようになります。エンドポイントを2304秒あたり2048トークン（256 + XNUMX）で構成した場合、 これらのサイズのリクエストには約1秒かかります5600 秒あたり 0,5 トークンに設定すると、同じリクエストが約 XNUMX 秒に短縮され、XNUMX 秒あたり XNUMX つの同様のリクエストを処理できるようになります。

ワークロードが変化すると、レイテンシーも変化します。 出力トークンを多く生成すると、入力トークンを増やすよりもペナルティが大きくなります。バッチ推論を行う場合は、データセットの入力トークンと出力トークンの平均数を計算し、それを以前のベンチマークと比較して時間を見積もってください。

実際の例: 1000行、平均3000入力トークンと500出力トークン、プロビジョニングされたスループットが3500秒あたりXNUMXトークンの場合、 1000秒以上かかります 平均値が基準値を超えているためです。代わりに、1500秒あたり100トークンのプロビジョニングで平均1600入力、XNUMX出力とすると、 1000秒を下回ります 合計で 1000 行になります。

オンデマンドの自動スケーリングと実際のスケーリング計算

Databricks Model Servingには、高速な自動スケーリング機能が搭載されており、 1秒あたりのトークンの需要に基づいてリソースを増減しますシステムは容量ブロック単位でスケールし、追加の容量は使用された場合にのみ課金されます。並列リクエスト数を増やしたテストでは、プロビジョニングされたスループットが増加し、リソースが飽和状態になると8000秒あたり約XNUMXトークンで安定し、キューイングのレイテンシが増加します。

1 秒あたりのトークン数がマークした数より少ない場合は、次の 2 つの点を確認してください。 エンドポイントのメトリックと最小帯域幅サイズを反映したプロビジョニングされた同時実行性 構成済み。このデータを使用して、実際のスケーリングは次の式で推定されます：プロビジョニングされた同時実行数 × 最小帯域幅サイズ / 4。

具体的な例: 最大同時実行数が8で、最小ストライプサイズが850秒あたりXNUMXトークンの場合、 実質的な制限は1700秒あたりXNUMXトークンとなる。 (8 × 850 / 4)。この計算式を理解することで、予期せぬ事態を防ぎ、レイテンシSLOに合わせて設定を微調整できるようになります。

MLPerf 推論：それが何であるか、そして現在何を測定しているか

MLCommons によって開発された MLPerf は、ビジョンから LLM まで、データセンターとエッジでの AI パフォーマンスを測定するためのオープンで標準化されたスイートです。 その目標は、公平かつ再現可能な方法でプラットフォームを比較し、エコシステムの効率を高めることです。最近の版では、焦点は明らかに GenAI と大規模 LLM に移行しています。

第2版では、Llama 70 50BがResNetXNUMXに取って代わり、スターベンチマークとして統合され、 3,3秒あたりのトークンの指標は、XNUMX年間で最良の場合で最大XNUMX倍に改善されました。ハードウェアとソフトウェアの最適化により、平均パフォーマンスは5倍向上しました。公式結果にはIntel Xeon 6などのCPUも含まれており、 特定のシナリオでは、効率的なジェネラリストソリューションの余地がある.

MLPerf Inferenceのバージョン5.1では、XNUMXつの新しい主要ベンチマークが組み込まれ、さらに飛躍的な進歩を遂げました。 DeepSeek-R1による推論、Whisper Large v3による音声テキスト変換、およびLlama 3.1 8Bに基づく小規模なLLM全体として、コンソーシアムは 27 名の参加者を報告し、90.000 件の結果というマイルストーンに到達し、インタラクティブ シナリオにおけるレイテンシ メトリックを絞り込みました。

新しいベンチマークの指標と目標

1BパラメータのMoEであるDeepSeek-R671による推論ベンチマークでは、 これらのモデルは答えが出る前に長い推論の連鎖を生み出す最大 20.000 トークンの出力をサポートし、データセット内の出力あたり平均 3880 トークンは、これまでの推論で最大のものです。

ルールは、オフライン モードとサーバー モードで厳格な制限付きでスループットを測定します。 最初のトークンまでの時間は2秒、トークンあたりのレイテンシはp80で99ミリ秒これは、「考える」予算とそれを展開するために必要な応答性のバランスをとることを目的としています。

Llama 3.1‑8B を使用した小規模な LLM ベンチマークが、ゲートウェイとして GPT‑J 6B に取って代わります。 最大128.000トークンのコンテキストをサポート CNN-DailyMailの要約を778個の入力トークンと73個の出力トークンを用いて評価しました。精度はROUGEで検証されており、閉区間において高精度ベンチマークの99%に匹敵することが求められます。

レイテンシ メトリックでは、TTFT (最初のトークンまでの時間) と TPOT (トークン アウトあたりの時間) の 2 つの指標が使用されます。 サーバーでは、2 秒の TTFT と 100 ミリ秒の TPOT が記録されます。 (約 480 ppm)、新しいインタラクティブ シナリオでは、チャット、コーディング、クリエイティブ ツールなどの場合にはそれぞれ 0,5 秒と 30 ミリ秒 (約 1600 ppm) に圧縮されます。

メーカーとオペレーターによるパフォーマンスのハイライト

• NVIDIAは再びリードし、今回はGB300 NVL72システムでBlackwell Ultraがスコアを獲得しました。 DeepSeek-R45はGB1 NVL200より72%高い推論スループットを実現オフラインでは GPU あたり 5842 秒あたり 2907 トークン、サーバーでは 5 トークンに達し、未検証の Hopper と比較して XNUMX 倍近くの改善が見られました。
• 新しいインタラクティブなLlama 3.1 405Bベンチマークでは、NVIDIAは Dynamoによる分散型サービス異なる GPU でコンテキストと生成を分離し、KV キャッシュを NVLink 経由で転送することで、Blackwell での従来のサービスと比べて GPU あたりのスループットが 1,5 倍、Hopper を使用したシステムと比べて 5 倍以上向上しました。
• 小型モデルについては、NVIDIAは Llama 18.000 3.1BオフラインでGPUあたり8秒あたりXNUMXトークン以上 Whisper では GPU あたり 5667 秒あたり XNUMX トークンを達成し、あらゆるシナリオ (オフライン、サーバー、インタラクティブ) で GPU のリーダーシップを維持しています。
• AMD は、現在 355-2B の範囲にある Instinct MI70X GPU の最初の出荷により存在感を拡大しました。 FP2,7ではMI325Xと比較してマルチノードスケーリングと8秒あたりのトークン数がXNUMX倍増加した。. オープンディビジョンでは、ラマ3.1-405B（FP4）に構造的剪定が適用され、 82%の深度削減モデルではスループットが21%向上し、90%の微調整モデルではスループットが33%向上します。精度を維持しながら。
• また、Llama 2-70B Interactive、Mixtral-8×7B、Stable Diffusion XLの出荷も開始し、MI300X/MI325Xの混合結果も発表しました。 4ノードに拡張すると、MI355XはMI3,4Xよりも300倍のスループットを達成しました。優れたスケーラビリティを備え、8 ノードまで拡張できます。
• HPEはProLiantとCrayを統合し、14の1位を獲得しました。DL380a Gen12は、3.1GPU PCIeシステムの中でDLRMとLlama 8-8B（サーバー）で際立っていました。DL385 Gen11は、 WhisperでGPUパフォーマンスが向上しました Cray XD200 (670× H8) は、RetinaNet、Llama 200-3.1B、Mixtral、Whisper で 8 つの最高記録を達成し、さらに DLRM では RTX Pro 6000 Blackwell SE と GH200 NVL2 の結果で最高記録を達成しました。
• CoreWeaveはGB300で結果を報告した最初のクラウドであり、 DeepSeek-R6005ではGPUあたり毎秒1トークン オフラインで、Kubernetes 上の Slurm を使用したオーケストレーションとスケーリング、およびトポロジを考慮したスケジューリングを実演し、NVLink を最大限に活用します。
• DellはAMDとNVIDIAのアクセラレーターを搭載した12のシステムを出荷し、PowerEdge XE2LとB70でLLaMA 9680 200B Interactiveで輝いた。 XE3.1L+B8 上の LLaMA 9685‑200B サーバー、XE9685L の SDXL、XE9680L の Whisper により、LLM による画像から音声までの多用途性が実証されました。
• インテルは、 サーバーCPUで結果を送信する唯一のもの Pコア搭載のXeon 6は、1,9つのベンチマークにおいて第5世代Xeonと比較して8倍のパフォーマンス向上を示し、汎用推論におけるその役割を確固たるものにしました。また、Llama60-192Bを複数のユーザーに提供するために2GBのVRAMを備えた70基のArc Pro BXNUMX GPUを搭載したワークステーションも発表しました。さらに、マルチGPUの導入を簡素化するドライバーとフレームワークもバンドルされています。
• インテグレーターとパートナーの中で、ASUSTeK 量子化、カーネル、スタックによるレイテンシとスループットの最適化Broadcom は、複数のワークロード (Whisper、SDXL、Llama 3.1-405B、Llama2-70B、RGAT、RetinaNet) でベアメタルと比較してオーバーヘッドが最小限である VCF 仮想化を実証しました。Cisco は、One G885 ネットワークでサポートされている UCS C8A M8 (200× H845 SXM) および UCS C8A M8 (200× H40 NVL または L200S) を使用して、ほぼ直線的に拡張しました。
• KRAIはOpenAI APIと現実的なオーバーヘッドを使用して、SGLangとvLLMをLlama3.1‑70Bと比較しました。 SGLang 31.391 でオフライン時に 0.4.9 秒あたり XNUMX トークン また、26.319x H0.9.2 を搭載した単一サーバーでは、vLLM 8 で 200 に達しました。動的量子化では、SGLang で 27.697、vLLM で 30.893 に達し、マルチノードでは、87.334 つのサーバーで XNUMX 秒あたり最大 XNUMX トークンまでスケールしました。
• ラムダは8x B200 180 GB SXMを搭載し、スループットが向上した。 SDXLでは最大7％、ラマ15-3.1Bでは最大405％ 前回のラウンドと比較して、マネージド Kubernetes または Slurm を使用した 16 ～ 1536 GPU のクラスターが提供されます。
• MiTACのG8825Z5シリーズは、LLaMA 2 70B Interactiveで輝きを放ちました。 18.846,1秒あたりXNUMXトークン サーバーとMixtralで良好な結果を示し、NebiusはGB200 NVL72、HGX B200、HGX H200で仮想化パフォーマンスがベアメタルとほぼ同等であると認定しました。 サーバー側では毎秒596,11トークン、Llama 855,82‑3.1Bではオフラインで405トークン 4 GB200 GPU を搭載。
• Red Hatは、AI推論サーバーでサポートされているランタイムとしてvLLMをデモしました。 FP8およびFlashAttention-3用のCUTLASSカーネル さらに改良されたvLLM v1エンジンを搭載し、優れたコストパフォーマンスでLlama-3.1-8BのH100およびL40Sに搭載されています。
• Supermicroは、インテルとAMDのCPUの両方でHGX-B200 8-GPU（空気と液体）でトップの結果を記録しました。 Llama 3.1-8B および Llama 2-70B（サーバー/オフライン/インタラクティブおよび Whisper）共同研究においては、32× H100-SXM および MI325X との代替手段で優れたスケーリングが示されました。
• VultrはSupermicro AS-8126GS-TNMRと8基のMI325Xを搭載し、クラウドGPUとして競争力のあるパフォーマンスを証明しました。GATEOverflow MLCFlowによる再現性の向上 RTX 4090およびAMD/Intel CPU上で、Giga Computingは8U空冷式EPYC+MI325XおよびXeon+HGX B200システムを出荷しました。QCTは、6× MI200Xシステムに加えて、H4 NVL（8 GPU）を搭載したXeon 200構成と、NVLinkおよびGPUDirectストレージを備えた5× H8 SXM325プラットフォームをカバーしました。

学術界にも大きな成果がありました。フロリダ大学は、HiPerGatorと統合されたDGX B200 SuperPODを導入し、 推論結果を提出した最初の機関であった クローズドパーティショニングによるサーバーレイテンシの達成、Docker/Sudoを使わずにApptainerの使用、そしてマルチユーザーSLURMへの適合。その逆の極端な例として、M1 MacBook Proで単一の送信を行った場合、 ONNXランタイムとGPUおよびニューラルエンジン上のCoreMLを使用は、エッジ カテゴリで目標精度を上回り、コンシューマー ハードウェアで品質推論を評価できることを実証しました。

ユーザーが感じる速度と実用的な限界

ユーザーエクスペリエンスはベンチマークで測られるだけでなく、日常生活でも 流動性は、1秒あたりのトークンの特定のしきい値を超えたときに感じられますあるユーザーは、会話の制限は 4 秒あたり 10 トークン、ストーリー作成の場合は XNUMX 秒あたり約 XNUMX トークンで、これより低いとインタラクションが遅く感じるとコメントしました。

LLMをローカルで実行しようとすると、3つの現実があります。デスクトップCPUでは、 1秒あたり2～XNUMXトークンの移動が正常です長い回答には適していません。ハイエンドのゲーミングGPUなら、5秒あたり100トークン近くまで処理できます。NVIDIA H60なら、すでにXNUMX秒あたりXNUMXトークンの処理が可能です。 しかし、これはデスクトップハードウェアではなく、データセンターハードウェアです.

クラウドでは何が起こっているのでしょうか? 最も強力なプロバイダーは、専用のハードウェアと最適化された推論スタックのおかげで、これらの数字を上回っています。 ChatGPT-119では4秒あたり約168トークン、GeminiではXNUMX秒あたりXNUMXトークンの平均が報告されています。一方、DeepSeekなどの人気のオープンソースモデルでは、21秒あたり約119トークンです。これを単語数に換算すると、90秒あたりXNUMXトークンは約XNUMX単語になります。

運用上の結論：ほとんどのユーザーにとって、 コンピュータ上でAIを実行することは可能だが、速度が遅いため実用的ではない快適な速度と短いレイテンシで作業するには、マネージド サービスが依然として賢明な選択肢です。

TPSに基づいてエンドポイントのサイズを決定する方法とレイテンシから何を期待するか

サイズ設定の実践的な手順。まず、ユースケースの概要を説明します。 入力トークンと出力トークンの平均数、長さの分布、および予想される同時実行性次に、TTFT とリクエストごとに持続する 1 秒あたりのトークン数を含む代表的なデータセットを使用して負荷テストを実行します。

次に、構成をパターンに合わせて調整します。ワークロードがDatabricksのリファレンス（入力2048、出力256）に似ている場合は、 リクエストが希望のレイテンシ予算内に収まるように、1秒あたりのトークンの範囲を選択します。通常、出力の複製は入力の複製よりもコストがかかり、効果的な同時実行性は実際の自動スケーリングに依存することに注意してください。

監視と調整。指標に注目してください プロビジョニングされた同時実行性、キュー、TTFT、TPOTを算出し、SLOと比較してください。容量が不足している場合は範囲​​を拡大し、リソースに余裕がある場合は範囲​​を下げてブロックを調整することで節約できます。真のスケーリング式は、レプリカが十分に作成されていない場合にエンドポイントが構成どおりに動作しない理由を理解するのに役立ちます。

最後に、シナリオに注意してください。対話型チャットボットスタイルのモードでは、 TTFTは0,5秒、トークンあたり30ミリ秒を目指す これにより、プレミアムなユーザーエクスペリエンスが実現します。サーバーモードでは、トークンあたり2秒と100ミリ秒が適切なガイドラインであり、オフラインでは、ベンチマークに必要な精度を維持しながら最大のスループットを追求します。

MLPerf の傾向を見ると、そのベクトルは明らかです。 より多くのコンテキスト、より多くのトークン、そしてより効率的なテクニック —分散型サービング、FP4/FP8、構造化プルーニング、カスタム カーネル、KV キャッシュ スケジューリング— により、チップあたりおよびシステムあたりの両方で、トークン上限が前年比で XNUMX 倍に上昇しています。

Databricks と MLPerf によって描かれた全体像は一貫しています。 LLM におけるコスト、レイテンシー、スケーラビリティを考えるには、1 秒あたりのトークン数で考えるのが最適です。適切な代表ベンチマーク、TTFT/TPOT メトリック、適切に調整された自動スケーリングにより、インフラストラクチャを過大にすることなく、高速で安定した応答を実現できます。