文章目录
我们和很多同行聊过一个话题。做 GPU 云，是不是一定要自己建机房、自己买卡。结论是未必。
重资产：可控，但背着折旧
重资产的路子大家熟。自己攒机器，自己运维，自己扛机房成本。好处是可控，卡就在自己手里，出了事自己能拍板。坏处也明显，钱压在硬件上，技术迭代一快，上一代卡还没回本，新一代就出来了，那笔折旧谁来背。我们算过，一张旗舰卡从入手到过时，回本窗口有时候就一年多，踩不准节奏就是净亏。
轻资产：把分散的资源连起来
轻资产的路子是另一套逻辑。平台不自己拥有所有算力，而是把分散在各处的资源连起来，统一调度、统一交付。用户提交一个任务，平台决定丢到哪类卡上，他全程不知道也不关心背后是谁家的机器。
这条路能走通，靠三件事。一是整合能力，把来源不同的资源抽象成同一套接口，调度层自己决定丢到哪类卡上最合适。我们接入一个新供应商，光把它的机型目录、网络延迟、可用区映射对齐，就要花上几周。二是调度能力，资源分散意味着空闲和紧张是局部的，谁能把任务精准调到宽松的地方，谁就能用更低成本交付同样的算力。三是交付能力，用户要的不是一堆裸机器，是一个能直接用的环境，镜像、存储、网络、监控都替他铺好。
优势：跟着市场走，不背资产包袱
轻资产模式的优势在于灵活。市场缺某类卡，平台不用自己囤，去把那类资源整合进来就行。某类卡过时了，撤掉就是，没有资产包袱。我们见过重资产同行被一代旧卡拖住，想上新机型又腾不出预算，进退两难。
代价：服务质量的一部分握在别人手里
整合别人的资源，意味着服务质量的一部分握在别人手里。网络抖一下、某家机器下线，平台得有能力立刻把任务挪走。我们给自己定的指标是，单一供应商出问题，任务迁移要在秒级完成，用户那头最多感受到一次重试。和上游签的不是有多少用多少，而是保底加弹性，保底那部分确保关键时刻有卡，弹性的部分随用随扩。一次行业里某类卡突然紧缺，靠保底合约我们没让客户的训练断过。
接一个新供应商，到底要做什么
轻资产不是接个 API 就完事。我们接一个新供应商，第一件事是把他的机型目录、网络延迟、可用区映射对齐成我们的标准接口。一张卡在我们系统里不能只是 gpu-xyz，得带上显存、架构代次、单卡算力、所在区域、历史可用率这些字段，调度层才敢把它放进同一个池子。光这一步就要花上几周，因为各家给的数据口径不一样，有的给峰值算力，有的给基准测试分，得统一成我们自己的衡量标准。
我们怎么看上游健不健康
和上游之间，我们盯几个硬指标：单卡可用率、平均交付延迟、突发缩容时的退场速度。任意一个连续下滑，我们就减少把关键任务分给它。保底合约覆盖的是稳态需求，弹性部分随用随扩，但弹性那部分也有上限，不能因为一家临时抽资源就把客户晾着。一次行业里某类卡突然紧缺，靠保底锁的量我们没让客户的训练断过，那批量是提前半年谈下来的，不是临时去市场抢的。
所以轻资产这事的门槛，不在有没有卡，在能不能把别人的卡管得像自己的。整合、调度、冗余，这三件做扎实了，卡从哪来反而不重要。
我们自己的整合规模，现在接的上游有几十家，覆盖几种主流架构。新机型从谈下到能在池子里被调度，平均周期比自建机房短一个量级。客户要新卡，我们不用等采购，去整合就行。
我们走的就是这条不重资产的路，把精力放在整合、调度、交付这三件擅长的事上，而不是和谁比谁机房大。对用户来说，他关心的从来不是你的卡是不是你自己买的，是他的任务能不能稳稳当当地跑完，账单是不是比他自己搞更省。我们选了更适合自己的一条，也见过在这条路上摔跟头的，根子都是调度和冗余没做扎实，不是轻资产这个思路本身有问题。