TT Lab
ブログ

한국어 English 日本語 中文

はじめる
ブログ

ブログ

分散推論と NVIDIA Dynamo：並列化、prefill/decode分離、KVキャッシュ転送

2026-10-07 · 33 分で読めます · #LLM서빙#분산추론#Dynamo#병렬화#prefill-decode분리#KV캐시#NIXL#쿠버네티스#토스 ML/AI Infra 준비

ステータス：ドラフト（2026-10-05、バナーは2026-10-07に更新）。 本文は公式ドキュメントで確認した記述であり、この記事の数値も依然としてドキュメントに基づいています。 Dynamoを1枚のGPU環境に直接インストールして実測したコスト（フロントエンドのコスト、KV認識ルーティング、1枚のGPU上でのprefill/decode分離）は 第24回に個別に記載しています。異なるGPUの2つのサーバー間（1GbE級ネットワーク）での分離サービングについても第24回4.5節で測定しており、NVLinkとRDMA環境は依然として 未実測 です。 記事の終わりの「確認したバージョンと日付」および「確認できなかったこと」を先にお読みください。 作成ルール：実測データを基本とし、測定できなかったものは「未実測」と表記します。

目次

概要

大きなモデルは1枚のGPUに収まらないため、重みを複数のGPUに分散させる必要があります。分割方式（テンソル・パイプライン・専門家・データ並列）ごとに通信量とレイテンシが大きく異なるため、ノード内では帯域幅の広い方式を、ノード間では通信の少ない方式を採用する傾向があります。また、prefill（プロンプト処理）とdecode（トークン生成）はリソースの特性が異なるため、プールを分けることで互いに干渉しなくなりますが、その代わりKVキャッシュを移動させる必要があります。NVIDIA Dynamoは、この分離、KV認識ルーティング、自動スケーリングをエンジン上で調整するレイヤーです。

この記事を読むことで面接で説明できるようになること

  1. テンソル・パイプライン・専門家・データ並列がそれぞれ何を分割し、どのような通信を引き起こすのか、およびノード内とノード間で選択が分かれる理由。
  2. prefill/decode分離の動機と代償をKVキャッシュサイズの計算を用いて説明し、利益となるワークロードと損となるワークロードを分ける基準。
  3. Dynamo v1.5.0のコンポーネントが1件のリクエストをどのように処理するか、llm-d、vLLM、SGLangとの違い。

執筆者の立場。 私は一般のイーサネット（1〜2.5GbE級）環境で実験を行っており、RDMA、InfiniBand、NVLinkの経験はありません。この記事は公式ドキュメントと論文を読んでまとめたものであり、直接測定した値はLMCacheの実験が1つあるのみです。

1. モデルを分割する4つの方法

並列化 何を分割するか 通信パターン 特性
テンソル（TP） 1層の行列積を複数のGPUに分割 層ごとにall-reduce 頻繁であり、レイテンシに敏感
パイプライン（PP） 層を前後の区間に分割 区間の境界でポイントツーポイント転送 少なく、鈍感。その代わりbubble（アイドル時間）が発生
専門家（EP、MoE） 専門家の重みをGPUに分散 層ごとにall-to-all（dispatch、combine） 帯域幅とレイテンシの両方に負荷がかかる
データ（DP） モデルの複製を複数配置 推論においては複製間の通信がほとんどない MoEではattentionのみをDPとする構成が一般的

通信量はNarayanan他（2021）の論文の式で見積もります。PPは隣接する区間間でマイクロバッチあたり b·s·h 個の要素（バッチ、シーケンス長、隠れ次元の積）を送信します。TPは学習基準で層ごとにデバイスあたり 8·b·s·h·(t−1)/t を送受信しますが、これは順伝播と逆伝播でall-reduceが2回ずつ行われるためです。推論には逆伝播がないため、順伝播分のみを残すと 4·b·s·h·(t−1)/t になります（筆者の導出）。

説明用の例（実測値ではありません）。 Qwen3-32B（隠れ次元5120、64層）に対して8,000トークンのプロンプト1つをTP=8でprefillし、bf16で計算する場合、層ごとにデバイスあたり約287MB、64層全体で約18GBがall-reduceとしてやり取りされます。同じリクエストでPPの境界を1つ越えるデータは約82MBです。

