#为什么 AI 应用很贵

很多团队第一次做 AI 功能时，会把它理解成“调用一个接口”。

前端发起请求，后端拼 prompt，模型返回结果。Demo 很快，效果也很惊艳。但一旦进入真实产品，账单和延迟会一起出现：用户越活跃，成本越高；上下文越丰富，响应越慢；功能越智能，链路越复杂。

AI 应用贵，不只是因为模型 API 单价高。更准确地说，AI 应用把“每一次用户交互”变成了一次有明显边际成本的计算任务。它可能包含长上下文、检索、工具调用、多次模型请求、日志存储、队列重试和人工审核。

对前端和全栈工程师来说，理解成本结构不是财务问题，而是架构问题。你设计的输入框、上下文注入、Streaming、重试按钮、历史记录、文件上传和自动执行流程，都会直接影响一次请求要花多少钱、等多久、失败后怎么恢复。

#贵在哪里

一次 AI 请求的成本通常不是单点成本，而是一条链路的总和。

最明显的是模型推理成本。大多数大模型 API 按输入 token 和输出 token 计费。你发给模型的 system prompt、历史对话、用户输入、检索片段、工具定义、页面状态和输出格式说明，都会变成输入 token。模型生成的回答、JSON、代码、工具调用参数，都会变成输出 token。

其次是上下文成本。AI 应用为了“更懂用户”，往往会注入更多信息：当前页面数据、用户资料、文档内容、知识库片段、业务规则、权限说明、多轮聊天历史。上下文越多，请求越贵，也越慢，还可能带来更多干扰。

第三是多步链路成本。一个看起来简单的“帮我处理一下”背后，可能先调用模型分类，再检索知识库，再调用工具查数据，再调用模型生成答案，最后再调用模型做安全检查或格式修复。用户只点了一次按钮，系统已经跑了多次模型和外部服务。

第四是基础设施成本。向量数据库、对象存储、任务队列、日志系统、trace、缓存、评估、监控、告警、后台任务和失败重试，都会进入总成本。它们不一定像模型账单那样刺眼，但会决定系统能不能稳定运营。

最后是工程和质量成本。AI 输出不稳定，需要 Eval、人工抽检、灰度发布、Prompt 版本管理、错误回放和线上反馈闭环。越是生产级 AI 功能，越不能只看“单次模型调用价格”。

这张图的重点是：AI 成本不是“模型”一个节点，而是整条请求路径的结果。

#Token 只是开始

Token 成本最容易理解，但也最容易被简化。

很多人会先算模型单价，然后估算一次请求大概要多少 token。这是必要的，但不够。真实系统里，token 用量会被产品设计快速放大。

例如，聊天应用会保留历史消息。用户越聊越久，每次请求带的历史越多。如果没有摘要、裁剪和窗口管理，成本会随着会话长度上升。

文档问答会注入检索片段。召回越多，模型看到的信息越多，但不相关片段也越多。如果检索没有重排、去重和压缩，成本会被“保险起见多塞一点”拖高。

Agent 或 Workflow 会产生中间步骤。每一步都可能有输入和输出。一个任务如果拆成 6 次模型调用，单次 token 再少，总成本也可能很高。

结构化输出也会增加成本。为了得到稳定 JSON，系统常常需要 schema、字段说明、示例、约束和失败修复。这些内容都在上下文里。

所以 token 成本不是用户输入长度决定的，而是系统为完成任务携带了多少上下文、生成了多少内容、执行了多少步骤决定的。

#延迟也是成本

AI 应用的“贵”还包括等待成本。

用户等待模型生成时，前端连接会保持打开，服务端资源会被占用，队列会积压，重试会增加，用户可能重复点击，客服和运营也会收到更多反馈。慢请求不只是体验问题，也会放大基础设施压力。

AI 延迟通常可以拆成几段：

前端最直接感知的是 TTFT，也就是 Time To First Token。Streaming 可以显著改善感知速度，因为用户不必等完整结果生成完才看到反馈。但 Streaming 不会自动减少总成本，它只是把等待过程变得可见、可中断、可承受。

如果一个功能本身很贵，单纯加 Streaming 只是让用户更早看到昂贵任务开始执行。真正的优化还需要控制上下文、模型选择、缓存命中和输出长度。

#路由为什么影响账单

不是所有请求都值得使用最强模型。

AI 应用常见任务可以分成不同层级：意图识别、分类、标题生成、摘要、改写、复杂推理、代码生成、长文档分析、视觉理解、工具规划。它们对模型能力、延迟和成本的要求不同。

