LLM 应用成本工程实战 2026：小模型价格战时代，把 API 账单压成零头

2026 年 10 月的第一周，AI 行业密集发生了一件会改变所有应用架构的事：新一代旗舰模型的 API 输入价降到每百万 token 两美元、缓存读取低至一折，轻量模型价格直接砍到上一代的十分之一，万亿参数的开放权重模型也即将可以自己部署。**模型能力正在快速商品化，"用哪个模型"第一次变成一个纯粹的工程经济学问题。**同样一个客服自动回复功能，全部走旗舰模型和按难度分级路由，月度账单可以相差几十倍，而用户几乎感受不到差别。本文系统讲解 LLM 应用的成本工程：从看懂账单、测量成本，到路由、缓存、压缩、批处理与熔断的完整实战。

---

一、先看懂账单：token 定价的四个结构性事实

优化成本之前，先要理解主流厂商定价表背后的规律。它们看似复杂，实则只有四条：

事实 1：输出 token 远贵于输入 token
  典型比例：输出价格是输入的 5 倍左右。
  含义：让模型"少说话"比让用户"少提问"更省钱。

事实 2：缓存命中的输入按折扣价计费
  典型折扣：缓存读取约为正常输入价的一折甚至更低。
  含义：重复的系统提示与上下文值得被刻意缓存。

事实 3：推理模型的思考过程也按输出计费
  含义：reasoning effort（思考力度）不是玄学档位，
       它直接决定账单长度。

事实 4：超长上下文存在阶梯加价
  部分模型对超过阈值（如二十多万 token）的请求整体加价。
  含义：把所有资料无脑塞进上下文，既慢又贵。

以 2026 年 10 月主流定价为例，一次调用的成本可以拆成三段：

单次调用成本
  = 输入 token × 输入单价
  + 命中缓存的输入 token × 缓存单价
  + 输出 token（含思考 token）× 输出单价

示例：一次 2000 输入 + 500 输出的常规调用，
     与一次 50000 输入 + 3000 输出的"文档总结"调用，
     成本差距不在一个量级——后者主要贵在输入规模。

核心认知：**LLM 成本不是一个总数，而是三类 token（新鲜输入、缓存输入、输出）各自乘以不同单价的加权和。**不理解这个结构，任何"换个便宜模型"的优化都是盲目的。

---

二、成本地图：没有测量，就没有优化

多数团队优化成本的第一步就错了：他们盯着账单总额看，却不知道钱具体烧在哪个功能、哪类用户、哪条代码路径上。成本工程的第一步是给每次调用打上结构化标签。

/** 一次 LLM 调用的成本记录 */
interface CostRecord {
  feature: string;        // 功能标识，如 "customer_support" / "doc_summary"
  userId?: string;        // 归因到用户（用于识别异常重度用户）
  model: string;          // 实际使用的模型
  promptTokens: number;   // 未命中缓存的输入 token
  cachedTokens: number;   // 命中缓存的输入 token
  completionTokens: number; // 输出 token（含思考）
  cost: number;           // 本次调用总成本（美元）
  cacheHit: boolean;      // 是否命中 prompt 缓存
  latencyMs: number;      // 延迟（成本与体验需要联合分析）
}

建议封装一个统一的调用入口，所有业务代码只允许通过它访问模型，成本采集在入口内自动完成：

/**
 * 带成本埋点的统一调用入口
 * 业务侧只调用此函数，禁止直接拼接厂商 SDK
 */
async function trackCompletion(params: {
  feature: string;
  userId?: string;
  model: string;
  messages: unknown[];
}): Promise<{ text: string; usage: CostRecord }> {
  const startedAt = Date.now();
  const resp = await callModelProvider(params.model, params.messages);
  const cost = calcCost(params.model, resp.usage); // 按定价表计算金额

  const record: CostRecord = {
    feature: params.feature,
    userId: params.userId,
    model: params.model,
    promptTokens: resp.usage.promptTokens,
    cachedTokens: resp.usage.cachedTokens ?? 0,
    completionTokens: resp.usage.completionTokens,
    cost,
    cacheHit: (resp.usage.cachedTokens ?? 0) > 0,
    latencyMs: Date.now() - startedAt,
  };

  await logCostRecord(record); // 写入数仓 / 分析平台
  return { text: resp.text, usage: record };
}

