LLM API成本估算指南：开发者如何精准控制token开销

为什么你的账单不是"几亿美元"

媒体总爱渲染大模型训练耗资数亿美金，但那是AI实验室的账单——GPU集群、数据清洗、RLHF和庞大的研究团队。作为开发者，你真正需要关心的是推理成本：按发送和接收的token数量计费，本质上和任何按量计费的云服务没有区别。

这意味着LLM成本是可以被精确建模和预测的。你只需要理解三件事：token怎么算、模型怎么选、哪些优化手段真正有效。

LLM成本估算指南

API定价的底层逻辑

几乎所有主流厂商的计费规则都遵循同样的框架：

按token收费，而非按请求。 一个token大约是英文单词的¾，中文则因分词方式不同而有所差异。
输入和输出分开定价。 输出token通常比输入贵2到5倍，因为生成比读取更消耗算力。
上下文长度影响单价。 超长上下文窗口往往对应更高的每token费率。
Prompt缓存是省钱利器。 如果你每次调用都重复发送同一段系统提示词、产品目录或风格指南，缓存能大幅削减这部分开销。

价格区间跨度极大：小型"微型"模型可能每百万token只需几美分，而顶级推理模型则可能高达数百美元。更关键的是，这个市场几乎只朝一个方向移动——降价。

什么是 token？ Token 是模型处理文本的最小单位，既不是字符也不是单词。主流的分词算法（如 BPE，Byte Pair Encoding）会把常见词整体映射为一个 token，把生僻词拆成若干子词。英文中一个 token 平均约等于 ¾ 个单词，1000 个英文单词大约是 1300 个 token。中文情况不同：由于 UTF-8 编码下每个汉字通常占 3 字节，多数分词器会把常用汉字映射为独立 token，因此一个汉字往往对应 1 个 token，标点和空格也会单独计数。这意味着同一段内容，中文的 token 数可能比英文多出不少，做成本估算时切忌用字数直接换算。要得到准确数字，最好调用厂商提供的 tokenizer 工具或读取 API 响应里的 usage 字段，而不是凭经验拍脑袋。

Prompt 缓存是怎么省钱的？ 大模型的推理过程分两步：先把输入 prompt 过一遍前向计算得到中间状态（KV Cache），再逐 token 生成输出。如果每次请求都携带相同的长系统提示词，这部分前缀就要反复计算。Prompt 缓存让服务端把这段公共前缀的中间状态存下来复用，命中缓存的输入 token 通常只按原价的 10% 到 25% 计费。要让缓存生效，重复内容必须出现在 prompt 的最前面且字节级完全一致，任何前置的变量都会导致缓存失效。因此正确的做法是把稳定的系统提示、产品目录、few-shot 示例放前，把用户问题、时间戳等动态内容放后。对客服机器人这类多轮对话场景，历史记录天然就是可缓存的前缀，收益尤其明显。

一个够用的成本估算器

在写第一行功能代码之前，先用这个公式建立成本直觉：

def monthly_llm_cost(requests_per_month, in_tokens, out_tokens,
                     price_in_per_m, price_out_per_m):
    """Estimate monthly LLM spend in USD."""
    total_in = requests_per_month * in_tokens
    total_out = requests_per_month * out_tokens
    return (total_in / 1_000_000) * price_in_per_m + \
           (total_out / 1_000_000) * price_out_per_m

以自然语言搜索功能为例：每月10万次搜索，每次约200个输入token和100个输出token，使用每百万token输入1美元、输出5美元的小型模型，月成本约为70美元。

要获得真实的token计数，最可靠的方式是运行一批具有代表性的prompt，然后读取API响应中的usage字段。

两个真实场景的成本画像

自动标签场景。 每天处理1万个商品条目，每条约100输入token和50输出token，每月合计约3000万输入和1500万输出token。在小型廉价模型上，月成本大约在15到100美元之间——与人工打标签的工时成本相比几乎可以忽略。

客服聊天机器人。 多轮对话每轮都要重新发送历史记录，输入token会快速膨胀。这正是缓存、历史摘要和默认使用更便宜模型能产生最大差异的场景。

核心规律是：成本随使用量线性增长，而模型选择是最大的乘数因子。 同一个功能，仅仅因为默认使用了旗舰模型，成本就可能相差5到10倍。

为什么多轮对话的输入 token 会越滚越大？ 大模型本身是无状态的，它不记得上一轮说了什么。要让对话连贯，客户端必须在每次请求时把完整的历史消息重新发送一遍。于是第 N 轮请求的输入长度约等于前 N-1 轮所有消息的累积。假设每轮往返合计 300 token，那么第 20 轮的输入就已经接近 6000 token，而其中绝大部分是重复内容。这会造成两个后果：一是输入成本随轮次呈平方级增长，二是很快逼近上下文窗口上限。缓解手段有三种——利用 prompt 缓存复用历史前缀、定期把早期对话压缩成摘要、以及为简单问答默认路由到更便宜的小模型。

七条实用的降本策略

选对模型尺寸。 分类、路由和提取任务几乎不需要前沿模型。在2到3个档次上跑基准测试，选满足质量下限的最便宜那个。
精简提示词。 更短、更清晰的系统提示词配上一两个好例子，往往比冗长的提示词效果更好，而且更便宜。
缓存静态上下文。 产品目录、政策文档和风格指南是完美的缓存候选对象。
批处理非紧急任务。 如果结果不需要实时返回，就用批处理API——多数厂商提供折扣价。
使用级联策略。 让小型模型处理简单的80%，只把低置信度的case升级给更大的模型或人工。
限制输出长度。 合理设置max_tokens，因为输出才是贵的那一侧。
按功能监控支出。 给请求打上功能标签，这样你就能精确知道是产品的哪个部分在驱动成本。

自托管：开源真的"免费"吗？

Llama或Mistral这类开放权重模型确实免去了按token计费，但你换来的是GPU基础设施、运维工作和工程时间的投入。自托管通常只在两种情况下划算：使用量极大且稳定，或者数据驻留要求排除了第三方API。

对大多数团队来说，自托管的经济账在早期并不成立。

该问的问题不是"能不能负担"

真正的问题从来不是"我们是否用得起LLM"——对大多数产品而言，答案是肯定的。真正的问题是：这个功能通过转化率提升、用户留存或节省的运营时间，能否赚回它的token成本？

提前做好token计算，选择能满足需求的最小模型，从第一天起就按功能维度追踪支出。这三件事做到了，LLM成本就从不可控的焦虑变成一行可以解释的账单数字。