算力市场与单位经济性

整套技术栈归根结底是一套花钱的方式，但发票还不是经济模型。本章要回答三个问题：算力从哪里购买，训练和推理为何是两类不同的成本，以及何时应该自建模型，何时应该通过 API 购买能力。对于「推理是否主导全生命周期成本」这个常见判断，本章也会用数据检验，而不会直接把它当作前提。

这些问题的答案都取决于明确的工作负载、服务目标、时间范围和核算边界。即使词元单价很低，只要模型需要生成很长的答案、反复尝试、调用工具或接受人工复核，最终产品仍可能十分昂贵。自托管模型即使速度很快，如果必须为少见的流量峰值长期保留大量闲置容量，经济上也未必划算。因此，真正有用的指标是每个合格结果的成本，而且只能比较满足同一份运行契约的方案。

拆开三个不同的决策

「自建还是购买」实际上把三个成本结构和退出路径都不同的决策混在了一起：

1. 创建还是获取能力。 团队可以从头训练，在现有模型上继续训练或微调，直接使用开放权重，也可以购买托管模型的访问权限。
2. 自行运行还是外包服务。 开放权重可以运行在自有或租用的容量上，也可以交给托管端点运行；提供商 API 则把模型和服务打包出售。训练一个模型和自行托管一个模型不是同一个决策。
3. 采购哪种容量。 自有容量、预留容量、按需容量和可中断的竞价容量，在价格、承诺期限、容量保障和中断风险之间做出了不同交换。

先判断可行性，再比较价格。如果某个候选方案达不到质量门槛、尾延迟目标、可用性目标、隐私边界、安全控制、许可条款或人工复核要求，它就不能与其他方案做经济比较。尾延迟是契约的一部分，不能只在平均吞吐量旁边加一句说明。提供商也可能提供私有网络、区域内处理、专用容量或托管开放权重，因此，非价格约束并不必然意味着从头训练。

第 75 章 给出了带版本的组件契约。成本记录必须把账本和预测绑定到通过这些契约的精确组合，包括模型、运行时、配置、策略、工作负载和证据。

建立完整的成本账本

先选定评估周期，例如一个月，并始终明确区分现金单位与资源单位。一份实用的全成本账本可以写成

$$\begin{aligned} C_{\mathrm{total}} &= C_{\mathrm{build}} \\ &\quad + \sum_{t=1}^{T}\bigl( C_{\mathrm{run},t} + C_{\mathrm{people},t} \\ &\qquad + C_{\mathrm{data},t} + C_{\mathrm{network},t} \\ &\qquad + C_{\mathrm{failure},t}\bigr), \\ u_{\mathrm{accept}} &= \frac{C_{\mathrm{total}}}{N_{\mathrm{accept}}}. \end{aligned}$$

这些符号分别明确了核算边界：

• $C_{\mathrm{total}}$ 是在整个评估期内分配给被评系统的全部成本；$C_{\mathrm{build}}$ 是常规运行之前发生的实验、模型适配、集成、评估和上线成本。
• $t$ 表示一个评估周期，$T$ 表示既定时间范围内的周期总数。求和项把各周期的经常性成本加在一起。
• $C_{\mathrm{run},t}$ 包括周期 $t$ 内的算力、存储、许可证、能源和托管服务；$C_{\mathrm{people},t}$ 包括工程、运维、支持、安全和复核人员的成本。
• $C_{\mathrm{data},t}$ 包括数据获取、标注、保留与删除；$C_{\mathrm{network},t}$ 包括传输、私有连接和出口流量；$C_{\mathrm{failure},t}$ 包括失败与重试工作、事故响应、赔偿额度和资源浪费。
• $N_{\mathrm{accept}}$ 只统计满足既定质量、延迟、策略和完成条件的结果。两者相除得到 $u_{\mathrm{accept}}$，也就是每个合格结果的全成本。

账本还需要一条写清楚的共享成本分摊规则。网关、评估团队、可观测系统或预留集群往往同时服务多个产品。把全部成本都算给最新产品，会夸大它的成本；完全不分摊，又会隐藏真实依赖。应当记录分摊依据，例如加速器小时数、请求数、存储字节数或人员工时，并分别展示计入与不计入有争议的分摊项时的结果。

分母与分子同样重要。原始请求数会把格式错误的调用、策略拒绝、重试以及未完成任务的答案都算进去；原始输出词元数还可能奖励冗长回答。合格结果必须沿用发布时使用的评估与服务契约。对于探索性系统，与其强行选一个分母，不如同时报告每次请求、每个合格结果、每个已解决案例以及每单位用户价值的成本。

