锺一勺做AI模型推理的服务化落地，我这些年踩过最多的坑，几乎都集中在一个词上：多线程。不是模型精度不够，不是网络带宽不够，往往就是线程模型设计不合理，导致一台高配机器只能跑个位数QPS，后端工程师和算法工程师互相看着干瞪眼。
去年接了一个OCR推理服务的性能调优任务，目标很直接：单线程QPS只有3，P95延迟约300ms，业务要求上线时至少扛住30 QPS。这个量级不算夸张，但调优过程中涉及的技术点非常典型——AI模型推理的调度流程、多线程并发模型设计、线程池参数调整、CPU绑核、队列优化、不同语言下的并发陷阱，几乎都被我撞了一遍。今天这篇就把整个调优方案完完整整复盘出来，希望给正在做AI应用开发、模型服务化或者准备多线程面试的朋友一些实际可落地的参考。
1. 先把问题盘清楚：为什么单线程推理服务扛不住
1.1 推理服务的性能模型与瓶颈在哪
先明确一个概念：模型推理服务并不等于“模型前向计算那一小段”。一个典型请求的完整路径是：网络收包、请求解码、图像或文本预处理、模型前向推理、后处理、结果序列化返回。在OCR服务里，预处理包括图像解码、缩放、归一化，后处理包括文本行解码、置信度过滤、坐标映射。这些步骤互相依赖，但处理的是不同数据和不同算力资源。
单线程模式下，所有请求只能一个接一个串行走完这条链路。假设单个请求端到端耗时300ms，那理论最大QPS只有1000/300约等于3.3，这和真实值3基本吻合。想提升吞吐，本质只有两条路：要么降低单请求耗时，比如上TensorRT、量化、模型剪枝；要么提高并发处理能力，让多个请求同时在不同阶段推进。我这次优化的重点在后一条，也就是多线程化。
瓶颈定位不能靠猜。当时我在单线程下用perf top和nvidia-smi分别观察CPU和GPU，结果很有意思：CPU使用率只有12%，GPU利用率更低，不到8%。这意味着单个请求处理期间，绝大多数计算资源都在闲着。真正的问题不是“硬件不够快”，而是“没有把多个请求塞进流水线里并行处理”。这一眼就确认了方向——多线程并发是当前最值得投入的优化点。
1.2 线程数不是拍脑袋定的：从Amdahl定律说起
不少同事一听多线程，第一反应是把线程数调大。但Amdahl定律早就告诉我们，并行加速有上限：加速比 = 1 / ((1 - P) + P / N)，其中P是可并行部分占比，N是线程数。假设一个推理请求里70%的操作可以并行，线程数从1提升到8，加速比也就大约3.1倍；继续加线程到16，加速比只有3.2倍，收益几乎停滞。如果并行比例只有50%，那更惨，8线程也只有1.6倍。
推理服务通常不是纯粹的CPU密集型或IO密集型，而是混合型。请求解码、结果序列化涉及IO和内存拷贝，模型前向计算是纯CPU或GPU计算，后处理可能既有计算又有字符串操作。粗略的经验公式“CPU密集型N+1、IO密集型2N+1”只能作为起点，不能直接拍板。我当时采用的做法更实际：在同一份压测脚本下，固定请求并发数，把线程池大小分别设为1、2、4、8、16、32，每档跑3分钟，记录QPS和P95延迟。这比任何理论公式都可靠，因为线程数这个变量最终要看真实系统的“拐点”落在哪。
还有一个容易被忽略的点：线程不是免费的。每个线程默认栈空间可能占8MB虚拟内存，线程切换涉及上下文保存恢复，竞争共享数据时还要付出锁等待和缓存失效成本。线程数量一旦超过某个阈值，收益变成负数，这在后面的实测数据里体现得非常明显。
1.3 目标指标：QPS、P95、CPU/GPU利用率一个都不能少
调优必须要有一组清晰可量化的指标，否则就是凭感觉乱撞。我在这类项目里固定看四个维度：
- QPS：每秒处理完成的请求数，反映系统整体吞吐能力。
- P95/P99延迟：从请求进入服务到返回结果的耗时，统计上比平均值更能暴露长尾问题。平均值好看但P99飙到1秒的情况，在推理服务里太常见了。
- CPU利用率：用
mpstat -P ALL 1或者top观察，判断瓶颈是在计算密集还是在等待锁。 - GPU利用率：
nvidia-smi -l 1持续观察，GPU是昂贵的稀缺资源，利用率低说明并发模型没有