成本控制清单

大模型 API 接入较快，但如果缺少成本控制机制，业务上线后可能出现费用增长过快、单个功能消耗异常或批量任务费用超出预期等问题。AI 助手、Agent、知识库问答、代码生成和批量处理场景尤其需要在上线前建立成本控制机制。

为不同业务创建独立 API Key

不建议所有环境和业务共用同一个 API Key。建议按以下维度拆分：

拆分后，可以在用量统计中清楚看到不同来源的 Token 消耗，也方便异常时快速定位和处理。Key 拆分不是权限控制的替代品，仍应为每个 Key 设置最小权限、来源限制和轮换流程。

给调用链路增加限制

成本控制也是系统稳定性控制。上线前建议增加：

• 单用户调用频率限制
• 单任务最大调用轮次限制
• 单次请求最大输入长度限制
• 单次输出 Token 上限
• 失败重试次数限制
• 批量任务总量限制
• 图片数量、尺寸和质量限制
• 视频最大时长、FPS、分辨率和并发限制
• 音频时长、文件大小和单任务处理时长限制
• 异常消耗告警

Agent 场景尤其需要同时控制自动循环次数、工具调用次数和模型请求总数，避免任务无法完成时反复消耗 Token。一次用户操作可能触发多次规划、工具结果总结和重试请求，不能只按用户点击次数做预算。

明确不同任务使用什么模型

很多成本浪费来自所有任务都使用高性能模型。更合理的方式是做模型分层：

如果业务对效果要求较高，可以先建立评测集，用实际样本比较不同模型的质量、延迟和完整调用成本，再决定默认模型。多模态场景还要确认模型是否支持目标输入类型，以及输入媒体的计费规则，不要只比较文本 Token 单价。

控制上下文

大模型上下文越长，输入 Token 越多，成本通常也越高。上线前检查：

• 是否每次都传入完整历史对话？
• 是否把整篇文档传给模型，而不是相关片段？
• 是否携带过多系统说明、工具描述和示例？
• 是否存在重复字段、无用 JSON 或过长日志？
• 是否可以通过检索、摘要或缓存减少输入？
• 是否把时间戳、用户问题和实时数据误放进缓存前缀？

知识库问答应优先传入命中的片段，而不是整篇文档；多轮对话则应定期压缩历史上下文。稳定且会被短时间内重复使用的长上下文可以测试缓存，但要用缓存读取 Token 和实际费用验证收益，不能只因为设置了 cache_control 就认为成本会下降。

控制输出长度

输出费用取决于具体模型的计费项。无论输出单价高低，限制无用输出都能减少延迟、上下文膨胀和后续轮次的输入成本。建议在提示词或 API 参数中设置：

• 最大输出 Token 数
• 固定输出结构
• 字数或条数限制
• 不需要解释过程时直接给结论

例如，将“请详细分析”改成“请用 5 条要点总结，每条不超过 50 字”。

上线后持续监控

建立预算和告警

不要只设置一个月度总预算。至少按模型、API Key、租户或业务线拆分预算，并为以下指标设置日、周或月阈值：

• 单位时间 Token 或媒体任务用量较过去基线的增长比例。
• 单次用户操作的平均模型请求数和 P95 请求数。
• 单个 API Key 的消费占比和异常增量。
• 图片、视频任务的提交数、终态失败数和平均生成参数。
• 缓存命中率、缓存写入量和单位任务成本。

告警触发后先暂停批处理或降低并发，再通过请求 ID、任务 ID 和 API Key 定位来源；不要直接通过无限重试来“恢复”业务。

小结

大模型成本控制应在上线前完成设计，而不是等账单异常后再处理。通过 Key 与权限拆分、请求和媒体参数限制、模型评测、上下文压缩、缓存验证、幂等重试和持续监控，团队才能解释每一笔费用从哪里产生。