按实际完成的工作衡量服务成本

对于租用或自有的加速器容量，可以先单独计算单位成本中的加速器部分：

$$C_{\mathrm{accel}} = r_{\mathrm{eff}} H_{\mathrm{billed}}, \qquad u_{\mathrm{accel}} = \frac{C_{\mathrm{accel}}}{N_{\mathrm{accept}}} = \frac{r_{\mathrm{eff}}H_{\mathrm{billed}}} {N_{\mathrm{accept}}}.$$

式中，$C_{\mathrm{accel}}$ 是分配给该工作负载的加速器容量成本。有效价格 $r_{\mathrm{eff}}$ 是计入承诺折扣、其他折扣和已分摊自有成本后，每个计费加速器小时的价格。$H_{\mathrm{billed}}$ 是付费购买的加速器小时总数，其中也包括闲置的预留容量；$N_{\mathrm{accept}}$ 是这些小时产出的合格结果数。两者之比 $u_{\mathrm{accel}}$，就是每个合格结果承担的加速器容量成本。

$N_{\mathrm{accept}}/H_{\mathrm{billed}}$ 是实际吞吐量。它已经包含闲置预留、批处理、失败工作和实际请求组合的影响，因此不要再除以一次利用率。如果实验室基准只给出满载吞吐量，才可以用一次利用率来估算实际吞吐量，而且还必须用生产遥测加以核验。

只有同时说明词元类别和请求组合，按词元报告成本才有意义。提供商可能对输入词元、缓存词元和输出词元采用不同价格；自托管系统中的预填充和解码也会以不同方式占用硬件。工具调用、推测执行、被拒绝的输出和内部推理，都会增加最终响应中看不见的工作量。报告单位成本时，应当在同一处给出提示词与输出长度分布、缓存命中率、批处理与并发策略、p50、p95 和 p99 延迟、错误率以及合格结果吞吐量。

第五部分的服务章节解释了这些技术手段。第 32 章 中的批处理可以提高实际吞吐量；第 33 章 中的解码优化和 第 34 章 中的内核优化，可以减少完成同一批合格工作负载所需的计费小时。第五部分的这些服务手段，只有在质量与服务门槛仍然达标时才会改善经济性。评估第五部分的服务优化时，必须把完整账本一起算进去，因为工程投入、更大的副本或更低的缓存命中率，都可能抵消单项内核优化带来的收益。

不同算力产品承诺的东西不同

一条小时报价并不能说明买到的究竟是什么。不同采购方式附带不同的权利和风险。即使承诺使用后小时单价更低，承诺本身的风险也必须纳入比较：

以 AWS 为例，其文档区分按需实例、竞价实例、节省承诺、容量预留和定时加速器容量；竞价实例可能在提前两分钟通知后被中断 (Amazon Web Services 2026)。这种产品细节不能直接推广到所有提供商。通用做法是把报价换算为有效成本，并计入未使用的承诺量、中断、检查点与重启成本、区域限制、存储、网络和出口流量。

电力和冷却也属于账本。国际能源署在 2025 年分析数据中心用电需求时，分别核算服务器、存储与网络设备，以及机房基础设施 (International Energy Agency 2025)。第 68 章 进一步加入了站点和供电时间契约。一份价格很低的加速器预留，如果电力无法按期交付，就不是可行容量。

看清历史成本数据的边界

随着模型从实验走向大规模服务，经济问题也发生了变化。Hoffmann 等人在 2022 年的 Chinchilla 研究中，估算了在固定训练算力预算下，使损失最小的模型规模与训练词元分配 (Hoffmann et al. 2022)。Sardana 等人在 2024 年把固定质量目标下的推理需求预测加入这一问题。在他们拟合的范围内，足够高的需求更有利于用更多词元训练较小的模型 (Sardana et al. 2024)。这个结论取决于质量目标、需求预测、拟合出的扩展规律和成本假设，并不代表某一种模型形状能让所有部署的全生命周期成本最低。

Cottier 等人估算了约 45 个前沿模型最后一次训练的加速器硬件与能源摊销成本。按其拟合结果，自 2016 年起这一成本每年约增长 2.4 倍，但不确定性很大 (Cottier et al. 2024)。这是对一组特定前沿模型的估算，不是经过审计的现金支出，也不是模型开发的全部成本。研究、消融、数据处理、失败训练、评估、人员以及购买整个设备集群的成本，都需要另行核算。

