Cost, Billing, and Ops2026年10月12日Flatkey Team

GPU 集群 TCO：云租用、托管机房与本地部署

通过一份实用的 FinOps 工作表，对云租用、托管机房和本地部署三种方案的 GPU 集群 TCO 进行比较，适用于 AI 基础设施采购者。

大多数 GPU 集群 TCO 对比之所以失败，原因都一样：它们拿云端按小时费率去对比硬件采购订单。这并不是决策本身。

真正的决策是：你的 AI 团队应该购买灵活性、购买硬件，还是购买设施控制权。一个严谨的 GPU 集群 TCO 模型必须把云租用、托管机房和本地部署统一到同一个结果上：完成的训练任务、被接受的推理 token、生成的媒体作业，或预留的容量月数。

对大多数团队来说，当利用率不确定、上线速度很重要，或者工作负载会随模型家族变化时，云 GPU 租用更占优势。当需求稳定、团队能够运维硬件，而且合同期限足够长，足以摊销 GPU、网络、备件和远程支持时，托管机房开始更有优势。本地部署通常需要最强的理由：极高且可预测的利用率、已有的数据中心运维能力、严格的本地性要求，或拥有设施层的战略要求。

Flatkey 的实用规则：先从工作负载开始，而不是从机柜开始。如果该工作负载可以由托管式模型 API 提供服务，先比较那个方案。如果你确实需要专用 GPU，请在签署容量合同之前，用同一张工作表分别为云租用、托管机房和本地部署定价。

GPU 集群 TCO 快速答案

在构建完整模型之前，先使用这张初步决策表。

情况	通常先从哪里开始	原因
原型、间歇性微调、短期基准测试窗口	云 GPU 租用	承诺最低，获得容量的路径最快。
稳定的、多月推理集群，模型组合已知	云预留容量或托管机房	利用率足够高，可以协商期限定价，但仍可能避免所有权风险。
具有严格网络拓扑要求的大型训练任务	专用云集群或托管机房	你需要可预测的节点放置、网络织构、存储本地性和基准测试验收。
多年利用率高于你的内部门槛回报率	托管机房或本地部署	只有当空闲时间、运维、电力和停机时间都被如实计入时，硬件摊销才可能胜过按小时租用。
受监管的数据本地性或设施控制要求	本地部署或受控托管机房	TCO 决策不仅包括计算价格，还包括合规和控制。
应用只需要模型输出，而不需要 GPU 控制权	模型 API 或 GPU 市场报价	当业务指标是每个被接受输出的成本时，购买集群可能过度。

本指南的其余部分将展示如何构建一个 GPU 集群 TCO 工作表，采购、平台工程和财务部门都可以使用它。

将所有选项统一到同一个单位

不要拿“每小时 H100”去对比“服务器购买价格”。请选择一个分母，并强制把所有选项都换算到这个分母上。

有用的分母包括：

每次完成训练运行的成本：最适合周期性的微调、预训练实验和批处理作业。
每个被接受输出的成本：最适合 LLM 推理、代码生成、图像生成和视频流水线，尤其是重试很重要时。
每个预留 GPU 月的成本：最适合为多个产品团队购买内部容量的平台团队。
每个符合 SLA 的 token 或作业的成本：最适合停机、抢占或排队延迟会改变面向用户可靠性的情况。

对于推理，最清晰的分母通常是：

effective_cost_per_accepted_output =
  total_monthly_cluster_cost
  / accepted_outputs_after_retries_and_quality_filters

这个分母能捕捉到按小时价格隐藏的两件事：失败的作业和闲置容量。

GPU 集群 TCO 公式

在添加特定供应商的细节之前，先使用这个模型：

monthly_gpu_cluster_tco =
  capacity_cost
  + storage_cost
  + data_transfer_cost
  + network_and_interconnect_cost
  + software_and_observability_cost
  + labor_and_operations_cost
  + support_and_warranty_cost
  + financing_or_depreciation_cost
  + downtime_and_retry_waste

然后把它转换为你关心的单位：

