数据模型没定、部署链路没谱的时候我一般不会去碰卡。GLM-5.3-Flash 这几天讨论度很高群里天天有人问怎么在 8 卡 A100 上跑起来能不能接 ccswitch/codex跟 DeepSeek V4 Flash 比怎么样。这篇东西不聊跑分直接按我实际验证过的路径来先 API 跑通再单机部署然后处理单机异构资源最后落到多卡生产服务。每一步都会把为什么这么搬、以及踩过的坑写清楚照着走比直接翻官方 README 省事得多。1. 部署规划的底层逻辑先想清楚 Flash 模型和传统开源模型的差别1.1 GLM-5.3-Flash 到底适合谁来用GLM-5.3-Flash 是智谱 GLM 系列里主打低延迟、低成本的那一档。它的特点和那种参数越大越猛的旗舰模型不同更像是一个在性能、成本、部署难度之间找平衡点的产物。最近大家都在说它进入了 Pareto 区通俗点解释就是如果画一张图横轴是部署成本纵轴是实际效果你会发现很多模型要么效果差一点但便宜要么效果好但贵得离谱而 Flash 刚好落在不用花旗舰的钱又能跑出可用效果的边界上。对绝大多数业务场景来说这就够了。我自己测下来的感受是它适合三类人一类是中小团队想做 Agent 或 RAG不想为每次调用付太多钱但又不想完全放弃效果一类是独立开发者想本地跑一个不占太多显存的服务给自己或者小范围用户用还有一类是平台工程师需要在新业务里快速验证模型形态先把链路打通再决定是否上更大规模。所以部署规划不能上来就奔着 8 卡去。正确的顺序应该是先在 API 形态下把业务逻辑和模型能力验证完再判断要不要私有化私有化之后再根据手里的卡去决定单机、异构还是多卡。很多团队的错误就是第一步还没跑通就租了一台 8×A100 开始折腾结果权重还没下完需求已经变了。1.2 API、单机、异构、多卡之间差的是哪一层这里说的四个阶段不是同一个东西的四种说法而是四种完全不同的工程状态。API 阶段你只是调用方不需要关心 GPU、显存、并发只需要把模型名和鉴权信息填对。这一阶段解决的问题是这个模型适不适合我的业务。单机部署是把模型权重拉到自己的机器上用一张或两张卡跑一个本地服务。这个阶段你要开始处理推理引擎、显存占用、模型并发、上下文长度这些底层问题。适合数据敏感、高频调用、或者单纯想省 API 费用的场景。单机异构严格来说是单机部署的一种特殊形态但它和插两块同型号卡差别很大。异构意味着机器上可能同时有 A100 和 4090或者不同品牌、不同显存大小的加速卡混插。此时难点不是模型本身而是怎么让这些能力不一致的卡协同工作不出现一块卡累死、另一块卡闲死的局面。多卡生产服务则是往对外提供稳定服务这个目标走。需要考虑的不只是启动一个模型进程还有多副本负载均衡、队列排队、超时控制、监控告警、以及部署升级时业务不中断。到这一步推理引擎反而只是其中一环。把这几个阶段在脑子里面分清后面每个章节就都有明确的上下文了。1.3 环境方面先达成共识避免后面各种莫名其妙不管你是单机还是多卡下面几项最好先统一操作系统Ubuntu 20.04/22.04 优先生产环境不要用 Windows 裸机跑GPU 驱动建议 535 或更高版本直接决定了 CUDA 运行时能不能正常走CUDA 环境统一在容器里配别在物理机上乱装版本冲突会让你怀疑人生PyTorch 与 vLLM/SGLang版本尽量跟随推理引擎的官方要求我会在后面的章节说明具体选择存储模型权重放 NVMe SSD 上冷启动加载速度相差很大尤其是多卡并发加载的时候。先用nvidia-smi确认所有卡能被系统识别再确认每张卡的型号、驱动版本、显存大小。异构环境尤其要看这一步因为后续你给 GPU 分组、分配模型实例依据就是这份清单。别嫌这个动作基础我真的见过有人到 vLLM 启动时报no available GPU才发现驱动没装好。2. API 先跑通最快的验证路径也是最容易被文档坑的地方2.1 开通 Key 和调用模型名一字都不能错API 接入的步骤其实很短去平台开通账号、创建 API Key、然后按接口文档调用。但我在实际操作中发现最容易出问题的不是鉴权而是模型名。GLM-5.3-Flash 在不同渠道里可能有不同叫法比如有的网关会带上[1m]后缀表示 1M 上下文版本有的地方只认glm-5.3-flash这个裸名。如果你用的是官方兼容接口模型名里带不带后缀需要问清楚。热词里那条The supported API model names are deepseek-v4-pro, deepseek-v4-flash...的报错就是因为某个兼容网关只允许它白名单里的模型名你的调用方传了别的名字进去服务端直接拒了。这不是模型能力问题是配置问题。所以接入时先用最干净的方式验证一次curl https://api.zhipu-ai.com/api/paas/v4/chat/completions \ -H Authorization: Bearer $ZHIPU_API_KEY \ -H Content-Type: application/json \ -d { model: glm-5.3-flash, messages: [ {role: user, content: 用一句话说明什么是张量并行} ] }注意把ZHIPU_API_KEY配到环境变量里别写死在代码和 Shell 历史里。还有如果你新注册账号通常会有免费额度最近的活动大概是赠送 1 亿 token 的体验包用来做功能验证完全够用不用一上来就充值。2.2 Python 最小调用脚本以及流式输出日常开发里我基本都是用 OpenAI SDK 去调因为接口风格是兼容的迁移成本很低。下面这个脚本是能跑的最小可复现版本import os from openai import OpenAI client OpenAI( api_keyos.environ.get(ZHIPU_API_KEY), base_urlhttps://api.zhipu-ai.com/api/paas/v4, ) resp client.chat.completions.create( modelglm-5.3-flash, messages[ {role: system, content: 你是一个擅长总结的助手。}, {role: user, content: 给我梳理一下大模型部署的四个阶段。}, ], temperature0.7, ) print(resp.choices[0].message.content)流式输出会把首 token 延迟压得很低聊天的体验会好很多。做法是把上面的create加上streamTrue然后迭代resp里的choices[0].delta.content。我这里多提一句如果你做的是 C 端产品能开流式就开流式用户对一个字一个字蹦出来的容忍度远高于转圈 10 秒然后一次性输出。还有一点部分新模型支持thinking_budget这个参数来控制思考深度它的语义是让模型在正式回答前多花一些内部推理过程。这个参数必须是正整数如果你传了0、负数或者字符串就会遇到热搜里那条api error: 400 the thinking_budget parameter must be a positive integer。这个报错已经在不少群里出现过属于新人高频问题。2.3 1M 上下文的正确打开方式我注意到很多人一听到1M 上下文就把整本小说往里塞。模型能接住 1048576 个 token 是一回事你的业务能不能用好是另一回事。先说报错。如果你调用时超过上限会看到类似this models maximum context length is 1048576 tokens. However, your request exceeds...的提示。这个逻辑不难理解系统统计的是 prompt 里的 token 总长度不是字符数。中文一个汉字可能对应一到两个 token英文一个单词可能拆成几个 token。你以为没超实际上可能已经逼近上限。另外一个报错是网关层提示theres an issue with the selected model (glm-5.3-flash[1m])。这通常意味着你的代理或接入层尝试选择一个不存在的变体名比如代码里写了glm-5.3-flash[1m]但后端实际注册的是glm-5.3-flash。两边模型名不一致而已。真正在 API 里跑长文档时我的建议是分块检索不要全量灌入。1M 上下文最大的价值是让你不用精心裁剪文档而不是逼你把所有内容一次塞完。把该用的段落检索出来再组装 prompt无论延迟还是成本都会健康很多。3. 单机本地部署从拿到权重到跑通 OpenAI 兼容服务3.1 权重获取别只盯着一个来源当你决定私有化部署第一步就是拿到权重文件。我一般优先从 ModelScope 拉因为国内网络环境下速度和稳定性都更好而且它的文件组织形式和 Hugging Face 基本一致。拉取之前先看清楚模型卡页面的说明有些模型会拆成多个分片.safetensors文件按索引划分不要只下载一个文件就以为完事了。完整模型目录起码应该包含config.json tokenizer.json tokenizer_config.json model.safetensors.index.json model-00001-of-0000X.safetensors ...下载完别急着启动推理引擎先做一次文件完整性校验。常见做法是对比下载目录里的 SHA256 值ModelScope 页面一般会给出参考值。这个步骤在单卡时可能觉得多余但如果你后面要把权重拷贝到多台生产机器上校验能避免拷贝了一半但看起来成功的隐性问题。3.2 推理引擎选型为什么我建议先考虑 vLLM选推理引擎是个很容易被忽略但决定后面所有体验的决策。几个主流选项Ollama部署最简单一条命令就能跑适合本机体验和开发调试。但它为了易用性做了很多抽象真正要精细控制并发、量化、上下文缓存时反而束手束脚。vLLM吞吐量大PagedAttention 对 KV Cache 的管理很成熟OpenAI 兼容接口开箱即用。生产环境里我用得最多的是它。SGLang在复杂调度和某些长文本场景下有优势但生态和资料相对少一点新手不建议第一个项目就上手。我的建议是自己一个人玩选 Ollama 没问题要给团队或者外部提供 API直接选 vLLM省得后面迁移。后面的示例我也统一用 vLLM。安装这一步用 pip 直接装通常没问题pip install vllm不过生产建议用官方 Docker 镜像原因是 vLLM 对 CUDA、PyTorch 的版本耦合很紧pip 装很可能把系统里已有的 Python 环境搞得一团糟。Docker 镜像是官方踩过坑之后打包好的出问题概率小很多。3.3 单机启动命令与最小验证假设你只有一张卡模型目录在/models/glm-5.3-flash最简单启动方式如下CUDA_VISIBLE_DEVICES0 python -m vllm.entrypoints.openai.api_server \ --model /models/glm-5.3-flash \ --served-model-name glm-5.3-flash \ --tensor-parallel-size 1 \ --max-model-len 32768 \ --max-num-seqs 8 \ --host 0.0.0.0 \ --port 8000几个参数我解释一下--served-model-name是外部调用时看到的模型名。你可以把它设成任何名字但建议还是设成glm-5.3-flash避免接入方困惑。--tensor-parallel-size是张量并行度。单卡就写 1后面多卡再改。--max-model-len是允许的最大上下文长度。默认值可能接近模型原生上限如果显存不大先设成 32768 跑通再说。--max-num-seqs控制同时处理的序列数。设太大在长上下文中很容易 OOM先保守一点。启动日志里如果出现Starting vLLM using ... GPU并且没有任何 error就说明模型加载成功了。然后用和 API 几乎一样的方式验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: glm-5.3-flash, messages: [{role: user, content: 你好}] }看到正常返回单机版就算通了。这时候拿最开始写的 Python 脚本把base_url改成http://localhost:8000/v1其他逻辑都不用动这就是 OpenAI 兼容接口的好处。3.4 显存怎么估以及量化要不要上显存预估我习惯用这个公式打底模型权重大小 KV Cache 激活值 一定冗余。权重大小很容易看把模型目录里所有.safetensors文件大小加起来就行。如果是 FP16/BF16 精度70B 左右模型大约 140GB 权重如果按 INT4 量化大约 35-40GB。这也是为什么单卡部署这种规模必须量化以及为什么Flash这种保留效率的档位会在单机上更实用。KV Cache 的大小取决于并发序列数、上下文长度和层数。vLLM 采用 PagedAttention 后不会一次性把所有显存吃光但如果你设了很大的--max-model-len又开高并发KV Cache 增长会非常快。显存不够时的选择优先级我一般是这样先降--max-model-len只保留业务真正需要的上下文长度再降--max-num-seqs限制并发还不够才考虑量化。量化方案上AWQ 和 GPTQ 是常用的 PTQ 方案。AWQ 对显存占用和推理速度兼顾得比较好而且它对模型效果的影响在多数任务上可以接受。如果你拿到的是官方或社区验证过的量化版本优先用现成的量化权重别自己拿脚本去量化大模型耗时不说精度损失还很难把控。需要留意的是量化版本的部署方式和原版完全一样vLLM 会读取权重里的量化配置自动处理。3.5 单机版最容易被忽视的细节上下文长度别默认拉满刚才提到了--max-model-len我在这里单独展开一下因为这是单机部署新手翻车最多的地方。GLM-5.3-Flash 原生支持 1M 上下文也就是 1048576 个 token。听起来很爽但如果你启动时不做限制vLLM 会按这个长度去预留 KV Cache 和计算结构。哪怕你的并发只有 2 个请求只要某一次请求比较长显存占用就会突然起飞。8 卡机器都未必扛得住极限长文的并发。所以私有化部署时我的习惯是先看业务数据分布。如果用户上传的文档大部分不超过几万字--max-model-len设成 32768 或者 65536 就够了。注意这个参数设小了超长请求会被直接拒绝并返回 400 错误设大了显存压力大。需要你在两者之间做个取舍。如果确实要支持超长文本务必开启 vLLM 的 prefix caching 能力--enable-prefix-caching它能让相同前缀的请求复用 KV Cache长文档多轮问答场景下性能提升非常明显。4. 单机异构一块 A100 加一块 4090别把 vLLM 张量并行直接拉满4.1 为什么异构卡放一个 TP 组会出事单机异构最典型的一个误区机器上有 8 张卡为了追求吞吐直接把--tensor-parallel-size 8拉上去结果启动报错、推理卡顿、显存 OOM 各种问题一起来。原因在于张量并行是模型在每一层计算时把矩阵切成多块分给多张卡同时算算完还要做 allreduce 汇总。这个机制隐含了一个前提参与并行计算的卡算力和通信能力不能差太多。如果一张 A100 和一张 4090 组进同一个 TP 组所有卡必须每层都同步一次快的卡要等慢的卡。4090 的 PCIe 带宽和 A100 的 NVLink 带宽也不在一个量级通信瓶颈会被无限放大。vLLM 对异构混插的支持虽然一直在演进但为了保证稳定我始终建议把相同型号、相同显存规格的卡分在一组不同组跑不同实例再在实例前面加一层路由。这比硬塞到一个 TP 组里要稳得多。4.2 一个实际案例2×A100-80G 2×4090-24G假设你这台机器上有两张 A100 80G 和两张 4090 24G。用nvidia-smi确认编号后可以这样规划GPU 0、1 是 A100跑一个相对完整的实例上下文设长一点GPU 2、3 是 4090如果显存放得下量化权重可以跑第二个实例上下文设短一点承担小请求两台实例对外看起来是同一个模型名但内部配置不同。启动方式就是用CUDA_VISIBLE_DEVICES把进程分别绑定到不同 GPU 上# 实例 A跑在 A100 上 CUDA_VISIBLE_DEVICES0,1 python -m vllm.entrypoints.openai.api_server \ --model /models/glm-5.3-flash \ --served-model-name glm-5.3-flash \ --tensor-parallel-size 2 \ --max-model-len 131072 \ --enable-prefix-caching \ --port 8001 # 实例 B跑在 4090 上用量化权重 CUDA_VISIBLE_DEVICES2,3 python -m vllm.entrypoints.openai.api_server \ --model /models/glm-5.3-flash-awq \ --served-model-name glm-5.3-flash \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --port 8002两个实例监听不同端口。这个方案的巧妙之处在于大请求或长上下文请求落在 A100 上短小快速请求落到 4090 上也能扛得住4090 虽然显存小但单请求处理速度并不慢胜在数量多了也能分摊压力。如果机器里还有更多卡你可以按照同样的思路继续拆。比如 8 张 A100 加几张 4090 的机器A100 组可以跑一个 TP8 的大实例用于高吞吐也可以拆成两个 TP4 的实例用于高可用4090 组则跑量化小实例。4.3 异构流量的分发Nginx 一挡外面只看到一个入口两个实例都启动后不能让调用方自己挑端口。用一个 Nginx 做反向代理外面统一暴露 8000 端口Nginx 按负载策略把请求分发到 8001 和 8002。upstream glm_backend { least_conn; server 127.0.0.1:8001 max_fails2 fail_timeout30s; server 127.0.0.1:8002 max_fails2 fail_timeout30s; } server { listen 8000; location /v1/ { proxy_pass http://glm_backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_read_timeout 600s; proxy_connect_timeout 5s; } }注意两点一是proxy_http_version 1.1并清掉Connection头是为了让上游复用连接否则每次请求都重建 TCP 会话长文本场景下延迟会明显变高二是proxy_read_timeout一定要设长一些长上下文的生成时间可能远超普通接口的几秒超时设成 60 秒可能不够我这边是按 600 秒来设的。least_conn适合这种后端能力不均衡的场景它会优先把请求分给当前活跃连接数少的实例。如果你想更精细地控制比如让某些请求优先走 A100 实例可以基于 URL 路径或者请求头里的标识位做路由但这在异构场景里属于进阶玩法一般用不上。4.4 异构环境里关于资源和故障的真实心得异构部署稳定跑了一段时间后有几点体会值得分享。第一异构环境下监控必须到卡级。nvidia-smi dmon可以实时看每张卡的利用率、显存、温度或者用nvtop也行。我遇到过一种情况两个实例都在跑但 A100 利用率只有 20%4090 已经 100% 满载。原因是我把默认权重指向了 4090 实例量化版本却没人调用。这时候你需要回头审视流量路由是不是符合预期而不是一味加卡。第二显存碎片在异构机器上更明显。24G 的卡跑长上下文时偶尔会出现显存还剩几个 G 但请求依然 OOM。vLLM 的 PagedAttention 已经降低了碎片影响但你如果同时开了很多不同长度的请求碎片还是会出现。缓解办法是适当降低--max-num-seqs并且尽量让同实例的请求长度分布接近。第三异构环境可以救急但不应该成为长期架构。如果你的核心业务是大吞吐高并发最后大概率还是会把服务收敛到同型号的卡上把异构机器只作为开发和预生产环境这是一种成本与稳定性的折中。5. 多卡生产服务8×A100 之上把服务做成能扛压的样子5.1 生产部署参数不是拍脑袋定的进入生产环节后第一步反而是算账。你需要明确几个数字预计 QPS、单请求平均输入长度、单请求平均输出长度、最大上下文。把这几个数字代入一个粗估预估吞吐 QPS ×输入 token 输出 token× 8比如你希望支持 20 路并发每路平均消耗 2000 token 输入 2000 token 输出那一分钟就是 20 × 4000 80000 token。单张 A100 在 vLLM 下跑 Flash 级模型的生成吞吐大概能到 3000-6000 token/s这个数字取决于模型规模、量化、显卡型号实际以压测为准。8 卡如果做单一实例理论上吞吐可能有几万 token/s但那是理论值算上排队、波动、资源碎片实际能到一半就很不错了。所以生产环境的参数调整核心逻辑是先用小并发跑通再逐步加压找到显存和延迟之间的平衡点。不要一上来就调大--max-num-seqs和--max-model-len那样只会得到一个频繁 OOM 的不稳定服务。5.2 8×A100 的部署配置和 Docker 化如果 8 张卡都是 A100 80G模型权重完整精度装得下那么通常有两种拓扑选择一种是单实例 TP8即 8 张卡同时服务于一个模型。这样吞吐最高显存利用率最充分缺点是单实例故障会影响全部流量重启时间也比较长。另一种是拆成 2 个实例每个实例 TP4前面 Nginx 做负载均衡。这样吞吐可能略低一点因为每 4 张卡各自维护一组 KV Cache无法共享但好处是一个实例发布或故障时另一个还能继续服务。对于生产服务我通常更倾向后者先把可用性保住再去优化吞吐。Docker Compose 是管理单机多实例最合适的方式。下面是一个 8 卡机器上拆成两个 TP4 实例的 Compose 配置services: glm-flash-a: image: vllm/vllm-openai:latest shm_size: 64gb command: - --model - /models/glm-5.3-flash - --served-model-name - glm-5.3-flash - --tensor-parallel-size - 4 - --max-model-len - 131072 - --gpu-memory-utilization - 0.92 - --host - 0.0.0.0 - --port - 8000 environment: - CUDA_VISIBLE_DEVICES0,1,2,3 volumes: - /models:/models:ro deploy: resources: reservations: devices: - driver: nvidia device_ids: [0, 1, 2, 3] capabilities: [gpu] ports: - 8001:8000 healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 30s timeout: 10s retries: 3 glm-flash-b: image: vllm/vllm-openai:latest shm_size: 64gb command: - --model - /models/glm-5.3-flash - --served-model-name - glm-5.3-flash - --tensor-parallel-size - 4 - --max-model-len - 131072 - --gpu-memory-utilization - 0.92 - --host - 0.0.0.0 - --port - 8000 environment: - CUDA_VISIBLE_DEVICES4,5,6,7 volumes: - /models:/models:ro deploy: resources: reservations: devices: - driver: nvidia device_ids: [4, 5, 6, 7] capabilities: [gpu] ports: - 8002:8000 healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 30s timeout: 10s retries: 3shm_size是共享内存默认 64MB 往往不够大模型运行时使用。数据加载、tokenizer、某些算子中间结果都会走/dev/shm调成 64GB 基本不会再遇到共享内存不足的问题。gpu-memory-utilization 0.92意思是让 vLLM 最多使用单卡 92% 的显存留出一点余量给 CUDA 上下文和其他进程避免直接打满导致驱动重置。5.3 多副本接入层与发版策略两个实例都跑起来以后接入层只需要把之前的 Nginx 配置改成指向 8001 和 8002 两个端口即可这里不再重复。需要注意的是 keepalive 和超时配置要加够生产环境中如果默认超时太短长输出请求会被 Nginx 拦截断开前端表现为回答到一半报错。发版策略也很重要。vLLM 每次升级都可能引入一些行为变化。如果不打算滚动升级至少要保证两个实例的版本一致。实操中我的流程是先挑一个实例改镜像跑通冒烟测试确认没有回归再同步另一个实例。这个过程在 Compose 下就是滚动更新配合 healthcheck当新实例健康检查通过后才摘掉旧实例。5.4 压测、可观测性和告警指标部署完成后必须做一次压测否则你根本不知道服务的真实水位在哪。vLLM 自带 benchmark 脚本python -m vllm.benchmark.benchmark_serving \ --backend openai \ --model glm-5.3-flash \ --base-url http://localhost:8000 \ --endpoint /v1/chat/completions \ --num-prompts 200 \ --request-rate 10request-rate从 1 开始往上加观察输出 token 的匀速程度和 p99 延迟。当延迟开始非线性上涨时说明已经接近并发上限这时候记下当前的 QPS 和吞吐作为容量规划的基线。线上监控方面vLLM 暴露了/metrics接口Prometheus 可以直接抓取。我重点关注四个指标gpu_cache_usage_percKV Cache 利用率接近 1 说明缓存紧张requests_running正在跑的请求数requests_waiting排队的请求数持续上涨说明容量不足平均生成吞吐以及 p99 每次生成的首 token 延迟。当requests_waiting持续超过设定阈值就应当告警并扩容。扩容不一定加卡也可以把量化实例的流量分担一部分这是异构资源池在紧急情况下的最大价值。5.5 部署和运维过程中几个让人头疼的报错多卡生产部署中报错往往集中在几个特定环节。我把最近常被问到的问题整理成一张速查表。报错现象原因处理方式Permission denied while trying to connect to the Docker API当前用户不在 docker 组或 Docker 服务未启动sudo usermod -aG docker $USER后重新登录systemctl status docker确认服务正常vLLM 启动后找不到 GPUCUDA_VISIBLE_DEVICES范围与实际卡号不一致或驱动不匹配nvidia-smi确认卡物理编号核对环境变量显存足够但模型一直 OOM--max-model-len设得过大KV Cache 预分配太多调小上下文长度或开 prefix caching请求一进来就被 400 拒绝调用模型名与--served-model-name不一致在/v1/models接口查看实际模型名长输出在中途断掉接入层超时时间太短Nginxproxy_read_timeout调长到 600s 以上单实例故障导致全站不可用只有一个副本没有做负载均衡拆成多实例或部署到多机6. 从 API 到裸机部署几个反复出现的问题和我的最终建议6.1 无论怎么切换部署形态先查模型名、再查显存配置如果你让我把这一路部署踩过的坑浓缩成一句话那就是后端报错先查模型名启动报错先查显存配置网络超时先查接入层。模型名问题几乎贯穿所有部署形态API 阶段可能因为网关白名单不认名字vLLM 本地启动后可能因为--served-model-name没设对调用方 404Docker 多实例部署后可能因为内部服务端口冲突导致 Nginx 把请求转发到旧实例。你在搜索引擎里看到的大量the supported api model names are ...报错本质都是这个。显存配置则主要卡在--max-model-len和并发上。单机部署时我见过有人开了默认的 1M 上下文然后请求稍微一多就 OOM也见过有人为了省显存把上下文压到 4096结果用户贴了一个稍长的文档进来就报 400。正确做法是先统计业务请求的长度分布再倒推参数。6.2 和 DeepSeek V4 Flash 的对比说说使用感受因为群里不少人问 GLM-5.3-Flash 和 DeepSeek V4 Flash 的取舍我简单说下自己的感受。两者的 API 风格都很接近 OpenAI接入成本不高在代码生成和中文指令理解上GLM-5.3-Flash 的表现我个人觉得更稳一点尤其多轮中文对话的跟随性更强。DeepSeek V4 Flash 也非常能打尤其在极低延迟场景下有自己的优势。但这种纯主观体验只能作为参考实际选型还是要拿自己的业务数据去跑不要看几个公开榜单就下结论。部署层面的差异不大两边的实现都已经很成熟真正决定优劣的反而是你的调用场景和 
长河君 · 2026/9/5 5:58:36 · 阅读 1.2k GLM-5.3-Flash部署实战：从API到多卡生产服务的完整路径
数据模型没定、部署链路没谱的时候我一般不会去碰卡。GLM-5.3-Flash 这几天讨论度很高群里天天有人问怎么在 8 卡 A100 上跑起来能不能接 ccswitch/codex跟 DeepSeek V4 Flash 比怎么样。这篇东西不聊跑分直接按我实际验证过的路径来先 API 跑通再单机部署然后处理单机异构资源最后落到多卡生产服务。每一步都会把为什么这么搬、以及踩过的坑写清楚照着走比直接翻官方 README 省事得多。1. 部署规划的底层逻辑先想清楚 Flash 模型和传统开源模型的差别1.1 GLM-5.3-Flash 到底适合谁来用GLM-5.3-Flash 是智谱 GLM 系列里主打低延迟、低成本的那一档。它的特点和那种参数越大越猛的旗舰模型不同更像是一个在性能、成本、部署难度之间找平衡点的产物。最近大家都在说它进入了 Pareto 区通俗点解释就是如果画一张图横轴是部署成本纵轴是实际效果你会发现很多模型要么效果差一点但便宜要么效果好但贵得离谱而 Flash 刚好落在不用花旗舰的钱又能跑出可用效果的边界上。对绝大多数业务场景来说这就够了。我自己测下来的感受是它适合三类人一类是中小团队想做 Agent 或 RAG不想为每次调用付太多钱但又不想完全放弃效果一类是独立开发者想本地跑一个不占太多显存的服务给自己或者小范围用户用还有一类是平台工程师需要在新业务里快速验证模型形态先把链路打通再决定是否上更大规模。所以部署规划不能上来就奔着 8 卡去。正确的顺序应该是先在 API 形态下把业务逻辑和模型能力验证完再判断要不要私有化私有化之后再根据手里的卡去决定单机、异构还是多卡。很多团队的错误就是第一步还没跑通就租了一台 8×A100 开始折腾结果权重还没下完需求已经变了。1.2 API、单机、异构、多卡之间差的是哪一层这里说的四个阶段不是同一个东西的四种说法而是四种完全不同的工程状态。API 阶段你只是调用方不需要关心 GPU、显存、并发只需要把模型名和鉴权信息填对。这一阶段解决的问题是这个模型适不适合我的业务。单机部署是把模型权重拉到自己的机器上用一张或两张卡跑一个本地服务。这个阶段你要开始处理推理引擎、显存占用、模型并发、上下文长度这些底层问题。适合数据敏感、高频调用、或者单纯想省 API 费用的场景。单机异构严格来说是单机部署的一种特殊形态但它和插两块同型号卡差别很大。异构意味着机器上可能同时有 A100 和 4090或者不同品牌、不同显存大小的加速卡混插。此时难点不是模型本身而是怎么让这些能力不一致的卡协同工作不出现一块卡累死、另一块卡闲死的局面。多卡生产服务则是往对外提供稳定服务这个目标走。需要考虑的不只是启动一个模型进程还有多副本负载均衡、队列排队、超时控制、监控告警、以及部署升级时业务不中断。到这一步推理引擎反而只是其中一环。把这几个阶段在脑子里面分清后面每个章节就都有明确的上下文了。1.3 环境方面先达成共识避免后面各种莫名其妙不管你是单机还是多卡下面几项最好先统一操作系统Ubuntu 20.04/22.04 优先生产环境不要用 Windows 裸机跑GPU 驱动建议 535 或更高版本直接决定了 CUDA 运行时能不能正常走CUDA 环境统一在容器里配别在物理机上乱装版本冲突会让你怀疑人生PyTorch 与 vLLM/SGLang版本尽量跟随推理引擎的官方要求我会在后面的章节说明具体选择存储模型权重放 NVMe SSD 上冷启动加载速度相差很大尤其是多卡并发加载的时候。先用nvidia-smi确认所有卡能被系统识别再确认每张卡的型号、驱动版本、显存大小。异构环境尤其要看这一步因为后续你给 GPU 分组、分配模型实例依据就是这份清单。别嫌这个动作基础我真的见过有人到 vLLM 启动时报no available GPU才发现驱动没装好。2. API 先跑通最快的验证路径也是最容易被文档坑的地方2.1 开通 Key 和调用模型名一字都不能错API 接入的步骤其实很短去平台开通账号、创建 API Key、然后按接口文档调用。但我在实际操作中发现最容易出问题的不是鉴权而是模型名。GLM-5.3-Flash 在不同渠道里可能有不同叫法比如有的网关会带上[1m]后缀表示 1M 上下文版本有的地方只认glm-5.3-flash这个裸名。如果你用的是官方兼容接口模型名里带不带后缀需要问清楚。热词里那条The supported API model names are deepseek-v4-pro, deepseek-v4-flash...的报错就是因为某个兼容网关只允许它白名单里的模型名你的调用方传了别的名字进去服务端直接拒了。这不是模型能力问题是配置问题。所以接入时先用最干净的方式验证一次curl https://api.zhipu-ai.com/api/paas/v4/chat/completions \ -H Authorization: Bearer $ZHIPU_API_KEY \ -H Content-Type: application/json \ -d { model: glm-5.3-flash, messages: [ {role: user, content: 用一句话说明什么是张量并行} ] }注意把ZHIPU_API_KEY配到环境变量里别写死在代码和 Shell 历史里。还有如果你新注册账号通常会有免费额度最近的活动大概是赠送 1 亿 token 的体验包用来做功能验证完全够用不用一上来就充值。2.2 Python 最小调用脚本以及流式输出日常开发里我基本都是用 OpenAI SDK 去调因为接口风格是兼容的迁移成本很低。下面这个脚本是能跑的最小可复现版本import os from openai import OpenAI client OpenAI( api_keyos.environ.get(ZHIPU_API_KEY), base_urlhttps://api.zhipu-ai.com/api/paas/v4, ) resp client.chat.completions.create( modelglm-5.3-flash, messages[ {role: system, content: 你是一个擅长总结的助手。}, {role: user, content: 给我梳理一下大模型部署的四个阶段。}, ], temperature0.7, ) print(resp.choices[0].message.content)流式输出会把首 token 延迟压得很低聊天的体验会好很多。做法是把上面的create加上streamTrue然后迭代resp里的choices[0].delta.content。我这里多提一句如果你做的是 C 端产品能开流式就开流式用户对一个字一个字蹦出来的容忍度远高于转圈 10 秒然后一次性输出。还有一点部分新模型支持thinking_budget这个参数来控制思考深度它的语义是让模型在正式回答前多花一些内部推理过程。这个参数必须是正整数如果你传了0、负数或者字符串就会遇到热搜里那条api error: 400 the thinking_budget parameter must be a positive integer。这个报错已经在不少群里出现过属于新人高频问题。2.3 1M 上下文的正确打开方式我注意到很多人一听到1M 上下文就把整本小说往里塞。模型能接住 1048576 个 token 是一回事你的业务能不能用好是另一回事。先说报错。如果你调用时超过上限会看到类似this models maximum context length is 1048576 tokens. However, your request exceeds...的提示。这个逻辑不难理解系统统计的是 prompt 里的 token 总长度不是字符数。中文一个汉字可能对应一到两个 token英文一个单词可能拆成几个 token。你以为没超实际上可能已经逼近上限。另外一个报错是网关层提示theres an issue with the selected model (glm-5.3-flash[1m])。这通常意味着你的代理或接入层尝试选择一个不存在的变体名比如代码里写了glm-5.3-flash[1m]但后端实际注册的是glm-5.3-flash。两边模型名不一致而已。真正在 API 里跑长文档时我的建议是分块检索不要全量灌入。1M 上下文最大的价值是让你不用精心裁剪文档而不是逼你把所有内容一次塞完。把该用的段落检索出来再组装 prompt无论延迟还是成本都会健康很多。3. 单机本地部署从拿到权重到跑通 OpenAI 兼容服务3.1 权重获取别只盯着一个来源当你决定私有化部署第一步就是拿到权重文件。我一般优先从 ModelScope 拉因为国内网络环境下速度和稳定性都更好而且它的文件组织形式和 Hugging Face 基本一致。拉取之前先看清楚模型卡页面的说明有些模型会拆成多个分片.safetensors文件按索引划分不要只下载一个文件就以为完事了。完整模型目录起码应该包含config.json tokenizer.json tokenizer_config.json model.safetensors.index.json model-00001-of-0000X.safetensors ...下载完别急着启动推理引擎先做一次文件完整性校验。常见做法是对比下载目录里的 SHA256 值ModelScope 页面一般会给出参考值。这个步骤在单卡时可能觉得多余但如果你后面要把权重拷贝到多台生产机器上校验能避免拷贝了一半但看起来成功的隐性问题。3.2 推理引擎选型为什么我建议先考虑 vLLM选推理引擎是个很容易被忽略但决定后面所有体验的决策。几个主流选项Ollama部署最简单一条命令就能跑适合本机体验和开发调试。但它为了易用性做了很多抽象真正要精细控制并发、量化、上下文缓存时反而束手束脚。vLLM吞吐量大PagedAttention 对 KV Cache 的管理很成熟OpenAI 兼容接口开箱即用。生产环境里我用得最多的是它。SGLang在复杂调度和某些长文本场景下有优势但生态和资料相对少一点新手不建议第一个项目就上手。我的建议是自己一个人玩选 Ollama 没问题要给团队或者外部提供 API直接选 vLLM省得后面迁移。后面的示例我也统一用 vLLM。安装这一步用 pip 直接装通常没问题pip install vllm不过生产建议用官方 Docker 镜像原因是 vLLM 对 CUDA、PyTorch 的版本耦合很紧pip 装很可能把系统里已有的 Python 环境搞得一团糟。Docker 镜像是官方踩过坑之后打包好的出问题概率小很多。3.3 单机启动命令与最小验证假设你只有一张卡模型目录在/models/glm-5.3-flash最简单启动方式如下CUDA_VISIBLE_DEVICES0 python -m vllm.entrypoints.openai.api_server \ --model /models/glm-5.3-flash \ --served-model-name glm-5.3-flash \ --tensor-parallel-size 1 \ --max-model-len 32768 \ --max-num-seqs 8 \ --host 0.0.0.0 \ --port 8000几个参数我解释一下--served-model-name是外部调用时看到的模型名。你可以把它设成任何名字但建议还是设成glm-5.3-flash避免接入方困惑。--tensor-parallel-size是张量并行度。单卡就写 1后面多卡再改。--max-model-len是允许的最大上下文长度。默认值可能接近模型原生上限如果显存不大先设成 32768 跑通再说。--max-num-seqs控制同时处理的序列数。设太大在长上下文中很容易 OOM先保守一点。启动日志里如果出现Starting vLLM using ... GPU并且没有任何 error就说明模型加载成功了。然后用和 API 几乎一样的方式验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: glm-5.3-flash, messages: [{role: user, content: 你好}] }看到正常返回单机版就算通了。这时候拿最开始写的 Python 脚本把base_url改成http://localhost:8000/v1其他逻辑都不用动这就是 OpenAI 兼容接口的好处。3.4 显存怎么估以及量化要不要上显存预估我习惯用这个公式打底模型权重大小 KV Cache 激活值 一定冗余。权重大小很容易看把模型目录里所有.safetensors文件大小加起来就行。如果是 FP16/BF16 精度70B 左右模型大约 140GB 权重如果按 INT4 量化大约 35-40GB。这也是为什么单卡部署这种规模必须量化以及为什么Flash这种保留效率的档位会在单机上更实用。KV Cache 的大小取决于并发序列数、上下文长度和层数。vLLM 采用 PagedAttention 后不会一次性把所有显存吃光但如果你设了很大的--max-model-len又开高并发KV Cache 增长会非常快。显存不够时的选择优先级我一般是这样先降--max-model-len只保留业务真正需要的上下文长度再降--max-num-seqs限制并发还不够才考虑量化。量化方案上AWQ 和 GPTQ 是常用的 PTQ 方案。AWQ 对显存占用和推理速度兼顾得比较好而且它对模型效果的影响在多数任务上可以接受。如果你拿到的是官方或社区验证过的量化版本优先用现成的量化权重别自己拿脚本去量化大模型耗时不说精度损失还很难把控。需要留意的是量化版本的部署方式和原版完全一样vLLM 会读取权重里的量化配置自动处理。3.5 单机版最容易被忽视的细节上下文长度别默认拉满刚才提到了--max-model-len我在这里单独展开一下因为这是单机部署新手翻车最多的地方。GLM-5.3-Flash 原生支持 1M 上下文也就是 1048576 个 token。听起来很爽但如果你启动时不做限制vLLM 会按这个长度去预留 KV Cache 和计算结构。哪怕你的并发只有 2 个请求只要某一次请求比较长显存占用就会突然起飞。8 卡机器都未必扛得住极限长文的并发。所以私有化部署时我的习惯是先看业务数据分布。如果用户上传的文档大部分不超过几万字--max-model-len设成 32768 或者 65536 就够了。注意这个参数设小了超长请求会被直接拒绝并返回 400 错误设大了显存压力大。需要你在两者之间做个取舍。如果确实要支持超长文本务必开启 vLLM 的 prefix caching 能力--enable-prefix-caching它能让相同前缀的请求复用 KV Cache长文档多轮问答场景下性能提升非常明显。4. 单机异构一块 A100 加一块 4090别把 vLLM 张量并行直接拉满4.1 为什么异构卡放一个 TP 组会出事单机异构最典型的一个误区机器上有 8 张卡为了追求吞吐直接把--tensor-parallel-size 8拉上去结果启动报错、推理卡顿、显存 OOM 各种问题一起来。原因在于张量并行是模型在每一层计算时把矩阵切成多块分给多张卡同时算算完还要做 allreduce 汇总。这个机制隐含了一个前提参与并行计算的卡算力和通信能力不能差太多。如果一张 A100 和一张 4090 组进同一个 TP 组所有卡必须每层都同步一次快的卡要等慢的卡。4090 的 PCIe 带宽和 A100 的 NVLink 带宽也不在一个量级通信瓶颈会被无限放大。vLLM 对异构混插的支持虽然一直在演进但为了保证稳定我始终建议把相同型号、相同显存规格的卡分在一组不同组跑不同实例再在实例前面加一层路由。这比硬塞到一个 TP 组里要稳得多。4.2 一个实际案例2×A100-80G 2×4090-24G假设你这台机器上有两张 A100 80G 和两张 4090 24G。用nvidia-smi确认编号后可以这样规划GPU 0、1 是 A100跑一个相对完整的实例上下文设长一点GPU 2、3 是 4090如果显存放得下量化权重可以跑第二个实例上下文设短一点承担小请求两台实例对外看起来是同一个模型名但内部配置不同。启动方式就是用CUDA_VISIBLE_DEVICES把进程分别绑定到不同 GPU 上# 实例 A跑在 A100 上 CUDA_VISIBLE_DEVICES0,1 python -m vllm.entrypoints.openai.api_server \ --model /models/glm-5.3-flash \ --served-model-name glm-5.3-flash \ --tensor-parallel-size 2 \ --max-model-len 131072 \ --enable-prefix-caching \ --port 8001 # 实例 B跑在 4090 上用量化权重 CUDA_VISIBLE_DEVICES2,3 python -m vllm.entrypoints.openai.api_server \ --model /models/glm-5.3-flash-awq \ --served-model-name glm-5.3-flash \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --port 8002两个实例监听不同端口。这个方案的巧妙之处在于大请求或长上下文请求落在 A100 上短小快速请求落到 4090 上也能扛得住4090 虽然显存小但单请求处理速度并不慢胜在数量多了也能分摊压力。如果机器里还有更多卡你可以按照同样的思路继续拆。比如 8 张 A100 加几张 4090 的机器A100 组可以跑一个 TP8 的大实例用于高吞吐也可以拆成两个 TP4 的实例用于高可用4090 组则跑量化小实例。4.3 异构流量的分发Nginx 一挡外面只看到一个入口两个实例都启动后不能让调用方自己挑端口。用一个 Nginx 做反向代理外面统一暴露 8000 端口Nginx 按负载策略把请求分发到 8001 和 8002。upstream glm_backend { least_conn; server 127.0.0.1:8001 max_fails2 fail_timeout30s; server 127.0.0.1:8002 max_fails2 fail_timeout30s; } server { listen 8000; location /v1/ { proxy_pass http://glm_backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_read_timeout 600s; proxy_connect_timeout 5s; } }注意两点一是proxy_http_version 1.1并清掉Connection头是为了让上游复用连接否则每次请求都重建 TCP 会话长文本场景下延迟会明显变高二是proxy_read_timeout一定要设长一些长上下文的生成时间可能远超普通接口的几秒超时设成 60 秒可能不够我这边是按 600 秒来设的。least_conn适合这种后端能力不均衡的场景它会优先把请求分给当前活跃连接数少的实例。如果你想更精细地控制比如让某些请求优先走 A100 实例可以基于 URL 路径或者请求头里的标识位做路由但这在异构场景里属于进阶玩法一般用不上。4.4 异构环境里关于资源和故障的真实心得异构部署稳定跑了一段时间后有几点体会值得分享。第一异构环境下监控必须到卡级。nvidia-smi dmon可以实时看每张卡的利用率、显存、温度或者用nvtop也行。我遇到过一种情况两个实例都在跑但 A100 利用率只有 20%4090 已经 100% 满载。原因是我把默认权重指向了 4090 实例量化版本却没人调用。这时候你需要回头审视流量路由是不是符合预期而不是一味加卡。第二显存碎片在异构机器上更明显。24G 的卡跑长上下文时偶尔会出现显存还剩几个 G 但请求依然 OOM。vLLM 的 PagedAttention 已经降低了碎片影响但你如果同时开了很多不同长度的请求碎片还是会出现。缓解办法是适当降低--max-num-seqs并且尽量让同实例的请求长度分布接近。第三异构环境可以救急但不应该成为长期架构。如果你的核心业务是大吞吐高并发最后大概率还是会把服务收敛到同型号的卡上把异构机器只作为开发和预生产环境这是一种成本与稳定性的折中。5. 多卡生产服务8×A100 之上把服务做成能扛压的样子5.1 生产部署参数不是拍脑袋定的进入生产环节后第一步反而是算账。你需要明确几个数字预计 QPS、单请求平均输入长度、单请求平均输出长度、最大上下文。把这几个数字代入一个粗估预估吞吐 QPS ×输入 token 输出 token× 8比如你希望支持 20 路并发每路平均消耗 2000 token 输入 2000 token 输出那一分钟就是 20 × 4000 80000 token。单张 A100 在 vLLM 下跑 Flash 级模型的生成吞吐大概能到 3000-6000 token/s这个数字取决于模型规模、量化、显卡型号实际以压测为准。8 卡如果做单一实例理论上吞吐可能有几万 token/s但那是理论值算上排队、波动、资源碎片实际能到一半就很不错了。所以生产环境的参数调整核心逻辑是先用小并发跑通再逐步加压找到显存和延迟之间的平衡点。不要一上来就调大--max-num-seqs和--max-model-len那样只会得到一个频繁 OOM 的不稳定服务。5.2 8×A100 的部署配置和 Docker 化如果 8 张卡都是 A100 80G模型权重完整精度装得下那么通常有两种拓扑选择一种是单实例 TP8即 8 张卡同时服务于一个模型。这样吞吐最高显存利用率最充分缺点是单实例故障会影响全部流量重启时间也比较长。另一种是拆成 2 个实例每个实例 TP4前面 Nginx 做负载均衡。这样吞吐可能略低一点因为每 4 张卡各自维护一组 KV Cache无法共享但好处是一个实例发布或故障时另一个还能继续服务。对于生产服务我通常更倾向后者先把可用性保住再去优化吞吐。Docker Compose 是管理单机多实例最合适的方式。下面是一个 8 卡机器上拆成两个 TP4 实例的 Compose 配置services: glm-flash-a: image: vllm/vllm-openai:latest shm_size: 64gb command: - --model - /models/glm-5.3-flash - --served-model-name - glm-5.3-flash - --tensor-parallel-size - 4 - --max-model-len - 131072 - --gpu-memory-utilization - 0.92 - --host - 0.0.0.0 - --port - 8000 environment: - CUDA_VISIBLE_DEVICES0,1,2,3 volumes: - /models:/models:ro deploy: resources: reservations: devices: - driver: nvidia device_ids: [0, 1, 2, 3] capabilities: [gpu] ports: - 8001:8000 healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 30s timeout: 10s retries: 3 glm-flash-b: image: vllm/vllm-openai:latest shm_size: 64gb command: - --model - /models/glm-5.3-flash - --served-model-name - glm-5.3-flash - --tensor-parallel-size - 4 - --max-model-len - 131072 - --gpu-memory-utilization - 0.92 - --host - 0.0.0.0 - --port - 8000 environment: - CUDA_VISIBLE_DEVICES4,5,6,7 volumes: - /models:/models:ro deploy: resources: reservations: devices: - driver: nvidia device_ids: [4, 5, 6, 7] capabilities: [gpu] ports: - 8002:8000 healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 30s timeout: 10s retries: 3shm_size是共享内存默认 64MB 往往不够大模型运行时使用。数据加载、tokenizer、某些算子中间结果都会走/dev/shm调成 64GB 基本不会再遇到共享内存不足的问题。gpu-memory-utilization 0.92意思是让 vLLM 最多使用单卡 92% 的显存留出一点余量给 CUDA 上下文和其他进程避免直接打满导致驱动重置。5.3 多副本接入层与发版策略两个实例都跑起来以后接入层只需要把之前的 Nginx 配置改成指向 8001 和 8002 两个端口即可这里不再重复。需要注意的是 keepalive 和超时配置要加够生产环境中如果默认超时太短长输出请求会被 Nginx 拦截断开前端表现为回答到一半报错。发版策略也很重要。vLLM 每次升级都可能引入一些行为变化。如果不打算滚动升级至少要保证两个实例的版本一致。实操中我的流程是先挑一个实例改镜像跑通冒烟测试确认没有回归再同步另一个实例。这个过程在 Compose 下就是滚动更新配合 healthcheck当新实例健康检查通过后才摘掉旧实例。5.4 压测、可观测性和告警指标部署完成后必须做一次压测否则你根本不知道服务的真实水位在哪。vLLM 自带 benchmark 脚本python -m vllm.benchmark.benchmark_serving \ --backend openai \ --model glm-5.3-flash \ --base-url http://localhost:8000 \ --endpoint /v1/chat/completions \ --num-prompts 200 \ --request-rate 10request-rate从 1 开始往上加观察输出 token 的匀速程度和 p99 延迟。当延迟开始非线性上涨时说明已经接近并发上限这时候记下当前的 QPS 和吞吐作为容量规划的基线。线上监控方面vLLM 暴露了/metrics接口Prometheus 可以直接抓取。我重点关注四个指标gpu_cache_usage_percKV Cache 利用率接近 1 说明缓存紧张requests_running正在跑的请求数requests_waiting排队的请求数持续上涨说明容量不足平均生成吞吐以及 p99 每次生成的首 token 延迟。当requests_waiting持续超过设定阈值就应当告警并扩容。扩容不一定加卡也可以把量化实例的流量分担一部分这是异构资源池在紧急情况下的最大价值。5.5 部署和运维过程中几个让人头疼的报错多卡生产部署中报错往往集中在几个特定环节。我把最近常被问到的问题整理成一张速查表。报错现象原因处理方式Permission denied while trying to connect to the Docker API当前用户不在 docker 组或 Docker 服务未启动sudo usermod -aG docker $USER后重新登录systemctl status docker确认服务正常vLLM 启动后找不到 GPUCUDA_VISIBLE_DEVICES范围与实际卡号不一致或驱动不匹配nvidia-smi确认卡物理编号核对环境变量显存足够但模型一直 OOM--max-model-len设得过大KV Cache 预分配太多调小上下文长度或开 prefix caching请求一进来就被 400 拒绝调用模型名与--served-model-name不一致在/v1/models接口查看实际模型名长输出在中途断掉接入层超时时间太短Nginxproxy_read_timeout调长到 600s 以上单实例故障导致全站不可用只有一个副本没有做负载均衡拆成多实例或部署到多机6. 从 API 到裸机部署几个反复出现的问题和我的最终建议6.1 无论怎么切换部署形态先查模型名、再查显存配置如果你让我把这一路部署踩过的坑浓缩成一句话那就是后端报错先查模型名启动报错先查显存配置网络超时先查接入层。模型名问题几乎贯穿所有部署形态API 阶段可能因为网关白名单不认名字vLLM 本地启动后可能因为--served-model-name没设对调用方 404Docker 多实例部署后可能因为内部服务端口冲突导致 Nginx 把请求转发到旧实例。你在搜索引擎里看到的大量the supported api model names are ...报错本质都是这个。显存配置则主要卡在--max-model-len和并发上。单机部署时我见过有人开了默认的 1M 上下文然后请求稍微一多就 OOM也见过有人为了省显存把上下文压到 4096结果用户贴了一个稍长的文档进来就报 400。正确做法是先统计业务请求的长度分布再倒推参数。6.2 和 DeepSeek V4 Flash 的对比说说使用感受因为群里不少人问 GLM-5.3-Flash 和 DeepSeek V4 Flash 的取舍我简单说下自己的感受。两者的 API 风格都很接近 OpenAI接入成本不高在代码生成和中文指令理解上GLM-5.3-Flash 的表现我个人觉得更稳一点尤其多轮中文对话的跟随性更强。DeepSeek V4 Flash 也非常能打尤其在极低延迟场景下有自己的优势。但这种纯主观体验只能作为参考实际选型还是要拿自己的业务数据去跑不要看几个公开榜单就下结论。部署层面的差异不大两边的实现都已经很成熟真正决定优劣的反而是你的调用场景和