DeepSeek-V3 提供了另一类记录。其技术报告自行报告称，一个总参数量 6710 亿、每个词元激活 370 亿参数的混合专家模型，完整正式训练流程消耗了 278.8 万个 H800 GPU 小时 (DeepSeek-AI 2024)。报告中的美元估值使用了假设的小时费率，也没有计入此前的架构、算法和数据研究及消融。GPU 小时数可以作为作者声明的资源记录复核，但它不是经过审计的开发总成本，也不能证明其他团队能以相同价格得到相同结果。

分析 API 价格趋势时也要遵守同样的边界。Epoch AI 的一项分析比较了在六项基准上达到固定能力门槛所需的标价，发现不同任务在观察期内的降幅差异很大 (Cottier et al. 2025)。这种比较比直接比较模型名称更可靠，但结果仍与任务有关，而且采用了明确的输入与输出价格权重。标价并不等于提供商的生产成本，基准门槛也不等于应用中的合格结果。必须记录能力变化，也不要把短期历史降幅外推成必然的预测。

按场景比较购买与自托管

先计算按场景折现后的总成本，再使用盈亏平衡的简化公式。对于一个预测场景，

$$C_{\mathrm{buy}} = \sum_{t=1}^{T} d_t B_t, \qquad C_{\mathrm{self}} = F_0 + \sum_{t=1}^{T} d_t S_t, \qquad d_t = (1+r)^{-t}.$$

换句话说，这组公式先把各方案每个周期的成本相加，再用折现因子 $d_t$ 把它们换算到同一个决策日期。

如果存在多个不确定场景，则有

$$\mathbb{E}[C_a] = \sum_{s=1}^{S} \pi_s C_{a,s}.$$

这些符号把时间与不确定性分开：

• $C_{\mathrm{buy}}$ 和 $C_{\mathrm{self}}$ 分别表示购买托管服务和自托管方案折现后的全成本。下标 $t$ 表示 $T$ 个规划周期中的一个。
• $d_t$ 是周期 $t$ 现金流的折现因子，$r$ 是每个周期的小数形式折现率。
• $B_t$ 是周期 $t$ 的购买侧账本，包括输入、缓存与输出价格，以及请求、工具、复核、网络和支持成本。
• $F_0$ 是自托管初期的集成、评估、迁移、预留容量和上线成本；$S_t$ 是之后各周期的容量、人员、数据、网络、故障和退出准备成本。
• 下标 $a$ 表示一个候选方案。下标 $s$ 表示 $S$ 个需求、价格、容量与故障场景中的一个；$\pi_s$ 是该场景的概率权重，所有权重之和为一。
• $C_{a,s}$ 是方案 $a$ 在场景 $s$ 下的折现成本，期望值 $\mathbb{E}[C_a]$ 是各场景按概率加权后的平均值。

至少要覆盖低、中、高三种需求，API 价格下降较慢与较快两种情况，以及一次容量短缺、一次模型迁移和一次严重事故。除了折现后的总额，还应展示未折现的年度现金流。期望成本不能取代尾部风险限制，均值更低的方案仍可能隐藏无法接受的停机或现金承诺。

常见的线性近似是

$$V^* = \frac{F}{p-c}, \qquad p > c.$$

$V^*$ 表示两条线性成本曲线相等时的用量。$F$ 是 API 方案没有、但自托管必须承担的固定成本；$p$ 是每个可比单位的固定 API 全成本；$c$ 是每个单位的固定自托管边际成本。只有满足 $p>c$，交叉点才是正数且有限。

这个公式只是诊断工具，不是决策本身。它假设两种方案提供相同能力与服务，价格不变，边际成本保持线性，没有容量台阶，也没有不确定性、切换成本或退出成本。现实中的自托管容量会随着副本增加而按离散台阶增加；协商后的 API 价格则可能包含阶梯折扣和最低承诺量。交互图可以帮助理解几何关系，真正的决策仍要回到场景与敏感性分析。

下面的小程序明确展示了四组假设。需求以百万个可比单位计量，仅仅改变 API 价格、需求量或应对峰值所需的固定容量，就可能使结论反转。

self_rate = 0.25  # dollars per million comparable units

scenarios = [
    ("base", 1_600_000, 2.00, 2_650_000),
    ("api-price-down", 1_600_000, 1.30, 2_650_000),
    ("demand-down", 800_000, 2.00, 2_650_000),
    ("peak-capacity-up", 1_600_000, 2.00, 3_250_000),
]

for label, volume, api_rate, self_fixed in scenarios:
    buy = volume * api_rate
    self_host = self_fixed + volume * self_rate
    choice = "self-host" if self_host < buy else "API"
    print(
        f"{label}: buy=${buy/1e6:.2f}M "
        f"self=${self_host/1e6:.2f}M -> {choice}"
    )

