LLM Serving / 推理引擎选型地图

选型从 workload 和 SLO 开始：先确定在线/批处理、输入输出分布、缓存重复与失败预算，再确认模型/硬件适配、engine、部署形态、routing/control plane 和运维约束。不存在统一最优栈；每层都应以真实负载的收益和运行成本决定是否加入。职责与控制面时序见 llm-inference-serving-project-map。

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

以下 release 经官方 GitHub API 核验，日期为 UTC 发布日；文档观察以 2026-10-03 为准。旧 Source 保留原分析时点，不能用旧组件图或 latest 文档替代目标 release 的兼容矩阵。

[!warning] Conflict
WVA 旧设计见 llm-d-workload-variant-autoscaler。2026-10-03 的 llm-d dev 文档明确 WVA deprecated，v0.10.0 release确认指南废弃，但 v0.9 架构页仍并列 WVA 与 HPA/KEDA。新部署应核验目标 release 的 EPP/KEDA/HPA 配置，旧 Source 不作为当前默认方案。

F4 · Workload / SLO-first 选型决策树

flowchart TD
    Work["记录 workload：模型、请求分布、租户与突发"] --> Mode{"在线还是批处理？"}
    Mode -->|"在线 / streaming"| Online["TTFT / ITL / P99 / 成功率预算"]
    Mode -->|"批处理 / 离线"| Batch["完成期限 / 成本 / 吞吐与重试预算"]
    Online --> Profile["上下文与输出长度分布 / prefix 重复 / 多模态"]
    Batch --> Profile
    Profile --> Target["确定 goodput 与容量目标，保留对应延迟约束"]
    Target --> HW{"模型 / 量化 / 硬件与拓扑是否支持？"}
    HW -->|"未确认"| Support["先验证模型正确性、显存、互联和候选 backend"]
    Support --> Engine
    HW -->|"已确认"| Engine["同 workload 验证 vLLM / SGLang / 其他 engine"]
    Engine --> Shape{"共置 engine 副本能满足目标？"}
    Shape -->|"是"| Agg["Aggregated baseline / 必要的模型并行"]
    Shape -->|"否且瓶颈有证据"| Dist["比较 P/D 或 distributed runtime 与 engine-native 集成"]
    Agg --> K8s{"需要 Kubernetes 路由或控制能力？"}
    Dist --> K8s
    K8s -->|"普通服务足够"| Plain["普通 Service / Gateway 或已有入口"]
    K8s -->|"需要 inference-aware picking"| Route["评估 llm-d / 已有路由组件"]
    K8s -->|"需要 fleet lifecycle 或扩缩"| Control["评估 AIBrix / Dynamo 控制模块 / 已有 controllers"]
    Plain --> Validate["验证 GPU 容量、运维所有权、成本、故障与 benchmark"]
    Route --> Validate
    Control --> Validate
    Validate --> Decision{"满足 SLO / 成本 / 可靠性门槛？"}
    Decision -->|"是"| Adopt["采用最小充分组合并保留回滚路径"]
    Decision -->|"否"| Profile

图注：箭头表示收集证据的评估顺序，不是运行时调用。假设模型质量与 API 语义已列入门槛；在线与 batch 混合时应分别测量并验证隔离。TTFT/ITL 主要约束交互请求，batch 还看完成期限与单位成本，见 batch-inference、llm-serving-performance。

不要从图中推断分支互斥、某项目必选，或 P/D 一定修复吞吐/延迟问题。llm-d、AIBrix、Dynamo 有职责重叠，可在接口明确时组合；每个副本目标必须只有一个写入者。P/D 收益需覆盖 KV transfer、网络拓扑与故障成本，见 disaggregated-serving；本页不指定统一最优 engine 或 stack。

决策输入与通过条件

选项目时比较同一层

不同层不能组成 engine 单选题。引擎先通过模型与 SLO 验收，外围层再处理其边界之外的问题；GPU 基础设施是所有组合的运行条件。跨云/K8s/Slurm 资源位置需求可另评估 SkyPilot，当前范围见官方 README。

组合方案

组合是候选设计，不代表任意版本交叉兼容。Dynamo v1.5.0的引擎依赖与本页独立 release 不同，AIBrix v0.7.0的 Batch API 仍有 preview 提示。混合平台前，逐项确认 request ownership、KV 契约、扩缩写入权、状态后端和升级顺序。

采用前的最小证据包

保留模型与 engine/container 版本、硬件/拓扑、输入输出长度分布、到达过程、缓存冷热状态、并行/batch 参数以及 benchmark 原始结果。同一目标下同时报告 goodput、TTFT/ITL 分位数、拒绝/错误率、GPU 成本与扩容滞后；切换 engine 或外围组件时只改变被比较变量。

上线门槛包括 API/输出回归、冷启动、超时与取消、worker/Gateway/网络故障、缩容排空、升级回滚和多租户隔离。可复用 llm-d-benchmark、inference-perf 与 llm-d-inference-sim；模拟器只能验证覆盖的控制面行为，不能证明 GPU 性能。指标方法见 llm-serving-performance，故障验收见 llm-serving-reliability。