LLM Inference / Serving 项目地图

本页回答“谁拥有哪一层职责，以及控制面如何把容量变成可接流量的 endpoint”。vllm / sglang 是执行引擎，dynamo 组织分布式 runtime，llm-d / aibrix 提供范围不同的 serving 与控制能力；这些层不能当成同类替代品。组合选择见 llm-serving-engine-selection-map。

请求执行的统一入口是 llm-inference，P/D 与 KV 交接见 disaggregated-serving，选点与异步信号见 inference-routing。本页只展开 Kubernetes 控制面及就绪传播，避免重复维护请求/KV 流程图。

当前上游核验（2026-10-03）

下表是 2026-10-03 对官方 GitHub release、固定 tag 源码及官方文档的直接核验。发布日期为 GitHub API 的 UTC 日期；release 标签与 latest/dev 文档分别记录，不推定二者完全一致。frontmatter 中的 Source 页面保留旧分析时点，其调用路径和配置不能自动外推到今天。

[!warning] Conflict
2026-10-03 核验时，llm-d v0.9 架构页仍并列 HPA/KEDA 与 WVA；dev 架构页已将 WVA 标为 deprecated，v0.10.0 release也确认 WVA 指南废弃并将仓库重命名为 llm-d-autoscaling。src-llm-d-workload-variant-autoscaler-architecture 与 llm-d-workload-variant-autoscaler 是历史设计参考，部署应核验目标 release 的扩缩路径，不能照搬旧 WVA 方案。

一句话分层

A4 · Kubernetes Serving 控制面

flowchart TB
    subgraph CTRL["Control plane：期望与异步收敛"]
        Intent["模型 / SLO / 拓扑意图"]
        Config["CRD / Deployment / 平台配置"]
        Decide["Autoscaler / Planner / HPA：计算并写入目标"]
        Desired["已持久化 workload /scale 或平台角色池目标"]
        Reconcile["Operator / workload controllers：收敛 Pods"]
        Keda["KEDA：读取外部指标并配置与拥有 HPA"]
        Intent -.-> Config
        Config -.-> Decide
        Decide -.-> Desired
        Desired -.-> Reconcile
        Keda -.-> Decide
    end
    subgraph WORK["Worker lifecycle"]
        Pool["Worker pools / Pod startup"]
        Load["Model load / warmup"]
        Ready["Readiness：模型已可服务"]
        Engine["Ready engine workers / local KV"]
        Pool -.-> Load
        Load -.-> Ready
        Ready -.-> Engine
    end
    Discover["Endpoint discovery / EndpointSlice / registry"]
    subgraph REQ["Request plane：接入、选点与执行"]
        Client["Client"]
        Proxy["Gateway / Frontend"]
        Picker["Router / EPP：endpoint decision"]
        Client --> Proxy
        Proxy -->|"咨询选点"| Picker
        Picker -->|"返回 endpoint"| Proxy
        Proxy -->|"转发请求 / stream"| Engine
    end
    subgraph EVENT["Event / metrics plane：异步观察"]
        Metrics["Queue / token backlog / SLO / GPU metrics"]
        KV["KV events / locality index"]
    end
    Reconcile -.-> Pool
    Config -.-> Discover
    Ready -.-> Discover
    Discover -.-> Picker
    Engine -.-> Metrics
    Proxy -.-> Metrics
    Engine -.-> KV
    Metrics -.-> Decide
    Metrics -.-> Keda
    Metrics -.-> Picker
    KV -.-> Picker

图注：这是 Kubernetes 部署的逻辑职责图，实线代表请求/选点交互，虚线代表异步控制、生命周期推进或信号。假设 readiness 检查覆盖模型可服务状态，endpoint 发现再把该状态传播给选点方。HPA 根据指标计算副本目标并写入 workload 的 /scale；workload controllers 再收敛 Pods。平台 Planner 也可写自己的角色池目标，由 Operator 转换并执行。图中是候选控制路径，每个目标只应有一个扩缩写入者。

不要从图中推断 Dynamo、llm-d、AIBrix 实现同一组框或能直接互换。Dynamo 的 Planner/Operator 控制连接、llm-d 的 EPP/KEDA/HPA 组合、AIBrix 的 Gateway/controller/runtime 组件拥有不同接口和对象。InferencePool/HTTPRoute 是配置与发现契约，Proxy/Frontend 才承接连接；EPP 咨询不要求 token stream 穿过 EPP 进程。控制权、信号时效及故障边界见 model-serving-operator、inference-routing。

S3 · 扩缩与就绪传播时序

