开篇先交代个背景前阵子有个做AI应用的老朋友半夜给我打电话说他们跑一批大模型的微调任务云上排队排了三天GPU竞价实例还被人抢走了一大批。他问我自建算力到底值不值得搞我说这问题现在问已经不是要不要的层面了而是什么时候开始规划的层面。这个标题——AI初创公司的下一个护城河自建算力——看着像是一个成本话题实际上牵涉的是产品迭代速度、技术壁垒、供应链话语权甚至团队工程能力的整体升级。我从2022年开始接触大模型训练集群从租云GPU到搭自己的小集群再到跟做Infrastructure的老同事们一起落地千卡级训练场这一路上的经验和教训写下来给正在纠结这个问题的团队做个参考。一句话先概括我的结论自建算力不等于省钱但它是AI初创公司从应用层玩家往模型能力拥有者跃迁的一道门。至于这道门怎么进、进门以后怎么走下面一条一条拆给你看。1. 先算账自建算力在什么条件下才划算很多人一拍脑袋说云上太贵了我们就自建这其实是最危险的决策方式。我见过不止一家公司算力账单还没省出来先被折旧、运维、闲置吓懵了。1.1 租云和自建的账面成本对比三年期的真实账本我们用一个常见的配置来计算假设你的团队需要持续运行GPU集群单机用8卡单卡按主流市场常见的训练级型号来估算单机成本大概在几十万元量级配套的存储、网络、机房托管、电力等加起来单机不含维护的总投入大致在50万~80万之间。云上租用同等算力按长期折扣后的价格估算单卡每小时的费用大概在30~60元区间浮动抢不到竞价实例的情况下还得上浮一年365天、每天按8小时的训练时长估算单机每年的云成本大概在几百万的量级。账面上的结论很清楚如果训练负载能稳定保持较高的日均使用率差不多一年半到两年自建的TCO就能追平云上。但这里有几个变量必须注意利用率自建集群一旦闲置就是纯亏。云的弹性在这里是实打实的优势。硬件寿命GPU集群三年需要更新迭代。残值处理和换代成本都要提前算进账里。隐性成本运维、监控、故障恢复、网络调试这些人力投入每个月都是真金白银。1.2 什么阶段的公司才具备自建的前提条件我梳理了一下自建算力至少要具备三个前提缺一个都会很吃力训练负载长期稳定你不是三天打鱼两天晒网地调模型而是有持续迭代的模型或产品线GPU利用率能稳定在60%以上。团队具备Infrastructure能力不是有会用PyTorch的人就行而是有人懂NCCL、RDMA、并行文件系统、作业调度能把集群当产品来运维。现金流能扛住硬件采购和一年内的闲置期刚拿到天使轮、团队不到20人我更建议先云上把产品验证跑通别急着买卡。我曾经见过一家做行业大模型的公司团队20多人靠着一笔Pre-A就一口气买了40多张卡结果项目方向调整算力需求断崖式下滑最后那批卡要么折价转卖要么在机房里积灰。算力规划的第一原则不是买得起而是跑得满。2. 自建算力背后那一整套看不见的工程量很多人以为自建算力就是买几台服务器装个GPU插上去。等你真的开始干了才会发现GPU只是整套系统里最不让人操心的部分。2.1 网络设计RoCE和InfiniBand怎么选这是极具迷惑性的一步。单机内部的NVLink把8张卡连成一个整体这个好解决但一旦算力规模超过单机加入第二台、第三台机器机器之间通信的性能直接决定整个集群的训练效率。我这些年做训练集群网络方案主要就在RoCERDMA over Converged Ethernet和InfiniBand之间权衡。InfiniBand性能好、生态成熟但交换机和线缆成本高而且供应链交付周期往往比以太网长RoCE则能在标准以太网硬件上跑RDMA成本友好很多但配置复杂度更高——要把无损网络、PFC流控、ECN拥塞控制全都调对了性能才上得去。有一个参数是围绕MTU的调优。如果MTU设置有误大包分片就会多RoCE的性能可以掉到原来的三分之一。我见过不少团队硬件买回来训练速度上不去排查了一圈发现就是MTU没调到9000。这事情就是典型的配置一个参数速度翻几倍。2.2 共享存储训练和推理的不同需求训练场景需要支撑海量数据的随机读取和推理场景那种小批量、低延迟的访问模式完全不是一回事。我建议把训练存储和推理存储从架构上分开设计场景核心需求推荐方案训练高吞吐、大文件顺序读分布式并行文件系统如GPFS、Lustre或高性能NAS推理低延迟、小文件随机读SSD直连或轻量级网络存储缓存有个容易踩的坑很多团队只在白天跑训练为了省钱把存储设计得很小结果晚上跑起批处理任务时数据加载成了瓶颈GPU在那里空转等着喂数据。存储这块省下来的每分钱最后都会以算力利用率下滑的形式加倍还回去。2.3 算力调度的切入时机Container、K8s与作业调度器的搭配物理机装好、网线插好之后真正的工程重心就来到了调度层。学术界和工业界的标准实践是让Kubernetes负责资源编排再在上面架一层面向AI作业的调度器比如Volcano、Kueue这类实现排队、优先级、抢占比等功能。这套组合解决的核心痛点就是开头我那位朋友遇到的问题——资源规划。自建集群同样需要排队机制毕竟不可能人人都是最高优先级。但你有控制权你可以根据业务需要自己定义调度策略而不是被云平台一个全局策略搅得头疼。3. 训练跑不起来的那一夜从AllReduce卡住说起如果说网络和存储是自建算力的地基那训练框架和它背后的故障排查就是地面上那栋房子能不能住人的问题。这里我挑一个最典型的困局来讲多卡训练突然卡住不动。3.1 从一道数学题理解为什么会卡住分布式训练的核心操作是AllReduce——各个GPU把各自计算得到的梯度汇总再分发给每个GPU用于更新模型参数。这个过程是所有GPU的集体行动意味着只要有一张卡延迟偏高全体就得等它整个训练步骤的耗时就被拉长到那张最慢卡的水平。有一次我们集群突然出现周期性卡顿每跑若干个Step就抖一下像打嗝一样。一开始怀疑存储因为每次卡顿正好落在检查点checkpoint写入的时间点附近。后来经过性能剖析发现问题出在网络拥塞——某个节点上一个被我们忽视的分析任务占用了额外的带宽把训练通信挤了。这类问题在云上可能只是一个账单明细浮动但在自建集群里你必须要靠自己的监控工具把每一跳的延迟、丢包、重传全部看透。3.2 排查路径的一个完整闭环把排查流程一般化可以整理成下面这样一套循环先看训练日志有没有报错和警告确认是卡死还是慢。在卡住的节点上抓包或采集通信库指标比如NCCL的耗时分解。从单机内通信测试、单机间通信测试逐层下发定位哪一段链路出了问题。特别要检查网络丢包、PFC死锁、拥塞风暴这三样东西在自建集群里是排名靠前的卡训练嫌疑犯。修复后压测验证确认性能回到预期再重新跑训练。这轮流程看起来机械但非常实用。有一回我们排查一个怎样都解释不通的周期性掉速最后发现竟然是一台机器上的风扇控制固件有bug温度一高GPU自动降频算力悄悄流失。硬件层和系统层的交叉影响在自建环境里要靠人的经验去担。4. 硬件的江湖采购、验收与迭代的经验之谈自建算力绕不开的就是跟服务器、GPU、网络设备打交道。这里面水很深我把自己踩过的坑和不踩坑的方法一起列出来。4.1 不只是选GPU型号那么简单整机架构的取舍很多人一上来先问买什么卡实际上你真正要做的是选一套系统。我通常建议从两个方向来锁定配置Scale-up方向在单台服务器里堆更多的卡配合NVLink或类似的高速互联适合单任务需要极高通信带宽的场景。代价是单机造价和散热压力大。Scale-out方向用更多性价比更高的机器通过网络组网把总规模做大适合任务并行度要求高、但单任务通信规模可控的场景。一个新的思路是训推一体。如果同一个集群既跑训练又能承载部分推理流量就能错峰利用。白天推理推理、晚上集中训练比单独建两个集群划算得多。这里尤其对应用型厂商成立训练不会全天候占满资源而推理总有一些时段是可以替代的。4.2 供应商谈判、质检与子卡惊魂硬件供应链里有不少细节外行容易当成纯参数对比内行知道那是血泪。有一次我们向某厂商采购一批算力卡组装机器之前我想起去设备调试图形界面看一眼结果差点吓到——发现卡上GPU核心数量少了一半。这就是行业里俗称的子卡套路利用某些型号本来就在规格上有对称裁剪的空间供应商堂而皇之地把阉割版发过来单看型号编号完全看不出差别。后来我们让工程师把每张卡都跑起来做压力测试核对核心指标和标称规格……幸好发现得早。所以我把验收流程看成硬件采购的生命线到货先做外观和序列号核验确认每一张卡的型号、规格没有出入。上架前必须做全量压力测试让GPU满载跑半个小时以上观察温度、功耗、性能是否达标。跑一次端到端的代表性训练或推理任务对比结果和标称基准。保存所有测试记录作为售后维保的依据。4.3 能不能用满比算力多少更重要硬件采购还有一个反直觉的判断维度往往会发现花同样的钱买了更高端的卡实际效益反而不如一票低一档但能跑得慢而稳的方案。AI训练对通信的敏感度有时候要高过对峰值算力的敏感度。如果一个集群的网络做不好任何型号的卡放在上面都是浪费。我见过有人用顶配服务器组了一台训练跑不满、推理延迟还高的昂贵集群最终总结就一句话没有均衡的架构就没有性价比可言。5. 机房的现实做不到恒温恒湿一切性能都是空话很多人觉得机房的事情交给托管商就行直到你的机器因为温度问题出现异常掉卡才知道电和风是比GPU更硬核的门槛。5.1 电力容量、机柜密度与散热的设计逻辑自建算力的机房选址电力是第一优先级的硬条件。GPU服务器的功率密度远高于普通机柜单个高密度机柜的功耗可以轻松到普通办公机房的好几倍。你不仅要有足够的电力余量还要面对一个现实问题如果机柜里塞满了高功耗设备普通机房的制冷循环很可能带不走热量。我在规划集群时用的一个基本估算公式是先确定单机峰值功耗再乘上机柜内可放设备的数量加上网络设备的功耗经常被忽略但交换机在满载时的功耗不低最终把这个数跟托管机房能给的单机柜电力上限核对。超过上限就只能拆柜、降密度否则开机的那一刻就会跳到电网负荷保护。5.2 液体冷却和空调方案常规散热踩过的一个奇特的坑大多数初创公司的自建集群还在风冷阶段。但有一次我们采购的一批服务器到了夏天频率总是莫名其妙地往下掉排查发现是风冷进风温度超过了临界值。当时托管机房告诉我们的是恒温22度但实际机柜位置的局部温度因为前后机柜互相串热已经漂到了29度以上。那个夏天我们还试过一种土办法把机房空调出风口用导风管道直接怼到服务器进风口。温度确实降下来了但也带来了新问题——因为风道占位维护通道变窄后续换线缆时工程师差点要把机架拆了才能钻进去。液体冷却是高密度集群更彻底的解法但它意味着机房的改造投入更大不是每一家托管都愿意接。如果资源有限我建议至少确保机柜布局采取面对面、背对背的原则让热量不会循环叠加进风温度要在夏季最热的时候实地拉测而不是信标称值。6. 护城河的真实面目自建算力到底在壁垒上起了什么作用聊完工程细节最后回到标题本身。为什么说自建算力是AI初创公司的下一个护城河这里我需要把护城河三个字解释清楚——它不是那种我今天采购了多少块卡的姿态而是一整套能力沉淀的结果。6.1 算法复现和模型迭代速度别人还在排队你已经跑完了一轮如果做AI应用模型迭代速度几乎决定产品对市场需求的一切响应能力。在云上你可能要面对配额限制、排队等待、被人争抢资源自建集群是完全可控的深夜想到一个实验思路早上起来就已经跑完了一轮对比。试错成本的低位是很多团队在高强度竞争中能撑下来的核心原因。对于那些训练数据量巨大、日更模型的互联网级团队这已经不是护城河宽不宽的问题而是生死线。自建集群意味着你把实验的自由度锁在了自己手里。6.2 数据安全与合规的内生需求很多垂直行业的模型训练涉及私有数据。数据不出域在今天已经不是加分项而是准入门槛。自建算力从物理上降低了数据暴露面不需要把数据拷贝到第三方平台后再做合规评估。对有保密要求的行业客户来说自建算力是商业谈判桌上非常重的一块砝码。6.3 站在供应商博弈的另一侧当今AI算力的供应链GPU的市场话语权很强。完全依赖单一云的资源采购你在价格、配额、交付周期上基本没有什么主动权。而如果你有自己的算力底仓再去云上租用谈判姿态完全不同——你可以用自建为主、云上弹性为辅的混合策略来要求更优的折扣也可以在不同的云之间做冗余和备份。这个灵活性带来的长期价值比省下来的钱有意义得多。6.4 人才密度与工程文化的无形壁垒从试验开始到集群维护、性能调优、分布式训练的故障排查这一系列过程会让团队的工程能力肉眼可见地增长。这种人才密度不是靠招聘广告砸钱就能砸出来的。投资人愿意给有底层算力能力的AI公司更高估值本质上是认可这套隐藏在服务器和网络链路背后的系统工程方法论认可团队对付不确定性突发状况的能力。7. 最后的实操建议与个人体会如果上面这些你已经仔细看完了决定要迈出这一步那我给三条落地原则作为收尾。第一从小规模开始验证。第一次自建可以不从几百卡起步用二三十张卡把网络、存储、调度、运维这套链路完整跑通在内部形成一套自己的SOP再谈扩容。别一上来就追求顶配集群跑不通的大集群比小集群更难救。第二成本模型里永远预留20%的冗余。电费、带宽、维修、折旧、备用设备每一项都可能超出初期的预估。硬件时代的不确定性和云时代不是一个量级。第三把训练和推理混合调度当做默认设计。很多公司刚开始建设时只盯着训练等推理的需求起来后才发现集群架构不支持低延迟推理又得买新机器。训推一体的弹性混部同样是护城河的一部分。我个人在这几年最大的体会是自建算力表面上是在解决问题实际上是在把团队逼着往系统思维上成长。那些在云上被隐藏的细节——电力、网络、散热、调度——每一件都会在你面前摊开逼你去理解一套AI系统真正运转起来所需的全部条件。这个过程痛苦但完成后你会获得一种很少人拥有的底层掌控感。而这种掌控感恰好就是护城河的真正源头也是我认为所有认真做AI的初创公司最终都必须补上的一课。