unit_cost =
  monthly_gpu_cluster_tco
  / useful_work_completed_per_month

这很重要，因为即使 GPU 小时费很便宜，如果集群利用不足、作业在队列中等待、存储放在错误的区域，或者失败运行烧掉了全价时间，它仍然可能很贵。

按部署模式划分的成本构成

成本项	云租用	托管机房	本地部署
GPU 容量	按需、竞价、预留、专用，或市场报价。	硬件购买或租赁，加上机柜合同。	硬件购买或租赁，加上内部设施分摊。
电力与制冷	通常已包含在费率中，但并非免费。	合同电力、计量电力、制冷附加成本和功率密度限制。	市电、UPS、发电机、制冷系统，以及 PUE 暴露。
网络	出站流量、专线、公共 IP、跨区域流量、互联。	传输、交叉连接、专线、远程访问、DDoS/安全服务。	WAN、互联网传输、专线、防火墙、交换、冗余路径。
存储	块存储、对象存储、文件系统、快照、备份、IOPS 分层。	本地 NVMe、共享存储、备份目标、远程复制。	存储硬件、备份、复制、介质更换、生命周期运维。
运营	主要是平台集成和成本控制。	硬件生命周期、远程协助、验收测试、备件、RMA 协调。	完整的设施与硬件运营、物理访问、备件、非工作时间值守。
承诺风险	按需模式较低；预留或专用合同则更高。	中到高。合同退出和硬件转售很重要。	最高。设施和设备决策可能会超出模型路线图的生命周期。

云租用看起来很简单，因为许多成本都打包进了费率。托管机房和本地部署在电子表格遗漏人员、电力、网络和故障预算时，看起来更便宜。

云租用：需要计入什么

云租用是 GPU 集群 TCO 最清晰的基线，因为它把容量转换成了计量服务。但这并不意味着小时费率就是全部成本。

计入：

GPU 实例或裸金属的小时费率。
预留、承诺或专用容量条款。
附加到集群的存储。
对象存储和快照保留。
数据传输和出站流量。
专用网络、负载均衡器、公共 IP 和 NAT。
调度器、Kubernetes、Slurm、可观测性、日志和告警。
由于队列空档、部署失败、冷启动和糟糕的 bin packing 造成的空闲时间。
如果使用了竞价或可中断实例，还要计入重试浪费。
支持计划和客户管理成本。

当团队的需求曲线不确定时，云租用通常更有优势。它也为采购提供了当前价格基准。AWS、Google Cloud、Lambda、RunPod 以及其他 GPU 云的公开供应商页面适合作为来源核对，但对大型集群真正重要的数字，是你能实际为所需区域、拓扑和期限预留到的报价。

将官方页面作为检查点：

AWS 在其 EC2 P5 实例页面上介绍了用于大规模 AI 工作负载的 P5 级基础设施。
Google Cloud 发布了 GPU 定价，并指出价格取决于 GPU 类型、区域和使用模式。
Lambda 和 RunPod 发布了 GPU 云定价界面，适合快速进行市场核对。
Flatkey Compute 发布了实时 GPU 小时价格指数，并允许买家发布匿名 GPU 需求，让经过验证的供应商竞价。

把每个价格都视为带时间戳的数据。GPU 可用性和小时费率变化速度比普通 SaaS 定价更快。

托管机房：需要计入什么

托管机房不只是“更便宜的云”。它把相当大一部分运营负担从服务商转移到了你的团队。

计入：

GPU 服务器、网卡、交换机、光模块、电缆和存储。
机柜或笼位费用。
合同电力和计量电力。
制冷和密度限制。
交叉连接、互联网传输、专线和网络安全。
远程协助、运输、收货、安装、库存和 RMA 处理。
备用 GPU、电源、NIC、光模块、风扇和存储盘。
硬件折旧、租赁成本、融资成本和转售假设。
设施 SLA、维护窗口和访问流程。
平台运维：镜像、驱动、CUDA 栈、Kubernetes 或 Slurm、可观测性、安全补丁和事件响应。

