推論基盤のパフォーマンス検証と最適化戦略

第3回 vLLM roundup Community Meetup Tokyoの登壇資料
https://ossbyredhat.connpass.com/event/383638/

当日利用しなかった補足資料なども追加してあります

Transcript

1. (C) SAKURA internet Inc. © SAKURA internet Inc. 推論基盤のパフォーマンス検証と 最適化戦略 さくらインターネット株式会社 道下幹也
2. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 2 ⾃⼰紹介 道下 幹也（Mikiya Michishita） さくらインターネット インフラエンジニア 担当業務： • ベアメタル型GPUクラウドサービス「⾼⽕⼒PHY」の インフラ設計・構築・性能調査 • 先端技術の調査・検証 • GPUを中⼼とした技術のサポート等 略歴 : • 2025/08-現在 さくらインターネット • 2019-2025/07 ヤフー → LINEヤフー https://speakerdeck.com/aztecher/distributed- inference-serving-vllm-lmcache-nixl-and-llm-d https://knowledge.sakura.ad.jp/author/mikiya_michishita
3. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 3 Agenda • 推論基盤の課題と最適化戦略 • パフォーマンス検証例 - PD-Disaggregation • パフォーマンス検証例 - KV Cache Reuse
4. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 4 推論基盤の課題と 最適化戦略
5. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 5 推論基盤を考える上での現実的な課題 「推論基盤」といっても⽬指すビジネスモデルによってインフラ要求は⼤きく違う ① どのようなビジネスモデルを⽬指し、どのLLMモデルを選択し基盤として展開・利⽤するか → 企業としての戦略・ロードマップに依存。これがないと適切なリソース・コストの議論はできない ② 現在・将来のビジネス規模に応じ、どのようなインフラを⽬指し、リソースを最適化するか → この部分が今回の前半の議論の中核 モデルをサーブする推論インフラへの要求やコストの⾒積もりが難しい 推論で⾼スペックなGPUは不要 CPUなどでも動く！ 推論でも⾼スペックGPUは必要！ ストレージなども今後重要に！ いずれの意⾒も事実ではあるが… • 実現したいビジネスモデル • ⽬標とするサービス規模やユーザ体験 この視点に違いが出ていて意⾒が合わない
6. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 6 「ユーザ体験」に基づく最適化戦略 最も重要なのはサービスを利⽤するユーザの体験を損ね ないこと →「ユーザ体験」を定義し、それを基準に最適化する → SLO（SLA）の設計と継続的な計測に基づく最適化 LLM Inference System GPU GPU SLO（SLA）-based Optimization Loop SLO（SLA) Compliance Low Cost SLO（SLA）を設計する SLO（SLA）を維持しながら コストの最⼩化を狙っていく
7. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 7 ユーザ体験の定義に利⽤可能な指標 指標 種類 説明 TTFT （Time-to-First-Token） Latency ユーザーリクエストを送信してから最初のトークンを受信するまでの時間 ITL （Inter-Token Latency） Latency 連続する2つのトークン間の間隔の平均 E2EL （End-to-End Latency） Latency ユーザーリクエストを送信してから、最後のトークンを受信するまでの時間 RPS （Request Per Second） Throughput LLMが1秒間に処理するリクエスト数の総数 TPS （Tokens Per Second） Throughput LLMが1秒間に処理するトークン数の総数 Goodput Latency + Throughput Latency要件を満たす、 LLMが1秒間に処理するリクエスト数の総数 ＊各種メトリクスの詳細は補⾜資料を参照
8. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 8 ユーザ体験の分析とシステム最適化のループ LLM Inference System GPU GPU ユーザワークロード 傾向・負荷分析 リソース・システム 最適化判断 • ユーザリクエストの傾向・負荷の分析 • SLO（SLA）ベースの分析 直近の動向に加え今後の予測を⽴てられるとなお良い 負荷傾向やSLO（SLA）などの指標に基づき 追加の投資やシステムの再構成を検討する • GPUのリソースを増やす・減らす • Aggregated → PD Disaggregation等に構成変更 • Prefill / Decode 各リソースのバランス調整 • KV Cache Storage等の検討 • …etc SLO（SLA）を満たしつつ、コスト最⼩化を狙う
9. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 9 最適化には技術的知⾒と「全体最適化」が必須 LLM Inference System GPU GPU ユーザワークロード 傾向・負荷分析 リソース・システム 最適化判断 正しく最適化を⾏うためには様々な技術に対しての 理解、 コスト感覚、実測が不可⽋ • どの指標に対しての最適化なのか • どのような技術が選択でき、改善幅はどの程度か • 最適化による追加コストに妥当性があるか さらにAIシステムの最適化においては • アプリケーションやフレームワーク、通信ライブ ラリ⾃体の動作原理の理解 • サーバ構成やネットワークなどのインフラの理解 を基軸とした「全体最適」が必須になる
10. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 10 パフォーマンス検証例 PD-Disaggregation
11. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 11 疑問: PD-Disaggregationのコスト効果 PD-Disagg構成ではP/D向けにGPUを分離 → GPUの利⽤枚数は増え、コストも増える → ⾼速伝送路（NVLink・インターコネクト等）も欲しい これらのコスト的な要求に直⾯すると疑問が出てくる • ⼩規模な環境でもPD-Disagg構成がいいのか？ • コストに資するほど明確にメリットが出そうか？ → 1台のサーバ規模で検証を⾏う （NVLinkは利⽤、インターコネクトは使わない規模） https://developer.nvidia.com/blog/introducing-nvidia-dynamo- a-low-latency-distributed-inference-framework-for-scaling- reasoning-ai-models/ ＊ PD-Disaggの期待効果については以下の資料を参照して下さい 分散推論基盤やその前提の考え⽅ 〜⾼⽕⼒ PHYで作る分散推論基盤 vol.1〜
12. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 12 PD-Disaggregation検証構成 Aggregated構成 • 4GPUを全て割り当てる Disaggregated構成 • 2GPUをPrefill / 2GPUをDecode • Disagg構成⽤のProxyを利⽤ • LMCacheによる KVCache転送 合計で4枚利⽤するという点は同じ → リソースコストの側⾯でフェアに した上で、Agg vs.Disaggを⽐較
13. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 13 測定結果（ITL / ISL=8k, OSL=1k, GPU=4） Aggregated（4GPU） • 並列度の上昇に伴い、達成可能なTail- Latencyの値が落ちる Disaggregated（P=2GPU / D=2GPU） • 並列度の上昇に伴って全体的なLatency はすこし悪くなるが、Tail-Latencyを維 持する このグラフから、32同時接続（8k1k）では • (Agg) P99を100ms以内に収められない • (PD) P99を30ms以内に収められる SLOを定める視点からこの違いは⼤きい
14. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 14 PD-Disaggの効果 PD-Disagg構成がITLのTail-Latencyに与える影響はかなり⼤きい • SLOとしてITLのTail-Latencyを指標として利⽤する場合、SLOを満たすためには⾮常に強⼒な⼿法 • Aggでは、ユーザ数の同時接続数がスポットで増えただけでバイオレーションする可能性もある • PD-Disaggでは、上記のようなケースはケアできそう • ⼀⽅で恒常的にユーザワークロードが⼩規模な場合はメリットが薄く、Aggで良いケースも⼗分ある ⻑い⼊⼒を伴うユーザワークロードが継続的に発⽣する環境において、SLOの定義にITLをもとにした指標を 組み込んでいる場合は、⼩規模環境（サーバ1台規模）でもPD-Disagg構成にする⽅が望ましい ＊ TTFTに関する議論については、詳細なベンチマークパラメータとともに補⾜事項に簡単にですが記載しています
15. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 15 パフォーマンス検証例 KV Cache Reuse
16. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 16 疑問: KV Cache Reuseによる効果 KV Cacheを共有ストレージに格納し再利⽤する技術が 普及してきている KV Cacheをうまく再利⽤できると、Prefillにかかる計 算コストを削減できる 対して疑問として • メインメモリやローカルストレージはともかく、 リモートストレージの効⼒がどれくらいか？ • KV Cacheのヒット率と性能はうまく相関するか？ → リモートストレージを模擬してKV Cacheヒット率 を変化させながら検証 LLM Prefill Decode LLM Prefill Decode KV Cache Store Output Input Output Input Same Prefix + α
17. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 17 測定内容 - KV Cache Reuse 同⼀vLLMインスタンスでの再利⽤ ① 設計したContext（8k）をリクエス トし、Storageにストアさせる ② 2回⽬以降のリクエストでは、初回 リクエストのPrefixとマッチする量を 変化させたContext（8k）を設計して 性能を測定 モデルはgpt-oss-120b、GPUは2枚 KV Cache StoreとしてはMoonCake Storeを別サーバ上で起動し利⽤
18. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 18 測定内容 - KV Cache Share 異なるvLLMインスタンスでの再利⽤ ① 設計したContext（8k）を Instance 1にリクエストし、Storage にストアさせる ② 2回⽬以降のリクエストでは、初回 リクエストのPrefixとマッチする量を 変化させたContext（8k）を設計し、 Instance 2にリクエストして性能を測 定 採⽤技術や設定はReuseと同じだが、KV Cacheを使い回すvLLMインスタンスが別
19. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 19 測定結果（TTFT / ISL=8k, OSL=1k, GPU=2） 8k⼊⼒のうち、全くKV Cacheにヒットし ないケースではTTFTは350+ms程度 1k, 2k, 4k, 8kと段階的にヒット率を上げて いくことで、最⼤1.75倍程度削減できている （200+ms程度） KV Cacheの再利⽤によって、TTFTの性能 に明確な改善が⾒られる
20. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 20 KV Cache Reuse / Sharingの効果 KV Cacheの再利⽤は、うまくキャッシュヒットするとTTFTを改善する • Tailも含む全体的なTTFTの性能向上に寄与する • ワークロード規模などに依存せず効果があるが、理論上Prefixの前⽅⼀致性に強く依存する • 実際はCache Blendなどの技術と併⽤することになる 業界の動向としてコンテキストは⻑くなる傾向にあり、システム的にはPrefill処理が重くなる • 今後、最適化の上では外せなくなってくる可能性が⾼い技術の⼀つ KV Cacheの使い回し⾃体はシステム規模やワークロード規模に関わらず有効だが、コストメリットを出す ためには、ある程度のユーザワークロードを受け⼊れる環境が望ましい • ストレージコスト、およびストレージへの⾼速通信のためのネットワークコストがかかる • （KV Cacheの再利⽤をしない場合は、KV Cache再計算によるGPUコスト等がかかることを勘案する）
21. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 21 おわりに
22. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 22 おわりに • 推論インフラにおいて「ユーザ体験」を基軸とした最適化戦略が重要 • 「ユーザ体験」を反映するSLO（SLA）の定義 • SLO（SLA）をベースとする継続的な最適化 • 「最適化」を⾏う際には技術への理解、実測による検証、コスト感覚などが重要 • AIシステムの最適化には「全体最適」が不可⽋ • 特定ドメイン領域の知識のみでは不⼗分 • ベンチマークによる検証の重要性 • 最先端の技術が常に⾃⾝のインフラで適切とは限らない • どのような事業フェーズ、ユーザ規模、SLO（SLA）定義か、など複合的な状況のもので、適切な技 術を選び取る必要がある • これを⾏う為には、理論も⼤切だが、実測による理解も⼤切
23. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 23 補⾜資料
24. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 24 ユーザ体験を反映する性能指標（Latency） • TTFT：ユーザーリクエストを送信してから最初のトークンを受信するまでの時間 • TPOT（ITL）：連続する2つのトークン間の間隔の平均 • E2EL：ユーザーリクエストを送信してから、最後のトークンを受信するまでの時間
25. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 25 システムの性能指標（Throughput） • RPS：LLMが1秒間に処理するリクエスト数の総数 • TPS：LLMが1秒間に処理するトークン数の総数
26. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 26 • Goodput：Latency要件を満たす、 LLMが1秒間に処理するリクエスト数の総数 ユーザ体験とシステム性能を織り込んだ指標（Goodput） Throughputが⾼くても、Latency要件 を満たすとは限らないため、両⽅を織 り込んだ指標 投下コストに対して「Throughputを改 善できるがLatencyの改善が限定的」 のような落とし⽳を回避するなどに利 ⽤できる Throughput is Not All You Need: Maximizing Goodput in LLM Serving using Prefill-Decode Disaggregation
27. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 27 システム性能に対するコストを直接的に評価する指標 ランニングコストに対する効果を検討する上で参考と なる⼀⽅で、導⼊時の初期投資⾦額や、⾃社サービス の抱えるワークロード負荷などを織り込んで総合的に 判断すべき指標でもある サービス提供者としては⾃⾝のサービスの費⽤対効果 を測る上で⾒ておきたい指標 LLM Inference System GPU GPU • Tokens / Dollar：1ドルコスト*あたりのトークン⽣成量 • Tokens / User / Dollar：1ドルコスト*で、1⼈のユーザに対してどれだけトークンを⽣成できるか * 「1ドルコスト」は⽣成AIを提供するインフラ・電気代等も全て織り込んだコスト Tokens / 1ドルコスト
28. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 28 システム性能以外の重要な指標 - モデルの精度 今回の話は「システムの性能がユーザ体験を損ねない程 度に⼗分か？」という指標 ⼀⽅でユーザはこれ以外にも「欲しい結果を返してくれ る」などの「精度」のような評価軸も存在する ビジネス戦略・ロードマップの策定などにおいては、こ の変量も織り交ぜた判断が求められる Model A GPU GPU GPU Model B 取り扱うモデルによって 推論基盤への要求も「⼤きく」変わる モデルの違いによって精度も⼤きく変わる ◎ ×
29. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 29 最先端の技術・動向とのギャップ 推論技術は最先端の世界の動向を反映して⽇々進化しているが、我々が置かれた状況とはあまりに違う • ハイエンドGPUを⼤量に横展開した推論基盤 • GPUメモリドメイン拡張技術（NVLink-C2C、Scale Up Network） • 推論向け⼤規模コンテキストストレージ いずれも⼤規模な推論インフラを展開する企業にとっては重要な技術 ⼀⽅、現時点での国内のレベルの規模では費⽤対効果が出るか否かは慎重に⾒極める必要がある このような業界内のギャップを適切に判断する為にも、技術的な理解、コスト感覚をもちつつ、今回話した ような最適化戦略をとるのがよいのではないかと考えている ⼀⽅で、将来的な動向の変化（Agentic AIの普及・拡⼤）を⾒据えた戦略の検討も必要かもしれない
30. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 30 PD-Disagg検証時のベンチマークパラメータ 近年のコンテキスト⻑の増加傾向を反映（8k⼊⼒） 同時リクエスト数は可変（1 ~ 32）とし、常にリクエス トが到達するようなユーザワークロードを収容するシ ステムを模擬 同時接続数を上げるほど、AggではPrefillとDecodeの 処理が競合し、ITLが悪くなることが想定される。 PD-Disaggの導⼊可否検討などのデータをとることに は適しているが、TTFTの値は作為的に上昇するため取 り扱いには注意が必要 --request-rateと--burstinessを調整して測定していく ことでより網羅的なデータ分析もした⽅が良い vllm bench serve Parameter Description --dataset-name random Random Datasetの利⽤ --random-input-len 8192 8k ⼊⼒ --random-output-len 1024 1k 出⼒ --request-rate inf 常にmax_concurrency分の リクエストをかけ続ける --burstinessは無視される --max_concurrency ${CONC} 最⼤同時接続数（1 ~ 32） --num-prompts ${CONC x 10} Concurrency x 10
31. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 31 測定結果（TTFT / ISL=8k, OSL=1k, GPU=4） 並列度が2までならAggが良い それ以上になるとPDの⽅が全体的な Latency値がよいが、Tail-Latencyで⾒ると 同程度か、場合によっては悪くなる Aggで平均的に悪い理由としては、P/Dの混 在によるDecode側処理の遅延に、Prefillも 引きづられているからではないかと推察 （常にリクエストが来るベンチマーク設計な ので顕著に⾒えていると想定される） ITLの測定時に同時TTFTについても測定して いたものをプロットしたグラフ
32. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 32 Mooncake Store LLM推論シナリオ向けに設計された Distributed Key-Value Cache Storage Engine • 複数サーバ上で起動し、KV Cache向けの分散メモリプールを構築できるOSSのソフトウェア • NIXL、LMCacheと連携可能 今回の試験では以下の理由からMooncakeを利⽤した • 外部ストレージへのKV Cache転送の測定に帯域ペナルティを⼊れたくなかった • ⾼帯域のNICを利⽤でき、RDMAで書き込めるストレージが欲しかった • これに該当するエンタープライズストレージを検証環境上に簡単に⽤意できなかった • 幸いインターコネクト経由で検証⽤のサーバが繋がっていたためこれを利⽤することにした Mooncake⾃体の細かい検証等は今後余裕があれば検討
33. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 33 TTFTにおけるKV Cache読み込みコスト 先の検証において、TTFTに占めるKV Cache読み込みコストがどの程度かをプ ロットした ほぼ全てキャッシュヒットするケース （8k）でもKV Cacheの読み込みに占める 時間が1/4程度になっているのはやや疑問が 残る この件については要調査事項としている
34. (C) SAKURA internet Inc. (C) SAKURA internet Inc. 34 KV Cacheの再利⽤に関する議論 KV Cacheの再利⽤性はワークロードやプロンプト構成などで⼤きく異なる • ⾼再利⽤性 = マルチターンチャット、カスタマーサポート等 • システムプロンプトを除き、ユーザとAIの過去の対話履歴がそのまま保持される • 新たな質問によって、過去の履歴は「Prefix」として扱われキャッシュヒットする。 • 低再利⽤性 = RAG、ユーザ定義プロンプト（テンプレートプロンプト） • 動的に取得されたコンテキストがプロンプトの中間に挿⼊されるとそこから再計算になる Agenticワークロードなどにおいても、各エージェントのプロンプト冒頭にロール固有のプロンプトが差し 込まれるケースがあり、この場合はPrefixが異なるため再計算になってしまう。 CacheBlendなどの技術による解消