引言
晚上 20:00，某电商平台的一场促销活动正式开始。
作为 AI 模型网关的维护人员，我和组员提前一小时进入值班状态。这次活动规模并不大，模型网关的整体 QPS 仅出现约 5% 的短暂增长，系统也始终处于正常负载范围内。
但在观察监控时，我发现了一条很有意思的曲线，而这种变化恰好与我此前对促销期间用户行为的猜测有些吻合…
1. 从 QPS 曲线开始
先交代一下监控口径。
这里的 QPS 指的是下游业务系统向 AI 模型网关发起的入口逻辑请求，并非终端用户的咨询次数，也不是网关向上游模型厂商发起的实际请求总数。
同时，网关承载多个电商平台的模型调用，本次只有其中一个平台开展促销，因此监控展示的是聚合流量。
全天流量概览
用于展示日常流量的整体变化。其他时段的独立流量峰值不纳入本次促销分析。夜间的短时高峰是促销前的瞬时压测预演。
从全天趋势来看，模型网关存在较为明显的日夜流量差异。白天请求量逐渐恢复，晚间则进入相对稳定的运行区间。
这次促销并没有让整体流量发生数量级上的变化。
活动前后的流量变化
重点观察 20:00 前后的负载变化，以及活动开始前的流量基线。
将时间范围缩小到活动前后，可以看到 20:00 附近发生了一次短暂的流量下探，随后迅速回升。
值得注意的是，活动开始前也存在一次较高的独立峰值，其原因暂时不明确，因此不能直接归因于促销。
继续放大活动开始后的曲线：
重点展示活动开始时的下降、快速反弹、多次局部峰值以及后续回落。
整段变化大致可以分成几个阶段：
- 短暂下降：活动开始附近，QPS 出现一个低谷。
- 快速反弹：随后一两分钟内迅速上涨，形成第一个明显峰值。
- 多峰波动：短暂回落后再次攀升，期间存在相对平缓的区间。
- 逐渐回归：后续反弹幅度减弱，流量重新进入日常波动范围。
相比持续上涨，这更像是一次由业务事件引发的短暂流量扰动。
2. 为什么促销开始，QPS 反而下降？
这是我觉得最有意思的地方。
在活动开始之前，我就猜测过，促销可能不会让 AI 客服的调用量立即增加，反而可能短暂降低。
原因其实很简单：用户的注意力是有限的。
想象一下，你正准备抢购一件限量商品，倒计时刚刚结束，最重要的事情是什么？
当然是赶紧点击购买、提交订单、完成支付。
这个时候谁还有空跟客服机器人唠嗑？
于是，用户行为可能经历一次短暂的转移：
浏览与咨询 → 集中抢购 → 完成下单 → 恢复咨询
在这个过程中，部分用户暂时停止咨询，可能使客服系统的模型调用需求下降。
而第一批用户完成下单后，又可能因为商品规格、订单信息、优惠细节等问题重新发起咨询，使 QPS 快速反弹。
这也能够解释为什么第一个峰值并不一定出现在活动开始的瞬间，而是稍有滞后。
当然，20:00 附近的低谷也可能包含正常流量波动。目前只能说观察结果与这个假设吻合，还不能认定两者存在直接因果关系。
3. 为什么会出现多个峰值？
如果所有用户都在同一时间完成购买，那么后续流量可能只有一次比较集中的上涨。
但真实的电商活动显然不是这样。
有些用户操作很快，有些用户需要反复提交订单，还有些用户可能受到平台排队、库存变化或支付流程的影响。
因此，不同用户完成购买的时间可能存在差异，后续咨询需求也可能分批出现。
这里还有一个值得注意的现象：不同用户群体产生的流量变化可能相互抵消。
比如：
- 一部分用户仍在抢购，暂时减少咨询。
- 另一部分用户已经完成购买，开始询问订单细节。
前者减少模型调用需求，后者增加模型调用需求。
最终聚合 QPS 可能表现为一段相对平缓的曲线。
曲线看起来很平静，并不代表背后的用户行为也同样平静。
但这还不是全部。
AI 模型网关承载的也不只是聊天模型。部分业务还可能涉及 Embedding、Rerank、知识库问答、自动化处理或回复质量评审等链路。
一次用户行为，可能触发多次模型调用；某些异步任务也可能延迟执行。
因此，多个峰值可能同时受到两类时间差的影响：
- 用户完成不同操作的时间差。
- 下游业务系统处理和调用模型的时间差。
不过，网关只能按模型和上游渠道观察流量，无法直接识别请求来自哪个电商平台、哪条业务流程。
所以我们并不能简单地把每一个峰值对应到某一批完成下单的用户。
4. QPS 有变化，系统就有压力吗？
并不一定。
这次促销带来的整体 QPS 增幅并不明显，上游模型调用成功率保持在很高的水平，延迟和 Token 吞吐也没有出现显著异常，容灾机制几乎没有介入。
整个系统始终处于正常服务能力范围内。
而对于 AI 模型网关来说，QPS 本身也无法完整描述实际负载。
同样是每秒 100 次请求，短文本推理和长上下文生成可能具有截然不同的 Token 消耗、执行时间和资源占用。
因此，QPS 更适合用于观察请求到达速率，不能单独作为系统压力的完整判断依据。
这次我们看到的主要是业务调用需求的短暂变化，而不是基础设施遭遇性能瓶颈。
5. 一点工程思考
这次观察让我更加确信了一件事：
业务事件发生的时间，不一定就是基础设施负载达到峰值的时间。
用户行为、业务处理和模型调用之间可能存在时间差，不同来源的请求也可能在聚合监控中相互叠加或抵消。
我们看到的是最终到达网关的流量，而不一定能直接看到产生这些流量的业务行为。
这也提醒我们：不要只凭一条 QPS 曲线，就为每个波峰和波谷编造一个确定的原因。
这次小促销并没有给系统带来什么挑战，却留下了一次有意思的生产观察。
等到真正的双十一大促，我也很想看看：当业务活动规模明显扩大时（3-10倍），这种先下降、再反弹、最后逐渐恢复的流量形态，是否还会出现。
到时候再回头对比这次曲线，或许能得到一些新的答案。
