glm5.2 vllm recipe

你手上有一台或多台卡，想把 GLM5.2 用 vLLM 起成能对外服务的推理接口，但不确定该用哪档权重、张量并行开多少、上下文和显存怎么取舍，参数照抄别人的又怕跑不起来。这篇按部署动作的顺序给你一套可执行的检查清单：先算够不够，再选参数，再压测，最后按现象排查。具体版本对应的显存与吞吐数字，本文不写死，去站内对应页面按当时的卡与量化档核对。

你手上有一台或者几台卡，想把 GLM5.2 用 vLLM 起成一个能对外服务的推理接口，但不确定该拿哪一档权重、张量并行开到几、上下文和显存怎么取舍，参数照抄别人的又怕跑不起来。这篇按部署动作的顺序给你一套能直接照着做的检查清单：先算够不够，再选参数，再压测，最后按现象排查。

有一点先说清楚：具体到某张卡、某个量化档位能跑多少并发、显存吃多少，这些数字随时会变，本文一个都不写死。你到站内的部署测算页和量化对比页，按你当时的卡型和上下文长度核对。下面讲的都是判断标准和动作顺序，数字请以站内当页为准。

动手前先核对三件事：权重、显存、许可证

很多人失败不是败在参数上，是败在第一步就下错了权重。拿到一个仓库地址先别急着 clone，把这三件事对着清单过一遍，能省掉后面大半的返工。顺序不要跳，权重没确认就去调参数等于白干。

• 权重从哪来：确认拿到的格式跟 vLLM 支持的加载方式对得上，仓库里有没有分片索引文件，别只看名字就下
• 显存先算再做决定：按参数量乘量化位宽粗估权重占用，再给 KV cache 留空间，到站内部署测算页按你的卡和上下文长度跑一遍
• 许可证边界：先看清这份权重允许的商用范围和再分发条件，内部测试和对外提供服务往往是两回事，不确定就按不能商用处理
• 版本兼容：vLLM 版本、CUDA 驱动、卡型三者互相牵制，先确认这条链路通，再谈调参

起服务时真正要调的参数，以及各自的取舍

服务能起来之后，真正影响体验的就是下面这几个旋钮。它们不是越大越好，而是互相拉扯：上下文开大就吃 KV cache，并发就上不去；精度要得高，显存和吞吐就得让路。下面这张表帮你把取舍想清楚。

并行度这块再展开一句：张量并行看起来是卡越多越快，但卡间带宽不够的时候，多出来的时间全花在通信上。所以正确做法是先拿一个能起的小配置跑出基线，再往上扩，每扩一次就压一次，看吞吐是不是真的涨了。

1. 先起最小可服务配置用能跑起来的最低并行度和保守的显存利用率把服务拉起来，确认接口能通、能出结果，这是你的基线。
2. 调上下文到业务真实值把最大上下文设成业务里最长那类请求的长度，不要图省事设成最大值，设完再压一轮看并发掉多少。
3. 定量化档位在质量验收线之内选最省显存的那档，具体每档的差异去站内量化相关页面核对当时的数字。
4. 补上鉴权与限流开放接口前先把访问控制和限流做好，裸起服务只适合内网自测，别直接对外。

上线前必须做的压测：看吞吐、看首字延迟、看显存曲线

压测的目的不是找出一个最大值拿去汇报，而是找到拐点——也就是再往上加并发，吞吐不再涨、首字延迟开始明显变差的那个位置。你对外承诺的容量，应该定在拐点之下，而不是压在拐点上。

• 分三档并发压：低、中、高各跑一轮，记录吞吐和首字延迟，找拐点而不是找最大值
• 盯显存曲线：稳定之后还缓慢上涨，基本是缓存或者请求堆积的问题，别等 OOM 才回头查
• 用真实长度的输入压：短 prompt 压出来的数字没有参考价值，按业务里最长的那类请求准备样本
• 把基线和机器规格一起记下来：换卡、换 vLLM 版本、换量化档位时才有得比

还有一个容易被忽略的点：压测和线上跑的环境要对得上。同一份配置在测试机和生产机上表现可能不一样，尤其是驱动版本和卡型不同的时候。如果你不确定手上的中转或者算力渠道是否和标称一致，可以先用站内的测速工具跑一遍，再去比压测数字。

跑不起来时的排查顺序，别一上来就改参数

起不来的第一反应往往是去翻参数，但绝大多数问题根本不在参数上。下面这个顺序按「问题发生的阶段」排，从加载阶段往运行阶段走，能帮你快速定位到到底是哪一层出的事。

1. 第一步：看权重加载阶段路径对不对、格式对不对、分片文件缺不缺，这一步的报错信息通常直接点名，照着改就行。
2. 第二步：区分显存爆在哪一刻加载时就爆，是权重和并行度的问题；跑起来才爆，多半是 KV cache 或者并发堆积的问题，两者处理方式完全不同。
3. 第三步：核对版本链路vLLM、驱动、卡的架构是否都在支持范围内，不在范围内怎么调参都没用，先去站内兼容性相关页面确认。
4. 第四步：最后才动服务参数并行度、上下文、显存利用率按顺序单变量调整，一次只改一个，否则你不知道是哪个改动生效了。

部署的功夫不在调出漂亮参数，而在出问题时知道先看哪一层。