【CSDN 编者按】在 AI 技术飞速发展的今天，OpenAI API 已成为众多 SaaS 开发者手中的得力工具。但高额的 Token 消耗，也让成本控制成为开发者不得不面对的难题。本文作者以一个月消耗 94 亿 Token 的实战经历，毫无保留地分享了优化成本的关键经验。
原文链接：https://www.reddit.com/r/LLMDevs/comments/1kigp51/spent_9400000000_openai_tokens_in_april_here_is/
选对模型是关键中的关键
我知道这听起来像废话，但这真的很重要。不同模型之间的价格差距巨大，我们通过大量测试，最终挑选了“最便宜但效果还不错”的组合：简单任务主要用 GPT-4o-mini，复杂一点的才上 GPT-4.1。
我们的业务并不需要强逻辑推理能力的模型（比如 GPT-4 Turbo），所以可以放心避开高价位的模型。虽然测试确实花了不少时间，但从长期来看绝对值得。
用好提示词缓存（Prompt Caching）
这点完全是意外收获。OpenAI 平台会自动缓存完全一致的提示词（prompt），在重复调用相同的 prompt 时，不仅速度提升，成本也能大幅下降！
我们实测发现：对于长提示词，延迟最多减少 80%，成本也降低近 50%。还有一点很重要：确保 prompt 中的“变化部分”放在末尾，否则缓存机制可能无法命中。除了这一点，其他都不用额外配置，真的省心又高效。
务必设置账单预警！
一定要开通账单提醒！我们就是因为没设置，一不小心 5 天就把整个月的预算都烧光了……
优化提示词结构，尽量减少输出 Token 数量
你知道吗？OpenAI 平台上“输出 Token”的价格是“输入 Token”的 4 倍！
所以我们优化了模型的输出方式：不再让它输出完整的文本结果，而是改为只返回位置编号和类别，然后在代码中进行映射。这一个小改动，让我们的输出 Token 数量直接减少约 70%，调用延迟也大大降低！
使用 Batch API 处理非实时任务
如果你有不需要即时返回的任务，比如夜间批处理类操作，强烈推荐用 Batch API（一个专门设计来处理大量数据的批处理服务）！我们把一批夜间处理逻辑迁移到了 Batch API 上，直接省了一半的费用。虽然它有 24 小时的处理窗口，但对非实时业务完全没问题，强烈推荐。
写在最后：这些经验教训是我们在烧掉 94 亿个 Token 之后，边踩坑边总结出来的，希望能帮大家避雷。如果你也在做 AI API 集成，欢迎补充一些实用技巧！
“这值得烧掉 94 亿个 Token 吗？”
然而，对于上面的这些建议和总结，多数网友的第一反应都是：就这，值得烧掉 94 亿个 Token 吗？
-
“你要是早点看 OpenAI 官方文档里 Best Practices 这部分，可能早就省下一大堆Token了……”
-
“不是我说你，这些经验教训其实应该是你在系统设计阶段就该思考的问题，而不应该靠‘烧钱’试出来。”
也有部分网友提出疑问，为什么不试试其他更便宜的模型：
-
“重点问题来了——你到底是干了啥，要用掉 94 亿 Token？！你有没有尝试过其他模型？有打算把 ChatGPT 换掉吗？”
-
“内容不错，不过我很想知道你们的 SaaS 业务究竟做什么的，竟然要用这么多 Token！有没有考虑过 Gemini 这种更便宜、支持多模态和 100 万 Token 上下文的模型？为啥一直坚持用 OpenAI 的模型？”
同时，个别开发者也指出，有些建议并不适用于所有情景：
-
“我想就第 4 点进行补充。虽然压缩输出 Token 听起来很划算，但有时候适当提供足够的输出空间，其实有助于大模型‘思考清晰、计算准确、提升答案自信度’，而限制 Token 可能会影响推理质量。如果你对 Token 预算很敏感，不妨考虑是不是这项任务根本不需要大模型来处理——用传统逻辑就够了。优秀的 Prompt 设计，是清晰、贴切、符合语境，而不是一味地压榨 Token 空间。”
（文：AI科技大本营）