AI推理并发场景设计方法

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

并发模型构建

老王的面馆要决定雇几个师傅，先得搞清楚“同一时刻有几个客人坐在店里等面”。小学放学时呼啦啦一群孩子冲进来，白领午休一拨一拨来，周末下午懒懒散散几个人。只统计“今天来了五百人”没意义——某个瞬间挤进六十人，三个灶台根本忙不过来。真正决定压力的是“同时在场”的人数。

AI 推理服务的并发模型构建，做的就是同样的事：把真实用户行为翻译成可模拟的并发请求。核心工具是利特尔定律（Little's Law）：平均在途请求数 = 请求到达率 × 平均响应时间。到达率就是“每秒进店几人”，响应时间相当于“每位客人从点单到吃完离店的平均时长”。

除了公式，构建并发模型还要定义用户画像：文本生成请求的输入输出 token 长度、图像请求的分辨率，这好比客人点大碗还是小碗；配置思考时间——真实用户看完菜单才下单，模拟器里需要在请求之间加间隔；还要考虑连接复用：长连接像熟客直接落座，短连接像每次重新找座位，反复建连会白白消耗服务端资源。

建好并发模型，老王才知道“高峰期同时二十人”是常态还是偶发，该留几张桌子。接下来他得看清这些客人是怎么一波波涌来的——这正是负载模式的分类。

负载模式分类

客流从来不是一条直线。清晨几位老客慢悠悠喝面汤，中午写字楼白领瞬间占满大堂，午后两点又冷清下来，偶尔一辆旅游大巴停在门口，几十人呼啦涌进来。不同的“人潮形状”对厨房的压力完全不同：同样一小时来两百人，匀速到来和十分钟挤完，前者师傅能从容应对，后者直接击穿堂食座位。

负载模式分类，就是把“人潮形状”归纳成几种标准曲线，压测时按需选用。四种最常用：稳态（恒定并发）、阶梯递增（每隔一段时间加一档）、突发尖峰（瞬间冲高）、波浪（周期性起落）。其中爬坡速度直接决定阶梯模式是否真实，用递增速率公式描述：

各模式各司其职：稳态适合长稳测试，连续跑几小时暴露内存泄漏和连接泄漏；阶梯递增用于找容量拐点——并发加到某档后吞吐不再上升；尖峰用于验证突发场景下系统是否超时雪崩；波浪用于观察自动伸缩能否跟上负载起伏。注意爬坡不能太快，否则系统预热不足会误报“崩了”。

老王根据星期几和节假日排不同的班表，压测同样要按业务日历选模式：大促前测尖峰，日常迭代测波浪，新版本上线前四种全跑一遍。

混合场景设计

面馆不是只卖一种面。菜单上有拉面、盖饭、小菜，有的客人还要加蛋加辣。如果演练时只模拟“客人不断点拉面”，师傅们流程再顺，也没法验证蒸饭、炸物、煮面同时开火的真实混乱。

AI 推理服务同样面对混合负载：文本生成吃算力，图像识别吃显存与 IO，语音转写吃带宽，向量检索吃内存。混合场景设计就是按真实业务占比把多种任务叠加到同一场压测里，同时覆盖数据分布——prompt 长度、图片分辨率都要贴近线上，否则测出来的是“实验室结论”。

设计混合场景要定三个要素：权重配比——从线上日志统计各任务占比；时段编排——白天对话多、夜间批处理多，按业务日历切分场景；切换节奏——避免所有任务同一秒爆发造成失真。最可信的做法是流量回放：录制一段线上真实流量，原样打到被测服务上，相当于把面馆一整天的真实点单记录重放一遍。

只有把“拉面、盖饭、小菜”按真实比例混合，压测结果才配得上“贴近生产”四个字。

性能指标监控

老王店门口挂了四块仪表：一小时出了多少碗面（吞吐量）、客人排队到上桌多久（时延）、灶台和师傅忙不忙（利用率）、有没有做糊或漏做的单（错误率）。这四块表必须一起看——光看“出餐多”可能师傅已经累到极限，下一分钟就崩溃。

AI 推理压测对应四个核心指标：吞吐量（QPS、每秒 token 数）、时延（P50/P95/P99）、GPU 与内存利用率、错误率（超时/5xx）。排队论用利用率描述系统忙闲：利用率 = 到达率 ÷ 服务率。

平均时延极具欺骗性：100 个请求里 99 个 10ms、1 个 5 秒，平均约 60ms，看起来不错，但那个等了 5 秒的用户早就流失了。所以必须看 P99——最慢 1% 请求的边界——以及吞吐量-时延曲线上的拐点。资源利用率与错误率要配合看：利用率逼近 100% 时错误率往往开始抬头，说明系统进入过载区。

老王盯着平均出餐时间会错过那碗迟到的面；盯 P99 才能发现某桌等了半小时。尾部时延才是口碑崩坏的开始。

容量规划评估

老王最怕两个极端：师傅雇太多，闲坐着还发工资；雇太少，客流一大客人扭头就走。他需要知道店面到底“最多能同时接待多少人”，还要留出安全垫——按峰值的 1.2 倍备料、备人。