sequenceDiagram
    participant M as Metrics / EPP queue / SLO
    participant K as KEDA 可选指标适配
    participant D as Autoscaler / Planner / HPA
    participant A as Workload scale / 平台角色池目标
    participant C as Operator / workload controllers
    participant P as New worker Pod
    participant L as Model loader
    participant E as Endpoint discovery
    participant R as Gateway / Router
    alt llm-d 的 KEDA 与 HPA 路径
        M-->>K: 提供 EPP 外部指标
        K-->>D: 配置与拥有 HPA 并提供评估后的指标
    else Planner 或其他 autoscaler 路径
        M-->>D: 观察排队、负载与 SLO 偏差
    end
    D->>D: 根据指标与策略计算期望容量
    D-->>A: 持久化 workload /scale 或平台角色池目标
    A-->>C: watch / reconcile 目标变化
    C-->>P: 收敛 workload 并等待调度后的 Pod 启动
    Note over D,R: Scale-up lag 从采样与决策持续到 endpoint 可路由
    R->>R: 现有容量承载流量并执行有界队列与 load shedding
    P->>L: 加载模型并执行 warmup
    alt 模型加载成功且 readiness 通过
        L-->>P: 模型可服务
        P-->>E: 发布 Ready endpoint
        E-->>R: endpoint 集合更新
        R->>P: 新请求变为 routable
        P-->>M: 发布新容量指标
    else 模型加载失败或超时
        L-->>P: 加载失败
        P-->>C: NotReady / failure 状态
        P-->>E: 不发布或撤销 Ready endpoint
        E-->>R: 传播不可用状态
        C-->>D: 容量缺口与失败反馈
        R->>R: 按预算排队、拒绝或选择健康 endpoint
    end

图注：这是一次扩容的逻辑时序，虚线表示异步状态/信号传播，横向距离不表示时长。假设所选 autoscaler、部署控制器和 discovery 能形成反馈闭环；GPU 容量不足、镜像拉取失败还可能让 Pod 在加载模型前停滞，同样不能计入可服务容量。

HPA 位于决策与目标写入侧：它计算 desired replicas 并更新目标 workload 的 /scale，不负责创建或收敛 Pods；Operator 与 Deployment 等 workload controllers 负责后续执行。平台 Planner 可改写自己的角色池目标，再由 Operator 收敛。在 llm-d 路径中，KEDA 的 Prometheus scaler 读取 EPP 信号，KEDA 配置并拥有 HPA、向其提供外部指标，HPA 执行副本决策。见 Kubernetes HPA、KEDA 概念与 llm-d dev 扩缩说明。这里聚焦非零副本扩容，KEDA 的零副本激活路径需另按配置核验。

不要从图中推断期望副本增加即等于可用容量增加，或 Ready 保证后续每次请求成功。采样窗口、决策周期、GPU provisioning、镜像/权重下载、warmup 和发现传播均进入 scale-up lag；有界队列、admission/load shedding 必须显式配置。缩容需停止新选点、排空在飞请求，再终止 worker，不能简单反转扩容箭头。容量与 goodput 见 llm-serving-performance，重试、取消和 draining 见 llm-serving-reliability。readiness/EndpointSlice 语义见 Kubernetes Pod 生命周期。

横向对比

按主要层比较职责；“拥有请求路径”指直接参与请求执行或选点，“local KV”指引擎内布局、分配和有效性，区别于外部 index/transfer/storage。成熟度列记录可核验版本与限制，不是性能或生产质量排名。

架构交叉矩阵

核心设计轴

1. KV 所有权与身份：引擎决定 local KV 是否有效，外部索引给出可能命中的线索。跨 worker/存储层复用还需模型版本、token 前缀、布局和失效契约，见 kv-cache-offload。
2. 执行与编排边界：引擎可跨设备/节点并行；runtime 处理实例间请求协作；Kubernetes 控制器收敛期望状态与容量。跨节点并行本身不意味着必须引入 Dynamo，见 llm-inference。
3. P/D 资源形态：角色比例、拓扑、KV transfer 与独立扩缩需共同决定。不能从“prefill 计算密集、decode 访存敏感”的概括直接得出部署答案，见 disaggregated-serving。
4. 复用与排队权衡：热 prefix worker 可能过载；cache-hit 高不保证 TTFT/ITL 达标。路由信号要有时效，评估最终达标的请求量，见 inference-routing、llm-serving-performance。
5. 设备与容量约束：GPU sharing、拓扑、权重和 KV 占用改变可分配容量；request autoscaling、Pod 调度与节点供给有不同周期，见 k8s-gpu-device-stack。

项目工程剖面

vllm：可测量的执行基线

V1 的 API/Engine Core/GPU worker 分工要求部署同时为 tokenization/调度保留 CPU。工程研究入口是 scheduler token budget、local KV block 管理及模型/attention backend 支持；旧版代码剖面见 src-vllm-architecture，当前进程边界见 V1 文档。采用成本集中于镜像、权重、并行和特性组合，模型支持列表不能承诺目标 SLO。