如果所有任务都走同一个大模型，架构最简单，但成本会被大量低难度请求抬高。

更合理的方式是做模型路由：

路由不只是省钱，它还影响延迟和可靠性。

便宜快模型适合高频、低风险、可校验任务。强模型适合少量、高价值、复杂任务。本地模型适合隐私敏感、离线、边缘或成本可预测场景。模型 API 适合能力要求高、上下文长、需要持续升级的场景。

但路由也有成本。你需要维护任务分类、模型能力矩阵、fallback 策略、质量评估和日志口径。没有 Eval 的模型路由，很容易变成“看起来省钱，实际质量退化”。

#缓存为什么不是万能解

缓存是 AI 成本优化里最诱人的词，因为命中缓存几乎意味着省掉模型调用。

但 AI 缓存比普通 Web 缓存更难。

普通接口通常有清晰的 URL、参数和失效条件。AI 请求则包含 prompt、历史、用户身份、权限、检索结果、模型版本、输出格式、温度参数和业务状态。任何一个字段变化，都可能影响结果。

常见缓存类型包括：

缓存的核心不是“能不能存”，而是“什么情况下可以复用”。

例如，公开文档的 FAQ 可以缓存完整回答；带用户权限的企业知识库更适合缓存检索中间结果，但最终回答要重新生成；实时库存、价格、订单状态则只能短 TTL 或不缓存。

对前端来说，缓存还会改变体验设计。你可能需要展示“刚刚生成”或“基于缓存结果”，也可能需要提供刷新入口。对于创作类功能，缓存命中如果让用户觉得结果重复，反而会降低体验。

#贵的常见坑

第一个坑，是把所有历史原样塞进请求。

多轮对话不是聊天记录越完整越好。长历史会增加成本、拖慢首 token，还可能让旧上下文干扰当前任务。更好的做法是保留近期关键轮次，对长期记忆做摘要或结构化存储。

第二个坑，是检索片段越多越安心。

RAG 很容易变成“召回 20 段全部塞给模型”。这会让输入 token 飙升，也会引入无关内容。检索应该有重排、去重、片段预算和引用约束。

第三个坑，是工具定义常驻。

如果每次请求都把几十个工具 schema 发给模型，即使本次任务只需要一个工具，成本也会很高。工具应该按场景暴露，或者先做意图识别再注入候选工具。

第四个坑，是失败后无脑重试。

AI 请求失败可能来自限流、超时、格式错误、内容安全、供应商故障。不同错误应该有不同策略。无脑重试会放大成本，也可能让用户收到多个不一致结果。

第五个坑，是只看平均成本。

平均值会掩盖长尾。真正危险的是少数超长文档、少数重度用户、少数 Agent 循环、少数失败重试。成本监控必须按功能、租户、用户、模型、prompt 版本和 token 分布拆开看。

第六个坑，是前端没有中断能力。

如果用户发现方向不对却不能停止生成，模型会继续产生输出 token。停止生成不只是体验功能，也是成本控制按钮。

#应该观测什么

如果没有数据，成本优化只能靠猜。

每次 AI 请求至少应该记录：

• feature：哪个功能触发。
• user id 和 tenant id：谁在使用。
• model 和 provider：用了哪个模型。
• prompt version：是哪版 prompt。
• input tokens 和 output tokens：输入输出规模。
• estimated cost：估算成本。
• TTFT 和 total latency：首 token 和总耗时。
• cache status：是否命中缓存。
• route decision：为什么选这个模型。
• retry count 和 fallback：是否重试或降级。
• status 和 error code：结果状态。

这些字段最好统一由 AI Gateway 或模型调用层记录，而不是散落在各个业务接口里。否则你很快会遇到口径不一致的问题：有的接口记录 token，有的只记录耗时，有的没有 prompt 版本，有的没有租户信息。

#小结

AI 应用很贵，是因为它把上下文、推理、生成、工具、检索和可靠性都放进了一次用户交互里。

成本不是单纯的模型单价问题。输入 token、输出 token、长上下文、多步调用、延迟、重试、缓存失效、工具调用、日志和评估都会进入总账。

工程上最重要的转变是：把 AI 请求当成有预算的任务来设计。前端要提供可中断、可解释、可降级的体验；后端要有路由、缓存、限流、观测和成本归因；团队要用 Eval 确认每一次省钱没有把质量悄悄省掉。