有了数据之后，按功能维度聚合，成本地图会立刻暴露三类典型问题：

成本地图上最常见的三个异常：
  ① 某个低频功能吃掉了大头预算
     → 典型原因：上下文里塞了整份长文档，且没有缓存。
  ② 同一类请求输出 token 远超预期
     → 典型原因：没有限制输出长度，模型在"礼貌性废话"。
  ③ 缓存命中率长期为零
     → 典型原因：动态内容拼在了前缀，缓存从未命中过。

先测量、再优化、最后用数据验证——这三步缺一不可。没有成本地图时，团队优化的往往是"自己觉得贵"的地方，而不是真正贵的地方。

---

三、模型路由：让一个请求在三个梯队间分流

2026 年的模型市场已经明显分层，这恰好是成本优化最大的杠杆：

三级模型梯队（按任务难度，而非按品牌）：

轻量梯队（Haiku / Luna 级）
  适合：分类、改写、提取、格式转换、简单问答
  特点：极快、极便宜，能力对结构化任务已经过剩

主力梯队（Sonnet / 中端旗舰级）
  适合：常规写作、多步工具调用、代码修改、业务推理
  特点：性价比最优，应承载绝大多数真实流量

旗舰梯队（Opus / 顶级旗舰级）
  适合：复杂规划、长周期 Agent、难题兜底
  特点：贵，只在被明确需要时才出场

路由的本质是一个"任务难度 → 模型档位"的判定函数。不要把路由写死在业务代码里，而是收敛为一个独立决策点：

/** 任务难度档位 */
type TaskTier = "light" | "standard" | "flagship";

/** 各档位对应的实际模型（可随时按价格与评测调整） */
const MODEL_BY_TIER: Record<TaskTier, string> = {
  light: process.env.MODEL_LIGHT!,      // 轻量模型
  standard: process.env.MODEL_STANDARD!, // 主力模型
  flagship: process.env.MODEL_FLAGSHIP!, // 旗舰模型
};

/**
 * 根据任务特征决定模型档位
 * 规则保持简单可读，便于随业务演进调整
 */
function routeTask(input: {
  feature: string;
  expectedOutputTokens: number;
  needsDeepReasoning: boolean;
  userMessage: string;
}): TaskTier {
  // 规则一：输出极短的结构化任务，永远走轻量档
  const structuralTasks = ["classify", "extract", "rewrite_title", "tag"];
  if (structuralTasks.includes(input.feature)) return "light";

  // 规则二：明确需要深度推理或长周期规划的，走旗舰档
  if (input.needsDeepReasoning) return "flagship";

  // 规则三：输入超长但任务简单的总结类，轻量档往往也能胜任
  if (input.feature === "doc_summary" && input.expectedOutputTokens < 400) {
    return "light";
  }

  // 其余流量默认走主力档
  return "standard";
}

接入统一入口时，业务侧只描述任务，不指定模型：

/**
 * 业务调用示例：先路由，再带着路由结果发请求
 */
async function answerSupportTicket(message: string, userId: string) {
  const tier = routeTask({
    feature: "customer_support",
    expectedOutputTokens: 300,
    needsDeepReasoning: message.length > 2000, // 超长工单升级
    userMessage: message,
  });

  return trackCompletion({
    feature: "customer_support",
    userId,
    model: MODEL_BY_TIER[tier],
    messages: [/* 系统提示 + 用户消息 */],
  });
}

路由规则上线后，要持续对照两件事：各档位的流量占比，以及用户对轻量档结果的满意度。成本工程的纪律是：任何把流量从高档下调到低档的改动，都必须配一个质量回归验证，而不是只看账单下降。

