大多数基于 LLM 构建产品的团队都多付了 60%–90% 的费用。这并不是因为他们使用了错误的模型或提示词效率低下，而是因为他们在每次请求中都在重复处理相同的 Token。提示词缓存（Prompt caching）可以解决这个问题，且只需大约 10 分钟即可实现。然而，它仍然是生产级 LLM 系统中利用率最低的优化手段之一。
实际情况是：每次你向 LLM API 发送请求时，模型都会对提示词中的每一个 Token 运行注意力机制（Attention）。如果你的系统提示词（System prompt）有 10,000 个 Token，且每天处理 1,000 个请求，那么你每天仅为提示词中的静态部分（即永不变化的上下文）就要支付 1,000 万个 Token 的处理费用。提示词缓存会存储中间计算结果（即 Key-Value 注意力状态），以便后续请求可以完全跳过这部分工作。
大多数团队都会遇到同样的拐点：LLM API 成本的增长速度超过了使用量的增长，而且每一个查询——无论是“总结这句话”还是“审计这个 2,000 行的代码库以查找安全漏洞”——都指向同一个昂贵的模型。解决方法不是挤压 prompt，而是路由。
LLM 路由意味着将每个请求引导至最适合该特定任务的模型。不是能力最强的模型，而是正确的模型——在成本、延迟和质量之间平衡，以满足查询的实际需求。如果做得好，路由可以在质量几乎不下降的情况下将 LLM 成本降低 50–85%。如果做得不好，它会产生隐性的质量倒退，直到用户流失你才会察觉。
这篇文章涵盖了其机制、权衡以及在生产环境中实际会出问题的地方。
大多数团队发现他们上下文管理问题的方式都如出一辙：一个在演示中表现良好的生产级智能体，在对话进行 15 轮后开始出现幻觉。日志显示 JSON 格式正确，模型返回了 200 状态码，且没有人修改代码。变化的是累积效应——工具结果、检索到的文档和对话历史悄无声息地填满了上下文窗口，直到模型需要在 80,000 个相关性参差不齐的 Token 上进行推理。
上下文溢出（Context overflow）是显而易见的故障模式，但“上下文腐化”（context rot）则更具隐蔽性。研究表明，在达到限制之前，LLM 的性能就已经开始下降。随着上下文的增加，模型会出现“中间迷失”效应（lost-in-the-middle effect）：注意力集中在输入的开头和结尾，而中间的内容则变得不可靠。埋藏在 30 轮对话中第 12 轮的指令可能会实际上消失。模型不会报错——它只是悄悄地忽略了它们。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
