前端 Token 控制与成本优化：把上下文、模型与预算一起管起来

前端 Token 控制与成本优化

很多团队第一次做 AI 产品，盯的是模型效果；做了两周之后，盯的就变成账单。

Token 成本真正难管的地方，不在单次调用，而在这三个连锁问题：

上下文越来越长，历史消息舍不得删。
小任务也用大模型，模型分层没建立。
没有预算口径，账单只能事后看。

如果不把这三件事一起治理，成本问题迟早会变成产品问题。

1. 先搞清钱花在哪，不然优化没有方向

一个 AI 请求的总成本，通常由四部分决定：

成本来源	典型表现	优化方向
输入 token 过长	把完整聊天历史全带上	摘要与裁剪
输出过长	要求“尽量详细”且没有长度约束	限制输出目标
模型选型过重	分类、改写也走大模型	分层用模
重试与重复请求	用户多次点击、前端自动重发	幂等与去抖

所以成本治理的第一步不是“换便宜模型”，而是建立这张账本。

2. 上下文压缩，要保留任务状态，不是保留所有原文

最常见的误区是：为了“保证模型懂上下文”，把所有历史消息原样带上。

更有效的方法是分层保留：

当前任务必须保留的信息。
对后续判断有影响的摘要。
可以随时回查、但不必每次都发给模型的原始全文。

一个前端应用最小可行的上下文策略可以这样分：

interface ContextLayer {
  currentTask: string
  stableFacts: string[]
  rollingSummary: string
  rawHistoryRefIds: string[]
}

也就是说，模型每次看到的应该是“任务状态”，不是“完整聊天录像”。

3. 模型分层决定了成本结构，不要把一个模型当万能入口

很多团队的隐性浪费来自一句话：先都用最强模型，后面再优化。

更稳的做法是按任务类型分层：

高复杂决策：规划、架构、风险分析。
中复杂生成：页面文案、摘要、方案比较。
低复杂处理：分类、提取、格式化、改写。

如果低复杂任务占总调用量 70%，那成本优化的主战场不在最复杂的 30%，而在高频任务的默认模型。

4. 前端最容易忽略的浪费，是“无意识重复请求”

这些情况很常见：

输入框每次改动都触发重新生成。
用户连续点两次“生成”。
页面切换回来再次自动请求。
同一任务在不同组件里各发一次。

推荐至少加三层防护：

const inflightRequests = new Map<string, Promise<unknown>>()

export async function runDedupedRequest(key: string, task: () => Promise<unknown>) {
  if (inflightRequests.has(key)) return inflightRequests.get(key)

  const promise = task().finally(() => inflightRequests.delete(key))
  inflightRequests.set(key, promise)
  return promise
}

这不是性能小技巧，而是直接的成本控制手段。