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

1. 结论

2026 年的 LLM 推理框架竞争，已经从单机 engine 性能，转向一套 serving stack 的系统竞争：

• Engine 层：vLLM、SGLang、TensorRT-LLM、TGI、LMDeploy 负责模型执行、batching、parallelism 和 OpenAI-compatible API。
• Kernel 层：FlashInfer、FlashAttention、TensorRT-LLM kernels 决定 attention、MoE、GEMM、quantization 的硬件效率。
• KV Cache 层：PagedAttention、RadixAttention、LMCache、Mooncake、NIXL、KV offload 把 KV 从进程内临时状态变成可复用、可迁移、可路由的系统资源。
• Serving 编排层：NVIDIA Dynamo、llm-d、Ray Serve、KServe 等把多个 engine 实例组织成 P/D 分离、cache-aware routing、autoscaling 和多租户服务。

如果只问“哪个框架最快”，答案通常不稳定。更可靠的问题是：

1. 这个 workload 是 prefill-bound、decode-bound，还是 KV-transfer-bound？
2. 请求是否共享长 prefix、RAG 上下文或多轮对话历史？
3. 模型是否是 MoE，是否需要 expert parallelism 或 DeepEP？
4. 目标是低 TTFT、低 TPOT、最大 tokens/s/GPU，还是 SLO 下的 QPS？
5. 部署对象是单机、单集群、Kubernetes fleet，还是异构 GPU/CPU/SSD 层级？

2. 2026 推理系统栈

层级	代表系统	主要职责	关键问题
API / Router	OpenAI-compatible server, llm-d router, Dynamo frontend, Ray Serve	接入请求、负载均衡、SLO 控制、cache-aware routing	请求应该去哪个 engine / 哪个 KV cache owner？
Scheduler	vLLM scheduler, SGLang scheduler, TensorRT-LLM in-flight batching	continuous batching、chunked prefill、P/D 分离、admission control	prefill job 会不会阻塞 decode？
Engine	vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy	模型执行、并行、量化、spec decode、structured output	单实例如何把 GPU 用满？
KV Runtime	PagedAttention, RadixAttention, LMCache, NIXL, Mooncake	KV 分页、prefix reuse、KV transfer、offload、持久化	KV 是重新算、迁移、复用，还是落盘？
Kernel	FlashInfer, FlashAttention, TRT-LLM kernels, Triton kernels	attention、GEMM、MoE grouped GEMM、FP8/FP4 kernel	kernel 是否匹配 batch shape 和硬件？
Hardware	H100/H200/B200/GB200, AMD MI300X/MI325X, CPU/Metal	HBM 带宽、NVLink/IB、FP8/FP4、PCIe/NVMe	bottleneck 在算力、显存带宽还是网络？

这张表比“框架功能清单”更重要。实际线上系统经常是组合形态：vLLM 或 SGLang 做 engine，FlashInfer 做 kernel，LMCache 做 KV 复用，llm-d / Ray Serve / Dynamo 做编排。

3. Prefill/Decode 分离成为主线

传统聚合式 serving 把 prefill 和 decode 放在同一批 GPU 上。问题是两阶段的瓶颈不同：

• Prefill 处理长 prompt，矩阵计算密集，更接近 compute-bound。
• Decode 每步生成一个 token，反复读取 weights 和 KV cache，更接近 memory-bandwidth-bound。
• Prefill job 插入 decode 流程时，会拉高 tail TPOT / ITL。
• 长上下文、RAG、多轮 agent 和 reasoning 输出让两阶段的资源需求更不对称。

P/D 分离把 prefill instance 和 decode instance 拆开，中间传输 KV cache。这样可以单独调 TTFT 和 TPOT，也可以给两阶段配置不同并行策略、GPU 类型和扩缩容比例。

系统	P/D 分离形态	关键点
vLLM	experimental disaggregated prefilling	prefill / decode 运行在两个 vLLM 实例，通过 connector 传 KV；官方明确提示该功能主要用于独立调 TTFT/ITL 和控制 tail ITL，不保证提升吞吐
TensorRT-LLM	disaggregated serving	context / generation 分离，支持 KV cache exchange、overlap optimization 和 cache-aware routing
Ray Serve	vLLM v1 上的 P/D deployment	把 prefill/decode 拆成独立 deployment，可用 NIXLConnector 或 LMCacheConnectorV1 传 KV
NVIDIA Dynamo	distributed inference framework	面向 reasoning model 的多节点 serving，强调 disaggregated serving、KV-aware routing 和跨 GPU pool 编排
llm-d	Kubernetes-native distributed inference	在 Kubernetes 上组合 vLLM、智能路由、KV cache 管理、P/D 分离、SLO-aware autoscaling

