相同的 Token 单价，不同的账单

某个团队把工作负载迁移到推理模型，看到与以往相同的 Token 单价，却发现了一个新的旋钮：推理强度。把它调高几乎感觉是免费的 — 那为什么不在所有地方都买更好的答案呢？然而，可见的输出几乎没变，账单却上去了。原因是隐藏的“思考”Token：推理模型会生成并对其计费，但从不在响应中展示。本项目在一组有代表性的少量任务上，测量这些额外 Token 何时物有所值、何时只会让账单膨胀。

团队为何关心

模型迁移之后，落到工程师面前的问题很直接：成本为什么变了，延迟为什么变了，为什么限流变多了？推理强度正处于这三者之下。若默认保持高档，它会悄悄把 Token 花在永远到不了读者面前的内部计算上 — 在即用即付下是真金白银，在预配容量下是宝贵的余量。知道强度究竟在哪里真正改变答案，正是一次有把握的上线与账单上意外之间的区别。

我们测了什么

我们固定提示词与工作负载切片，对每个切片应用相同的推理强度阶梯 — 简短的事实性回答、从结构化数据到自然语言的转换、多步推理，以及使用工具的智能体 — 并在每次调用时记录完整的用量明细：输入、缓存、推理与输出 Token，外加质量信号和延迟。在这一实测的 Token 构成之上，我们叠加了一层建模视角：同一工作负载在即用即付（PAYG）与预配吞吐量（PTU）下分别如何计费。

证据揭示了什么

结果像好的证据应有的那样分化了 — 有些地方强度物有所值，有些地方只买到了隐藏的计算。四条要点贯穿各个切片。

务必测量推理 Token

它们会被计费却不会返回。请在每次调用时记录完整的用量明细—— 输入、缓存、推理和输出。

并非每个任务都需要推理

在简短的事实性回答、从结构化数据到自然语言的转换以及简单分类中，成本上升却往往没有相应的质量提升。

推理强度是主要的成本杠杆

将推理强度旋钮默认设为最低档，仅当质量评估证明这笔支出合理时才调高。

计费模式会改变收益

在即用即付（PAYG）下，减少推理 Token 会降低账单。在预配吞吐量（PTU）下，同样的削减会在固定账单下转化为吞吐量提升。

适用人群

面向运行 Azure OpenAI 部署的工程师与架构师：正在决定是否（以及在多大程度上）启用推理、评估容量规模，或在模型迁移后排查成本、延迟或限流方面的变化。

接下来读什么

阅读概览文章

有引导的故事：强度在哪里浪费支出、在哪里值得一试，以及为什么必须把隐藏 Token 明确纳入预算。开始阅读 →

浏览文章中心

完整的阅读脉络 — 证据主题、衔接文章，以及关于恢复、缓存与容量规划的运维笔记。打开中心 →

查看证据看板

审计线索：每条论断背后受治理的表格与渲染的源图表。打开看板 →

阅读完整方法论

决策框架与运维指南位于仓库文档中。在 GitHub 上查看 →

术语表

Foundry: Azure AI Foundry — 用于部署和提供本项目所测模型的托管平台。
PTU: 预配吞吐量单位 — 按吞吐量而非按 Token 计费的预留固定容量计费方式。
PAYG: 即用即付 — 按输入、缓存、推理和输出 Token 计费的消耗型计费。
推理 Token: 推理模型生成并计费、但从不在响应中返回的内部"思考"Token。
缓存: 提示缓存 — 复用先前已处理的提示前缀，以更低的缓存输入单价计费。
429: HTTP 429 Too Many Requests — 当部署超出其速率或容量上限时返回的限流响应。