第四章 实战案例：压测、灰度与生产化

第四章 实战案例：压测、灰度与生产化

导读：原理讲完，回到真实世界。一个推理服务「能跑」离「敢接生产流量」还差三件事：你不知道它扛不扛得住（压测）、你不敢一次性全量（灰度）、你不知道它什么时候快挂了（可观测与调优）。这一章用两个完整案例把这三件事串起来：4.1 用压测找到你的真实吞吐上限；4.2 把服务做成可灰度、可监控、可回滚的生产形态。读完你应能交付一份「上线 checklist」。

4.1 压测：找到你的真实吞吐与延迟上限

不上压测就全量，等于蒙眼开车。压测目标不是「跑个分数」，而是回答三个业务问题：单副本能扛多少并发？P99 延迟到多少？显存什么时候爆？

工具上，可复用 vLLM 自带的基准脚本，或简单的并发 curl / Python 客户端循环。关键不是工具，是 压测姿势：

• 渐进加压：从 1 并发开始，逐步加到 8、16、32……每档跑够时间，记录吞吐（tokens/s）和延迟分布。你会看到一个拐点——并发再高，吞吐不涨了但延迟飙升，那就是单副本天花板。
• 贴近真实负载：用接近生产的 prompt 长度与生成长度。只测「短问短答」会严重高估能力；GLM-5.2 常用于长上下文，务必带长输入压测。
• 同时盯显存：压测时开 nvidia-smi -l 1 或 DCGM Exporter，确认峰值显存是否触顶。很多 OOM 不在「起服务」时发生，而在「高并发 + 长上下文」叠加时发生。

拿到数据后做一张表：并发数 / 吞吐 / P50 延迟 / P99 延迟 / 峰值显存。这张表就是后面定副本数、设 HPA 阈值的依据——一切容量规划都该来自这张表，而不是拍脑袋。例如若单副本在 16 并发时 P99 已到 2s 且显存 95%，那你至少要多副本才能接 50 并发的业务。

4.2 灰度、监控与回滚：让服务「可交付」

压测过了，下一步是「敢上线」。核心三件套：

灰度（金丝雀）：别一次性把 100% 流量切到新版本。用 Ingress 或网关把 5%–10% 流量导到新副本，观察错误率、延迟、显存是否异常，再逐步放大到 50%、100%。出问题立刻把权重调回旧版本。K8s 里可以靠两个 Deployment（v1 / v2）+ Service 权重或网关路由实现。

监控：至少盯四类指标——（1）业务指标：QPS、成功率、P99 延迟；（2）GPU 指标：利用率、显存占用、温度（DCGM Exporter + Prometheus）；（3）队列指标：vLLM 内部等待队列长度，它是「该扩容了」的最早信号；（4）资源事件：Pod 重启、OOMKilled。没有监控的上线等于盲飞。

回滚：K8s 的 kubectl rollout undo 能在秒级回退 Deployment。前提是 新版本出问题能被监控捕获、且旧版本镜像仍在仓库。务必演练一次回滚，确认链路通畅——很多人第一次回滚才发现旧镜像被清了，欲哭无泪。

把这三件做实，你的 GLM-5.2 服务就不再是「实验室玩具」，而是能写进上线报告的「生产系统」。容量、灰度、监控三者闭环，才是本章要交付的终局能力。

本章小结

• 压测要渐进加压 + 贴近真实负载 + 同步盯显存，输出「并发/吞吐/延迟/显存」四联表。
• 容量规划全部源自压测表，不拍脑袋。
• 上线三件套：金丝雀灰度、四类监控（业务/GPU/队列/事件）、可演练的回滚。