LLM 自ホストで数百万円節約する方法

はじめに

安価なオープンウェイトモデルが未来だと信じるなら、この記事はあなた向けです。なぜそう言えるのかは既にご存知でしょうから、ここではその根拠となる経済性に基づいた具体的な「やり方」をお伝えします。

私はこれまで、この形式で LLM の推論に関する数式とコスト計算の両方を、実際の運用トラフィックやプロバイダーとの交渉データに基づいて解説した記事を見つけたことがありません。これは、LLM 推論の数式とドル単位の費用を、生産環境での実数値に裏打ちされて初めてカバーできる、唯一無二（あるいは最も重要な）記事です。

もし本書の数式計算に誤りが見つかった場合は、印刷版の書籍をお送りし、末尾のクレジット欄にお名前を記載させていただきます。

この記事は誰向け？

• ソフトウェアエンジニア・マネージャー: オープンウェイトモデルを実装する方
• AI 研究・推論エンジニア: 推論の数式と価格設定の実用的なモデルを知りたい方
• 経営層・プロダクトマネージャー: 「自社ホスト化（Self-hosting）に価値があるのか」を検討中の方。数式の部分はざっと読み飛ばし、末尾の金額部分だけ読んで判断してください。
• 学生: フロンティアラボでの就職を目指す方

このブログ記事に必要な数学は高校レベルの代数だけです。登場するすべての式は、掛け算・割り算・累乗などの基本演算で構成されています。機械学習の深い専門知識は必須ではありません。トランスフォーマー、MoE（Mixture of Experts）、KV キャッシュ、量子化などに関する用語は、本文内で解説するか、私が探した最も優れた入門記事へのリンクを貼っています。ただし、このブログ記事自体は非常に密度が高く、真に理解を深めるには、これらのリンク先でさらに深く学ぶ必要があります。最低限でも、内容を完全に自分のものにするためには週末 1 日を費やすことをお勧めします。

では、具体的に何を取り扱うのでしょうか？

今回の事例として取り上げるのは「Kimi K2.6」です。これの性能評価には、Cline の実際の生産環境でのトラフィックデータを基準（グランドトゥルース）とします。この計算式は、自分で GPU を借りる場合も、推論プロバイダーから利用する場合も、どちらでも通用するものです。順を追って、モデルの読み込み、推論サービスの提供、バッチ処理、そして本番環境向けにチューニングする方法まで解説していきます。

モデルアーキテクチャ

モデルをセルフホストするには、まずその重み（ウェイト）を GPU にロードする必要があります。これに必要なメモリ量は、モデルのアーキテクチャによって決まります。Kimi K2.6 は DeepSeek V3 のアーキテクチャに着想を得たもので、MoE パラメータを採用しています。

• 総パラメータ数：1 兆（スパース MoE）
• アクティブパラメータ数：320 億
• ヒドゥンサイズ：7,168
• アテンションヘッド数：64
• ルートされるエキスパート数：384
• 共有エキスパート数：1
• トークンあたりのエキスパート数：8
• MoE インターミディエイトサイズ：2,048
• MoE レイヤーの頻度：1
• コンテキストウィンドウ：256K トークン

これらの数値をゼロから導出したい場合は、Kipply の伝説的な「パラメータ計測記事」をお読みください。

トランスフォーマーアーキテクチャの背景知識を得たいなら、必ず『The Illustrated Transformer』を読んでください。もしブログ記事を読む気力がない場合は、私がこれまで見た中で最も優れた LLM 可視化ツールである「LLM Visualizer」を試してみてください。

GPU の選定

今回は NVIDIA B200（Blackwell）を採用します。これは NVIDIA のフラッグシップ推論用 GPU で、主要なネオクラウドからレンタル可能です。

この GPU について知っておくべきポイントは以下の通りです。

• GPU 1 基あたり 192 GB の HBM3e VRAM を搭載
• 標準的な HGX ラックには 8 基の GPU が NVLink で接続されています。NVLink は GPU 間の高速インターコネクトであり、これにより 8 基の GPU が推論時にあたかも巨大な 1 つの GPU のように動作します。
• 8 基構成のノードにおける総 GPU メモリ容量は 192 GB × 8 = 1,536 GB（約 1.5 TB）です。

このノードの実質的なコストはいくらになるのでしょうか？