そのため、論文ではTPをサーバー内のGPU数まで使い、それを超える分はPPに増やすべきだとまとめられています（Takeaway #1、学習の文脈）。vLLMのドキュメントでも、TPをノードあたりのGPU数に、PPをノード数に設定するよう指示されており、NVLinkのないGPU（L40Sなど）ではPPの方が優れていると記載されています。帯域幅の違いは仕様からもわかります。NVIDIAはNVLink第4世代をGPUあたり900GB/s、第5世代を1,800GB/s（双方向の合計）と表記しており、ConnectX-7の1枚あたりの帯域幅は400Gb/s（方向あたり約50GB/s）です。DeepSeek-V3のレポートにおけるH800クラスターは、NVLink 160GB/s対InfiniBand 50GB/sでした。

EPはトークンを専門家が存在するGPUに送信し、結果を返送するため、層ごとにall-to-allが発生します。DeepSeek-V3はトークンが最大4つのノードにしか到達しないようにルーティングを制限してInfiniBandのトラフィックを削減し、デプロイ単位をprefill 32 GPU（EP32）、decode 320 GPU（EP320）に設定しました。vLLMでは --enable-expert-parallel を有効にするとEPサイズが TP × DP になり、通信バックエンドとしてprefillに deepep_high_throughputを、decodeに deepep_low_latency を使用するよう案内されます。

 [노드 A: TP=4]                          [노드 B: TP=4]
 GPU0 GPU1 GPU2 GPU3 -- PP 경계 --> GPU4 GPU5 GPU6 GPU7
  └ NVLink all-reduce ┘  (활성화 텐서,    └ NVLink all-reduce ┘
    층마다, 지연 민감       점대점, RDMA)      층마다, 지연 민감

2. prefill/decode分離：なぜ行い、何を支払うのか

動機。 Dynamoのドキュメントでは、prefillを演算中心、decodeをメモリ中心と説明しており、そのためdecodeにより大きなTPを、prefillにより小さなTPを割り当てることができるとしています。SGLangのドキュメントでは、1つのエンジン内で混在させると、新しいprefillが実行中のdecodeを中断し、トークン生成が遅延すると説明しています。vLLMのドキュメントは、TTFT（最初のトークンまでの時間）とITL（トークン間の遅延）を個別に調整でき、テールITLを制御できることを理由として挙げつつ、分離によってスループットが向上するわけではないと明確に記しています。論文側では、DistServeがチャットボットにおいてvLLMと比較してリクエストレート2.0〜4.6倍（DeepSpeed-MIIと比較して1.6〜7.4倍）、要約においてSLOを最大12.6倍厳格に満たすと報告しており（異なるアプリケーションと比較対象の最大値であるため、1つの構成で同時に得られた値ではありません）、Splitwiseは既存のクラスターと比較してスループット1.4倍、コスト20%削減、または同等の電力で2.35倍を主張しています（クラスター規模の利得は実測ではなくシミュレータの結果です）。どちらも70Bから175B級のモデルと高速な接続（NVLink内の配置、InfiniBand 200/400Gbps）という論文の条件の下で得られた値です。本文の数値は、以下の「外部の根拠」で直接確認しました。

代償：KVキャッシュを移動させなければなりません。 トークンあたりのKVサイズは 2(K와 V) × 층 수 × KV 헤드 수 × 헤드 차원 × 바이트 수 です。Qwen3-32Bの config.json（64層、KVヘッド8、ヘッド次元128、bf16）で計算すると、トークンあたり256KiB、8,000トークンであれば約2.1GBになります。

転送経路 理論上の線速度 2.1GBの転送時間（説明用の計算、オーバーヘッドを無視）
1GbE 0.125GB/s 約16.8秒
2.5GbE 約0.31GB/s 約6.7秒
100GbE 12.5GB/s 約0.17秒
400Gb/s（NIC 1枚） 50GB/s 約0.042秒

