Distributed Inference Serving - vLLM, LMCache, NIXL and llm-d

Transcript

1. Distributed Inference Serving - vLLM, LMCache, NIXL and llm-d 2025/06/25 Mikiya Michishita(@aztecher) 1 1
2. 本資料の内容は、2025 年06 月25 日時点の情報や実装に基づいています。 実装についてもすべてのプログラムが最新ブランチを参照しているわけではなく、あく までllm-d の当時の最新ブランチが依存としているバージョンを参照しています。 将来にわたり情報等が更新される可能性があります。 著者もキャッチアップしながら学んでいる身のため不正確な情報がある可能性があります もし間違いを見つけたら報告いただけると幸いです。 本資料でターゲットにする話題はLLM を分散環境でサービングするケースです 基本的には小規模なモデルやLLM ではないモデルについては取り扱いません Disclaimer 2 2
3. LLM の推論はその処理の特性、応答特性や、ユーザトラフィックの変化などにより、分散 環境で実行することでメリットが生まれるケースがある 当然それ以外にも単順にモデルに対する要求が急激に増加している背景もある 本資料ではこれらの特性や変化を元にしつつ、vLLM / LMCache / NIXL / llm-d などのソ フトウェアを取り上げ、アプリケーションレイヤーの動作や最適化、分散推論インフラに ついて理解を深めていく Distributed LLM Inference Serving 3 3
4. LLM へのリクエストやその処理には非常に重要な特性がある ユーザリクエストの多様化と複雑化 ユーザが入力するPrompt は多様であり複雑、入力長もリクエスト毎に大きく異なる 一方で、多くのリクエストは以前の会話の焼き回しを含む、という特性もある リクエストへの応答には異なる計算フェーズが存在し、それぞれ処理特性が異なる これらの特性について理解し、最適化するための手法を知ることが、LLM 推論向け基盤を理解 する第一歩になる LLM へのリクエストとLLM の処理の特性 4 4
5. LLM へのリクエストは従来のウェブアプリケーショ ンにおける一般的なユーザリクエストとは大きく異 なる特性を持つ 従来: シンプルかつそこまで多様ではない内容で データ長も短い LLM へのリクエスト: リクエストは非常に複雑で 多様でありデータ長は長い User A chat between a curious user and an artificial intelligence assistant. The assistant... LLM ユーザリクエストの変化 5 5
6. リクエスト内容は従来に比べ多様化、複雑化する 一方で、Prompt Engi ne eri ng やR AG などのシ ステム化によって、プロンプト前半にテンプレー ト的な定型文が多用される。 LLM では入力トークンに対して計算処理を行う が、文章が定形である場合は計算結果が同じにな る特性がある。 User Please translate the following english to japanese: Would you like to tell me how to ... LLM Please translate the following english to japanese: Your suggestion is really helpful but... Prompt Template ユーザリクエストの特性とLLM による計算の特性 6 6
7. 文章生成などの生成タスクに採用される多くのモデ ルは、Decoder- only のTransformer モデル （Autoregressive Model ）である。 Autoregressive Model では、モデルが生成したト ークンを系列の末尾に加え、再度次のトークンの予 測計算を行うような機構になっている。 input Embedding RMS Norm Self-Attention（Grouped Multi-Query Attention） with KV Cache RMS Norm Feed Forward SwiGLU RMS Norm Linear Softmax Q V K Rotary Positional Encodings Nx LLaMA Transformer Model 7 7
8. モデルの構造中の重要な処理として、Attention の計算がある。　 ただし、Autoregressive Model の場合はこのAttention の計算は新しいトークンを除いてた だの再計算になってしまい、特にこれは入力トークン長に依存して計算量も大きくなる そのため、計算結果をキャッシュし、以降の計算で使いまわすことで計算量を減らそう、とい う発想になる。ここで出てくる「計算結果のキャッシュ」が KV-cache である *Transformer やAttent ion の話はたくさんの情報が検索すると出てくるのでここでは省略します。スライド 最後のReferences に自分が主に参照した資料については掲載しています Attention 8 8
9. Cache memory Queries 4 64 64 4 KT Values 64 Results 64 4 Caching K Caching V Restoring from cache K Restoring from cache V Queries 1 64 64 5 KT Values 64 Results 64 1 Cached part K Cached part V Prefill Decode ref: Mastering LLM Techniques: Inference Optimization KV-cache overview 9 9
10. Pref ill phase 入力トークンを処理し、最初のトークンを生成 入力トークンに対応するK V- cache も生成 行列演算が主となりCompute Bound な処理 Decode phase 直前のtoken をベースに後続の出力を生成する K V- cache による計算結果の再利用ができ計算処 理は重くないが、主記憶からG PU へのデータ転 送に時間がかかるMemor y Bound な処理 Key / Value Caches Prefill Phase LLM Decode Phase Prefill phase and Decode phase 1 0 1 0
11. Pref i ll 処理とDecode 処理を別のWorke r に分離 異なるボトルネックを適切に分離し効率的に処理 しそれぞれの処理効率を上げる手法 一方で「K V- cache をいかに共有するか」, 「 どの ようにリクエストをルーティングするか」など新 たな考慮事項が出現することになる。 Prefill Worker Shared KV (Prefix) Cache Prefill Worker Prefill Worker Decode Worker Decode Worker Decode Worker Prefill Workers Decode Workers Prefill-Decode (PD) Disaggregation 1 1 1 1
12. 同一モデルであれば、すでにK V- cache を作成済 みのトークンは使いまわすことができる。 K V- cache を外部ストレージなどに格納し、LLM サーバ間で共有することで、Pre f ill の計算処理 の一部をスキップすることができ高速化が見込ま れる 復数サーバで処理することで、より多くのユーザ アクセスをより受け付けられるようになり、ノー ド障害に対する可用性等の面でも有利な面が出て くる。 LLM LLM LLM Storage ① Request ② Calculate KV-cache and store it to storage Router ③ Request with the Same prefix as request ① ④ Lookup the KV-cache from storage. If you get hit, you can skip calculation KV-cache sharing 1 2 1 2
13. vLLM 1 3 1 3
14. vLLM は元はUC Berkeley のSky Computing Lab によって開発されたプロジェクト 高速で簡単に利用できるLLM inference & serving engine Community-driven project 様々なモデルを様々なリソース（NVIDIA GPU, AMD GPU, Google TPU, ...etc ）で動作 させることができる 近年急成長しているソフトウェア（主観）で、様々な最新技術を取り込んでいる先進的な 推論フレームワーク（主観） 正しいインフラは正しいアプリケーションの理解の上で成り立つので、本節ではvLLM をベー スにLLM 推論の技術について理解していく vLLM とは 1 4 1 4
15. P/D disaggregation ( これまで議論してきた通り) Paged Attention Automatic Pref ix-Cache Continuous Batching Speculative Decoding ( 本資料ではskip) Chunked Pref ill （本資料ではskip ） Quantilization ( 本資料ではskip) vLLM core technologies 1 5 1 5
16. 従来の手法では、KV-cache に利用するGPU メモリは、モデルが扱える最大トークン数分を 連続した領域に事前に確保するというナイーブな実装になっていた。 これは様々な課題を抱えていた リクエストに対して余分にメモリを確保するケースが多々発生しメモリ効率が悪い KV-cache をリクエスト間で共有できない（リクエスト毎に上記の動きをするため） ...etc より効率的なKV-cache のメモリ管理手法として、PagedAttention が提案されvLLM に実装さ れた。 Paged Attention (1/6) 1 6 1 6
17. PagedAttention: OS のページングを参考に考案されたKV-cache 管理手法 KV-cache をKV blocks に分割する KV blocks は固定サイズのメモリチャンクで、Logical KV blocks とPhysical KV blocks の 2 つのブロックが定義される Logical KV blocks ではトークンが自然な順序で格納され、Physical KV blocks では連続 したブロックの任意の場所にトークンが配置される Logical KV blocks とPhysical KV blocks のマッピングはBlock Table と呼ばれる新しい データ構造がに保存される これまでの静的な固定長のメモリ割り当てから動的な割り当てになり、かつフラグメンテーシ ョンの問題を解決できる手法になっている。 Paged Attention (2/6) 1 7 1 7
18. ① Four score ① and ① seven ① ① years ago ① our ① fathers ② ③ brought ① Four score ① and ① seven ① ① years ago ① our ① fathers ② ③ brought Physical block number #filled 7 4 1 3 -> 4 3 1 - - Block 0 Block 1 Block 2 Block 3 Block 4 Block 5 Block 6 Block 7 Block 8 Physical KV blocks （on GPU DRAM） Block 0 Block 1 Block 2 Block 3 Request A Prompt: "Four score and seven years ago our" Outputs: "fathers" -> "brought" -> ... Logical KV blocks Block Table ref: Eff icient Memory Management for Large Language Model Serving with Paged Attention Paged Attention (3/6) 1 8 1 8
19. ① 入力プロンプトの7 つのトークンをLogical KV blocks （Block 0, 1 ）とPhysical KV blocks(Block 7, 1) にマッピングする。Attention アルゴリズムによって得られたKV-cache は Logical KVblock のBlock 0, 1 に格納する ② 新しく生成したトークン（fathers ）は、Logical KV blocks で空いているBlock 1 のスロ ットに割り当てられる。新しく生成したKV-cache もそこに保存され、Block table の#f illed レコードが更新される。 ③ 次の生成トークン（brought ）はLogical KV blocks が満杯のため、新しいLogical KV block (Block 2) に保存する。このとき新しいPhysical KV block(Block 3) を紐付け、それを Block Table に記載する Paged Attention (4/6) 1 9 1 9
20. 既存のシステムでは、シーケンス毎のKV-cache が連続した別々のスペースに格納されるた め、メモリ共有ができなかった。 Paged Attention により、シーケンス間でメモリを共有することができるようになる。 実際は安全な共有を保証するために、物理ブロックの参照カウント（Ref count ）を追 跡し、Copy-on-Write メカニズムによって必要に応じてデータをコピーする。 同じリクエストに関連する異なるシーケンス間、あるいは異なるリクエスト間でもブロッ ク単位でメモリの共有が可能になる。 特に同一プロンプトから複数のシーケンスを生成する際の、並列サンプリングやビーム サーチなどのサンプリングアルゴリズムにおいて、メモリオーバーヘッドを大幅に削減 することができる。 Paged Attention (5/6) 2 0 2 0
21. Four score and seven years ago our Block 0 Block 1 Block 2 Block 3 Block 4 Block 5 Block 6 Block 7 Block 8 Physical KV blocks Block 0 Block 1 Request A1 Logical KV blocks Four score and seven years ago our mothers Block 0 Block 1 Request A2 Logical KV blocks Four score and seven years ago our fathers fathers mothers years ago our Copy-on-write Ref count: 1->2 ref: Eff icient Memory Management for Large Language Model Serving with Paged Attention Paged Attention (6/6) 2 1 2 1
22. P/D disaggregation ( これまで議論してきた通り) Paged Attention Automatic Pref ix-Cache Continuous Batching Speculative Decoding ( 本資料ではskip) Chunked Pref ill （本資料ではskip ） Quantilization ( 本資料ではskip) vLLM core technologies 2 2 2 2
23. 前項で触れた「Request 間でのKV-cache を共有」を行うには、各Request が参照可能な Mapping の保持や管理、Lookup 時のUnique Key などを考える必要がある。 vLLM ではこれをKV-cache Manager が担っている。 Request 間でのKV-cache を共有は、Prefill フェーズの計算効率を上げることに寄与する Automatic Prefix-Caching 2 3 2 3
24. キャッシュをLookup するためのKey を、Paged Attention のBlock をベースとして計算する A gentle breeze stirred the leaves as children laughed in the distance Block 0 Block 1 Block 2 Block tokens Block tokens Block tokens Prefix Prefix hash（Prefix tokens + Block tokens）<--> KV Block Block 0 Block 1 Block 2 ref: Automatic Pref ix Caching Automatic Prefix-Caching 2 4 2 4
25. Request 毎に作成されるLogical K V cache を元 にhash 値を計算し、Phyiscal K V Blo cks との関 係をGlobal なHash Table に格納する 新規Request の入力トークンのうち、Pre f ix が 一致する部分はGlobal H ash Table からLookup 可能であり、再計算が不要になるため、Pref i ll フェーズの計算量削減につながる Logical KV cache Block Table Physical KV Blocks （on GPU DRAM） Logical KV cache Block Table Previous Request #1 Previous Request #2 Global Hash table Hash When the new request comes in, Try to lookup from the Global Hash Table to see if recomputation can be reduced Automatic Prefix-Caching 2 5 2 5
26. P/D disaggregation ( これまで議論してきた通り) Paged Attention Automatic Pref ix-Cache Continuous Batching Speculative Decoding ( 本資料ではskip) Chunked Pref ill （本資料ではskip ） Quantilization ( 本資料ではskip) vLLM core technologies 2 6 2 6
27. LLM の推論リクエストに対しての、サーバサイドのバッチ処理の最適化を考える。 特徴的な点は、リクエストに対しての応答サイズ（出力トークン長さ）が不定であること そもそもバッチで処理を行おうとすると、バッチの中で最も長い出力を生成する処理に 引っ張られてしまう。 S1 S2 S3 S4 S1 S2 S3 S4 S1 S3 S4 S1 S4 S2 S3 T1 T2 T3 T5 T6 T8 T7 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S3 S4 S1 S4 S2 S3 T1 T2 T4 T3 T5 T6 T8 T7 S4 decode S1 S4 S2 S2 S2 S2 END END END END T4 Continuous Batching (1/2) 2 7 2 7
28. LLM 推論の新たなバッチ戦略としてContinuous Batching が提案された* バッチ中の生成を終了したシーケンスに対して、次のリクエストを詰めていくイメージ iteration-level scheduling とも呼ばれる方式 vLLM でもこのContinuous Batching がサポートされている S1 S2 S3 S4 S1 S2 S3 S4 S1 S3 S4 S1 S4 S2 S3 T1 T2 T3 T5 T6 T8 T7 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S3 S4 S1 S4 S2 S3 T1 T2 T4 T3 T5 T6 T8 T7 S4 decode S1 S4 S2 S2 S2 S2 END END END END T4 S6 S6 S5 S5 S7 S5 *OSDI'22: Orca: A Di stri buted S e r v ing Sy ste m fo r Transfo rm er- Ba sed G enerative M od els Continuous Batching (2/2) 2 8 2 8
29. vLLM KV Connector API, NIXL and LMCache 2 9 2 9
30. P/D Disaggregation を実現するためには、何かしらの方法によってKV-cache を複数推論サー バ間で共有する必要がある。 Peer-to-Peer でKV-cache を送受信する 共有ストレージを利用してKV-cache を共有する ...etc vLLM ではこの部分をコアロジックから分離しインターフェイスとすることでプラグイン可能 にしている。 How to share KV-cache? 3 0 3 0
31. K V Connector API はvLLM におけるK V- cache の管理を外部システムと連携するためのインター フェイス。 最近、V0 から大幅にリファクタリングされたV1 API が実装された。 vLLM Instance KV Connector V1 API KV Connector LMCache NIXL kv & metadata transmission KV Connector API 3 1 3 1
32. 現時点で確認できるV1 実装としては以下がある SharedStorageConnector: サンプル・デバッグ実装。ローカルディスクに書き出す。 MultiConnector: 復数のV1 Connector を束ねるメタコネクタのような実装 P2pNcclConnector: NCCL と統合するコネクタ NixlConnectorV1: NIXL と統合するコネクタ LMCacheConnectorV1: LMCache と統合するコネクタ V0 時点では実装があったMoonCakeStore 向けコネクタがV1 をまだ実装していないように見 えるが、LMCache のレイヤーでは既に統合されている V1 Supported Connectors 3 2 3 2
33. NVIDIA 製のXfer Library P2P 通信の高速化を目的としたライブラリ AI Inference Framework におけるTransport として利用する想定 NVIDIA Dynamo で利用されている データ転送におけるストレージソリューションと最適な転送方式を抽象化する つまり、P2P でKV Cache を転送を最適に実行するためのライブラリ モジューラプラグインアーキテクチャを採用しており独自に拡張可能 NIXL (NVIDIA Inference Xfer Library) 3 3 3 3
34. Transfer Agent Metadata Handler Memory Selection North-Bound NXIL API South-Bound Backend API Backend Connection Info Backend Connection Info Backend Connection Info Backend Connection Info Backend Connection Info Backend Connection Info DRMA VRAM FILE NVMe/ Block Example Transfer Backend Plugins Remote Agent info cached locally Node memories registered with Agent NIXL cross-node & cross-mem buffer list primitive NXIL Transfer Handles with repost capability UCX GDS Custom Backend ref: https://github.com/ai-dynamo/nixl/blob/main/docs/nixl.md NXIL Overview 3 4 3 4
35. LMC ache はLLM Ser vi ng E ngi ne の拡張機能と して、K V- C ache の管理機能を提供する ロングコンテキストのシナリオにおいて、T TF T を削減しスループットを向上させる K V- cache のバックエンドとして様々な場所 （storage など）に保存することができる LMC ache Connector はvLLM 公式のUp stre am と統合されているためシームレスに利用可能 LMCache vLLM V1 KV connector NIXL GPU・ Network・ Storage LLM Engine Layer KV Cache Layer Hardware Layer ref : Shapi ng NIXL-based PD Di saggregati on in vLL M V1 LMCache 3 5 3 5
36. ref : Shapi ng NIXL-based PD Di saggregati on in vLL M V1 LMCache: Two Core KV Cache Functions 3 6 3 6
37. KV Cache をストレージソリューションに永続化する ユーザセッション間でKV Cache を共有する際などに有効に利用できる DB-style の抽象化によって、GPU からCPU メモリやDISK などにKV-cache をオフロード Eviction やPrefetch 戦略もカスタマイズ可能 LMCache のvLLM との統合はvLLM V1 の高度なメモリ機能（pref ix caching, chanked pref ill, paged memory manager ）に合わせて設計されている Storage: DB-Style Loading and Offloading 3 7 3 7
38. PD disaggregation 向けに、リアルタイムでKV-cache を別ノードに転送する仕組み LMCache はP2P KV transfer をサポートしノードをまたいた再計算をなくしキャッシュを 有効に利用する。 NIXL をサポートすることで多様はハードウェア、トランスポートに対応 このNIXL による高速なKV-cache transfer は、多くの場合単一のトークンのAttention を 計算するより高速 Transport: P2P-Style Direct Transfer 3 8 3 8
39. LMCache には現在2 種類のKV-cache sharing の方式が存在する。 Centralized Sharing: 中央のキャッシュサーバを利用したKV Cache の共有 P2P Sharing: Peer-to-Peer でKV Cache を共有する 以降では、llm-d の議論の際にすこしだけ議論に絡むため、P2P Sharing の方式について軽く 深堀りする。 ＊ あくまでKV-cache 共有によるPref ill 段階での計算量削減の文脈。ややこしいが後者はPD Disaggregation 時のP2P Transfer の話とは別軸の話 KVCache sharing strategies 3 9 3 9
40. KVCache P2P Sharing を行う場合、有効化設定である eanble_p2p に加え、lookup_url と distributed_url という設定項目が必要になる YAML Configuration Name Environmental Variable Default enable_p2p LMCACHE_ENABLE_P2P False lookup_url LMCACHE_LOOKUP_URL "" distributed_url LMCACHE_DISTRIBUTED_URL "" ref : https:/ /docs.lmcache.ai /ap i_ re ference /conf igura tion s. html# peer-to -p eer- shar ing- conf i gurati ons Example: KVCache P2P Sharing: CPU RAM 4 0 4 0
41. LMC acheEngi ne にコアロジックの実装がある 様々なStorageBackend をインターフェイス 越しに操作 LMC ache がサポートするストレージソリュ ーションはこのインターフェイスを実装する 形で統合される 前述の通りP2P Shari ng ではLookupSer ver や DistributredSer ver という概念が登場する が、これは何なのだろう？ Storage Solutions LMCacheConnectorV1Impl LMCacheEngine StorageManager Adapter Adapter Adapter Distributed Server Backend Backend Backend Storage B LookupServer Client Lookup Server NIXL Storage A KV connector V1 API LMCacheEngine 4 1 4 1
42. LookupSer ver K V- cache のローカリティ（host : port ）が書き 込まれている（外部）Redis Se r ve r のこと LMCACHE_LOOKUP_URL によって LMC acheEngi ne 内部のRedi s クライアントが接 続、リクエストを発行する DistributedSer ver K V- cache をP2P で転送しあうときの送受信サー バ（LMC acheEngi ne 内の別スレッド） LMCACHE_DISTRIBUTED_URL によって指定したホ スト、ポートで通信を待ち受ける LMCacheConnectorV1Impl LMCacheEngine StorageManager Distributed Server LookupServer Client KV connector V1 API LMCACHE _LOOKUP_URL DISTRIBUTED _URL LookupServer and DistributedServer 4 2 4 2
43. LMCacheEngine LocalCPU Backend DistributedServer LookupServer Client Lookup Server LMCacheEngine LocalCPU Backend DistributedServer LookupServer Client ③ Store locality ① Call Store ② Store Cache ④ Call load ⑤ Lookup Cache → Cache Miss ⑥ Lookup → Hit! ⑦Request to send data ⑧ Get cache ⑨ Send local cache ⑩ Return How P2P KV-cache sharing works? 4 3 4 3
44. LLM Inference Framework: llm-d 4 4 4 4
45. LLM Inference の最適化技術を最大限活用できる最適なルーティング、P/D Disaggregation を効率的に実行できるインフラの構成などを考える必要がある。 Users Prefill Worker （vLLM） Prefill Worker （vLLM） Prefill Worker （vLLM） Prefill Workers Decode Worker （vLLM） Decode Worker （vLLM） Decode Worker （vLLM） Decode Workers Transfer KV-cache Routing Efficient Routing KV-cache aware, Prefix aware, ...etc P/D Disaggregation Support Cache LLM inference considertaion 4 5 4 5
46. llm-d はvLLM とKubernetes をベースとした分散推論基盤ソフトウェア 大規模で最適なGenAI 推論基盤の提供を目指すオープンソースプロジェクト RedHat, CoreWeave, Google Cloud, IBM Research, NVIDIA がローンチメンバー AMD, Cisco, Hugging Face, Intel, Lambda, Mistral AI がパートナー ref: LLM-D. AI llm-d 4 6 4 6
47. llm-d はkubernetes 環境に以下の機能を提供する ModelService による一貫したLLM Model のデプロイ vLLM のPD Disaggregation を補完するデプロイ機構の提供 Gateway API Inference Extension をベースとしたLLM 推論向けルーティング機能 vLLM, LMCache などの最適化手法を最大限活かせる環境 柔軟なAutoScaling 技術 (WIP) ref: Overview of llm-d architecture llm-d 4 7 4 7
48. ref: https://github.com/llm-d/llm-d llm-d architecture 4 8 4 8
49. Gateway API Inference Extension （GIE ）をベースにしたルーティング機能の拡張 LLM の推論リクエストに特化した最適なルーティング機能を提供する KV-cache aware routing Pref ix aware routing Session aff inity routing Load aware routing Model metadata routing ルーティング機構はPluggable であり、機能を拡張することができる。 現状は環境変数で切り替えられる Inference Gateway (IGW) 4 9 4 9
50. k8s 上にGenerative Mode l を最適にセルフホス トするための公式プロジェクト Gateway API のHT TPRoute のextensi onRef フ ィールドを利用して機能を拡張する 推論リクエストに対して、コスト面・性能面から 最適なルーティング・ロードバランス機能を提供 詳細は公式資料のIntroducti on を参照 GatewayClass Gateway HTTPRoute InferencePool Service InferenceModel InferenceModel Inference Extension Gateway API Inference Extension (GIE) 5 0 5 0
51. GIE の実装方式としてEnvoy E x te rnal Processi ng(ext-proc) が利用されている ext-proc はEnvoy 外部のと連携しFi lte r C hain の拡張を実現することができる機能 HT TP のRequest/ Response のH ead er やBody, Trai ler の読み込みや修正が可能 gRPC インターフェイスを実装する外部サービス （external processor ）と連携可能 Client Envoy Proxy External Processing Server Server gRPC interface ref: External Processing Filter GIE and Envoy External Processing 5 1 5 1
52. E x . kgateway （envoy ベース） GIE のリソース（HT TPRoute , Inference Pool , InferenceModel ）を作成すると、ex t-p roc の ため設定を生成し読み込む ext-proc のリクエスト先は、InferencePo ol で 定義しているバックエンドのリソース 以降、HT TPRoute で指定したInferencePo ol 向 けのルールにマッチするリクエストを受けると、 ext-proc へのgRPC リクエストを発行するような 挙動を行う Gateway Gateway Class HTTPRoute Inference Pool Inference Model kgateway Pod (envoy) EPP Pod（llm-d-inference-scheduler） ExtProc gRPC Server Scheduler Invoke ext-proc via gRPC to select destination pod vLLM Pod Scorers Filters ... Plugins gRPC interface vLLM Pod vLLM Pod vLLM Pod vLLM Pod vLLM Pod Inference Pods (prefill / decide) EPP Service / Pod Client GIE implementation @kgateway 5 2 5 2
53. GIE において Endpoint Picker (EPP) がスケジューリングのコア機能を担う llm-d ではこの機能は llm-d-inference-scheduler に実装される llm-d-inference-scheduler はGIE 本家の実装をベースに、GIE の拡張可能性を利用した独 自のscheduling 機能の実装（Plugins ）を行っている ext-proc としてgRPC を受け、scheduling 機能によって最適なエンドポイントを選択する kgateway Pod (envoy) EPP Pod（llm-d-inference-scheduler） ExtProc gRPC Server Scheduler Invoke ext-proc via gRPC to select destination pod Scorers Filters ... Plugins gRPC interface Endpoint Picker (EPP) & llm-d-inference-scheduler 5 3 5 3
54. EPP は、GIE のリファレンス実装のSche dule 処理を そのまま呼び出し、以下のような処理を実行する。 PreSchedulePlugi n の実行 Fi lterPlugi n の実行 ScorerPlugi n の実行 Pi cker の実行 PostSchedulePlugi n の実行 GIE ではそれぞれのPlugi n などが満たすべきインタ ーフェイスが定義されており、それを満たすような 実装を行うことで処理の追加や差し替えが可能。 Schedule GIE Scheduler.Schedule EPP ( llm-d-inference-scheduler) Prefill Scheduler Schedule Decode Scheduler Schedulie runPreSchedulePlugin runFilterPlugins runScorerPlugins runPickerPlugin runPostSchedulePlugins Run ＊EPP の実装的に処理の分岐等はあるが、必ずPre f ill・ Deco de のどちらかのSche duler でG IE のSch ed ule 処 理は呼び出される形にはなる Scheduling processes of EPP 5 4 5 4
55. llm-d ではGIE のSchedling 処理の中で拡張可能なFilter やScorer として独自の機能を持つもの を定義している。例えば、llm-d のScorer には以下が存在する。 Scorer Description Session-aware Session ID に基づいて、直前にそのセッションを処理したPod を優先 Load-aware Pod のリアルタイムな負荷指標を元に過負荷なPod を避ける Pref ix-aware Prompt のpref ix が過去に処理されているPod を優先 KVCache-aware KVCache の再利用が見込めるPod を優先 これらのScorer 有効・無効などは環境変数から設定可能な実装になっている。 llm-d defined scorer 5 5 5 5
56. リクエストに含まれる、「x-se ssion-token 」の 情報を取得し、Pod の情報が書き込まれている場 合は対象のPod のスコアを加算する Pod1 Incomming request Pod3 Pods（provided by GIE） Next Scorer Session-aware scorer Pod2 x-session-token: xxxxxxxxx Session Token String decode Pod3: +Score Find Session-aware scorer 5 6 5 6
57. Pod の負荷状況に合わせて、負荷の小さいPod を 優先するようスコアリング Pod のメトリクスはGIE の実装の中で定期的に Pod のメトリクスを収集・保存する仕組みがあ り、その情報をスコアリング時に利用している 現状の実装ではWai ti ngQue ue の情報のみを利 用している Pod1 Incomming request Pod2 Pods（provided by GIE） MetricsState MetricsState Waiting QueueSize Waiting QueueSize Pod1: +Score1 Pod2: +Score2 Next Scorer Load-aware scorer Load-aware scorer 5 7 5 7
58. リクエストのPrompt のPre f ix が過去にどこかの Pod で計算、キャッシュされている場合、それを 検出してスコアを上乗せする。 インメモリにLRU キャッシュを構築し、リクエス トを受けるとこれをLookup してPod に対してス コアリング Prefix-aware scorer Model Name Cache （LRU） Lookup LRU cache by Model Name LRU cache Hash Hash Hash Hash CacheBlockSize Lookup block by Prefix hash Pod Name Score Pod1: +Normalized Score1 Pod1 Score1 Pod2 Score2 Pod3 Score3 Pod2: +Normalized Score2 Pod3: +Normalized Score3 Request Prompt Incomming request Next Scorer Prefix-aware scorer 5 8 5 8
59. K VC ache が再利用できるように最適なルーティ ング先のスコアを上乗せする llm- d-k v- cache-manager にリファレンス実装 があり、K VC ache- aware sco re r は基本その実 装を利用する形で実装されている。 Incomming request llm-d-kvcache-manager KVCache Indexer Pod1: +Normalized Score1 Pod2: +Normalized Score2 Next Scorer KVCache-aware scorer Score？ Normalize KVCache-aware scorer 5 9 5 9
60. KVCache-aware なルーティングを実現するための管理機構 リクエストに対し、どのPod にルーティングすると最もながいPref ix でKVCache にヒッ トするか、を最適化するようなルーティングを実現したい 現在の実装ではLMCache を概ね前提にしていそう 現時点ではさらに、vLLM のConnector API を介した、KVCache Engine にオフロード されるテンソル情報のみしか利用できない KVCacheIndexer という実装があり、これがKVCache を意識したスケジューリングを行え るように設計された、プラグイン可能なモジュールになっている。 Scorer のリファレンス実装も存在する。KVCacheIndexer を利用し、KVCache を最適に再 利用できるPod のスコアを加算するようなスコアリングの実装が存在する。 llm-d-kv-cache-manager 6 0 6 0
61. Router KVCache Indexer vLLM Core LRU Prefix Store KVBlock to Pod availability index KVCache Engine ( LMCache ) Redis Score (prompt, ModelName, relevantPods) FindLongestTokenizedPrefix (prompt, ModelName) -> tokens DigestPromptAsync GetPodsForKeys(tokens) -> {KVBlock keys to Pods} availability map Route Redis MGet(blockkeys) -> {KVBlock keys to Pods} Connector API UpdateIndex (KVBlock keys, IP) vLLM Node KVCache Manager {Pod to Scores map} ref: https://github.com/llm-d/llm-d-kv-cache-manager llm-d-kv-cache-manager overview 6 1 6 1
62. KVCacheIndexer はいくつかのコンポーネントで成り立つ tokenization.Pool: インメモリのQueue 構造＋それを処理するWorkers の実装 pref ixstore.Indexer (&LRUTokenStore): インメモリキャッシュへのIndexer kv-cache.TokenProcessor: Token 処理を行うプロセッサ kv-cache.Indexer: （外部のRedis に対するIndexer ） kv-cache.KVBlockScorer: 戦略に従ってスコアを計算する実装 llm-d-inference-scheduler で利用されるスコアリング機能を元に少し深堀りしていく llm-d-kv-cache-manager implementation 6 2 6 2
63. リクエストを一時的に保存するQueue 構造 + Queue を処理してインメモリLRU キャッシュ （pref i xstore.Indexer 内部の構造）に tokeni ze して書き込むWorker Queue へのTask の追加は別のプロセス・処理か ら追加される（llm- d-i nfe re nce-sche dule r の 場合はScori ng 処理の冒頭で追加している） Task Worker #1 Worker #N Prefix Store workqueue Task Task Task AddTokenization Encode Get AddTokenization Encode Get AddTask tokenization.Pool 6 3 6 3
64. インメモリLRU キャッシュ構造、及びLRU キャッ シュを索引するインデクサ LRU キャッシュに書き込まれたTo ke n をリクエス トのモデル名、Prompt から索引できる Scori ng の文脈では、Prompt のPre f ix の最長マ ッチして、取得したTokens をつなげたものを返 却する実装がある Model Name Cache （LRU） Lookup LRU cache by Model Name LRU cache Hash Hash Hash Hash Lookup token by Prefix hash Request Prompt tokens tokens tokens tokens prefixstore.Indexer 6 4 6 4
65. Token から（外部）Redi s の索引に利用するKe y （Block Key ）を作成するプロセッサ tokens（ []uint32 ） chunk chunk chunk chunk chunkSize +ModelName kvblock.Key kvblock.Key kvblock.Key kvblock.Key kv-cache.TokenProcessor 6 5 6 5
66. Block Key を元にRedi s を索引するインデクサ。 Pods のリストが取得される。 今回の場合はRedi s にはvLLM から. ... なので「対 象のPref i x を処理したPod のリストを取得する」 という形になる kvblock.Key1 kvblock.Key2 kvblock.Key3 kvblock.Key4 Redis Pod1 Pod2 Pod3 Pod4 Pods ( by Key1 ) Pods ( by Key2 ) Pods ( by Key4 ) Pods ( by Key3 ) kv-cache.Indexer 6 6 6 6
67. 「Redi s からPod のリストを取得」という話をし たが、このRedi s がLMC ache で説明したLookup Ser ver に該当する。 Lookup Ser ver にはK V- cache のLocalit y （Host :Port ）が記述されているため、ここから Host （= Pod ）を取り出せる ただし、この実装は現在アップストリームでは非 推奨としてより良い形にするべく絶賛議論が進ん でいます Redis ( Lookup Server ) KVCache Indexer Pods vLLM w/ LMCache vLLM w/ LMCache vLLM w/ LMCache Store kv-cache locality Lookup for Scoring What is this Redis? ... LMCache's LookupServer! 6 7 6 7
68. kv-cache.Indexer から得られる結果を元に、特定の戦略に従ってスコアリングする LongestPref ixScorer （デフォルト）では、Pref ix により長くマッチするKVCache を保有 するPod が一番点が高くなるようにスコアリング Pod1 Pod2 Pod3 Pod4 Pods1 ( by Key1 ) Pod1 Pod2 Pod3 Pods2 ( by Key2 ) Pod1 Pod2 Pods3 ( by Key3 ) Pod1 Pods3 ( by Key3 ) Pods1 x Pods2 Pod1 Pod2 Pod3 Pods1 x Pods2 x Pods3 Pod1 Pod2 Pods1 x Pods2 x Pods3 x Pods4 Pod1 Score = 1 Score += 1 Score += 1 Score += 1 kv-cache.KVBlockScorer 6 8 6 8
69. llm- d-i nference-scheduler では、llm- d- k v - cache-manager で実装されているデフォルトの K VC acheIndex を初期化して利用 tokeni zati on.Pool はメインスレッドとは別の gorouti ne で起動。 K VC ache- aware scorer はこのk v- cache.K VBlockScorer の実装を概ね流用し、ス コアリング結果を正規化だけしている。 Incomming request llm-d-kvcache-manager KVCache Indexer Pod1: +Normalized Score1 Pod2: +Normalized Score2 Next Scorer KVCache-aware scorer Score？ Normalize Revisit: KVCache-aware scorer 6 9 6 9
70. LLM 推論 on k8s は、かなり多くのResource の連携によって実現することになる 単一のベースモデルに対して、これらのリソースをうまくコントロールする仕組みを提供 ModelService CR にpref il/decode/epp/LLM model 情報などを記載 ModelService Controller のReconcile 処理の中で様々なリソースを管理 Create/Update Pref il/Decode deployment & conf igmap Create/Update EPP service & deployment Create/Update InferencePool/Inference Model ...etc より詳細なリソース間の関係はREADME のHow It Works を参照されたい llm-d-model-service 7 0 7 0
71. Overview Kubernetes Resource Data Plane Client inference Gateway vLLM Inference Pool Body-based Routing Inference Scheduler vLLM Prefix caching vLLM vLLM Prefill Decode Route to selected Pod Gateway Gateway Class HTTPRoute Inference Pool Inference Model llm-d- inference- scheduler Gateway Pod kgateway Pod (envoy) EPP Pod（llm-d-inference-scheduler） ExtProc gRPC Server Scheduler Invoke ext-proc via gRPC to select destination pod vLLM Pod vLLM Pod Route to selected Pod ModelService vLLM Pod vLLM Pod vLLM Pod vLLM Pod Prefill Decode llm-d- model- service Scorers Filters ... Plugins llm-d overview, resources and data plane 7 1 7 1
72. LLM 推論における性能指標 7 2 7 2
73. 本資料では、応答性能に関する代表的な指標と、モデルの精度の指標となるものとして代表的 な以下のものを取り上げ簡単に概説するに留める 何に対する指標か 代表的な指標 応答速度に対する性能指標 TTFT / TPOT (ITL) モデルの精度（Code Generation ）に対する指標 Pass@1 詳細の確認や、その他の性能指標については各々確認されたい LLM 推論における性能指標 7 3 7 3
74. T TFT （T ime To First Token ） リクエスト送信から最初のトークンが返るまでの時間 (= Pref ill にかかる時間) TPOT(T ime Per Output Token), ITL 1 トークン生成にかかる時間 (= 1Token のDecode にかかる時間 ) ユーザがモデルに対して行ったリクエストに対し、完全な応答を生成するのにかかる時間（待 ち時間）は以下のように計算できる。 待ち時間 生成されるトークン数 応答性能の指標: TTFT / TPOT 7 4 7 4
75. pass@1 モデルのコーディング能力を評価する指標 モデルが、与えられた問題に対して生成した最初の施行で正しい回答を生成できる確率を 示す指標 モデル間での性能比較や、量子化により性能影響を比較することができる。 Code Generation 系ベンチマークツールとしてOpenAI のHumanEval や、最近では LiveCodeBench あたりが有名そう（試してないです） 精度の指標: pass@1 7 5 7 5
76. まとめ 7 6 7 6
77. LLM 推論ではKV-Cache の取り扱いを始め、計算効率、処理効率を最適化するための技術的 な仕組みやルーティングが重要になる vLLM は様々な最適化技術を実装した推論エンジンとして昨今注目を集めている。 LMCache を利用することでvLLM に対してキャッシュレイヤｰの機能を統合できる KV-Cache の転送を最適化するためにNIXL などのソフトウェア、それに準じたHW やス トレージなどが要求されてくる可能性がある llm-d はk8s 環境へこれらのインフラをk8s 的に実現する手段の一つ。その他にもNVIDIA Dynamo やKServe など様々なソリューションが存在。 自身のインフラにとって最適な選択をするための審美眼が必要。 正しい判断をするにはLLM 等の技術に関する正しい知識を持つことが重要になる まとめ 7 7 7 7
78. 本資料では具体的なソフトウェアを取り扱いながら、現在の分散推論基盤に求められる機能や その実装方式について詳しく説明してきました。 ただし、今回の資料ではカバーしきれていない領域（Attention の最適化や各種量子化、推論 時のモデル並列、テンソル並列など）もあるため、まだまだ我々我々が把握すべきことは多い と思っています。 本資料が、今後分散推論基盤構築や検証に関わる方にすこしでも参考になれば幸いです。 さいごに 7 8 7 8
79. Off icial docs / Codes vLLM off icial docs / Codes NIXL docs LMCache off icial docs / Codes llm-d off icial docs / Codes Related Technologies External Processing Extend Your Data Plane Out-of-Process Using Envoy's External Processing (Youtube) References 7 9 7 9
80. Optimization Techniques Eff icient Memory Management for Large Language Model Serving with PagedAttention Mastering LLM Techniques: Inference Optimization How continuous batching enables 23x throughput in LLM inference while reducing p50 latency Continuous vs dynamic batching for AI inference Pref ixCaching - SGLang vs vLLM: Token-Level Radix Tree vs Block Level Hashing References 8 0 8 0
81. Transformer Transformer, this tech behind LLMs Attention in transformers, step-by-step How might LLMs store facts LLaMa explained: KV-Cache, Rotary Positional Embedding, Grouped Query Attention, SwiGLU References 8 1 8 1