建模启发：P/D 分离不是免费吞吐提升。模拟器至少要显式建模：

TTFT = queue_prefill + prefill_compute + kv_transfer + first_decode
TPOT = queue_decode + decode_step + scheduling_gap
KV transfer cost = bytes(KV blocks) / effective_network_bandwidth + protocol_overhead

对短 prompt、短输出、低并发请求，KV transfer 和调度开销可能抵消收益。对长 prompt、中等输出、tail latency 敏感的 workload，P/D 分离更容易有效。

4. KV Cache 变成系统资产

早期推理框架把 KV cache 当作 engine 内部状态；2026 年的趋势是把它作为可观测、可复用、可迁移的资源。

能力	典型实现	解决的问题
Paged KV	vLLM PagedAttention, FlashInfer PagedKV	降低连续内存分配压力，支持变长请求和 continuous batching
Prefix reuse	vLLM automatic prefix caching, SGLang RadixAttention	system prompt、多轮对话、RAG 前缀重复时减少 prefill
KV transfer	vLLM NIXL / LMCache / Mooncake connectors, TensorRT-LLM KV exchange	P/D 分离时把 prefill 生成的 KV 交给 decode
KV offload	LMCache, vLLM offloading connector, llm-d tiered KV	GPU 显存不足或长上下文复用时，把 KV 放到 CPU/SSD/远端存储
Cache-aware routing	llm-d, TensorRT-LLM disaggregated server, SGLang load balancer	请求路由到已有 prefix/KV 的 worker，减少重复 prefill

KV cache 复用的收益高度依赖 workload。多轮 agent、RAG、固定 system prompt 和批量同源任务能提高 hit rate；一次性短请求几乎没有收益。

模拟器启发：

effective_prefill_tokens = new_tokens + missed_prefix_tokens
saved_prefill_compute = hit_prefix_tokens * per_token_prefill_cost
extra_kv_memory = cached_prefix_tokens * kv_bytes_per_token

如果缓存放到 CPU/SSD，还要把 load_KV_latency 加回 TTFT；命中不等于免费。

5. Engine 层对比

框架	核心定位	强项	主要边界
vLLM	通用高吞吐 serving engine	PagedAttention、continuous batching、OpenAI-compatible API、量化生态、spec decode、P/D connector 生态	极端 MoE/DeepSeek workload 通常需要额外 tuning；P/D 分离仍受 connector 和基础设施成熟度影响
SGLang	面向复杂程序化 LLM workload 的 serving engine	RadixAttention、structured generation、speculative decoding、DeepSeek/MoE 支持、DeepEP 集成	生产部署需要理解 runtime 参数；生态规模小于 vLLM
TensorRT-LLM	NVIDIA 硬件上的高性能编译/运行时	FP8/FP4、kernel fusion、in-flight batching、Blackwell 支持、TRT-LLM/Triton/Dynamo 集成	模型适配和构建流程更重；对非 NVIDIA 硬件不可用
FlashInfer	composable inference kernel library	PagedKV attention、decode/prefill kernel、JIT 编译、被上层框架复用	不是完整 serving 系统
TGI	Hugging Face 生态 serving	部署简单、HF model hub 集成、Rust router、常见量化	对最新 MoE/P/D/KV 生态的覆盖通常落后于 vLLM/SGLang
LMDeploy	轻量部署和 TurboMind engine	AWQ/W4A16、KV INT8、C++ backend、部署简单	大规模 MoE、P/D 分离和 fleet 编排能力有限
llama.cpp	单机、CPU、边缘和 GGUF 生态	极致量化、CPU/Metal/CUDA 多后端、单文件模型	不适合多节点高并发 serving
DeepSpeed/FlexGen	offload 和离线大 batch	GPU-CPU-NVMe 层级、超大模型离线推理	实时交互 serving 不是主战场

6. MoE 与 Expert Parallelism

MoE 推理把瓶颈从普通 dense GEMM 扩展到 expert routing、dispatch/combine、all-to-all、load balance 和 expert placement。

问题	对框架的要求
Expert 分散在多卡/多机	需要 expert parallelism、fast all-to-all、拓扑感知 placement
每 token 激活少量 expert	需要 grouped GEMM / fused MoE kernel，避免小 GEMM 吞吐低
热门 expert 倾斜	需要 routing 监控、load balance、capacity 策略
Prefill 和 decode 资源需求不同	MoE 更容易需要 P/D 分离和不同并行配置
DeepSeek 类模型有 MLA/MoE 组合	KV layout、attention kernel、expert dispatch 要一起调