容量规划评估以压测基线为起点：基线测试得到当前配置下的最大吞吐与拐点时延；再按业务预测峰值乘冗余系数确定规划容量。

拐点识别是核心动作：阶梯递增压测时，吞吐量不再随并发上升甚至开始下降，同时时延猛增，这个点就是拐点，生产容量应规划在拐点之下留足余量。成本平衡同样重要：GPU 资源昂贵，冗余太少违反 SLA，冗余太多浪费预算，常用“成本—可用性”权衡曲线决定冗余率，并在关键业务上靠多副本和故障转移对冲风险。

容量规划就像备面粉：按周末客流上限多备两成，既不用天天倒陈面，也不会在旅行团到来时只能道歉。

云原生优化实践

理想中的面馆，是客流少时两个师傅歇着，午市自动“打电话”叫来临时工，高峰实在挤不下时让客人先取号排队，而不是几十人堵在柜台——那样反而更慢。云原生架构正是给 AI 推理服务装上这套“随客流呼吸”的能力。

结合压测得到的基线与拐点，云上可落地四件事：弹性扩缩容（HPA 按吞吐或 GPU 利用率自动加减副本）、队列削峰（瞬时超量请求先缓冲进队列，避免打爆服务）、缓存加速（复用 prompt 前缀和常用结果，减少重复算力）、运维监控（Prometheus 采集 + 告警）。副本数的计算依赖压测基线：

弹性伸缩要配冷却时间，防止客流一抖、临时工刚上岗就被遣返，形成伸缩抖动；队列削峰要盯积压深度与超时，队列太深等于换了种方式排队，用户照样等不起；缓存看命中率，命中低时缓存反而白占内存；监控则把吞吐、时延、利用率、错误率四块仪表接入告警，拐点附近自动报警。这一切配置的“标尺”都来自压测——没有基线，阈值就是拍脑袋。

老王最后发现，机器和师傅一样：不该全天候满编，而该跟着客流涨落。压测得到的并发曲线，就是这套呼吸节奏的乐谱。

AI 应用场景

Python 演示

import mathimport randomimport threadingimport time  class InferService:    """模拟AI推理服务, 每个worker相当于一个拉面师傅"""     def __init__(self, workers=3):        self.workers = workers        self.queue = []        self.lock = threading.Lock()        self.done_count = 0        self.latency_list = []     def _infer(self, task_size):        time.sleep(0.05 * task_size * random.uniform(0.8, 1.2))     def _cook(self):        while True:            with self.lock:                if not self.queue:                    continue                body = self.queue.pop(0)            start = time.time()            self._infer(body[1])            cost = time.time() - start            with self.lock:                self.latency_list.append(cost)                self.done_count += 1     def start_workers(self):        for _ in range(self.workers):            threading.Thread(target=self._cook, daemon=True).start()     def run(self, load_func, seconds=8, qps_base=8):        self.start_workers()        end = time.time() + seconds        tick = 0        while time.time() < end:            ratio = tick / seconds            qps = load_func(ratio) * qps_base            n = max(1, int(qps * 0.25))            for _ in range(n):                self.queue.append((tick, random.randint(1, 4)))            tick += 1            time.sleep(0.25)        time.sleep(1.5)  def spike(ratio):    if ratio < 0.3:        return 0.2 + 2.5 * ratio    if ratio < 0.5:        return 1.0    return max(0.1, 1.0 - 2.0 * (ratio - 0.5))  def wave(ratio):    return 0.5 + 0.4 * math.sin(ratio * math.pi * 4)  def report(name, svc):    with svc.lock:        total = svc.done_count        good = len([x for x in svc.latency_list if x < 0.3])    pct = 100.0 * good / total if total else 0.0    print("%s: 完成%d单, 合格率%.1f%%" % (name, total, pct))  def main():    svc1 = InferService(workers=3)    svc1.run(spike)    report("尖峰客流", svc1)    svc2 = InferService(workers=3)    svc2.run(wave)    report("波动客流", svc2)  if __name__ == "__main__":    main()

1. self.done_count = 0完成请求计数器，对应师傅做完的面碗数，读取时用锁保护。
2. time.sleep(0.05 * task_size * random.uniform(0.8, 1.2))推理耗时与任务大小成正比且带随机扰动，还原真实计算波动。
3. self.queue.pop(0)师傅从队列取单，模拟服务端请求排队，队列越长等待越久。
4. with self.lock:加锁保护共享的队列和计数，避免多线程并发写坏数据。
5. qps = load_func(ratio) * qps_base由负载模式函数算出当前时刻请求速率，负载模式不同，灌入节奏就不同。
6. threading.Thread(target=self._cook, daemon=True).start()启动师傅线程，对应 Kubernetes 里的副本实例。
7. good = len([x for x in svc.latency_list if x < 0.3])统计时延低于 0.3s 的合格请求，对应“出餐是否在承诺时间内”。

常见误区

面试题