外观
第 18 章 成本、性能与可观测性
先从一个很多工程师都感同身受的场景讲起。
一位充满激情的工程师，利用业余时间，做了一个非常酷的内部工具，一个“AI 代码评审助手”。工具内部是一条复杂的 Prompt 链，甚至还结合了 RAG 技术，能深度理解公司内部积累了多年的大量代码规范和架构最佳实践。
本地测试了一下，效果非常好。它给出的评论，质量接近一位在公司工作了十年的资深架构师，留在提交的 Pull Request (PR) 下面。这些评论不仅能发现一些低级的拼写错误和格式问题，甚至还能指出潜在的逻辑漏洞、并发风险和性能瓶颈。
工具的作者兴奋地把这个工具带到小范围的团队会议上，给 Leader 和几个同事做了个 Demo，把大家都镇住了。“这太牛了！”“简直是黑魔法！”“有了这个，我们的代码质量不是要起飞了？”……赞美声不绝于耳，工具的作者很是得意。
Leader 当场拍板：“这个工具太棒了！我们把它集成到公司的 CI/CD 流程里，让整个研发部门都用起来！”
工具的作者激动得一晚上没睡好，花了两天时间，把它打包成一个标准的服务，接入了公司的 GitLab CI。现在，每当有工程师提交一个新的 PR，这个 AI 助手就会自动运行，对代码进行分析，并把评审意见，以一个虚拟用户“Code Guardian”（代码守护者）的身份，评论在 PR 页面上。
问题很快接踵而来。
第一类问题是性能。一周后，技术支持的钉钉群里，开始出现此起彼伏的抱怨。 “最近的 CI 怎么这么慢？以前 5 分钟就能跑完，现在动不动就要 15 分钟！” “就是啊，我就改了一行文案，也要等一刻钟，太影响效率了！”
很快，有人通过分析 CI 日志，定位到了问题来源，就是那个新上线的、名叫“Code Guardian”的 AI 助手。因为它每次都需要调用好几次强大的 LLM API，处理大量的代码上下文，硬生生地把整个 CI 流程的时间，拉长到了原来的三倍。 大家的热情，迅速冷却。那个曾经顶着“黑魔法”称号的工具，现在成了大家口中“拖慢效率的累赘”。有人甚至在 PR 描述里写道：“@Admin，可以暂时禁用 Code Guardian 吗？它卡住我的发布了。”
第二类问题是成本。又过了一周，Leader 把工具的作者叫进了一间会议室，参会的还有部门的总监。总监的脸色，不太好看。 他指着投影上的云服务成本监控大盘说：“我们部门这个季度的‘实验性工具’预算，是 5000 元。你的这个代码评审助手，上线两周，已经花掉了 4800 元。能解释一下吗？”
看着那条陡峭上升的成本曲线，工具的作者这才意识到，为了追求最好的效果，工具里无脑地使用了最强大的 DeepSeek V4 Pro 模型。当只有一个 PR 时，成本微不足道。但当整个部门几百个工程师每天提交几百个 PR 时，每一次 CI 运行都在调用昂贵的 API，成本随调用量成倍增长，很快用完了所有的预算。
第三类问题是可观测性。正当工具的作者因为成本和性能问题焦头烂额时，一个同事在钉钉上发来消息：“@你，你的机器人好像出 bug 了。我写了一段 Go 代码，它给我的建议，居然是一段 Python 的语法。这完全不对啊。”
工具的作者想排查问题，打开了服务的日志，但里面除了最终那段错误的 Python 代码，什么有用的信息都没有。 在模型生成那段错误代码之前到底发生了什么，完全无从知晓。是拿到的代码上下文不完整？是链条里的某个 Prompt 环节出了问题？还是模型本身在那一刻突然“抽风”了？一无所知。 此时的排查没有任何线索可用，不知道问题在哪，只能靠“感觉”，在代码里不断加各种 print 语句，然后一次又一次地重新运行那个长达 15 分钟的 CI 流程，去复现那个偶尔才会出现的 bug。 这种调试体验非常低效。
这个故事，在今天的 AI 圈子里，几乎每时每刻都在上演。
它揭示了一个残酷的事实。在 LLM 应用的时代，成本、性能和可观测性，不再是传统软件开发中那种可以排在功能开发之后的“优化项”，从项目设计的第一天起，就是决定产品能否长期运行的基础条件。
一个不考虑这些工程问题的 AI 工程师，做得再快，交付的系统也很难在生产环境里长期稳定运行。
所以，这一章要系统地解决这三个“工程化”痛点：一是讲清楚成本怎么计算、怎么控制；二是讲清楚延迟怎么降下来；三是讲清楚怎么通过可观测性看清系统内部的运行状态，并在故障发生时保住可用性。
18.1 Token 成本的计算与控制
在 LLM 的世界里，Token，就是一切。
它既是与模型沟通的“语言单位”，也是向云服务商支付的“货币单位”。发送给模型的每一个字、每一个标点，模型返回的每一个字、每一个标点，背后都有明确的价格，都按 token 计费。
所以，Prompt 工程师不能只把自己当成“技术人员”，必须从第一天起就建立“成本意识”，对每一处 token 消耗都心中有数。这就是“Token 经济学”的思维模式。
成本计算与预测
在写任何一行 Prompt 之前，先要能准确回答一个问题。这套设计如果上线，平均处理一个用户请求，要花多少钱？
这个计算其实是一道简单的数学题，需要先弄清楚几个关键参数。首先是输入 Token 成本，也就是所使用的模型每 100 万个输入 token 的价格。这个价格，不同的模型、不同的服务商，差异巨大。海外闭源旗舰以美元计价，OpenAI 与 Anthropic 的最新旗舰闭源模型在 OpenRouter 聚合平台上的输入报价约 $2~$5 每百万 token（截至 2026 年 8 月，以 OpenRouter 当日报价为准）。
国产模型以人民币计价，在各自的开放平台上明码标价。DeepSeek 旗舰款输入约 9 元每百万 token（按官网定价页实时为准，含分时段计费）；MiniMax 旗舰款输入约 2 元级别每百万 token（按官网公示）；智谱 GLM、月之暗面 Kimi 的报价，同样在各自开放平台的定价页上一目了然；而一个开源的小模型，成本可能接近于零。
查海外模型的实时报价，OpenRouter 这类聚合平台是个好工具，同一家模型不同供应商的开价并排呈现；国产模型则直接以各家官方平台为准。模型价格随时间波动很快，下面这些数字也仅作为示意，请以调用时服务商官网上的最新报价为准。
紧接着是输出 Token 成本。通常输出 token 的价格比输入 token 更贵，差距能达到好几倍，因为生成输出需要模型做更复杂的推理计算。通常输出 token 单价是输入的 3~6 倍，以各厂商官网实时报价为准。
接下来是 Prompt 工程师最需要关注和控制的平均输入 Token 数，也就是应用在处理一个典型请求时，平均会向模型发送多少 token。这包括 System Prompt 的长度、Few-shot 示例的长度、RAG 系统检索回来的上下文的长度，以及用户输入的平均长度。最后是平均输出 Token 数，也就是应用平均会从模型那里接收到多少 token 的回复，这和任务设定以及在 Prompt 中对输出长度的约束有关。
那么，平均每个请求的成本，就是 (平均输入 Token 数 / 1000) 乘以输入 Token 成本，再加上 (平均输出 Token 数 / 1000) 乘以输出 Token 成本。
再来复盘那个“AI 代码评审助手”的账单。经过日志分析会发现，“不计成本”的 V1 版本，平均处理一个 PR，会发生这些事。Prompt 链条为了追求全面，会把 PR 涉及到的所有文件的完整内容，而不仅仅是变更部分（diff），都作为上下文。一个中等规模的 PR，可能涉及十几个文件，这一下，光代码上下文就轻松超过了 80000 tokens。RAG 系统为了找到最相关的规范，会检索出 10 篇长长的公司内部技术文档，加起来又是 16000 tokens。System Prompt 写得非常长，足足有 4000 tokens。最后，用的还是最贵的 DeepSeek V4 Pro。
来算一笔账。假设一个 PR 的总输入是 80000 + 16000 + 4000 = 100000 tokens，生成的评论有 1000 tokens。按高峰时段单价粗算（输入 9 元、输出 27 元每百万 token，先不考虑缓存），一个 PR 的成本就是：(100000 / 1000000) × 9 + (1000 / 1000000) × 27 = 0.9 + 0.027 ≈ 0.93 元。
看起来不多，一个 PR 九毛多钱。但是，公司有 500 个工程师，平均每人每天提交 1 个 PR，一天的成本就是 500 × 0.93 ≈ 465 元，两周（10 个工作日）就是约 4650 元。这个数字已经很接近那 4800 元的账单了（考虑到可能还有一些更复杂的 PR，成本更高）。
这个简单的计算，让人看清成本是怎样累积起来的。
所以，团队里必须建立一个成本预测模型。在设计任何一个新的 Prompt 功能时，都应先拿出计算器，或者写个小脚本，基于对典型场景的预估，估算一下这个功能上线后可能带来多大的成本压力。这个估算，是技术选型（比如继续用最贵的旗舰，还是换成 DeepSeek V4 Flash、通义千问 Qwen 这类更便宜的型号）、产品定价，以及向上级申请预算最重要的依据。
成本优化的四个方法
知道了成本是怎么算的，也就明白了在 LLM 应用里，“省钱”和“赚钱”同样重要。而省钱，同样需要精细的方法。
在前面的章节里，其实已经提到过很多降本的技巧，比如缓存和模型分级（田忌赛马）。这里再补充几个专门针对 Prompt 本身的精简技巧。
最直接的是Prompt 压缩。打开那些长长的 System Prompt，仔细读一遍，里面是不是充满了各种“车轱辘话”和不必要的客套？比如，“你是一个友好、乐于助人、知识渊博、世界一流的、由 XX 公司开发的 AI 助手...”。这些话对模型的表现，可能有一点点心理暗示的作用，但它们也在每一次 API 调用中，实实在在地消耗着 token 和经费。可以尝试用更简洁、更精炼、更像代码注释的语言重写指令，然后用评估集跑一下，看看在核心评估指标不显著下降的前提下，能把 Prompt 压缩到多短。
精简 Few-shot 示例也很重要。Few-shot 示例很管用，但它们也是 token 消耗的大户，尤其当示例本身就很长的时候。可以做个实验，试试从 5 个示例减少到 3 个，甚至只保留 1 个最经典、最能体现边界情况的示例，看看对效果的影响有多大。很多时候会发现，一个高质量的、精心挑选的示例，胜过五个随手写的、重复的示例。
上下文选择与压缩，是降本空间最大的方法。在 RAG 系统里，尤其如此。第 14、15 章讲的“重排序”和“上下文压缩”，不仅仅是性能优化的手段，更是成本优化的有力方法。只把最相关的、经过压缩和提炼的上下文喂给模型，输入 token 的数量可能从 10000 降低到 1000，成本直接下降一个数量级。
此外，还要严格控制输出长度。可以在 Prompt 里用非常明确的、不容商量的语气，要求模型把回答保持在一定的长度范围内。比如，“请用不超过 200 个汉字的篇幅，来回答这个问题。”或者，“你的回答，必须是一个少于 500 token 的 JSON 对象。”这不仅能节省输出 token 的成本，也能让答案更聚焦，在很多时候，反而能提升用户体验。
Token 经济学，是每个 Prompt 工程师的必修课。对 Token 的敏感度，直接决定了产品的商业可持续性。
18.2 降低延迟的三个方法
除了成本，另一个让工程师和用户都无法忍受的，就是延迟（Latency）。
在一个习惯了“秒开”“即时响应”的互联网时代，一个需要用户盯着加载动画、等待超过 3-5 秒的 AI 应用，基本上就已经失去了竞争力。用户会觉得产品“很卡”“很笨”，然后关掉它，去寻找竞争对手的产品。
LLM 应用的延迟，是由多个环节累加起来的。它的主要组成部分包括模型本身的计算时间，也就是从接收到请求到生成第一个 token 的时间（TTFT），以及之后每生成一个 token 所需的时间（TPOT）。模型越大，通常这两个时间就越长。此外，数据传输和处理时间也是一个重要因素，Prompt 越长，传输所需的时间就越长。在 RAG 系统里，还要加上从向量数据库检索数据、用重排序模型处理上下文等步骤的时间。
所以，优化性能，也要从这几个方面逐一入手。
Prompt 精简：同时降低成本与延迟
很多成本优化的技巧，同时也是性能优化的技巧，这并不让人意外，因为它们都指向一个共同的、朴素的目标，即减少需要处理的 token 数量。
发送给模型的 token 越少，网络传输就越快，模型需要处理的上下文就越短，TTFT 通常也会相应地缩短。要求模型生成的 token 越少，总的生成时间也就越短。
所以，上面提到的Prompt 压缩、精简 Few-shot 示例、上下文压缩、严格控制输出长度，这些技巧能同时改善成本和体验两个维度，既能让成本降下来，也能让用户体验更流畅。
流式输出（Streaming）：降低感知延迟
这是改善用户感知延迟最重要、也最有效的一个技巧。注意，这里说的是“感知延迟”，而不是“物理延迟”。
想象一个需要 10 秒才能生成完整答案的请求。在非流式模式下，用户点击“发送”后，看到的是一个长达 10 秒的加载动画。在这 10 秒里，用户不知道系统是不是卡死了，也不知道还要等多久。
而在流式模式下，用户点击“发送”后，几乎在 1-2 秒内，就能看到第一个字或第一个词出现在 AI 的对话框里。后续的文字，一个一个地、流畅地出现。虽然总的生成时间可能还是 10 秒，但用户的体验，会有明显差别。
在流式输出的模式下，用户从等待一个“未知”的结果，变成了“观看”一个正在进行的过程。这种“即时反馈”，这种“正在输入...”的感觉，极大地缓解了用户的等待焦虑，甚至会让用户觉得，这个 AI “反应很快”。
几乎所有主流的 LLM API，都支持流式输出的模式。后端需要处理一个 Server-Sent Events (SSE) 的数据流，这是一件需要一些异步编程技巧的活；前端需要用 JavaScript 来接收和渲染这个数据流。实现起来有一定的工程复杂度，但对于任何一个交互式的 AI 应用来说，这个投入都绝对值得。它是在物理延迟无法再压缩的情况下，提升用户体验的有效手段。
KV Cache 优化：前缀缓存的原理与用法
这是一个更底层、更偏向于模型推理本身的优化。工程师大概率不需要自己去实现它，但必须理解它的原理，因为它会影响技术选型和架构设计。
Transformer 模型在生成每一个新的 token 时，都需要依赖于它前面已经生成的所有 token 的信息。如果每生成一个新的 token，都要把前面所有的 token 重新计算一遍注意力，那计算量就太大了，生成速度会随着文本变长而越来越慢。
KV Cache，就是一种用来缓存这些“中间计算结果”的技术。简单来说，模型在处理完第一个 token 后，会把它的一些关键计算结果存起来。在生成第二个 token 时，它就不需要重新计算第一个 token 了，可以直接利用缓存的结果。以此类推。
这极大地加速了模型的生成过程。
这和 Prompt 工程有什么关系呢？关系在于，当需要让模型对同一个前缀（Prefix）进行多次不同的生成时，KV Cache 就能派上大用场了。
举个例子，假设有一个“AI 辅助写作”的功能。很长的 System Prompt 和用户已经写好的一段文章开头，构成了共同的“前缀”。现在，要让 AI 为用户提供三种不同的“续写”建议。
在没有 KV Cache 的情况下，需要调用三次 API，每一次都把那个长长的前缀发给模型，模型每一次都要重新处理一遍。而有了 KV Cache，可以先让模型处理一遍那个共同的前缀，并把它的 KV Cache 保存下来，再基于这个缓存，分别进行三次续写。这三次续写，就不再需要重复计算前缀的注意力了，速度会快得多。
目前，像 vLLM、TGI 这样的开源推理框架，都对 KV Cache 做了深度的优化。一些云服务商，也开始提供类似的功能。在进行技术选型，或者设计一些需要“多次生成”的复杂应用时，一定要把“是否支持 KV Cache 优化”，作为一个重要的考量因素。
18.3 看清系统内部发生了什么
成本和性能聊完了。现在来看工程上最棘手的问题，也就是调试。
一个传统的软件系统出了 bug，有一整套成熟的工具和方法：看日志、打断点、单步调试、内存快照... 工程师可以把系统的每一个部分都拆开来看，直到找到那个出错的地方。
但一个 LLM 应用，特别是那种由多个 Prompt 组成的链条，它更像一个“黑箱”。当它输出错误时，看到的只是一个最终的、错误的结果，很难知道这个错误，到底是哪个环节、哪个 Prompt、哪句指令导致的。
这种“不可知”和“无法解释”，会让工程师感觉对系统失去了控制。
可观测性（Observability），就是解决这种“不可知”的方法。它的目标，就是让人能清楚地看到，数据在系统内部，是如何一步一步地流转、处理和变化的。
一个好的 LLM 应用可观测性系统，至少应该做到以下几点。
监控（Monitoring）：全局状态总览
这是最基础的，也是第一道防线。需要一个监控大盘（Dashboard），来实时地、宏观地看到整个系统的“健康状况”。这个大盘上，至少应该有请求量、Token 消耗、端到端延迟和失败率这几个关键的图表。
这个大盘，能在系统出现失败率激增、延迟飙升等重大异常时，第一时间发现。像 Datadog、Prometheus、Grafana 这些传统的监控工具，都可以用来构建这个大盘。
追踪与调试：定位每一步的输入输出
宏观的监控，只能说明“出事了”，但不能说明“哪里出事了”，以及“为什么出事了”。要定位到根本原因，需要更细粒度的工具，也就是分布式追踪（Distributed Tracing）。
它的思想是，为每一个进入系统的请求，都分配一个唯一的 trace_id。然后，当这个请求，在系统内部，流经不同的服务、不同的函数、不同的 Prompt 链环节时，都把这个环节的详细信息，连同这个 trace_id，一起记录下来。
这样，通过一个 trace_id，就能把一个请求在系统内部的完整生命周期，都串起来，形成一个清晰的、可视化的、可交互的调用链。
有了这样一条清晰的调用链，当一个请求出错时，排查就有了明确的方向。如果最终答案是错的，可以回溯到检索环节，看看是不是检索回来的文档，从一开始就是错的。如果系统延迟很高，可以清楚地看到，是哪个环节耗费了最多的时间，应该重点优化哪个环节。如果查询重写环节的输出，就已经偏离了用户的意图，那说明“查询重写”这个 Prompt，需要优先修复。
像 LangSmith、Langfuse 这样的工具，就是专门为构建这种 LLM 应用的可观测性系统而生的。Arize Phoenix 也是开源可观测性方案的常见选择，主打 OpenTelemetry 兼容与本地部署。Helicone 是另一常见选择（注：以 2026 年中后续维护状况为准，必要时查官方仓库的近期 commit），而 OpenTelemetry 是 CNCF 旗下的通用可观测性标准，也广泛用于为 LLM 应用采集追踪数据。把它们集成到应用里，可能需要一些前期的工作量，但一旦建成，它节省下来的、用于调试的时间，将是不可估量的。它能把调试效率，从“小时级”，提升到“分钟级”。
18.4 Prompt 脆弱性与模型漂移
还有一类更隐蔽、也更让人头疼的不稳定问题。
工程师大概都有过这样的经历。一个 Prompt，昨天在本地环境测试得好好的，效果完美。结果今天，一个字都没改，再用同样的输入去跑，它输出的结果，就变得乱七八糟了。
或者，一个 Prompt，在线上稳定运行了三个月，一直表现良好。结果某一天，它的错误率，突然开始莫名其妙地、持续地、缓慢地上升。查了半天，代码、Prompt，都没有任何变更。
看上去就像遇到了无法解释的异常，甚至会让人怀疑是不是基础设施出了问题。
这几乎就是 LLM 应用版本的墨菲定律。任何可能出错的地方，都一定会出错，而且通常是在最意想不到的时候，以最意想不到的方式。
这种现象，背后有两个主要原因，即Prompt 的脆弱性（Brittleness）和模型漂移（Model Drift）。
Prompt 的脆弱性：输出对微小改动高度敏感
Prompt 的脆弱性，指的是模型的输出，对于 Prompt 中一些微小的、看似无关紧要的改动，表现出极度的、不成比例的敏感性。
工程师可能只是把“请总结以下文本”，改成了“请为以下文本，生成一个摘要”，结果模型的输出风格，就从“严肃、书面”，变成了“活泼、口语”。
也可能只是在 Prompt 的末尾，多加了一个换行符，或者把 XML 标签，从 <tag> 换成了 [tag]，结果它输出的 JSON 格式，就莫名其妙地错了。
这种脆弱性，源于大模型本身的“黑箱”特性。至今也无法完全理解，Prompt 中的每一个词、每一个符号，到底是如何影响模型内部那几千亿个参数的复杂交互的，只能通过大量的实验，去摸索一些“经验性”的、有时候甚至有点“迷信”的规律。
要应对这种敏感性，第一道防线是严格的版本控制，把 Prompt 像代码一样纳入 Git 进行管理，任何修改都必须通过 Pull Request，并附上清晰的修改理由。此外，全面的自动化回归测试至关重要，它能在任何可能“破坏”原有功能的修改发生时，第一时间告警。最后，对于任何重要的 Prompt 修改，都不要直接全量上线，而是用 A/B 测试去小流量地验证它的真实影响。
模型漂移：模型版本静默更新
模型漂移，则是一个影响范围更大、也更不可控的问题。
通过 API 调用的那些商业大模型，它们并不是一成不变的。模型提供商为了修复 bug、提升性能、对齐价值观，会定期地对这些模型进行更新。
有时候，这些更新是明确告知的，比如发布一个带日期的新版本。但更多时候，这些更新是“静默”的。调用的那个别名，它背后指向的真实模型，可能在一夜之间就变了。
这种变化，大部分时候是好的。但有时候，它也可能会导致一些意想不到的“能力退化”。比如，一个新版本，可能在代码生成能力上变强了，但在遵循复杂格式指令的能力上，却变弱了。
这就意味着，那个在线上稳定运行了半年的、完美适配了旧版模型的 Prompt，在新版模型上线的那一刻，可能就突然“失灵”了。
也就是说，Prompt 与模型版本之间的适配，会在无人知情的情况下悄悄失效。
要应对模型漂移，首先要锁定模型版本，在 API 调用中，尽可能地使用明确的、带日期的模型版本号，而不是那个会随时变化的“最新版”别名。其次，建立模型能力退化检测流水线，定期用核心评估数据集，去测试模型提供商发布的最新模型版本，并与当前线上使用的旧版模型进行对比。然后，设置告警，如果发现新版模型在任何一个核心指标上出现了显著的“能力退化”，就立刻向团队发出告警。最后，主动适配与计划性迁移，当决定要升级到一个新的模型版本时，必须把它当成一次重大的项目变更，用全套的评估体系去完整地重新验证所有的核心 Prompt。
模型漂移，是所有 LLM 应用工程师，都必须面对的一个永恒的挑战。漂移本身无法阻止，但一套完善的监控和适配流程，能把被动变成主动，最大程度地降低它对业务的冲击。
18.5 API 不可用时的容灾与降级
成本、性能、可观测性都聊过了。最后来看那个谁都不希望发生、但又必须提前准备的情况，也就是灾难恢复。
依赖的 LLM API 服务，不是 100% 可靠的。它可能会因为服务商的机房着火、海底光缆挖断了，或者碰上了大规模的 DDoS 攻击，而突然变得不可用，或者延迟急剧飙升。
如果整个业务，都强依赖于这个单一的、外部的 API，那么，当它不可用时，产品也就跟着无法正常服务了，用户看到的将是接连的错误提示。
一个成熟的、生产级的系统，必须有容灾（Disaster Recovery）和降级（Degradation）策略。工程师要总是做最坏打算，提前想好，在最坏的情况下，备用方案是什么。
容灾：模型故障切换（Model Failover）
模型故障切换（Model Failover） 是最理想，也是最复杂的容灾方案。可以考虑，在系统中同时集成多家不同云服务商的 LLM API。比如，主模型用的是 GPT-5.4，可以把另一家厂商的旗舰，或者 DeepSeek、通义千问 Qwen 这类国产模型中的旗舰或性价比款，作为备用模型。
在代码里，需要实现一个“健康检查”和“自动切换”的逻辑。可以用一个断路器（Circuit Breaker）模式，来监控对主模型 API 的调用。当一段时间内连续几次调用主模型 API 都收到了超时或 5xx 服务器错误，断路器就“跳闸”了，自动地把后续的所有请求都切换到备用模型上。同时，它会定期地去“探测”一下主模型是否恢复，一旦恢复，再自动地切回来。
当然，这里面最大的挑战是，不同的模型，它们的 API 接口、能力，甚至对 Prompt 的偏好，都可能不一样。需要提前做好适配和测试，确保核心 Prompt 在备用模型上，也能有一个“可以接受的”表现。
降级：规则兜底与功能降级
有时候，问题不是 API 完全不可用，而是变得极度缓慢。这时，为了保证核心业务的可用性，可能需要主动“降级”AI 功能。
一种方法是规则兜底（Rule-based Fallback）。对于一些关键的、有确定性逻辑的业务，可以准备一套传统的、基于规则的“兜底”方案。比如，在“内容审核”系统里，当 LLM API 的延迟超过了设定的阈值时，系统可以不再等待模型的智能判断，而是自动降级，只使用一套非常严格的、基于“关键词黑名单”的规则来进行最基础的审核。这种降级，可能会导致一些“误杀”，但它保证了内容发布流程不会因为 AI 的缓慢而完全卡住。
另一种方法是功能降级。对于一些非核心的增强型 AI 功能，甚至可以在监控到上游服务不稳时，直接在前端把这个功能的入口暂时灰掉，并给用户一个友好的提示：“AI 服务当前繁忙，请稍后再试。”
容灾和降级，体现的是一种“底线思维”。它要求工程师，永远不要对任何外部依赖，抱有 100% 的信任，永远要为最坏的情况，准备好备用方案。
本章总结 四项工程能力
这一章聊的，都是些不讨喜的话题。没有酷炫的算法，没有新奇的技巧，有的只是成本、延迟、监控、日志、故障切换这些听起来有点“枯燥”的工程概念。
但这恰恰是 Prompt 工程，从个人摸索，走向成熟的工程化生产，所必须经历的、最重要的一步。
一个只会写 Prompt 的人，只能算一个提示词的调试者。他靠个人经验和反复试错来调优，追求的是效果最好的那一个版本。
而一个既懂得调 Prompt，又懂得设计一套能大规模、低成本、稳定运行的系统，并且为这套系统配上完整的监控、告警和应急预案的人，才是一个真正的工程师。
这一章聊的 Token 经济学、性能优化策略、可观测性体系，以及容灾降级方案，就是从会调 Prompt，到能交付生产级系统，所必须掌握的、最核心的工程素养。
成本意识，决定做出来的东西不仅技术上可行，更能在商业上长期运转；性能意识，决定产品不仅智能，用户用起来也不觉得慢；可观测性，让人能看清系统的内部状态，而不是出了问题只能盲猜；可靠性意识，让系统在故障发生时仍能保住核心功能。这四样东西，缺一不可，它们共同构成了一套能让系统在真实世界里长期运转的基础设施。
掌握了这些，交付的就不再是一个脆弱的、充满了不确定性的“AI 功能”，而是一个稳健的、可信赖的、真正能在生产环境中，为千万用户创造价值的“AI 系统”。
这，才是“工程”二字的真正含义。
参考资料
- DeepSeek. 模型 & 价格（官方定价页）. https://api-docs.deepseek.com/zh-cn/quick_start/pricing/
- NVIDIA. Metrics（NIM LLM Benchmarking 文档，TTFT 与逐 token 延迟的定义）. https://docs.nvidia.com/nim/benchmarking/llm/latest/metrics.html
- vLLM. Benchmark CLI（官方基准文档，输出指标含 Mean TTFT 与 Mean TPOT）. https://docs.vllm.ai/en/latest/benchmarking/cli/
- OpenAI. Streaming API responses（stream=true 时经 server-sent events 返回增量内容）. https://developers.openai.com/api/docs/guides/streaming-responses
- Kwon W, Li Z, Zhuang S, Sheng Y, Zheng L, Yu C H, Gonzalez J E, Zhang H, Stoica I. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP 2023. arXiv:2309.06180. https://arxiv.org/abs/2309.06180
- vLLM 项目. 官方博客发布公告（PagedAttention 与 vLLM 首次发布）. https://vllm.ai/blog/2023-06-20-vllm
- Hugging Face. Text Generation Inference 文档之 PagedAttention 概念页. https://huggingface.co/docs/text-generation-inference/en/conceptual/paged_attention
- Prometheus. 官网（自述为开源监控系统与时序数据库）. https://prometheus.io/
- LangChain. Announcing LangSmith. https://www.langchain.com/blog/announcing-langsmith
- Helicone. GitHub 仓库 helicone/helicone（开源 LLM 可观测性平台）. https://github.com/helicone/helicone
- OpenRouter. 模型报价聚合平台. https://openrouter.ai/
- MiniMax. 按量计费定价（官方文档）. https://platform.minimaxi.com/docs/guides/pricing-paygo
- OpenTelemetry. What is OpenTelemetry?（官方文档，自述为开源、厂商中立的通用可观测性框架）. https://opentelemetry.io/docs/what-is-opentelemetry/
- Microsoft. Circuit Breaker pattern（Azure Architecture Center 云设计模式，含闭路、开路、半开三态）. https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker
- Arize. Phoenix 文档（官方：开源、OpenTelemetry/OpenInference 兼容的 LLM 可观测性与评估平台）. https://arize.com/docs/phoenix/