SGLang 公开的 DeepSeek 96 H100 案例把 P/D disaggregation 和 large-scale expert parallelism 放在一起，这是 2025 以后 MoE serving 的典型方向。TensorRT-LLM 也在持续补 large-scale EP、DeepSeek R1、MTP 和 Blackwell 优化。

详见 MoE 推理。

7. Speculative Decoding 不再是单一功能

Speculative decoding 的基本形式是 draft-verify，但框架支持已经分化：

方式	代表实现	适用场景	风险
Draft model	vLLM / SGLang	小模型草稿 + 大模型验证	draft 质量低时 acceptance rate 低
EAGLE / EAGLE-3	SGLang、vLLM 生态	利用 hidden state 预测后续 token	需要匹配模型和草稿权重
MTP	DeepSeek-V3/R1、vLLM MTP 支持	模型训练时内置多 token prediction head	需要模型原生支持，不能靠 serving 开关生成
N-gram / suffix	vLLM 等	重复文本、代码补全、固定模板	泛化能力有限
DSpark 类半自回归 drafter	DeepSpec/DSpark 方向	DeepSeek-family target + 专用 drafter	需要 target hidden-state export、draft/verify loop 和 scheduler 支持

关键判断：spec decode 的收益来自“多发 token 被 target 接受”。吞吐收益取决于：

speedup ≈ accepted_tokens_per_verify / (1 + draft_overhead + verify_overhead)

如果 acceptance rate 低、draft 模型占用 GPU、或者 batch 中请求形态差异大，收益会下降。不要把它建模成固定倍数。

详见 投机解码 和 DSpark 与 MTP。

8. Structured Output 与 Agentic Serving

Agent、tool calling、JSON schema、function calling 会改变 serving 负载：

• decode 时要按 grammar / schema 过滤 token；
• batch 内请求可能有不同 grammar；
• reasoning trace、tool result、RAG context 会拉长 prompt；
• 同一个会话会反复复用 system prompt 和工具说明；
• 输出格式错误会触发重试，放大 tail latency。

SGLang 默认推荐 XGrammar 作为 structured output 后端；vLLM 也把 structured outputs、tool calling、reasoning outputs 放进 serving 功能。对框架选型来说，这说明 engine 不只负责“吐 token”，还要和 agent runtime、schema validator、router、cache 层配合。

模拟器启发：结构化输出会改变 decode step 的采样成本，但更大的影响常来自重试率和输出长度分布。需要在 workload 里记录：

schema_type, grammar_backend, retry_rate, avg_tool_calls, reasoning_tokens, output_tokens

9. 业界信号

方向	公开案例	可以学到什么
P/D 分离	vLLM、TensorRT-LLM、Ray Serve 均已有文档化支持	P/D 分离已经从论文/实验进入主流框架，但要把 KV transfer 和调度成本纳入评估
Reasoning serving	NVIDIA Dynamo 针对 DeepSeek-R1/GB200 报告 disaggregated serving 带来的请求数提升	reasoning model 的长输出让 decode pool、KV routing、fleet 编排变成核心问题
MoE at scale	SGLang DeepSeek 96 H100 案例	MoE serving 不能只看单卡 kernel，需要 EP、P/D、网络拓扑和 scheduler 一起设计
Kubernetes-native inference	llm-d 进入 CNCF Sandbox，围绕 vLLM、prefix-cache routing、KV tiering、SLO autoscaling 做生产栈	生产推理开始从单 engine 部署走向 cloud-native serving stack
KV cache platform	LMCache 把 KV cache 做成可持久化、可复用、可观测的管理层	长上下文、RAG、多轮 agent 的性能上限取决于 KV 生命周期管理

这些案例的指标不能直接横向比较。硬件、模型、ISL/OSL、SLO、并发、batch 策略、KV hit rate 不同，tokens/s 或 x 倍提升 只在原测试条件下成立。

10. 场景化选型

场景	首选方向	理由
通用 OpenAI-compatible API，高并发，模型覆盖广	vLLM	生态大、部署简单、PagedAttention/continuous batching 成熟
DeepSeek/MoE/共享 prefix 多的服务	SGLang	RadixAttention、DeepSeek/MoE 支持和程序化 serving 能力更强
NVIDIA 单模型固定形态，追求硬件极限	TensorRT-LLM	编译优化、kernel fusion、FP8/FP4、Blackwell 支持更直接
多节点 P/D 分离、reasoning 服务、fleet 编排	Dynamo / llm-d / Ray Serve + vLLM/SGLang/TRT-LLM	需要 router、KV transfer、autoscaling 和多实例生命周期管理
RAG、多轮、长上下文、system prompt 重复	vLLM/SGLang + LMCache 或框架内 prefix cache	关键瓶颈在重复 prefill 和 KV 生命周期
单机/边缘/CPU/本地工具	llama.cpp / LMDeploy	部署简单，量化格式丰富
离线大 batch、GPU 显存不足	DeepSpeed/FlexGen/offload 系统	更适合吞吐优先的批量任务，不适合交互式低延迟

