创业团队 AI 成本控制：先建立单位经济模型

上个月帮一个做客服 SaaS 的朋友看账单，他们月调用量大概 12 亿 token，月账单 $47,000。团队花了两周砍到 $12,700——没换模型，没砍功能，只是把缓存、路由和上下文裁剪做对了。

这种事我在三个创业团队身上见过类似剧本。共同点不是「找到了某个神奇便宜模型」，而是先搞清楚了一件事：成本要跟着用户价值走，不是跟着 token 单价走。

没有单位经济模型，优化方向一定跑偏

大部分团队看 AI 成本的第一反应是换便宜模型，或者压供应商价格。这个思路有个前提——假设所有 token 成本一样，所有用户价值一样。两个假设都不成立。

2026 年的现实是：GPT-4 级别模型的 API 价格已经降到每百万 token $0.40 左右，比 2024 年跌了 90% 以上。但企业 AI 账单反而在涨——推理成本现在占企业 AI 预算的 85%，而 2023 年这个数字只有 40%。原因很直接：用得多、用得深、Agent 链路长、上下文越来越长。单价跌了，总量涨得更凶。

所以要看的不是「一次 API 调用多少钱」，而是「一个用户、一个任务、一笔订单带来多少模型成本，对应多少业务价值」。这就是单位经济模型。

把成本拆到最小粒度，再和业务指标对齐，你才能回答这几个问题：

• 哪个功能的 ROI 最高，值得投入更多模型预算？
• 哪个功能在烧钱但没产生用户价值？
• 成本突增是因为流量增长（好事）还是因为重试循环（坏事）？

先把成本来源拆清楚

AI 调用的成本通常来自这几块：

这些数字因场景差异很大。RAG 密集型应用的检索上下文占比可能到 40%；Agent 应用的工具调用轮次可能到 30%。关键是先埋点记录，拿到自己的真实分布，再决定从哪里下手。

盲目换便宜模型的问题在于：如果你的成本大头是 RAG 上下文太长，换模型只能省 20-30%，但裁剪上下文或者做摘要可以省 50-70%。方向错了，努力白费。

模型分层：最立竿见影的一刀

模型分层的核心逻辑很简单——不是所有任务都需要最强的模型。

简单分类、格式转换、信息抽取、意图识别这类任务，用 Haiku 或者 GPT-4o-mini 就够了；复杂推理、长文生成、高风险判断才需要 Sonnet 或 GPT-4 级别。这个分层做好了，能省 60-80%，而且对终端用户几乎无感。

实际做法是在请求前面加一个轻量路由器。可以是一个本地小模型、一个规则引擎、甚至一个决策树。ProjectDiscovery 的团队用了一个本地 ONNX 分类器来判断查询复杂度，68% 的请求被路由到便宜模型，每月省了 $5,400。

// 优化前：所有请求打同一个模型
async function handleQuery(query: string) {
  const response = await openai.chat.completions.create({
    model: 'gpt-4o',
    messages: [{ role: 'user', content: query }],
  })
  return response.choices[0].message.content
}

// 优化后：本地路由器 + 分层模型
const router = new LocalONNXClassifier('query-complexity-v3')
 
async function handleQuery(query: string) {
  const complexity = await router.classify(query)
 
  const model = complexity === 'complex'
    ? 'gpt-4o'        // 复杂推理、多步任务
    : 'gpt-4o-mini'   // 简单问答、分类、抽取
 
  const response = await openai.chat.completions.create({
    model,
    messages: [{ role: 'user', content: query }],
  })
  return response.choices[0].message.content
}

路由判断本身也有成本。关键是让判断逻辑足够轻——本地模型推理延迟在毫秒级，不增加额外的 API 调用。如果路由准确率不够，可以先从规则开始：关键词匹配、输入长度阈值、用户等级。

缓存是 ROI 最高的优化手段

2026 年做 LLM 成本优化，缓存几乎是公认的最高 ROI 手段。原因不复杂：你已经在为相同的 system prompt 和类似的查询反复付全价了。

缓存分两层：

Provider 级 Prompt Caching：OpenAI 和 Anthropic 都支持。System Prompt 超过一定长度（OpenAI 是 1024 token），自动享受缓存价格，输入 token 成本打 1-2 折。Anthropic 需要你在 message 里加 cache_control 标记。这一层几乎零成本，开了就有。

语义缓存（Semantic Cache）：对用户查询做向量化，相似度超过阈值就直接返回缓存结果。不需要完全相同的 query——「怎么退款」和「我想退钱」会被识别为同一个问题。

