LLM 支出中的货币敞口
更新于 September 1, 2026 · 首次发布 September 1, 2026
几乎所有前沿模型都以美元定价。如果你的预算不是以美元计算，那么你的 LLM 成本中就有一部分是你从未主动选择承担的货币头寸。
EUR/USD 变动 6%，就意味着你的模型支出成本上涨 6%，而 token 用量没有变化，模型没有变化，任何用量仪表盘也无法解释这一点。财务部门看到了差异。工程团队看着以 token 计价的仪表盘，只看到一个平稳的月份，也无能为力。
为什么它如此难以察觉
从 API 调用到总账之间有三层换算。供应商按每百万 token 以美元定价。信用卡或账单按某个日期、某个汇率和某个点差进行换算。你的会计系统再按另一个汇率入账。等这个数字进入差异报告时，汇率因素和用量因素已经混成了同一个数字。
云市场让情况更糟，而不是更好。通过经销商或云市场以本币购买，看起来似乎消除了敞口。通常它只是把换算环节前移，并在其中加了一层利差。你仍然承担着敞口，只是再也看不到实际汇率了。
把两类差异分开
修复方法很小，完全是报告口径的调整。在遥测数据中，把每个请求的成本以供应商标价的美元金额作为主要数字记录。在报告边界处，以一个明确声明的汇率，将其一次性换算为你的报告货币。这样，月度差异就能干净地拆分为两部分：工程团队负责并能采取行动的用量差异，以及财务团队负责、工程团队无法修复的汇率差异。
两个团队为同一个数字争论，这才是真正的成本。它比汇率波动本身更昂贵，因为它浪费了本应用来发现真实增长的那次审查。
什么时候值得对冲
很少，而且只有在规模足够大时才值得。对大多数公司来说，正确的应对是可见性，而不是对冲：了解敞口有多大，声明你预测所用的汇率，并停止让财务效应冒充工程效应。只有当模型支出大到足以与公司其他美元成本相提并论时，对冲才成为一个实际的讨论，而那时它应当与这些成本一起处理，而不是放在 FinOps 审查里。
一个实用提示：如果你改签了本币合同，请把换算价格算清楚。用自己的货币锁定汇率值得付出一点代价，但如果其中隐含的点差大于它所消除的波动，那就毫无价值。
相关阅读
相关文章
想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 →