前几天跟一个做AI应用的创始人聊天他说每个月的算力账单快把融资烧没了正在纠结要不要咬牙上自建算力。这个问题这两年被问得越来越多尤其是做Agent、做垂直模型微调、做视频生成的小团队。我的回答一直很直接如果算力只是成本那就租如果算力是你产品迭代速度的一环那就得认真算一算自建的账。自建算力正在变成AI初创公司最硬的一道护城河但前提是你会建、会养、会用。这篇文章不打算讲宏大的“算力战略”只聊一个AI初创团队从云上迁移到自建集群的真实路径什么时候该自建、怎么选硬件、怎么搭分布式算力、踩过哪些坑、ROI怎么算。适合正在被云账单折磨、又担心自建后运维翻车的技术负责人和创始人参考。1. 为什么自建算力能成为护城河1.1 从租用算力到自建算力的逻辑转变过去两年大多数AI初创公司都是“云原生”的开个账号、刷卡、拉起几十张卡模型开始训练过得像个租车公司。这种做法最大的好处是灵活今天要A100明天要H100后天想退回云厂商都随你。但随着业务稳定下来算力从“弹性需求”变成“持续需求”租车的弊病就出来了一是账单永远不封顶二是排队和限流三是你的数据、模型、调度策略全都长在别人平台上。自建算力并不是把云账单换成折旧账单那么简单它改变的是你对算力的使用方式。云上的GPU是按“实例”租的自建之后GPU变成你自己的资产你可以7x24小时跑推理可以在半夜没人用的时候批量跑数据清洗可以把训练和推理调度共用一张卡。这些操作的边际成本几乎为零而云上每执行一次都要重新计费。很多团队问我说“自建是不是就是买几台机器插上电”其实不是。自建算力的核心是把硬件变成软件可以精确控制的资源池这需要一套调度、监控、容错体系。一旦建成你获得的不只是便宜而是“别人排队等待、你随时可跑”的确定性这恰好是模型迭代最需要的节奏感。1.2 护城河的本质成本、数据、迭代速度护城河这个词被讲烂了但放在AI初创公司身上其实只有三个要素真正扎得深成本结构、数据私密性、迭代速度。成本结构好理解。同样一张RTX 3090的算力云上按小时租和自建摊薄到每天价格可能差到3到5倍。我算过一笔账一张RTX 3090的二手卡摊三年折旧加上机房和电费每小时成本不到云上租用同级别实例的一半。初期看起来购买成本高但一旦利用率超过40%自建的账就比云好看。对需要持续训练和推理的团队来说这种成本差异直接决定你的定价权。数据私密性是被低估的一环。做医疗、金融、法律领域的垂直模型客户要求数据不出域的情况非常多。用公有云训练即使签了保密协议客户依然有顾虑自建集群可以把数据全程锁在自己的机房里安全审计也好做。这种“数据可用不可见”的信任感正是B端客户愿意买单的重要原因。迭代速度则更微妙。模型微调和Agent产品试错需要频繁跑实验云上的配额、网络延迟、数据回传都会拖慢节奏。自建算力下每一次实验的排队时间几乎归零你可以在一个晚上跑完原来要一周的消融实验。这种节奏优势积累下来就是产品功能的领先半拍而AI赛道的半拍往往意味着市场窗口。1.3 什么样的公司适合自建算力不是所有AI初创都该自建。我见过一些团队被“自建算力”这个概念点燃脑子一热买了十几张卡最后利用率不到20%运维天天救火反而拖垮了业务。做这个决定前先回答三个问题你是否有长期稳定运行的算力负载如果只是每周跑一两次微调其他时间闲置自建大概率不划算。但如果你有固定日活用户调模型推理或者每天都要跑数据管道和实验训练自建的利用率就能拉起来。你是否愿意投入人力搭建和运维自建不是买硬件是养一个小型基础设施团队。至少要有一个人懂Linux、GPU驱动、Docker和网络另一个人最好懂分布式调度。没人懂运维就贸然自建容易变成新的技术债。你是否在意数据主权和定制能力如果你的业务依赖私有数据或者需要对训练框架和调度策略做深度改造自建的价值会非常高。反之如果只是标准模型API调用那自建纯属浪费。我后来给创始人的判断标准很简单算力占你月度支出的比例超过30%且未来12个月不会大幅下降就值得认真算自建这笔账。2. 自建算力的四个关键选型2.1 硬件选型显卡/加速卡的性价比账自建的第一步永远是选硬件这也是最容易交学费的地方。当前可选的无非三类消费级显卡RTX 3090、RTX 4090、专业数据中心卡A100、H100、L40S、以及国产加速卡。很多初创团队选择RTX 3090原因很现实24GB显存够用FP16算力约71 TFLOPS二手卡性价比高用来跑7B、13B量级的模型微调和推理完全足够。RTX 3090最大的优势不是参数而是生态兼容。PyTorch、CUDA、FlashAttention都有成熟适配社区踩坑资料多出问题容易搜到方案。相比之下RTX 4090性能更强但功耗高、散热压力大多卡并行时NVLink被砍了组集群反而更难。我见过有团队先买4090后懊恼的例子就是没想清楚“单卡快”和“集群稳”是两回事。如果预算充足且业务对显存、训练吞吐有硬要求A100/H100还是首选。但这里要泼一盆冷水很多初创团队根本用不满A100模型的batch size和小集群通信开销会让旗舰卡的利用率惨不忍睹。与其买一张卡全程吃灰不如买一批中端卡把实验并行度提上来。硬件选型还有一个隐性成本售后和维修。消费级卡没有企业级质保挂一张就是一张的损失数据中心卡服务好但价格也“好”。我的建议是主力推理混跑用RTX 3090/4090核心训练任务可以少量配置A100/H100千万不要一步到位买一堆顶级卡吃灰。2.2 网络与存储集群不是把卡插在一起很多人觉得集群就是几台服务器用网线连一下实际上一训练模型就原形毕露。多卡训练需要高速互联两张卡之间动辄几十GB的梯度同步千兆网根本扛不住跑起来所有卡都在等网络。自建集群最少要上25GbE交换机最好有InfiniBand或RoCE否则分布式训练的效率会被网络打成麻花。存储同样是容易翻车的环节。训练数据、checkpoint、日志都在本地盘算力节点一重启数据就丢这是无法接受的。需要共享存储比如NAS或者分布式文件系统把数据集和模型权重放进去多个节点一起访问。但注意不要直接把NFS挂到训练路径上IO瓶颈会卡死数据加载标准做法是把数据在训练前打成TFRecord或WebDataset格式顺序读取。网络和存储的预算往往被压缩这是大忌。我见过一个团队买了几十张卡却用千兆交换机训练速度被网络拖慢了一半最后只能加钱换网络设备。算算换网络耽误的时间成本远远超过一开始多花的几万块。2.3 分布式算力调度从单机到GPU池硬件到位只是第一步真正让算力变得“可用”的是调度层。没有调度系统每张卡都是信息孤岛跑任务前还得人工分配机器、设置环境效率低还容易出错。Kubernetes加上NVIDIA Device Plugin是目前的主流也可以考虑开源的Ray、Slurm关键是要把GPU当成池子里的资源而不是给每台机器贴标签。调度系统的核心价值在于第一根据任务优先级和资源需求自动分配GPU第二支持队列机制任务多时排队任务少时碎片化运行第三提供监控和日志方便定位算力瓶颈。对AI初创来说不需要一开始就上很重的平台可以先从一台调度服务器加Agent节点起步跑通之后再扩展。我们团队早期用的是最简单的Shell加脚本手动分配机器后来任务多了实在撑不住才切到Kubernetes。切换之后最明显的变化是不再有人问“这张卡谁在用”每个人提交任务自动排队GPU利用率从不到30%涨到60%以上。这个提升不是靠硬件省出来的而是管理出来的。2.4 软件生态驱动、容器、训练框架自建算力不是把驱动装完就完事软件栈的每一层都可能出问题。驱动版本和CUDA版本的匹配PyTorch容器与驱动的不兼容Infiniband驱动的编译失败这些问题我不信每个运维没踩过。我的经验是少折腾多用官方容器镜像比如NVIDIA NGC或PyTorch官方Docker驱动版本锁定CUDA版本跟着镜像走能省掉大量“环境地狱”。开发环境尽量容器化每个项目一个镜像环境互不干扰。用Docker或许会带来镜像占空间的烦恼但和“项目A升级库导致项目B跑不了”相比这一点成本不值一提。更进一步可以上Kubernetes管理容器调度让Docker和GPU资源统一被编排。训练框架的选择同样影响算力利用率。分布式训练不一定非要DeepSpeed或Megatron如果模型规模不大用PyTorch原生的DistributedDataParallel就够。框架越简单出问题越容易定位。不要为了炫技引入太多组件否则最后会发现你花在调框架上的时间比训练时间还多。3. 从零到一的自建实操路径3.1 第一步明确业务场景和峰值需求动手买硬件之前先在纸上把你的负载画清楚。是训练为主还是推理为主还是混合负载训练负载有长时任务和同步通信需求对网络和存储要求高推理负载则更看重时延和吞吐需要做模型切分和动态批处理。很多团队连“自己到底卡在训练还是推理”都没搞清买完机器发现完全用不上。算需求时不要只看平均值要看峰值。假设你的推理业务每天有两次高峰每次持续1小时那你的算力容量至少要覆盖到高峰的1.5倍否则用户一多就排队。同时预留一点余量给临时实验最好再保留20%的资源给故障转移。把这些数字记下来按峰值算卡数千万不要按均值买卡不然业务一冲量你又要去云上临时补。把这个需求转化为GPU型号和数量时还要考虑显存和带宽。我做推理服务时发现模型量化到INT8之后RTX 3090的24GB显存可以塞下一个13B模型的量化版本但并发一高显存就不够需要配合PagedAttention这类技术提高利用率。所以别只看卡数显存和并发预估要同步做。3.2 第二步机房、电力、散热的现实约束决定自建后第一个要面对的其实是“放哪”。办公室放两到三台高配服务器可以放二十台那就需要规划机房了。最基本的要求是电力要够、散热要够、噪音要控制。一张RTX 3090满载功耗约350W一台8卡服务器就是2.8kW二十台就是56kW一般办公室的电路根本扛不住。这时候得找专业机房托管或者改造电路。散热是另一个大坑。GPU满载时温度控制不住性能会下降寿命也会受损。机房的空调不能只看温度看的是房间里的总热负荷。用一台8卡服务器每小时要排掉2.8度电的热量空调制冷量至少要按1.3倍散热计算。我见过团队把服务器放在没有精密空调的小房间里结果夏天GPU直接热到降频训练速度比冬天慢20%。噪音容易被忽略但对办公环境影响很大。放在工位旁边的服务器满载时风扇声音堪比吸尘器人会崩溃的。所以大多数选择托管的团队宁愿每月交托管费也要把机器放到专业机房。托管成本通常按机柜和电力算但和云账单比还是便宜得多。3.3 第三步搭建集群的清单和踩坑记录一步步来的话自建集群大致分六个阶段采购服务器、GPU、交换机、存储设备签机房托管合同装机装驱动和CUDA验证单机多卡是否正常配置网络设置IP、VLAN、路由打通跨机通信部署容器运行时和调度平台接入监控系统持续追踪GPU显存、温度、利用率迁移业务把原来的训练和推理任务搬到新集群。这套流程看起来简单实际每一步都有坑。装机时最容易犯的错是电源功率不够一张卡瞬时功耗可能跑到400W电源要按冗余设计。网络配置时容易把不同机柜的网线顺序搞混建议一开始就贴标签。部署容器时最容易遇到GPU权限问题需要配置nvidia-container-runtime。监控系统一定要第一时间就上不要等出了故障再补。我自己的习惯是每台机器打一个固定标签记录硬件型号、驱动版本、所在机柜和IP所有变更都写在文档里。硬件运维最怕的就是“谁动了我的机器”说不清楚过程记录比事后排查重要得多。3.4 第四步成本测算与ROI成本测算是自建决策里最容易感性化的部分。我建议把成本拆成五个部分硬件采购、机房托管、电力、人工运维、备用设备。硬件采购是一次性支出机房托管和电力是持续支出人工运维可以按半个到一个人天折算备用设备则是你应对故障的第一道防线。以8张RTX 3090的集群为例一台8卡服务器整机大概8到10万元加上交换机、存储或共享盘初始投入约15万元。托管加电力一个月约3000到5000元运维人力按兼职算一个月5000元。这样一年的总成本大约20万元出头。同样的8卡GPU在云上按最便宜的抢占实例算一个月也要大几万一年轻松超过30万。如果线上负载稳定第一年就能回本第二年开始是纯节省。但这个计算有个前提利用率。如果集群每周只用10小时那每小时的摊薄成本会高得吓人自建反而更贵。所以ROI要分两条线看一条线是资源利用率有没有超过40%另一条线是业务增速能不能在未来一年内吃掉多余容量。两条都满足自建就是好生意。4. 自建算力的常见问题与排查实录4.1 GPU利用率上不去从数据管线找原因自建集群最常见的现象是GPU利用率只有20%但任务明明在跑。很多人以为是模型代码问题实际上绝大部分原因是数据加载太慢。数据从磁盘读到内存、预处理、再送到GPU任何一个环节慢GPU都会闲着等数据。检查一下训练脚本里的DataLoader看num_workers是不是太少看数据是不是跨网络读瓶颈基本就暴露了。我们曾遇到一个案例GPU利用率卡在30%调度显示任务没排队但显存和SM占用都是低水位。后来发现每个epoch前都要重新读一份几百GB的原始数据并做一次shuffleIO全打在同一块机械硬盘上。换成SSD再用WebDataset做预处理利用率直接跳到70%以上。所以排查利用率问题先看IO再看CPU预处理最后才怀疑GPU。另一个容易忽略的点是batch size太小导致kernel启动开销占比高。一次前反向计算可能只要几毫秒如果batch size设得太小GPU大部分时间花在kernel启动和同步上。可以把batch size调大同时使用gradient accumulation让每次迭代的数据量尽量填满显存这是最直接的提速方法。4.2 AI Agent并发场景下的算力瓶颈做Agent产品的团队越来越多AI Agent并发和传统模型推理不太一样。Agent任务通常是一连串模型调用和工具调用中间穿插上下文管理、记忆检索和外部API等待。在这种情况下GPU可能大部分时间都在空闲等待真正的瓶颈反而不是算力峰值而是调度效率和吞吐。我们跑过一组压力测试50个Agent实例并发每个要调用三次大模型。结果GPU使用率不到40%但用户响应延迟却很高因为单请求内的序列调用是串行的GPU前面在忙后面在等。后来我们引入了连续批处理把多个请求的token级计算拼在一个batch里执行吞吐翻了接近一倍。这个优化对Agent场景很有用比单纯堆GPU卡更省钱。另外Agent场景需要频繁的“多AI协作”也就是多个模型互相调用、多个Agent共享信息。这会带来很大的内存调度压力显存中需要缓存若干个会话的中间状态。我们最后用vLLM这类推理引擎管理显存通过PagedAttention把显存切小页按需分配才让并发量提上来。如果没有这套机制你买再多卡也扛不住Agent的并发浪涌因为闲置显存浪费太多了。4.3 多租户和资源隔离怎么做初创公司内部通常会有多个小组算法组做训练产品组做推理还有数据组做清洗。如果大家共用一个GPU池不做资源隔离就会出现“一个大任务把资源抢光其他小组干等”的局面。最省事的做法是用Kubernetes的Namespace做逻辑隔离再用ResourceQuota限制每个组的GPU数量确保小任务也有资源可用。隔离的关键还需要任务优先级。训练任务可以晚上大量跑推理任务必须实时响应可以把这两种任务放到不同节点池并设置资源标签。调度时实时任务优先训练任务在闲置节点上排队这样既不浪费算力也不牺牲用户体验。我们曾经因为没有划优先级一次全量训练把推理资源挤占产品线上直接报错后来痛定思痛把调度策略重做了一版。数据隔离也要考虑。不同项目的数据如果都在同一个存储路径上权限很容易混乱。建议在自建集群第一天就建立清晰的数据目录结构和访问控制用Linux的用户和用户组管理目录权限或者直接在对象存储上设置IAM。这事情不复杂但拖到后期再改成本极高。4.4 算力闲置与弹性扩缩容自建的天然劣势是弹性不足。业务有高峰有低谷低谷时GPU闲置无法退回高峰时集群容量可能不够。应对办法是建设“本地集群云上弹性池”的混合模式所有稳定流量走自建突发流量临时从云厂商拉一批实例跑完就退。这样既保留了自建的低成本又买了一份保险。弹性扩缩容的实操细节在于镜像和脚本要提前标准化。自建集群上用Docker容器的环境云上也能用同一个镜像跑这样你才可能在几分钟内把云上实例拉起来。如果两边环境不一致迁移就要半天时间弹性就没有意义了。另外要盯住集群的闲置资源。调度平台可以统计每张卡的历史利用率定期把利用率极低的节点收回来或者把闲置节点做功耗限制节省电费和散热压力。宁可让少量节点保持热备用也不要让一群卡在低功耗下空转空转也是成本和热量。5. 自建算力不是银弹反模式与边界5.1 哪些情况建议继续用云自建算力的坑不少我遇到最典型的反模式是业务还在验证期需求每天变模型换得很频繁这时候买硬件就是给自己上绑。因为你的场景、数据量、技术路线都没跑通硬件买错了只能贱卖而云上的灵活性可以帮你低成本试错。验证期的团队就老老实实用云把精力花在产品上。另一种情况是资源需求极度脉冲化。比如一年只做两次季度级的大规模数据清洗其他时间算力需求很小这种负载自建的闲置率太高不如去云上包几次竞价实例。或者项目周期很短三个月后可能就要转型自建资产的退出周期太长风险巨大。这些都是云更合适。运维能力不足的小团队也要谨慎自建。比如团队里没人有Linux和容器经验第一台服务器的驱动都装不明白我建议还是先用云托管的GPU实例等积累一两个懂行的人再慢慢过渡。硬件运维出事的时候不是花钱能立刻解决的没人会修会更痛苦。5.2 把自建算力当护城河的前提自建算力能构成护城河但它本身不是终点而是手段。护城河的本质是因为你有长期自建的算力储备所以你可以做别人做不了的事。比如你的模型迭代周期比别人短一半可以疯狂试错比如你的推理成本比对手低可以压低产品定价比如你能把客户私有数据留在本地可以做数据合规方案。所有这些的前提一是算力利用率真的高二是团队确实把基础设施沉淀成了工程能力三是有足够清晰的业务方向去消化算力。如果只是“别人都有卡我也要有”那护城河会变成成本沼泽。我见过一个团队买了大量卡结果没有稳定的训练任务最后只能拿去挖矿既折损显卡寿命也荒废了核心业务。所以自建的决策永远要绑定到具体业务上。一个做垂直模型微调的团队自建的价值在于模型每天都进步一个做AI Agent产品的团队自建的价值在于对延迟和并发调度的深度掌控。你要能说清楚“自建让我多做了什么”这笔硬件投入才值得。5.3 个人观点真正的护城河是“算力落地能力”做了这么多年AI基础设施我个人越来越觉得自建算力这个动作的背后真正拉开差距的是“让算力落地成产品”的能力。硬件谁都能买机房谁都能托管但能把集群调度、分布式训练、推理优化、成本控制串成一条完整流水线的团队才真正拥有壁垒。这就像买了最好的锅不代表能做出好菜菜谱和手艺才是关键。以前我们总觉得算法是护城河后来发现模型权重可以被开源社区快速复现又觉得数据是护城河但数据如果不流动不标注价值也很难发挥。现在长期做的自建算力会让团队沉淀出很多隐性知识哪一版驱动最稳、哪个节点该换散热、怎样调度能省电、哪些优化能让吞吐翻倍。这些东西没法从云上买回来只能在一次次的故障和调优中积累。未来两年算力可能会成为更多AI初创公司的标配资产。但标配是前提不是差异。真正让你跑赢同行的是你是否能用这部分资产持续产出又快又好的模型和服务。如果你能把自建算力变成工程体系的一部分那它才是护城河如果只是买一堆卡那它反而是最贵的装饰品。写在最后一点个人体会从云上迁到自建集群是我这几年在AI工程里做得最值得的决策之一但也是最折腾的一段经历。初期每次机器告警、每次网络抖动、每次看着GPU利用率提不上去都让我怀疑自己是不是花冤枉钱。后来逐渐把调度、监控、容灾、成本拆解做扎实看到账单直线下降、实验排队时间归零、客户因为数据不出域而愿意签约我才确定这条路走对了。如果你也在犹豫要不要自建我的建议是先花一个月把负载特征和成本账做透再动手买第一台机器。不要头脑发热买一堆卡也不要在业务稳定之后还一直当云大户。把算力的掌控权拿回自己手里哪怕最开始只拿回一部分那个感觉和纯粹租别人服务是完全不同的。希望这篇经验能帮你少踩几个坑也希望你的算力不只是一堆硬件而是真正驱动产品往前跑的引擎。