本ブログ全体で統一する数値を一つ決めておきましょう。GPU 1 基あたり時間当たり 6 ドルとします。2026 年の実際の B200 の価格は、GPU 単体のレンタルであれば約 4 ドルに近くなる可能性がありますが、ここでは保守的な上限として切り上げました。もしこの計算で採算が取れるなら、現実世界でも問題なく成立するはずです。

• $6/GPU/時間 × 8 GPU = 1 ノードあたり 時間当たり $48
• $48 × 24 時間 = 1 ノードあたり 1 日当たり $1,152
• $48 × 730 時間（月平均）= 1 ノードあたり 1 ヶ月当たり $35,040
• $48 × 8,760 時間 = 1 ノードあたり 1 年当たり $420,480

この時間当たり$48 が固定費です。ユーザーが 1 人でも 1,000 人でも、メーターは同じように回ります。本ブログの残りの部分では、この「時間当たり$48」からいかに多くのトークンを引き出すかについて解説します。これが実質的なトークンあたりのコストを決めるからです。

注記：

このモデルを API 推論に月額 35,000 ドル以上使っている場合のみ、セルフホスティングは意味を持ちます。このモデルは小規模な構成では動作しないため、月額 35,000 ドルが最低限の参入条件となります。

GPU のレンタルなら月額 3.5〜4 ドルから可能ですが、推論プロバイダーを利用すると、モデルのホスティングやスペキュレーティブ・ディコーディング（予測的デコーディング）、そしてその他の推論最適化技術の管理コストとして、月額 5.5〜6 ドルを請求されます。このブログ記事の後半で詳しく解説しますが、他人にモデルを任せるために追加費用を支払うのは、適切に行えば推論エンジニアを雇うよりもはるかに安く、非常に優れた選択肢です。

では、このモデルを読み込むには何枚の GPU が必要なのでしょうか？

まず重み（ウェイト）のサイズを確認しましょう。

Kimi K2.6 は 1 トリオン（10 兆）のパラメータを持っています。今回は FP4 量子化（パラメータあたり 0.5 バイト）で動作させます。量子化とは、モデル内の各重みをより少ないビット数で保存する技術です。例えば $4.7283910 を四捨五入して $5 に丸めるようなものです。これによりメモリ上のモデルサイズが劇的に縮小され、注意深く実施すれば、ほぼ同じ精度の回答を得ることができます。

FP4 は積極的な量子化レベルですが、現代のモデルは量子化を前提として訓練されているため、品質への悪影響はさほど大きくありません。また、ホスティングが容易になり、GPU への読み込みに必要なメモリも大幅に削減されます。

計算式：

重みサイズ = 1,000,000,000,000 パラメータ × 0.5 バイト = 500 GB

次に GPU メモリで割ります。

500 GB ÷ B200 のメモリ 192 GB = 約 2.60

つまり、技術的には FP4 量子化モデルの重みをロードするには B200 が 3 枚あれば十分です。これが最低ラインであり、VRAM にモデルを読み込むにはこれで足りるものの、それ以上の余裕はありません。

量子化と品質について

量子化は、コストと品質のトレードオフです。コスト面では、このセクション以降の数値すべてがパラメータあたりのバイト数に対して線形に比例します。FP4 では重みが 500GB になり、FP8 にするとその倍の 1TB（B200 を 3 基ではなく 6 基必要とします）、BF16 にするとさらに倍になります。現代の量子化対応モデルにおいて、許容できる品質を維持しつつ最も安価な tier が FP4 です。そのため私たちはこれを採用しています。もし評価結果で FP4 がワークロードに悪影響を与えていると判明すれば、計算式はそのままに FP8 で再構築すればよいだけです（コストは上がりますが）。なお、ここで言う「FP4」とは Blackwell のネイティブな 4 ビット形式である NVFP4 を指します。以降のブログ全体でも簡略化のため「FP4」という表記を使います。

品質面でのトレードオフは、スペックシートからは見えません。一部のプロバイダーは低コスト・低遅延の推論を提供していますが、量子化が過度に激しすぎて、どれだけ優れたレイテンシ SLA（Service Level Agreement）を謳っていても出力が崩壊してしまいます。実際に何が提供されているかを知る唯一の方法は、評価（evals）を実行することです（当社の設定はこちら）。

このモデルを提供するために必要な GPU 数は？

