@2025__さくらのナレッジ__分散推論基盤やその前提の考え方

# 分散推論基盤やその前提の考え方〜高火力 PHYで作る分散推論基盤 vol.1〜「高火力 PHY で作る分散推論基盤」連載の第 1 回。著者は [[道下幹也]]（[[SAKURA Internet]] クラウド事業本部）。LLM 推論の基礎概念・性能指標体系・バッチ戦略・Prefill-Decode 分離(PD分離)・KV Cache 設計の考え方を解説する。(Source: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) --- ## LLM 推論リクエストの特徴一般的な Web アプリケーションと異なり、LLM 推論リクエストには次の特徴がある。 - ユーザーが任意に入力する自然言語であること - レスポンスもユーザー入力に大きく依存すること - リクエストが任意のタイミングで到着することこれらの性質により、システムの負荷特性が各ユーザー入力に依存し、通常より最適化が難しい。高価な GPU リソースを前提とする推論基盤ではこの問題は無視できず、「実際のユーザーワークロードの特性を解析し、その負荷特性に従って最適化する」アプローチが有効になる。(Source: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) --- ## 性能指標体系従来の Web サービスではレイテンシとスループットが主な指標だったが、LLM 推論ではより細粒度な指標が必要になる。(Source: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) ### レイテンシ指標 | 指標 | 正式名称 | 意味 | |------|---------|------| | TTFT | Time to First Token | 最初のトークン受信までの時間 | | ITL | Inter-Token Latency | 連続する 2 トークン間の平均間隔 | | TPOT | Time per Output Token | TTFT 除外後の平均生成時間 | | E2EL | End to End Latency | リクエスト送信から最終トークン受信までの時間 | ### スループット指標 | 指標 | 正式名称 | 意味 | |------|---------|------| | TPS | Tokens per Second | 1 秒間に処理するトークン数 | | RPS | Requests per Second | 1 秒間に処理するリクエスト数 | ### Goodput 「レイテンシ要件を満たすスループット」を示す指標。スループットが高くても [[サービスレベル目標]](SLO)を達成できない場合があるため重要である。例えば秒間 10 RPS を達成するシステムでも、TTFT 200 ms 以下・ITL 50 ms 以下の制約では Goodput が秒間 3 RPS に低下する可能性がある。(Source: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) --- ## KV Cache と Prefill/Decode の二段構造 LLM 推論では以下のプロセスが繰り返される。 1. ユーザーリクエストに基づいて計算を実行 2. トークンを 1 つ生成 3. 生成トークンを入力末尾に追加 4. 再度同様の計算を実行各イテレーションでの計算結果(Attention 演算結果)は再利用可能であり、この計算結果のキャッシュが「KV Cache」である。初回計算でユーザー入力トークンに対する KV Cache が生成され、以降の生成トークンの計算結果も追加でキャッシュされる。(Source: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) KV Cache の読み書きに伴うメモリ操作が GPU 処理の支配要因となるため、推論処理は以下の二段に分かれる。 - **Prefill**: 初回処理。入力トークン全体を一括処理し KV Cache を生成する。**計算バウンド**であり TTFT に対応する。 - **Decode**: 以降のトークン生成処理。KV Cache を読み書きしながら逐次トークンを生成する。**メモリバウンド**であり TPOT/ITL に対応する。この段階差は推論最適化と観測設計の出発点となる([[LLM推論]])。(Source: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) --- ## バッチ戦略 4 種 GPU 利用効率を高めるためにバッチ処理が用いられる。4 種の戦略が存在する。(Source: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) ### Static Batching 最もシンプルなバッチ処理方式。一定数のリクエストが蓄積されるまで待機してからまとめて処理する。 ### Dynamic Batching タイミングウィンドウを設定し、その期間内に到着したリクエストをまとめて処理する。 ### Continuous Batching 同一バッチ内の各リクエストは完了後、新しいリクエストに即座に置き換えられる。GPU 利用効率を最大化できる LLM 推論に適したバッチ戦略である。 ### Chunked-Prefill Prefill 処理を複数のチャンクに分割して処理する。ただし ITL のテイルレイテンシの改善は限定的にとどまる可能性がある。 --- ## Prefill-Decode 分離(PD 分離) ### 概要 Prefill 処理を行う GPU と Decode 処理を行う GPU を物理的に分離する構成。(Source: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) ### 利点 - Prefill と Decode が同一バッチに混在しなくなる - ITL(TPOT)のテイルレイテンシが改善される - GPU リソースの追加投下で性能がスケールすることが期待される - ユーザーワークロード特性に応じた柔軟な最適化が可能 ### 欠点 - 実装上、必要な GPU 数が増加する - SLO/SLA が明確でない環境や PoC ではメリットよりコストが上回る可能性がある --- ## KV Cache 転送がボトルネック PD 分離の実装において最大の技術的課題は KV Cache 転送である。KV Cache のサイズは非常に大きく、例えば入力 8k トークン・バッチ 1 の場合： | モデル | KV Cache サイズ | |--------|----------------| | Llama-3.1-8B-Instruct | 1.0 GB | | Llama-3.1-405B-Instruct | 3.94 GB | 100 並行リクエストの場合、KV Cache 転送には高速ネットワークが必須となる。インフラ設計の前提として以下が求められる。(Source: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) - **ノード内**: NVLink などのスケールアップネットワーク - **ノード間**: 高帯域 NIC とインターコネクト、GPUDirect RDMA [[高火力 PHY]] は HGX H100(H100 GPU × 8、NVLink 接続、400 Gbps NIC × 8)を提供し、こうした要件に対応する。 --- ## 「KV Cache を設計の中心に据える」が定石 LLM 推論基盤では「KV Cache を設計の中心に据えることが定石」となってきており、以下の技術が提案・実装されている。(Source: [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) - **オフロード技術**: GPU メモリ上限を補う KV Cache のオフロード - **キャッシュ共有**: プレフィックスキャッシュなど複数リクエスト間での KV Cache 再利用 - **圧縮技術**: KV Cache の量子化・スパース化 - **ルーティング技術**: KV Cache の局所性を考慮したリクエストルーティング [[vLLM]] はページドアテンション(Paged Attention)による KV Cache のメモリ効率化を特徴とし、業界で急速に標準的地位を確立しつつある推論フレームワークである。 --- ## おわりに本連載のまとめとして著者が強調する重要点は以下の通り。 1. LLM 推論技術は複雑で多様であり、ネットワーク・サーバ・GPU・ソフトウェア全体の理解が必須 2. Transformer の構造と処理についての正しい理解が必要 3. 最新技術が常に有効とは限らず、システム規模や投資計画に基づいた取捨選択が重要 --- ## 関連 - 概念: [[LLM推論]] / [[サービスレベル目標]] - エンティティ: [[道下幹也]] / [[高火力 PHY]] / [[vLLM]] / [[SAKURA Internet]] - 関連ソース: [[@2025__ACM Computing Surveys__Towards Efficient Generative Large Language Model Serving]] - 関連 MOC: [[LLM4SRE - MOC]]