大模型 API 的钱花在哪：输入、输出、缓存与失败调用拆解 多模型统一接入，按场景配置路由与配额 先把账拆开：一笔调用到底由哪几块钱组成 很多企业第一次看大模型账单时的反应是一样的：明明业务量不大，钱怎么花得这么快。原因通常不是单价高，而是没人把费用拆开看。我们在帮客户做 API 成本梳理时，习惯把一笔调用的费用分成四块：输入 token、输出 token、缓存、重试与失败调用。前两块是明面上的，后两块是账单上不写、但真金白银流走的。 先说一个前提，也是我们踩过的坑：不同供应商的计费口径并不统一。有的把系统提示词也计入输入，有的对缓存命中单独定价，有的输出按生成 token 计、有的把思考过程也算进去，还有的按「请求次数 + token」双轨收费。所以看到「每百万 token 多少元」就直接横向比价，结论往往是错的。比较之前先统一口径：同样一段提示词、同样长度的输出、同样开启或不开启缓存，各跑一次，把实际扣费拉平到「一次有效业务调用多少钱」，这才有可比性。详细的服务范围与计费方式可以看我们的模型 API 与成本管理页面。 第一块：输入 token，最容易被悄悄放大的部分 输入 token 单价通常比输出低，所以很多人不当回事。但输入的量级往往远超预期，因为它由提示词模板、历史对话、检索到的资料、工具返回结果共同堆出来。一个客服问答场景，如果每轮都带上完整历史对话和前五条知识库片段，输入很容易从 800 token 涨到 6000 token，费用直接翻几倍，而回答质量未必提升。 我们通常做三个动作：去掉模板里没人看的说明性文字；历史对话只保留最近若干轮并做摘要压缩；检索片段按实际需要条数取，而不是固定塞满。这三步不涉及换模型，也不改业务流程，纯靠改提示词结构，很多客户输入侧能降下来一半左右——具体幅度取决于原始提示词有多臃肿，不能一概而论。 输出 token：贵在它不可控 输出单价高，更麻烦的是它由模型自己决定长度。同一句「请总结这段内容」，模型可能回 80 字也可能回 400 字。业务上常见的浪费是：让模型输出整段 JSON、再用代码解析其中两个字段；或者要求「详细说明」却没有字数约束；或者把不需要推理的简单分类任务交给会展开讲道理的模型。 实操上，输出侧最有效的三个约束是：明确字数或条目上限、用结构化输出减少解释性文字、把「思考」和「回答」分开控制。另外提醒一句，结构化输出如果字段设计得过于宽泛，模型会自己补内容，长度反而涨。字段能少就少。 第二块：缓存，省钱的杠杆也是算错账的重灾区…