モデルを読み込むことと、実際のトラフィックに対応してサービスを提供することは別問題であり、後者の方がより多くの VRAM を消費します。同時接続するユーザーそれぞれに、KV キャッシュの断片（アテンションが二次関数的になるのを防ぎ、新しい推論リクエストでキャッシュを活用するための per-user memory）が必要です。また、リクエストを効率的にバッチ処理するために帯域幅と余裕分も確保する必要があります。KV キャッシュ、帯域幅、そして余裕分については次節で詳しく解説しますが、現時点では VRAM の残りがここに使われると理解してください。

さて、8 枚の B200 GPU を搭載したノード全体（VRAM 合計 1,536 GB）を活用します。このリソース配分は以下の通りです。

この約 956 GB が、実際にユーザーにサービスを提供するための予算です。次のセクションでは、このリソースをどのように配分するかを解説します。

モデルの提供 (Serving the model)

リクエストが来ると、モデルはまずプロンプト全体を読み込む「プリフィル」処理を行い、その後トークンを一つずつ生成する「デコード」処理を行います。今回は、長文生成においてコストの大部分を占めるデコードから解説し、後ほどプリフィルについても触れます。

デコードの要点 (TL;DR)

LLM は一度に一つのトークンだけを生成します。モデルは新しいトークンを出力する際、これまでに得られたすべての情報（入力プロンプトと、直前に生成したトークン）を参照して次のトークンを決定し、処理が完了するまでこれを繰り返します。

[prompt] → token_1

[prompt + token_1] → token_2

[prompt + token_1 + token_2] → token_3

...

このループの 1 回（1 フォワードパス）ごとに、入力は数十層のネットワークを通過します。各層は VRAM から自身の重みスライスを読み取り、その出力を次の層へ渡していきます。最終的に、次に来るトークンの確率分布が得られ、モデルはその中から一つを選択して生成し、また次のステップへと進みます。

つまり、推論処理とは「VRAM から重みを読み込む → 行列計算を行う → トークンを出力する → これを繰り返す」という単純なループに過ぎません。

トークンの生成（デコード）

320 億のアクティブパラメータを持つモデルにおいて、出力トークンを 1 つ生成する際に必要なデータフローは以下の通りです（FP4 量子化では 1 パラメータあたり 0.5 バイトとなります）。

トークンあたりの読み込みバイト数 = 32B アクティブ × 0.5 バイト = 16GB

つまり、生成するトークン 1 つごとに、重みデータ 16GB が帯域幅を流れます。これが最大のボトルネックとなる数値です。

NVIDIA B200 GPU 1 基あたりのメモリ帯域幅は 8TB/s です。一見すると莫大な数字に見えますが、計算を実行してみましょう。最大出力速度は「帯域幅 ÷ トークンあたりのバイト数」で求められます。

• 単一の B200: 8 TB/s
• 8 GPU ノード（理論値）: 64 TB/s
• 8 GPU ノード（実効値）: 同期オーバーヘッドを考慮して約 50 TB/s

50,000 GB/s ÷ 16 GB/token ≈ 3,125 tok/s（理論値）

実際の運用ではメモリ帯域利用率（MBU）が 10〜12% に制限されるため、実効的なデコード速度は合計で約 312〜375 トークン/秒となります。

つまり、FP4 で量子化された Kimi K2.6 を 8 GPU の B200 ノード全体で小バッチサイズで処理する場合、理論上の上限は aggregate decode（集計デコード）速度で約 3,125 トークン/秒です。

デコードは逐次処理のため、トークン N+1 を生成するにはトークン N の完了を待たなければなりません。このため、デコードは帯域幅に依存し、出力ストリームの速度を決める指標が TPS（1 秒あたりのトークン数）となります。（注：スペキュレーティブ・ディコーディングの例外を除く）

理論上の最大デコードスループットと実測値の最大スループットの注意点

上記の「16 GB/token」という数字は、バッチサイズが 1 の場合、つまり各トークンが独自に専門家（エキスパート）を呼び出すという前提に基づいています。しかし、バッチ処理が始まるとこの前提は崩れます。多くのユーザーが同じ順次計算パス（フォワードパス）を通るようになると、MoE（Mixture of Experts）構造内でトークン間で専門家の読み込みが共有されるため、1 トークンあたりの実効バイト数は減少し、デコード全体の処理速度はこの数値を大きく上回ります。他にも考慮すべき要素はありますが、バッチ処理の具体的な仕組みについては後述する「バッチング」のセクションで詳しく解説します。