---

四、级联升级：先用便宜模型，没把握再换旗舰

静态规则解决不了"看上去简单、实际很难"的请求。更精细的做法是级联（cascade）：**默认让轻量模型作答，只有当它显式表示没把握时，才升级到更强模型。**这让大部分简单请求享受极低成本，同时不牺牲困难请求的质量。

/** 轻量模型的自评结果：直接给答案，或请求升级 */
interface LightAnswer {
  confident: boolean;  // 模型对答案是否有把握
  answer?: string;     // 有把握时的答案
  reason?: string;     // 没把握时说明原因，便于观测
}

/**
 * 级联调用：轻量模型先行，低置信度时升级主力模型
 * 返回最终文本及实际使用的档位，用于成本分析
 */
async function cascadedAnswer(
  feature: string,
  messages: unknown[],
): Promise<{ text: string; tier: TaskTier }> {
  // 第一级：要求轻量模型输出结构化自评
  const first = await trackCompletion({
    feature,
    model: MODEL_BY_TIER.light,
    messages: [...messages, { role: "system", content: SELF_ASSESS_PROMPT }],
  });

  const parsed: LightAnswer = JSON.parse(first.text);
  if (parsed.confident && parsed.answer) {
    return { text: parsed.answer, tier: "light" };
  }

  // 第二级：低置信度时升级，仅这部分请求承担高成本
  const upgraded = await trackCompletion({
    feature,
    model: MODEL_BY_TIER.standard,
    messages,
  });
  return { text: upgraded.text, tier: "standard" };
}

其中让模型自评的提示词需要强制结构化输出，并把"不确定"的门槛说清楚：

SELF_ASSESS_PROMPT（要点）：
  你是一个分流助手。先判断自己能否高质量回答用户问题。
  - 如果问题属于事实性、常识性、简单改写类，给出答案。
  - 如果需要专业知识、多步推理或你没有把握，
    明确返回 confident=false，不要猜测。
  只输出 JSON：{"confident": boolean, "answer": string, "reason": string}

级联策略的经济性来自一个分布事实：**真实生产流量中，绝大多数请求是简单的。**只要轻量模型能自信解决其中大部分，只有少数请求升级，加权平均成本就会急剧下降。需要警惕的反向风险是模型过度自信（明明不会却自信作答），因此自评提示要配合抽检，必要时用一批已知难度的请求校准"自信阈值"。

---

五、Prompt 缓存：把重复前缀变成一折资产

多数 LLM 应用的每次请求都携带大段重复内容：系统提示、工具定义、few-shot 示例、产品文档、长对话的早期轮次。这些内容每请求都按全价发送，是最隐蔽的浪费。Prompt 缓存让厂商在服务端复用这部分前缀，命中部分按约一折计费。

缓存生效有一个硬性前提：**请求必须共享完全一致的前缀，且前缀要足够长。**因此要把稳定内容前置、易变内容后置：

错误的拼接顺序（缓存几乎永远不命中）：
  [当前时间] [随机 requestId] [用户信息]   ← 易变内容在前
  [系统提示 + 工具定义 + 知识库文档]        ← 稳定内容在后

正确的拼接顺序（稳定前缀最大化）：
  [系统提示 + 工具定义 + 知识库文档]        ← 稳定内容在前，命中缓存
  [对话历史（旧 → 新）]                    ← 渐进追加
  [当前时间 / 用户信息 / 本轮输入]          ← 易变内容放最后

显式声明缓存断点（部分厂商支持），可以主动控制哪些块参与缓存：

/**
 * 构造带缓存断点的消息序列
 * 稳定块在前并打上 cache_control，易变块在后
 */