筆者の実測。 Qwen2.5-1.5Bを8GB級のノートPC用GPU上でvLLM + LMCacheを用いて動かした実験です。ドキュメントあたり4,864トークン（0.13GB）のKVをCPUメモリからGPUにロードするのに約8〜9ms、同じ5,000トークンを新しく計算するのに約560msかかりました。このモデルのトークンあたりKVは28KiBであるため、4,864トークンが0.13GiBとなり、ログの0.1299と一致します。ただし、これは同一ノード内のCPUからGPUへの移動であり、ネットワーク転送ではありません。また、同時実行数1、モデル1.5B、合成ドキュメント、単一の測定値です。読み取れる結論は「移動させる方が再計算する方よりもコストが低い場合がある」という方向性までであり、ネットワーク区間で成立するためには上記のように帯域幅がサポートしている必要があります。

Dynamoのドキュメントセットには、TCPでKVを移動させるとTTFTが約98秒、RDMAであれば200〜500msになると記載されています。2つの数値の性質は異なります。98さんはLlama-3.1-8B、入力8,000トークン、AWS p5.48xlargeにおいて、 EFA PodのNIXLがUCXの低速パスに暗黙的にフォールバックした際 に測定された値であり（ドキュメントでは解決策としてNIXLバックエンドにLIBFABRICを指定するよう案内されています）、200〜500msはドキュメントが「仕様に基づく期待値」として記載している値です。同じ条件のEFAで実際に測定されたKV転送の追加分は37msでした。したがって、「TCPは98秒、RDMAは0.5秒」を一般的な比較として捉えてはなりません（以下の「外部の根拠」を参照）。

3. KVキャッシュはどのような経路で移動するか

転送ライブラリはNIXL（NVIDIA Inference Xfer Library）です。メモリの種類（HBM、DRAM、ファイル、オブジェクトストレージ）を抽象化し、プラグインによってバックエンドを選択します。ドキュメントで挙げられているバックエンドはUCXとGPUDirect Storageであり、DynamoのドキュメントにはUCXまたはlibfabricを経由すると記載されており、SGLangはMooncakeとNIXLをサポートしています。ノード内ではCUDA IPCによるNVLinkを、ノード間ではRDMAを使用します。

方向は「decodeがprefillから引っ張る（pull）」形式です。llm-dのドキュメントはそのように記述しており、vLLMのNixlConnectorはprefill側のKVブロックをデフォルトで30秒のリース（lease）で保持します。運用にあたって知っておくべき点が4つあります。第一に、 NCCL_IB_HCA のようなNCCL変数はNixlConnectorには適用されず、 UCX_TLS, UCX_NET_DEVICES を使用する必要がある点です。第二に、Dynamoのドキュメントによると、同一ノード内の異なるポッド間でもNVLinkがブロックされ、NIC経由で転送する必要がある点です。第三に、Kubernetesにおける /dev/shm のデフォルト値（64MB）はNIXLの初期化には不十分であるため、 sharedMemory を16Giに引き上げるよう案内されている点です。第四に、vLLMのドキュメントは kv_role="kv_both" を非推奨（廃止予定）に指定している点です。 kv_producer/kv_consumer の使用が推奨されますが、Dynamo 1.5.0のドキュメントの例はまだ kv_both を使用しています。

4. Dynamo v1.5.0の構造

Dynamoはエンジンを置き換えるのではなく、vLLM、SGLang、TensorRT-LLM上で複数のノードを調整します。ランタイムはRust、拡張はPythonです。

flowchart LR
  C[클라이언트] -->|HTTP 8000| F[Frontend<br/>토큰화·검증]
  F --> R[Router / PrefillRouter]
  R -->|1 prefill 요청| P[Prefill Worker]
  P -->|2 disaggregated_params| R
  R -->|3 decode 요청+메타데이터| D[Decode Worker]
  P -.->|4 KV 전송 NIXL| D
  D -->|5 토큰 스트림| F
  PL[Planner] -.->|복제본 수 조정| P
  PL -.-> D
  DS[(Discovery: K8s 또는 etcd)] -.-> F

