LLM服务突发流量应对策略

可视化演示

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

流量预测分析

奶茶店老板的柜台上放着一本厚厚的经营日志，上面记录着每天的天气、是否促销、卖了多少杯。每个周末打烊后，他都会翻看这本日志，琢磨“下周六会来多少客人”。这就是预测——不是算命，而是从历史中找规律。

对 LLM 服务来说，流量预测同样不是玄学，而是四个动作的组合。第一是历史数据回溯：翻出过去一年的请求日志，按小时统计 QPS，找出“去年同期发生了什么”。第二是业务事件驱动：把公司的大促日历、产品发布会、营销活动排期转换成流量增量因子——就像奶茶店老板知道商场贴出“买一送一”海报那天，客流一定会涨。第三是周期规律挖掘：识别日、周、月的重复模式，比如工作日上午十点和晚上八点总是出现两个请求高峰，每周一模型调用量明显高于周日。第四是预测模型评估：通过 MAPE（平均绝对百分比误差）等指标衡量预测偏差，持续修正预测参数。

奶茶店老板在预测时会格外看重“昨天卖了 500 杯”这个数字，而不是上个月的日均——加权移动平均正是把这种直觉数学化：让近期的流量数据拥有最大的发言权。预测越准，后面的容量规划越有底气。

容量规划评估

预测到周末会大爆满之后，店长开始算账：店里最多能同时站多少人？几台奶茶机一刻不停能出多少杯？要提前备多少珍珠和鲜奶？这套“算账”在技术世界叫容量规划。

容量规划包含四个步骤。峰值需求估算：根据预测结果换算出峰值 QPS 和峰值并发数，这是规划的目标值。资源基线测量：通过压测得到单个 LLM 实例的 QPS 上限、显存占用和 P99 延迟——相当于让店员试做 100 杯，测出单人单机的极限速度。余量设计原则：容量目标 = 峰值 ×（1 + 冗余系数），冗余系数通常取 20%~50%，用来吸收预测误差和未知波动。压测验证方法：用压测工具（如 k6、Locust）模拟真实流量冲击服务，验证容量评估是否准确，就像大促前一晚让临时工提前演练一遍。

这就像奶茶店的操作台：每分钟进来 10 个订单（QPS=10），每单从下单到出杯平均要 2 分钟（T=2），那操作台上任何时刻都会堆着 20 杯在做的饮品（C=20）。如果操作台只能放 15 杯，说明系统的并发能力不够了。

弹性伸缩策略

客流高峰杀到，店长一个电话召来三名兼职大学生，又支起一张折叠操作台；傍晚客流回落，就让兼职先下班、收起折叠台。这种“人多加人、人少减人”的动态调整，就是弹性伸缩。

在 Kubernetes 世界里，弹性伸缩有四个关键设计。水平自动扩缩：通过 HPA（Horizontal Pod Autoscaler）根据 CPU、内存或自定义指标自动增减 Pod 副本数——相当于按客流人数增减操作台。垂直资源调整：临时调大单个实例的 CPU 和显存配额，比如把 8GB 显存升到 16GB——相当于给奶茶机换一个更大的原料桶。伸缩阈值设定：合理设置触发条件，比如“CPU 使用率超过 70% 且持续 3 分钟则扩容一个副本”，防止瞬时抖动导致频繁伸缩。冷启动优化：大模型权重加载动辄数分钟，可通过预置实例池、容器镜像预热、模型权重预先加载等手段，让新实例“秒上岗”。

回到奶茶店：预测周末峰值 600 单/小时（QPS_peak），一名店员每小时最多做 60 单（QPS_single），再留 20% 的富余（m=0.2），那就需要 ⌈600/60 × 1.2⌉ = 12 名店员。伸缩不是拍脑袋，而是这套算术。

服务限流保护

店门口站着一位壮硕的保安，手里捏着计数器，店里满 50 人后，“请排队取号”——这就是限流。限流看似在“赶客”，实则在保护：让店内系统始终在安全容量内运转。