function buildCachedMessages(opts: {
  systemPrompt: string;   // 长期稳定的系统提示
  toolsSpec: string;      // 工具定义
  knowledgeDoc: string;   // 产品知识库（按版本更新）
  history: unknown[];     // 对话历史
  userInput: string;      // 本轮输入
}) {
  const stablePrefix = [
    { role: "system", content: opts.systemPrompt, cache_control: { type: "ephemeral" } },
    { role: "system", content: opts.toolsSpec,  cache_control: { type: "ephemeral" } },
    { role: "system", content: opts.knowledgeDoc },
  ];

  return [...stablePrefix, ...opts.history, { role: "user", content: opts.userInput }];
}

缓存命中率本身必须成为监控指标。命中率为零通常只有三个原因：前缀不稳定、前缀太短、请求间隔超过了缓存存活时间。

缓存运营要点：
  - 系统提示一旦发布就避免频繁改动，改一个字都会让前缀缓存失效。
  - 热门文档/工具定义放在最前，并与业务版本绑定、整体更新。
  - 低峰期的长间隔任务要有"预热"意识，别假设缓存永远在。
  - 把缓存命中率、缓存 token 占比做成看板，按功能分别看。

---

六、语义缓存：让重复问题根本不进模型

Prompt 缓存只折扣输入，输出仍然要模型重新生成。对于问答、客服、搜索摘要这类相同语义的问题被反复提问的场景，可以更进一步：语义缓存（semantic cache）——命中时根本不调用模型，直接返回历史答案，成本为零，延迟也从数秒降到毫秒级。

/** 语义缓存条目 */
interface SemanticCacheEntry {
  questionEmbedding: number[]; // 标准化问题向量
  answer: string;
  model: string;
  createdAt: number;
}

/**
 * 查询语义缓存：问题向量与历史条目的相似度超过阈值即命中
 * 阈值需要按业务对"准确性 vs 命中率"的偏好调节
 */
async function semanticLookup(question: string): Promise<string | null> {
  const qVec = await embed(question);
  const hits = await vectorSearch("llm_cache", qVec, { topK: 1 });

  if (hits.length > 0 && hits[0].score >= SIMILARITY_THRESHOLD) {
    return hits[0].answer;
  }
  return null;
}

完整的读写流程把模型调用包在缓存 miss 分支里：

/**
 * 带语义缓存的问答：命中直接返回，未命中才请求模型并回写缓存
 */
async function cachedAnswer(question: string, feature: string) {
  const cached = await semanticLookup(question);
  if (cached) {
    await logCacheHit(feature); // 记录"零模型调用"的节省
    return { text: cached, source: "semantic_cache" as const };
  }

  const { text } = await trackCompletion({
    feature,
    model: MODEL_BY_TIER.light,
    messages: [{ role: "user", content: question }],
  });

  // 异步回写，不阻塞用户响应
  void upsertSemanticCache(question, text);
  return { text, source: "model" as const };
}

语义缓存有两个必须正视的边界，否则会省小钱出大事故：

语义缓存的红线：
  ① 个性化内容禁止缓存
     "我的订单到哪了""帮我改密码"——问题相似，答案因人而异。
     缓存键必须包含用户维度，或这类请求直接绕过缓存。

  ② 时效性内容要能主动失效
     价格、库存、政策类答案会过期，需要 TTL
     与版本标记，文档一更新就让相关缓存批量失效。

经验上，客服与内部知识问答场景的语义缓存命中率可以做到很高，是 ROI 最直观的一项优化；而开放式创作场景则不适合，强行缓存只会返回陈旧雷同的内容。

---

七、输入与输出：在账单最贵的两端同时压缩

7.1 压缩输入：别把整个世界塞进上下文

超长输入既是延迟杀手也是成本大户。常见的有效做法包括：

输入压缩的四个动作：
  ① 检索替代堆砌：用向量检索只取相关片段，而非整篇文档。
  ② 先摘要再投喂：长文档先用轻量模型压成要点，再交给主力模型。
  ③ 历史窗口裁剪：对话只保留近期轮次 + 早期对话的摘要。
  ④ 结构化去冗余：用 JSON/表格替代自然语言描述，省 token 且更精确。

