推理框架对比 2026：从 Engine 到 Serving Stack

框架选型不是在排行榜里找“最快引擎”。生产系统通常同时包含 API/Router、Scheduler、Engine、KV Runtime、Kernel、集群编排与硬件；任何一层都可能改变性能、可运维性和故障边界。

这篇给出选型合同：先描述 workload 与 SLO，再检查候选栈是否支持所需数据路径，最后在相同 identity 下压测。机制细节由各主题页负责。

1. 比较单位：Serving Stack

层级	主要职责	选型时要确认
API / Router	协议、鉴权、限流、路由、SLO	streaming/tool schema 是否兼容；是否 cache-aware
Scheduler / Engine	admission、batching、模型执行	token budget、公平性、抢占、P/D 语义
KV Runtime	分页、prefix reuse、transfer、offload	key/ownership、block layout、淘汰、失败恢复
Kernel Backend	Attention、GEMM、MoE、量化	目标 shape/dtype/hardware 是否命中预期 kernel
Orchestrator	replica、资源池、扩缩容、健康检查	拓扑、滚动升级、故障转移、观测
Hardware / Fabric	HBM、计算、NVLink/RDMA/PCIe	单 rank 可行性与跨 rank 有效带宽

一个系统可以由不同项目组合：engine 使用一套 scheduler，Attention/MoE 来自外部 kernel library，KV 由 connector 接出，再由 Kubernetes/Ray/Dynamo 类控制面编排。项目列表不能代替接口与 ownership 图。

2. 候选组件的定位

下表用于缩小候选范围，不代表相同模型与版本下的性能排序：

组件	主要定位	值得验证的强项	主要边界
vLLM	通用 Serving Engine	模型/量化生态、continuous batching、Paged KV、OpenAI-compatible API、connector	高阶能力的成熟度依赖版本、backend 与部署组合
SGLang	程序化与高性能 Serving Runtime	prefix/radix reuse、structured generation、MoE/推测路径	参数语义和模型特化路径需按目标版本验证
TensorRT-LLM	NVIDIA 优化的编译/运行时	NVIDIA kernel、低精度、in-flight batching、分布式部署集成	模型构建与硬件绑定更强
FlashInfer	可组合 inference kernel library	Paged KV Attention、Prefill/Decode/MoE kernel	不是完整 API、调度和编排系统
TGI / LMDeploy	面向部署的 Engine/Server	模型生态或轻量部署路径	复杂 P/D、KV/EP/fleet 能力需逐版本确认
llama.cpp	本地、CPU/Metal/边缘推理	GGUF、量化、多后端、低运维门槛	目标通常不是多节点高并发 Serving
Ray Serve / KServe / llm-d / Dynamo 类	分布式编排或 Serving 控制面	replica、路由、资源池、P/D、扩缩容	必须与具体 engine/KV connector 一起评估

“支持 FP4”“支持 P/D”“支持 MoE”都只是入口。真正的检查项是：目标 checkpoint、GPU、engine 版本、backend 和 topology 组合是否命中该路径。

3. 六组实现差异

3.1 Scheduler 合同

比较：

admission policy
token / sequence budget
continuous batching semantics
chunked prefill default and priority
preemption / recompute / swap behavior
multi-tenant fairness

同名参数不保证同义。Chunked Prefill 的机制与实验方法见 Chunked Prefill 深入分析。

3.2 KV 合同

比较：

block/page layout and fragmentation
prefix cache key and isolation
eviction / persistence / tiering
KV ownership and transfer connector
load/transfer observability
failure and retry semantics

Prefix hit 不等于免费：若 KV 位于其他 rank、CPU、SSD 或远端，还要加入路由和加载成本。

3.3 并行与 MoE 合同

比较：

TP/PP/DP/EP/CP supported combinations
rank placement and topology mapping
expert dispatch/combine backend
load-balance observability
weight/KV ownership under failover

EP 的数据流见 MoE 推理，组合策略见 推理并行策略。

3.4 Kernel 与低精度合同

Checkpoint recipe、executed kernel 和 resident dtype 必须分开验证：

load log -> conversion/fallback -> executed kernel
         -> resident memory -> quality/performance result

仅凭模型名、GPU 名或配置中的 dtype，不能证明使用了目标 FP4/FP8 kernel。需要 kernel trace 和加载后显存闭环。

3.5 API / Agent 合同

Tool calling、reasoning output、JSON schema、grammar、streaming 与取消请求会改变：

• tokenizer / parser 行为；
• sampling 与 grammar 开销；
• 输出长度和重试率；
• 客户端兼容性与错误语义。

只用离线纯文本 benchmark，无法证明 Agent Serving 的协议与 SLO。

3.6 运维合同

至少检查：

health/readiness semantics
rolling upgrade and model reload
queue/KV ownership during failure
metrics/traces with request identity
autoscaling signal and cooldown
capacity degradation behavior

