消费队列的推理 worker 按 CPU 核数直接设成十六个，每个进程各加载一份 7B 模型，启动阶段显存就打满，服务只起来一半；压测发现吞吐比四个 worker 时还低，P99 从两百毫秒涨到四百八十毫秒。
一开始怀疑是「下游数据库连接池上限没跟着放大，请求排队等连接」，查了一圈，方向不对。
这类报错背后常见的原因有几处，逐个排除就行。每个 worker 各加载一份权重，显存和内存都在抢。也可能是并发超过实际可并行度，上下文切换开销压过收益。
还有一种情况，多个 worker 从同一队列预取，重复拉取同一条消息。
动手时先看队列积压与单条处理耗时
curl -s http://worker:9100/metrics | Select-String 'queue_depth|process_seconds'随后把 worker 数降到四再做同样的压测
python worker.py --workers 4 --concurrency 2再往下核对数据库连接池是否够用
psql -c "SELECT count(*) FROM pg_stat_activity WHERE datname='app';"末了对比两轮压测的吞吐与延迟
python bench_queue.py --workers 4 --duration 600 --report恢复的判定其实很直接。四个 worker 下吞吐不低于十六个时的水平，P99 从四百八十毫秒降到两百一十毫秒，显存占用始终在窗口内。
worker 数不是越多越快，模型服务里每个进程都要一份权重，扩之前先算显存和下游连接数。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。