Kubernetes。 Dynamo OperatorがCRDを調整します。核心は DynamoGraphDeployment（DGD、フロントエンドとワーカーで構成される推論グラフのセット）であり、 DynamoComponentDeployment, DynamoGraphDeploymentRequest（DGDR、モデル・ハードウェア・SLAを記述するとプロファイルしてDGDを生成）、 DynamoGraphDeploymentScalingAdapter（HPA/KEDA連携）、 DynamoModel がさらにあります。v1.5.0で nvidia.com/v1beta1 が保存バージョンとなり、 spec.components のリストに type: frontend|worker|prefill|decode を使用します。複数のノードにわたるワーカーはGrove（デフォルト）またはLeaderWorkerSetがないと、Operatorがエラーを返します。以下はドキュメントの例（Qwen3-32B）を簡略化したものであり、実際に適用してみたものではありません。

apiVersion: nvidia.com/v1beta1
kind: DynamoGraphDeployment
spec:
  components:
  - {name: Frontend, type: frontend}
  - name: VllmPrefillWorker
    type: prefill
    sharedMemorySize: 16Gi
    # args: --model Qwen/Qwen3-32B --disaggregation-mode prefill
    #       --kv-transfer-config '{"kv_connector":"NixlConnector",...}'
  - name: VllmDecodeWorker
    type: decode        # args 는 같고 --disaggregation-mode decode

5. llm-d、vLLM、SGLangとの位置づけの違い

項目 Dynamo llm-d vLLM単体 SGLang単体
性格 エンジン上の調整レイヤー Kubernetes中心のスタック、CNCF sandbox エンジンの実験的機能 エンジン内蔵PD分離
リクエストのエントリ 独自のFrontendまたはGateway APIのEPP Gateway API Inference Extension規格プロキシとEPP 自作のプロキシ（ドキュメントではtoyの例） SGLang Model Gateway（旧Router）
KV転送 NIXL（UCXなど） NIXL、RDMA推奨、TCP代替可能 NixlConnector、Mooncake、LMCacheなど Mooncake、NIXL
自動スケーリング Planner（SLAベース） SLO認識オートスケーリングの紹介 読んだドキュメントでは確認できず 読んだドキュメントでは確認できず

これら3つのプロジェクトは排他的ではありません。Dynamo 1.5.0のリリースノートにllm-dバッチゲートウェイの例があり、どちらもvLLM・SGLangをモデルサーバーとして使用します。どちらがより高速かは確認できていません。llm-dの「最大70%のスループット」（B200、AWS）とDynamoの「TTFT 2倍」（Baseten）は、条件が異なるだけでなく 測定対象が異なります。 70%はprefill/decode分離のスループット（GPT-OSS、入力と出力1,024トークン）、2倍は分離ではなくKV認識ルーティングのTTFT（Qwen3-Coder 480B、入力約5万トークン、ランダムルーティング比較）であるため、両者を並べて優劣を読み取ることはできません。

6. 分離が利益をもたらすケースと損失をもたらすケース

Dynamoのドキュメントを基準とすると、 利益となるのは、長いプロンプトによりprefillのコストが高い場合、高い同時実行性によりdecodeがボトルネックとなっている場合、2つのプールを個別に拡張したい場合、2つの段階で異なる並列化が必要な大規模モデルの場合です。llm-dは、入力対出力が10:1の長いコンテキストを推奨事例として挙げています。 損失となるのは、小規模モデル、短いプロンプト、低い同時実行性、高速なKV転送ネットワークがない場合であり、統合（aggregated）デプロイの方がシンプルであり、通常はより高速です。ドキュメントでは、decode KVの容量がボトルネックであるときにprefillレプリカを増やすと、全体的な容量が低下する可能性があることも警告しています。

Dynamoの対応策は 条件付き分離（conditional disaggregation、実験的） です。ルーターがdecodeワーカーのKVの重複を除いた残りの有効入力長がデフォルトで2048トークン未満であり、元の長さに対する割合が0.7未満である場合、prefillワーカーを経由せずにdecodeワーカーがprefillまで処理します。マルチターン対話のようにプレフィックスの再利用が多いケースをターゲットにしており、vLLMの双方向KV転送（prefillがdecodeの持つ以前のターンのKVを取得する）も同じ問題意識に基づいています。