单实例 benchmark 领先，不代表它在故障、扩缩容和多租户下仍是更好的生产栈。

4. P/D 分离：能力不是收益

P/D 分离把 Prefill 与 Decode 放到独立资源池，通过 KV transfer 衔接：

$$\operatorname{TTFT} =T_{\text{queue,P}} +T_{\text{prefill}} +T_{\text{KV transfer}} +T_{\text{admission,D}} +T_{\text{first token}}$$ $$\operatorname{TPOT} \approx T_{\text{queue,D}} +T_{\text{decode step}} +T_{\text{scheduling gap}}$$

它提供独立配置 P

比例、并行策略、硬件和扩缩容的空间，也新增：

• KV connector 与带宽；
• ownership、路由和 backpressure；
• 两个队列与容量耦合；
• 失败重试和孤儿 KV；
• 跨池观测。

评估候选实现时，不要只问“是否支持 P/D”，而要问：

合同	需要得到的答案
传什么	KV block、压缩表示、metadata，还是可重算状态？
何时传	完整 Prefill 后，还是支持增量/流水？
谁拥有	cache key、生命周期与回收由哪层控制？
怎么限流	Decode pool 满时 Prefill 是否继续生产 KV？
如何恢复	connector、worker 或 router 故障后重算还是迁移？

对短 Prompt、短输出或低并发，额外传输与排队可能抵消收益；对长 Prompt、长 Decode 与 tail SLO 冲突明显的 workload，才更值得进入对照实验。

5. 场景到候选方向

场景	首先验证的合同	可进入试验的方向
通用 OpenAI-compatible API、多模型	协议、模型覆盖、调度与可观测	vLLM、SGLang、TGI/LMDeploy
固定 NVIDIA 模型、追求特定低精度路径	构建、kernel 命中、显存与质量	TensorRT-LLM，或目标 engine + NVIDIA backend
MoE / 多节点 EP	expert placement、all-to-all、负载均衡	支持目标模型/EP backend 的 vLLM、SGLang、TensorRT-LLM 组合
长共享 Prefix / RAG / 多轮	cache key、hit、tiering、路由	engine prefix cache、Radix 路径、LMCache/其他 KV runtime
P/D / reasoning fleet	KV transfer、backpressure、跨池扩缩容	engine + Ray/llm-d/Dynamo/KServe 类编排
本地、CPU/Metal、边缘	格式、内存、部署体积	llama.cpp、LMDeploy 等轻量路径

表中的项目是候选，不是默认赢家。若团队现有观测、运维和模型适配成本很高，理论功能更全也可能不是总成本更低的选择。

6. 可比较的压测合同

候选框架必须使用同一组 identity：

model/checkpoint and tokenizer
precision recipe and executed kernel
hardware count/topology/power mode
TP/PP/DP/EP/CP and placement
engine/version/backend/config
ISL/OSL distributions and arrival process
prefix share/hit and KV tier
tool/structured-output ratio
warmup, measurement window, failure policy

同时报告：

指标	目的
TTFT P50/P95/P99	排队、Prefix/Prefill 与首 token
TPOT/ITL P50/P95/P99	流式 Decode 稳定性
E2E P95/P99	长输出与重试的完整体验
SLO-goodput	满足延迟约束的有效吞吐
tokens/s/GPU	资源效率，但不可跨 workload 裸比
resident/peak memory	可部署性与余量
KV hit/load/transfer	缓存收益与代价
network/collective	TP/EP/P/D 的数据面
errors/retries/preemptions	稳定性与隐藏成本

如果 identity 不同，标记 not_comparable；没有指标则标记 missing / unavailable，不要用零补齐。

7. 最小决策记录

一个可复查的选型结论应只有四段：

1. 目标：workload、SLO、容量与运维约束；
2. 候选：每套 Serving Stack 的组件与版本；
3. 证据：相同 identity 的功能验证、trace 和压测；
4. 决定：选择、放弃原因、已知风险和复测触发条件。

当模型、GPU、engine 大版本、kernel backend 或 workload 分布变化时，重新验证，而不是沿用“2026 年某框架最快”的静态结论。

8. 与模拟器的接口

框架不能只是一个字符串标签。至少向模拟器提供：

scheduler policy and budgets
KV block/layout/tiering/connector
parallel placement
executed dtype/kernel backend
workspace/runtime reserve
calibrated kernel and communication curves

具体公式、scope 和校准状态见 模拟器建模指南。

相关页面

• 批处理与调度
• MoE 推理
• 推理并行策略
• Kernel / Runtime 优化
• KV Cache
• 模拟器建模指南

参考资料

• vLLM Documentation
• SGLang Documentation
• TensorRT-LLM Documentation
• FlashInfer Documentation
• Ray Serve: Prefill/Decode Disaggregation
• llm-d
• NVIDIA Dynamo
• LMCache Documentation