Inference Serving（推論サービング）

LLM 推論サービングは単発 forward pass でなく、エンジン + スケジューラ + API + マルチテナントルーティング + オブザーバビリティ + オートスケーリング を束ねて SLO (tech-44) を守りつつ多テナントを継続的に捌くインフラ全体。バッチング詳細は tech-43、prefill/decode 非対称は tech-45、高速化スタックは tech-46。

3 層アーキテクチャ

vLLM のように L1+L2 が融合する実装も多い。境界が曖昧化するのは continuous batching (tech-43) がスケジューラと L1 の tight coupling を要求するため。

実行エンジン比較

ライセンスは多くが Apache 2.0、TGI/TRT-LLM は商用条項あり。vLLM は確認時点 2026-05 で 0.6.x → V1 移行中 (スケジューラ・メモリマネージャ・エンジンループを刷新)。

モデルサーバ層

NVIDIA Triton (BSD-3): TensorRT/PyTorch/ONNX/OpenVINO/vLLM/TRT-LLM backend の統一 API、ensemble DAG、L2 dynamic batching scheduler (L1 continuous batching とは別)、response cache、Prometheus、KServe 統合 — 企業内 heterogeneous 基盤。TorchServe: メンテナンスモード移行情報あり (公式日付未確認)、新規は Ray Serve/KServe/Triton 推奨。Ray Serve (Anyscale): Ray Actor で request-level autoscaling、fractional GPU、composition graph、vLLM/TGI backend、KubeRay。KServe (Kubeflow→CNCF Sandbox): InferenceService CRD、Knative ベース scale-to-zero、ModelMesh で多数小モデル動的ロード、Triton/MLServer/vLLM backend。BentoML/OpenLLM は Bento パッケージ、Seldon Core v2 は Pipeline DAG CRD。

ゲートウェイ層

LiteLLM Proxy (MIT): 100+ プロバイダを OpenAI 互換に統一、テナント別トークン/費用追跡、月次予算強制、LB、フォールバック — コスト管理層のデファクト。Envoy AI Gateway (CNCF、2024–25 立上げ): token rate limit/コスト計上/モデルルーティング。Kong AI Gateway: AI Proxy/AI Rate Limiting/AI Prompt Injection を plugin 提供。OpenAI 互換 API は L3 デファクト契約 — /v1/chat/completions (SSE stream: true、tool_calls、logprobs、n) を vLLM/SGLang/TGI/LMDeploy/Ollama すべて実装。vLLM Production Stack (2025) は K8s ヘルム (ルーター + ワーカープール + Redis + Prometheus/Grafana)。

スケジューリングと要求ルーティング

continuous batching (tech-43) はイテレーション単位の差し込みでスケジューラを L1 に内蔵必須、L2 はバッチング権限を L1 に委譲。Triton dynamic batching は L2 queue で別物。PD 分離サービング (tech-45) の L1/L2 写像は (a) prefill プール (compute-bound)、(b) decode プール (memory-bandwidth-bound)、(c) NCCL/RDMA KV 転送 (NIXL/Mooncake が加速)。プレフィックスキャッシュ対応ルーティングは同一 system prompt を一貫性ハッシュで同じワーカーに誘導し KV ヒット率を最大化 (vLLM Production Stack router、AIBrix)。round-robin だと毎回 prefill 再実行で TTFT 悪化 (P3)。KV 対応 LB は QPS でなく KV 使用量でルーティング。SLO-aware admission: TTFT deadline + 優先度キュー + 達成不可は早期 429 で goodput を守る。Prefill burst の head-of-line blocking は priority queue + chunked prefill (tech-45) で緩和。投機的デコード予算: speculative (tech-46) の draft も GPU 時間を消費、負荷依存で gating する adaptive 制御。

マルチテナントとアダプタサービング

S-LoRA (Sheng et al., 2023) は数百〜数千 LoRA を単一ベースで同時サービング、ベース重みは GPU 常駐、アダプタは CPU/NVMe からオンデマンドロード、tensor parallel との相互作用 (per-shard 配置) を処理、バッチ内で異なる LoRA を混在処理。vLLM は --enable-lora/max_loras/max_lora_rank で実装、cold-tenant のアダプタスワップ遅延が数十〜数百 ms 出るため warm pool が要る。テナント分離はテナント ID ごと tokens/min クォータ + per-tenant rate limit (L3) + 高優先度専用キュー or 専用プール + per-tenant cost attribution。

分散サービング

並列化は TP (Attention/FFN 分割、単一ノード NVLink)、PP (レイヤ段階分割、マルチノード低帯域)、EP (MoE expert 分散)、DP (独立レプリカ)。MoE 分散サービング: DeepSeek-V3 (671B/37B active)・Qwen3 MoE は EP 必須、vLLM -tp N -ep M で組合せ、expert dispatch は all-to-all。expert 偏りの負荷不均衡が EP 固有課題。ノード間 KV 転送: NIXL (NVIDIA Inference Transfer Library) が GPU/CPU/NVMe 間直接転送 (Dynamo 統合)、Mooncake (Moonshot AI) は KV プールアーキで分散 KV ストアを複数インスタンスで共有。

オブザーバビリティと SLO

