做个 LLM 应用的 demo 很容易。调个 API，拼个 prompt，跑出来效果不错，发个朋友圈，感觉自己掌握了未来。
把它搬上生产是另一回事。demo 跑十次有九次对就行，生产要一万次里有九千九百次对。demo 延迟五秒无所谓，生产超过两秒用户就跑了。demo 烧自己的 token 不心疼，生产烧的是真金白银。demo 挂了刷新一下，生产挂了要写故障复盘。
demo 到生产之间的这道鸿沟，就是 LLM 应用工程化要填的。它和传统软件工程有相通之处，也有 LLM 特有的新难题。这篇讲这道鸿沟里到底有什么。
可靠性，demo 跑通不等于稳定可用
图：Demo 与生产在可靠性、成本、延迟、可观测性四个维度上的差距，这正是工程化要填的鸿沟。
这是最大的鸿沟。LLM 的输出有随机性，同样的输入可能给出不同的输出，有些对有些错。demo 里你展示的是跑得好的那几次，生产里用户撞上的是跑得差的那几次。
提升可靠性要做几件事。降低输出的方差，通过调温度、优化 prompt、加约束，让输出更稳定地落在「正确」的范围里。建立兜底机制，模型给不出好答案的时候，有降级方案，而不是把垃圾直接抛给用户。建立评估体系，持续监控输出的质量，发现质量下降能及时处理（这在前面 Agent 评估那篇讲过）。
可靠性还涉及外部依赖的稳定性。LLM API 可能限流、可能超时、可能短暂不可用。你的应用要能处理这些，重试、降级、多模型备份，不能因为 OpenAI 抽风了一下你的应用就全挂。
成本，token 是真金白银
LLM 应用的成本结构和传统应用完全不同。传统应用的主要成本是服务器和带宽，相对固定。LLM 应用的成本和用量强相关，每一次调用都烧 token，用得越多烧得越多。
成本失控的几个常见原因。prompt 太长，把大量无关上下文塞进去，每次调用都付这些 token 的钱。调用次数太多，一个任务里反复调用模型，成本叠加。选了过强的模型，简单任务用最贵的模型，杀鸡用牛刀。
控制成本的几个手段。prompt 精简，只放必要的上下文，砍掉冗余。缓存，相同或者相似的查询复用之前的结果，不重复调用模型。模型分级，简单任务用便宜的小模型，复杂任务才上大模型。监控 token 用量，发现异常消耗及时排查。
成本和质量的平衡是 LLM 应用的持续课题。用最贵的模型质量最好但烧钱，用最便宜的省钱但质量差。找到那个满足质量要求的最低成本配置，是工程化的核心目标之一。
延迟，用户等不了太久
LLM 推理是慢的，比传统 API 调用慢一个数量级。一个复杂的生成可能要几秒甚至十几秒，用户体感很差。
降低延迟的几个方向。流式输出，模型一边生成一边把内容推给前端，用户看到字一个个出来，体感等待时间大幅缩短。这是最有效的延迟优化，不改技术只改体验。并行化，能并行的调用别串行，多个独立的工具调用或者多个检索同时做。缓存，重复的查询直接返回缓存结果。用更快的模型或者更短的 prompt，推理时间和输入长度正相关。
延迟优化有个原则，区分「首字延迟」和「完整延迟」。首字延迟是用户看到第一个字要等多久，这个最影响体感，要尽量短。完整延迟是全部生成完要多久，相对次要。流式输出之所以有效，就是因为它把首字延迟和完整延迟解耦了，让用户在生成还在进行时就开始消费内容。
可观测性，黑盒里要有眼睛
图：LLM 应用的可观测性需要记录四类数据——输入输出、中间步骤、性能指标、质量指标，缺一则无法调试和运维。
LLM 应用是个黑盒。输入进去，输出出来，中间发生了什么，不记录的话完全不知道。这在调试和运维上是巨大的挑战。
可观测性要记录什么。每次调用的输入和输出（用于调试和质量分析）。调用的中间步骤（Agent 的规划、工具调用、反思过程）。性能指标（延迟、token 用量、成本）。质量指标（用户反馈、自动评估分数）。
这些记录下来，才能做几件关键的事。调试，某个 case 输出不对，能回溯看是哪一步出了问题。监控，线上质量下降或者成本飙升，能第一时间发现。优化，分析常见的失败模式，针对性地改进 prompt 或者流程。
可观测性不是锦上添花，是 LLM 应用上生产的必需品。没有可观测性的 LLM 应用，就是个没法维护的黑盒，出了问题只能靠猜。
评估和回归测试
这个在 Agent 评估那篇详细讲过，这里强调它在工程化里的位置。LLM 应用的每一次改动（改 prompt、换模型、调参数），都可能影响质量，而且影响是非线性的，小改动可能引发大退化。
所以要有回归测试。每次改动，跑一遍黄金测试集，对比改动前后的质量分数。分数跌了就回滚或者修复，涨了才合并。这个「改动、测试、对比」的循环，是 LLM 应用质量管理的核心，和传统软件的 CI/CD 一个道理，只是测试方法不同。
渐进式上线的策略
图：三种渐进式上线策略——灰度发布控制影响范围，影子模式零风险验证，AB 测试用数据决策，核心都是降低上线风险。
LLM 应用不适合「大爆炸」式上线，风险太高。渐进式上线更稳。
灰度发布。先放给一小部分用户或者内部使用，收集反馈和数据，确认质量稳定再逐步扩大。这样即使有问题，影响范围也小。
影子模式。新版本和旧版本并行跑，但只返回旧版本的结果给用户，新版本的结果只做记录和对比。积累足够数据确认新版本更好之后，再切换。这种方式能在不影响用户的前提下验证新版本。
AB 测试。两个版本同时跑，各给一部分用户，对比真实指标（用户满意度、任务完成率等）。用数据决定哪个版本更好，而不是靠拍脑袋。
做 demo 的人很多，把 LLM 应用工程化到生产级的人不多。差距全在那些「枯燥」的工程细节上，可靠性、成本、延迟、可观测性、评估、上线策略。这些不性感，但决定了应用能不能真正用起来。这也是为什么有想法的团队很多，能把 LLM 应用做稳的团队很少，中间隔着的就是这道工程化的鸿沟。
一个认知的转变
从 demo 到生产，最需要的认知转变是，接受 LLM 的不确定性，并建立管理它的工程体系。
传统软件追求确定性，同样的输入必须同样的输出。LLM 应用做不到这点，它的输出天然有方差。工程化的目标不是消除这个方差（做不到），是把它管理在可接受的范围内，通过约束降低方差、通过兜底处理异常、通过监控发现问题、通过评估持续改进。
这需要一种新的工程思维，不再追求「完美无 bug」，而是追求「统计意义上的可靠」。这种思维转变，是从 demo 走向生产的关键。能完成这个转变的团队，才能把 LLM 的能力真正落地成可用的产品。
