flask自带app.run()严禁用于生产环境，因其单线程阻塞、无超时控制、无进程看护、无结构化日志；必须改用gunicorn等wsgi服务器，并配合nginx处理静态文件与tls终止。
直接用 flask run 启动模型接口，生产环境必崩——它单线程、无超时控制、不回收内存，2秒推理延迟下并发撑不过5个请求。
为什么 gunicorn app:app 启动后还是卡死？
最常见原因是没删掉代码里的 app.run()，导致实际运行的仍是 Flask 自带开发服务器。Gunicorn 会加载模块，但不会执行 if __name__ == '__main__': app.run(...) 块；可一旦这个块里有初始化逻辑（比如加载大模型），又没做保护，就可能阻塞 worker 启动。
- 必须注释或删除所有
app.run()调用，哪怕加了debug=False - 检查
app.py或入口文件顶部是否有耗时操作（如torch.load()、transformers.AutoModel.from_pretrained()）——这些应在 worker 初始化时做，而非模块导入时 - 启动时加
--log-level info，确认输出里出现类似Booting worker with pid: 1234，而不是只看到 Werkzeug 的启动日志
worker 数量设多少才不爆显存也不浪费 CPU？
对大模型接口，worker 数不是越多越好。GPU 显存和 Python 进程内存是硬瓶颈，盲目增加 workers 会导致 OOM 或显存不足报错（如 CUDA out of memory）。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- CPU 密集型 + GPU 推理：从
workers = 1开始试，再逐步加到 2 或 3；每多一个 worker 就多一份模型副本在显存中 - 纯 CPU 推理（如 ONNX Runtime）：可用
workers = multiprocessing.cpu_count() * 2 + 1，但需配合--max-requests 500防止内存缓慢增长 - 绝对不要用
gevent或eventlet：它们共享同一个 Python 解释器和 GIL，无法真正并行加载多个模型实例，反而因协程切换引入额外开销
timeout 和 max_requests 怎么配才防住长请求又不丢任务？
模型推理动辄几秒甚至几十秒，timeout=30（默认值）会直接 kill 正在跑的请求，返回 Worker timeout 错误，用户看到的是 502。
-
timeout应略大于最大预期推理耗时，比如最长 90 秒，则设timeout = 120；但别设成0（无限等待），否则失败 worker 永不重启 -
max_requests用于强制轮换 worker，缓解 CPython 内存碎片问题；大模型场景建议max_requests = 100~500，再配合max_requests_jitter = 20避免雪崩式重启 - 若用 GPU，务必加
preload = True（写在配置里），确保模型在 fork 前加载，避免每个 worker 重复 load 权重造成显存翻倍
gunicorn 配置文件里哪些项不能省？
命令行参数容易漏、难复现，生产环境必须用配置文件。以下几项是模型接口存活的关键：
-
bind = "0.0.0.0:5000"：显式绑定地址，别依赖默认127.0.0.1 -
workers = 2：明确指定，不靠默认值 -
timeout = 120：覆盖默认 30 秒 -
max_requests = 200和max_requests_jitter = 30 -
preload = True：GPU 场景救命项 -
accesslog和errorlog必须设路径，否则错误全丢进黑洞
最容易被忽略的是 preload 和日志路径权限——如果 logs/ 目录不存在或不可写，gunicorn 会静默失败，连 errorlog 都打不开。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