メトリクス定義は tech-44。サービング層は TTFT/TPOT/E2E latency/Queue Time/RPS/TPS/GPU Util vs MFU/KV cache usage を per-request/per-tenant/per-model ラベルで計測。Prometheus: vLLM /metrics は vllm:gpu_cache_usage_perc/num_requests_running/e2e_request_latency_seconds、TGI は tgi_request_duration/tgi_batch_current_size。OpenTelemetry GenAI semantic conventions (2024–25 策定) は gen_ai.system/request.model/usage.input_tokens/usage.output_tokens/response.finish_reason を標準化中。トークンアカウンティング: input/output トークンを API キー or テナント ID で集計 × $USD/1M tokens、LiteLLM が L3 で自動化。goodput vs throughput: SLO 違反を除いた完了レート (goodput) を KPI に据えるのが 2024 以降標準化、throughput 最大化は SLO 違反を増やしうる。

オートスケーリングとサーバレス

HPA カスタムメトリクスは QPS (生成長分散を無視)、in-flight requests (KEDA 組合せ)、KV cache utilization (vLLM 推奨)、queue length (バックログ直接観測)。decode-heavy LLM は後二者が現実的。Scale-to-Zero: KServe Serverless (Knative) はアイドル時 0 縮退でコールドスタートが課題、RunPod Serverless は冷起動数秒〜数十秒。緩和はモデルウォームアップ + prefix cache priming + 共有モデルストレージ (NFS/EFS/GCS Fuse) + provisioned concurrency。スポット GPU は 60–80% 削減、ステートレスでリトライ可、provisioned + spot 混合がスイートスポット。マネージドは AWS Bedrock/Azure AI Foundry/Vertex AI、GPU サーバレスは Replicate/Modal/RunPod/Beam/fal.ai/Together/Fireworks/Anyscale。価格は per-token (マネージド)、per-second GPU (自前)、per-request (小規模)、batch discount (非同期)。2023→2026 で GPT-4 クラス API 単価は大幅低下傾向 (定量未確認)、量子化 + 効率サービング + HW 進化の合成で on-prem vs managed 経済判断を継続的に揺らす。

2026 年フロンティア

vLLM V1 (移行中)、vLLM Production Stack (2025、K8s ヘルム)、AIBrix (ByteDance 2024 OSS、LLM クラスタコントロールプレーン: KV 対応ルーティング + プレフィックスキャッシュ対応スケジューリング + 複数 vLLM 統合管理)、LMCache (cross-request KV reuse、vLLM 統合)、Mooncake (KV プール分散ストア)、NVIDIA Dynamo (2025 発表、PD 分離オーケストレーション: worker 管理 + NIXL KV 転送 + スケジューリング統合)。標準化: OpenAI API がデファクト L3 契約、MCP (Anthropic) が tool/context routing 標準候補、OpenTelemetry GenAI が L2/L3 トレーシング標準。

ピットフォール

• P1: ナイーブ動的バッチング ≠ continuous batching — preferred-batch-size + queue-delay 型は static 改良で batch 境界の同期が残り head-of-line blocking が消えない。L1 内蔵スケジューラ必須 (tech-43)。
• P2: 「最新 vLLM 使えばいい」 — バージョン間で API・設定・モデル対応が変動、tokenizer/model 版ずれが推論バグを招く。transformers 含む依存を固定し本番分布で再ベンチ。
• P3: プレフィックスキャッシュ無視のルーティング — 共有 system prompt の RAG/agent で round-robin だと毎回 prefill 再実行で TTFT 著しく劣化。
• P4: max_num_seqs 過剰設定 — 同時シーケンス上限を大きくすると KV 多数確保し prefill バーストで GPU OOM、長コンテキストモデルで特に注意、KV 利用率を HPA で自動制御。
• P5: グローバル単一キュー — 長 prefill (8K) と短 prefill (50) を同キューに混ぜると長 prefill が短いリクエストを遮断、priority queue + chunked prefill (tech-45) で緩和。
• P6: CPU offload ページアウト忘却 — vLLM cpu_offload_gb を使わないと長コンテキストで GPU OOM、CPU↔GPU 転送コストとの trade-off。
• P7: 対話型とバッチを同プール混在 — TTFT<500ms の対話型と throughput 優先バッチを混ぜるとバッチが対話型 SLO を侵害、プール分離 or 優先度スケジューラ必須。
• P8: コスト按分 tokens vs GPU 秒 — 長 CoT は出力短くても GPU 秒大、トークン単価では過小評価、課金モデルはワークロード特性に合わせる。

未確認事項 (確認時点 2026-05)

情報カットオフ 〜2025-08 のため、2026-05 時点で要再確認: (1) vLLM V1 の正確なリリース日・バージョン番号、(2) TorchServe メンテナンスモード移行の公式発表、(3) TGI v1.0 以降のライセンス変更詳細、(4) NVIDIA Dynamo の正式リリース日と機能セット、(5) AIBrix の最新リリース、(6) LMCache の vLLM 統合ステータス、(7) Mooncake の OSS 公開範囲、(8) NIXL の公開 API/ライセンス、(9) OpenTelemetry GenAI semantic conventions の Stable 昇格状況、(10) Envoy AI Gateway の GA ステータス、(11) Seldon Core v2 の現行ライセンス、(12) per-token コスト動向の定量数値、(13) vLLM Production Stack の正確なリリース日。