LLM 服务的限流体系包含四层设计。限流算法选择：固定窗口计数、滑动窗口、令牌桶、漏桶是四种经典算法，其中令牌桶能同时兼顾“平均速率限制”和“突发流量容忍”，是网关限流的主流选择。客户端限流：在 App 或 SDK 层面控制单个用户的请求频率，防止客户端异常重试或恶意刷接口——相当于保安认识老顾客，常客可以先放进去。网关层限流：在 API 网关统一施行全局限流，无论请求来自哪个客户端，都必须在“大门”处过闸机。过载保护：当系统负载超过危险线（如 CPU 90%），主动拒绝新请求、优先保护存量请求完成，这是最后的“保命手段”。

限流的精髓在于“先放行一部分，保全整体”。就像奶茶店保安宁可让顾客在门外排 10 分钟，也不让 100 人同时涌进只有 20 个座位的小店——那会让所有人都等 40 分钟并且体验崩溃。

排队降级机制

暴雨天客流实在太大，保安开始发号：你是 108 号，前面还有 30 桌，预计等 15 分钟。同时，招牌“雪山芝士莓莓”的草莓用完了，店员诚恳建议：“要不要试试基础款珍珠奶茶？一样好喝。”这就是排队和降级。

排队降级机制有四个设计要点。队列缓冲设计：将超出处理能力的请求写入消息队列（如 Kafka、Redis Stream），让后端按自身节奏消费，实现“削峰填谷”——就像取号机把等待客人的“需求”先存起来。优先级调度：在队列中为不同等级的请求分配权重，如付费用户、VIP 客户的请求优先出队。降级预案：提前准备好“降级菜单”：返回缓存结果、切换轻量模型、限制上下文长度（如 4K 降到 2K）、关闭非核心功能（如停止“联网搜索”）。友好提示反馈：对实在无法进入队列的请求，返回 429 状态码并携带 Retry-After 头部，告诉客户端“太忙了，请 30 秒后再来”。

这个公式最震撼的结论是：当 λ 逼近 μ 时，等待时间会急剧变长——奶茶店每秒来 58 个单、每秒只能做 60 个时，等待时间会明显拉长；若每秒只能做 59 个，同样的到达率下排队就会失控。所以系统设计一定要让 μ 远大于 λ，留出能力余量。

熔断恢复机制

如果厨房的炸锅突然起火，店长会做三件事：先按下消防按钮停止一切接单（熔断打开）；火灭了，打开一个小窗，只接几个熟客的订单试试（半开探测）；确认出杯正常后，才重新开门迎客（恢复闭合）。这就是熔断器的完整生命周期。

熔断机制的设计包含四个环节。熔断状态机：记住三种状态——闭合（closed，正常放行）、打开（open，拒绝所有请求）、半开（half-open，试探性放行）。失败率阈值：在滚动窗口内统计失败率（超时、5xx 错误），当失败率 ≥ 阈值（如 50%），熔断器从闭合跳转为打开。半开探测恢复：打开状态持续一段时间（如 30 秒）后转入半开，放行少量探测请求，若成功率达到阈值则迅速恢复闭合，否则再次跳回打开。故障隔离：熔断只隔离故障依赖，避免一个下游服务的故障像多米诺骨牌一样压垮整个链路。

熔断的本质是“主动止损”：与其让所有请求都超时、把系统拖入雪崩，不如让一小部分请求快速失败，换回整体的快速恢复。这就像厨房起火时果断停业，远比勉强出杯制造更大的事故划算。

监控告警体系

店长的办公室有一面监控墙：当前排队人数、三台奶茶机的运行状态、珍珠和鲜奶的库存、最近十分钟的出杯速度，全部实时刷新。任何一项指标异常，对讲机立刻响起——这就是监控告警。

