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

by Mikiya Michishita

Embed

Start on current slide

Slide 1

Slide 1 text

Distributed Inference Serving - vLLM, LMCache, NIXL and llm-d 2025/06/25 Mikiya Michishita(@aztecher) 1 1

Slide 2

Slide 2 text

本資料の内容は、2025 年06 月25 日時点の情報や実装に基づいています。実装についてもすべてのプログラムが最新ブランチを参照しているわけではなく、あくまでllm-d の当時の最新ブランチが依存としているバージョンを参照しています。将来にわたり情報等が更新される可能性があります。著者もキャッチアップしながら学んでいる身のため不正確な情報がある可能性がありますもし間違いを見つけたら報告いただけると幸いです。本資料でターゲットにする話題はLLM を分散環境でサービングするケースです基本的には小規模なモデルやLLM ではないモデルについては取り扱いません Disclaimer 2 2

Slide 3

Slide 3 text

LLM の推論はその処理の特性、応答特性や、ユーザトラフィックの変化などにより、分散環境で実行することでメリットが生まれるケースがある当然それ以外にも単順にモデルに対する要求が急激に増加している背景もある本資料ではこれらの特性や変化を元にしつつ、vLLM / LMCache / NIXL / llm-d などのソフトウェアを取り上げ、アプリケーションレイヤーの動作や最適化、分散推論インフラについて理解を深めていく Distributed LLM Inference Serving 3 3

Slide 4

Slide 4 text

LLM へのリクエストやその処理には非常に重要な特性があるユーザリクエストの多様化と複雑化ユーザが入力するPrompt は多様であり複雑、入力長もリクエスト毎に大きく異なる一方で、多くのリクエストは以前の会話の焼き回しを含む、という特性もあるリクエストへの応答には異なる計算フェーズが存在し、それぞれ処理特性が異なるこれらの特性について理解し、最適化するための手法を知ることが、LLM 推論向け基盤を理解する第一歩になる LLM へのリクエストとLLM の処理の特性 4 4

Slide 5

Slide 5 text

LLM へのリクエストは従来のウェブアプリケーションにおける一般的なユーザリクエストとは大きく異なる特性を持つ従来: シンプルかつそこまで多様ではない内容でデータ長も短い LLM へのリクエスト: リクエストは非常に複雑で多様でありデータ長は長い User A chat between a curious user and an artificial intelligence assistant. The assistant... LLM ユーザリクエストの変化 5 5

Slide 6

Slide 6 text

リクエスト内容は従来に比べ多様化、複雑化する一方で、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

Slide 7

Slide 7 text

文章生成などの生成タスクに採用される多くのモデルは、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

Slide 8

Slide 8 text

モデルの構造中の重要な処理として、Attention の計算がある。　ただし、Autoregressive Model の場合はこのAttention の計算は新しいトークンを除いてただの再計算になってしまい、特にこれは入力トークン長に依存して計算量も大きくなるそのため、計算結果をキャッシュし、以降の計算で使いまわすことで計算量を減らそう、という発想になる。ここで出てくる「計算結果のキャッシュ」が KV-cache である *Transformer やAttent ion の話はたくさんの情報が検索すると出てくるのでここでは省略します。スライド最後のReferences に自分が主に参照した資料については掲載しています Attention 8 8

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

同一モデルであれば、すでに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

Slide 13

Slide 13 text

vLLM 1 3 1 3

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

従来の手法では、KV-cache に利用するGPU メモリは、モデルが扱える最大トークン数分を連続した領域に事前に確保するというナイーブな実装になっていた。これは様々な課題を抱えていたリクエストに対して余分にメモリを確保するケースが多々発生しメモリ効率が悪い KV-cache をリクエスト間で共有できない（リクエスト毎に上記の動きをするため） ...etc より効率的なKV-cache のメモリ管理手法として、PagedAttention が提案されvLLM に実装された。 Paged Attention (1/6) 1 6 1 6

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

① 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

Slide 19

Slide 19 text

① 入力プロンプトの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

Slide 20

Slide 20 text

既存のシステムでは、シーケンス毎のKV-cache が連続した別々のスペースに格納されるため、メモリ共有ができなかった。 Paged Attention により、シーケンス間でメモリを共有することができるようになる。実際は安全な共有を保証するために、物理ブロックの参照カウント（Ref count ）を追跡し、Copy-on-Write メカニズムによって必要に応じてデータをコピーする。同じリクエストに関連する異なるシーケンス間、あるいは異なるリクエスト間でもブロック単位でメモリの共有が可能になる。特に同一プロンプトから複数のシーケンスを生成する際の、並列サンプリングやビームサーチなどのサンプリングアルゴリズムにおいて、メモリオーバーヘッドを大幅に削減することができる。 Paged Attention (5/6) 2 0 2 0

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Slide 23

Slide 23 text

前項で触れた「Request 間でのKV-cache を共有」を行うには、各Request が参照可能な Mapping の保持や管理、Lookup 時のUnique Key などを考える必要がある。 vLLM ではこれをKV-cache Manager が担っている。 Request 間でのKV-cache を共有は、Prefill フェーズの計算効率を上げることに寄与する Automatic Prefix-Caching 2 3 2 3

