直接设--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观察内存增长趋势，再微调
最容易被忽略的验证动作
配完不验证等于没配。三个必做检查：
立即学习“Python免费学习笔记（深入）”；
- 启动后立刻执行
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% 的“性能问题”其实源于没看清自己到底在跑什么类型的代码。