当利用率可预测且很高、团队具备真正的基础设施运维能力，并且合同提供了足够支撑你计划运行的 GPU 代际所需的功率密度时，托管机房才开始变得合理。当团队买了硬件，却低估了远程协助、网络、电力约束、备件以及扩容缓慢的成本时，它就会失效。

对于 GPU 集群，网络架构往往是决定方案的成本项。需要紧耦合训练的集群，与一组彼此隔离的推理节点并不等价。如果工作负载依赖 InfiniBand、RoCE、NVLink、NVSwitch 或特定的存储布局，就应将其纳入报价和验收测试。

本地部署：需要计入什么

本地部署的 GPU 集群 TCO 应被视为一个设施项目，而不是一次服务器采购。

计入：

托管机房模型中的所有内容。
数据机房空间分配或建设改造。
电气工程、UPS、发电机、电力分配和消防系统。
制冷系统容量和维护。
物理安全和访问控制。
设施人员和非工作时间升级响应。
保险、合规审计和安全流程。
面向下一代 GPU 的长期容量规划。
被设施和硬件占用的资本机会成本。

对于已经拥有数据中心能力、利用率高、地点合规要求严格，或出于战略控制需要的组织，本地部署是有理由的。当团队仍在摸索模型组合、上下文长度、吞吐目标和产品市场契合度时，它是最弱的选择。

隐藏的风险是 GPU 代际更替。一个机房决策的寿命可能比你所服务的模型架构还要长。如果你的 TCO 依赖某一模型家族在三年内持续占据主导地位，就应该对这个假设进行压力测试。

盈亏平衡利用率

核心的盈亏平衡问题是：

required_utilization =
  owned_monthly_cost
  / equivalent_cloud_monthly_cost_at_100_percent_use

如果自建基础设施每月成本为 X 美元，而在满利用率下的等效云租用成本为 Y 美元，那么只有当实际有效利用率高于 X / Y 时，购买才有意义。有效利用率指的是本来会被付费的工作量。它不包括闲置库存、失败任务、队列缓冲，以及为罕见峰值预留的容量。

在三种情景下运行模型：

情景	要测试什么
基准情景	预期工作负载、预期利用率、预期合同期限。
下行情景	更低的利用率、产品上线延迟、更弱的转售价值、更高的电力成本、更慢的验收。
压力情景	新模型无法放入内存、网络拓扑不正确，或需求转向托管 API。

如果下行情景会摧毁经济性，那么云租用或更短期的专用合同通常是更安全的第一步。

可直接复用的 GPU 集群 TCO 工作表

在采购文档中使用这份工作表。针对云租用填写一遍，针对托管机房填写一遍，再针对本地部署填写一遍。

字段	云租用	托管机房	本地部署
GPU 型号和数量
合同期限
预期有效利用率
每月 GPU 容量成本
存储和备份
数据传输和网络
电力和制冷	包含在内或已报价
机柜、笼位或机房资源分配	不适用
硬件折旧或租赁	不适用
远程协助 / 人员
支持、保修和备件
可观测性和平台工具
停机和重试浪费
估计月度 TCO
单位成本分母
每个已接受输出的成本
扩容前置时间
退出成本

不要跳过最后两行。扩容前置时间和退出成本，往往正是看起来很有吸引力的硬件经济性最终变贵的地方。

向每个供应商提出的采购问题

针对云租用：

报价容量是共享、预留、专用还是裸金属？
保证的区域、可用区和节点放置是什么？
包含的确切 GPU 型号、显存大小、互连、CPU、RAM、本地存储和网络架构是什么？
是否包含存储、快照、对象存储、带宽、公共 IP 和支持？
如果集群在合同期内不可用，会发生什么？
供应商能否在承诺开始前运行验收基准测试？
失败任务、平台故障和维护窗口如何抵扣？

针对托管机房：

每个机柜签约的功率密度是多少？
电力是按表计量、承诺，还是已混入机柜价格？
包含哪些远程协助工作，哪些需要计费？
可用哪些运营商和私有链路？
新增机柜、电力和交叉连接的部署速度有多快？
备件、RMA 和固件维护由谁负责？
用什么验收测试来确认集群已具备生产就绪状态？

