跳到主内容
@wquguru
精选88r/LLMDevs(Reddit)技巧与观点

开发者自建日志追踪OpenAI账单,揭示缓存与推理Token计费陷阱

I built a tiny logger to prove which feature was eating my OpenAI budget. Fell into a rabbit hole of people getting hit way harder

原文
发到 X
推荐理由

做LLM应用开发的必看实操指南,详细拆解了缓存、推理和音频Token的计费陷阱,直接解决成本控制痛点。

This started as a small itch.

这一切始于一个小小的困扰。

OpenAI gave me one number every month: total spend. I wanted to know which feature in my app was spending it. I've got a code-gen feature, a summarizer, and a couple of smaller things running in the background. My money was on the code one, obviously, but I had no way to actually check.

OpenAI 每月只给我提供一个数字:总支出。我想知道我的应用中是哪个功能在消耗这些费用。我有一个代码生成功能、一个摘要器,以及几个在后台运行的小功能。我原本把钱押在代码生成上,显然,但我没有任何方法可以实际验证这一点。

So I built a tiny thing for myself. Every response already comes back with a usage object, so after each call I log the token counts plus a feature name, then price them myself. One line per call. I only wanted visibility, nothing more.

所以我为自己构建了一个小工具。每个响应都会返回一个 usage 对象,因此每次调用后,我会记录 token 数量加上功能名称,然后自己计算价格。每次调用一行日志。我只想要可见性,别无其他。

The "price them myself" part was way more annoying than I expected:

"自己计算价格"这部分比我预期的要烦人得多:

  • cached reads bill at a different rate than normal input, and cache writes can cost more than normal input
  • reasoning tokens bill as output even though you never see them
  • providers disagree on whether cached tokens sit inside the prompt count or next to it. I double-counted them for a while before catching it
  • audio tokens can cost several times the text rate on the same model, so blending them with text gives you garbage
  • 缓存读取的计费费率与普通输入不同,而缓存写入的成本可能高于普通输入
  • 推理 token 按输出计费,尽管你从未见过它们
  • 各提供商对于缓存 token 是计入 prompt 计数还是单独列出存在分歧。我在发现这个问题之前有一段时间重复计算了它们
  • 音频 token 在同一模型上的成本可能是文本费率的数倍,因此将它们与文本混合会导致数据失真

Then I got curious whether anyone else cared, and went looking. Turns out my small itch was the door into a rabbit hole:

然后我好奇是否有人也在意这件事,于是去查找了一番。结果发现,我这点小困扰竟是一个兔子洞的入口:

  • someone on Google's AI dev forum got around €290 in search charges attached to like €10 of actual LLM usage, and their spend cap never caught it
  • a dev on DEV wrote that the job that blew up their bill was green on every dashboard they had. A timeout plus auto-retry on long-context calls was quietly doubling costs, and it took weeks to figure out
  • one startup reported a $113k AI bill in a single month
  • Google AI 开发者论坛上有个人遇到了约 €290 的搜索费用,而实际的 LLM 使用量仅约 €10,且他们的支出上限未能捕捉到这一异常
  • DEV 上一位开发者写道,导致账单爆炸的那个任务在他们所有的仪表板上都显示为绿色。长上下文调用的超时加上自动重试悄悄地将成本翻了一倍,花了数周时间才查明原因
  • 有一家初创公司报告单月 AI 账单高达 11.3 万美元

For me it was curiosity. For them it was money leaving before anyone could see where it was going.

对我而言是好奇心。对他们而言则是资金在无人察觉去向的情况下流失。

Full honesty: I have little to no experience building products. What I'm decent at is digging into other people's problems, so I kept going. More features, more providers and models, learning what proxies and gateways actually are, reading how Langfuse and Helicone handle this. The logger eventually turned into an actual product (LLMtrack), but honestly I'm more curious how you all deal with it:

坦诚地说,我几乎没有构建产品的经验。我擅长的是深入挖掘他人的问题,所以我继续前行。增加了更多功能、支持更多提供商和模型,学习代理(proxies)和网关(gateways)到底是什么,阅读 Langfuse 和 Helicone 如何处理此类问题。这个日志工具最终变成了一个真正的产品(LLMtrack),但说实话,我更好奇你们大家是如何应对的:

  • Do you track LLM cost per feature or per customer at all, or just watch the provider total?
  • If one feature started costing 5x more today, how long until you'd notice?
  • Anyone who rolled their own: did you hit the cached-token double-count thing too, or was that just me?
  • 你会按功能或按客户追踪 LLM 成本吗?还是只看提供商的总账单?
  • 如果一个功能的成本今天突然增加了 5 倍,你需要多久才能注意到?
  • 任何自行实现的人:你们也遇到过缓存 token 重复计算的问题吗?还是只有我一个人这样?

Oh, and yes, it was the code feature eating most of my money, about 70% of the bill. I knew it. Funny part: by tokens, the summarizer was way bigger (129M vs ~30M), and it cost $14 total. If I'd only looked at token counts, I'd have blamed the wrong thing.

哦,对了,是的,代码功能花了我最多的钱,占了账单的约70%。我心里有数。有趣的部分是:按token计算,摘要器要大得多(1.29亿 vs 约3000万),总花费为14美元。如果我只看token数量,我就会怪错对象了。

更进一步:量化金融体系

看懂新闻只是起点——沿量化金融路径,把它变成能交付的工程能力

进入量化体系 →

相似阅读

关联信息,但可能不是同一事件