ProjectDiscovery 的案例很有说服力。他们的缓存命中率从最初的 7% 做到 84%，整体成本从 $23,000/月降到 $8,600/月。最关键的一步是把动态内容（实时召回缓冲区）从 prompt 开头移到了末尾——因为 provider 的 prompt caching 是基于前缀匹配的，开头一变后面全部失效。这个改动让命中率从 8% 一夜跳到 74%。

// 优化前：动态内容混在 system prompt 里，每次前缀都不同
const messages = [
  {
    role: 'system',
    content: `你是一个客服助手。
当前时间：${new Date().toISOString()}        // 每秒变化，前缀失效
用户信息：${user.name}                        // 每个用户不同，前缀失效
知识库上下文：${ragContext}
请回答用户问题。`
  },
  { role: 'user', content: query }
]

// 优化后：稳定前缀 + 动态内容移到 user message
const messages = [
  {
    role: 'system',
    content: `你是一个客服助手。请回答用户问题。`,  // 稳定前缀，可以缓存
    // Anthropic: 加 cache_control 标记
    // cacheControl: { type: 'ephemeral' }
  },
  {
    role: 'user',
    content: `当前时间：${formatDateOnly(new Date())}
用户：${user.name}
知识库参考：${ragContext}
 
问题：${query}`
  }
]

语义缓存要注意几个坑：

1. 误命中：「取消航班」和「取消订阅」语义很接近，但业务完全不同。必须做命名空间隔离，按业务域分桶。
2. 命中率阈值：语义缓存有向量检索开销。命中率低于 15-20% 时，缓存层的基础设施成本可能比省下的 API 费用还高。
3. TTL 管理：通用查询 24 小时，价格和策略类信息 1 小时。时间敏感的内容缓存太久会出问题。
4. 多租户隔离：cache key 里必须带 tenant ID，否则会有数据泄露风险。

批处理和上下文裁剪

很多团队忽略了两个低成本高回报的手段：批处理 API 和上下文裁剪。

批处理 API：OpenAI、Anthropic 都提供 batch 接口，价格通常是实时 API 的 50%。如果你的场景对延迟不敏感（比如 nightly 数据标注、批量内容生成、报表汇总），切换到 batch API 是最简单的一刀。

上下文裁剪：多轮对话场景下，对话历史会不断膨胀。不做处理的话，10 轮对话的输入 token 可能是第 1 轮的 8-10 倍。做法有几种：

Anthropic 的 prompt caching 文档里提到一个技巧：用「冻结日期」代替完整时间戳。如果你的 system prompt 里包含 new Date().toISOString()，每秒都在变，缓存永远命中不了。改成只显示日期 2026-06-26，一天内所有请求共享同一个缓存前缀。

还有一个容易被忽视的点：工具调用结果的压缩。Agent 场景下，每次 function calling 返回的结果会被完整注入到下一轮的上下文中。如果你的工具返回了一大段 JSON，里面 80% 的字段模型根本不需要，那就浪费了。做法是在工具层做一次压缩，只保留模型需要的关键字段：

// 优化前：工具返回完整对象，全部注入上下文
function searchOrders(query: string) {
  return db.orders.findMany({ where: { description: { contains: query } } })
  // 返回完整订单对象，包含 30+ 字段
}
 
// 优化后：工具层压缩，只返回模型需要的字段
function searchOrders(query: string) {
  const orders = db.orders.findMany({ where: { description: { contains: query } } })
  return orders.map(o => ({
    id: o.id,
    status: o.status,
    amount: o.amount,
    summary: o.description.slice(0, 100)
  }))
  // token 消耗减少约 60-70%
}

自部署还是继续用 API

当你的月调用量过了某个门槛，自部署模型会变成值得考虑的选项。根据 Spheron Network 的分析，对于稳定、可预测的工作负载，自建推理服务可以降低 70-90% 的成本。

但这个决策不能只看 token 单价。

一个经验性的判断标准：如果你每月在某个模型上的 API 支出稳定超过 $5,000-8,000，且未来 6 个月的量级可预见，自部署的 ROI 就开始转正了。但如果你的业务还在快速变化，模型选择还没定下来，留在 API 上是更灵活的选择。

成本告警和可观测性

上线之后不是设完优化就结束了。成本是动态的，需要持续监控。

我见过的成本突增原因：

• 循环调用：Agent 进入死循环，同一个任务反复重试，一晚上烧掉几千美元
• Prompt 膨胀：产品迭代不断往 system prompt 加内容，三个月后 prompt 长了 3 倍
• 缓存失效：某次部署改了 prompt 顺序，缓存命中率从 80% 掉到 10%
• 攻击流量：恶意用户刷接口，每次都带超长输入