一套完整的监控告警体系包含四层能力。核心指标监控：盯住四个黄金信号——QPS、延迟（P95/P99）、错误率和资源饱和度（GPU 利用率、显存占用、CPU）。日志追踪链路：为每个请求生成全链路 Trace ID，串联网关、模型服务、下游依赖的日志，一旦出问题能快速定位“请求究竟卡在了哪个环节”。告警分级响应：P0 级（如错误率 > 20%）通过短信 + 电话轰炸值班人，P1 级（如 P99 延迟超阈值）发企业微信并创建工单，P2 级仅记录观察。大屏可视化：把黄金指标集中到 Dashboard 大屏，帮助值班团队在一分钟内定位全局状态。

记住一个经典数字：99.9% 的 SLO 意味着每月最多约 43 分钟的故障时间。奶茶店要承诺“99.9% 的订单 3 分钟内出杯”，那一个月累计超时不得超过 43 分钟——超出预算就必须启动熔断和限流来“止损”。

AI 应用场景

Python 演示

import randomimport math  def generate_traffic(t):    """模拟 t 时刻的请求量: 平时 50 左右, 第 20-35 步飙到 400"""    if 20 <= t <= 35:        return 400 + random.randint(-20, 20)    return 50 + random.randint(-5, 5)  def predict_next_traffic(history):    """加权移动平均: 越近的数据权重越大"""    n = min(len(history), 5)    if n == 0:        return 50    weights = [0.1, 0.15, 0.2, 0.25, 0.3]    recent = history[-n:]    w_sum = sum(weights[-n:])    return sum(w * q for w, q in zip(weights[-n:], recent)) / w_sum  class TokenBucket:    """令牌桶限流器"""     def __init__(self, rate, capacity):        self.rate = rate          # 每秒补充令牌数        self.capacity = capacity  # 桶容量        self.tokens = capacity    # 当前令牌数     def allow(self, n=1):        self.tokens = min(self.capacity, self.tokens + self.rate)        if self.tokens >= n:            self.tokens -= n            return True        return False  def main():    SINGLE_INSTANCE_QPS = 60   # 单个实例能处理的 QPS    REDUNDANCY = 0.2           # 冗余系数    history = []    bucket = TokenBucket(rate=80, capacity=120)    stats = {"total": 0, "rejected": 0, "instances": []}     for t in range(50):        qps = generate_traffic(t)        history.append(qps)        pred = predict_next_traffic(history)        need = math.ceil(pred / SINGLE_INSTANCE_QPS * (1 + REDUNDANCY))        capacity = need * SINGLE_INSTANCE_QPS        allowed = 0        for _ in range(qps):            if allowed >= capacity * 1.2:                stats["rejected"] += 1                continue            if bucket.allow():                allowed += 1            else:                stats["rejected"] += 1        stats["total"] += qps        stats["instances"].append(need)        if t % 10 == 0 or 20 <= t <= 36:            drop = 1 - allowed / qps            print("t={:2d} QPS={:3d} 预测={:6.1f} 实例={:2d} 拒绝={:3d} 丢弃率={:.1%}".format(                t, qps, pred, need, qps - allowed, drop))     print("\n总请求={} 被拒={} 总丢弃率={:.2%}".format(        stats["total"], stats["rejected"], stats["rejected"] / stats["total"]))    print("实例数峰值={} 平均={:.1f}".format(        max(stats["instances"]), sum(stats["instances"]) / len(stats["instances"])))  if __name__ == "__main__":    main()

1. history.append(qps)每步把真实流量记入历史序列，为预测提供素材
2. pred = predict_next_traffic(history)用加权移动平均推断下一时刻流量，权重偏向最近数据
3. need = math.ceil(...)根据预测值、单实例能力与冗余系数算出目标实例数
4. bucket.allow()令牌桶判断当前请求是否放行，是网关限流的经典实现
5. if allowed >= capacity * 1.2:超过容量 120% 的请求直接拒绝，模拟过载保护
6. stats["rejected"] += 1统计被限流丢弃的请求数，用于计算总丢弃率

常见误区

面试题