企业官网建设流程全解析

数据模型没定、部署链路没谱的时候，我一般不会去碰卡。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_key=os.environ.get("ZHIPU_API_KEY"), base_url="https://api.zhipu-ai.com/api/paas/v4", ) resp = client.chat.completions.create( model="glm-5.3-flash", messages=[ {"role": "system", "content": "你是一个擅长总结的助手。"}, {"role": "user", "content": "给我梳理一下大模型部署的四个阶段。"}, ], temperature=0.7, ) print(resp.choices[0].message.content)

流式输出会把首 token 延迟压得很低，聊天的体验会好很多。做法是把上面的create加上stream=True，然后迭代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 model's 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_DEVICES=0 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 增长会非常快。显存不够时的选择优先级，我一般是这样：

1. 先降--max-model-len，只保留业务真正需要的上下文长度；
2. 再降--max-num-seqs，限制并发；
3. 还不够，才考虑量化。

量化方案上，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_DEVICES=0,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_DEVICES=2,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 组可以跑一个 TP=8 的大实例用于高吞吐，也可以拆成两个 TP=4 的实例用于高可用；4090 组则跑量化小实例。

4.3 异构流量的分发：Nginx 一挡，外面只看到一个入口

两个实例都启动后，不能让调用方自己挑端口。用一个 Nginx 做反向代理，外面统一暴露 8000 端口，Nginx 按负载策略把请求分发到 8001 和 8002。

upstream glm_backend { least_conn; server 127.0.0.1:8001 max_fails=2 fail_timeout=30s; server 127.0.0.1:8002 max_fails=2 fail_timeout=30s; } 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，模型权重完整精度装得下，那么通常有两种拓扑选择：

一种是单实例 TP=8，即 8 张卡同时服务于一个模型。这样吞吐最高，显存利用率最充分，缺点是单实例故障会影响全部流量，重启时间也比较长。

另一种是拆成 2 个实例，每个实例 TP=4，前面 Nginx 做负载均衡。这样吞吐可能略低一点，因为每 4 张卡各自维护一组 KV Cache，无法共享，但好处是一个实例发布或故障时，另一个还能继续服务。对于生产服务，我通常更倾向后者，先把可用性保住，再去优化吞吐。

Docker Compose 是管理单机多实例最合适的方式。下面是一个 8 卡机器上拆成两个 TP=4 实例的 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_DEVICES=0,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_DEVICES=4,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: 3

shm_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 10

request-rate从 1 开始往上加，观察输出 token 的匀速程度和 p99 延迟。当延迟开始非线性上涨时，说明已经接近并发上限，这时候记下当前的 QPS 和吞吐，作为容量规划的基线。

线上监控方面，vLLM 暴露了/metrics接口，Prometheus 可以直接抓取。我重点关注四个指标：

• gpu_cache_usage_perc：KV Cache 利用率，接近 1 说明缓存紧张；
• requests_running：正在跑的请求数；
• requests_waiting：排队的请求数，持续上涨说明容量不足；
• 平均生成吞吐，以及 p99 每次生成的首 token 延迟。

当requests_waiting持续超过设定阈值，就应当告警并扩容。扩容不一定加卡，也可以把量化实例的流量分担一部分，这是异构资源池在紧急情况下的最大价值。

5.5 部署和运维过程中几个让人头疼的报错

多卡生产部署中，报错往往集中在几个特定环节。我把最近常被问到的问题整理成一张速查表。

6. 从 API 到裸机部署，几个反复出现的问题和我的最终建议

6.1 无论怎么切换部署形态，先查模型名、再查显存配置

如果你让我把这一路部署踩过的坑浓缩成一句话，那就是：后端报错先查模型名，启动报错先查显存配置，网络超时先查接入层。

模型名问题几乎贯穿所有部署形态：API 阶段可能因为网关白名单不认名字；vLLM 本地启动后可能因为--served-model-name没设对，调用方 404；Docker 多实例部署后，可能因为内部服务端口冲突，导致 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 也非常能打，尤其在极低延迟场景下有自己的优势。但这种纯主观体验只能作为参考，实际选型还是要拿自己的业务数据去跑，不要看几个公开榜单就下结论。部署层面的差异不大，两边的实现都已经很成熟，真正决定优劣的反而是你的调用场景和