AI账单吃不消了？5个工具让你立马省钱

AI 账单冲击波像一场缓慢移动的飓风，已在全行业蔓延。除了大语言模型（LLM）成本飙升之外，更深层的架构问题是归因：钱到底花到哪儿去了，它到底为业务创造了什么价值？

当 API 调用被一层层自动化智能体和提示模板包裹起来时，你的应用就变成了一个消耗资本来生成 token 的黑箱。如果某个功能引擎每月仅仅为了让 LLM 输出几句客套话、或处理低价值数据，就烧掉数千美元，那不是创新，那是一个没盖盖子的下水道口，一处赤裸裸的负债。架构成熟度意味着把 token 当作任何其他受限资源来对待。

幸运的是，我们手头有几根好用的杠杆可以控制 AI 支出。以下是驯服这头猛兽的五件关键工具。

模型路由

能用图钉解决的事，别上射钉枪。

像最新的 Claude Opus 这样最强大的模型，是有史以来最精密的软件系统之一。它们能处理极其复杂、微妙的用例。但当涉及算力消耗时，它们也是贪得无厌的巨兽。它们常常是大材小用。

在原型开发、勾勒 API 和需求时，我们自然会先用手上最强大的模型。那是因为我们处在“先让它跑起来”的模式，不想被模型能力的局限绊住。但到了生产环境，绝对有必要把模型选型收敛到我们能用的最不强大的那一个。

有时我们可以通过调整模型选择、手动摸索出什么可行来解决。但在更大型的企业架构中，我们可以转向条件路由层。RouteLLM 或 Semantic Router 之类的框架，能把简单的分类、基础文本解析和用户意图识别动态地分流给又快又便宜的工具型模型，比如 GPT-4o mini 或 Claude 3 Haiku。

你也可以用高级 AI 网关来做路由和支出分配。在基础设施层面，把这套逻辑包进一个专用的 AI API 网关（如 Kong、Cloudflare AI Gateway 或 Portkey），能给你终极的控制力。一个成熟的网关让你可以实现“级联路由”：当主 LLM 碰到速率限制或延迟飙升时，自动回退到更便宜或开源的模型。更重要的是，AI API 网关把遥测数据集中起来，剥掉黑箱，让你能对每个租户或每个微服务强制执行硬性 token 预算。你本质上是在为认知任务构建一个负载均衡器。

当然，AI 网关自身也会引入复杂性和成本，这些因素必须纳入权衡。但归根结底，你的项目总有一个尺寸合适的模型。把请求路由到一个“够用就好”的金发姑娘模型，能帮你省下一大笔钱。

顺带一提：模型路由的另一股趋势是“算力回流”。这指的是在本地硬件上运行模型（通常是开源模型），而不是在云端租用生成式 AI 端点。这意味着所有本地部署选项的权衡与收益。

语义缓存

在传统 Web 应用中，缓存是一个已经解决的问题。你把 Redis 放在数据库前面，把一次精确查询映射到一份缓存好的负载，就完事了。但 LLM 打破了传统缓存，因为人类语言是无限可变的。“我该怎么重置密码？”和“我忘了登录信息”，是完全不同的字符串，却表达了完全相同的意图。

如果你依赖过度精确的匹配，命中率实际上会趋近于零，而每一种措辞变体你都要按完整 token 价格付费。

于是语义缓存登场了。它就像“用于含义的正则表达式”。你不去对原始文本字符串做哈希，而是先把进来的提示跑过一个快速的嵌入模型，再与此前回答过的提示做相似度检索。你设定一个置信度阈值（比如 0.92），一旦达到，就直接返回缓存响应（完全绕开 LLM 及其成本）。

其架构效果有两重。第一，一次语义缓存命中，把该查询的推理成本降到恰好为零。第二，它把响应延迟从秒级降到毫秒级。你可以用专门的框架如 GPTCache 来实现，或者，如果你偏好更精简的基础设施，可以在现有的 PostgreSQL 数据库里用 pgvector 来存储和匹配嵌入。

不过，和动态路由一样，语义缓存要求严谨的架构权衡。你是用生成成本去换嵌入和查询成本。要查缓存，你仍然得对提示做分词、调用一个便宜模型（如 text-embedding-3-small），并执行一次向量检索。

你还引入了非常真实的“语义扁平化”风险。调节相似度阈值是一门精细的手艺。调得太低，你的应用就会开始拿泛泛的、循环利用的答案去应付用户的细微问题。对于开放式、创造性的生成式 AI 应用，语义缓存几乎毫无用处。但对于检索增强生成（RAG）实现、客服机器人，以及用户会用上千种不同问法问同样 20 个问题的内部知识库，它是你能拉动的最有效的降本杠杆。

提示缓存

语义缓存存储的是某个意图对应的回答，而提示缓存存储的是为问题提供上下文所需的数据。当用户输入提示时，它被发送到生成式 AI 端点。但你的应用不必反复去收集并发送构建该提示所需的海量上下文信息——那些来自 RAG 流水线、数据库或其他来源的信息——因为这些信息已经预先加载在上下文缓存中。模型只需把这个新问题套用到缓存数据上，从而同时砍掉你的延迟和输入成本。

