1.2 推理框架选型：为什么GLM-5.2首推vLLM

文档摘要

1.2 推理框架选型：为什么 GLM-5.2 我首推 vLLM GPU 链路通了，下一步是决定"用什么把模型跑起来"。这一步看似只是选个工具，实际上它直接决定了你后面所有部署 YAML 的写法、性能上限、以及能不能舒服地支持 1M 上下文。选错框架，后面每一步都是补丁；选对框架，很多工程难题它已经替你解决了。这一节我把主流推理框架摆到一张桌上横向对比，给出我自己的结论和理由，并附一张可直接照着用的选型决策表。读完后，你应该能 confidently 说出：GLM-5.2 为什么要选 vLLM，以及在什么特殊场景下才该考虑其他框架。一、先纠正一个常见误解很多人以为"推理框架"就是个把模型 load 进显存的壳，随便选一个都行。这是大错特错。

1.2 推理框架选型：为什么 GLM-5.2 我首推 vLLM

GPU 链路通了，下一步是决定"用什么把模型跑起来"。这一步看似只是选个工具，实际上它直接决定了你后面所有部署 YAML 的写法、性能上限、以及能不能舒服地支持 1M 上下文。选错框架，后面每一步都是补丁；选对框架，很多工程难题它已经替你解决了。

这一节我把主流推理框架摆到一张桌上横向对比，给出我自己的结论和理由，并附一张可直接照着用的选型决策表。读完后，你应该能 confidently 说出：GLM-5.2 为什么要选 vLLM，以及在什么特殊场景下才该考虑其他框架。

一、先纠正一个常见误解

很多人以为"推理框架"就是个把模型 load 进显存的壳，随便选一个都行。这是大错特错。大模型推理的瓶颈根本不在"算得快不快"，而在显存管理和请求调度——也就是：怎么让一块有限的显存同时喂饱多个并发请求、怎么不让长上下文把显存撑爆、怎么让 token 一个接一个流畅地吐出来而不是卡顿。

这些恰恰是不同框架差异最大的地方。下面这张图说明为什么"框架选型 ≈ 吞吐与成本选型"：

```mermaid graph TD A[用户并发请求] --> B{推理框架的调度与显存管理} B -->|高效: 连续批处理+分页显存| C[单卡高吞吐低单位成本] B -->|低效: 静态批处理+整块预留| D[频繁 OOM 或显存浪费高成本] C --> E[生产可用] D --> F[需堆更多卡烧钱] ```

一句话：框架选得好，同样的卡能多服务几倍流量。 对 GLM-5.2 这种 1M 上下文、权重体量不小的模型，这一点尤其致命——选错框架，你可能需要多买一倍的卡才扛得住同样的流量。

二、主流选手逐一过堂

候选 A：vLLM

vLLM 是目前开源大模型推理里生态最成熟、社区最活跃的项目之一。它的两个杀手锏：

PagedAttention（分页注意力）：这是 vLLM 成名的核心。传统推理框架为每个请求预留一整块连续 KV 缓存，长上下文一来就碎片化、撑爆显存。vLLM 借鉴操作系统"虚拟内存分页"的思路，把 KV 缓存切成块、按需分配，显存利用率大幅提升，能支持的并发和上下文长度显著变长。这对 GLM-5.2 的 1M 上下文尤其关键——没有分页机制，长上下文几乎不可能在常规显存下跑稳。
连续批处理（Continuous Batching）：不等一个批次所有请求都完成才处理下一批，而是来一个请求就动态插入，显存和算力利用率更高，延迟更稳。

此外，vLLM 提供 OpenAI 兼容的 API 服务（vllm serve 或 vllm/vllm-openai 镜像），你现有的调用 OpenAI 接口的代码几乎不用改就能接到 GLM-5.2 上，迁移成本极低。官方还有 production-stack 项目，给出了 K8s 部署的参考清单。更实际一点：当你在 K8s 里遇到 vLLM 相关问题，社区里能搜到的答案数量，通常比其他框架多一个量级——这对生产稳定性是隐性的巨大优势。

候选 B：SGLang

SGLang 是近年崛起的高性能框架，特点是RadixAttention（前缀缓存共享）——当很多请求共享相同的前缀（比如相同的 system prompt、相同的 few-shot 示例）时，它能复用计算，省下大量重复算力。在"大量请求带相同前缀"的场景（如固定模板的批量推理）下，SGLang 性能非常亮眼。

