1. 算力竞赛最先撞上的不是芯片墙而是电力与散热墙这几年只要聊AI绕不开的话题就是算力。大模型规模一路膨胀从百亿参数冲到万亿参数GPU集群越建越大好像只要卡够多模型效果就能持续往上走。但真正在AI Infra这行干过的人都知道把一万张卡摆进机房里只是万里长征第一步。接下来要面对的问题一个比一个现实电从哪儿来热往哪儿排卡和卡之间怎么通信。这些问题不解决再贵的GPU也只能躺在机柜里当摆设。1.1 TOPS只是纸面算力真实吞吐才是“跑得动”的关键很多人选卡的第一参考指标是TOPS也就是每秒万亿次运算。打开各类“显卡AI算力TOPS排行”一眼能看出谁强谁弱选型似乎变得特别简单。但实际跑起来你会发现TOPS这个数字很有迷惑性。它是芯片在理想频率、理想温度、无通信开销下的峰值运算能力而真实场景里几乎不可能达到。我举一个最常见的例子跑大语言模型推理时决定生成速度的往往不是算得多快而是数据搬运得多快。模型权重要从显存里被反复读出来和输入计算。这时候显存带宽的重要性就压过了TOPS。两张标称算力差不多的卡A卡显存带宽大一截跑同一个7B模型的流式输出可能每秒钟多生成十几二十个token用户端的主观体验就是一个快一个慢差得很明显。所以现在越来越多做AI工程的人不再只看TOPS排名而是综合看四样东西显存容量能不能装下模型权重和KV Cache显存带宽决定了推理和训练时权重读取的上限卡间互联带宽多卡并行时通信是否成为瓶颈生态兼容性CUDA、ROCm或其他自研生态决定了你现有代码能不能直接跑。纸面算力决定的是“理论天花板”而这四项共同决定了“实际可用算力”。后者才是你在真实业务里真正能感受到的那个数字。1.2 电力与散热深水区的第一道硬约束你去看那些头部厂商发布的算力基础设施规划最醒目的往往不是GPU型号而是“XX吉瓦”这样的电力指标。为什么因为GPU实在太能吃电了。新一代训练卡的单卡功耗已经朝着700瓦以上走一个标准机柜塞进8张卡再加上CPU、内存、交换机和风扇整柜功耗能轻松超过50千瓦。传统数据中心是怎么建的呢过去一个机柜额定功率5到10千瓦就算高密了。整套配电、制冷设计都是基于这个前提的。现在突然翻了好几倍老机房根本接不住。就算接得住风冷的散热能力也逼近物理极限。热风排不出去芯片温度一高就降频降频就掉算力掉算力就意味着你花大价钱买来的GPU在“偷懒”。这就是为什么液冷从可选项变成了必选项。液冷比风冷的好处很明显散热效率高一个量级、噪音更低、还能回收余热做二次利用。但液冷也意味着机房改造、管线铺设、运维流程全要变。很多企业遇到的尴尬局面是卡已经下单了机房却还没准备好。要么排队等机柜要么花额外的钱做定制化改造。买得起卡进不了机房这不是段子是每天都在发生的事。电力对算力成本的冲击有多直接我用一个粗算来说明。一个规模还不错的算力集群假设总功耗10兆瓦一年电费开销就是电单价乘以总用电量。哪怕把PUE从1.5优化到1.3节省下来的电费在集群生命周期里也是一笔非常可观的数字。所以现在很多算力中心的选址逻辑已经从“靠近客户”变成了“靠近电厂、靠近便宜电”这也是为什么“算力 电力”会同时出现在热搜词里因为这俩本来就是绑定的。1.3 卡间网络的“通信墙”单卡性能再强跑大模型也得靠多卡并行。训练千亿参数模型动辄几百上千张卡一起干活这就牵扯到一个谁都无法回避的问题卡和卡之间怎么把数据高效地传来传去。业内有个比例大家都很熟悉大规模分布式训练里通信耗时经常能占到整个训练步长的30%到50%。也就是说你有一半的时间不是在算而是在等数据。如果卡间互联做不好一万张卡的集群实际效率可能还不如优化良好的两千卡集群。卡间互联的技术路线大致有三条英伟达的NVLink加InfiniBand是高性能标配性能和成本都在顶端RoCE走普通以太网成本低不少但调优更费劲还有各个自研芯片生态里的互联方案性能在追赶生态还在补课。做AI Infra的人必须理解你手头的集群用的是什么互联方案因为它直接决定了你的并行策略怎么写。举例来说如果你卡间走的是InfiniBand通信时延低、带宽高数据并行时梯度同步的压力就小可以更大胆地增加卡数。如果只有千兆以太网那你可能得把梯度压缩、通信和计算重叠、减少同步频率这些优化手段全部用上才能勉强维持一个能看的利用率。通信墙的可怕之处在于它不像算力那样有一个明确的指标可以衡量但它会慢慢侵蚀掉整集群的效率。1.4 “水账单”AI耗水问题开始浮出水面聊完电和热还有一个容易被忽视的隐形成本水。无论是风冷还是液冷散热系统都需要大量水资源。尤其液冷的环路里冷却介质要通过冷却塔把热量交换出去这个过程消耗的水量相当可观。数据中心密集的地区已经开始出现“算力挤占当地水电资源”的争议。别觉得这事儿离自己很远。如果你是自己买了几张卡在办公室跑实验水费根本感觉不到。但当算力规模化之后耗水就是和耗电一样重要的成本项和合规项。一些地方的算力中心审批已经开始把水资源消耗纳入考虑。这也是热搜词里“AI的水账单待解”背后的真实议题。以后做基础设施规划光盯着PUE还不够WUE水资源使用效率也会慢慢成为硬指标。2. 算力供给正在分层万卡集群、算力云与小型私有算力各有生存逻辑早几年大家聊算力默认指的就是自己买GPU自己搭集群。现在完全不一样了。整个算力市场已经分化成几个泾渭分明的赛道不同规模的玩家各取所需。你很难说哪种方式绝对更好关键看你的约束条件是什么。2.1 超大规模集群的规模红利与调度代价头部厂商为什么要烧钱建万卡级别的集群因为前沿模型的训练模式决定了他们需要。超大集群可以让训练任务在合理时间内完成迭代也能支撑更大规模的模型并行。这是一个纯粹的规模游戏模型越大需要的数据越多算力规模不上来训练周期就会长到失去商业意义。但万卡集群的管理难度是指数级上升的。几千块卡里每天总有一两块卡故障这几乎是例行公事。那么大的集群也必须依赖非常成熟的容错和断点续训机制否则一故障就得从头再来代价完全不可接受。调度系统这时候要处理的不只是“哪张卡能用”还包括故障隔离、任务迁移、数据副本位置复杂度和一个小型集群完全不是一个量级。还有一个容易被忽略的问题规模边际效应递减。卡越多通信开销越大单卡能发挥出的有效算力反而可能越低。业界常用的MFUModel FLOPs Utilization模型算力利用率指标就是衡量实际计算吞吐和理论峰值之间差距的。万卡集群的MFU如果能做到50%以上已经是非常优秀的水平了。剩下的一半就是为规模付出的代价。所以超大规模集群并不是越多越好它背后包含了大量工程调优的投入。2.2 算力云开发者“按需取用”的平权入口对绝大多数中小团队和个人开发者来说自己攒一个万卡集群完全不现实。但他们同样需要算力来做微调、做推理、跑Agent应用。算力云平台在这个需求点上精准切入。你在网页上注册个账号选一台带GPU的机器按小时付费几分钟就能开起来一个带完整环境的训练任务。用完关机不再产生额外成本。这类平台的价值在于它把算力这种重资产变成了一种类似水电的基础服务。你不需要关心硬件采购周期、故障维护、驱动升级只要关注自己的算法和代码。一个学生或者独立开发者花很少的钱就能跑起一个微调实验这在五年前是难以想象的。我之前带过一个小团队做垂直领域的问答模型整个微调周期就是用算力云完成的。最方便的一点是弹性白天做数据分析不训练的时候把实例停了省钱晚上集中跑训练任务多开几张卡并行动作早上起来看结果。这种“用时开、不用关”的模式让算力支出变成了一个精确可控的变量。2.3 小型私有算力数据合规与成本效率的折中不是所有企业都适合把数据放到云端。医疗数据、金融数据、核心研发数据这些敏感信息受合规约束出域管控非常严格。这些场景下小型私有算力反而是最合理的选择。我见过不少企业并没有买那种动辄上千卡的训练集群而是采购几台8卡或4卡的服务器部署在自有机房。配合开源模型这些资源已经可以覆盖大量实用场景私有知识库的RAG检索增强生成、垂直领域的模型微调、内部办公Copilot等。用几十万的硬件投入换来的是数据不出域的合规保障和长期稳定的推理能力。这就是热词里“算力集群”和“小型私有算力”共存的原因。它俩不是替代关系而是不同约束下的分头演化。大集群追求的是研发自动驾驶式的规模化效率小私有算力追求的是在边界条件内实现最高性价比。3. 算力调度系统从“能跑”到“跑满”的隐形主战场很多刚开始接触算力运维的人把注意力全放在硬件采购上觉得卡买回来、驱动装好、环境配好事情就完了。等真正跑起业务才发现GPU利用率低得吓人一半以上的算力都在闲着。这时候你才会意识到调度系统的价值甚至比硬件本身还大。3.1 调度到底在调度什么说直白一点调度系统做的就是把算力资源像电梯一样按楼层分配谁进、谁等、谁先上。但在实际工程里它要处理的维度非常复杂算力资源管理GPU显存多大、卡有多少、分布在哪些节点、当前是否空闲任务队列调度多个训练任务排队时按什么顺序执行优先级与抢占高优任务能不能插队低优任务执行到一半被抢占了怎么办弹性伸缩推理服务的负载波动时怎么自动增减实例故障容错某张卡挂掉了任务如何自动迁移。一个小型企业如果只是十几张卡可能用一个简单的任务排队脚本就够了。但到了上百张卡、多团队共用、7x24小时跑业务的状态没有一套清晰的调度策略资源浪费和团队争执就会同时爆发。3.2 调度策略背后的取舍逻辑调度策略没有绝对的“最优”只有“在你的业务约束下最合适”。拿最常见的两种策略来说FIFO简单公平先来后到实现成本极低。但如果来了一个紧急的线上修复任务它也得排在那个跑了十个小时的大训练任务后面业务上就接受不了了。这时候就要引入优先级调度高优任务可以插队甚至抢占资源。带来的副作用是被抢任务的状态保存、断点续跑这些都得配套实现。另一个真实的取舍是“碎片化”问题。GPU显存有大有小如果第一个任务申请了80GB显存第二个任务只有40GB而这块卡是80GB的那么剩下的40GB空闲就没法被利用。这些碎片的累积会让集群的实际可用资源比账面上少一截。解决思路包括引入显存分片、MIG或者将小任务调度到单卡剩余空间等。一定要记住一个原则GPU利用率的指标本身不是目的任务从提交到完成的时间周期、用户等待时长才是需要关注的最终指标。利用率很高但是排队时间极长说明调度可能把所有任务都塞进了队列里反而损害了用户体验。3.3 小团队也能落地的调度优化如果团队没有专职的SRE或平台工程师也不一定要把调度系统做得非常重。我见过很多小团队用一套很轻量的脚本配合任务锁就成功把GPU利用率从三成提到了七八成。核心做法并不复杂先装一套GPU监控把每块卡的温度、利用率、显存占用、功耗记录下来根据监控数据找到空闲时间段和碎片显存用简单的队列脚本把优先级高的小任务塞进碎片时段运行定期复盘看看哪些任务其实根本不需要那么大的显存重新分配。这里的核心不是技术复杂度而是“先量化再优化”。没有数据的时候你只能靠拍脑袋有了监控数据所有优化动作都会变得有据可依。这也是很多企业最容易忽略的第一步。4. 企业规划算力资源需要算清的几笔账从产业视角回到微观决策一个具体的团队到底要不要买卡买多少买完怎么用这些问题的答案远比“卡越多越好”这六个字复杂得多。4.1 采购成本之外的隐性账时间与机会成本先算一笔最简单的账。假设团队有预算一百万元两个选择摆在面前自建一台8卡服务器还是拿这笔钱在算力云上租一年。单纯从硬件单价看自建似乎更划算毕竟卡是实实在在的固定资产。但你得算持有关服务器折旧、机房机位费、电费、散热成本、运维值班人力、硬件故障维修。这些零碎成本加起来一年下来不是小数目。更关键的是时间成本。买卡到货可能要等几个月期间团队只能干等。而租算力当天就能开起来项目周期不延误。算力行业技术迭代极快今天买的卡可能两年后就不香了。租用模式的好处是你可以在不同代际的卡之间灵活切换始终用上合适的算力。从机会成本的角度来看那些所谓的“预算”如果不投在硬件上而是花在算法工程师、数据标注或者产品迭代上对很多公司来说回报可能更大。算力只是工具工具再好不会用或没时间用也是白搭。4.2 训练与推理必须分开决策训练和推理对算力资源的需求逻辑完全不一样。训练任务的特点是峰值明显、算力密集、时间相对集中。比如一个微调任务可能需要几十张卡跑三个小时跑完就释放。这种场景天然适合弹性资源租用算力云或者超算中心按需付费非常划算。如果为了几天一次的训练任务去自建一个大型集群大部分时间资源都是闲着的利用率上不来成本分摊不划算。推理任务的特点是长期稳定、对时延敏感、QPS每秒请求数相对固定。比如你上线了一个内部Copilot服务7x24小时要响应员工请求这种场景对资源的可靠性要求很高。跑在共享算力云上容易受邻居负载影响时延抖动明显。此时自建小型私有算力反而是优势资源可控、时延稳定、故障响应也快。所以比较合理的规划是训练靠弹性租用推理靠稳定自建或长期包月两边分开决策各取所长。4.3 用一张检查清单辅助决策遇到很多团队来问“我们要多少算力”我的回答几乎都是一个套路先跑通再扩容。下面这张检查清单是我自己筛选项目时常用的分享出来给大家参考决策问题自建/私有算力租用/算力云数据能否出域严格受控时选自建可以出域时优先租用使用频率长期7x24小时稳定运行按需、弹性、偶发高强度延迟敏感度高时延不能抖动中等可接受偶尔排队技术迭代速度慢需要长期稳定使用快希望保持代际更新初期投入预算充足可承担硬件采购紧张希望低成本启动这五个问题过完一遍大方向基本就清楚了。剩下的无非是调整数量和规格的细节问题。5. AI工程实践视角下未来两年值得关注的关键变量行业到了这个阶段单纯堆卡已经不再是新闻如何把已有的算力真正用好、如何让算力成本和业务价值匹配起来才是真正的护城河。5.1 电力约束将改写算力中心选址思路既然电力是硬约束那么未来算力中心的选址一定会越来越靠近能源富集区。风电、光伏、水电资源丰富的地区会天然成为算力基础设施的新集聚点。这不是猜测而是已经发生的趋势。绿电溢价虽然还存在但随着碳交易机制逐步完善绿色算力的成本优势会越来越明显。对于使用算力的企业来说这意味着未来算力服务的成本曲线会和能源价格深度绑定。在规划长期AI业务时除了关注GPU报价也要关注算力中心所在地的能源结构。那些能提供稳定、低成本绿电的算力服务商会在未来两年获得明显的竞争优势。5.2 “有效算力”会成为比TOPS更受关注的指标继续说回TOPS的问题。产业界对算力衡量的方式正在从“买了多少卡”转向“真正跑出了多少有效计算量”。MFU和训练吞吐这类指标会比芯片标称参数更频繁地出现在各种技术报告和采购文档里。这背后的原因是大家发现自己缺的不是纸面算力而是能真正用于业务的有效算力。采购决策时除了问“这张卡多少TFLOPS”更要问“在这个框架、这个模型、这个集群规模下实际能跑出多少MFU”。这个转变会给那些在互连、调度、框架优化方面做得扎实的团队带来机会。5.3 中小团队切入AI应用最现实的窗口期聊一点让开发者们比较振奋的变化。开源模型的成熟度这两年提升非常快很多7B、14B量级的开源模型在特定垂直任务上的能力已经追平甚至超过此前需要巨额算力才能训练的闭源模型。这直接拉低了中小团队做AI应用的门槛。过去做垂直场景的AI应用必须从零开始预训练一个大模型这事只有大厂和头部创业公司玩得起。现在完全不需要只需要在开源模型基础上用自己积累的场景数据做微调再配合RAG注入知识库就能做出效果很实用的应用。而微调和推理所需的算力通过像autodl这样的算力云平台就能低成本获得。这意味着当前是中小团队切入AI应用最明确的窗口期。这个阶段拼的不是谁的算力大而是谁更懂场景、更懂数据。算力变成了一种人人可得的工具差异化价值反而回归到了对业务本身的理解上。6. 写在最后从“抢算力”回到“用算力”我个人在AI基础设施这条线折腾了很多年最大的体会是算力从来不是目的而是手段。当整个行业还在为“谁的卡更多”较劲时那些真正做出价值的团队往往已经在思考另一个问题——如何让每一份算力都产生尽可能多的业务回报。如果你正在规划自己的算力方案我的建议很朴素先别急着下单买卡花一周时间把三个东西梳理清楚。第一你的业务到底需要什么量级的算力是训练、推理还是两者兼有第二你的数据约束和延迟约束是什么决定了能不能随意上云第三你的团队未来六到十二个月的实际使用节奏是一天跑满八个钟头还是偶尔冲一波峰值。把这三件事想清楚之后再去对比自建、租用、混合部署的性价比。你会发现很多“算力焦虑”其实并不存在只是因为缺少一个清晰的需求边界。打开autodl看看当前各类卡片的实时租金心里大概就有了盘算。算力竞赛的深水区拼的是精细化运营和工程落地能力。谁能在有限的算力里榨出更多的有效价值谁就能在这场长跑里走到最后。