Skip to content

12. 框架对比与版本 ​

本篇导读 ​

学完机制和语音边界,终于可以回答“该选哪个”。这一篇用小林资料助手的两种落点——Mac 本地学习、Linux GPU 多人服务——说明怎样筛候选,再比较 vLLM、SGLang 与其他路线。版本信息单独作为有日期的快照,避免把设计原理和短期更新混在一起。

先过三道门,再看跑分 ​

从任务质量、模型硬件支持到真实负载性能的选型顺序

先问能不能正确完成任务,再问目标设备和功能组合能不能运行,最后才比较真实请求下的延迟、容量与成本。比如资料助手必须引用正确条款,而语音助手还要正确分块和打断;只比较模型名或 tokens/s 会漏掉这些要求。

Mac 本地学习可以从 MLX-LM 或 llama.cpp 建立可运行的直觉;Linux GPU 多人服务可以先比较 vLLM 与 SGLang。候选会因模型、后端和部署约束变化。历史招牌帮助理解设计,不足以代表今天的全部能力。

vLLM 与 SGLang ​

维度vLLMSGLang实测判断标准
经典切入点分页 KV,通用推理服务前缀树复用、生成程序与 runtime历史机制是否解决当前瓶颈
前缀索引常规完整块及父哈希关联压缩前缀树与扩展实际粒度、命中 token、管理成本
连续批处理支持支持延迟目标下吞吐、抢占与公平性
分块预填充支持支持长短混合请求 TTFT 与 ITL
结构化输出支持相应约束后端支持,属于长期重点方向Schema 子集、编译、截断、组合正确性
推测解码多路线,受模型和后端约束多路线,受模型和后端约束每轮推进、草稿成本、质量、并发
量化与 LoRA多方案多方案精度、rank、模型、设备的交集
多卡与 MoE多种并行与相关路径多种并行及混合路径目标模型的通信与 kernel
外部 KV / P/Dconnector 等机制P/D、HiCache 等机制传输、命中、恢复和隔离
API 与工具解析依模型模板及 parser依模型模板及 parser字段、流式、并行调用、停止语义
前端语言常规 API 与应用代码可选 DSL,不是部署前提应用是否真需要生成程序原语

因此不能用“vLLM 没有 radix tree”推出它不能复用前缀,也不能用“SGLang 有树”推出它在任意请求上更快。两者都要落到物理状态、后端、调度和 kernel。

学习时可先用 vLLM 建立基线,再把同样模型和请求切到 SGLang。第二套部署应回答“为什么有差别”,而不只是再记一条启动命令。

其他路线怎样定位 ​

方案值得优先评估的场景需要考虑的边界
TensorRT-LLMNVIDIA 上固定模型与硬件的深入优化后端、精度、硬件矩阵与适配成本;当前不全是固定 engine 构建流程
llama.cpp本地、CPU/GPU 分担、量化与广泛后端GGUF 模型适配、设备卸载、目标并发与调度
MLX-LMApple Silicon 本地生成和量化实验统一内存仍有容量与带宽上限,多用户能力须实测
LMDeploy已有成熟适配的模型和多模态生态TurboMind 与 PyTorch 两条路径支持不同
ONNX Runtime / OpenVINO通用模型、CPU 和相应设备生态生成模型特性与服务调度需看具体套件
移动端运行时手机、嵌入式、离线 SDK导出、算子、状态、功耗、体积与许可
Ollama本地模型管理、使用体验和 API 封装应进一步确认实际后端与模型路径
TGI维护既有生产服务已进入 maintenance mode,新项目需计入长期维护状态

vLLM 已有 vLLM-Metal 路线,SGLang 0.5.22 也有 Apple Silicon 标准 PyTorch 与 MLX 路线。不能再笼统说两者完全不能在 Mac 运行,但这些后端不等于 NVIDIA 路径的全部功能和性能。

Mooncake、LMCache、Dynamo 等位于 KV 或分布式服务层,常与引擎组合;它们不应与单机模型执行引擎放在同一跑分榜直接比较。

按工作负载建立候选 ​

