一个团队按小时租了八卡机跑训练，跑满一年后把账单和采购报价摆在一起：租金总额已经超过同规格整机的采购价，手里却既没有资产也没有残值，议价时连筹码都没有。同一个团队如果只在每周两三个晚上跑批处理，同一张账又会得出完全相反的结论——租比买便宜一个量级。
决定答案的不是单价，是利用率。这篇把四种获取方式放回同一张账上：判断的等式、必须计入的隐性项、供应风险怎么改写模型，以及什么条件下这笔账本来就该算不清。
1. 四种获取方式与它们的成本结构
| 获取方式 | 计价单位 | 成本主要构成 | 风险落在谁身上 | 需求形态 |
|---|---|---|---|---|
| 按量租 | 每小时 × 卡型 | 单价 × 时长，无承诺 | 供应方（价格随行就市，你承担涨价与回收） | 峰值、实验、短周期 |
| 预留 / 包年 | 承诺期 × 折扣 | 预付或按月摊，换折扣 | 你（承诺期内不用也要付） | 稳定基线 |
| 自建 | 资本支出 + 年运维 | 采购、折旧、电力、网络、人力、备件 | 你（全部） | 长期高利用率基线 |
| 混合 | 组合计价 | 基线自建 + 峰值外购 | 分摊到两边 | 基线稳定、峰值不可预测 |
四种方式的差异不在"贵不贵"，而在成本是变动的还是沉没的。按量租把成本变成变动成本，随时能停；自建把成本变成沉没成本，停不下来。选型本质是选你愿意承担哪一种风险，而不是选哪个数字更小。
2. 判据：利用率，不是单价
每卡时租金 = 账单金额 / 实际占用卡时
自有每卡时成本 = (整机价 / 折旧年限 / 年可用小时) / 利用率 + 每卡时电费与运维
盈亏平衡利用率 = 自有每卡时固定成本 / 每卡时租金
| 月均利用率 | 自有每卡时成本（以租金为 1.0） | 结论 |
|---|---|---|
| 5% | 十几倍量级 | 自建在任何场景都算不过租 |
| 20% | 数倍 | 仍以租为主，顶多买一台做常驻服务 |
| 50% | 与租金接近，取决于电价与人力摊销 | 分水岭，必须按本地电价重算 |
| 70% 以上 | 低于租金，随年限继续下降 | 自建开始有账面优势 |
| 90% 以上 | 明显低于租金，但要计入代际贬值 | 自建基线 + 预留承诺组合 |
盈亏平衡点落在哪，取决于电价、机位费、人力摊销三项。不要借用别人的平衡点：同样 50% 利用率，一线城市机房托管与自有托管机位的账能差一倍以上（按自己机房报价核对）。
3. 隐性成本：单价之外的七项
| 隐性项 | 计入方式 | 漏算的典型后果 |
|---|---|---|
| 运维人力 | 按 FTE 折算到每卡时 | 无人值守 → 故障恢复按天计 |
| 网络与存储 | 出网流量、对象存储、跨区复制 | 数据搬运费超过卡钱 |
| 机房与电力 | 机位费、电费、UPS、制冷 | 高功耗卡型的电费常年漏算 |
| 备件与保修 | 备件库、返修周期、替换机 | 单卡故障拖垮整机可用性 |
| 闲置率 | 利用率分母里的空转小时 | 用峰值当分母，算出来永远偏乐观 |
| 折旧周期 | 3 年 vs 5 年、残值假设 | 5 年折旧的账在下一代卡面前失真 |
| 采购周期与资金占用 | 交付周数 × 现金流成本 | 交付 8 周意味着需求已经变了 |
一条经验：这些项加起来通常能把自有的账面成本抬高一个可观比例（典型量级 30%–60%，按自己的机房与人力量级核对）。凡是算出"自建便宜一半"的方案，先确认这七项都进了分母。
4. 预留承诺：把不确定性明码标价
| 承诺期 | 折扣量级 | 你付出的代价 | 适用条件 |
|---|---|---|---|
| 1 年 | 中等 | 一年内需求下滑仍要付 | 需求可预测、有年度预算 |
| 3 年 | 较高 | 三年内可能跨过代际 | 基线稳定、业务确定 |
| 无承诺 | 无 | 价格随行就市、可能被挤占 | 试点、需求不确定 |
基线承诺量 = 过去 6 个月负载的 P10 分位（不是平均值）
峰值 = 按量补齐
实验 = spot / 抢占式，接受随时被回收
用平均值签承诺，等于有一半时间在为闲置付钱。承诺量要取"不会低于"的那条线。
5. 弹性：基线自建 + 峰值外购
# 队列 → 算力池的映射（示意，字段按自家调度器核对）
pools:
baseline: # 自建池，常驻
provider: onprem
max_nodes: 8
accept: [batch_daily, embedding_backfill]
burst: # 外购池，按需拉起
provider: cloud_a
max_nodes: 64
accept: [batch_daily_overflow, adhoc_experiment]
ttl_minutes: 120 # 空闲即回收
preemptible: true
ttl_minutes 是这份配置里最省钱的一行。外购节点按小时计费，"忘了关"是这类账单最常见的失控来源，其次是"临时实验"变成了常驻服务。
6. 供应风险：配额、排队与区域
| 风险 | 表现 | 对成本模型的影响 | 对冲 |
|---|---|---|---|
| 配额不足 | 想扩扩不出来 | 峰值只能靠预留兜底，用折扣换保障 | 提前申请配额、准备第二区域 |
| 排队时长 | 提交到开跑几十分钟到数小时 | 有效利用率下降 | 队列分级、优先级、抢占 |
| 区域售罄 | 目标卡型不可用 | 被迫上更贵卡型或跨区搬数据 | 部署模板按两区域准备 |
| 抢占回收 | spot 被中断 | 无断点则重跑成本翻倍 | 存盘频率按单步时长定 |
排队时长必须进分母：算力分配给你但没跑起来的时段，在自建模型里是闲置，在租赁模型里是付费空转，两种模型都得扣一次。
7. 代际贬值：什么时候该换
| 信号 | 观察 | 处置 |
|---|---|---|
| 新卡同功耗吞吐明显提升 | 单位 workload 成本下降 | 新采购直接上新代，不再补旧代 |
| 旧卡租赁价下滑 | 市场已按旧代定价 | 自建旧卡的账面优势随之消失 |
| 备件难买、保修到期 | 故障恢复时间变长 | 提前规划退出，别等坏 |
| 模型规模跨过显存门槛 | 旧卡装不下 | 换卡或量化/切分，两条都改架构 |
折旧年限要跟代际节奏对齐：账面可按 5 年折旧，规划不能按 5 年。财务口径可以长，物理替换周期通常更短。
8. 多云与单一供应商
| 维度 | 单一供应商 | 多云 |
|---|---|---|
| 议价能力 | 用量集中，折扣空间大 | 单家用量小，折扣弱 |
| 复杂度 | 一套网络与权限 | 两套网络、两套计费口径、跨云流量费 |
| 故障逃生 | 区域级故障即全断 | 可切换，但要演练过 |
| 成本观测 | 账单口径统一 | 口径不一致，需自建归一化层 |
多云的真实成本不是"多一份账单"，是多一套要长期维护的抽象层。如果动机只是议价，先把用量集中再谈，通常比拆开划算。
9. 自建的隐性门槛
自建准入检查（任一不满足，先别自建）
[ ] 有人能处理驱动、固件、散热与显存故障，且不是"兼职顺便"
[ ] 有备件或保修响应承诺（返修周期 < 可接受的停机时间）
[ ] 机位电力与制冷能覆盖满载功耗，不是"够用就行"
[ ] 出网带宽能支撑数据搬运，且有流量预算
[ ] 有资产台账与折旧口径，能与财务对上账
第五条最常被跳过。没有台账，成本只能靠感觉，下一轮决策又退回"比单价"。
10. 成本分层观测：谁在用、用在哪、用多久
-- 每卡时成本归集：团队 × 任务类型 × 池
SELECT team,
task_type,
pool,
SUM(gpu_hours) AS gpu_hours,
SUM(gpu_hours * unit_price) AS cost,
SUM(gpu_hours) / SUM(occupied_hours) AS utilization
FROM compute_usage_daily
WHERE day >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY team, task_type, pool
ORDER BY cost DESC;
字段口径必须与账单对齐（同卡型、同计费粒度），否则归集数无法与发票对账，归因也就失去意义。
11. 度量
| 指标 | 定义 | 用途 |
|---|---|---|
| 每有效算力小时成本 | 总成本 / 有效计算小时（剔除初始化与空转） | 跨池比较的唯一可比口径 |
| 利用率 | 有效计算小时 / 占用小时 | 盈亏平衡判断的输入 |
| 排队时长 | 提交到开跑的等待 | 有效利用率的扣减项 |
| 闲置率 | 占用但无任务的小时占比 | 回收策略与 TTL 的依据 |
| 峰值外购占比 | 外购卡时 / 总卡时 | 检验弹性策略是否真在起作用 |
12. 排错
| 现象 | 常见原因 | 检查 |
|---|---|---|
| 账单高于预算一截 | 闲置节点未回收、实验机忘了关 | 按空闲时长排序找长期空转 |
| 自建算出"极其便宜" | 分母用峰值、漏算人力电力 | 用 6 个月实际利用率重算 |
| 预留折扣谈不下来 | 承诺量低于门槛、期限太短 | 集中用量、拉长期限再谈 |
| 排队严重但卡利用率不高 | 任务粒度太碎、调度碎片化 | 看碎片分布与队列分级 |
| 训练成本突然翻倍 | 存盘点太稀、被抢占后重跑 | 缩短单步时长、提高存盘频率 |
| 跨区数据费超预期 | 数据与算力不在同区 | 把数据下沉到算力所在区 |
13. 边界
| 场景 | 结论 | 理由 |
|---|---|---|
| 需求极不稳定（月间波动数倍） | 以租为主 | 自建与承诺都在为不确定付钱 |
| 团队无运维能力 | 租或托管 | 自建门槛全部落在你身上 |
| 单次实验性需求 | 按量租 | 采购周期长于需求生命周期 |
| 小规模常态需求（几卡） | 租更合适 | 规模效应不在你这边，议价与备件都不成立 |
| 数据必须留在自有网络 | 自建或专有云 | 这条约束优先于任何成本模型 |
14. 自测
- 两张账一张说"租更贵"、一张说"买更贵"，先对齐哪个变量才能比较？
- 为什么不能用平均负载去签预留承诺？
- 成本等式里的利用率该用哪个口径，为什么不能用峰值？
- 排队时长在租与买两种模型里分别表现为什么？为什么要各扣一次？
- 折旧年限写 5 年，为什么不能按 5 年做替换规划？
- 多云带来的额外成本，除了账单本身还有什么？