镝不咸先说一个我印象很深的场景：凌晨两点，运营群里突然弹出一条消息，“人群包刚跑完，准备开始推送”，后台监控上的QPS从800一下蹿到2万，模型服务实例从20个被拉到120个，平台自动扩容，消息队列积压从0涨到几十万又慢慢回落到0。整个过程没有值班工程师被电话叫醒，第二天复盘时大家看曲线，发现流量高峰和成本峰值几乎完美错开。
这就是做智能营销AI平台最让人上瘾的地方。也和做常规业务系统完全不同：你不能按峰值流量把机器常年备着，那会让成本高到老板怀疑人生；也不能只按平均流量设计，那大促活动一上来系统必挂。弹性可扩展架构说到底只有两件事：高峰期能不能扛得住，低谷期能不能把钱省下来。但真把这八字落到实处，要从流量特征、系统分层、伸缩策略、稳定性兜底一路抠到GPU调度。
这篇文章是我团队从0到1搭智能营销AI平台、以及后续多次大促压测后的完整记录。包含架构怎么拆、弹性怎么调、扩容过程中踩过的坑、靠什么机制兜底，希望能给正在做同类系统的朋友一些参考。
1. 营销流量和普通流量不一样：先搞清楚到底在“弹”什么
1.1 脉冲式流量才是常态
传统互联网后端，哪怕是电商业务，平时流量和峰值之间通常也就三五倍的差距，而且这种增长是渐进式的。智能营销AI平台的流量模型完全不同：运营一次“618会员召回”、“双11前站预热”、“直播间的实时发券”，流量形态都是一条近乎垂直的脉冲。
举个例子，一个千万级用户的品牌，运营选好人群包、点下“开始投放”按钮的那一秒，人群圈选服务要立刻把几百个筛选条件跑完，随后消息发送请求会在几分钟内打到触达服务上。如果这个营销位是通过Push、短信、微信模板消息触达，后端要处理的不是每秒几百个请求，而是每秒数万条消息的投递。即便加上了限速、分批、队列削峰，瞬时拥塞依然存在。
所以建平台第一天就要接受一个事实：弹性可扩展架构的第一目标不是“快”，而是“宽”——能在几分钟内把系统容量拉大几十倍，顶住脉冲并不被打垮。 谁按常驻流量的3倍去留冗余，谁就会在第一次大促时付出惨痛代价。
1.2 AI推理负载让弹性问题更难办
如果只是消息推送，弹性问题其实好解决，多加无状态实例就行。智能营销AI平台难在它里面混着两类完全不同特征的负载：
第一类是传统业务负载，比如人群圈选、名单导出、触达发送、频控查询。这类服务的关键字是“连接数”和“IOPS”，依赖数据库、Redis、消息队列。
第二类是AI推理负载，比如用lookalike模型找相似人群，用CTR/CVR模型给用户打分排序，用NLP模型抽取用户意图标签。这类服务吃的是CPU算力，更吃GPU显存。一个基于Transformer的打分模型，GPU推理单次可能几百微秒到几毫秒，但一旦并发上来，显存不够就直接OOM。
这两种负载对扩容的反应速度完全不一样。普通Web服务加几个Pod，几十秒内就能开始接流量。带模型的推理服务扩容，要考虑镜像体积、模型文件下载、GPU驱动初始化、CUDA上下文预热，冷启动动不动三两分钟起步。大促流量不可能等你慢慢拉实例。
1.3 营销链路处处是“状态”，扩了容但不一定扛得住
最坑的是，营销平台不像纯展示类系统那样可以随便无状态化。一次完整的营销活动链路是这样的：
- 运营创建活动，选择目标人群圈选条件
- 人群圈选服务实时或离线圈出用户ID集
- 系统对人群做频控、黑名单过滤、疲劳度检查
- AI模型对人群打分排序，选出“最可能转化”的头腰部用户
- 消息触达服务按用户偏好渠道发送内容
- 用户点击/转化行为回流到数据系统，形成下一轮营销的优化素材
每一环几乎都带着状态：圈选任务有进度，频控要查用户N天内是否收过同类型消息，触达渠道有上游限流配额，连AI打分都有特征拼接需要实时读取用户画像。
这种情况容易让人陷入一个误区：以为弹性就是“K8s加Pod”。实际上，扩了无状态应用，瓶颈可能跑到数据库连接数上；把数据库连接池加大，瓶颈又到