GLM-5.3-Flash 发布之后很长一段时间都待在性价比的前沿区也就是大家常说的 Pareto 前沿成了很多团队做内部知识库、类 Codex Agent、对话产品时优先试跑的模型。但模型再好落地时该踩的坑一个都不会少。我见过太多人把时间浪费在部署路线的反复横跳上有人上来就申请官方 API跑了几天发现并发一高账单根本撑不住有人非要一步到位上 8 卡 A100 生产集群结果从驱动到推理引擎配了一周还没跑通一个请求还有人手上只有几张混着的显卡A100 和 4090 插在同一台机器里不知道怎么把显存都榨干。这篇文章就围绕这三个典型场景展开GLM-5.3-Flash 的 API 快速接入、单机异构环境的灵活部署、多卡生产服务的完整落地。适合刚拿到模型不知道往哪条路走的算法工程师也适合被生产稳定性按在地上摩擦的运维和平台研发。我会把每条路线背后的取舍逻辑、我实测过的启动命令、以及真实环境里踩过的坑都写清楚尽量做到每一步都能直接抄作业。1. 部署路径拆解API、单机异构、多卡生产分别解决什么问题1.1 这三条路线不是晋级关系而是不同约束下的最优解先说一个最常见的认知误区很多人把部署方式理解成一个从简单到复杂的升级路径先调 API然后本地单卡最后多卡集群。实际上这三条路是并行的对应的是完全不同的业务约束。官方 API 路线本质上是在买时间。你不需要准备任何显卡不需要装 CUDA 驱动也不需要维护推理引擎注册完拿 key 就能发请求。代价也很明显数据要经过第三方服务延迟上限不可控成本会随着调用量线性上涨。它最适合的场景是技术验证、产品原型、低并发的内部工具以及你还不确定模型效果到底行不行的时候。本地部署的意义则在于把数据流和控制权全部拿回自己手里。权重放在自己的机器上请求不出内网延迟和并发由自己的硬件决定单次调用成本会随着吞吐量增加被摊薄。这种情况下面临的真正问题变成了我手上到底有什么硬件怎么用最省事的方式把模型跑起来。于是就有了单机异构和多卡生产这两条路之间的选择。单机异构处理的典型情况是机器上有不同型号的显卡A100、4090 混插没有统一的高速互联。这种环境的本质问题是资源碎片化你需要先决定是让它们协同服务一个大模型还是各自独立服务多个小实例。多卡生产则是更规范的场景比如一台 8 卡 A100 80G 的机器专门跑 GLM-5.3-Flash目标是高吞吐、低延迟、稳如老狗。它要解决的核心问题不是能不能跑而是能不能抗住真实业务流量。1.2 三个判断信号帮你快速选型实际做技术方案的时候我一般不会一上来就聊架构而是先问三个问题并发多大、数据能不能出内网、预算怎么算。把这三个问题理清楚路线基本就浮出水面了。如果日均请求量只有几百到几千峰值并发不超过 10且你只是内部体验或者做 demo直接走官方 API 是最省力的。哪怕一个月花几百块也远比自己买卡划算。这个阶段最大的成本是你的时间不是 API 账单。如果请求量上来了或者数据有合规要求必须留在内网那就得考虑自建。先看单卡能不能装下模型能装下就单卡跑单卡装不下就考虑多卡并行。这里最容易踩的坑是一上来就奔着 8 卡去做张量并行实际上如果模型权重在 60G 以下一张 A100 80G 或者两张 4090 就足够应付中小规模流量了没必要为了“看起来很专业”把架构搞复杂。第三个信号是 SLA。如果业务方告诉你 P99 延迟不能超过 3 秒或者失败率必须低于 0.1%这就不是单纯“能跑”的问题了。你需要做容量规划、负载均衡、健康检查、滚动升级甚至要考虑推理引擎的连续批处理参数调优。这些工作只有多卡生产部署才能承载。1.3 GLM-5.3-Flash 这个模型部署前必须想清楚的三件事第一件事是上下文长度。很多人看到新闻说支持超长上下文就兴奋直接把请求 context 拉到几十万 token。但上下文长度和显存占用几乎是线性关系KV cache 会以肉眼可见的速度吃显存。你要先确认自己拿到的模型权重是哪个变体部署时是否能在模型配置里限制默认最大长度而不是傻乎乎地按最大支持值去分配显存。第二件事是 thinking_budget 这类参数。GLM 系列带思考模式以后推理请求里可能会有 thinking 预算的概念。如果你在网关层或者 API 层把参数的默认值处理错了比如透传了一个 0 或者负整数服务端会直接报参数校验错误。部署时要把这类参数单独列出来做配置项而不是硬编码在客户端代码里。第三件事是模型名。这个坑在接第三方平台时特别明显官方 API 平台、本地 vLLM 服务、ccswitch 这类模型网关各自看到的模型名可能不一样。本地推理服务用 --served-model-name 指定网关层做 model mapping如果不一致就会出现“模型不存在”这类奇怪的报错。后面我会专门讲怎么统一。2. 基础环境准备显卡、驱动、容器化一条龙2.1 硬件基线与显存估算的土办法不管走哪条部署路线只要自建硬件就是绕不开的话题。先说生产推荐单机 8 卡 A100 80G这是目前跑 GLM-5.3-Flash 这类中大体量模型最稳的组合。如果预算有限4 卡 A100 80G 也能起步无非是把并发和上下文空间压低一点。异构场景我后面单独开一章讲这里先给一个通用显存估算逻辑。模型权重用的格式如果是 BF16那每 10 亿参数大约占用 2GB 显存。你可以用这个公式先估算权重占多大再留出 KV cache 的空间。KV cache 的大小取决于并发请求数、上下文长度和模型层数精确算比较复杂但实操时有个土办法先用默认配置启动服务看 vLLM 或者 SGLang 启动日志里打印的 KV cache size再根据剩余显存反向调整最大并发数和上下文长度。这样比你对着公式手算靠谱得多。另外千万不要忽略 CPU 内存和共享内存的配置。模型加载、tokenizer 词表、中间激活都可能落在 CPU 侧。跑多卡并行时Docker 容器默认的 /dev/shm 只有 64MBPyTorch 的分布式通信一上来就可能报共享内存不足启动容器时直接加 --shm-size 32g 是省心做法。2.2 驱动和 CUDA 的版本基线怎么定自建推理环境这件事硬件到位后第一个拦路虎就是驱动。我的建议很简单显存比较老的机器驱动先升到 550 或更高版本CUDA 环境尽量别直接在宿主机上折腾直接走 Docker。NVIDIA 官方镜像和主流推理引擎镜像都会自带匹配的 CUDA runtime宿主机只要装好显卡驱动和 nvidia-container-toolkit 就够了。宿主机上先跑一下 nvidia-smi 确认驱动和 GPU 都被识别。驱动能识别之后再确认容器能把 GPU 透传进去。如果你的机器上已经能跑起来一个常见的 GPU 容器说明环境基本没问题不用在 CUDA 版本上浪费时间。很多部署失败其实不是镜像里缺东西而是宿主机没装 nvidia-container-toolkit导致 Docker 根本看不到显卡。2.3 用 Docker 把环境一次锁死生产环境最忌讳在每个机器上手工装一堆 Python 包版本漂移能把人逼疯。我建议从一开始就用 Docker 固化推理环境。vLLM 官方镜像或者 SGLang 镜像里已经预装了编译好的 CUDA 依赖和推理引擎直接拉下来用比自己从头编译省半天时间。一个可以直接套用的启动模板长这样docker run -d --name glm-flash-prod \ --gpus all \ --shm-size 32g \ --ipchost \ -v /data/models:/models \ -v /data/cache:/root/.cache \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/glm-5.3-flash \ --served-model-name glm-5.3-flash \ --host 0.0.0.0 \ --port 8000这里有几个细节值得注意。--ipchost 或者大的 --shm-size 是多卡并行必需的否则 NCCL 通信会在共享内存上出问题。挂载 /root/.cache 是为了让 Hugging Face 的缓存文件复用避免每次启动都重新下载。模型权重文件放在宿主机 /data/models 下通过挂载方式进容器这样升级镜像时权重不用重新拷贝。3. API 接入篇最快半小时把服务跑起来3.1 官方 API 与自建 API 的合理分工如果只是验证 GLM-5.3-Flash 在你业务场景里的效果我建议直接先申请官方 API 跑几天。这个阶段主要验证的是模型能力而不是部署能力。你不用管并发参数不用调显存拿一个 key 就开干。等验证完了判断要不要自建核心看两件事成本和数据。成本上你可以统计一下高峰期每分钟请求数、平均输入输出 token 数用官方价格算一笔月度账单。如果月账单能买一张显卡并且你本身有运维能力自建是划算的。数据上凡是不允许出内网的业务别犹豫直接自建。自建服务对外暴露的接口建议直接做成 OpenAI 兼容格式。这样业务代码不用绑死某个厂商的 SDK后面想换模型或者接 Dify、ccswitch 这类平台都会很省事。目前主流推理引擎对 OpenAI 兼容格式的支持已经非常成熟vLLM 一行参数就能起一个兼容服务。3.2 用 vLLM 拉起一个 OpenAI 兼容服务环境准备好之后我习惯用最小的参数先把服务拉起来验证模型权重没问题再逐步加生产参数。最小化启动命令长这样export MODEL_DIR/data/models/glm-5.3-flash export SERVED_MODEL_NAMEglm-5.3-flash vllm serve $MODEL_DIR \ --served-model-name $SERVED_MODEL_NAME \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 131072 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 64 \ --enforce-eager逐行解释一下这些参数的用途。--max-model-len 是最大上下文长度这里我给了 131072也就是 128K。如果你要测试超长上下文可以调大但一定要先确认显存扛得住。--gpu-memory-utilization 表示允许推理引擎使用多大比例的显存0.9 是比较保守稳健的起步值。--max-num-seqs 控制并发序列数也就是同时处理多少个请求值越大吞吐越高但单个请求的等待时间会变长。--enforce-eager 是关闭 CUDA graph 加速首次跑通时建议加上能避免很多启动阶段的花式报错等验证稳定后再去掉。启动日志里出现“Starting vLLM server”并且没有报错服务就算起来了。我实测下来模型权重如果是放在本地 SSD 或内存盘里加载阶段通常几分钟内能完成。3.3 用 curl 和 Python 快速验证接口服务起来后先用 curl 打一个最简单的请求确认链路通不通curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: glm-5.3-flash, messages: [ {role: user, content: 用一句话介绍你自己} ], max_tokens: 256 }如果返回内容是一段正常的 JSON说明服务和模型都没问题。接下来再用 Python 客户端验证参数传递特别是 thinking_budget 这种特殊参数在 OpenAI SDK 里怎么走from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, ) resp client.chat.completions.create( modelglm-5.3-flash, messages[{role: user, content: 帮我写一段部署脚本}], max_tokens1024, extra_body{ thinking_budget: 4096 } ) print(resp.choices[0].message.content)注意 thinking_budget 这类非标准参数OpenAI SDK 不会识别所以要放到 extra_body 里透传。如果你用的是原生 HTTP 请求直接把它加进 JSON body 即可。不同的推理引擎对这类参数的处理方式可能有差异实测为准。3.4 接入 Dify、ccswitch 时先统一模型名服务本身没问题之后接平台就是最后一公里。很多团队内部会用 Dify 搭知识库应用用 ccswitch 或者类似网关统一管理多模型路由。这类平台配置 GLM-5.3-Flash 时最常见的报错是“模型不存在”或者“The supported API model names are ...”十有八九是模型名对不上。Dify 的接入方式在模型供应商里选择 OpenAI-API-compatible填两个关键信息Base URL 填 http://你的服务地址:8000/v1模型名填 glm-5.3-flash。记得把 API Key 随便填一个非空字符串有些平台不允许 key 为空。ccswitch 这类网关配置时通常需要两步先定义一个模型供应商指向你的 vLLM 服务再做一个模型映射把平台侧的模型别名映射到你服务实际的 served-model-name。我的习惯是全程统一用一个名字比如 glm-5.3-flash从 vLLM 启动参数到网关映射再到业务请求体全部保持一致。这样能省掉 80% 的模型名排查时间。4. 单机异构部署混插显卡别硬上张量并行4.1 异构环境下最容易翻车的点是通信单机异构指的是同一台机器上插了不同型号甚至不同代的显卡。比如我见过不少团队既有几张 A100又有几张 4090全插在一台工作站里。直觉上你会觉得显存加一起不少可以合力跑一个大模型。但实际做起来性能和稳定性很容易被通信拖垮。原因在于张量并行会把一个层的计算切到多张卡上每算一步都需要卡间同步。如果显卡之间有 NVLink 或者 NVSwitch同步速度很快如果只是走 PCIe甚至某些卡之间 PCIe 带宽还被 CPU 拓扑切成两半通信开销会卡死整个推理过程。更麻烦的是不同型号的算力和显存带宽不匹配快的卡算完要等慢的卡综合吞吐反而不如用单张最快的卡。所以在异构环境里我踩过最大的一个坑就是强行给所有显卡做 tensor parallel。看起来显存管够实际吞吐低得可怜而且偶尔还会因为某个卡驱动状态不稳定导致整个服务崩掉。后来我把策略改成分组独立部署效果立刻好了很多。4.2 先看拓扑再决定并行策略拿到一台异构机器第一步不是急着配环境而是看卡间拓扑nvidia-smi topo -m输出会显示每张卡之间的连接方式是 NVLink、PCIe 还是需要通过 CPU 中转。你要关注的是哪些卡之间是高速互联哪些卡之间其实隔着 CPU。比如一张 A100 80G 和两张 4090 在一台机器上如果拓扑显示 4090 之间是 PCIe P2P而 A100 在另一个 CPU 的 PCIe 域里那么最合理的方案是分成两个独立实例A100 独自分一组跑一个服务两张 4090 一组通过 tensor-parallel-size 2 跑另一个服务两组之间用 nginx 做负载均衡。这样每组内部通信都是同型号卡通信节奏一致整体稳定性会好很多。4.3 显存不够时的异构应用大卡小卡各司其职异构不只是为了并行更实际的做法是让不同规格的卡承担不同任务。比如模型比较大一张 4090 放不下全部权重和 KV cache但一张 A100 80G 能放下就可以只在 A100 上跑高优在线推理4090 专门跑量化版模型、批量离线任务或者测试环境。如果模型大到连 A100 单卡都装不下必须跨卡跑我的建议是先按卡的显存分成两个组每组内部尽量是同型号然后通过 tensor parallel 把模型切开。例如 2 张 A100 组 TP2同时把 4 张 4090 组 TP4两组各自启动独立实例。GLM-5.3-Flash 如果单卡能放下一份完整权重我甚至不建议做任何并行一个实例用大显存卡另一个实例用小显存卡业务方自行决定路由到哪个服务逻辑最简单故障域也最小。启动组内并行时关键是用 CUDA_VISIBLE_DEVICES 限定进程可见的 GPU 编号。比如在一台 6 卡机器上如果编号 0、1 是 A1002、3、4、5 是 4090那启动两组服务的命令大致是CUDA_VISIBLE_DEVICES0,1 vllm serve /models/glm-5.3-flash \ --served-model-name glm-5.3-flash-a100 \ --tensor-parallel-size 2 \ --port 8001 CUDA_VISIBLE_DEVICES2,3,4,5 vllm serve /models/glm-5.3-flash \ --served-model-name glm-5.3-flash-4090 \ --tensor-parallel-size 4 \ --port 8002这里我给两个服务起了不同的 served-model-name方便在前面加负载均衡时根据模型名转发到不同后端。4.4 异构部署的显存与性能预期异构环境里要接受一个现实整体性能通常低于同规格卡的均值。你不能期待 2 张 A100 加 4 张 4090 的组合跑出 6 张 A100 的效果。4090 的显存带宽和 A100 不是一个量级PCIe 的通信带宽更是瓶颈。实际测下来跨 PCIe 做张量并行时TP2 甚至 TP1 但请求排队比强行 TP 把显存聚合起来要快得多。另外4090 这类消费级卡在 vLLM 里跑长上下文时会比较吃力。KV cache 增长速度远超 A100显存很快就满。如果你主要是测长文档理解建议长上下文请求都路由到 A100 组4090 组负责短对话和批量跑分。这样分工会让异构机器发挥最大价值。5. 多卡生产服务8 卡 A100 单机怎么扛住真实流量5.1 先给生产架构画个轮廓多卡生产和前面两类场景最大的区别是它要保证的是长时间、高并发、低故障率的服务不是跑通一个接口就行。一台标配的 8 卡 A100 单机内部结构其实可以分为三层推理引擎实例负责模型计算和并发调度网关层负责请求分发和流量控制监控层负责探活和指标采集。在 8 卡机器上最常用的组网方式是张量并行度设为 8也就是一个模型实例横跨全部 8 张卡。这种模式的显存总量大、单实例吞吐高模型权重不用切得很碎。如果单实例 TP8 的并发能力不够可以在同一批卡上起两个 TP4 的实例每个实例各用 4 张卡前面加负载均衡分摊流量。两种方案没有绝对优劣取决于你的请求长度和并发模型。长上下文多、显存吃力就选 TP8短请求密集、追求吞吐就选双 TP4。5.2 显存规划要像算账一样算清楚生产环境部署前我习惯做一个显存预算表免得启动后才发现爆显存。模型权重占用可以用模型文件总大小粗略估算比如 BF16 格式下权重目录总大小约等于加载后的显存占用。KV cache 部分则取决于你想支持多大的并发和上下文。假设 8 卡 A100 总显存 640G。如果模型权重占 200G你至少还要留几十 G 给中间激活和 CUDA context那 KV cache 可用的空间大概在 350G 左右。这个空间能缓存多少 token取决于每 token 的 KV cache 大小。不同层数、不同注意力头数的模型差异很大但 vLLM 启动时会自动计算并打印出来。我建议第一次启动时先用小一点的 --max-model-len 和 --max-num-seqs让服务正常起来看日志里的 KV cache 数字再逐步调大。这里有个技巧--gpu-memory-utilization 不要一上来就拉到 0.99。虽然 vLLM 会预留一部分但太激进容易在极端流量下触发显存抖动。生产环境我一般设在 0.92 到 0.95 之间留一点安全余量给 CUDA context 和临时显存分配。5.3 一条完整的 8 卡生产启动命令我当前在用的生产启动参数大概是这样的vllm serve /data/models/glm-5.3-flash \ --served-model-name glm-5.3-flash \ --tensor-parallel-size 8 \ --max-model-len 131072 \ --max-num-seqs 256 \ --gpu-memory-utilization 0.92 \ --swap-space 16 \ --trust-remote-code \ --host 0.0.0.0 \ --port 8000--max-num-seqs 256 意味着推理引擎最多同时处理 256 个请求序列。请求超过这个数会排队不会直接失败。--swap-space 是允许用 CPU 内存做显存溢出交换的空间单位是 GB。这个值不要设太大因为 CPU 交换会显著增加延迟生产中我更倾向于把并发限制在显存能容纳的范围内而不是依赖 swap。如果你想追求更低延迟的流式输出建议把 --max-num-seqs 调低一些比如 128这样每个请求能分到更多的 KV cache 空间连续批处理也会更从容。到底该设多少建议压测后再定不要拍脑袋抄参数。5.4 网关层、健康检查与滚动升级的坑生产服务不能把 vLLM 的端口直接暴露给业务方中间要有一层网关。最简单的做法是 nginx 反代再加上一层基于 /health 接口的探活。vLLM 默认提供 /health 端点服务就绪后返回 200网关层可以定时探测发现异常就把流量切走。滚动升级是另一个容易忽略的点。很多人升级模型权重或者推理引擎版本时直接 docker restart导致正在处理的请求被硬杀。正确的做法是先在网关层把该节点的流量摘掉等正在处理的请求跑完然后再重启服务最后重新挂载流量。vLLM 在收到 SIGTERM 后是否支持优雅退出取决于版本我用的时候会在网关层做摘流而不是依赖推理引擎内部的优雅关闭这样最可控。监控指标方面vLLM 暴露了 Prometheus 格式的 /metrics 端点。重点盯这几个指标正在排队的请求数、每个请求的平均生成 token 数、端到端延迟 P99、首 token 延迟。这些指标共同决定了你的容量上限。有一次我压测时发现 QPS 上不去但 GPU 利用率也不高后来通过指标发现是 max-num-seqs 太小请求全在排队GPU 一直在等数据。把并发数调大之后吞吐直接翻倍。5.5 压测驱动的容量规划压测不是为了测出好看的数字而是为了找到服务在什么并发下开始变慢。我的做法是用一个简单的并发脚本向服务发送固定 token 数量的请求不断增大并发数记录每一档的 P99 延迟和吞吐。有一个重要经验最大并发不等于最佳并发。当请求排队时间超过模型实际生成时间时P99 延迟会急剧上升而你牺牲了每个请求的体验换来的吞吐增益却很小。容量规划的目标是在延迟预算内找到允许排队的最大并发数。对大多数对话场景P99 在 3 秒以内是可接受的如果超出就把并发限制往下调或者通过网关限流。8 卡 A100 的 GLM-5.3-Flash 到底能扛多少 QPS这个问题我没法给一个通用数字因为它和输入长度、输出长度、batch 策略强相关。有人说自己压测到了单实例几百 QPS但那是短输入短输出、批量友好型请求。如果你的请求平均输入 2000 token、输出 500 token实际 QPS 会低很多。所以别信网上晒的参数自己去压。6. 实战中踩过的坑与排查记录6.1 常见报错速查表整理一张排障速查表方便大家直接对号入座现象根因处理方式请求返回 model 不存在served-model-name 与请求体里的 model 不一致统一模型名或检查网关 mapping启动时 CUDA OOM模型权重加 KV cache 预估超过显存调低 gpu-memory-utilization 或 max-model-lenRuntimeError: NCCL error多卡通信异常检查卡间拓扑、驱动、--shm-sizeDocker 无法访问 GPU宿主机缺 nvidia-container-toolkit安装 toolkit 并重启 docker400 thinking_budget must be a positive integer透传了 0 或负数不传该参数或传正整数上下文长度超过最大值请求 token 数超 max-model-len调大 max-model-len 或限制输入长度启动后首个请求极慢CUDA graph 未预热或模型权重在冷盘预热请求或把权重放到 SSD速查表只能解决 80% 的已知问题剩下 20% 需要结合日志现场推理。6.2 一个让我印象深刻的异构案例复盘去年帮一个团队优化 GLM-5.3-Flash 部署机器是 4 张 A100 和 2 张 4090 混插。最初的方案是把 6 张卡全拉通tensor-parallel-size 6 启动负载一上来就发现生成速度还不如单张 A100。用 nvidia-smi topo -m 一看4090 和 A100 之间根本没有高速互联所有跨卡通信走 PCIe switch通信等待直接把算力全拖死了。后来我把方案改成两个独立实例4 张 A100 做 TP4 跑在线主服务2 张 4090 做成 TP2 跑离线批量任务。在线服务延迟立刻恢复正常离线任务也在慢慢跑互不干扰。这个案例给我最大的教训是并行度不是越大越好通信拓扑决定了并行度的上限异构机器尤其如此。6.3 超长上下文与思考模式参数的调参心得GLM-5.3-Flash 的宣传卖点是长上下文和思考能力但真用在生产里这两块都需要单独对待。超长上下文最直接的影响是 KV cache 以接近线性的速度膨胀。如果一个请求要读 500K token 的文档而你又把 max-num-seqs 设得很大显存瞬间就会被打满甚至影响同实例的其他请求。我的建议是不要用一个服务承接所有长度的请求。把在线对话服务和长文档处理服务拆开在线对话用 32K 或 64K 上限、高并发参数长文档服务单独一个实例max-model-len 调到最大但并发数压得很低。这样两个场景都不会因为对方的流量特征而互相拖累。思考模式参数也要在接入前就跟业务对齐。thinking_budget 的含义和取值是看官方文档确认的但不同网关层可能会做参数白名单额外字段会被丢弃。如果你发现请求没有触发思考行为先检查是不是网关层已经把 extra_body 里的字段吞掉了。这类问题日志里不会报错只能靠抓包和网关侧排查才能定位。6.4 几个防呆设计建议踩坑踩多了我习惯在部署一开始就加入一些防呆设计。第一所有服务必须支持健康检查接口并且这个接口不能被业务流量影响。第二模型名和权重路径统一用环境变量注入不要直接写在启动脚本里不然不同环境切换时很容易改漏。第三跑批任务一定要加上超时和失败重试机制。LLM 推理服务和普通 HTTP 服务不同单个请求可能持续几十秒甚至几分钟网关层的超时时间要单独设计不能用默认的 30 秒。最后再说一个不算技巧的技巧每次部署新版本别急着切全量流量。先在一个实例上加载新权重用一套固定的回归用例跑一遍比如数学题、代码生成、长文档摘要各来几条确认输出质量符合预期再切流量。这个习惯帮我拦住过至少三次权重文件传错导致的线上事故。说到权重文件传错我个人的习惯是每次部署前先记录权重文件的 SHA256 校验值而不是只看文件名。文件名和实际内容不一致的情况在多人协作的团队里太常见了。你花一晚上排查出来的“推理结果变差”最后可能只是有人把旧权重覆盖到了线上目录。这听起来很蠢但确实是生产环境里最高频的事故来源之一。