// 按功能维度记录成本
function recordCost(feature: string, model: string, tokens: { input: number; output: number }) {
  const pricing = MODEL_PRICING[model]
  const cost = tokens.input * pricing.inputPerToken
            + tokens.output * pricing.outputPerToken
 
  metrics.increment('llm.cost', cost, { feature, model })
  metrics.increment('llm.tokens.input', tokens.input, { feature, model })
  metrics.increment('llm.tokens.output', tokens.output, { feature, model })
 
  // 单次请求成本异常告警
  if (cost > COST_THRESHOLD_PER_REQUEST) {
    alerts.fire('llm_cost_spike', { feature, cost, tokens })
  }
}
 
// 按小时聚合，检测成本趋势
function checkCostTrend(feature: string) {
  const hourlyCost = metrics.sum('llm.cost', { feature, window: '1h' })
  const baseline = metrics.avg('llm.cost', { feature, window: '7d', sameHour: true })
 
  if (hourlyCost > baseline * 2) {
    alerts.fire('cost_trend_anomaly', { feature, hourlyCost, baseline })
  }
}

可观测性工具方面，Helicone、Portkey、Langfuse 都能做。核心是三个维度：按功能、按租户、按模型。成本异常的时候能快速定位是哪个维度出了问题。

成本优化的决策流程

把上面的策略串起来，一个比较完整的决策流程是这样的：

单位经济模型怎么算

回到最开始的问题：怎么判断 AI 成本是否健康？

核心指标是「每用户模型成本 / 每用户收入」。不同业务模型的计算方式不同：

一个比较实用的做法是给每个功能设定成本预算上限。如果某个功能的单用户成本连续三天超过预算，就触发 review——要么是优化不够，要么是这个功能本身不值得用 AI。

一份可以打勾的检查清单

下面是我自己用的成本优化检查清单。不需要一次全做，但建议每个月过一遍：

基础设施层

• 所有 API 调用都记录了 token 消耗和成本（按功能、模型、租户维度）
• 设置了成本异常告警（单次请求阈值 + 每小时趋势阈值）
• 有成本 dashboard，能看到最近 7 天和 30 天的趋势

缓存层

• 开启了 Provider 级 Prompt Caching（OpenAI 自动、Anthropic 加 cache_control）
• System Prompt 的稳定内容在前、动态内容在后
• 时间戳只精确到天，不用 ISO 格式
• 评估了语义缓存的可行性（查询重复率 > 20% 就值得做）
• 语义缓存做了命名空间隔离和 TTL 管理

模型路由层

• 有模型分层策略，不是所有请求都用同一个模型
• 路由判断是本地执行的，不增加额外 API 调用
• 定期 review 路由准确率，对比分层前后的质量指标

上下文层

• 多轮对话有上下文裁剪策略（滑动窗口或摘要压缩）
• 工具调用结果做了压缩，只保留必要字段
• RAG 检索结果有长度上限，不是把整个文档塞进去

批处理层

• 延迟不敏感的任务使用 Batch API（价格通常减半）
• 批量任务有失败重试机制，但重试次数有上限

业务层

• 每个功能有单位经济模型（成本 vs 业务价值）
• 每个功能有成本预算上限
• 定期 review 低 ROI 功能，考虑是否值得继续用 AI

AI 成本控制不是一次性的项目，是一个持续运转的飞轮。你建立了度量体系，才能发现问题；发现了问题，才能针对性优化；优化之后，才能验证效果。

最关键的一步永远是最开始那一步：搞清楚你每个 token 花在了哪里，换回了什么。

参考资料

• LLM Inference Optimization: Cut Cost & Latency at Every Layer (2026) — Morph LLM，2026 年 LLM 推理优化四层策略综述
• AI Inference Cost Crisis 2026: Why Your AI Bill Is Exploding — Oplexa，企业 AI 推理成本占比分析
• AI Inference Cost Economics in 2026: GPU FinOps Playbook — Spheron Network，推理成本经济学与 FinOps 实践
• How We Cut LLM Costs by 59% With Prompt Caching — ProjectDiscovery，Prompt Caching 实战案例
• Semantic Caching Saved Us $14K/Month in LLM API Costs — BirJob，语义缓存 + 模型路由实战
• Gartner Predicts Inference Cost to Drop 90%+ by 2030 — Gartner，2026 年 3 月推理成本预测
• Reducing LLM Inference Cost: A Practical Guide — Medium，推理工程优化技术详解
• Prompt Caching in 2026: Anthropic, OpenAI, Azure Compared — Technspire，各厂商 Prompt Caching 对比