OpenShiftでllm-dを動かそう！

Transcript

1. OpenShiftでllm-dを動かそう！ Red Hat AI SSA Junpei Ishikawa
2. LLMでは⼊⼒された⽂章を元に、逐次的に出⼒処理を⾏います。そのため前の計算結果をVRAMにキャッシュし再利⽤する ことで、計算処理を⾼速化しています。 KV Cache
3. KV Cache
4. 5 • 不均⼀な⼤きさのプロンプトの⼊⼒ • KVキャッシュに強く依存したステートフルな処理 • ⾼コストなGPUリソースでの処理 • 均⼀なリクエストの⼊⼒と振り分け • ステートレスな処理 • 汎⽤的なCPUで⾼速に処理可能 LLM推論の課題：推論のロードバランシング Service Pod 1 Pod 2 Pod 3 Serviceによるロードバランシング Load Balancer Pod 1 Pod 2 Pod 3 LLMの推論におけるロードバランシング GPU KV Cache GPU KV Cache GPU KV Cache KubernetesのServiceでは推論時のステート（KV Cache）を考慮することができないため、推論の効率が悪化します。 LLMの推論を効率化するためにはLLMの特性に合った新たな仕組みが必要となります。 推論を最適化するための LBの仕組みが必要
5. 6 llm-d High Performance Distributed Inference on Kubernetes
 https://github.com/llm-d/llm-d Contributors: Red Hat, Google, IBM, NVIDIA, AMD llm-dはLLM推論を最適化するスケジューラーやKVキャッシュ管理の階層化を提供し、推論パフォーマンスを最⼤化します。 ▸ Kubernetes上にデプロイする 分散推論ソフトウェアスタック ▸ インフラの利⽤効率を最⼤化、 推論スループットを向上 ▸ マルチターンエージェント向けの ⾼速なレスポンスを実現
