这个坑值得记一笔。GPU 节点被调度占满，服务自动回退到 CPU 推理，7B 模型单请求要 8 秒，QPS 只有 3，监控告警但进程健康检查一直是绿的。
刚开始盯着「CPU 上没有做量化，仍按 fp16 计算」，折腾了半个多小时，排掉了。
这类报错背后常见的原因有几处，逐个排除就行。回退逻辑没有区分模型规模，直接切 CPU；健康检查只看端口存活不看推理延迟；并发上来后线程争抢，延迟进一步恶化。
量出 CPU 下单请求的耗时
python bench.py --device cpu --model Qwen2.5-1.5B-Instruct --n 5再往下换成 int8 或 gguf 量化版本再压测
python bench.py --device cpu --quant int8 --n 20接着把健康检查加上延迟阈值
curl -s http://127.0.0.1:8000/healthz?max_latency=2000限制 CPU 模式的并发并做排队
python serve.py --device cpu --max-concurrency 2当时还开着另一个排查窗口，两边日志对照着看才定位到。
怎么算真的好了，看的是同一批现象。CPU 模式下 QPS 至少到 8 且 P99 在 3 秒以内，超过阈值时健康检查转为不健康并触发扩容。
提醒一点。回退不能只看能否启动，要按延迟阈值判断可用性，否则服务活着但用户完全用不了。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。