11. 评估指标

框架评估必须同时报告 workload、硬件和 SLO，否则结论不可复用。

指标	含义	常见误区
TTFT	请求到首 token 的延迟	只看平均值会掩盖 prefix miss 和排队
TPOT / ITL	decode 阶段相邻 token 延迟	prefill 插队会拉高 tail
E2E latency	请求完成时间	长输出 reasoning 请求不能只看 TTFT
tokens/s/GPU	单卡吞吐	不同 ISL/OSL 和 batch 下不能直接比较
SLO QPS	满足延迟约束时的最大 QPS	比裸吞吐更接近线上容量规划
KV hit rate	prefix/KV 复用比例	hit 的 KV 如果在 CPU/SSD，还要算加载延迟
acceptance rate	spec decode 接受率	接受率低时 draft 成本会抵消收益
GPU utilization	SM/HBM/NVLink/PCIe 利用率	单个 utilization 数字无法定位瓶颈

建议压测矩阵至少包含：

model, precision, tp/pp/dp/ep, gpu_type, gpu_count,
ISL distribution, OSL distribution, concurrency,
prefix_share_ratio, kv_hit_rate, structured_output_ratio,
TTFT P50/P95/P99, TPOT P50/P95/P99, E2E P95,
tokens/s/GPU, SLO QPS, GPU memory, network bandwidth

12. 与模拟器的关系

推理框架会影响模拟器参数，不应只把 framework 当作字符串标签。

框架能力	对模拟器的影响
Paged KV block size	影响 KV internal fragmentation 和可容纳 batch
Prefix cache / RadixAttention	改变有效 prefill tokens 和 TTFT
P/D 分离	引入独立 prefill/decode queue、KV transfer、P 配比
Expert parallelism	引入 all-to-all、expert imbalance、dispatch/combine 开销
FP8/FP4/INT4	改变 weight bytes、GEMM throughput、精度风险
Speculative decoding	引入 draft cost、verify cost、acceptance rate
Structured output	改变 decode sampling cost、重试率和输出长度
KV offload	引入 CPU/SSD/network load latency 和缓存容量

详见 模拟器建模指南、KV Cache Hit Ratio 修正模型。

13. 相关页面

• LLM 推理优化学习路线
• KV Cache：推理性能的命根子
• Compute-bound vs Memory-bound：推理的两大瓶颈
• 批处理与调度：推理服务的灵魂
• 推理引擎架构：vLLM / TensorRT-LLM / SGLang
• 投机解码：突破 decode 一次只出一个 token 的限制
• DSpark 与 MTP：DeepSeek 投机解码调研
• MoE 推理：Expert 并行与调度机制
• FP4/FP8 量化：低精度推理的存储与计算
• 模拟器建模指南：显存与吞吐公式
• 从 Profiling 到 Simulation：推理性能分析的证据链方法

14. 参考资料

• vLLM: Disaggregated Prefilling — vLLM 对 P/D 分离、TTFT/ITL 独立调优和 KV connector 的说明。
• TensorRT-LLM: Disaggregated Serving — NVIDIA 对 context/generation 分离、KV exchange、cache-aware routing 和性能评估方法的说明。
• Ray Serve: Prefill/decode disaggregation — Ray Serve 基于 vLLM v1 的 P/D deployment 文档。
• NVIDIA Dynamo — NVIDIA 面向 reasoning model 的分布式推理框架介绍。
• llm-d — Kubernetes-native distributed inference stack，覆盖智能路由、KV cache 管理、P/D 分离和 SLO autoscaling。
• SGLang DeepSeek 96 H100 案例 — SGLang 的 DeepSeek P/D disaggregation 与 large-scale expert parallelism 实践。
• LMCache — KV cache 管理层，覆盖持久化、复用、offload 和 observability。
• SGLang Speculative Decoding — EAGLE、MTP、n-gram 等 speculative decoding 支持。
• SGLang Structured Outputs — structured output 与 XGrammar 后端。
• vLLM Structured Outputs — vLLM structured output、reasoning output 和 OpenAI-compatible serving 支持。