1. 先确定在算哪一张账
至少有五种常被写成“AI 成本”的数字。
第一种是一次正式训练运行:在既定模型设计、数据和训练方案下,完成预训练、上下文扩展或后训练所消耗的计算。第二种是从研究到发布的完整开发:除正式运行外,还包括架构探索、消融实验、失败运行、数据获取与清洗、研究和工程人员、评测、安全工作。第三种是稳定推理服务:硬件折旧、租赁、网络、能源、运维、冗余和未被充分利用的容量会持续发生。第四种是云或 API 对外价格。第五种才是客户总拥有成本,它还包括集成、内部人工、人工复核、错误处理、迁移和业务失败。
五层边界不是要求企业维护五套互不相干的账,而是防止同一笔支出被遗漏或重复计算。例如,供应商购买服务器属于资本投入,随后会通过折旧进入服务成本;客户支付的 API 账单已经包含供应商向客户转移的部分成本,客户不应再把供应商的整套设备投资原样加进自己的 TCO。相反,客户为接入 API 进行的数据治理、评测和人审并不在 token 报价里,必须另行记录。成本归属于哪一层,取决于谁拥有资产、谁承担风险以及所比较的时间段。
实际核算可以为每个数字附上四个标签:成本对象、时间范围、计量单位和责任主体。一次训练复盘可以按“某个正式运行、从启动到结束、GPU 小时、模型开发方”标记;年度服务预算则可能是“生产推理、一个财年、通过验收的请求、业务部门与平台团队”。只有四个标签一致,数字才适合直接比较。若标签不同,分析者应先做桥接表,说明哪些项目需要补入、剔除或改按同一期间摊销,而不是用一个汇率或单价把两张账强行换算。
DeepSeek-V3 是解释边界的好例子。技术报告列出的数字是预训练 266.4 万 H800 GPU 小时、上下文扩展 11.9 万小时、后训练 0.5 万小时,合计 278.8 万 GPU 小时;作者按每 GPU 小时 2 美元的假设折算为 557.6 万美元。紧接着,报告明确排除了此前围绕架构、算法和数据开展的研究与消融实验。[1]
因此,“557.6 万美元”回答的是一组正式训练工作的估算成本,不是 DeepSeek 开发这套模型能力的全部账单。美元额还依赖作者采用的租赁单价假设,相比之下,分阶段 GPU 小时更接近原始披露。把这个数字用于比较正式运行效率是合理的;把它扩写成研发团队、数据、失败试验和基础设施的完整成本,则越过了报告自己划定的边界。
Epoch AI 对少数前沿模型的研究也把最终训练运行、支持性实验和研发人员分开建模,并区分摊销硬件与能源、云租赁以及更完整的开发成本。该研究估算,在其选取的模型中,硬件、能源和研发人员各自进入不同成本类别;但样本有限,许多输入来自公开披露与估算,不是一套可直接套到所有公司的会计比例。[2]
这意味着,比较两项训练成本时,先要逐项核对:是否只含最终运行,是否包括失败工作,人员和数据算在哪一层,硬件是按租金还是折旧计量,能源、融资和机会成本有没有进入。若这些问题没有答案,两个精确到小数点后的美元数字仍然可能不可比。
边界也决定失败如何入账。失败训练不应进入“成功训练 token”这一分母,却不能从成本分子里消失;一次没有达到质量门槛的推理请求也不应算作有效产出,但它已经消耗的计算、网络和人工仍是支出。真正适合业务决策的分母是“达到既定质量和服务目标的有效工作”;GPU 小时和 token 只能作为过程指标。
2. GPU 之外,HBM、封装和网络怎样进入成本
加速器的峰值算力不会自动变成完成的训练或生成任务。模型参数、激活与 KV 状态要由内存承载;计算裸片和内存要经过封装形成可工作的器件;任务跨越多颗加速器后,机内互连和机间网络又决定数据能否及时到达。任何一环让处理器等待,昂贵的计算单元都可能在计时,却没有产生等比例的有效输出。
Blackwell 的官方架构资料显示,两颗接近光罩尺寸上限的裸片通过 10 TB/s 芯片间互连组成统一 GPU;GB200 NVL72 则把 72 颗 GPU、13.4 TB HBM3E、576 TB/s 聚合内存带宽和 130 TB/s NVLink 通信组织成一个液冷机架。[3][4] 这些规格说明为什么不能把 GPU 当成脱离内存、互连和冷却的孤立商品,但规格本身并不能证明某个组件占系统成本的固定比例,也不能保证生产工作负载达到厂商列出的性能倍数。
HBM 首先进入供应商的产品成本边界。NVIDIA 的 2026 年 10-K 披露,公司从 SK hynix、Micron 和 Samsung 采购内存,并在销售成本与存货成本的说明中列入购买的内存、其他组件、制造支持和相关费用。[5] 将这份会计披露与 GB200 的 HBM3E 配置放在一起,可以得出一个有限但重要的结论:HBM 是可部署系统中的实际投入,并通过采购或制造进入产品成本。来源没有把 HBM 从整颗 GPU、整台机架或云服务中单独定价,所以不能据此声称“HBM 通常占总成本的某个百分比”。
HBM 也形成容量经济。Micron 把 HBM 定义为使用硅通孔连接的 3D 堆叠 DRAM,其云内存业务单元覆盖 HBM、DDR、LPDDR 等产品,并按收入、销售成本和营业利润管理。公司还披露在新加坡建设 HBM 先进封装设施、在台湾扩充 DRAM 与 HBM 能力。[6] 这能证明 HBM 需要晶圆生产、堆叠、封装、测试和扩产资源,却不能从该业务单元的聚合数字中分离出 HBM 的单位成本,也不能证明全行业长期短缺。
先进封装以另一种方式进入账本。NVIDIA 把晶圆制造、组装、测试和封装列为制造流程,明确披露使用 CoWoS,并将组装、测试、封装和制造支持费用列入销售成本与存货成本。[5] TSMC 则把 CoWoS 和 SoIC 描述为整合相同或不同类型芯片、提高计算密度、能效和集成度并降低延迟的先进封装能力,同时披露对相关产能的持续资本投入。[7]
两类披露共同划出两个边界:对于芯片或系统供应商,封装是产品制造成本;对于供给能力,封装还是需要厂房、设备、良率爬坡和资本支出的后段产能。但“需要投入”不等于封装在所有 AI 系统中都排第二贵,也不等于每一笔资本开支都会迅速变成同等数量的合格产品。来源没有给出每颗 Blackwell 或每个 CoWoS 封装的独立成本,更没有给出全球统一的供需缺口。
网络则横跨资本和运营边界。Meta 的 2025 年 10-K 把服务器、网络基础设施和建筑的折旧,以及能源和带宽费用,列入交付产品的销售成本;文件还披露了网络基础设施的资本购买、租赁和长期合同承诺。[8] 对服务提供者而言,网络可以表现为设备购置与折旧、带宽运营支出、租赁付款或提前锁定的容量责任。Meta 的数字覆盖全公司技术基础设施,并未单独拆出 AI 网络,因此不能用来计算每个模型或每百万 token 的网络占比。
Google 的 TPU v4 论文提供了一个边界更窄的例子。在论文描述的 4,096 芯片系统里,光路交换机低于系统成本的 5%、低于功耗的 3%,同时用于改善系统规模、可用性和利用率。[9] 这个例子说明,成本占比较小的网络组件也可能通过拓扑改变昂贵处理器的有效使用;它不说明其他 GPU 集群、以太网集群或云服务也具有相同的低于 5% 比例。
所以,采购表里不应只有“GPU 数量乘单价”。至少还要记录:每卡可用内存与有效带宽能否容纳目标模型;封装、测试、良率损失和供货承诺是否已进入报价;机内和机间网络采用什么拓扑,交换设备、带宽、租赁和容量承诺由谁承担;最后再用目标工作负载实测,而不是用峰值规格替代有效产出。
这些项目还需要做联动情景,而不是各自选最低价。内存不足可能迫使模型跨更多设备切分,从而增加通信和可调度设备数量;更高的机架密度可能改变网络端口、供电和冷却条件;交付时间不同,则会让一套纸面成本更低的系统晚数月产生业务输出。采购方不必预先断言哪一项最贵,但应分别测试容量、带宽、交付和利用率的变化怎样影响最终分母。这样得到的是目标工作负载的系统经济性,而不是组件价格的静态排名。
3. 机器开始折旧后,利用率和设施开销决定单位成本
硬件成本的难点不只在买入价,还在时间。固定资产按日历消耗,业务输出按请求和任务产生。训练队列的空洞、通信等待、故障恢复、推理服务的低流量时段以及不合适的批处理,都会让折旧、租赁和设施费用继续发生,却减少同一期间的有效输出。
可以把单位有效工作成本理解为:某段时间内的折旧或租赁、资金成本、能源、设施、网络、运维与失败损失之和,除以满足质量和服务目标的输出。这是比较框架,不是要求每家公司采用同一会计公式。它的价值在于迫使采购方同时看分子和分母:降低设备价格可能缩小分子,提高利用率也可能放大分母;相反,更严的延迟和可用性目标可能要求保留余量,使单位成本上升。
利用率也不能只报一个全局平均值。设备在监控图上处于忙碌状态,可能是在进行有效计算,也可能在等待内存、通信、数据或其他设备;集群平均值还可能掩盖少数热点设备与大量空闲设备并存。面向成本的测量应把计划维护、故障、排队空洞、通信等待、未被接受的运行和满足验收条件的输出分开,并按高峰与低谷观察。管理层才能判断问题来自容量真的不足、调度不佳,还是服务目标要求保留了无法出售给其他任务的余量。
折旧假设本身足以显著改变期间成本。Alphabet 在 2023 年把服务器的估计使用寿命从四年延长到六年,把部分网络设备从五年延长到六年,当年因此减少折旧费用 39 亿美元、增加净利润 30 亿美元。[10] Alphabet 的 2024 年 10-K 继续把技术基础设施折旧、网络容量、能源和设备成本列入成本,并说明服务器和网络设备通常按六年折旧,同时要考虑过时和计划利用情况。[11]
这并不证明六年是行业的正确寿命。延长会计寿命会降低当期折旧,却不会让旧设备自动获得更高性能,也不保证它还能以有竞争力的能效和维护成本运行。自建方案因而需要同时测试三件事:设备在账面上摊多久,技术上能服务多久,经济上何时会被更高效的系统替代。三种寿命未必相同。
网络也会以类似方式跨越资本与运营账。Meta 将服务器和网络基础设施折旧、能源与带宽列为销售成本,并记录网络相关租赁和长期承诺。[8] 租云免去资本开支,只是把网络容量的成本和风险通过合同重新分配:供应商承担或转移设备与容量责任,客户则通过价格、最低承诺、预留安排或弹性溢价支付。
电力也不只是芯片的铭牌功耗。Google 对数据中心 PUE 的定义,是总设施能耗与 IT 设备能耗的比值;总设施能耗还包括冷却和配电等非计算开销。[12] 因此,在相同服务器功耗下,冷却方式、供电转换和设施设计仍会改变总用电。PUE 也有明确限制:它衡量设施开销,不衡量模型质量、芯片利用率或每个成功请求的成本。
美国能源部转述劳伦斯伯克利国家实验室研究称,美国数据中心 2023 年用电约为 176 TWh,并给出 2028 年 325 至 580 TWh 的预测区间;AI 是报告列出的多个需求驱动因素之一。[13] 这些数字覆盖所有数据中心,不能把增长全部归因于 AI,也不能直接换算某项服务的电费。它们说明的是另一层约束:当电网接入、供电设备、冷却和建设周期限制新容量时,设施不再是服务器采购之后自然存在的背景条件。
自建与租云应放在相同工作负载和服务目标下比较。自建要对利用率、折旧年限、残值、维护、网络、能源、机房和交付周期做敏感性分析;租云要评估租赁溢价、弹性、预留承诺、上线速度和退出成本。只有把相同工作负载与服务目标放进两种方案,成本转移才会显现。
4. 推理成本会随模型、请求和服务目标变化
训练结束并不意味着成本问题结束。推理是一种随模型、请求和服务目标变化的工作负载。同样一百万 token,短输入长输出、长输入短输出、低并发实时对话和高并发离线生成,对计算、内存和调度的压力完全不同。
模型规模首先决定要搬运多少权重、执行多少计算;稀疏模型还要区分总参数与一次请求实际激活的参数。输入长度主要影响预填充阶段,系统要并行处理已有上下文;输出则通过自回归解码逐 token 生成,每产生一个 token 都要进行下一轮计算。ORCA 论文解释了这种多轮迭代性质,并指出以完整请求为单位的固定批次会让已经完成的请求等待,同时让新请求排队。[14]
批处理能够让多个请求共享权重读取与设备执行,提高吞吐,却会与排队时间和尾延迟发生冲突。流量足够稳定、允许等待的离线任务可以形成更大的批次;低流量或强实时服务可能长期无法填满同样的批次。因而,“每 token 成本”至少要附带并发、批量、首 token 时延、每输出 token 时延和尾延迟,否则低价可能只是通过更长等待换来的。
KV cache 是第二个常被低估的约束。它保存生成过程中已经计算的注意力键和值,随并发和序列长度增长,占用显存。vLLM 论文指出,每个请求的 KV cache 体积大且动态变化,内存碎片和重复会限制可形成的批量;其 PagedAttention 方法在论文测试中,以相同延迟获得了相对所选基线 2 至 4 倍的吞吐。[15] 这个倍数属于特定模型、硬件、序列和解码设置,不是任意生产系统都能兑现的成本降幅。它证明内存管理会改变利用率和吞吐,不能直接推出通用节省比例。
预填充与解码也可能争夺不同资源。DistServe 把首 token 时延(TTFT)和每输出 token 时延(TPOT)分开,说明两阶段共置时会互相干扰,并以同时满足两种时延目标的请求速率衡量服务能力。[16] Google 的推理研究同样把分区方式、批量、模型计算利用率、内存需求、上下文长度和严格时延放在同一个优化问题中。[17] 这解释了为什么一套在离线吞吐测试中高效的配置,未必适合需要快速首 token 和稳定尾延迟的交互产品。
缓存还要区分两种机制。单次请求中的 KV cache 保存本次生成状态;跨请求提示缓存则尝试复用相同的前缀。Anthropic 的文档说明,提示缓存依赖相同前缀和缓存命中;未命中时,完整提示仍要被处理,随后才建立可复用条目。[18] 因此,固定系统提示、大段重复文档或模板化调用可能受益,前缀经常变化的流量则不能把标称缓存优惠当成稳定节省。
可靠性会进一步改变容量需求,但现有来源不能给出适用于所有服务的冗余比例或重试成本。副本、跨区、容量预留、限流、回退和重试应被视为采购检查清单,而不是论文已经确立的统一成本规律。企业在试运行中需要逐项记录:目标可用性和尾延迟,过载时如何限流,是否保留副本或跨区容量,回退到哪个模型,何时触发重试,失败与重试如何计费,重试后的结果是否仍通过质量验收。
最终的推理测试表至少应包含输入和输出 token 分布、并发、批量、KV cache 占用、跨请求缓存命中、TTFT、TPOT、尾延迟、成功率、重试率和质量。成本分母则应采用“通过验收的结果”,这样系统用更低单价生成大量无效输出时,不会被误判为效率提高。
测试还应覆盖流量形态,而不只是在稳定满载下跑一次基准。企业可以分别构造日常负载、突发高峰、长上下文、长输出、缓存高命中和低命中等情景,在同一质量门槛下观察吞吐、时延、失败与账单如何变化。若方案只能在持续满载时显示低单位成本,就要进一步判断真实业务能否形成这种批量;若低延迟方案依赖大量空闲余量,也应把这部分容量明确归入服务目标成本。情景结果比单一平均值更适合决定模型路由、容量预留和自建或租用范围。
5. API 价格、供应商成本和客户总成本是三条曲线
API 标价是客户会实际支付的价格,却不是供应商成本报表。它通常按输入、输出、缓存或其他服务单位计费,背后可能包含硬件与能源、工程运维、容量风险和商业决策,但仅凭公开价目表无法识别各因素的贡献,也无法判断供应商利润率。
Epoch AI 对推理价格趋势的研究追踪达到特定基准门槛的最低 API 价格,并把输入与输出价格加权。研究明确表示,它没有对成本驱动因素建模,也没有足够证据判定价格下降是否来自利润率收窄。[19] 因此,文章可以说“观察到的 API 价格下降不等于已经识别的供应商成本下降”,却不能据此列出一张确定的价格因果表。
客户还需要另一张账。一个实用的总拥有成本框架可以分成四层:直接支出包括 API 或云账单、存储、检索、工具调用、网络、日志和为服务目标购买的容量;内部人工包括集成、数据与提示维护、评测、安全合规、人审和线上运维;失败损失包括失败运行、重试、返工、事故和未达服务目标造成的可计量损失;机会成本则包括等待、迁移、被占用的工程容量和延迟交付放弃的其他机会。
这四层是本文提出的核算工具,不是来源已经建立的行业标准。它们也不能无条件相加。只有时间范围、质量门槛、计量基础和成本归属一致,才适合汇总为某个业务结果的 TCO;机会成本尤其应与现金支出分列。否则,一项估算中的潜在收入损失可能与另一项现金账单混在一起,制造出精确却不可解释的总数。
效率改善仍然重要。Stanford 2025 AI Index 报告称,达到 GPT-3.5 水平的系统,其推理价格在 2022 年 11 月至 2024 年 10 月间下降超过 280 倍。[20] 这一比较基于特定性能门槛,不等于所有任务获得同等价值,也不能单独证明底层成本或价格下降的原因。但它显示,单位能力价格可以在较短时间内大幅变化。
单位价格下降也不保证总支出下降。更便宜的调用会让原本不经济的功能成立,产品可能采用更长上下文、生成更多候选、增加代理步骤或把模型嵌入更多流程。若调用量与每次工作量的增长超过单位成本下降,总需求和总支出仍会上升。反过来,如果任务量固定、输出受控,而且效率提升没有诱发更多使用,总支出完全可能下降。价格趋势和数据中心总用电趋势只能共同说明这种可能性,不能构成两者之间的因果证明。[13]
采购决策可以用六个问题收束:
1. 这是什么边界:正式训练运行、完整研发、供应商产品与容量、稳定服务,还是客户 TCO?
2. 分母是什么:GPU 小时、token、请求,还是通过验收的业务结果?
3. 工作负载是什么:模型多大,输入和输出多长,并发、批量、缓存命中和峰谷分布如何?
4. 服务目标是什么:质量、TTFT、TPOT、尾延迟、可用性和数据边界是什么?
5. 固定成本与可靠性责任由谁承担:内存、封装、网络、折旧、闲置、预留、冗余与重试落在供应商、自建方还是合同双方?
6. 哪些项目尚未进入报价:数据、集成、检索、评测、人审、失败、迁移与退出成本是否已经分层记录?
这套方法不会给出一个脱离场景的“AI 平均价格”。它会让真正的变化变得可见:有时芯片或 API 单价下降,成本却转移到网络、服务目标和内部工程;有时更好的调度、缓存与模型选择提高有效产出,单位经济性确实改善。只有先固定边界、分母和验收条件,采购方才能判断一项成本是在下降、被转移,还是被更多需求放大。