买硬件之前没人写下来的那份 GPU 成本模型

所有人都会做的那个对比

每场自建还是采购的讨论里，都有一张只有两个数字的表格：API 每百万 token 的价格，以及一张 GPU 的小时租金除以一个假想吞吐量。第二个数字通常比第一个小三到十倍，然后会就结束了。

表格的算术没错，错的是分母。它除的是这张卡「能」达到的吞吐，而不是它「会」达到的吞吐。

真正决定结果的是哪个数字

利用率。按小时计费的 A100 或 H100，不管服务一个请求还是一万个请求，账单是一样的。而 API 只对你真正消耗的 token 收费。所以分水岭不是价格问题，而是你的卡一天里真正忙碌多少小时。

举个具体的形状：每天几百万 token 的稳定流量，集中在工作时间。这种负载大概让单卡饱和四分之一天，其余时间闲置。按实际服务的 token 摊下来，闲置的那些小时是纯开销，API 轻松胜出。把同样的流量压成 24 小时持续负载并做批处理，排名才会翻转。

表格里漏掉了什么

有两类成本被系统性遗漏。第一类是工程师。总得有人负责服务栈、模型升级、CUDA 与驱动兼容性、自动扩缩容策略和值班。这不是能开票的行项，但它是一个人的真实一部分工时，而且它不会随流量下降而下降。

第二类是重试与故障预算。托管 API 自己消化自己的坏时段；你的集群自己消化自己的，形式是事故。而客户试点期间的事故，代价远高于它所中断的那点算力。

到底该怎么决定

先测后买。用真实流量在租来的硬件上跑两周，记录实际服务的 token 数和计费的 GPU 小时，算出你的实际每百万 token 成本，再与同质量档位的 API 价格比较。结果取决于你的流量形状——这也正是通用对比表无法替你回答的原因。

然后再按非成本因素决定，而这些往往才是真正的驱动力：数据驻留、到用户的延迟、不受限流影响，以及你是否需要一个没人托管的模型。