09. 整体对比与选型：同一个资料助手，该交给哪个框架
前八篇分别拆开了七个推理框架和它们上面的编排层。每一篇都在讲“它擅长什么、怎么配置、有哪些坑”，这一篇把它们放到同一张桌子上：先按运行位置和职责分清谁和谁才有可比性，再逐项对比硬件、模型、量化、并行、默认值和安全边界，然后给出一条选型路径，最后讲在框架之间迁移时最容易出错的地方。读完你应该能为资料助手的不同阶段（个人试用、部门上线、全公司规模化）各列出一两个候选框架，并知道该怎样用自己的数据验证它们。
先分清谁和谁可以比
把 vLLM、Ollama、Dynamo 放进同一张跑分表，就像把发动机、家用轿车和车队调度系统放在一起比百公里加速。它们解决的是不同层次的问题：
数据中心引擎（vLLM、SGLang、TensorRT-LLM、LMDeploy）在 GPU 服务器上同时服务很多人，核心指标是一张卡在延迟约束下能撑住多少并发（Goodput，见衡量快慢）。它们都实现了连续批处理、分页 KV、前缀缓存、量化、投机解码和多卡并行，差别在实现深度、默认值和覆盖范围。
本地与端侧框架（llama.cpp、Ollama、MLX-LM、ExecuTorch、MLC-LLM）面向一台笔记本、一部手机，核心指标是单个用户的首字延迟和每秒生成多少 token，以及在有限内存里塞进多大的模型。它们的并发能力有限，量化格式和硬件覆盖却比数据中心引擎宽得多。
编排与 KV 缓存层（Dynamo、llm-d、production-stack、AIBrix、Mooncake、LMCache）不自己算模型，而是在多个引擎实例之上做路由、P/D 编排、KV 传输和扩缩容。它们和引擎是组合关系：Dynamo 下面跑的可以是 vLLM、SGLang 或 TensorRT-LLM。
所以下面的对比在每一类内部进行，跨类只比较“适合什么场景”。
数据中心引擎逐项对比
| 维度 | vLLM 0.32.0 | SGLang 0.5.22 | TensorRT-LLM 1.2.1 | LMDeploy 0.18.0 |
|---|---|---|---|---|
| 出身与维护 | 伯克利 PagedAttention 论文，社区治理，约两周一版 | LMSYS，RadixAttention 论文，两三周一版 | NVIDIA 官方；1.2.1 之后只有预发布 | 上海人工智能实验室 InternLM 团队 |
| 硬件 | NVIDIA（主包 CUDA 13.0）、AMD、Intel XPU、CPU；TPU、昇腾等走平台插件 | NVIDIA（0.5.20 起只支持 CUDA 13）、AMD、昇腾、Intel；TPU 另有 sglang-jax | 只支持 NVIDIA GPU + Linux | NVIDIA 为主；昇腾、沐曦、寒武纪只能用 PyTorch 引擎 |
| 模型覆盖 | 最广，另有 Transformers 后端兜底 | 广，新模型常同步给出配方，也可回落 Transformers 实现 | 约二十多个文本架构加多模态，热门大模型跟进快 | TurboMind 只认 19 个架构名，其余回落到 PyTorch 引擎 |
| 前缀缓存 | 默认开，按完整块做哈希链 | 默认开，基数树，按 token 粒度 | 块复用默认开 | 默认关，要加 --enable-prefix-caching |
| 量化 | FP8、NVFP4、AWQ、GPTQ 等；GGUF、bitsandbytes 需插件 | FP8、NVFP4、MXFP4、AWQ/GPTQ、GGUF | 依赖 ModelOpt 离线产出；NVFP4 只在 Blackwell | AWQ W4A16、SmoothQuant W8A8、在线 KV INT8/INT4 |
| 并行 | TP/PP/DP/EP、上下文并行 | TP/PP/EP，针对 MLA 的 DP Attention | TP/PP/EP、注意力 DP、Wide-EP | TP/DP/EP，TurboMind 另有上下文并行 |
| P/D 分离 | KV 连接器（NIXL、Mooncake、LMCache），官方标为实验性 | 内置，默认 Mooncake 传输 | 自带 trtllm-serve disaggregated，生产推荐配合 Dynamo | PyTorch 引擎支持 |
| 适合优先评估 | 大多数场景的默认起点 | 前缀复用多（多轮、Agent、共享长文档），大 MoE 多机部署 | 模型和 NVIDIA 硬件都固定，追求 FP8/NVFP4 下的极致性能 | TurboMind 支持的模型做 4 bit 部署，国产卡 |
表格里还有几处看不出的差别。
KV 预算的口径不一样。 四个引擎都有一个“给 KV 留多少显存”的比例参数，名字相近，含义完全不同。vLLM 的 gpu_memory_utilization（默认 0.92）是总显存中引擎能用的比例，权重、激活、KV 都从这里面分；TensorRT-LLM 的 free_gpu_memory_fraction（默认 0.9）是加载权重、试跑测出峰值以后剩余显存的比例；LMDeploy 的 cache_max_entry_count（默认 0.8）是加载完权重后空闲显存的比例；SGLang 的 mem_fraction_static 默认不设，按显存大小、分块预填充长度和 CUDA Graph 档位自动算出一个总显存比例（H100 上 Qwen3-8B 手算约 0.83）。所以“vLLM 0.92 比 TensorRT-LLM 0.9 更激进”这种比较没有意义；同一台机器上能放下多少 KV，要看各自启动日志里打印的 token 容量。
默认调度和分块预填充不同。 vLLM 和 SGLang 默认开启分块预填充，长输入会被切成多段和别人的 Decode 交替执行；TensorRT-LLM 1.2.1 默认关闭，超过 max_num_tokens（默认 8192）的输入会被直接拒绝。资料助手如果要读整本员工手册，换到 TensorRT-LLM 时要显式打开 enable_chunked_prefill。
发布节奏和稳定性。 vLLM 和 SGLang 每两三周一个正式版，参数改名、默认值变化很常见（例如 SGLang 的 --enable-dp-attention 已标为废弃，改用 --attn-dp-size）；TensorRT-LLM 的正式版停在 1.2.1，后续只有预发布，1.3 系列删除了旧的 TensorRT 引擎后端；LMDeploy 的文档表格明显落后于代码。无论选哪个，都要锁定版本、保留启动参数，升级前用同一套质量集和压测脚本回归（性能测试与分析）。
本地与端侧框架逐项对比
| 维度 | llama.cpp 0.7.0 | Ollama 0.40.12 | MLX-LM 0.32.2 |
|---|---|---|---|
| 定位 | 无依赖的 C/C++ 引擎和 GGUF 格式的事实标准 | 模型仓库 + 自动调度 + 常驻 API，底层调用 llama.cpp 或 MLX | Apple 芯片上的推理、量化和 LoRA 微调 |
| 硬件 | 最广：x86/ARM CPU、Metal、CUDA、HIP、Vulkan、SYCL、CANN 等，可 CPU/GPU 混合加载 | 跟随底层引擎 | 以 Apple Silicon 为主；MLX 也有 CUDA、CPU 后端，但在 NVIDIA 上不如数据中心引擎成熟 |
| 量化 | 最丰富：1.5—8 bit 的 k-quants 与 IQ 系列、imatrix 校准、KV 量化到 q4_0 | 拉取现成的量化标签；导入 safetensors 时可量化（走 MLX），GGUF 要先用 llama.cpp 量化好再导入 | 分组 affine 量化（默认 4 位）、MXFP4/NVFP4/MXFP8，以及 DWQ、AWQ、GPTQ 等用校准数据的量化 |
| 并发 | llama-server 有槽位和连续批处理，适合少量并发；-c 在槽位间分配 | 默认每个模型 1 个并行请求，多个请求排队 | mlx_lm.server 可批处理，官方不建议用于生产 |
| 上手 | 需要自己选量化文件和参数 | 一条 ollama run | 一条 mlx_lm.generate |
本地框架之间更像“同一套能力的不同包装”：Ollama 用起来最省事，代价是默认值按“一个人一台机器”设定（上下文长度按显存档位自动选，在 16—24 GB 的机器上是 4096，超出部分会悄悄丢掉最早的消息）；llama.cpp 把所有旋钮都交给你；MLX-LM 在 Mac 上直接利用统一内存，还能顺手做 LoRA 微调。三者都不适合当作多人在线服务的生产引擎，部门级上线应回到数据中心引擎。
默认安全边界
推理服务的默认监听地址和鉴权方式差别很大，而且多数框架默认不鉴权。这张表值得在部署前对照一次：
| 框架 | 默认地址 | 默认鉴权 |
|---|---|---|
| vLLM | 所有网卡的 8000 端口 | 无；--api-key 只保护 /v1 等前缀，/metrics、/health 仍开放 |
| SGLang | 127.0.0.1:30000 | 无，可设 API 密钥 |
| TensorRT-LLM | localhost:8000 | 无内置鉴权 |
| LMDeploy | 所有网卡的 23333 端口 | 无；设置 --api-keys 后，/health 和 /nodes 开头的节点管理路径仍不鉴权 |
| llama.cpp | 127.0.0.1:9931（Docker 镜像内是 0.0.0.0:8080） | 无，可加 --api-key；CORS 默认放开 |
| Ollama | 127.0.0.1:11434 | 无服务端鉴权 |
| MLX-LM | 127.0.0.1:8080 | 无 |
两条原则对所有框架都成立：引擎端口不要直接暴露到办公网或公网，放在网关后面由网关负责鉴权、限流和 TLS；在容器里把监听地址改成 0.0.0.0 时，要同时确认网络策略只允许网关访问（生产部署与运维）。
为什么不能直接看别人的跑分
网上常见“X 比 Y 快 2 倍”的结论，搬到自己的场景里往往不成立。原因在于性能高度依赖四个条件：模型（稠密还是 MoE、是否有 MLA）、硬件（H100 和 B200 上最优的框架可能不同）、请求分布（输入输出长度、并发、前缀共享比例）和配置（量化格式、KV 比例、CUDA Graph、投机解码）。前缀共享多的多轮对话，SGLang 的基数树可能明显占优；每个请求都是全新长文档的批量摘要，前缀缓存几乎不起作用，差距就来自算子和调度。
更可靠的做法是自己比，按选型三道关的顺序：先用同一份质量集确认候选框架上回答质量达标（对话模板、停止条件、采样默认值都对）；再确认目标模型、量化格式、GPU 型号和需要的功能组合在这个版本上真的被支持；最后用业务的真实请求分布压测，比较满足延迟目标时的 Goodput，而不是峰值吞吐。
一条选型路径
把资料助手的几个阶段放进这张图：
个人试用。 小林想在自己的 MacBook 上试试 Qwen3-8B 能不能回答制度问题。Ollama 一条命令就能跑起来；想比较不同量化档位的质量，换成 llama.cpp 直接加载不同的 GGUF 文件；想顺手用几十条样本做个 LoRA 试验，MLX-LM 最方便。这个阶段不需要考虑并发。
部门上线。 人事部门几十个人同时使用，部署到一台 H100 服务器。从 vLLM 建基线：模型、接口、工具调用解析器都最齐全，出了问题资料也最多。如果每个请求都带着同一段系统提示和制度文档，再用同样的请求分布试一次 SGLang，对比首字延迟和 Goodput。公司采购的是昇腾服务器时，先查 vLLM 昇腾插件和 LMDeploy PyTorch 引擎对目标模型和型号的支持矩阵。
全公司规模化。 几千人使用、十几张卡以上、加上语音提问。这时副本之间的路由开始影响前缀缓存命中率，长文档的 Prefill 开始拖慢别人的 Decode，才值得引入 Dynamo 或 llm-d 这样的编排层做 KV 感知路由和 P/D 分离。模型和硬件都确定、要把单卡性能压到极限时，再评估 TensorRT-LLM。
不适合的情况。 只有两三个副本时上编排层，多出来的组件和网络跳数只会增加故障点；只有一个人用时上 vLLM，启动时间和显存占用都比 Ollama 大得多；用 Ollama 承接全公司的在线请求，默认的单并发和上下文截断会让问题在高峰期集中暴露。
在框架之间迁移时最容易出错的地方
换框架时，同一个模型给出不同的回答，原因通常不在推理引擎的“质量”，而在这几处默认值不一致：
- 对话模板。 有的框架用模型自带的 Jinja 模板，有的内置模板表，Ollama 的 Modelfile 可以覆盖模板。迁移后先用同一个请求渲染出实际送进模型的文本逐字比对。
- 采样默认值。 vLLM 在线服务会合并模型目录里
generation_config.json的采样参数，其他框架未必如此；不传max_tokens时各家的默认输出上限也不同。生产请求应显式写出温度、top_p 和最大输出长度。 - 停止条件和特殊 token。 结束符没被识别时，模型会答完不停；推理模型的思考内容是否单独解析，取决于有没有配置对应的推理解析器。
- 上下文长度。 各框架的默认上下文和超长处理方式不同：直接报错、截断最早的消息，或者在槽位之间平分。
- KV 和量化。 KV 量化、不同实现的同名量化格式（例如 AWQ 内核）会带来数值差异，换框架后要重跑质量集。
版本快照
以下是 2026 年 10 月下旬（27—28 日）查询的 GitHub 正式发布版本。框架迭代很快，使用时以实际安装的版本为准。
| 项目 | 最新正式版 | 发布日期 | 说明 |
|---|---|---|---|
| vLLM | 0.32.0 | 2026-10-18 | 预编译包为 CUDA 13.0，另有 -cu129 变体 |
| SGLang | 0.5.22 | 2026-10-19 | 0.5.20 起只支持 CUDA 13 |
| TensorRT-LLM | 1.2.1 | 2026-04-20 | 之后只有预发布，1.3 起移除 TensorRT 引擎后端 |
| llama.cpp | 0.7.0 | 2026-10-15 | 2026 年 8 月起使用语义化版本，0.7.0 起服务默认端口 9931 |
| Ollama | 0.40.12 | 2026-10-27 | |
| LMDeploy | 0.18.0 | 2026-09-28 | |
| MLX-LM | 0.32.2 | 2026-10-16 | |
| NVIDIA Dynamo | 1.6.1 | 2026-10-27 | 锁定的引擎版本落后于各引擎最新版 |
| llm-d | 1.0.0 | 2026-10-20 | |
| AIBrix | 0.8.0 | 2026-10-13 | |
| LMCache | 0.5.6 | 2026-10-14 | 发布列表里混有候选版和每日构建 |
| Mooncake | 0.3.13.post1 | 2026-08-31 |
数据中心引擎里，vLLM 是覆盖最广的默认起点，SGLang 在前缀复用和大规模 MoE 上投入最深，TensorRT-LLM 用硬件锁定换 NVIDIA 新硬件上的极致性能，LMDeploy 在 4 bit 部署和国产卡上有自己的位置；本地框架里，Ollama 最省事，llama.cpp 最灵活，MLX-LM 是 Mac 上的首选；编排层只有在副本多、前缀共享多或需要 P/D 时才有回报。KV 比例、分块预填充、监听地址、对话模板这些默认值在框架之间差别很大，比较和迁移时都要逐项核对。想回顾这些框架背后的共同机制，回到大模型推理优化系列；想了解模型本身怎样训练出来，见模型训练与调优。