直接设--workers 2×CPU核心数+1常翻车，因该公式忽略负载类型、GIL限制、Uvicorn进程隔离及模型加载开销；实际需按硬件资源（容器cgroups限核、GPU显存）与业务类型（CPU/I/O/混合型）双维度确定，8核下推荐值分别为6～8、12～16、10，并必须通过ps、lsof和top验证生效。

为什么直接设 --workers 2 * CPU核心数 + 1 常常翻车

这个公式在文档里反复出现，但实际压测时经常发现：设了 17 个 worker，CPU 利用率卡在 40%，QPS 却没涨——不是配置漏了，是它根本没适配你的负载类型。Python 的 GIL、Uvicorn 的进程隔离、模型加载开销，三者叠加后，“多开几个进程”反而变成负优化。

--workers 数值必须按硬件和业务双维度定

别只看 nproc 输出的数字，先确认真实可用资源：

• 容器环境？查 cat /sys/fs/cgroup/cpu.max 或 docker inspect，cgroups 限核后设 8 个 worker 可能只跑得动 2 个
• 用 GPU 推理？RTX 4090（24GB 显存）加载一个 8GB 模型，--workers 3 就是极限，再多直接 OOM
• 全是 async/await 调用且无同步阻塞？单 worker 已能扛几千 QPS，加进程纯属浪费内存和调度开销
• 代码里混了 time.sleep(1) 或 requests.get()？哪怕只有一处，就必须开多 worker，否则事件循环被锁死

不同负载类型的实际推荐值（以 8 核 CPU 为例）

这不是拍脑袋，而是从日志、htop 和压测曲线里反复验证过的起点：

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

• CPU 密集型（如图像预处理、特征向量化）：--workers 6～8。再高会因进程切换反拉低吞吐
• I/O 密集型（FastAPI 接口、数据库聚合查询）：--workers 12～16。注意观察 ps aux | grep uvicorn 是否真起了对应数量进程
• 混合型或不确定负载：--workers 10，上线后用 gunicorn --preload + --max-requests 1000 观察内存增长趋势，再微调

最容易被忽略的验证动作

配完不验证等于没配。三个必做检查：

• 启动后立刻执行 ps aux | grep -v grep | grep uvicorn | wc -l，输出数必须等于你设的 --workers 值。如果少于该数，大概率是 --worker-class uvicorn.workers.UvicornWorker 拼写错误或漏写
• 请求进来时，用 lsof -i :8000 看连接是否分散到多个 PID 上，否则说明 Gunicorn 没真正把连接分发出去
• 压测中盯住 top -p $(pgrep -f "gunicorn.*app:app" | head -n1)，主进程 CPU 应始终低于 5%，否则说明 worker 数超出了 Gunicorn 调度能力

Gunicorn 的 --workers 不是性能开关，是资源闸门——开太小堵死流量，开太大冲垮内存。真实生产里，80% 的“性能问题”其实源于没看清自己到底在跑什么类型的代码。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！