但要注意：SGLang 的 API 和生态相对 vLLM 更年轻，某些边缘特性的兼容性、社区问答量不如 vLLM。它对 GLM 系列的支持在快速跟进，是否可用请以官方模型支持列表为准——不要想当然认为"支持 Llama 就支持 GLM"，每个模型的 tokenizer 和架构细节都不同，必须查官方支持矩阵。 另外，RadixAttention 的收益依赖"前缀真的高度重复"，如果你的请求前缀千差万别（比如每个用户完全不同的长 system prompt），它的优势可能落空，甚至因维护缓存结构带来额外开销。

候选 C：TGI（Text Generation Inference）

HuggingFace 出品的推理服务，工业级、稳定，和 HF 生态无缝。但它对最新模型的跟进节奏、长上下文的显存优化，相比 vLLM/SGLang 在纯吞吐比拼上略逊一筹。它在"我就想用 HF 全家桶、求稳"的场景仍有价值，但作为 GLM-5.2 生产部署的首选，我一般不选它。换言之，TGI 更像"稳妥的备选"，而不是"性能与生态双优的默认答案"。

候选 D：原生 transformers + 自己写服务

理论可行，但等于把调度、批处理、显存管理全自己造轮子。除非你有极强的工程团队和特殊定制需求，否则强烈不建议拿它做生产推理服务——它的吞吐和稳定性会被专门框架甩开一个数量级。它适合"做研究、跑离线批处理、验证模型行为"这类场景，但一旦要面向线上并发，就该换专门框架。

```mermaid flowchart TD A[GLM-5.2 推理需求] --> B{请求是否大量共享前缀?} B -- 是 --> C[SGLang 可重点考虑] B -- 否/通用 --> D{vLLM 是否官方支持该模型?} D -- 是 --> E[首推 vLLM: 分页显存+连续批处理+OpenAI API] D -- 否 --> F[查 SGLang/官方模型卡兼容性] E --> G[直接用 vllm serve 起服务] C --> G ```

三、我的结论：GLM-5.2 默认选 vLLM

把上面几点收成一个明确主张：

对绝大多数想把 GLM-5.2 跑在 K8s 上的团队，我首推 vLLM。 理由按重要性排：

长上下文友好：PagedAttention 是 1M 上下文能落地的前提。GLM-5.2 主打 1M 上下文，没有分页显存管理，你几乎必然在长请求上 OOM。这一点上 vLLM 是刚需级优势。
兼容 OpenAI API：你已有的调用代码、上下游系统几乎零改造。生产环境里，"能直接替换"往往比"理论性能高 5%"更重要。
K8s 生态成熟：官方 production-stack 有现成的 Deployment/Service 参考，社区踩坑记录多，出问题容易搜到答案。
社区活跃、跟进快：新模型、新优化通常很快被支持。

那什么时候该考虑 SGLang？当你的业务有"海量请求共享相同前缀"的特征时（比如统一的 system prompt 很长、或者做批量结构化抽取），SGLang 的 RadixAttention 能实打实省算力。但即便如此，我也建议你先用 vLLM 把服务跑通、拿到基线性能，再决定是否值得为前缀共享优化切换到 SGLang——别在一开始就增加变量。这句话的意思是：先用最稳的方案打通链路，拿到可对比的基线，再决定是否为了某个特定收益去承担切换风险。

四、一张能直接照用的选型决策表

维度	vLLM	SGLang	TGI	原生 transformers
长上下文（1M）显存优化	强（PagedAttention）	强	中	弱
连续批处理吞吐	强	强	中	需自研
共享前缀复用	一般	强（RadixAttention）	一般	无
OpenAI API 兼容	是	是	是	需自封装
K8s 部署参考	官方 production-stack	社区为主	有	全自研
生态成熟度/问答量	最高	较高	高	依赖自身
新手友好度	高	中	中	低
适合 GLM-5.2 生产首选	推荐	前缀场景可考虑	求稳 HF 栈可用	不推荐

重要提醒：上表中"是否支持 GLM-5.2"必须以框架官方模型支持列表为准。发布时间、版本迭代快，今天支持不代表你用的版本支持，反之亦然。部署前请先到对应项目仓库核对模型兼容性，必要时用 1.1 的 gpu-test 思路先做个最小可运行验证。我见过有人因为"听说支持"就直接上生产，结果缺一个 tokenizer 补丁，服务起得来但输出全是乱码——这种坑，查一次官方列表就能避开。