7. 実際に試してみる

RDMAとマルチGPUノードがない場合、分離サービングを再現することはできませんが、可能な範囲は以下の通りです。

  1. KVサイズの計算（環境変更なし）。 モデル config.json においてトークンあたりのKVを計算します。
    python3 -c "import json,sys;c=json.load(open(sys.argv[1]));h=c.get('head_dim',c['hidden_size']//c['num_attention_heads']);print(2*c['num_hidden_layers']*c['num_key_value_heads']*h*2,'bytes/token(2바이트 가정)')" config.json
  2. KVのロードコストの測定。 2節の実験のように一時的なPodからvLLMとLMCacheを実行し、CPUメモリからKVをロードする時間と新しく計算する時間を比較します。終了したらPodを削除します。ノードメモリを他のワークロードと共有している場合は、制限を増やす前に空き容量を確認する必要があります。
  3. TCPでNIXLを動かしてみる（未検証）。 GPUが1枚ずつの2台のサーバーでprefill/decodeインスタンスを起動し、 UCX_TLS をTCP系に制限してTTFTが上記の表の1GbEの行のように増加するかを確認する実験です。この記事の執筆時点では実行しておらず、動作も保証できません。GPUが他のワークロードによって占有されている可能性があるため、実行前の確認が必要です。外部の測定によると、100Gb/sのTCPでもGPU間の転送は実装に応じて0.55GB/s（UCX）から約4.8GB/s（UCCL）まで分かれるため、1GbEの行の理論上の線速度は実際にはさらに遅い可能性があります（以下の「外部の根拠」を参照）。（2026-10-07追加：異なるGPUを持つ2台のサーバー間で、第24部4.5節で直接測定しました。UCXのデフォルト設定（TCP）で1,500単語入力の初トークンが1.7秒、3,000単語は3.4〜3.5秒となり、単独サービング（44〜172ms）の20倍以上に増加しました。1つのGPU内で UCX_TLS をTCP系に制限したバリエーションは、デフォルト設定と同じ速度でした。）
  4. ノード間のTCPスループットの直接測定値（計算に必要な最小限の実測値）。 異なる3ペアのノード（Podネットワーク、 iperf3 10秒）において、単一ストリームで894〜902Mbit/s、4ストリームで901〜912Mbit/sと、いずれも1GbE級（約112MB/s）でした。このネットワークでトークンあたり114,688バイトである1.7Bモデルの8,000トークンのKV（約917MB）を転送すると約8秒かかり、同じ入力を8GB級のGPUが再計算するのにかかる時間は約1秒（第21部）です。つまり、 小規模モデルと1GbEでは分離サービングが損失となる（転送が再計算の8倍遅い）という第6節の記述が計算によって確認されます。2つのインスタンスを直接接続したエンドツーエンドのTTFTは、第24部4.5節で測定しました。0.6Bモデル（トークンあたりのKVが114,688バイトで同じ）の3,000単語のリクエストは、転送あたり351.75MBを104MB/sで3.4秒かけて転送し、初トークンは3.4〜3.5秒となり計算結果と一致しました（単独時は83〜172ms）。

外部の根拠：論文や公式資料で確認された内容

分離サービングはデータセンター級の設備なしには再現できないため、この記事の数値的な主張はすべて一次資料に当たり、条件とともに確認しました。外部の数値は当方の環境（小規模モデル、GPU 1枚、1GbE）と条件が異なるため、直接比較は行わず方向性の判断のみに使用しました。

