最近SemiAnalysis有一篇文章《How Oracle Is Winning the AI Compute Market》[1], 里面的一些经营相关的分析还不是那么专业, 特别是缺少一些对经营风险的分析以及算力资源流动性管理的内容.
今天以一个非技术的金融狗视角, 再来谈谈这个问题. 作者除了常年在云计算设施中负责技术相关的工作外, 当过量化交易基金经理学过FRM, 常年对金融资产的流动性视角的风险量化定价进行研究, 也帮朋友评估过一些绿电算力中心的投资, 因此本文会从涉及一些算力固定资产折旧/算力资源证券化/算力融资租赁等几个环节来分析, 并且转换到云计算的技术术语就是:弹性...
这也是为什么云的计算部门都会叫弹性计算, 无论是AWS的EC2(Elastic Compute Cloud)还是阿里云的ECS(Elastic Compute Service). 弹性计算本质上和线下IDC机房卖铁有很多的区别, 前段时间写了一篇文章关于云计算弹性的文章
《锐评某友商说传统云还在卖铁: 从金融的视角谈云计算及其流动性管理》
今天针对GPU云这个场景, 继续写一些内容. 特别是过去十年在传统云计算中, 一直是三大巨头---AWS/Azure/GCP的天下, 而在AI时代的云这三家似乎有些变化, GPU的市场占用率和整体的云营收占比来看, AWS/GCP分别有自己的ASIC(Trainuium/TPU), 微软也在尝试着做自己的ASIC(但是最近听说又延期了). 在GPU市场上Coreweave和Oracle却是异军突起, 占掉了Nvidia GPU接近30%的采购份额... 而另一方面, 为什么微软在今年五月裁完6000人后最近又爆出要裁9000人? 这里面都暗含着很多财务上的风险以及供应链上针对流动性的一些特殊的操作...
本文的目录如下:
1. 以H100构建一个简单的模型算起
1.1 租赁价格走势
1.2 算力成本估计
1.3 简单计算一下ROI
2. 谈谈SemiAnalysis报告的问题
3. GPU云的经营风险
3.1 市场风险
3.2 信用风险
3.3 操作风险
3.4 流动性风险
3.5 其它重要风险
4. 如何避免GPU云的经营风险
4.1 运营成本管理: “白盒云是云么?”
4.2 弹性: 避免信用风险和流动性风险的良药
4.3 弹性视角下的性能
4.4 弹性视角下的安全和稳定
5. 弹性视角下的算力证券化
1. 以H100构建一个简单的模型算起
我们以H100为例来谈谈相关的风险, 这里采用一个更简单的估算模型.
1.1 租赁价格走势
H100早期的价格大概是在280w人民币. 一开始的时候定价差不多在4~5美元/小时/卡. 随着那个时候多家大模型厂家急于训练自己的模型, 实际价格超过8美元/小时/卡. 随着卡供应的充足, 以及部分模型厂商退出, 在2024年中的时候就很容易找到1~2美元/小时/卡的服务器了. 而最近基本上国内的整机价格也跌倒了4.5w/每月, 折合每小时正好1美金. 因此大致的价格为:
实质上, 我们可以看到租赁价格的影响存在两个影响因子.
供应紧张时的流动性溢价 随着新的H200/B200卡出现的算力折价
其实从早期的价格来看, 一台280w的机器, 十几个月就能收回成本, ROI特别容易让人冲动... 但是在实际经营过程中, 需要考虑到由于网络/存储等性能不一致带来的售卖折价, 冷备份机器及售卖率影响下导致的平均销售价格折扣等因素..
1.2 算力成本估计
对于算力的成本, 通常包含几个方面. 附属的网络和存储成本, 机房建设(机柜/制冷/安保等..), 电费, 销售费用, 运营费用, 维护费用以及SLA不达标等带来的赔付等费用. 对于一些超大规模的项目, 还有一些融资租赁的成本.
通常有一个很快的速算算法, 附加费用五年成本按照算力服务器价格1:1计算. 也就是说280w的H100, 五年期内带上其它费用的总计成本为560w.
1.3 简单计算一下ROI
总体按照五年来算, 按照100%售卖率估计收入为450W, 五年辛辛苦苦的亏损了110W....其实在财务上有很多手段来调整利润, 我们这一章节采用最简单的直线折旧法按照五年折旧来计算, 这也是SemiAnalysis的折旧计算法方法, 也就是平均每年的运营成本为112W. 这样来看, 第一年的收入为20x12=240w, 利润率很高. 第二年基本持平, 第三年往后开始就亏损很大了...
那么为了弥补第三年的亏损, 很简单的一个做法就是再搞一个规模更大的B系列集群, 在第三年的时候用新的卡的利润来填补H卡的亏损.. 然后再过两年再用更大规模的R卡来填补B卡的亏损. 只要规模(杠杆)继续扩大, 亏损就可以往后藏很多年...但是前提是算力的需求能跟上这样的节奏...
其实这里就隐含了一个风险, 即期亏损可以通过更大规模的新的算力的利润来填补, 例如搞了10万卡的H100, 然后到第三年财务上要出现亏损了, 可以再搞40万卡的B200, 然后40万卡的B200即期利润可以把H100的亏损摊销掉. 但是同样再过三年B200的亏损又要拿更大规模的R卡的摊销, 实际的亏损隐藏掉延后... 直到有一天爆雷.
2. 谈谈SemiAnalysis报告的问题
我们先来看看SemiAnalysis对于Oracle的分析, 再详细的展开进行一些分析.
总共40万片GB200, 折合5555台NVL72的机柜, 单机72卡售价的售价在3M USD, 累计成本为16B USD. Hosting Cost就是在前文1.2章节阐述过的, 网络/存储/制冷/安保/数据中心的机柜占用等成本. 然后就是电费. 这两项费用上考虑了通胀和资源紧缺的因素, 逐年费用上涨... SA在计算安装维修这些成本时, 实际上是偏低的.
另一方面由于整个集群220亿美金的开销, 因此需要一定程度的融资, 因此带来了一些利息的支出, 通常的做法是自建数据中心, 然后卖给金融机构后再回租的方式来降低数据中心建设的资金占用, 同时还有一些算力服务器也可以构成抵押品, 但是抵押物自身的价值变动带来的抵押品价值波动风险, 抵押品变现等带来的费用, 利率变化, 残值风险等都没有考虑.后面一个章节我们将详细展开.
从SA的这个表来看, Margin还是很不错的. 但是需要质疑的其收入的估算可能有一些问题. 按照2.6USD/hr/GPU计算, 2.6x0.4Mx24x365= 9110M USD. 也就是说SA的估计是100%售卖率的情况下, 对于硬件故障维修导致的租金损失没有计算, 实际为了满足SLA需要一定比例的备份机器没有计算, SLA导致的违约赔偿没有计算, 租赁合同中的信用风险敞口等没有计算. 特别是后续价格雪崩后导致的退租风险等...即这部分需要考虑到信用风险...
例如这些损失定价计算叠加售卖率维修等影响, 实际上很有可能会导致Margin为负...
还有一部分是折旧的计算. 只采用了直线折旧法, 在一些针对所得税的处理上, 美国允许对折旧进行税收减免. 折旧算法基于 Modified Accelerated Cost Recovery System (MACRS)[2]. 而服务器通常归类为5-year property. 加速折旧法的比例如下所示:
在这样的方式下也会带来一些风险, 特别是自身经营状况导致的信用变化又会使得再融资成本增高...
3. GPU云的经营风险
在FRM(Financial Risk Manager)定义的风险类别如下:
市场风险(Market Risk)* 信用风险 (Credit Risk)* 操作风险 (Operational Risk)* 流动性风险 (Liquidity Risk)* 模型风险(Model Risk) 法律风险 (Legal Risk) 声誉风险 (Reputation Risk) 战略风险 (Strategic Risk) 监管风险 (Regulatory Risk) 系统性风险 (Systemic Risk)
我们对于GPU云的经营风险来看 ,主要集中在打星号的这几块. 当然对于租赁模式下的信用风险溢价后也会引入相应的模型风险. 我们将分别对这些风险进行阐述.
需要注意的是AWS对于云计算业务一直有六大支柱的阐述: 弹性, 安全, 性能, 成本, 稳定, 可持续. 实质上也是在针对前述的风险管理进行阐述.
基于这些视角下, 为什么AWS会选择定制自己的GB200... 也有很多考虑.. 而Google则是采购了大量的B200没有选择GB200, 也有它业务上风险管理的考虑, 以前写过一篇文章可以读一下
《AWS Re:Invent 从AWS CTO演讲的教训看AI云基础设施架构》
3.1 市场风险
市场风险主要有几块, 首先是利率风险, 由于整个基础设施建设的费用中有很大一部分资金采用融资租赁的方式, 浮动利率租赁合同中利率变化的会带来影响, 另一方面不同期限的利率变化也对融资成本带来一定的影响. 另一方面是残值风险, 租赁合同周期对于资产的价值在周期内的评估会产生影响. 另一方面是技术淘汰风险, 例如新的Rubin卡出来后将会导致抵押品残值迅速下跌, 从而进一步影响, 要么提前偿还资金, 要么补充抵押品...
另一方面, 随着市场租赁价格的变化, 例如OpenAI可能提前解约带来一定程度上的退租风险和重定价风险, 当然这一部分风险我们将其归类到下一节中的信用风险.
3.2 信用风险
信用风险主要包括以下几个方面:
违约风险：交易对手无法履行义务的风险信用价差风险：信用利差变化带来的风险降级风险：信用评级下调的风险集中度风险：过度集中于某些交易对手的风险国家风险：特定国家的政治经济风险
对于这种大规模集群, 大客户就那么一两家, 因此租户集中度风险是存在的. 然后承租人交易合同来看, 由于算力价格的波动, 承租人自身有提前解约的风险, 然后这些租赁合同又没有足够的担保. 承租人自身的信用也存在风险, 例如OAI被Meta挖人后, 以及应对Anthropic和Google Gemini的竞争下, 自身信用也有风险...它未来是否能够完全偿付租金是一个值得商榷的话题.
对比国内某些大模型厂家已经逐渐掉队, 然后开始退卡卖卡等... 退租后的这些算力如何变现? 通常应对这些风险的方法是降低租赁客户集中度和提供更好的多租支持能力.
最后, 还有因为中美特定政治关系影响, 导致GPU无法采购, 无法按时交付带来的违约风险等...
对于信用风险的量化建模通常包含三个量化指标
PD (违约概率)：承租人在特定时间内违约的概率 LGD (违约损失率)：违约发生时的损失比例 EAD (违约风险敞口)：违约时的风险暴露金额
然后我们就可以计算出Expected Loss = EAD x PD x LGD获得, 并且这些Expected Loss需要考虑到整个ROI模型中, 这也是国内很多线下算力中心最近一段时间遇到很多经营上问题的原因. 下图是几年前给小伙伴讲Vasicek Model计算, 虽然是Bassel中针对监管资本的计算, 但某种程度上可以借鉴用于算力租赁的信用风险的量化分析.
3.3 操作风险
操作风险主要包含如下几个方面
内部欺诈：员工的欺诈行为外部欺诈：第三方的欺诈行为就业实务和工作场所安全客户、产品和业务实务有形资产损失业务中断和系统故障执行、交付和流程管理
这一部分就是AWS在云计算六大支柱中谈到的安全和稳定. 最容易理解的是, 例如OAI的训练中的模型数据泄漏导致的安全问题, 数据中心内高功耗情况下的散热/供电等带来的安全隐患. 这些会带来相应的赔偿风险,
另一方面, 对于性能是否满足SLA, 资产本身的故障率等, 通常都会在租赁合同中有相应的条款, 例如有效训练时长低于95%, 训练MFU由于通信网络的问题低于xx%, 推理模型加载时长不能超过xxx, 存储在小文件高IOPS情况下的性能不低于xxx, 都有相应的条款约定. 当这些无法满足时, 可能会导致潜在的退租风险.
另一方面还有些法律合规风险等, 例如合同条款风险：租赁合同条款不完善或执行困难, 法规变更风险：相关法律法规变化对业务的影响..
3.4 流动性风险
其实流动性风险才是整个云经营管理的重点, Berkeley在2009年谈论云计算时, 有一篇著名的论文：《Above the Clouds: A Berkeley View of Cloud Computing》讲述了6点
从金融的角度来看, 前两条讲的是算力要有刚性兑付, 第三条讲的是算力的租赁关系, 第四条到第六条讲的是类似于金融机构的云计算算力机构的经营管理. 实质上这几点诠释了云计算如何为算力上杠杆的逻辑, 以及如何提供流动性.
例如前两条, 谈论了流动性风险中, 由于无法兑付客户的算力需求而产生的风险. 当然在GPU本身供应受HBM和COWOS产能制约时, 还有一种故意制造流动性溢价的方法.
新的算力刚出来的时候, 由于流动性紧张, 其租赁价格通常会非常高, 例如GB200整机柜按照2.6美金/每卡/每小时计算单月租金为13.4W USD, 但是现在很多GB200的租赁价格超过8美金, 则整机柜价格高于40W美金, 但这仅限于少数几个机柜的临时租赁价格, 长租的合同价格还是偏低.
对于Oracle/Coreweave而言, 他们采用Nvidia-Only的策略, 这种单一采购可以在生产排期过程中, 通过更高的预付款和绑定协议能够尽早的拿到货, 享受到初期的流动性溢价红利以及更低的购买价格. 同时买的越多, 就越能够在市场上制造流动性紧张的局面, 获得更高的溢价租赁合同.
而对于AWS/GCP/Azure则同时押注于自研ASIC和商用GPU, 对于一个成熟的大体量的云, 他们并不会很在意去制造一些流动性的问题, 从而对自己的长期经营带来很大的风险. 其实这一点上Azure在H卡上过于冒进的做法已经开始尝到恶果了, OpenAI和Oracle的Stargate项目, 某种意义上来说就给Azure带来了很大的经营压力, 所以今年5月裁员6000人后, 最近又准备裁员9000人...
除了这些由于资金和市场引起的流动性风险外, 还有一些现金流的风险. 过度集中的大客户使得云计算业务面临的风险也非常大, 租金收入的时间性和确定性风险受到单个客户违约的风险影响也很大, 另一方面过高的杠杆使得这样的云计算平台自身再融资也会出现一些风险...
下一章我们会详细来谈谈如何避免信用风险和流动性风险, 即为什么云计算需要把弹性放在第一位.
3.5 其它重要风险
除此之外, 对于一个云计算公司实体, 还需要考虑如下一些风险:
法律风险：法律环境变化带来的风险 声誉风险：负面事件对机构声誉的影响 战略风险：战略决策失误的风险 监管风险：监管政策变化的风险 系统性风险：整个金融系统面临的风险
例如最近的一些充电宝事件, 由于供应商的问题,导致自身的经营出现重大停滞甚至倒闭的风险都属于这一类, 例如交换机/光纤等频繁故障, CDU失效导致的过热损失和机房潜在的漏液等停运的风险, 或者管控平面/存储集群故障导致的数据丢失和整个数据中心停运的风险等, 这些风险直接就会产生声誉风险.
另一方面对于非美资的云还有可能面临中美关系的影响承受一些法律风险和监管风险等, 这些都需要考虑. 当然这些不是全文的重点阐述的内容.
4. 如何避免GPU云的经营风险
一般的经营过程中, 为了避免经营风险的管理手段无非就是开源节流, 我们首先来谈一下常见的节流手段, 即成本管理, 然后再来谈一些云计算特有的弹性多租, 然后再进一步扩展到对PaaS和MaaS的一些讨论. 最后还有一些经营上的资金流动性, 算力资产证券化的视角.
4.1 运营成本管理: “白盒云是云么?”
这是线下IDC机房和云计算共有的, 例如更大的采购量和预付款以及独家运营条款等可以降低采购成本. 然后同时直接向OEM采购避免从DELL/SuperMicro采购又会获得一定程度上的降本优势, 甚至是采用自研定制服务器的方式节省一些成本. 网络上也采用白盒交换机和一些根据某些workload垂直优化的拓扑结构来降低网络成本, 当然这些操作有利有弊, 例如AWS和GCP对于GPU互连的ScaleOut网络都有自己的考虑...
另一方面其实是Nvidia自身作为一个设备提供商, 他们眼里的AI Cloud和AI Factory的认知是有问题的, 即便是他们也在做一些BlueField一类的DPU, 对于云的弹性多租和软件的护城河理解还是不够深刻. 像Oracle这样的云现阶段很大程度上还是以裸金属交付为主, 软件上的护城河相对来说是有缺陷的. 例如SA的分析中也提到这个问题:
在大型合同的竞争中, 并不存在软件层面的护城河。我们开始看到一些早期迹象, 表明大型 AI 客户正在采用更多的软件层服务, 例如 OpenAI 可能正在采用 Coreweave 提供的托管 Kubernetes 服务。但总体而言, 我们认为这些还不足以构建一个可持续的护城河。
因此, 即便是采用白盒化的基础设施, 看上去通过规模效应降低了成本, 但是它的竞争力仅限于通过财务杠杆带来的一些流动性紧张时的溢价, 当流动性泛滥时, 或者其它玩家高杠杆进入这个市场后, 没有软件的护城河的白盒云并不能称为云. 那么软件的护城河在哪? 最近Oracle在sglang里面做出了很多非常高质量的贡献, 另一方面是往PAAS和MAAS拓展, 这些问题我们将在稍后的章节阐述.
4.2 弹性: 避免信用风险和流动性风险的良药
在3.2中我们谈到了信用风险, 主要是大客户过于集中而产生的集中度风险, 另一方面是由于算力价格本身的波动和新技术的引入导致的提前退租而产生的违约风险, 或者是这些大客户本身的营收状况存在的信用风险等.
通常Blackwell这些卡刚出来的一年, 由于供应相对紧张和大客户本身有在更好的算力下进行大规模训练的需求, 平均售价和售卖率都能得到保障. 流动性溢价通常在第二年开始逐渐消失了, 随着价格的雪崩大客户本身也有一定的退租风险, 因此对于GPU云来说就产生了经营性风险. 例如最近一些线下机房经常会在小红书上有这样的帖子
我们还是以经发生过的一些事情举例, 以H100为例来谈谈弹性的重要性...
H100单机成本是280w RMB, 配上网络和五年的电费运维费用差不多接近500w, 除以60个月, 那么每月的售价就是8.3w才能保本卖铁. 第一年供应紧张的时候, 单月租金可以做到12w以上... 这样第一年计提8.3w每月的成本, 净利润就是3.7w每月. 然而随着B200这些卡出来, 现在H100的租金降到4.3W一个月, 也就是说第二年开始平均每台机器要每月亏损4w.
弹性的重要性在供应相对充足的时候就算的过来了, 例如此时的H100不采用包年包月, 而是短期租赁, 例如每卡15块钱一个小时, 有些客户一天就用8个小时, 这样他看到的每月成本是2.8w, 比包年包月要低, 而剩余的16个小时, 其它客户用或者抢占式实例按照单卡7.5元一小时定价, 也可以类似把整个月的收入做到6w以上, 然后配合资产加速折旧的算法, 可以保证相对稳定的现金流.
其实这就是一笔弹性的账. 可惜很多人只看到了第一年, 只看到了包年包月... 经营的风险是错期发生的, 前期成本计提不足, 然后又疯狂的上杠杆上规模, 后期自然就会遇到这些问题.
云计算弹性多租是和线下IDC机房的本质区别, 上面这个例子也就显示了云计算弹性提高社会效率, 提供普惠的算力资源的能力. 从用户的角度而言, 他只根据自己的使用时长付费, 相对于包年包月节省了费用, 而云又通过资源复用售卖, 提高了销售利润.
这也是2009年Berkeley在Cloud economic 101中谈到的. 特别是在大规模推理场景下, 存在明显的需求变化时,
并且当它服务于大量的多个租户时, 资产租赁集中度显著下降了, 相应的信用风险也下降了. 但是另一方面也对流动性风险管理提出了更高的需求.按照峰值资源预留将会产生很大的浪费. 而当资源预留低于峰值需求时又会丢失客户, 因此我们需要能够将服务器本身更加快速灵活的给不同客户使用, 并按需的提供流动性.
所以为什么阿里云和AWS要推出基于CIPU和Nitro的弹性裸金属服务器, 它和普通的裸金属服务器的实质区别就在弹性上. 所以真正的GPU云并不是建设一个大集群去裸金属交付售卖和大客户签订长期的包年包月合同, 而是将算力本身商品化, 既能满足大客户的流动性(按需弹性)需求, 又能灵活满足大量中小客户的需求
最近一段时间看到AWS也在做出一些类似的描述:
因此你会看到AWS并不急于上线GB200, 而是需要完全定制自己的GB200机柜, 通过Nitro构建一个通用的网络, 避免专网诱惑.
这里其实暗含了一个标准化算力服务的需求, 通过标准化的算力来提高流动性, 避免流动性风险, 也就是说:
做大规模, 公共云优先, 标准化算力是提供高质量流动性的必然出路
流动性风险管理是指银行应避免各种业务品种在某一特定的时期风险过分集中和业务中产生的资金流量缺口风险。同时必须考虑自身财务状况恶化时, 被交易对手要求提前终止安排或提高信用安排时所需要的融资来源。那么云计算机构的流动性管理和库存调度如何能够更好的匹配算力的弹性需求? 简而言之规模越大流动性越好, 流动性成本越低。做大规模, 公共云优先才是一条正路, 简单的来说就像四大行对其它股份制银行或者农商行.
另一方面是来自于交易模式上, 用户自服务的方式而不是线下议价合同的方式将会更好的释放流动性, 当然短期内在流动性缺乏时也会存在一些做市商那样的去间接提供流动性, 但最终充分的弹性用云和大规模的流动性供应上,会在双方提供大量的流动性.
事实上在传统金融领域, 对于融资租赁业务通常是要求有适当的担保抵押和保险来转移风险的, 而对于算力服务而言, 这样的大客户租赁, 事实上对于退租违约金的偿付等还是有很大一部分成本没有纳入考量的. 当它们大规模释放这些计算实例后, 云如何将他们拆散了避免资源闲置和低售卖率风险是值得我们深思的...
4.3 弹性视角下的性能
弹性多租户的情况下通常会带来一些虚拟化的开销, 因此既要满足虚拟化给客户按需提供资源, 又要满足客户的性能需求, 不至于因为性能损失而产生算力资源折价售卖的影响. 如何保证零损耗的虚拟化成为关键技术. 例如阿里云的CIPU在存储上的能够和物理机提供完全一致甚至更高的性能(隔壁友商好像还是只有2x GB/s)
同时我们为什么要做弹性RDMA, 也是基于这个视角. 特别是在推理场景下和一些Agent MCP场景下, 提供统一的网络接入, 又维持E2E和独立的RDMA网络相同的性能.
4.4 弹性视角下的安全和稳定
当我们经营模式从传统的单租卖大客户, 演化到弹性多租的时候, 有几个潜在的问题需要考虑. 也就是前面谈到的一些操作风险相关的内容.
首先我们需要保证用户的数据安全, 计算环境的安全可信. 同时在服务器出现问题后, 尽可能的降低维护成本和宕机对客户的感知. 在这个视角下需要做很多工作, 如下图所示:
例如整个数据链路的校验/加密/隔离, 安全可信根, 还有特别重要的热迁移能力. 当预测到故障时, 能够在客户尽量不感知的情况下将计算实例迁移到其它主机是非常重要的, 另一方面是基于调度视角的热迁移, 对资源碎片进行整理能够满足不同规格的用户需求... 而在这一块, 全球唯一能够做到RDMA热迁移的只有阿里云CIPU, 而Nvidia BF3 DPU在安全/热迁移等多个场景下还有很多问题...他们的Lossless RDMA也在弹性多租下遇到很多挑战.
5. 弹性视角下的算力证券化
算力证券化=计算实例按照标准化的仓单交付
云计算的实质是一种融资租赁的业务模式, 融资租赁在FRM框架中被视为一种复合型金融产品, 其风险管理需要综合考虑信用、市场、操作等多重风险因素, 而它自身的技术性壁垒下, 经营者很少对这些风险有足够的认知, 也就是SemiAnalysis分析出来有很好的ROI, 但是按照H系列卡的实际营收来看反而会出现亏损的原因.
云的弹性经营实质是在规避信用、市场、操作等多重风险, 前述章节已经讲过了. 而算力弹性售卖的核心逻辑是算力证券化, 即需要以标准化的方式提供算力, 标准化算力的交付物一方面需要维持计算实例上的标准化交付,即IaaS层的算力证券化, 说一个非标交付的例子, 例如AWS并没有标准的RDMA RC Verbs兼容的接口, 在3FS/DeepEP IBGDA/Mooncake这些生态出现后, 传统的基于NCCL插件适配的非标生态直接导致了一系列问题. 而你会看到阿里云的eRDMA和Google Falcon都采用标准RC交付, 这就是在IaaS层为什么要强调标准化接口的原因.
另一方面还需要提供完善的PaaS和MaaS能力, 即以API或者token作为标准化算力的交付物.
因此整个算力证券化的过程是分层交付的, 标准化的交付避免复杂的租赁合同, 使得按需获取弹性使用成为可能. 算力使用者将一些风险转嫁给了云, 而云又通过各种灵活的定价策略和销售策略使得资源能够被更多的算力使用者消费, 从而整体上提高了社会效率, 降低了整个算力使用的成本, 实现了计算资源的普惠供应.
当然在PaaS和MaaS上, 还有很多可以进一步提高弹性的空间, 例如隔壁友商有一篇文章在说传统云还在[卖铁], 下一代云已经在[炼钢], 然后是不是马上要大跃进了呢?
实际上从前面四个章节的分析, 传统云能盈利的都不是卖铁, 有太多的经营上的细节, 归根结底就是弹性, 以及围绕着弹性的安全/稳定/性能/成本的考虑, 这才是云计算的全貌, 脱离这些就真的是卖铁了...例如那个签大单大跃进卖裸金属的Oracle...
当然, 有些财务上的亏损可以通过比较好的手段隐藏, 例如前文所述的, 在H100卡第三年产生的亏损通过更大规模的B卡首年利润来隐藏, 将亏损进一步向后顺延. 谈到B卡顺便吐个槽, 实际上最近SGLang的一些优化和很多仿真分析都可以得出一个结论, GB200-NVL72的实际性能大概是H100的3倍左右.
那么即便是对于当前的推理模型, GB200的实际定价参考H100 1美元/每卡/每小时应该也就是 3美元/每卡/每小时, 至少在推理场景下B卡的高溢价并不存在, 相反H100更小的规格还能做出在MaaS层的弹性调度能力... 这笔卖铁的账真的挺难算的....即便是炼钢也挺难的...因为流动性的溢价在推理场景下被前一代卡压住了...
参考资料：
How Oracle Is Winning the AI Compute Market: https://semianalysis.com/2025/06/30/how-oracle-is-winning-the-ai-compute-market/
MACRS: https://en.wikipedia.org/wiki/MACRS
本文作者：zarbot，来源：zarbot，原文标题：《谈谈GPU云的经营风险和流动性管理》