sglang：执行路径与前缀复用

当前 Scheduler、ModelRunner、RadixCache 源码见核验表；src-sglang-architecture 保存早期 HTTP/TokenizerManager/Scheduler/DetokenizerManager 与 forward mode 剖面。prefix reuse、chunking、speculative decoding 和 P/D 应组合验证，避免外推单项优化收益。v0.5.21 P/D 指南限定 backend、安装与拓扑配置。

dynamo：模块化分布式协作

工程重点是 worker membership、信号延迟、KV transfer、Planner 与 Operator 的所有权。v1.5.0 release列出的 engine 依赖为 vLLM v0.28.0、SGLang v0.5.18，并记录 backend 已知限制；不能把本页所有独立最新版直接拼成已验证栈。

KVBM 已在 Dynamo v1.5.0 被标为 deprecated，计划在 v1.6.0 移除；host/disk 分层 offload 用户应迁向 engine-native KV offloading。KV Cache Runner（KVCR）是针对跨节点 KV 共享的独立早期项目，release 明确它不替代 KVBM。上述状态来自 v1.5.0 release 的废弃与迁移说明。src-dynamo-architecture 保留整体架构与 cache offload 的历史快照，kv-cache-offload 中的项目映射也需按这一版本边界解读。

llm-d：Gateway/EPP 与 Kubernetes serving 组合

Proxy 负责连接与流，EPP 选 endpoint，InferencePool 表达后端集合，Model Server 执行。v0.10.0 release记录 KV-cache 仓库迁入 router、WVA 指南废弃及组件版本表；src-llm-d-architecture、src-llm-d-router-architecture、src-llm-d-kv-cache-architecture 反映早期仓库划分。迁移需核对镜像、chart、CRD 和插件配置，不能只升级总项目 tag。

aibrix：多引擎 fleet 的组合式运维

v0.7.0 release让比较范围覆盖多引擎、P/D、Batch 与 HA Gateway，但组件成熟度并不一致。按需采用 Gateway、controller、AI Runtime 或 KV 能力，并明确 adapter 生命周期、状态恢复及副本写入权。旧剖面见 src-aibrix-architecture，serving API 边界比较见 src-k8s-serving-stack-comparison。

基础设施参照：资源位置与设备能力

SkyPilot 的当前 README描述统一 Kubernetes、Slurm 与云资源入口；Source 中 Task/Dag/Resources、Optimizer 等细节属于原分析版本。src-k8s-gpu-device-plugins-stars 和 k8s-gpu-device-stack 组织 device plugin、GPU Operator、DRA/CDI、sharing 与 observability 的阅读路径；具体驱动/API 兼容性需独立核验，资源与设备层均不能替代 token 执行。

核心难点

• 吞吐与延迟：continuous-batching、chunked prefill、speculative decoding 都改变资源和队列行为；按固定 workload 下满足 TTFT/ITL 的 goodput 与成本评价，见 llm-serving-performance。
• 缓存与排队：locality 收益要减去热点排队、事件延迟与迁移成本。KV index 过期和 KV 数据损坏是不同故障，不能用同一 fallback 解释。
• 分离后的状态转移：handoff、采样/约束解码状态、取消和已输出 token 的重试边界由 backend 契约决定，见 disaggregated-serving、llm-serving-reliability。
• Offload 是缓存系统：介质、evict/promote、身份去重、并发加载和重新 prefill 的机会成本共同决定收益，见 kv-cache-offload。
• 容量到达的时差：决策、GPU provisioning、模型加载、readiness、endpoint discovery 各自可延迟或失败，扩容期间仍需入口保护。
• 跨层观测：关联 TTFT/ITL、queue/token backlog、KV hit/transfer、GPU/显存、controller 决策和 provider capacity error，不能只看 HTTP 平均延迟。

选型与下一步验证

组合、avoid-if 与迁移成本见 llm-serving-engine-selection-map。本页没有同模型、同硬件、同 SLO 的跨项目实测，因此只给职责和验证顺序，不给性能排名。

1. 用 llm-d-benchmark、inference-perf 和 llm-d-inference-sim 统一 workload 与故障场景，分别测基线、路由和扩缩收益。
2. 按 release 核验 EPP/KEDA/HPA 路径及 WVA 迁移，建立与历史 Source 的配置差异清单。
3. 结合 kueue、karpenter、lws、jobset 测量 GPU 不足、模型冷启动和 worker group readiness 时间线。
4. 对 Gateway/EPP、P/D worker、KV 通道做故障注入，记录流式输出前后的取消、重试、超时和 draining 语义。

尚需补齐 engine/connector KV 身份与布局兼容矩阵、在飞请求恢复边界、GPU sharing/拓扑对 goodput 的影响。更多候选见 llm-d-kubernetes-sigs-candidate-map。