针对本地部署：

该设施是否已经支持目标功率密度？
是否无需扩建即可获得制冷能力？
谁负责 24/7 硬件响应？
电气、网络和安全变更的审批路径是什么？
折旧周期是多久，假设的转售价值是多少？
如果下一代模型需要更多显存、更多带宽或不同的服务栈，会怎样？

决策矩阵

标准	云租用	托管机房	本地部署
启动速度	最佳	中等	最慢
前期资本支出	最低	中到高	最高
运营负担	最低	中等	最高
长期稳定利用率经济性	中等	如果运营得当则很强	仅在设施成熟时才很强
按 GPU 世代的灵活性	最佳	中等	最低
设施控制权	低	中等	最高
采购可逆性	最佳	中等	最低
基准测试要求	重要	关键	关键

最站得住脚的答案很少是“总是云端”或“总是购买”。通常更合理的是分阶段方法：先租用以进行探索，为稳定需求预留资源，在利用率得到验证后转向托管机房，而只有当设施控制本身就是需求的一部分时才采用本地部署。

GPU 集群 TCO 模型中的常见错误

将标价与最佳情形下的自有成本进行比较

一个公平的 GPU 集群 TCO 模型应比较真实报价与真实的自有成本。云端标价并不等同于预留容量或议价后的容量。硬件采购价格也不等同于已运行集群的成本。

忽视利用率

一个仅有 40% 有效利用率的自有集群，可能会输给一个小时费率高得多的云集群。衡量的是有效工作，而不是已安装的 GPU 数量。

把网络拓扑视为次要因素

仅靠 GPU 数量并不能定义一个集群。训练、微调和高吞吐推理对网络和存储的要求可能大不相同。

忘记重试浪费

重试、部署失败、抢占式中断以及低质量输出都会抬高单位成本。把重试浪费计入分母，而不仅仅是分子。

低估人力成本

驱动、CUDA 版本、容器镜像、调度器、监控、固件、安全补丁和事件响应都属于 GPU 集群 TCO 的一部分。即使报价单上没有，它们也总有人在付费。

什么时候模型 API 优于 GPU 集群

专用 GPU 集群并不总是正确的抽象。如果你的产品只需要模型输出，而不需要硬件控制，那么应将集群 TCO 与 API 路径进行比较。

在以下情况下，模型 API 可能更具优势：

流量具有突发性。
模型组合经常变化。
你需要访问多个前沿模型和开源模型。
团队无法将 GPU 保持在很高利用率。
质量过滤和重试在请求层更容易管理。
财务团队希望获得按请求的使用记录，而不是基础设施池。

Flatkey 在这里很有相关性，因为同一个买家往往同时需要这两条路径。Flatkey Compute 帮助团队比较实时 GPU 小时容量、匿名发布 GPU 需求，并接收供应商出价。Flatkey 的模型和工具 API 层为团队提供了一种方式：当不需要拥有 GPU 层时，通过一个密钥、一个余额和一套使用账本来路由 AI 工作负载。

实际工作流程是：

在租用的 GPU 上对工作负载进行基准测试。
计算每个可接受输出的成本。
通过模型 API 比较同一工作负载。
只有在不利情景假设下专用硬件明显更优时，才预留或转向托管机房。

GPU 集群 TCO 模型的来源清单

请使用当前的来源页面和报价文件，不要从另一篇文章中复制过时费率。

来源类型	需要核实的内容
云 GPU 提供商页面	实例类型、GPU 数量、区域、存储、网络，以及价格是按需、预留、抢占式还是专用。
GPU 供应商系统规格	功耗、内存、互连、服务器外形规格，以及支持的拓扑。
托管机房报价	机柜/笼位、电力、远程协助、交叉连接、网络、安装费用和扩容限制。
公用事业或能源数据	电价假设和递增幅度。
内部平台数据	真实利用率、排队延迟、故障率、重试率、可接受输出量和员工时间。
财务假设	折旧周期、资本成本、税务处理、残值和合同退出成本。