Slide 24

Slide 24 text

キャッシュを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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

vLLM KV Connector API, NIXL and LMCache 2 9 2 9

Slide 30

Slide 30 text

P/D Disaggregation を実現するためには、何かしらの方法によってKV-cache を複数推論サーバ間で共有する必要がある。 Peer-to-Peer でKV-cache を送受信する共有ストレージを利用してKV-cache を共有する ...etc vLLM ではこの部分をコアロジックから分離しインターフェイスとすることでプラグイン可能にしている。 How to share KV-cache? 3 0 3 0

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

現時点で確認できるV1 実装としては以下がある SharedStorageConnector: サンプル・デバッグ実装。ローカルディスクに書き出す。 MultiConnector: 復数のV1 Connector を束ねるメタコネクタのような実装 P2pNcclConnector: NCCL と統合するコネクタ NixlConnectorV1: NIXL と統合するコネクタ LMCacheConnectorV1: LMCache と統合するコネクタ V0 時点では実装があったMoonCakeStore 向けコネクタがV1 をまだ実装していないように見えるが、LMCache のレイヤーでは既に統合されている V1 Supported Connectors 3 2 3 2

Slide 33

Slide 33 text

NVIDIA 製のXfer Library P2P 通信の高速化を目的としたライブラリ AI Inference Framework におけるTransport として利用する想定 NVIDIA Dynamo で利用されているデータ転送におけるストレージソリューションと最適な転送方式を抽象化するつまり、P2P でKV Cache を転送を最適に実行するためのライブラリモジューラプラグインアーキテクチャを採用しており独自に拡張可能 NIXL (NVIDIA Inference Xfer Library) 3 3 3 3

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

ref : Shapi ng NIXL-based PD Di saggregati on in vLL M V1 LMCache: Two Core KV Cache Functions 3 6 3 6

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

PD disaggregation 向けに、リアルタイムでKV-cache を別ノードに転送する仕組み LMCache はP2P KV transfer をサポートしノードをまたいた再計算をなくしキャッシュを有効に利用する。 NIXL をサポートすることで多様はハードウェア、トランスポートに対応このNIXL による高速なKV-cache transfer は、多くの場合単一のトークンのAttention を計算するより高速 Transport: P2P-Style Direct Transfer 3 8 3 8

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

LLM Inference Framework: llm-d 4 4 4 4

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

ref: https://github.com/llm-d/llm-d llm-d architecture 4 8 4 8

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

リクエストに含まれる、「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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

リクエストの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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

リクエストを一時的に保存する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

Slide 64

Slide 64 text

インメモリ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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

「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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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- modelservice Scorers Filters ... Plugins llm-d overview, resources and data plane 7 1 7 1

Slide 72

Slide 72 text

LLM 推論における性能指標 7 2 7 2

Slide 73

Slide 73 text

本資料では、応答性能に関する代表的な指標と、モデルの精度の指標となるものとして代表的な以下のものを取り上げ簡単に概説するに留める何に対する指標か代表的な指標応答速度に対する性能指標 TTFT / TPOT (ITL) モデルの精度（Code Generation ）に対する指標 Pass@1 詳細の確認や、その他の性能指標については各々確認されたい LLM 推論における性能指標 7 3 7 3

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

pass@1 モデルのコーディング能力を評価する指標モデルが、与えられた問題に対して生成した最初の施行で正しい回答を生成できる確率を示す指標モデル間での性能比較や、量子化により性能影響を比較することができる。 Code Generation 系ベンチマークツールとしてOpenAI のHumanEval や、最近では LiveCodeBench あたりが有名そう（試してないです）精度の指標: pass@1 7 5 7 5

Slide 76

Slide 76 text

まとめ 7 6 7 6

Slide 77

Slide 77 text

LLM 推論ではKV-Cache の取り扱いを始め、計算効率、処理効率を最適化するための技術的な仕組みやルーティングが重要になる vLLM は様々な最適化技術を実装した推論エンジンとして昨今注目を集めている。 LMCache を利用することでvLLM に対してキャッシュレイヤｰの機能を統合できる KV-Cache の転送を最適化するためにNIXL などのソフトウェア、それに準じたHW やストレージなどが要求されてくる可能性がある llm-d はk8s 環境へこれらのインフラをk8s 的に実現する手段の一つ。その他にもNVIDIA Dynamo やKServe など様々なソリューションが存在。自身のインフラにとって最適な選択をするための審美眼が必要。正しい判断をするにはLLM 等の技術に関する正しい知識を持つことが重要になるまとめ 7 7 7 7

Slide 78

Slide 78 text

本資料では具体的なソフトウェアを取り扱いながら、現在の分散推論基盤に求められる機能やその実装方式について詳しく説明してきました。ただし、今回の資料ではカバーしきれていない領域（Attention の最適化や各種量子化、推論時のモデル並列、テンソル並列など）もあるため、まだまだ我々我々が把握すべきことは多いと思っています。本資料が、今後分散推論基盤構築や検証に関わる方にすこしでも参考になれば幸いです。さいごに 7 8 7 8

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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