6. Well-Lit Path llm-dでは確⽴された分散推論のデプロイパターンとしてWell-Lit Pathを公開しています。利⽤したいモデルやユースケー スによってこれらのパターンを使い分けます。 Intelligent Inference Scheduling KV Cacheの所在やvLLM Podの負荷状況 に応じた最適なスケジューリング処理を 実施 Prefill / Decode Disaggregation トークンの⼊⼒と出⼒を処理するGPUを 分離することで全体の処理効率を向上 Wide Expert Parallelism DeepSeekやgpt-ossなどのMoEモデルの 推論処理最適化 Prefix Cache Offloading KV CacheをGPUのVRAMだけではなく CPU RAMにオフロード利⽤可能な容量を 拡⼤
7. Well-Lit Path llm-dでは確⽴された分散推論のデプロイパターンとしてWell-Lit Pathを公開しています。利⽤したいモデルやユースケー スによってこれらのパターンを使い分けます。 Intelligent Inference Scheduling KV Cacheの所在やvLLM Podの負荷状況 に応じた最適なスケジューリング処理を 実施 Prefill / Decode Disaggregation トークンの⼊⼒と出⼒を処理するGPUを 分離することで全体の処理効率を向上 Wide Expert Parallelism DeepSeekやgpt-ossなどのMoEモデルの 推論処理最適化 Prefix Cache Offloading KV CacheをGPUのVRAMだけではなく CPU RAMにオフロード利⽤可能な容量を 拡⼤
8. Endpoint Picker 推論リクエストをGatewayが受け取ると、Endpoint Picker(EPP)に問い合わせを⾏ってルーティング先のPodを選択します。 Inference Gateway (Envoy) Endpoint Picker Plugins gRPC prefix-cache-scorer load-aware-scorer max-score-picker Pod 1 Pod 2 Pod 3 GPU KV Cache GPU KV Cache GPU KV Cache ▸ EnvoyのExternal Processingを利⽤ した外部スケジューラー ▸ 設定されたプラグインに基づきルー ティング先のPodを計算して選択 ▸ バックエンドの各Podが保持するKV Cacheの位置情報を保持
9. Endpoint Picker の設定 EPPはEndpointPickerConfigというYAMLを通じて設定します。プラグインを変えることで各Well-Lit Pathに合わせてEPPの 設定を変更できます。 apiVersion: inference.networking.x-k8s.io/v1alpha1 kind: EndpointPickerConfig plugins: - type: single-profile-handler - type: prefix-cache-scorer - type: load-aware-scorer - type: max-score-picker schedulingProfiles: - name: default plugins: - pluginRef: prefix-cache-scorer weight: 2.0 - pluginRef: load-aware-scorer weight: 1.0 - pluginRef: max-score-picker 利⽤するプラグインと パラメーターの設定 スコア計算時のプラグイ ンごとの重み付け Endpoint Picker Plugins prefix-cache-scorer load-aware-scorer max-score-picker
10. Intelligent Inference Scheduling KV Cacheの位置情報やvLLM Podの処理状況に応じてEPPが最適なバックエンドを選択します。 Maintain prefix-tree. “Pod A has hit” Prefix Aware Scorer EPP Pod A Pod B Pod C GET completions Load Aware Scorer EPP Pod A Pod B Pod C GET completions Prompt 過去リクエストのハッシュ値を保持し、リクエストが来 た際に最も⻑いハッシュ値を持つvLLM Podを優先 Scrape metrics. “A has low load” 各vLLM Podの処理キューの情報を元に、 処理の空きがあるPodを優先 Pod A Prompt Pod A /metrics KV Events
11. llm-d のデプロイ OpenShiftではKServeのLLMInferenceServiceというカスタムリソースを通じてllm-dに必要なコンポーネントをデプロイし ます。 .spec.model デプロイするモデルをどこから取得するか （HF、OCI Registry、オブジェクトストレージ、PVC） .spec.router Gateway、HTTPRoute、EPPの設定 .spec.template/worker/prefill デプロイするvLLM Podの設定
12. llm-d のデプロイ OpenShift AIコンソールからもデプロイが可能です。 *: 詳細設定はyamlから実施する必要があります
13. 推論パフォーマンスの計測と比較 マルチターンでの推論リクエストを実施しllm-dの有無によるレイテンシーへの影響を確認します。 Service Pod 1 Pod 2 Pod 3 Inference Gateway Pod 1 Pod 2 Pod 3 GPU KV Cache GPU KV Cache GPU KV Cache EPP パターン1: Serviceでロードバランシング パターン2: llm-dでロードバランシング
14. 推論パフォーマンスの計測と比較 両者を⽐較した結果、TTFT(Time to First Token)のロングテールにおけるレイテンシー改善が確認できました。 llm-dを利⽤する場合にチャットなどのユースケースでユーザー体験の向上が期待できます。 詳細はこちら：llm-dを実⾏しよう https://rheb.hatenablog.com/entry/2026/01/06/175215
15. 推論パフォーマンスの計測と比較 推論機能を強化するllm-d https://www.netone.co.jp/media/detail/20260121-01/ TTFT (ms) [p99] TTFT (ms) [p90] ITL (ms) [p99] ITL (ms) [p90] llm-d 181.09 73.24333333 35.50666667 34.97333333 Service 693.4166667 124.7466667 32.22333333 31.38333333 NetOne様のブログより
16. まとめ • LLMの推論パフォーマンスを最⼤化するにはその特性に応じた考慮が必要 • llm-dではWell-Lit Pathとして様々なユースケースに応じたデプロイパターン を提供 • Intelligent Inference SchedulingではKV Cacheや負荷状況に応じて最適な vLLMを選択 • llm-dによりロングテールでのレイテンシーを⼤幅に改善しユーザー体験を向 上 3/5(⽊)にレッドハット東京オフィスにてvLLM Meetup開催予定！
17. linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you