UXOFFER每年到了农历腊月二十几，我手机里挂着生产环境和告警的群就开始热闹起来。今年比往年更忙，因为团队手里多了一个AI应用——在大模型上做的春节互动功能，类似AI拜年文案生成、生肖运势解读这种。做过普通Web服务的人第一次把模型推理服务扛到春节流量面前，会踩到很多意料之外的坑。这篇文章就聊聊春节流量洪峰下，AI应用稳定性这件事。如果你是AI应用开发工程师、独立创业者，或者公司里负责AI应用上线的技术负责人，下面这些思路和踩坑记录，应该能帮你少走不少弯路。
先说个很多人容易忽略的事实：AI应用的流量洪峰，跟传统Web应用的压力完全不是一回事。普通接口被压垮，往往是CPU和数据库连接先撑不住；AI应用真正吃紧的是GPU显存、推理并发控制、Token吞吐，还有那笔按小时计费的算力账单。你不可能像堆普通服务那样无脑加服务器，因为贵，更因为单纯加机器可能解决不了推理框架层面的瓶颈。所以这篇文章我打算从流量预估、压测、推理优化、监控预案、成本控制、事故复盘六个维度，把春节前需要做的事完整过一遍。
1. 先给AI应用算一笔“春节流量账”
1.1 春节流量跟平时到底差在哪
很多团队做容量规划的时候，习惯拿平时的QPS乘个系数，然后照着扩机器。这一套在普通Web服务上能凑合，放到AI应用上会出问题，因为春节流量有几个非常特殊的形态。
第一是用户活跃时间彻底变了。平时是早晚高峰，除夕到初三基本是全天在线，凌晨两三点还有人在生成祝福语、玩AI合影。这意味着你没有低谷期可以喘口气，也不能指望凌晨悄悄缩容省成本。
第二是瞬时流量特别陡。活动一上线，短视频平台一个爆款视频带进来几万用户，他们几乎同时点进来。这种流量不像平稳爬坡，而是断崖式涌进来，如果扩容跟不上，第一波用户就全跑了。
第三是单请求的消耗在变大。春节场景里用户不会只发一句话就结束，很多人会连着追问、反复生成，对话轮次比平时长很多。文字生成接口的单请求耗时本来就比普通API高好几倍，再加上用户交互变深，系统承受的压力不是QPS涨了，而是“QPS涨 + 单请求成本涨”的双重放大。
第四是业务类型变得很杂。同一个AI应用里可能同时有文本对话、图像生成、语音交互，它们的资源消耗模型完全不同。文生图单请求可能要几十秒，GPU利用率极高；语音唤醒类功能对延迟极其敏感，连排队都接受不了。规划容量的时候如果只按总QPS一刀切，很容易把资源配置错。
1.2 从DAU倒推QPS，再算算要多少GPU
估算容量最靠谱的方式是压测，但在压测之前，至少得有个粗略的目标量级。我习惯用下面这个公式：
code复制峰值QPS = 日请求总次数 × 高峰时段集中系数 / 高峰窗口秒数
举个例子。假设平时DAU是20万，人均每天调用AI接口5次，日请求量就是100万。春节DAU涨到150万，人均调用次数因为活动交互变深涨到15次，日请求量就是2250万。再假设高峰集中在晚上8点到12点这4个小时，集中系数取0.7，那么高峰窗口秒数是4×3600=14400秒，算下来：
code复制峰值QPS = 2250万 × 0.7 / 14400 ≈ 1094 QPS
这个数字只是平均峰值，真正瞬间的流量尖刺可能再冲高2到3倍。所以目标容量至少要按2000到3000 QPS去准备。
拿着目标QPS倒推GPU实例数，需要知道单实例能扛多少。这里没有统一答案，取决于模型大小、输入输出长度、推理框架和显卡型号。我一般先做理论估算，再用压测修正：
code复制单实例QPS ≈ 单实例并发处理数 / 单请求平均耗时
假设一个7B参数模型，用vLLM部署在单张24GB显卡上，同时处理64路请求，单请求平均耗时1秒，那单实例大约能扛64 QPS。要撑3000 QPS的冗余目标，大概需要47个实例。如果把并发数优化到128路，实例数就能降到24个左右。这中间的差距就是优化空间，后面会细说。
1.3 不同类型AI应用的资源差异
上面是按文本生成模型算的，但AI应用远不止这一种。
纯文本对话和文本生成类，瓶颈通常在线程并发和KV Cache显存占用。用户输入的prompt越长、生成的output越长，显存消耗越大。这类服务适合用支持连续批处理的推理框架，尽量把GPU的每一份算力榨干。
文生图、图生图这类多模态任务，单请求耗时可能高达几十秒，而且请求期间GPU几乎全程满载。它的问题不是并发高，而是并发稍微一起来，显存就爆了。这种反而更适合走异步队列，请求先进来排队，后台慢慢出图，用户端用轮询或者WebSocket拿结果。
语音唤醒、实时对话这类交互，对时延的敏感度极高。用户说一句话，一两秒内必须响应，否则体验归零。它们不能排队，也不适合塞进共享的推理集群里跟其他任务抢资源，需要独立的低延迟部署。
做容量规划的时候，先搞清楚你的应用属于哪一类，再决定用同步还是异步、用共享集群还是独立资源，这一步能省下大量冤枉钱。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 性能压测：别等年三十才第一次看监控
2.1 压测工具选型
容量规划做完，下一步就是上压测。我见过很多团队图省事，直接拿curl脚本或者Postman点几下就当压测了，结果一到大促就现原形。正经做AI应用压测，工具选择也有一些讲究。
wrk是个轻量级工具，适合快速打一下入口HTTP层的极限，但它构造复杂JSON body的能力弱，模拟真实业务场景比较费劲。
k6是目前我用的最多的。它用JavaScript写脚本，能模拟用户行为、构造复杂请求体、设置阶梯式加压，还能跟Prometheus、Grafana对接，压测数据直接进监控