对话历史的"滚动摘要"是性价比很高的一招：

/**
 * 压缩对话历史：近期轮次原样保留，更早的内容交给轻量模型摘要
 * 在不丢失关键事实的前提下显著缩短输入长度
 */
async function compressHistory(messages: ChatMessage[], keepRecent: number) {
  if (messages.length <= keepRecent) return messages;

  const oldPart = messages.slice(0, -keepRecent);
  const recentPart = messages.slice(-keepRecent);

  const { text: summary } = await trackCompletion({
    feature: "history_compress",
    model: MODEL_BY_TIER.light, // 摘要任务用轻量模型即可
    messages: [
      { role: "system", content: "用要点列表总结以下对话中的关键事实与待办。" },
      { role: "user", content: oldPart.map((m) => m.content).join("\n") },
    ],
  });

  return [{ role: "system", content: `早期对话摘要：${summary}` }, ...recentPart];
}

7.2 压缩输出：最贵的是生成的每个字

输出单价通常是输入的数倍，控制输出长度的收益立竿见影：

/**
 * 约束输出成本的请求参数集合
 */
const OUTPUT_CONTROL = {
  maxTokens: 500,          // 按业务场景设硬上限，杜绝失控长文
  stop: ["\n\n\n"],        // 合理的停止序列
  // 要求结构化输出：字段固定、不产生客套话与重复
  responseFormat: { type: "json_object" },
} as const;

系统提示中的一句"反废话"指令往往效果显著，且零成本：

输出风格约束（写进系统提示）：
  - 直接给结论，不要寒暄、不要重复问题、不要自我表扬。
  - 不确定就说明，不用填充性段落凑长度。
  - 使用编号与短句，避免营销腔与无信息量的形容词。

对于推理模型，还有一个专属杠杆：**按任务调节思考力度。**简单分类任务用最低档思考，复杂规划才拉满——思考 token 同样按输出计费，低档与高档之间的成本差异非常可观。

---

八、批处理：能等的任务，一律半价

并非所有 LLM 请求都需要即时响应。给用户发的回复要秒级返回，但大量后台任务天然可以延迟：夜间的工单批量分类、上千条评论的情感分析、数据集标注、长文档的离线摘要。主流厂商的批处理接口对这类任务提供约五折价格，且通常享有更宽松的速率限制。

/**
 * 提交批处理任务
 * 适用于不要求实时、可容忍较长返回窗口的离线场景
 */
async function submitBatch(job: {
  feature: string;
  records: Array<{ id: string; input: string }>;
}) {
  const file = await uploadJsonl(
    job.records.map((r) => ({
      custom_id: r.id,
      method: "POST",
      url: "/v1/chat/completions",
      body: {
        model: MODEL_BY_TIER.light, // 批量任务优先轻量模型
        messages: [{ role: "user", content: r.input }],
      },
    })),
  );

  return createBatchJob({ inputFileId: file.id, metadata: { feature: job.feature } });
}

实时与批处理的分流应该在架构里显式存在，而不是靠开发者临场判断：

请求时效分流：
  同步路径（用户正在等待）
    → 在线 API，追求延迟与稳定，可配合路由与缓存。
  异步路径（用户不在等待）
    → 批处理 API，接受排队与延迟，换取半价与高限额。
    典型：日报生成、批量标注、离线评估、数据清洗。

把能异步的任务移出实时链路，往往是一次改造、长期省钱的高 ROI 动作，同时还能削平高峰期的速率限制压力。

---

九、降级链、限流与预算熔断：别让一个死循环刷爆信用卡

成本工程的最后一道防线是承认程序会出错：一个有 bug 的循环、一次失控的 Agent 自我调用、一次被刷的接口，都可能在短时间内产生惊人账单。必须在架构层设置硬性保护。