「3,125 tok/s」という数字も理論上の値に過ぎません。実際に達成できる性能は、MBU（Memory Bandwidth Utilization：メモリ帯域利用率）によって決まります。これは、推論スタックが実質的に有効な作業に割り当てている、名目上の帯域幅の割合のことです。この MBU の値は状況によって大きく変動します。例えば、vLLM と Kimi K2.6 を使用し、8 枚の B200 GPU に 80K トークンのコンテキストを処理させた場合など、下限に近い環境では約 11% という測定結果も出ています。

私たちが得られる実践的な教訓は、理論上の上限やベンダーが提示する数値を鵜呑みにしてはいけないということです。負荷テストを実施し、以下の式で実際に達成された MBU を計算してみましょう。

（測定した Aggregate Decode の tok/s × 1 トークンあたりのバイト数）÷ ノードの名目帯域幅

その後、研究論文などと照合して、自分の結果が妥当な範囲内にあるか確認してください。もし大幅に外れている場合は、その原因を突き止める必要があります。

さらに進む前に、GPU の推論性能における真のボトルネックを理解するための 2 つの重要な概念を押さえておく必要があります。

1. メモリバウンドとコンピュートバウンドの違い
2. 演算強度（Arithmetic Intensity）

メモリバウンドとコンピュートバウンド

これはトランスフォーマー推論、より広くは深層学習の最適化において頻繁に遭遇する課題です。基本的な考え方は以下の通りです。GPU で数値計算を行うには、まずメモリから重み（weights）を読み出す必要があり、これがメモリー帯域幅の消費につながります。

好消息として、この部分は非常に最適化されており、GPU は最初の重みがメモリから読み込まれた瞬間に計算を開始できます。つまり、メモリの読み込みと数学演算は並列して実行されるのです。

したがって、ある瞬間には以下の 2 つの状態のいずれかが起こっています。

Compute-bound（計算バウンド）/ Flop-bound: この場合、GPU は演算処理でボトルネックになっています。演算ユニットがフル稼働しており、メモリはアイドル状態です。FLOP（Floating Point Operation）とは浮動小数点演算の 1 つを指します。乗算 1 回、加算 1 回などが該当します。「GPU は 15 PFLOPS の性能を持つ」と言う場合、それは 1 秒間に 15 × 10¹⁵回の浮動小数点演算が可能であることを意味します。計算バウンドと FLOP バウンドの詳細については、講義ノートをご覧ください。

Memory-bound（メモリーバウンド）: この場合、メモリへのデータ転送経路がフル稼働しており、演算ユニットはアイドル状態です。

もう一度強調しておきますが、デコード処理はメモリー帯域幅に依存しており、これが推論速度の大きなボトルネックとなっています。

演算強度（Arithmetic Intensity）

GPU は常に「メモリーバウンド」か「計算バウンド」のいずれかの状態にあります。この 2 つの状態を切り替えるのが「演算強度」です。これは、メモリから読み込んだ 1 バイトあたりに行われる FLOP の数で定義されます。

arithmetic_intensity = 実行された FLOPs / HBM から読み込まれたバイト数

すべての GPU には、計算処理と帯域幅処理が同時に完了する「ブレイクイブンポイント（屋根モデルにおける山頂）」が存在します。この山頂より下側ではメモリーバウンドとなり、上側では計算バウンドとなります。

FP4 で動作する B200 の場合、計算とメモリのバランスを示す「リッジ（山頂）」は以下のようになります。

ridge = peak_flops / peak_bandwidth

= 10 PFLOPS / 8 TB/s

≈ 1,250 FLOPs per byte

つまり B200 では、計算がボトルネックになる前に、重み（weight）の 1 バイトあたり約 1,250 回の演算を行う必要があります。これ未満だと、数学演算ユニットが HBM のデータ転送を待ってアイドル状態になってしまいます。

ここでデコードとプリフィルの位置づけを確認しましょう。

デコード（バッチサイズ=1）：読み込んだ重み 1 バイトあたり約 2 FLOPs（各重み値に対して乗算・加算が 1 回ずつ）。これは完全にメモリ帯域制限領域にあり、リッジから約 600 倍も低い位置にあります。そのため、デコード時のトークン生成速度（tok/s）は演算能力ではなく、帯域幅によって決定されます（以前にも触れましたね）。

プリフィル：重みは一度だけ読み込まれ、数千のトークン（またはバッチ処理）で再利用されます。このとき、その読み込みを共有するトークン数に応じて演算強度はほぼ線形に増加します。十分な数のトークンを 1 つの順伝播パスに通せば、リッジを超えて計算制限領域へと移行できます。