用分布而非平均值描述需求

平均需求不能充当容量规划。必须记录请求的到达分布、请求与响应大小、并发量、地理分布和突发流量。自托管设备集群还要为维护、故障和既定尾延迟目标留出余量。一旦峰值越过下一个副本或集群边界，成本就会按台阶上升，而不是沿着平滑的边际成本曲线增长。

评估至少应覆盖一个代表性的稳定时段、一个 p50 日、一个 p95 峰值和一个 p99 压力时段。还要重放足以形成队列的突发流量，移除一个故障域并测量恢复过程。对于训练和批处理任务，应记录截止时间的弹性和检查点频率，因为这些因素决定了计入浪费工作与重启成本后，竞价实例的中断是否真的省钱。

需求不确定性也会影响购买侧。配额可能让名义上可弹性扩展的容量无法及时到位，批量折扣可能使价格变成非线性，提供商修订模型也可能改变质量或词元用量。应当锁定报价与模型修订版本的日期，并在任一项发生变化时重新比较。

区分现金流、会计费用与经济成本

资本性支出（CapEx） 指投入自有加速器、数据中心设备等长期资产的现金。API 调用、租用算力、电费和许多运维成本通常属于 运营性支出（OpEx），也就是经常发生的运营费用。模型开发本身并不天然属于其中一类：云上训练和研究人员成本可以是运营费用，自有训练硬件则是资本资产；重新训练和评估也会反复发生。

三个视角回答不同的问题：

• 现金流记录资金何时流入或流出组织，用来检验流动性和融资需求。
• 会计费用遵循适用的报告政策。折旧会在资产的预计使用寿命内分摊其账面成本。
• 经济成本还包括放弃的最佳替代方案，也就是机会成本，以及运行风险、切换成本和预期残值。

改变折旧估计只会改变会计费用确认的时间，不会改变已经支付的现金。例如，Amazon 报告称，它在 2024 年把服务器使用寿命从五年延长到六年，随后又在 2025 年把部分服务器和网络设备缩短回五年 (Amazon.com, Inc. 2026)。这份申报文件只能证明估计发生过调整，不能说明所有加速器的正确使用寿命。比较自有容量与租用容量时，团队应当展示使用寿命和残值的敏感性，并计入物理故障、性能过时以及旧硬件的后续用途。

融资是第四个视角。债务、租赁或特殊目的载体会改变现金发生的时间、必要回报、契约限制和剩余风险的承担者，却不会让底层容量变成免费资源。国际清算银行的研究人员记录了 2025 年基础设施建设中不断增加的债券发行和表外结构 (Eren et al. 2026)。对于产品决策，融资条件应体现在折现率、固定承诺和下行情景中。除非有明确的分摊规则，否则不应把融资成本直接混入词元成本的分子。

持续校准经济模型

经济决策应当形成控制循环，而不是只做一次的电子表格：

1. 冻结工作负载。 对候选模型、请求组合、验收规则、服务目标、策略边界、时间范围和需求场景进行版本化。
2. 筛选可行方案。 剔除无法通过质量、延迟、可用性、隐私、安全、许可、区域或交付日期门槛的方案。
3. 测量候选方案。 使用同一工作负载，对精确的 API 修订版本和精确的自托管组合进行基准测试，其中包括故障测试与峰值测试。
4. 统一成本账本。 对所有方案采用相同的成本类别、共享成本分摊规则、汇率日期和合格结果分母。
5. 建立场景模型。 改变需求、价格、容量台阶、使用寿命、事故、迁移和退役假设，并发布敏感性分析。
6. 演练退出。 导出状态，更换提供商或运行时，恢复服务，并按实测结果计算切换成本与退出成本。
7. 批准承诺。 记录选定场景、负责人、预算、预留或合同条款、复核日期和回滚触发条件。
8. 核对实际结果。 每个周期把发票、遥测、评估结果和事故记录连接起来，解释预测误差并重新执行决策流程。

证据记录应保留报价与发票版本、模型和运行时摘要、工作负载与验收规则摘要、已计费容量与有效容量、词元类别、合格结果、人员成本分摊、事故记录，以及批准决策时使用的预测。如果缺少这些输入，成本偏差就无法区分价格漂移、需求预测错误、质量不合格或运行退化。

第 77 章 将从单个购买方的账本向外展开，考察决定供给、议价能力和利润率的价值链。两章之间的衔接很明确：本章衡量一个可行方案要花多少钱，下一章解释这些价格和选择为何存在。便宜的词元不一定带来便宜的结果。

延伸阅读