GLM 4.7 Flash 用 vllm 怎么部署：起服务参数与常见坑

你把 GLM 新小模型的权重下回来了，pip 装完 vllm，一条命令敲下去却各种报错：显存不够、模型结构不认、起得来但请求一直转圈。这篇不讲原理课本，只按「先确认前提、再写启动参数、最后照着报错排查」的顺序走一遍，让服务能稳稳跑起来。文里不放死数字，显存和版本一律让你去站内页面按当时的规格核对。

你把 GLM 新小模型的权重下回来了，pip 装完 vllm，一条命令敲下去却各种报错：显存不够、模型结构不认、服务起得来但请求一直转圈。这篇不讲原理课本，按「先确认前提、再写启动参数、最后照着报错排查」的顺序走一遍，让服务能稳稳跑起来。

文里不放死数字，显存和版本一律让你去站内页面按当时的规格核对。部署这件事，坑基本都在对齐环节：权重和框架要对齐，参数和硬件要对齐，调用方式和兼容层要对齐。

先把三件事对齐，再动手装

先把三件事对齐，再动手装。权重、框架、硬件三条线只要有一条对不上，后面参数怎么写都是白费。

• 确认权重来源与目录结构：从官方渠道拿到的权重通常带 config、tokenizer 与分片文件，先看清是不是完整分片，缺一层就会在加载阶段直接挂
• 确认 vllm 与模型架构的匹配关系：新模型往往要较新的 vllm 才认，装之前去 /models/deploy 看当时的支持口径，别用老镜像硬试
• 确认硬件底线：卡型、显存、卡数决定你能不能用默认精度起，显存怎么估先去 /models/deploy 与 /compute/gpus 对一遍
• 不适用的情况：如果你只是想试效果、日调用量很低，先走 /inference 看托管推理，本地部署的运维成本不一定划算

起服务的参数：按这个顺序填

起服务的参数按这个顺序填：必填四件套、并行相关、长度与并发、精度与量化。每填一层就起来验一次，别一次性把参数堆满再调，那样报错你分不清是哪个变量引起的。

• 必填四件套：模型路径、服务端口、监听地址、显存占用比例；显存比例是第一个要调的旋钮，用它给 KV cache 留空间
• 并行相关：单卡不够时先考虑张量并行，几卡就填几；流水线并行只在跨机或有特殊拓扑时才用，填错就是直接报错
• 长度与并发：最大上下文长度、最大并发序列数、批处理 token 上限三个参数互相牵制，先按保守值起，压测后再往上抬
• 精度与量化：默认精度起不来就降一档，量化档位怎么选看 /models/deploy 的对照，别一次跳两档，质量损失和吞吐变化会混在一起说不清

1. 先填必填四件套模型路径、端口、监听地址、显存比例。显存比例先给保守值，起得来再往上加，验证方式是看日志里 KV cache 是否成功分配。
2. 再补并行参数单卡不够时张量并行等于卡数；跨机才考虑流水线并行。验证方式是启动日志里能看到所有卡都参与了加载。
3. 最后调长度与并发最大上下文长度、最大并发序列数、批处理 token 上限先按保守值起，压测后再往上抬。验证方式是用短请求跑通不报错。

起来之后先验服务，别急着接业务

起来之后先验服务，别急着接业务。服务进程活着不等于能正常推理，中间还隔着监听、模型名、协议兼容几道关。按下面顺序过一遍，能省掉后面接业务时一半的扯皮。

• 先打健康检查与模型列表接口，确认服务真的在监听、模型名和你调用时写的一致，名称对不上是新手最常见的 404 来源
• 用一条短请求跑通再说：提示词控制在几十个 token，看首字延迟与是否报错，延迟基线可以拿 /tools/speed-test 横向比
• 压一把并发：慢慢加并发直到吞吐不再涨或开始报错，这个点就是你的实际上限，写进部署记录
• 接业务前的兼容层：本地服务默认走 OpenAI 兼容协议，客户端怎么填地址与 Key 参考 /base-url

报错排查顺序：从外到内四步

报错排查顺序从外到内四步：显存、权重版本、参数冲突、网络端口。很多人一报错就去翻代码，其实前四步里至少三步跟你的代码无关。

1. 第一步看是不是显存问题启动即 OOM、加载到一半被杀，先降显存比例、降上下文长度或上量化，别先怀疑代码。验证方式是降一档后能起来。
2. 第二步看是不是权重或版本问题模型结构不认、缺文件、tokenizer 报错，这类错对着日志第一行搜，通常是版本不匹配。验证方式是换到站内标注支持的 vllm 版本。
3. 第三步看是不是参数冲突并行数与卡数不符、上下文超过模型上限，这类会在启动校验阶段就退出。验证方式是逐项对照启动参数与硬件。
4. 第四步看是不是网络与端口服务起来了但连不上，检查监听地址是不是只绑了本地、端口有没有被占、容器有没有映射出来，完整顺序可对照 /local-api-network-troubleshoot 的三步法。

报错先看最外面那层：显存、权重、参数、网络，四步走完再翻代码。

长期跑起来要做的几件小事

长期跑起来要做的几件小事：记录部署清单、持续调优显存与并发、和调用 API 做一次成本对照。这三件事决定你是能稳定跑半年，还是每周都在救火。

• 记录一份部署清单：权重版本、vllm 版本、启动参数、卡型与卡数、实测并发上限，换卡或升级时靠它回滚
• 显存与并发调优是长期活，量化、张量分片、CPU offload 的选择参考 /vram-optimization-guide
• 和调用 API 做一次成本对照：日请求量到某个量级后本地跑才划算，分界线用 /rent-gpu-vs-api 的方法算