この視点は、本ブログの残りの部分でも常に意識しておくべきポイントです。後述するすべての最適化手法は、根底では「HBM のトラフィックにおける 1 バイトあたりにより多くの有用なトークンを生成させる」ための工夫、つまり演算強度を高めるトリックにほかなりません。後ほど負荷テストを行い GPU への負荷を高めた際、この両方の限界を実践で確認できるでしょう。

プロンプトトークンの読み込み（プリフィル）

次に学ぶべき概念は「プリフィル」です。これは、ユーザーが入力したプロンプト全体を一度に大規模な並列行列乗算として読み込み、モデルがそれを処理して応答（デコード）を生成できるようにするプロセスを指します。

imageイラスト付きトランスフォーマーの画像

なぜプリフィル（初期処理）を並列実行できるのか？

入力シーケンス全体が既知であるため、データを層に流し込む際に並列処理が可能です。重みの読み出しは 1 回で済み、その瞬間に数千トークンを同時に処理できます。このように 1 回の読み出しを数千トークンで共有することで、帯域幅のボトルネックは解消されます。

プリフィルは計算量（コンピュート）がボトルネックとなります。今回のケースでは、B200 GPU は帯域幅よりも圧倒的に高い計算能力を持っています。GPU 1 基あたり FP4 で約 10 PFLOPS の密集演算性能があり、8 基を並列運用しています。

現実的なプリフィル速度は、8 GPU 構成の B200 ノードで集計すると約 78,000 トークン/秒に達します。これは、長い Kimi K2.6 の会話において、1 秒間に 1 つのコーディングエージェント相当の新しいプロンプトを処理できる速度です。Cline でこのワークロードを実行した際に測定される値がこれになります。

計算の詳細

GPU あたりの FLOPS = 10 PFLOPS

トークンあたりの FLOPS = 2 × 32B（アクティブ）= 64 GFLOPs

ノードの計算能力 = 8 GPU × 10 PFLOPS = 80 PFLOPS（密な FP4 演算）

理論上の最大値 = 80 PFLOPS ÷ 64 GFLOPs ≈ 125 万 トークン/秒

現実的な数値 ≈ 6.4% の MFU（アテンションの二次関数的コストと MoE のオール・トゥー・オール通信がボトルネック。ただし B200 のアテンションパイプラインが部分的にこれを相殺）

≈ 長いプロンプトで 78,000 トークン/秒（負荷テストで実際に観測された値）

MFU（Model FLOPS Utilization：モデルの FLOPS 利用率）は、モデル処理で実際に消費された FLOPs/秒を、ハードウェアが持つピーク FLOPs/秒で割った値です。

これは事前計算（prefill）の数値に対する現実的なチェックになります。もし測定した MFU が文献で報告されている範囲から大きく外れているなら、自社のスタックに根本的な問題があるか、あるいは他社の方が同じハードウェアからより多くの性能を引き出しているかのどちらかです。

TTFT：最初のトークンまでの時間（Time To First Token）

これは、チャットで「送信」ボタンを押してから最初の文字がストリーミング表示されるまでにかかる待ち時間を指す指標 TTFT の由来です。最初のトークンが表示されるまでの間はすべて計算リソースを消費する事前計算（prefill）の領域であり、それ以降はメモリ帯域幅を消費するデコードの領域となります。

もしノードで 80,000 トークン/秒の速度で事前計算が行える場合でも、ユーザーが 80,000 トークンのプロンプトを送ってきたとすると：

80,000 トークン ÷ 80,000 トークン/秒 = TTFT は 1 秒

ただし実際には、以下の 2 つの要因が異なる方向にこの数値を大きく変動させます：

1. バッチ処理：80K トークン/秒という数値は、GPU ノード全体の最大スループットです。もし 16 ユーザーが同時にプリフィル（初期化）を実行した場合、各ユーザーに割り当てられる実効スループットは約 5,000 トークン/秒に過ぎません。その結果、80K のプロンプト処理には約 16 秒かかってしまいます。

ストリームごとの数値と集計値では大きく異なり、実際の性能を把握するにはさまざまな構成で負荷テストを行う必要があります。バッチ処理の詳細については、このドキュメントの後半で改めて解説します。

1. KV キャッシュの活用とプロンプトの再利用：コーディングエージェントやチャットボットでは、会話が積み重なるように進行します。長いスレッド内で 5 通目のメッセージが送信された際、過去の会話から得た KV キャッシュはすでに VRAM に保持されているため、80K のコンテキスト全体を再プリフィルする必要はありません。

