vllm recipe glm 模型，起服务前先把这几格参数对好

用 vLLM 起 GLM，多数人不是卡在装不上，而是卡在 recipe 抄了别人的、模型名对不上，服务起来了却一直返回空或者乱码。这篇不铺原理，直接按部署顺序走一遍：先确认手上是哪份权重，再决定抄哪份 recipe，然后逐格检查启动参数，最后给一套报错时的排查顺序。

用 vLLM 起 GLM，真正卡人的地方往往不是装不上。装依赖、拉镜像这些活儿，网上教程一大把，照着敲就行。麻烦的是服务起来了，请求也返回 200，可内容要么是空的，要么答非所问，要么出来一串乱码。这时候人会先怀疑模型不行、显卡不够，其实十有八九是启动配置里那几格没对好。

recipe 这个词听着高级，说白了就是别人跑通过的一份启动配置样板。抄它没问题，问题是抄之前得先确认：人家那份 recipe 是配哪份权重的？你手里这份权重又是哪个规格、哪种量化、是不是 MoE？这三件事没对上，后面参数填得再漂亮也是白搭。下面按部署的实际顺序走一遍。

先别抄 recipe，先认手里的权重

很多人拿到一个模型名就去搜 recipe，搜到一份就开始改路径。这一步最容易埋雷。recipe 是跟着权重走的，不是跟着模型名字走的。同一个 GLM 家族，不同规格、不同量化档、官方原版和第三方转换版，对应的启动配置可能差得很远。名字一样不代表能套同一份配置。

所以动手前先去模型库把三件事记下来：参数量多大、量化格式是什么、是不是 MoE 结构。参数量决定张量并行数怎么填，量化格式决定显存估算，MoE 结构则会影响并行策略和一些优化开关能不能开。这三点不清楚，后面全是猜。

• 参数量：决定张量并行数的最低要求，填少了直接加载失败
• 量化格式：决定单卡显存估算，也决定要不要额外的量化相关参数
• 是否 MoE：影响专家并行相关配置，普通稠密模型的 recipe 不能直接套
• 权重来源：官方权重和第三方转换版的目录结构、文件名可能不一样，路径别照抄
• recipe 对应的权重版本：官方 recipe 一般写在仓库示例或模型卡片里，先确认它配的是不是你手里这份

对话模板和 tokenizer 是最容易填错的两格

这两格出错的表现特别有迷惑性。模板没带对，模型照样出字，但答非所问，你问东它答西，看着像模型能力不行，其实是对话格式没对上。tokenizer 指错了目录，轻则报词表不匹配，重则输出一串乱码。这两种情况我都见过有人去调温度、调 top_p，调半天没用，因为根子不在这。

GLM 系列有自己的对话模板，启动时要显式指定，别指望自动推断。自动推断在模型目录结构规整时能猜对，一旦你用的是转换版权重或者自己挪过目录，猜错的概率不低。tokenizer 同理，用权重目录里自带的那份，不要图省事指向另一个模型的目录，词表不一样，后面全乱。

1. 确认模板参数在启动命令里显式写上对话模板相关参数，值参考该权重对应的 recipe，不要留空让程序猜
2. 锁定 tokenizer 路径路径指向权重目录本身，不要指向父目录或别的模型目录；启动日志里一般会打印实际加载的 tokenizer 路径，看一眼对不对
3. 发一条最短请求验证用一句简单的问候打通，看返回是否通顺、是否符合对话格式；格式对不上时这一条就能暴露

启动参数按这个顺序过一遍

参数不是一股脑填完再启动，顺序有讲究。先定张量并行数，再算显存够不够放 KV 缓存，这个顺序反了，你会来回改。并行数定高了浪费卡，定低了加载不起来；而 KV 缓存能放多少，又直接受最大上下文长度和并发设置影响。

最大上下文长度这格特别容易被照抄。别人 recipe 里写的是他们业务的上限，你按自己的实际长度设就行，设太大只会白吃显存。端口、监听地址、API key 这三项写好之后，先拿一条最简单请求打通，别急着挂业务流量。至于各种优化开关，要看你的卡型和驱动版本，recipe 里给的是参考起点，不是必选项，开之前先确认兼容。

服务起来了但不对，按这个顺序查

排查最忌讳东一榔头西一棒子。按症状分路线，能省很多时间。返回空或者一直超时，先别怀疑模型，去看模板和停止符，再看是不是请求长度超了上下文被截断。加载阶段就报错的，优先怀疑权重格式和 vLLM 版本不匹配，换版本往往比改参数快。

输出重复、乱码这类，基本回到 tokenizer 和模板，这两处错位最典型。还有一种情况：显存明明够却 OOM，这时候别急着加卡，先查最大上下文和并发设置，多半是这两项把显存预算吃穿了。每一步都记下你改了什么，不然改着改着自己都忘了初始状态。