压测流量和真实流量有什么区别？

消防演习跑得再整齐，也代替不了真火场的慌乱。大模型服务上线前压测全绿、上线当天照样卡死，原因几乎都出在同一处：压测流量和真实流量根本上是两种东西。压测流量是按脚本造出来的，真实流量是千万用户随手发出来的。结论先说：压测用来验证容量下限，真实流量才检验体验上限，两者都要看，谁也替代不了谁。

压测流量是造出来的

压测脚本里的请求往往规整：固定长度、固定间隔、固定类型。它会刻意制造高峰，验证系统在预设压力下撑多久、哪里先断。这种规整是优点——结果可复现、便于对比，也是缺点——把真实世界最难缠的部分全剪掉了。另一个常见偏差是压测机本身成为瓶颈，发起压力的机器先撑不住，测出来的数字全部失真，压测机配置也要留余量。从 ModelScope 拉模型做内测时，用少量样例请求跑通链路没问题，但据此判断生产容量就危险了。

真实流量不讲道理

真实流量的特点是有毛边：请求长短参差、高峰没有预兆、用户会发超大附件、会连点重试、会在同一秒挤进来。它还带节奏——工作日上午的客服高峰、晚间的闲聊高峰各不相同。更麻烦的是异常组合：恰好赶上模型切换又逢缓存过期，任何单点都测过、组合起来照样翻车。把真实流量单独存一份脱敏样本库，每次压测都从这里取材，样本库本身就是团队重要的测试资产。

为什么压测过了线上还是崩

常见三个原因。一是压测只打主链路，真实流量会探索到冷门接口。二是数据形态不同，压测短句、真实长文档，内存占用差一个量级。三是压测环境太干净，没有伴随的定时任务和后台清理抢资源。上线后的第一周要格外盯紧，监控怎么配可参考自建监控和托管监控的取舍。还有第四个原因：压测时段恰好其他业务闲置，资源互不干扰，而真实环境里大家挤在同一台宿主机上。

把这几处对不上号的地方逐条摆开，落差就清楚了。

让演习贴近实战的五个办法

• 用脱敏后的历史请求回放，别自己编句子；
• 把峰值放大百分之三十到五十，留出余量；
• 压测时段故意叠加后台任务，模拟抢资源；
• 长短请求混发，节奏忽快忽慢；
• 把降级切换也纳入压测范围，验证备胎真能接得住，链路设计见多模型路由和单模型加降级。

压测之后还要做什么

压测报告要转化成动作：扩容多少、限流阈值定在哪、哪个接口加缓存。容量涨了成本也要重新记账，摊法见成本归集和成本分摊。扩出来的资源若按需启停，冷启动开销会吃掉一部分余量，预热思路看冷启动优化和常驻优化。真出了事故，复盘流程要落在纸上，模板参考容灾演练和预案文档。

自查清单

• 压测数据来源：脚本现编 → 改用历史回放
• 峰值假设：拍脑袋 → 取近三月最高峰加余量
• 场景覆盖：只有主链路 → 补冷门接口
• 降级验证：没测过 → 纳入压测脚本

划重点：压测证明「设计成这样能扛」，真实流量证明「用户用起来没事」，两句话都要成立。

关于压测流量和真实流量的三个常问问题

• 新业务没有历史流量怎么办？：用相似业务的日志做种子，再手工加长尾样本，上线后第一周按真实分布重新校准压测脚本。
• 压测会不会把线上服务打挂？：会，务必在隔离环境或低峰时段执行，并提前告知值班同事，预案先行。压测环境与生产环境的配置差异要记录在报告里，方便事后换算。
• 用什么工具编排压测流程？：请求编排可借助扣子这类平台组装，重放与统计交给压测专用工具，别让一个工具干所有活。

演习的目的不是拿到一张全绿报告，是提前暴露断点。把压测当草稿、把真实流量当定稿，容量心里就有底了。上线后第一个月每周复盘一次延迟曲线，把偏差记回脚本的假设里。