#为什么 AI 应用必须关注 Token 成本

传统 Web 应用当然也有成本：服务器、数据库、CDN、存储、日志、第三方服务。但大多数前端功能的边际成本并不明显。用户多点一次按钮，通常不会让你立刻感到一次“按字计费”的消耗。

AI 应用不同。

很多 LLM API 的成本直接和 Token 数相关。你传给模型的内容越多，模型生成的内容越多，费用越高。更关键的是，Token 成本通常和用户体验强绑定：多轮对话越长、检索上下文越多、输出越详细、工具越复杂，请求就越贵、越慢、越难控。

所以 AI 应用必须从第一天就关注 Token 成本。它不是财务月底才看的账单，而是产品设计、前端交互、后端架构和模型策略共同决定的工程结果。

#Token 成本到底从哪里来

一次模型调用的成本通常来自输入 Token 和输出 Token。

输入 Token 包括应用发给模型的所有上下文：

• 系统提示词。
• 用户当前消息。
• 历史对话。
• 页面状态。
• 用户资料。
• 检索片段。
• 工具定义。
• 工具返回结果。
• 输出格式约束。
• 示例和模板。

输出 Token 是模型生成的回答、JSON、代码、摘要或工具调用参数。

这意味着 AI 应用的成本不是由“用户打了多少字”决定，而是由“这次请求完整携带了多少上下文，以及生成了多少内容”决定。

一个用户输入“帮我总结一下”，背后可能附带一整篇文档、十几轮聊天历史、多个工具定义和复杂的结构化输出要求。输入框很短，请求并不一定便宜。

#成本会随着产品成功而放大

Token 成本最容易被低估的地方在于：它和使用量几乎线性相关。

早期只有内部测试用户时，一切看起来都还好。等到功能上线，用户开始频繁使用，每次请求都带着长上下文，账单会很快变成真实问题。

尤其是以下功能：

• 长文档总结。
• 代码库问答。
• 多轮客服对话。
• AI 写作助手。
• Agent 自动执行多步任务。
• 文档 RAG。
• 会议纪要和录音转写后的总结。
• 根据用户数据生成个性化内容。

这些功能天然会消耗大量输入或输出 Token。如果没有预算、限流、缓存、裁剪和监控，成本会随着用户增长直接放大。

这和前端性能优化很像。一个页面在本地跑得流畅，不代表它能承受真实设备、弱网、老手机和高并发。AI 功能在 Demo 里效果惊艳，也不代表它能在生产环境里稳定、可负担地运行。

#Token 成本影响产品定价

AI 应用的商业模型必须考虑推理成本。

如果一个功能每次调用都要消耗大量 Token，而你又把它放在免费入口、无限使用、没有节流，那么产品增长越好，亏损越快。

常见的产品策略包括：

• 免费额度。
• 每日或每月调用次数限制。
• 按功能分层。
• 高级模型只给付费用户。
• 长文档处理单独计费。
• 后台任务设置队列和优先级。
• 对超长输出做明确限制。

前端工程师虽然不一定负责定价，但会参与这些策略的落地。例如额度提示、模型选择、结果长度控制、排队状态、升级引导、失败提示、重试策略，都发生在用户界面上。

如果前端不了解成本，就很容易把一个昂贵能力设计成“看起来没有成本”的无限按钮。

#Token 成本影响性能体验

Token 多不仅贵，也慢。

输入 Token 越多，模型处理上下文的时间越长。输出 Token 越多，生成时间越长。用户看到的体验就是：

• 首字更慢。
• Streaming 时间更长。
• 中途更容易取消。
• 移动端等待焦虑更明显。
• 多个并发请求更容易排队。
• 服务端超时概率更高。

有些时候，优化 Token 比换模型、加机器、改动画更有效。

例如，一个文档问答系统每次都把 20 段检索内容塞给模型，但真正有用的只有 4 段。减少无关上下文后，成本下降，速度变快，回答还可能更稳定。

对前端来说，这会影响交互设计：

• 是否需要 Streaming。
• 是否允许停止生成。
• 是否展示生成进度。
• 是否拆成“先给摘要，再展开细节”。
• 是否让用户选择输出长度。
• 是否在上传前提示文件过大。

Token 成本和体验不是两件事。

#Token 成本影响架构设计

如果不关注 Token，AI 应用很容易演变成一个巨大的字符串拼接系统：所有历史、所有资料、所有规则、所有工具都塞进一次请求。

短期能跑，长期会出问题。

更合理的架构需要把 Token 当成预算来分配：