テーマ 資料と確認した箇所 確認した内容と条件 この記事との関係
98秒 vs 200〜500ms Dynamo v1.4.2 ドキュメント「Disaggregated Inference Communication Guide」（Performance Expectations、Break-Even Analysis）、v1.5.0 rdma-setup/efa-on-aws 98秒は Llama-3.1-8B、入力8,000トークン、AWS p5.48xlargeのTCP代替経路での測定値。200〜500msはInfiniBandの仕様に基づく期待値（測定ではない）。同一条件でのEFA実測KV転送追加分は+37ms（約9.6GB/s）。同ドキュメントでは、98秒はUCXが遅い経路にフォールバックした誤設定の事例であると説明されている。 限定的に支持。 方向性（TCPがはるかに遅い）は合致しているが、一般的なTCPの値ではない。本記事の記述を修正。
DistServe Zhongら、OSDI 2024、arXiv 2401.09670、セクション1・2・6.1〜6.4・7 A100-80GB 32枚、ノード内NVLinkおよびノード間25Gbps。チャットボットのvLLMと比較してリクエストレートが2.0〜4.6倍（DeepSpeed-MIIと比較して1.6〜7.4倍）、要約SLOが12.6倍厳格。KV転送はOPT-175Bにおいて全体遅延の0.1%未満（ノード内配置で解決）。セクション7では、GPUが1枚または数枚程度の環境では効果を出しにくいと記載されている。 支持。 ただし、いずれもOPT-13B〜175B級の大規模モデルの条件である。
Splitwise Patelら、ISCA 2024、arXiv 2311.18677、概要・セクションIV-C・VI 実際のハードウェアはDGX-A100・H100が各2台（InfiniBand 200・400Gbps）、 クラスターの利益はシミュレーション。同一電力でスループット2.15倍、同一コストで1.4倍（電力25%増）、レイヤー別転送の見かけ上の転送時間はprefill計算の7%未満。10分の1の帯域幅については推測のみでテストされていない。 支持。 「コスト20%削減で1.4倍」は異なる構成の値であり、同時に得られたものではない。
Mooncake Qinら、USENIX FAST 2025（arXiv 2407.00079）、セクション5.2・5.4 A800ノード（RDMA 800Gbps級）、ダミーのLLaMA3-70B。有効リクエスト容量が+59%から+498%になるが、利益にはKVキャッシュプールとキャッシュ認識スケジューラーが混ざっており、分離単体の効果ではない。入力が短いツール・エージェントワークロードでは+42%、公開データセットでは+20〜40%。帯域幅が100Gbps未満の場合はTTFTが急増するため、最低100Gbpsが推奨される。 限定的に支持。 利益が長文、大規模モデル、高速なRDMAに依存するという第6節の記述を裏付け
利益が消える条件 DynamoコミュニケーションガイドのBreak-Even表（Llama-3.1-8B、p5.48xlarge、同時実行数10）。Mitra他（NVIDIA）、「Beyond the Buzz」、arXiv 2506.05508。Wang他、TaiChi、arXiv 2508.01989 入力1,000トークンでスループット利益約0%、2,000トークン +3%、4,000トークン +14%、8,000トークン +22%。利益はprefillが重いトラフィックと大規模モデル（10B超）で最も大きく、小規模モデルや生成が重いトラフィックでは制限的。統合はTTFTが厳しいとき、分離はTPOTが厳しいときに有利 支持。 第6節の「損失」条件と一致。同時実行数に応じた曲線を示す公開計測は見つからず
llm-d 70%、Dynamo 2倍 AWS MLブログ（2026-03-16）、Basetenブログ（2025-10-16） 70%：分離、1秒あたりのトークン、GPT-OSS、B200のEFA、入力・出力1,024トークン、基準デプロイのレプリカ数が不明確。2倍：KV認識ルーティングによるTTFT 50%削減（ランダムルーティングと比較）、Qwen3-Coder 480B、入力約5万トークン 支持（比較不可）。 測定対象が異なり、優劣を読み取ることができない
TCPによるKV転送 llm-dブログ「Networking for Distributed Inference in llm-d」（2026-06-23）、Mooncake第5.4節、vLLM NixlConnectorドキュメント 100Gb/s TCPにおけるGPU間転送は実装ごとにUCX 0.55GB/s、UCCL約4.8GB/s（RoCEとInfiniBandは線速度の97〜99%）。Mooncake転送エンジンはTCPより2.4倍および4.6倍高速。1〜2.5GbE級の測定は見つからず 限定的に支持。 「必要」ではなく「推奨」、TCPは実装に大きく依存。1GbEは我々が直接測定（第7節4番）
マルチノード通信コスト DeepSeek-V3技術報告書（arXiv 2412.19437）第3.2・3.4節、Singhania他（arXiv 2511.09557） トークンを最大4つのノードに制限、decode EP320、NVLink 160GB/s対IB 50GB/s。ノード間TPの強い拡張性が悪く、decodeが重いバッチではPPもTPに劣る事例 支持。 第1節のノード内TP、ノード間通信が少ない方式の記述は傾向として正しいが断定はしない