工作负载候选起点重点验收
通用 Linux GPU 问答vLLM、SGLang质量、TTFT、ITL、成本与维护
共享长文档、多轮 Agent两者及对应缓存路由冷热缓存、任务整体完成时间、队列
NVIDIA 大模型固定服务加入 TensorRT-LLM指定硬件和精度的 goodput
大规模 MoE目标模型适配成熟的多种引擎总权重、EP、热点、网络和恢复
本地 Mac 学习MLX-LM、llama.cpp,按需试新后端量化质量、内存与交互体验
ASR / TTS模型专用或通用运行时,加受支持的生成引擎RTF、final、首音频、分块与状态

顺序是:任务质量达标,模型与硬件可支持,真实请求正确,再寻找满足延迟目标的容量和成本。若模板或停止条件错了,漂亮的 tokens/s 没有工程意义。

版本快照 ​

核查日期为 2026-10-20,Asia/Shanghai。下表“正式版”指当时 GitHub Releases 的 latest 非预发布记录,不代表 nightly、全部包分发通道或厂商推荐生产镜像。

项目最新正式版发布日期(上海时间)关注点
vLLM0.32.02026-10-18执行器、低精度 KV、解析和升级语义
SGLang0.5.222026-10-19推测、P/D、加载与混合状态正确性
TensorRT-LLM1.2.12026-04-20正式与 RC 通道要区分
llama.cpp0.7.02026-10-16不应只按历史 build 编号理解当前标签
LMDeploy0.18.02026-09-28两类引擎支持矩阵分别核对
MLX-LM0.32.22026-10-16Apple Silicon 本地执行
Mooncake0.3.13.post12026-08-31KV 系统组件
Dynamo1.5.12026-10-07分布式推理组件

TensorRT-LLM 的 1.4.0rc0 发布于 2026-10-15,属于预发布;不能写成最新正式版,也不能因正式标签较早就认定项目长期没有更新。

vLLM 0.32.0 应怎样读 ​

这次版本包含 Model Runner V2 演进、不同硬件与模型的低精度 KV、启动和多 API worker 改善,以及解析、状态和安全修复。它们并非对所有模型默认同时生效。

GLM-5.x 在 SM100 的 FP8 KV 局部测试报告 KV 内存减半、吞吐增加 2.3%—5.5%,同时 TTFT 增加 7%—11%。这恰好说明“吞吐更高”和“首响应更快”可能方向相反。另一项多 API worker 的 43%—85% 增益来自 Qwen3-0.6B、32 输入/1 输出 token 的请求吞吐,不是长回答输出 tokens/s 的通用提升。

升级还要关注最低 Python 3.11、默认 CORS 收紧、旧接口或参数移除,以及 max_tokens 变为输出上限、不再按原语义预留上下文。上下文总限制仍存在,不能据此无限生成。

新增 /v1/systemone 和读取 response_template 的 hf parser 路径,仍依赖模型与模板支持,不会自动让任意 checkpoint 获得可靠决策或工具能力。

SGLang 0.5.22 应怎样读 ​

该版本继续扩展推测、MTP、P/D、加载器与多硬件路径,新增 Apple Silicon 标准 PyTorch 路线,并要求 Python 3.11 或更新。发布中的加载和长 prompt P/D 性能报告绑定特定模型与负载,不能直接加总为整体加速倍数。

尤其值得注意的是混合模型在推测解码与结构化输出组合下的 Mamba 状态恢复修复。单独测试两个功能可用,无法证明它们组合后正确。升级验收应把目标功能组合纳入固定质量集。

升级时保留什么 ​

保留引擎 tag、镜像 digest、模型 commit、tokenizer、chat template、精度文件、设备与驱动、CUDA/ROCm、启动参数,以及质量和压测结果。先阅读 breaking changes 和正确性修复,再看性能。

latest 文档可能对应开发分支,固定 tag 的旧说明也可能落后于该版本的新路径。实际使用应围绕目标模型和硬件交叉检查支持与启动日志。

本篇回顾 ​

  • vLLM 和 SGLang 有大量重叠能力,差异要在相同模型、设备和负载上验证。
  • 本地运行时、通用引擎和 KV / 分布式组件职责不同,候选应围绕实际部署组合建立。
  • 最新版本只是起点;适配、正确性修复、破坏性变化和功能组合决定能否升级。

选出了两个候选,怎样证明哪个更适合小林的助手? 最后一篇把它们放进可复现的实验。

别急,先让缓存热一下。