演示到生产的失败模式：为什么AI原型在真实用户到来时会崩溃
30%的生成式AI项目在概念验证后被放弃。95%的企业试点没有产生任何可衡量的业务影响。Gartner预测，到2027年底，40%的智能体AI项目将被取消。这些并非底层技术的失败——而是演示与生产之间差距导致的失败。
演示到生产的失败模式是可预测、可重复的，也几乎完全可以预防的。它的发生是因为让演示看起来很棒的条件与让生产正常运行的条件系统性地不同。团队优化前者，却被后者打个措手不及。
演示是谎言（并非有意为之）
一个引人注目的AI演示有几点优势，但没有人会大声说出来：
精心挑选的输入。 演示使用构建者知道系统能很好处理的问题和提示。演示者选择一个主题，清晰地构建查询，避免真实用户会立即产生的模糊、不完整 或对抗性措辞。没有人在演示中写"你能帮我总结一下这个玩意儿吗？？"但真实用户会这样写。
预热的基础设施。 从开发者笔记本电脑或预热的暂存环境演示的系统，其模型权重已加载到GPU内存中，向量索引已热加载，提示缓存已填充。生产环境面临冷启动延迟：无服务器GPU部署在第一个token出现之前，加载权重可能需要30到60秒。即使是托管推理，在需求激增时也会增加可变的队列时间。演示中看起来很好的p50延迟，并不是用户将体验到的p95。
有耐心的评估者。 评估演示的人对其成功有投入，对错误有容忍度。他们会在心理上补全模糊的输出，原谅缓慢的响应，如果出现问题也不会关闭标签页。真实用户如果应用程序在三秒内没有响应就会放弃——53%的用户会这样做。每增加一秒延迟，7%的用户就会离开。
这些都不是欺骗性的，只是演示自然构建的方式。问题在于当团队将演示性能视为生产就绪性的可靠信号时。
分布偏移：测试集与用户之间的差距
生产崩溃最常见的原因不是bug——而是真实用户发送的请求与系统评估时使用的请求完全不同。
规范查询与真实查询。 工程师构建的评估集措辞规范、结构清晰、语义明确。真实用户写的是片段，混合语言，发出矛盾的指令，并做出系统无法满足的假设。在完整帧中人脸占据整个画面的近距离肖像上，基准准确率为94%的人脸检测模型可能会系统 性地失败——这种输入类型没有人想到要包含在测试集中。
对抗性分布。 系统上线的那一刻，就有一部分用户会积极探测它。他们会尝试越狱，注入冲突指令，并探索没有任何演示场景接近的边缘案例。这不仅仅是安全问题——对抗性输入揭示了标准评估集完全遗漏的故障模式。
长尾变异。 多语言输入、特定领域术语、非标准文档格式、具有共享状态的并发请求——这些边缘案例不会出现在演示中。在生产中，它们构成了实际流量的相当大比例。在演示中处理干净PDF的RAG系统，在生产中会遇到破坏分块管道的扫描文档、嵌套表格、部分OCR文件和格式转换数据。
解决方案是在评估期间故意注入多样性：在预发布测试套件中包含多语言输入、语法错误输入、对抗性输入和边缘案例格式。不是作为事后补充——而是作为必要关卡。
延迟悬崖：并发下的均值与尾部
生产延迟和演示延迟测量的是不同的东西。
演示延迟是单请求、预热缓存、无拥塞的。生产延迟是并发的、第一次调用时冷启动的、受队列动态影响的。
交互式AI应用程序的相关指标不是平均延迟——而是在真实并发下的p95首token时间（TTFT）。可用交互式AI的行业目标是文本p95 TTFT低于500ms，语音低于300ms。一旦请求并发超过演示测试期间的基础设施容量，两者都会崩溃。
这个数学是无情的。随着批量大小超过最优服务点，每个请求的延迟会急剧增加。当并发超过可 用GPU容量时，请求就会排队。在单用户演示中响应时间为400ms的系统，当50个用户同时访问时可能响应时间为8000ms——这还不包括冷启动。
冷启动陷阱。 出于成本原因选择无服务器或按需缩放GPU部署的组织，往往在生产中发现这个问题。单单加载模型权重就可能需要30秒。容器缓存策略可以将此减少约一半，但将30秒冷启动减半仍然会产生15秒的等待，这会破坏每次新部署或自动扩展事件时所有用户的第一印象体验。
预发布负载测试必须模拟真实的并发用户，而不是单请求顺序运行。必须捕获p95和p99百分位数，而不是均值。必须测试冷启动场景，而不仅仅是预热稳态。
为什么传统质量保证对LLM系统失效
标准测试假设是：相同输入→相同输出。这个不变量消失了。
LLM在设计上是不确定的。温度、采样以及自回归生成的随机性意味着相同的提示在连续调用中可能产生实质上不同的输出——即使在零温度下，跨提供商区域的批处理效果和硬件差异也会引入方差。
这破坏了大多数继承的测试基础设施：