ベンダー（NVIDIA、AWS、Baseten、llm-d）の数値は条件が本文に記載されているもののみ転載しました。2つのllm-d README項目の元のブログとMegatron-LMの通信量公式を開けなかったため、数値を記載していません。

8. 面接で出そうな質問

  1. 70BモデルをGPU 8枚構成のノード2台にデプロイする場合、並列化をどのように設定しますか？ ノード内にはNVLinkがあるためTP=8、ノード間は通信が少ないPP=2に設定します。ただしPPにはバブルが発生するため、モデルが1つのノードに収まるのであればノードごとにTPレプリカを置き、DPでスケールアウトする方が望ましいと付け加えます。
  2. prefill/decode分離はなぜ行い、いつ行わないのですか？ 演算中心とメモリ中心というリソース特性の違いや、互いの干渉を解消してTTFT、ITLを個別に制御することが動機です。KV転送とGPU分割が代償となるため、短いプロンプト、低い同時実行数、低速なネットワークでは統合の方が優れています。
  3. 8KトークンのプロンプトのKVを100GbEで送信すると、どれくらい時間がかかりますか？ トークンあたりのKV（Qwen3-32Bは256KiB）により約2.1GBであり、線速度12.5GB/sであれば理論上0.17秒です。実際にはさらに時間がかかるため、TTFTの目標と比較してRDMAが必要かどうかを判断すると回答します。
  4. KV認識ルーティングの利点とリスクは何ですか？ プレフィックスを持つワーカーに送信することでprefill計算をスキップしTTFTが短縮されますが、キャッシュを持つワーカーに集中するとホットスポットになります。Dynamoはキャッシュクレジットとアクティブ負荷を1つのコスト関数に入れ、効果は random|round-robin と kv を同じ負荷で比較して確認するよう案内しています。
  5. PlannerはHPAと何が異なりますか？ CPUやリクエスト数ではなく、TTFT、ITL SLAやprefill/decode別のシグナル（キューの深さ、KV使用率）を使用し、トラフィックを予測します。スケールダウン時に処理中のリクエストが失敗する可能性があるため、最小レプリカ数の下限を設定します。

9. よくある誤解

参考文献（実際に参照したもの）

確認したバージョンと日付、確認できなかった事項

確認日は2026-10-05です。GitHubリリースAPIによりDynamo v1.5.0（2026-09-21、バンドルエンジンSGLang v0.5.18、TensorRT-LLM v1.3.0rc25、vLLM v0.28.0）、NIXL v1.5.0（2026-09-30）、llm-d v0.10.0（2026-09-29）、vLLM最新v0.30.0、SGLang最新v0.5.21を確認し、ドキュメントサイトの latest もv1.5.0です。

確認できなかった事項：（1）Dynamoドキュメントの一部がまだv1alpha1と kv_both の例を使用している理由。（2）llm-d・Dynamo・SGLang間の性能優劣（測定対象が異なるため比較自体が困難です）。（3）第7節3番の実験（2台のサーバーでTCPによりNIXLを実行してTTFTを検証するテスト）は2026-10-07に第24編第4.5節で実行しました（1GbE級リンクのみ、RDMAではありません）。（4）2つのllm-d README項目の元のブログの一部とMegatron-LM論文の通信量公式を開けなかったため記載していません。98秒および200〜500msの条件（確認済み）、DistServe・Splitwiseの本文数値（確認済み）は「外部根拠」にあります。

ログインするといいねできます

コメント

まだコメントはありません。

ログインするとコメントできます