asyncio 服务 CPU 密集任务丢线程池：队列排队把 P99 顶到 800ms，怎么定池大小与隔离策略

【背景】 我做了 8 年性能优化，最近在帮一个团队复盘一个 Python 3.11 的推荐服务：FastAPI + asyncio，入口 QPS 约 3000，单机 8C16G。核心链路是「读特征 → 打分（一次约 3~6ms 的 CPU 密集计算）→ 拼响应」。打分这一步最初写在 event loop 里，后来抽到 loop.run_in_executor，用的是默认 ThreadPoolExecutor（max_workers = min(32, cpu+4) = 12）。

【现象】

• 低峰（QPS < 800）：P50 ≈ 15ms，P99 ≈ 40ms，很健康。
• 高峰（QPS ≈ 3000）：P50 涨到 60ms 还可以接受，但 P99 间歇性飙到 800ms~1.2s，且伴随 event loop lag 监控（用 loop.time() 前后打点）出现 200ms+ 的尖刺。
• 关键诡异点：CPU 使用率只有 55% 左右，没有打满，说明不是算力不够，而是「排队」——线程池的 work queue 堆了 200+ 个任务，每个任务等 20~50ms 才轮到。

【已尝试的排查与结果】

1. 把 max_workers 从 12 调到 32、64：P99 没有改善，反而更抖。我猜是 Python GIL 让 64 个线程里真正并行跑 CPU 的也就 1 个左右，其余全在排队 + 上下文切换，等于把单核排队问题放大成 64 路排队。
2. 把打分逻辑从「每个请求算一次」改成「同 batch 请求共享结果」（加 LRU cache，命中率约 35%）：P99 从 800ms 降到 ~400ms，方向对了但没解决根因。
3. 考虑过把打分进程化（multiprocessing / 独立打分 worker 进程池，通过 queue 通信），但团队担心引入 IPC 开销和新的背压问题，没敢上。

【期望得到的答案形态】 想请教有真实线上 asyncio + CPU 密集混合负载经验的同行：

1. 你们的线程池（或进程池）max_workers 到底按什么公式定？是核数、核数 × 1.5、还是完全看压测？有没有可复现的定参方法（比如用 asyncio 的 loop lag 指标反推）？
2. CPU 密集任务在 asyncio 里的「正确姿势」是什么——线程池、进程池、还是干脆拆成独立打分服务？各自的适用边界在哪？
3. event loop lag 监控怎么落地？你们用什么工具/指标，阈值怎么设，告警怎么和 P99 关联起来？
4. 有没有「CPU 密集任务 + I/O 密集任务」混跑时的隔离策略经验（比如按任务类型分 pool、按优先级分队列）？

我倾向于最终方案是「打分独立成进程池 + 按优先级分队列」，但想听听大家踩过的坑，避免我重蹈覆辙。