五、选定 vLLM 之后，你需要提前想清楚的几点

框架定了，不代表后面就一帆风顺。基于 vLLM，有几点要提前规划（后面章节会展开）：

镜像来源：国内环境 HuggingFace 可能拉不动权重，要规划 ModelScope 或镜像加速；推理框架镜像本身也要有可靠的拉取源。
tensor_parallel_size 怎么设：单卡放不下 GLM-5.2 时，要用多卡张量并行，这个值等于用几张卡。它直接决定你的 Pod 要请求几张 nvidia.com/gpu（呼应 1.1 的资源规划）。这里有个现实约束：这个值通常是 2 的幂（1/2/4/8），且尽量不超过单节点卡数，否则跨节点通信会吃掉性能。
max_model_len 设多大：这是显存和能力的核心权衡。设到接近 1M 很爽，但显存账单会吓人；设太小又浪费了 GLM-5.2 的长上下文优势。第三章我们会算这笔账——提前剧透：很多团队实际只设到几万到十几万，因为真要稳定跑满 1M 的并发请求，显存和延迟都吃不消，得权衡你的真实业务。
服务暴露方式：vLLM 起的是 HTTP 服务，K8s 里用 ClusterIP + Ingress 还是直接用 LoadBalancer，取决于你的访问来源（第四章展开）。
量化要不要开：GLM-5.2 若提供量化权重（如 AWQ/GPTQ），能大幅降显存、提吞吐，但可能损精度。要不要在 K8s 里默认开量化，取决于你的精度容忍度，第三章会结合显存账一起算。

```mermaid flowchart LR A[选定 vLLM] --> B[确认模型官方支持] B --> C[规划权重获取源] C --> D[确定 tensor_parallel_size] D --> E[确定 max_model_len 显存账] E --> F[规划 K8s 服务暴露] F --> G[第二章动手部署] ```

还要提醒一个成本视角的误区：框架选型的收益是“卡的账单”级别的，不是“百分之几”的优化。一张高端 GPU 一年的费用足以养活一个工程师，而把单卡吞吐提升一倍，相当于凭空省下一半的卡。所以认真做这一节的选择、并且在第三章把显存账算清楚，是整本教程里“投入产出比最高”的一段工作。别因为“反正公司有的是卡”就跳过——卡多了，调度的复杂度、运维的成本、故障的爆炸半径也跟着放大，框架和配置没选好，规模越大越痛。

最后给一句判断标准，帮你结束纠结：如果你的场景是“通用对话/API 服务、希望尽快上线、要兼容现有 OpenAI 调用”，闭眼选 vLLM；如果你的场景是“批量模板推理、前缀高度重复、已经到了为算力成本极致优化的阶段”，再去认真评估 SGLang。绝大多数 GLM-5.2 的 K8s 部署，都落在前者。

六、本节小结

推理框架的差异本质是显存管理 + 请求调度的差异，直接决定吞吐和成本。
vLLM 凭 PagedAttention（长上下文友好）、连续批处理（高吞吐）、OpenAI API 兼容、成熟 K8s 生态，是 GLM-5.2 的默认首选。
SGLang 在"大量共享前缀"场景有优势，但建议先跑通 vLLM 基线再考虑切换；前缀不重复时其优势可能落空。
TGI / 原生 transformers 各有定位，但一般不是 GLM-5.2 生产首选。
所有"是否支持"的判断，以官方模型支持列表为准，绝不臆测；先用稳定方案打通，再为特定收益承担切换风险。

下一节（1.3）我们把主角请上台：GLM-5.2 这个模型本身有哪些你必须知道的事实——发布时间、开源协议、上下文能力、权重去哪下载，以及哪些参数官方还没公布、需要你自行核实。把模型和框架两件事对齐，第二章就能直接动手部署了。

补充一句给纠结型读者：框架选型这事，最忌“分析瘫痪”。vLLM 是经过了海量生产验证的默认安全选项，你花在纠结框架上的每一小时，不如先拿它把服务跑通、拿到真实吞吐数据。数据到手，该不该换 SGLang、该不该调量化，都是可量化的决策，而不是拍脑袋。这也是我整套教程的方法论：先跑通、再优化、每一步用数据说话。