ステータス：ドラフト（2026-10-07）、マップ記事です。 この記事は新しい測定を行わず、同じ連載の別の記事における 筆者が直接計測した値と ドキュメントで確認した内容を1枚にまとめたものです。数値の横には、どの記事でどのような条件で計測したかを記載しています。測定はすべて小規模なモデル1〜2個、GPU1枚（8GBクラス）、使い捨ての単一ノードクラスターで行ったため、 絶対値よりも形状と原理を持ち帰っていただければと思います。ドキュメント基準であるか、測定したことがない内容は「ドキュメント基準」、「未計測」と表示しました。 作成ルール：実測データが基本であり、測定できなかったものは「未計測」と表示します。
目次
- 1. この記事をどのように読めばよいか
- 2. 全体マップ：8つの層
- 3. 層1：GPUとハードウェア、速度の上限はどこから来るのか
- 4. 層2：KubernetesのGPUスタック
- 5. 層3：スケジューリングとマルチテナンシー
- 6. 層4：LLMサービングエンジン、数値で理解する
- 7. 層5：ネットワーク
- 8. 層6：ストレージとモデルデプロイ
- 9. 層7：観測可能性と障害診断
- 10. 層8：コントローラーとデプロイ自動化（Kubernetesエンジニアのツール）
- 11. 測定する方法：すべての層を貫く技術
- 12. 4週間学習パス
- 13. 現場や面接でよく出る質問
- 15. このマップが扱わないこと
- 参考：このマップの根拠となった記事
- 確認した日付
1. この記事をどのように読めばよいか
ML・AIインフラストラクチャは1つの分野ではなく、 複数の層が重なった分野です。GPUメモリ帯域幅を知らなければサービングの数値を説明できず、Kubernetesスケジューラーを知らなければGPU作業がなぜ停止するのか分からず、観測可能性を知らなければその両方を修正できません。この記事では、各層ごとに「これだけは知っておくべきこと」を整理し、深く読むべき記事へと繋げます。
読む順序は2つあります。
- ML・AIインフラエンジニア： 第2〜5節（ハードウェア、スタック、スケジューリング、サービング）を先に見るか、第9節の測定方法に進みます。
- Kubernetesエンジニア： 第3、4、8節（スタック、スケジューリング、コントローラー）を先に見、GPUが一般的なリソースとどこが異なるかを第2節と第5節で補います。
2. 全体マップ：8つの層
| 層 | コアな質問 | 代表的なツールと概念 | 深く読むべき記事 |
|---|---|---|---|
| 1. GPUとハードウェア | 何が速度の上限を決めるのか | メモリ帯域幅、演算スループット、VRAM構成 | 第21回、第11回 |
| 2. KubernetesのGPUスタック | GPUはどのようにPodに届くのか | ドライバー、ツールキット、デバイスプラグイン、GPU Operator、パススルー | 第3回、第13回 |
| 3. スケジューリングとマルチテナンシー | 複数のチームと作業がGPUをどのように分割するか | Kueue、Volcano、ギャングスケジューリング、クォータ、プリエムプッション | 第10回、第9回 |
| 4. LLMサービングエンジン | スループットとレイテンシーは何が決めるのか | 連続バッチング、KVキャッシュ、プレフィックスキャッシュ、チャンクプリフィル、量子化、LoRA | 第4回、第5回、第14回、第15回 |
| 5. ネットワーク | サービスの拡張とGPU間通信 | CNI、kube-proxy vs Cilium、サービスメッシュ、RDMA、NCCL | 第2回、第7回 |
| 6. ストレージとモデルデプロイ | 重みとKVをどこに配置するのか | モデルキャッシュ、コールドスタート、KVオフロード、重み保護 | 第8回、第16回 |
| 7. 観測可能性と障害診断 | 何を見て、いつアラートを上げるのか | DCGM、XID、TTFT・ITLパーセンタイル、サーバーメトリクス | 第17回、第18回、第11回、 第25回 |
| 8. コントローラーとデプロイ自動化 | 宣言された状態をどのように維持するのか | CRD、オペレーター、GitOps | 第9回 |
3. 層1：GPUとハードウェア、速度の上限はどこから来るのか
知っておくべきこと
- トークン生成はメモリ帯域幅が上限を決めます。 トークンを1つ生成するたびにすべての層の重みを1回読み込むため、
초당 토큰 수 ≤ 메모리 대역폭 ÷ 가중치 바이트です。 - 入力（プロンプト）の処理は演算が上限を決めます。 一度に多くのトークンを計算すると、同じ重みを複数のトークンが再利用します。
- VRAMは重み、KVキャッシュ、活性化関数（アクティベーション）、CUDAグラフで分割して使用します。 サービングにおいてスループットを決めるのは、通常KVキャッシュに残る割り当て分です。
- コンシューマー向けGPUとデータセンター向けGPUでは診断機能が異なります。 ECC、行リマッピング、プロファイリング指標がない場合があります。
- コンテナのCUDAバージョンはホストドライバーが定めた上限を超えることはできません。 イメージをデプロイしたところ起動に失敗した場合は、ドライバーバージョンから確認します。
実際に計測した数値 （第21回、第11回）
| 確認したこと | 結果 |
|---|---|
| サイズ・精度が異なる4つのモデルの生成速度×重み | 計測した帯域幅（250GB/s）の86〜98% |
| 精度を半分に減らすと（bf16からfp8） | 重みは1.7倍小さくなったが、速度は1.54倍（トークンごとに発生する固定費の分だけ恩恵が減少） |
| 入力処理（1,024トークン以上） | 計測した行列積処理量の約75〜80%、同一モデルの生成よりも65〜127倍高速 |
| コンシューマー向けGPU3種のECC・ページリタイア | すべてN/A |
| 行リマッピング | 3種のうち1種のみ値を返却（0とN/Aを区別する必要がある） |
よくある落とし穴
- 計測値をハードウェアの限界値と比較しないこと。 入力処理速度がGPU演算の限界の20倍として出力された際、プレフィックスキャッシュのヒットという誤りに気づきました（第14回、第21回）。
- PCIeの世代がアイドル状態で低下しているのをダウングレードと誤解すること。 負荷をかけてから再度読み込む必要があります（第11回）。
grep Xidのエラー行を突き止めること。 ネットワークカードドライバーのチップリビジョン行と、XidではないGPUドライバーエラーを併せてキャッチします。NVRM: Xidに絞り込みます（第11回）。
4. 層2：KubernetesのGPUスタック
知っておくべきこと
- GPUは拡張リソースです。 整数でのみ要求し、要求と制限（リミット）が同一でなければならず、オーバーコミットや共有はできません。
- スタックは下から上へと積み上げられます。 ホストカーネルモジュール（ドライバー）、コンテナランタイム用ツールキット、デバイスプラグイン（リソースの広告）、ノードラベル（GFD）、モニタリング（DCGM exporter）。GPU Operatorがこれらを一括してインストールします。
- 共有方式によって分離レベルが異なります。 タイムシェアリングはメモリを分離せず、MIGはサポートされているGPUでのみハードウェアレベルで分割し、ソフトウェア方式（HAMiなど）はCUDA呼び出しをインターセプトします（ドキュメント基準、第3回と第10回）。
- GPUを仮想マシンに丸ごとパススルーすることもできます。 このときホストはGPUを使用できないため、コンテナ用と仮想マシン用をノード単位で分割します（第13回）。
- ドライバー、ツールキット、オペレーターの責務を切り分けると、障害分析が迅速になります。 どの層で失敗したかが症状（
nvidia-smiの失敗、PodのPending、コンテナ起動失敗）によって分かれます。
よくある落とし穴
- ホストドライバーをオペレーターがインストールするのか、すでにホストにあるのかを定義しないままオペレーターをデプロイすること。 両者が衝突します（第3回）。
- 新しいCUDAイメージが古いドライバーで起動できないこと。 実際にCUDA 13イメージがCUDA 12系ドライバーで初期化エラー（Error 804）により失敗しました（筆者のテスト、この記事では一般原理のみ）。
- GPU Podがノードメモリ要求量の合計によりPendingになってしまうこと。 GPUに空きがあっても通常のリソース（メモリ）が不足しているとスケジュールされません。待機理由のメッセージを先読みにします。
5. 層3：スケジューリングとマルチテナンシー
知っておくべきこと
- デフォルトのスケジューラーはPodごとに判定します。 複数のPodが同時に立ち上がって初めて意味を持つ作業（分散学習、マルチノード推論）は、一部のみが枠を獲得して互いに待ち続けます。
- ギャングスケジューリングには2つの方式があります。 Kueueは作業単位でクォータを確認し、受け入れられるまでPodを作成せず、Volcanoは別個のスケジューラーがPodグループの最小数を満たせる場合にのみ一括して枠を割り当てます。
- クォータ、借用、返却、プリエムプッションは設計の問題です。 誰が余剰リソースを借りることができ、オーナーが戻ってきたときに誰が追い出されるかをポリシーで定めます。
- LeaderWorkerSetはグループ単位のリカバリを提供します。 マルチノードサービングで1つのランクが消滅すると残りが使い物にならなくなるため、グループ全体を再作成することが基本です。
実際に計測した数値 （第10回、第9回）
| 確認したこと | 結果 |
|---|---|
| 4つのPodを必要とする2つの作業が8つのリソースを奪い合い（デフォルトのスケジューラー） | 60秒間それぞれ2つずつ握ったまま停止（デッドロック） |
| 同じ状況におけるKueue、Volcano | 1つの作業のみを受け入れ、約2〜4秒以内に4つを実行、一部のみが実行された瞬間はない |
| 受け入れられた作業を削除した後に待機中の作業が立ち上がるまでの時間 | Kueue 3.0〜3.6秒、Volcano 3.6〜4.2秒 |
| LeaderWorkerSetでワーカーを1つ削除すると | 同一グループのPod 3個がすべて新しく作成され、他のグループはそのまま（約2秒） |
| LeaderWorkerSetのみでリソースが不足している場合 | リーダーのみがRunningでワーカーはPending、ギャングスケジューリングがない |
よくある落とし穴
- ギャングスケジューリングなしで大規模なジョブをデプロイすること。 リソースを保持したまま互いに待ち合い、クラスターが遊んでしまいます。
- 終了猶予時間（グレースピリオド）を知らずにプリエムプッション・返却時間を測定すること。 追い出されるPodが終了シグナルを無視すると猶予時間（デフォルト30秒）を使い切って終了するため、測定値が猶予時間そのものになります（第10回で実際に遭遇）。
- 「同じ優先順位で同時にサブミットすると順序が決まる」と信じ込むこと。 どちらのジョブが先に受け入れられるかは毎回同じではありませんでした。
6. 層4：LLMサービングエンジン、数値で理解する
この層は最も質問が多く、最も多く計測が行われた場所です。8GBクラスのGPU1枚で1.7Bモデルを使用し、vLLMとSGLangを測定しました（第5回、第14回、第15回）。
知っておくべきこと
- 連続バッチングにより、同時リクエストの重み読み込みコストが分散されます。 そのため、同時実行数を上げると総スループットがほぼ比例して増加し、KVキャッシュ容量のところで頭打ちになります。
- トークンあたりのKVサイズは数式で計算します。
2 × 층 × KV 헤드 × head_dim × 바이트。同時実行数の制限はKV 용량 ÷ 요청당 토큰で見積もります。 - プレフィックスキャッシュは、共通する前半部分の入力処理をスキップします。 システムプロンプトとドキュメントを先頭に固定するサービスにおいて、最もコストパフォーマンスの高い最適化です。
- チャンクプリフィルは、長い入力が他のユーザーのトークン処理を中断させる時間を決定します。
- 量子化には2種類あります。 重み量子化は速度（読み込みバイト数）を、KV量子化は容量（格納するトークン数）を変更します。
- LoRAはベースモデル1つに対して小さなアダプターを載せてサービングします。 同時に使用されるアダプター数とスロット数の関係がパフォーマンスを決定します。
実際に計測した数値
| 確認したこと | 結果 | 記事 |
|---|---|---|
| サーバーログのKV容量 ÷ トークン数 | トークンあたり約114,900バイト、数式の114,688バイトと0.2〜0.3%以内の誤差 | 第14回 |
| 同時リクエスト1から16 | 総スループットが14〜15倍、1リクエストあたりの速度は8〜14%減少 | 第21回 |
| 同時実行32から64（入力512） | 最初に計測したサーバーはスループットが 831 から 787 tok/s に低下し、TTFT（Time to First Token）は 666ms から 5.7秒へと 8.6倍になりました。サーバーを3回再起動したところ、KV容量（22,048 から 26,560トークン）に応じて 2.1～5.7秒の間でばらつきました | 第14編 |
| KV 8bit | 同じメモリで 1.9倍のトークン、長い入力（2,048トークン）同時 16 の TTFT が 4.0秒から 0.94秒に | 第14編 |
| プレフィックスキャッシュ（共通 3,000トークン） | 最初のトークンが 394ms から 28ms に、オフにすると 393ms | 第14編 |
| 長い入力（3,500トークン）が割り込んだときの最大トークン間隔 | チャンク 512トークンで 69ms、2,048トークンは約 227ms、8,192トークンで 445ms | 第14編 |
| 同じテストにおける SGLang のデフォルト動作 | チャンクを 512 に減らしても 472ms（入力全体を処理する時間）、チャンク分割（Chunked Prefill）を有効にして初めて 69ms | 第5編 |
| 両エンジンの純粋なスループット | 同時実行数 1～64 で ±5% 以内（帯域幅に縛られた小さなモデル） | 第5編 |
| LoRA アダプターを使用するリクエストのスループット | リクエスト 48個を基準に約 10%（アダプター1つ）から 12.5%（2つを混在）減少（5回繰り返しの中心値、一度計測した 17.9% はウォームアップが混ざった値）、LoRA を有効にしておくこと自体は無料 | 第15編 |
| アダプター 3個を 2つのスロットでサービング | スロット 4個のときの 56% にスループットが低下 | 第15編 |
| サーバーの再起動 | 35～55秒（重みのロード 4～6秒）、初回起動はコンパイルのため 71秒 | 第14編 |
現場のルール
- 同時実行数の上限は、KV が保持できるリクエスト数の近辺に設定します。 超えるとスループットは増えず、TTFT のみが増加します。
- TTFT は p95、トークン間隔（ITL）は p99 を確認します。 中央値は問題なくても裾野が大きくなります（ITL p99 223ms）。
- エンジンを比較する前にデフォルト設定を合わせます。 同じ名前のオプションでもデフォルト値が異なります（チャンクサイズ、チャンク分割、メモリ設定）。
- プレフィックスが重複するリクエストは同じインスタンスに送信します。 キャッシュはインスタンス内に存在します（第8編、ドキュメント基準）。
7. レイヤー 5：ネットワーク
知っておくべきこと
- サービス数が増えると iptables のルールが増加します。 Cilium の eBPF はルールの代わりにマップ参照によってサービスの負荷分散を行います。
- サービスメッシュはリクエストごとにプロキシホップを追加します。 LLM サービングでは最初のトークンまで数百 ms かかるためわずかですが、トークンごとにストリーミングする応答や短い呼び出しでは表面化する可能性があります。
- GPU 間通信は別レイヤーです。 NCCL が集合通信を行い、ノード間では RDMA（InfiniBand または RoCE）が CPU をバイパスします。
- RDMA のよくある障害は設定です。 固定メモリの制限（memlock）、MTU の不一致、GID の選択、PFC・ECN。
実際に測定した数値 （第2編、第7編）
| 確認したこと | 結果 |
|---|---|
| Istio サイドカー（mTLS） | リクエスト 1回あたり約 2.2ms 追加。暗号化は約 8%、残りがプロキシであり、そのうち HTTP 解析は約 39%（解析のない L4 にしても +1.35ms が残る）。gRPC は +3.4ms、100MiB の応答はスループットが 3.5～4.5倍低下、ストリーミングイベントの間隔（20ms）への影響なし |
| conntrack の制限を超える同時接続 4,000個 | 制限 2,048 から 1,913個成功（= 制限 - 既存のエントリ）、残りは拒否されることなく静かにドロップ |
| サービス 1万個の直後に新しいサービスへ接続 | kube-proxy 側で 45秒（2回に1回）、Cilium 側で 0.25秒 |
| iptables のルールが 11万行 | 同一ノード内の新規接続の平均遅延は約 0.05ms の増加にとどまる（通念より小さい） |
| ソフトウェア RDMA（rxe） | 同一マシンの TCP の方が RDMA 書き込みより約 8倍高速（概念確認用）、イーサネット MTU 1500 で active_mtu 1024 |
| 一般ユーザーの固定メモリ制限 64・1,024KiB | 1MiB のメモリ登録が Failed to create MR で失敗、8,192KiB から成功 |
よくある落とし穴
- 「iptables はサービスが多いと遅い」をデータパスの遅延としてのみ理解すること。 この環境で差が大きかったのは、ルールを一括して更新するタイミングでした。
- 同じ値が繰り返し出てくるテーブルを信じ込むこと。 接続試行の制限が測定値を 2つの値に固定してしまったことがあります（ツールの解像度を疑います）。
8. レイヤー 6：ストレージとモデルデプロイ
知っておくべきこと
- 重みのサイズは
파라미터 수 × 바이트です。 70B bf16 の場合 140GB になるため、ノードごとにダウンロードしないよう共有キャッシュやイメージ戦略が必要です。 - コールドスタートは、イメージの取得、モデルの取得、ロード、コンパイル、ウォームアップの合計です。 オートスケーリングの設計では、この合計が新しい Pod がトラフィックを受け付けるまでの時間になります。
- KV を GPU の外（CPU、ディスク、リモート）に退避させると、プレフィックスをより長く再利用できます。 ただし、ロード時間が再計算より短い場合のみ効果があります。
- 重みの暗号化はストレージからの流出や改ざんを防ぎますが、実行中のメモリは保護できません。
実際に測定した数値 （第8編、第16編、第14編）
| 確認したこと | 結果 |
|---|---|
| GPU に収まりきらない 10個のドキュメント（約 5万トークン）を同じ順番で再読み込み | LMCache（CPU オフロード）により TTFT が 576ms から 48.6ms に、初回の読み込み時に保存コストが約 4% |
| LMCache の CPU 容量がワーキングセット（約 1.49GB）より小さい場合 | 効果なし（0.5GB、1.0GB ではヒット 0）、1.5GB で 600ms が 39ms に（ヒット率 98%）。コンテキストが長いほど効果が高く、6,414トークンでは約 19倍 |
| 損益分岐点のヒット率 | 約 4%（そのテストの値で計算） |
| AES-256-GCM による重みファイルの暗号化 | ファイルサイズの増加は約 0.00005%、復号 0.78～0.95 GB/s（純粋な計算処理は 1.8～2.2 GB/s） |
| 暗号文の 1バイトの改ざん、チャンク順序の入れ替え | どちらも復号を拒否（InvalidTag）。AAD がないと入れ替えや切り詰め、ファイル間のチャンクの入れ替えを検知できない |
| AES のハードウェアアクセラレーションをオフにした場合 | 復号が 4～7倍遅くなる（2.0 から 0.47、0.29 GB/s）。スレッドは 2つで頭打ちになるが、プロセスは 8つまで拡張 |
| 復号した重みをメモリボリュームに配置してサーバーを起動（0.6B モデル） | 復号に約 2.3秒がかかり、サーバーの準備時間（約 28秒）の前に加算される。改ざんされたファイルはサーバー起動前に拒否される |
| 実行中の LoRA アダプターのロード（6.4MB） | サーバーの再起動なしで 0.2秒以内（ドキュメントでは本番環境での使用に警告あり） |
9. レイヤー 7：観測性と障害診断
知っておくべきこと
- GPU の指標には 3つのレイヤーがあります。 ハードウェア（DCGM：使用率、電力、温度、クロック制限の理由、XID）、サーバー（キュー、KV 使用率、プリエムション数）、サービス（TTFT、ITL、エラー率）。
- 使用率だけを見ると誤解が生じます。 メモリ帯域幅に縛られたサーバーは、使用率が高くても演算をほとんど行えていない場合があります。
- XID は GPU ドライバーがカーネルログに記録するエラー番号です。 一般アカウントでは
dmesgがブロックされている可能性があるため、journalctl -kを使用します。 - Cilium と DCGM の指標は多く、カーディナリティがコストになります。 ラベルの組み合わせが時系列データの数を決定します（第17編、第18編）。
- アラートは、症状（TTFT のテールレイテンシ）と原因（VRAM の傾向、クロック制限）を分けて設定します。
- 1つのリクエストを追跡するシグナルがトレースです。 vLLM はリクエストごとに 1つのスパンに待機、プリフィル、デコードの時間を属性として記録し、これだけで遅いリクエストが待機によるものか計算によるものかを切り分けることができました。有効化するコストは誤差の範囲内であり、遅いリクエストを記録するには確率サンプリングではなくテールサンプリングが必要でした（第25編）。
よくある落とし穴
- N/A と 0 を同じものとみなすこと。 サポートされていない指標は 0 ではなく N/A として表示されます（第11編）。
- サーバーの再起動ごとに KV 容量が変化することに気づかず、メモリの数値で比較すること。 トークンあたりのバイト数で比較します（第14編）。
10. レイヤー 8：コントローラーとデプロイ自動化（Kubernetes エンジニアのツール）
知っておくべきこと
- レベルベースの調整。 イベントではなく現在の状態を読み取り、望ましい状態と比較して一致させます。イベントを取り逃がしても次回の調整で修正されます。
- べき等性。 すでに一致している場合は何も書き込まないようにする必要があります。
- オーナー参照と finalizer。 子リソースは所有者が削除されるときに一緒にクリーンアップされ、finalizer はクリーンアップが完了して初めて削除を許可します。
- CRD はスキーマとバリデーションが設計の要です。 単純なルールには CEL、複雑なルールには Webhook を使用します。
- GitOps では、Git に記述されたフィールドを他のコントローラーが変更すると競合が発生します。 HPA と
replicas,ignoreDifferences（第9編）。
実際に測定した数値 （第9編）
| 確認したこと | 結果 |
|---|---|
| CEL による検証 | 空文字列のモデル名は作成段階で model must not be empty として拒否 |
| LWS（Lavoro/LWS）のローリングアップデート | 序数の大きいグループから 1グループずつ（maxUnavailable がデフォルト 1） |
オペレーターが実際に動作する挙動（子リソースを削除したときの復旧時間、べき等性、finalizer、重複実行、リトライ）については、第9編で実際にテストした結果を続けて反映する予定です。
11. 測定方法：全レイヤーを貫通する技術
連載の中で最も価値があるのは数値ではなく、 数値を疑った瞬間でした。
| 直面した出来事 | 教訓 |
|---|---|
| 入力処理が GPU 演算限界の 20倍の値で出力される | ハードウェアの限界値と比較してみる 同じ文章を繰り返したことでプレフィックスキャッシュがヒットしていたためだった |
| 「同時実行 1、16」が実際には 3倍の 48個のリクエストだった | ツールの引数が何をするものかを確認する。 表記と実際ののリクエスト数を一致させる |
| 同じ値が繰り返し表示されるテーブル | 測定ツールの解像度を疑う |
| 終了猶予期間 30秒がプリエムション時間に混入する | 測定したい時間以外の時間が混入していないか確認する |
ヘッダー行のみを残す grep によって結果が表示されなくなる |
結果を隠してしまうフィルターを使用しない |
| root で行ったテストで障害が再現しない | 再現させたい条件（一般ユーザー）でテストを行う |
| 両エンジンの同じ名前のオプションのデフォルト値が異なる | 比較する前にログで設定を一致させる |
そして、3つの習慣を身につけます。 リクエストごとに異なる入力を使用する, 繰り返しと分散（1回の計測値で断定しない）、 環境と方法を数値の横に記録する.
12. 4週間の学習ロードマップ
独学する場合はこの順序をおすすめします。各週の成果物は 自分で測定した 1つのテーブルです。
| 週 | テーマ | 試してみること | 成果物 |
|---|---|---|---|
| 1 | GPU とサービングエンジン | 小さなモデル（1～2B）を vLLM で起動し、サイズ・精度別の生成速度に重みのバイト数を掛けて帯域幅と比較する | 「速度 × 重み vs 帯域幅」の表 |
| 2 | 負荷とキャッシュ | 同時実行数を 1 から 64 まで増やしながらスループット、TTFT p95、ITL p99 を測定し、KV容量の式とパフォーマンスが低下するポイントを突き合わせる。プレフィックスキャッシュの有効化・無効化 | 同時実行数の曲線と KV の計算 |
| 3 | Kubernetes の GPU とスケジューリング | 使い捨てクラスターでダミーの拡張リソースによりデッドロックを発生させ、Kueue と Volcano で解決する。コントローラー（kopf 等）を自作して子リソースの削除復旧時間を測定する | デッドロックの再現と解決、復旧時間 |
| 4 | 観測性、障害、セキュリティ | DCGM の指標を読み取り、N/A と 0 を区別するダッシュボードの作成、XID アラート規則、重みの暗号化・復号速度の測定 | 指標リストとアラート規則のドラフト |
使い捨ての環境（仮想マシンの k3s、一時的な Pod）でのみ行い、終了したら削除します。本番サービスで使用しているクラスターで最初に試さないようにします。
13. 現場や面接でよくある質問
- LLM のトークン生成速度の上限はどのように見積もるか？ メモリ帯域幅 ÷ 重みバイト。4つのモデルで測定した帯域幅の86〜98%となった。
- サーバーの同時リクエストの制限は？ KVキャッシュトークン数 ÷ リクエストあたりのトークン。これを超えるとスループットは向上せず、TTFTが8倍に跳ね上がる。
- プレフィックスキャッシュの効果が大きいのはどのような場合か？ 共通のプレフィックス部分が長いサービス。3,000トークンで最初のトークンが394msから28msに短縮された。
- 長い入力が他のリクエストをブロックするのをどのように軽減するか？ チャンクプリフィルのチャンクを減らし、エンジンのデフォルトの動作（混雑したチャンクかどうか）を確認する。
- GPUの処理が停止しているのにGPUが空いている。なぜか？ ギャングスケジューリングなしで一部のポッドのみがリソースを獲得した（デッドロック）、または一般リソース（メモリ）が不足してPendingになっている。
- ギャングスケジューリングをどのように実装するか？ Kueueはワーク単位の承認、Volcanoはポッドグループの最小数。
- GPUの共有方式は？ タイムスライシング（メモリ分離なし）、MIG（ハードウェア分離、サポートするGPU）、ソフトウェア方式（呼び出しのインターセプト）。
- コンテナが起動しない。CUDAイメージとドライバは？ コンテナのCUDAはホストドライバの上限を超えることはできない。
- サービスメッシュの遅延コストは？ この環境ではリクエストあたり約2.2msで、そのうち暗号化は約8%。
- LoRAアダプターを複数サービングする際の注意点は？ 同時に使用されるアダプターの数とスロット数。スロットが不足するとスループットが半分程度になる。
- 重みを暗号化すると何が保護されるか？ ストレージの漏洩と改ざん。実行中のメモリは保護できない。
- オペレーターでイベントを取りこぼすとどうなるか？ レベルベースの調整（Reconciliation）が現在の状態を再読み取りして一致させる（タイマーや再同期が復旧させる）。
- パフォーマンスのテスト結果がおかしいとき、最初にすべきことは？ ハードウェアの限界と比較する。
14. このマップが扱わないもの
- トレーニング（学習）インフラ。 分散学習（データ並列、テンソル・パイプライン並列）、チェックポイント、データローダー、学習中の障害復旧はこの連載では測定していません（未計測）。
- データセンターGPU、NVLink・NVSwitch、InfiniBandの実機、数百ノード規模のスケジューラのスループット。
- 大規模モデル（数十B以上）とマルチGPUサービングの数値。この記事のサービングの数値は1.7Bの単一モデルです。
- サービング以外のMLプラットフォーム（特徴量ストア、実験管理、パイプラインオーケストレーション）。
参考：このマップの根拠となった記事
第2部（ハイブリッドGPUクラスターとネットワーク）、第3部（GPU Operator）、第4部（LLM推論とvLLM）、第5部（vLLMとSGLang）、第6部（分散推論）、第7部（RDMA）、第8部（ストレージとKVオフロード）、第9部（CRDとオペレーター）、第10部（マルチテナントスケジューリング）、第11部（GPU障害診断）、第13部（GPUパススルー）、第14部（vLLM負荷とKVキャッシュ）、第15部（LoRAサービング）、第16部（重み保護）、第17部（DCGM指標）、第18部（Cilium指標）、第21部（速度の原理）。
確認した日付
2026-10-07基準。数値は各記事の「確認したバージョンと日付」に準拠します（vLLM 0.31.0、SGLang 0.5.21、Kueue 0.20.0、Volcano 1.15.3、LeaderWorkerSet 0.11.1など）。