• 哪些内容必须进系统提示词。
• 哪些内容可以按需检索。
• 哪些历史消息要保留原文。
• 哪些历史可以总结。
• 哪些工具只在特定场景暴露。
• 哪些长文本应该先压缩再使用。
• 哪些结果可以缓存。
• 哪些模型适合便宜任务，哪些模型适合复杂任务。

这会自然引出更多工程能力：

• Token 统计。
• 成本日志。
• 上下文裁剪。
• 摘要记忆。
• Prompt 版本管理。
• RAG 检索和重排。
• 模型路由。
• 缓存和复用。
• 限流和配额。

这些不是“高级优化”，而是 AI 应用从 Demo 走向生产时必须补齐的基础设施。

#前端工程师为什么要关心

很多 Token 消耗由前端产品形态触发。

用户选中一段代码，还是整个文件？上传一个 PDF，还是整个资料库？点击“继续生成”，是接着当前上下文生成，还是重新带上全部历史？展开更多细节，是前端本地展开，还是再次调用模型？

这些交互决定了请求大小。

前端还负责让成本边界变得可感知。用户不需要看到复杂的 Token 明细，但需要理解产品规则：

• 为什么这个文件暂时不能处理。
• 为什么本次输出被限制长度。
• 为什么长对话会被总结。
• 为什么免费额度用完了。
• 为什么选择更强模型会消耗更多额度。
• 为什么系统建议缩小代码选择范围。

好的 AI 前端不是把成本暴露成技术术语，而是把成本转化为清晰、可预期、可操作的体验。

#实践建议

第一，为每个 AI 功能建立成本画像。

不要只看全站总 Token。应该按功能入口统计：聊天、总结、润色、代码解释、文档问答、工具调用分别消耗多少输入和输出 Token。

第二，设置 Token 预算。

每个请求类型都应该有预算，例如系统提示词最多多少、历史消息最多多少、检索结果最多多少、输出最多多少。预算不是为了限制能力，而是为了让系统可控。

第三，优先减少无价值输入。

优化成本时，先检查是否重复发送了无用上下文。过长的系统提示词、重复的历史消息、低相关检索片段、过多工具定义，都是常见浪费。

第四，控制输出长度。

很多产品场景不需要模型一次性写到很长。可以提供“简洁 / 标准 / 详细”选项，也可以让模型先给结构，再让用户按需展开。

第五，使用更细的模型路由。

不是所有请求都需要最强模型。分类、改写、摘要、格式转换、标题生成、简单问答可以考虑更便宜或更快的模型。复杂推理、关键决策、长上下文分析再使用更强模型。

第六，设计缓存和复用。

相同文档的摘要、相同检索片段的压缩结果、固定系统提示词的中间表示、重复用户请求，都可能有缓存空间。缓存策略需要结合业务正确性，不要盲目复用过期结果。

第七，把成本纳入可观测性。

日志里至少应该能回答：哪个功能最贵？哪个用户或租户消耗最多？哪个 prompt 版本导致成本上升？输出 Token 是否异常增长？错误重试是否造成额外浪费？

#常见误区

误区一：等产品有用户了再优化成本。

如果早期完全没有成本数据，后期很难判断问题来自模型、Prompt、上下文、检索还是用户行为。成本意识应该从开发阶段开始。

误区二：只要换便宜模型就能解决成本问题。

模型单价只是成本的一部分。上下文过长、输出失控、重试过多、工具定义膨胀，都会让便宜模型也变贵。

误区三：Token 越多，回答越好。

更多上下文不一定带来更好结果。无关信息会干扰模型，旧消息可能和当前任务冲突，过长输入还会增加延迟和费用。

误区四：成本优化会牺牲用户体验。

好的成本优化通常会改善体验。减少无关上下文、控制输出长度、按需展开、使用 Streaming、做模型路由，往往同时让产品更快、更清晰。

误区五：成本只需要后端关注。

前端交互决定用户会传什么、传多少、何时重试、何时继续生成、如何选择模型和输出长度。成本边界必须在产品体验里被设计出来。

#小结

Token 成本是 AI 应用的核心工程变量。它影响账单，也影响延迟、稳定性、产品定价、功能边界和用户体验。

对前端工程师来说，关注 Token 成本不是要变成财务或模型专家，而是要在设计 AI 交互时具备成本意识：少传无关内容，控制输出长度，给用户清晰边界，和后端一起建立可观测、可预算、可优化的上下文系统。

AI 应用不是只要“能回答”就完成了。真正可发布的 AI 应用，还要回答得起、等得起、控得住。