「要不要自己买卡」这个问题，我被问过很多次。问的人大多已经决定要买了，只是想找人点头。
我的答案通常不太好听：绝大多数情况下，不该买。
先说结论
把判断标准压成一句话：只有当你的调用量足够大、足够稳定，而且对数据或延迟有硬要求时，自建才划算。 其余的，买 API。
理由在下面拆开说。
自建的成本只有三项，但第三项最容易被漏掉
第一项：硬件摊销。
卡不是一次性成本，它要用两三年摊下来。这里的坑是，很多人只算了买价，没算配套：电源、散热、机箱、主板能不能插下多张卡、机房的电容量够不够。这几项加起来，往往能到卡本身价格的一半。
第二项：电费和运维。
一张高性能卡满负荷跑起来的功耗不低，电费是按月出的真金白银。再加上系统维护、驱动升级、故障排查的时间成本——如果你的时间是钱，这一项必须计入。
第三项，也是最容易被漏掉的：闲置率。
自己买的机器，没请求的时候它也在那儿，成本照付。而买 API 的好处恰恰是弹性：用多少付多少，闲时为零。
闲置率这件事的杀伤力，取决于你的负载曲线。平稳的负载闲置率低，自建就有利；忽高忽低的负载闲置率高，自建就是浪费。
一张表把事情摆开
| 维度 | 自建 | 买 API |
|---|---|---|
| 前期投入 | 高，且不可逆 | 几乎为零 |
| 单位成本 | 负载越高越便宜 | 与用量线性相关 |
| 弹性 | 差，扩缩容要买机器 | 好，随时增减 |
| 数据边界 | 数据不出内网 | 取决于服务商条款 |
| 延迟 | 可控，无网络往返 | 受网络和排队影响 |
| 模型换代 | 换模型等于换硬件 | 换模型只是改个名字 |
| 运维负担 | 自己扛 | 服务商扛 |
这张表里，最容易被低估的是最后两行。
这几种情况，自建才立得住
- **日均调用量大且平稳**。负载曲线平的时候，硬件利用率能跑上去
- **数据明确不能出内网**。这是唯一一个「钱不是首要考虑」的理由，也是最有说服力的理由
- **对延迟有硬指标**。本地推理省掉了网络往返，某些实时场景确实需要
- **需要固定版本**。业务要求模型长期不变，不接受服务商升级带来的行为漂移
注意第二、三、四条都不是「省钱」的理由，而是「买不到」的理由。真正因为省钱而自建成功的，只有第一条。
这几种情况，别自建
- **用量小**。一个月几百块的 API 账单，自建的摊销永远追不上
- **用量波动大**。峰值撑不住，低谷全浪费
- **模型要频繁换**。硬件跟着模型换，折旧会非常难看
- **团队没人管运维**。机器坏了没人修，业务直接停
最后一条是最现实的。自建不是买完就完事，它是一个需要长期投入的系统工程。
一个常被忽略的变量：换代速度
这条值得单独说。
模型能力的迭代速度，决定了硬件的有效寿命。你按今天最好的模型配的机器，半年后可能就被一个更小、更省的架构比下去了——而你的机器还得继续折旧。
买 API 的人不受这个影响，换模型只是改个配置。自建的人要把这笔「技术过时」的损失算进成本里。
算账的正确顺序
如果你确实在权衡，我建议按这个顺序走：
- 先统计真实调用量，看日均和峰值，连续记一个月
- 算清楚 API 这边一个月的实际账单
- 再算自建的摊销加电费加运维，除以同样的用量
- 最后问自己：第二条和第三条之外，有没有「必须自建」的理由
- 有，就上；没有，就继续买
第 1 步是关键。我见过太多人凭感觉估用量，估出来的数字和真实值能差好几倍。
说点实在的
自建和买 API 之间不是路线之争，是成本结构之争。
用量大而稳，自建省；用量小而散，买 API 省。 数据不能出内网，自建是唯一解。其他的纠结，算一遍账基本就清楚了。
本文不构成任何采购建议，具体方案请结合自身用量、合规要求与预算评估。