必要なのは差分のみです。つまり、新しいユーザーのメッセージと、その時点で読み込まれた最新の文脈（ファイルの読み込みやツールの出力など）だけです。

Cline ではシステムプロンプトは小さく、約 3〜4K トークン程度です。トークンの大半を占めるのは、会話のやり取りの中で行われるファイル読み込みや検索の結果です。コンテキスト全体が 80K に達していても、実際のある特定のターンでプリフィルされる新しいトークンは通常 8〜10K 程度であり、その多くはファイル読み込みによるものです。

KV キャッシュ：956 GB の VRAM はどこへ消えたのか

先ほど「約 956 GB の空き VRAM を確保した」とお話ししましたが、これがまさに KV キャッシュに充当される場所です。

KV キャッシュが解決する核心的な問題はこれです。モデルが新しいトークンを 1 つデコードするたびに、アテンション層はコンテキスト内のすべての過去トークンの K（キー）と V（バリュー）ベクトルを必要とします。キャッシュがない場合、各デコードステップで K と V を最初から再計算することになり、新しいトークンごとに履歴全体を新規に事前処理（prefill）する羽目になります。これは何の価値もない二乗計算です。

解決策はシンプルです。過去のトークンからの K と V は、そのトークンの決定論的な関数であり、モデルの重みも変化しません。つまり、ステップ 5 で計算した K と V の値は、ステップ 6、7、10 でも全く同じ数字として再計算されることになります。一度計算して VRAM に保存し、その後のすべてのステップで読み出せばよいのです。

上記の画像が、この仕組みの直感的な理解を助けます。

洞察 2：次のトークンのアテンション計算には、新しいトークンからのクエリベクトルと、すべての過去のキー・バリューベクトルだけで十分です。Q（クエリ）はステップごとに新しく生成されますが、過去のステップから得た K と V は、一度計算すれば永遠に再利用可能です。

つまり、キャッシュの動作は以下のようになります。トークン 5 を生成する際、K_5 と V_5 を新たに作成して K/V バッファに追加します。一方、トークン 1～4 はキャッシュから読み出されます。次にトークン 6 を処理する際は、K_6 と V_6 を追加し、トークン 1～5 をキャッシュから取得します。ステップごとに新しいペアを 1 つずつ追加するだけで、再計算は不要です。これが KV キャッシュのすべてです。

このキャッシュのサイズは、何バイトになるのでしょうか？

DeepSeek V3 と、アテンションアーキテクチャを継承する Kimi は、MLA（Multi-head Latent Attention）を採用しています。従来のように各ヘッドごとに K（Key）と V（Value）をキャッシュするのではなく、MLA では層ごとに単一の共有潜在ベクトルと小さな RoPE 成分に圧縮します。これにより、キャッシュサイズはヘッド数に依存しなくなります。

bytes_per_token (MLA) = num_layers × (kv_lora_rank + qk_rope_head_dim) × bytes_per_value

= 61 × (512 + 64) × 1

≈ 35 KB / token / user

956 GB の VRAM をキャッシュに充てる場合、ユーザーあたりの KV キャッシュ量は以下のようになります。

KV per user = 35 KB × context_length

利用可能な VRAM は 956 GB なので、理論上の最大同時接続ユーザー数は以下で計算できます。

max_users ≈ 956 GB / (context_length × 35 KB)

これは理論上の上限値であり、運用上の上限ではありません。もし残りの VRAM がすべて KV キャッシュに充てられると仮定すれば上記の数字が成立しますが、現実はもっと複雑です。実際には一度に 341 ユーザーを捌くことはできず、せいぜい 32 ユーザー程度しかサポートできません。その理由については、次のバッチ処理（Batching）のセクションで解説します。

バッチ処理（Batching）

バッチ処理の本質的な目的は、デコード処理がメモリー帯域幅にボトルネックを抱えている点にあります。バッチサイズを 1 にすると、単一のユーザーに対してトークンを 1 つ生成するだけで、HBM から重みデータをすべて読み出すという全コストを支払うことになります。これは明らかに非効率です。すでにデータバス上に存在する重みを、より多くのトークンに流用しない手はありません。

つまり、多数のユーザーによる次のトークンの計算を1つの順次パスにまとめて処理します。各パスではモデルの重みを一度だけ読み込み、バッチ内のすべてのユーザーがその読み込み結果を共有します。もし B 人のユーザーを