提示缓存背后的核心理念是：AI 引擎本身为进来的提示保留相关的上下文数据。以这种方式缓存的 token，相比原始输入 token 能拿到大幅折扣（50% 到 90%）。但具体如何处理，各家供应商并不相同。

对 OpenAI 而言，提示缓存是自动的，但需要留意你的应用如何使用端点，才能利用上它。OpenAI 强制执行 1024 token 的最低门槛。更重要的是，它要求从第 0 个 token 开始精确到字节的逐字节前缀匹配。如果你在系统指令最顶端注入一个动态变量（比如时间戳或用户 ID），你就会立刻让缓存失效，并为后续每一个 token 支付全价。

其他一些供应商，如 Anthropic Claude 和 Google Gemini，使用的是显式缓存。你必须刻意把缓存设计进你的架构，要么命中一个专用 API 端点，上传静态文档（上下文数据）并设定生存时间，要么在 JSON 负载中注入严格的缓存控制断点。显式缓存往往需要预先支付一笔“写入溢价”，但它给你控制力，保证你沉重的 RAG 数据能在内存里存活数小时而非数分钟。

提示词的纪律

一个模型“能够”吃掉海量 token，并不意味着它“应该”。

如今模型已能在单次提示中吞下 100 万到 200 万 token，于是有一种诱惑：把整份 PDF、整个代码库，或者过去三年的日志一股脑塞进负载，让 LLM 自己去理清，用蛮力把用例压服。

这是 finops 上的重大失误。你发送的每一个 token 都要付费。而且，从工程角度看，把上下文窗口塞满会撞上非常真实的“中间迷失”问题（又称“上下文腐化”），模型会失去对内容中段的解析力。随着负载增长，性能和准确率都会受损。

解药是严格的 RAG 节食。幼稚的 RAG 实现可能会从向量数据库里拉出前 20 条结果，盲目拼接进提示。架构成熟度要求在那些 token 抵达昂贵的 LLM 之前，先进行更不留情面的过滤。

这正是重排序（reranking）变得关键的地方。重排序接收编制好的提示上下文，确保它在抵达 LLM 之前被高效地组织好。你不把原始搜索结果直接送给主模型，而是先引入一个极小、极高效的交叉编码器（如 Cohere Rerank 或开源的 BGE 模型）。你在便宜的向量数据库里撒一张大网，取回 50 个潜在匹配，再把它们交给重排序器，针对用户的具体提示给它们的真实相关性打分。重排序器无情地削去肥肉，让你只把最相关的前三四个片段送给昂贵的前沿模型。

你是用一个庞大、昂贵的 LLM 上下文负载，换一个微小、廉价的重排序步骤。这里的架构算术，几乎总是一笔响亮的胜利。虽然交叉编码器可能给流水线增加 100 毫秒延迟，但它通常能把提示 token 数砍掉 80% 甚至更多，同时提升最终生成结果的准确性。在生成式 AI 支出这本兵法里，让你的 LLM 少读一点，是你能做出的杠杆率最高的动作之一。

限制响应

默认情况下，LLM 礼貌、健谈、啰嗦。如果你向一个 API 要数据，它会迫不及待地以“当然！这是您请求的 JSON”开头，再以“如需其他帮助请告诉我！”结尾。

在网页界面里，这很讨喜。在一个应用的 API 架构里，这是 finops 船体上的一个漏洞。生成 token（输出）的定价几乎普遍比提示 token（输入）贵 3 到 5 倍。每一句客套话，都在燃烧你最昂贵的商品。

驯服 LLM 的响应，需要在 API 层面严格强制。第一，max_tokens 必须被当作硬性断路器来防止失控的生成循环，而不是一个格式化工具。（指望用 max_tokens 来缩短答案，往往只会得到被截断、无法解析的 JSON。）第二，使用停止序列（stop sequences）。如果你的模型只需要输出一条 SQL 查询，为 markdown 结束标记（三个反引号）或“Explanation:”这个词设置停止序列，就会迫使模型在计算工作一完成就立刻切断连接。

现代 API 还提供结构化输出（或严格 JSON 模式），强制模型遵循你定义的刚性模式。把它与零容忍的系统提示结合起来（“只输出合法 JSON。省略所有对话性文字和客套话。做不到就会破坏系统”），你就能迫使 LLM 表现得像一个传统的 API 端点，而不是一个聊天机器人。

这里的架构平衡在于：不要因为严格限制输入而损害模型的推理能力。LLM 没有内部工作记忆，它通过迭代输出 token 来“思考”。如果你强迫一个模型去解决复杂的逻辑问题，却不让它有推理的余地、只输出单个布尔值 true 或 false，它的准确率会骤降。finops 的目标其实不是强制把字数压到最少，而是确保每一个昂贵的输出 token 都在做真正的计算工作（比如思维链推理）。

如何有效地消费生成式 AI 以满足用户需求，是第一场战役。第二场，是别让财务问题侵蚀掉这些艰苦的工作。这里讨论的五把钥匙，应当能给你足够的掌控力，确保工程与成本控制协同运作。