/** 模型降级链：主模型失败时按顺序尝试更便宜/更稳的备选 */
const FALLBACK_CHAIN = [
  MODEL_BY_TIER.standard,
  MODEL_BY_TIER.light,     // 主力挂了先用轻量模型保住核心功能
  MODEL_BY_TIER.light,     // 可切换到另一厂商的轻量模型避免单点
];

/**
 * 带降级的调用：按降级链依次尝试，全部失败才抛出
 */
async function resilientCall(messages: unknown[]) {
  let lastError: unknown;
  for (const model of FALLBACK_CHAIN) {
    try {
      return await callModelProvider(model, messages);
    } catch (err) {
      lastError = err;
      await reportFallback(model); // 记录降级事件以便复盘
    }
  }
  throw lastError;
}

预算熔断则是财务意义上的保险丝：为功能、用户、时间窗口分别设上限：

/**
 * 预算守卫：超过任一维度上限即拒绝新调用
 * 计数器建议放在 Redis 等共享存储，多实例共享
 */
async function assertBudget(ctx: {
  feature: string;
  userId?: string;
  estimatedCost: number;
}): Promise<void> {
  const dailyTotal = await getCounter(`budget:day:${today()}`);
  const featureTotal = await getCounter(`budget:feat:${ctx.feature}:${today()}`);
  const userTotal = ctx.userId
    ? await getCounter(`budget:user:${ctx.userId}:${today()}`)
    : 0;

  if (dailyTotal > DAILY_HARD_LIMIT) throw new BudgetExceededError("日预算熔断");
  if (featureTotal > FEATURE_LIMIT[ctx.feature]) throw new BudgetExceededError("功能预算熔断");
  if (userTotal > PER_USER_DAILY_LIMIT) throw new BudgetExceededError("单用户预算熔断");

  await incrBy(`budget:day:${today()}`, ctx.estimatedCost);
}

三层保护各自解决不同问题：

  限流：防止单用户/单 IP 的异常高频调用。
  功能预算：防止某个失控功能烧光全站额度。
  全站日熔断：最后的总闸门，触发后可降级为缓存答案或排队提示。

熔断触发时给用户的体验也要提前设计好——返回"服务繁忙"远好过账单爆炸后服务停摆。

---

十、落地清单：按 ROI 排序的优化动作

最后，把上述手段按"实现成本 / 节省幅度"排序，给独立开发者一份可直接执行的清单：

第一梯队（几天内可做，立即见效）
  □ 统一调用入口 + 成本埋点，建立按功能的成本地图
  □ 给所有请求设 max_tokens，系统提示加入"反废话"约束
  □ 简单的结构化任务统一切到轻量模型
  □ 设置全站日预算与单用户预算的硬熔断

第二梯队（一两周，节省最大）
  □ 三级模型路由 + 难度判定函数
  □ 重构消息顺序，稳定前缀前置，开启 Prompt 缓存
  □ 客服/问答类高频场景接入语义缓存
  □ 推理任务按难度调节思考力度

第三梯队（需要架构投入，长期收益）
  □ 低置信度级联升级，用评测集校准自信阈值
  □ 长文档与对话历史的摘要压缩流水线
  □ 离线任务全面迁移批处理接口
  □ 多厂商降级链与容量备份

每完成一项，都回到成本地图验证两件事：**账单是否如预期下降，质量指标（满意度、重试率、人工接管率）是否保持稳定。**成本工程的本质是花钱的精细化，而不是一味追求最低价——一个省了钱却答非所问的系统，会用流失的用户让你加倍偿还。

---

结语：模型会越来越便宜，工程差距会越来越贵

小模型价格战还会继续，开放权重模型会持续逼近闭源前沿，"模型能力"本身正在成为廉价的基础设施。但这并不意味着成本问题会自动消失——**当调用便宜到可以被随意挥霍时，浪费也会同步膨胀。**真正拉开差距的，是那些把成本决策写进架构的团队：他们知道每个功能在烧哪类 token、每类请求该走哪个档位、每次失败有谁兜底。

模型的单价由厂商决定，但你账单上的加权平均成本，永远由自己的工程设计决定。