一、高并发推理系统概述：定义、挑战与核心指标
各位同学，咱们今天聊聊高并发推理系统。说实话，这个领域我摸爬滚打了五六年，踩过的坑比走过的路还多。先别急着看代码，咱们先把概念理清楚。
1.1 到底什么是高并发推理系统？
说白了，就是一台或多台机器，同时接待成千上万个用户发来的推理请求。每个请求都希望模型能快速给出答案。比如你打开一个AI聊天助手，背后就是这样的系统在支撑。
我个人习惯把这类系统拆成三个层面看：
- 推理引擎层：负责加载模型、执行前向计算。这是核心，也是瓶颈所在。
- 调度与排队层：管理请求的到达顺序、优先级、超时策略。我见过不少系统在这层翻车。
- 资源管理层：分配GPU、CPU、内存。说白了就是钱的问题——怎么用最少的卡，扛最多的请求。
核心定义：高并发推理系统 = 在有限硬件资源下，同时处理大量推理请求，并保证延迟可接受、吞吐量达标的工程系统。
1.2 为什么它这么难搞？
你想想看，传统Web服务扛高并发，加机器就行。但推理系统不一样——每个请求都要过一遍模型计算，GPU显存就那么大，算力就那么多。
我遇到过最头疼的场景：某次线上大促，流量突然暴涨3倍。模型推理延迟从50ms飙到800ms，用户直接超时。查了半天，发现是请求排队把显存打爆了。嗯，这就是典型的「并发与资源」矛盾。
主要挑战我总结为四点：
- 显存墙：模型参数动辄几十GB，一张A100才80GB显存。并发一高，显存先撑不住。
- 计算墙：Transformer的注意力计算是O(n²)复杂度。序列越长，计算越慢。
- 调度墙：请求长短不一，有的问「你好」，有的上传整篇论文。怎么调度才能公平又高效？
- 成本墙：GPU贵啊。我见过一家公司为了压延迟，给每个请求单独分配一张卡——结果成本直接爆炸。
避坑指南：我曾经以为只要模型够快，并发不是问题。结果被现实狠狠教育了一顿——推理系统的瓶颈往往不在模型计算本身，而在数据搬运和显存分配。设计时一定要先画资源流图。
1.3 三个核心指标：QPS、延迟、吞吐量
做系统设计，没有指标就是瞎搞。这三个指标是铁三角，缺一不可。
| 指标 | 定义 | 单位 | 我的经验值 |
|---|---|---|---|
| QPS（每秒查询数） | 系统每秒能处理的请求数量 | req/s | 线上一般要求单卡100-500 QPS（视模型大小） |
| 延迟（Latency） | 单个请求从发起到返回的时间 | ms | 对话场景通常要求P99 < 200ms |
| 吞吐量（Throughput） | 单位时间内系统处理的总数据量 | tokens/s 或 MB/s | 生成式模型常用tokens/s衡量 |
这里有个关键点：QPS和延迟是矛盾的。你想想看，并发高了，请求排队，延迟自然就上去了。我习惯用Little定律来估算：并发数 = QPS × 平均延迟。如果延迟100ms，要扛1000 QPS，那系统里同时处理的请求就得有100个。显存够吗？
小技巧：我一般先定延迟目标（比如P99 < 150ms），再反推QPS上限。别一上来就追求高QPS，延迟崩了用户全跑了。
1.4 指标之间的关系——一张图说清楚
下面这张图是我自己总结的「铁三角」关系。你看一眼就明白了。
1.5 实际项目中怎么定指标？
我一般按这个步骤来：
- 先定延迟SLA：跟产品经理聊，用户能接受多慢？对话场景一般P99 < 200ms，离线批处理可以放宽到秒级。
- 再算QPS目标：根据DAU和用户行为预估。比如100万DAU，每人每天发10次请求，集中在2小时内，那峰值QPS大概在
100万×10÷7200≈1389。 - 最后算吞吐量：结合模型输出长度。比如每个请求平均输出200 tokens，那吞吐量就是
1389×200≈278K tokens/s。 - 反推硬件需求：一张A100跑LLaMA-13B，实测吞吐量约5000 tokens/s。那需要
278000÷5000≈56张卡。嗯，成本就出来了。
经验之谈：我建议你留30%的余量。线上流量从来不会按你预估的来。我曾经把余量留了20%，结果被双十一流量直接打穿。从那以后，我都是按「预估峰值×1.5」来规划资源。
1.6 本章小结
好，咱们捋一下今天的内容：
- 高并发推理系统 = 资源受限下的高效推理服务
- 四大挑战：显存墙、计算墙、调度墙、成本墙
- 三个核心指标：QPS、延迟、吞吐量，它们互相制约
- 定指标的顺序：延迟 → QPS → 吞吐量 → 硬件