GPU租用和购买哪个划算

团队要跑本地模型，预算会上一开口就问：租卡还是买卡？这个问题的答案不在设备报价单上，而在你每天真正把卡用到多少小时。这篇不堆参数，只给一套能自己套进去的算法：先量负载，再算固定成本和可变成本，最后定一条回头线。看完你能判断自己现在处在租卡区、买卡区，还是两边都别碰的中间地带。

团队要跑本地模型，预算会上一开口就问：租卡还是买卡？这个问题的答案不在设备报价单上，而在你每天真正把卡用到多少小时。同一张卡，一天跑两小时和跑二十小时，结论完全相反。所以先别急着比价，先把自己的负载量出来，这是后面所有账的分子。

这篇不堆参数，只给一套能自己套进去的算法：先量负载，再拆开算固定成本和可变成本，最后定一条回头线。看完你能判断自己现在处在租卡区、买卡区，还是两边都别碰的中间地带，也大概知道下季度该往哪边挪。

先别问价格，先量出你的真实占用率

占用率就是一天里卡真正被业务占着的小时数除以二十四。做法很土但有效：把一天拆成训练、推理、空闲三段，连续记一周，取平均值。很多人凭感觉觉得自己「天天在跑」，一记账才发现大量时间是排队、调试、等人改代码，卡在空转。

1. 按用途分三段记录训练、推理、空闲各记多少小时，训练段里再标出真正在算的比例。用监控或简单日志都行，重点是连续记满一周，别只挑最忙的那天。
2. 按峰值和均值各估一次卡数峰值并发决定你要几张卡同时在线，平均并发决定这些卡平时用掉多少。两个数差得越远，说明你越需要弹性，越不适合买死。
3. 算占用率并留出余量用平均占用小时数除以二十四得到占用率，再打个折——设备故障、升级、等人，都会让实际利用率比账面低。打折后的数才是拿去算账的数。

租卡的钱到底花在哪几块

很多人比价只比每小时租金，最后账单超预期，问题往往出在边上那几项。存储通常单独计费，而且模型权重和数据集会一直占着；带宽和内网出网流量也容易漏算，尤其是要把训练结果频繁拉回本地的时候。

• 租金按小时或按月计，先确认是独占整卡还是共享算力，两者单价口径完全不同
• 存储按容量和时长计费，冷数据该归档就归档，别让几个老权重常年挂在热存储上
• 带宽和出网流量单独看，大批量拉取结果的场景要把这笔算进去
• 计费粒度问清楚，按秒、按分钟还是按小时取整，短任务多的时候差别不小

按量租适合短周期和波动负载，包月包年适合占用率长期高的场景，但包月一旦中间停用，摊下来可能比按量还贵。各家中转和云厂商的挂牌口径不一样，先到 /compute/gpu-rental 看当时的租用报价口径，再到 /compute/price-index 对一遍横向价格，别拿两年前的印象做决定。

买卡不只是那张卡

自购的账最容易算漏的是「卡以外」的部分。一张卡要插进整机，整机要放进机架位，机架位要有电和散热，这几层每一层都要钱。而且这些投入是按三到五年摊的，摊得越久，卡越老，单位算力的电费占比越高。

三年总账的口径可以照 /compute/tco 的算法走，把上面每一项填进去；电费这一项单独到 /compute/power 对一遍，按你机房的实际情况估，别用厂商标称功耗直接乘。运维人力这项，如果团队里没人专职管机器，就要么算进去，要么承认它是以「大家轮流救火」的形式在支付。

回本点怎么算：一条能套的公式

判断标准只有一条：把自购的三年总成本除以你每月预计占用的小时数，得到「自购等效小时价」，再拿它和租卡的实际时价比。前者低于后者，买划算；明显高于，租划算；差得不多，说明你在中间地带，先别动。

自购等效小时价 = 三年总成本 /（每月占用小时数 × 36）
三年总成本 = 卡与整机 + 机架电源散热改造 + 三年电费 + 三年带宽存储 + 三年运维备件
租卡实际时价 = 租金 + 摊到每小时的存储 + 摊到每小时的流量

两个细节决定这条公式准不准。第一，别用挂牌单价比，要用你实际能拿到的成交价，两边都把存储和流量加上。第二，折旧周期要跟模型迭代节奏走：如果明年很可能要换代卡型，折旧年限就缩短，回本点会明显后移，很多原本「买划算」的测算会因此翻盘。

买不起整机又老是用满：混合方案

最难受的是中间地带：占用率不低，但还没高到值得养一整套机房。这时候常见做法是混合——底仓自购一到两张卡跑常驻推理，峰值训练、临时压测、新模型试跑走租用，把闲置和峰值分开处理。

• 常驻推理放自有卡，负载稳定、延迟要求高，长期占用率撑得住
• 突发训练和压测走租用，按量计费，用完就释放，不留闲置
• 不敏感的实验任务放租用环境，敏感数据留在自有卡上，兼顾成本和数据边界
• 两套环境要共用一套镜像和配置管理，否则每次迁移都在重新踩坑

混合方案不是没有代价：两套环境意味着两套镜像、两套监控、两套值班习惯，运维成本会实实在在多出一块。如果团队里没人能同时管两边，混合反而比纯租更累。判断标准是——有没有一个人能说清楚两边环境的差异，没有就先别混合。

别买错卡：先按模型算一遍

决定买之前，还有一步不能省：按你实际要跑的模型反推显存。参数量、量化档位、上下文长度三个变量一起决定显存占用，只看参数量会严重低估。用 /compute/sizing 按你的模型和量化档位估一遍，部署侧的细节到 /models/deploy 对。

显存不够时的降级顺序是固定的：先降量化，再缩短上下文，最后才考虑拆多卡。拆多卡会带来通信开销和部署复杂度，不是免费的扩容。硬件规格参数对照 /compute/gpus 看，如果考虑国产卡，可得性和生态适配到 /compute/domestic 核对，别只信纸面参数。

下单前的对照清单

把前面几步的结论收敛成四个维度，各打一个分：负载占用率高不高、预计要用多少个月、数据敏不敏感、团队有没有人专职值守。四项不用精确打分，定性判断就够用。

四项里有两项以上偏「租用」那一列，就先租；反过来两项以上偏「自购」，才进入购买测算。另外，决定买之前，至少让租用环境完整跑通一次业务，把部署时长、故障恢复时长这些真实数字试出来——这些数字比任何估算都准。

每季度回头看一眼

这笔账不是算一次就完的。每季度把实际占用率、实际电费或租金账单、故障次数拉出来，和当初测算比一遍。偏差在预期区间内就继续，偏差大就调整：占用率涨上去了可以补购，掉下来就把闲置卡降配或者租出去。

• 记录实际占用率，和测算值比，看是估高了还是估低了
• 核对账单结构，确认存储和流量有没有超出预期
• 统计故障和停机时长，这直接影响自购的隐性成本
• 价格会动，回头对一次 /compute/gpu-rental 和 /price-watch 的当期数字，别用去年的账

回头看的价值在于纠偏：大多数团队的第一次测算都会高估占用率，因为把调试和等待也算成了在用。跑过一两个季度，你对自己负载的理解会准很多，那时候再决定要不要加购，比一开始拍脑袋靠谱。