前阵子帮一个朋友评估内部AI推理项目过程很有意思。算法选型、模型权重、推理框架都定好了显卡也到货了结果项目卡在了一个完全预料之外的环节——机房配电柜没有多余容量。当时的反应几乎一致“加个机柜不就行了”然后就被电力扩容的时间表教育了一轮。也就是从那次之后我越来越确定一件事AI竞赛真正的隐性边界可能不是买不到算力卡而是没有那么容易买到足够的电力。算力可以被运输可以被租赁可以被云化但电力是绑在物理位置上的。你可以把GPU从华南寄到华北可以把训练任务从一个云服务商迁到另一个但你不能把电网也一起搬过去。电力供应、配电容量、冷却条件、机柜功率这些才是真正决定一个AI项目能不能落地、能不能持续扩大的现实约束。这篇文章不打算写宏观能源政策也不想只做算力科普。我想从一个工程实践者的角度把“从算力到电力”这件事拆开为什么电力会变成瓶颈算力指标背后到底藏了哪些电气参数以及我们在规划AI项目时应该建立怎样的判断框架。1. 先理解“算力不够”和“电力不够”是两种完全不同的卡壳1.1 算力可以买电力只能等过去两年AI项目遇到最多的问题叫“算力不够”。算力不够的解决方案相对直接加卡、换卡、上云、申请更多配额。只要预算充足算力是可以从市场上买到的。GPU卡有固定型号云厂商有相应实例租赁平台也有按小时计费的服务。哪怕暂时缺货也总有一些渠道能拿到资源只是贵一点的问题。电力不够则完全不是同一个逻辑。电力不是一台设备也不是一个可以随时调货的商品。它背后涉及电网容量、变电站、变压器、配电柜、线路载流量、备用电源、冷却系统。任何一个环节不满足项目就无法运行。更关键的是电力扩容的周期通常以月甚至季度计很多时候还涉及物业、园区、电力公司多方协调。算力不够你可以换供应商电力不够换的是物理位置动的是基础设施。从工程经验看算力不够是“资源调度问题”电力不够更像是“基础设施建设问题”。前者可以通过技术手段和商务手段快速解决后者只能靠时间和投入慢慢等。这也是为什么很多AI项目在规划阶段没有把电力当回事结果到了部署阶段被卡住。1.2 一旦集群规模上来电表会比温度计先报警单张GPU卡工作时功耗问题不明显。插在普通台式机里甚至不一定需要专门处理散热。但只要机器密度上来情况迅速变化。一台通用GPU服务器单卡功耗常见在250W到700W之间具体型号差异很大。如果一台机器插满8张卡再加上CPU、内存、硬盘、网卡和风扇整机功耗轻松到数千瓦。到了机柜层面一个标准机柜如果放4到8台这样的服务器供电需求会迅速逼近甚至超过普通机房机柜的设计上限。很多团队踩过的坑是只按“单卡功耗×卡数”来估算总功率忽略了整机其他部件和散热带来的额外负载。结果设备进场一上电测试配电柜跳闸才知道预留功率根本不够。更麻烦的是高密度计算还会导致机房热点空调系统制冷能力不足设备降频甚至停机。这其实是一个很容易被忽视的规律当算力集群规模还小的时候瓶颈在软件、框架和模型当规模变大之后瓶颈会从计算设备逐渐转移到供电和散热。电表读数虽然不会像温度计那么敏感但它往往在更早的时候就定义了系统的上限。2. 算力指标背后藏着一张完整的电力账单2.1 GPU参数表里真正要关注的不只是TOPS和TFLOPS很多朋友选型时习惯先看FP16算力、FP32算力、显存容量关注TFLOPs越高越好。这当然没有错但在实际部署中还有一个同样关键的数字热设计功耗也就是TDP或TGP。这个参数决定了这块卡满载运行时的功耗上限也直接决定了你需要怎样的供电和散热条件。日常讨论中大家喜欢列“显卡TOPS算力表”“GPU算力排行”比来比去都是性能数字。但真实项目里一块卡的算力再高如果放进一台供电不足、散热不够的服务器里也只能降频运行实际吞吐可能还跑不过一块功耗更低但温度控制良好的卡。换句话说算力表只能告诉你上限电力系统才决定你能接近上限多少。这里可以给出一个简单判断选GPU型号时把“每瓦算力”当作一个核心指标。同一代产品每瓦算力更高的卡往往更适合大规模部署因为它意味着同样的电力预算能带来更多有效计算。不要只看绝对算力还要看达到这个算力需要消耗多少电。2.2 从一块卡到一个集群功率是怎么累加的要真正理解电力约束需要把功率从单卡推到集群。以一个常见的训练节点为例假设每张卡TDP在300W左右8卡节点光是GPU部分就是2400W。加上两颗CPU、多根内存、NVMe盘、高速网卡和风扇整机功耗很容易到3000W以上。如果机柜里放4台这样的服务器机柜总功耗可能超过12kW。这还不包括机柜内交换机、监控设备和其他辅助设备的功耗。如果是推理集群情况略有不同。推理负载通常不是7x24小时满载但突发流量峰值同样会拉高功耗。更麻烦的是推理集群一般按在线服务设计需要持续供电和稳定制冷不能随便停机。所以规划时不能只看平均功耗还要看峰值功耗。实际项目中建议这样估算系统总功率列出所有设备的满负载功耗包括GPU节点、CPU节点、存储节点、交换机、防火墙。把整机功耗累加并乘上一个冗余系数常见做法是预留15%到30%的余量。查看机房机柜可用供电规格确认是否满足。确认制冷系统能否带走对应热负荷特别是高密度区域。最后才是考虑UPS和备用电源容量。这个顺序可以避免很多部署阶段的意外。很多人习惯先看服务器性能、再问折扣最后才想起电力这时候往往已经晚了。2.3 别忽略PUE买来的电力并不都用在计算上数据中心行业有个指标叫PUE全称是Power Usage Effectiveness用来衡量总能耗中有多少真正用在IT设备上。PUE越接近1说明电力越高效PUE达到1.5意味着每消耗1度电给计算设备用还要额外消耗0.5度电在制冷、供配电等环节。PUE对AI项目的影响很直接。同样是100kW的IT负载PUE 1.5的数据中心实际总耗电是150kWPUE 2.0则是200kW。对长期运行的训练任务来说这个差距会显著影响电费成本。普通团队可能觉得PUE是数据中心建设者才需要关心的问题自己租用机柜或机房托管就行。但如果你租用的是共享机房同样需要问清楚机柜供电规格是多少PUE大概多少是否支持高密度风冷或液冷备用电源续航多长时间。这些答案决定你后续能放多少设备、付多少电费、能承受多久的市电中断。注意规划AI集群时把电力成本纳入预算不要把电费当成固定成本忽略掉。训练一个较大的模型电力消耗可能达到一笔不可忽略的支出。3. 电力约束正在反向影响AI技术选型3.1 为什么量化、蒸馏、MoE 不光是模型技巧也是省电策略过去我们谈模型优化更多是从精度和速度角度考虑。但在电力约束下一些技术开始获得新的价值维度。模型量化可以把权重从FP16降到INT8甚至更低显存占用减少推理速度提升同时单位请求的能耗也会下降。模型蒸馏用一个小模型去模拟大模型的行为虽然需要先用大模型生成训练数据但部署阶段的成本会大幅降低。混合专家模型通过路由机制只激活部分参数同样能减少每token的计算量从而降低单次请求功耗。这些技术通常被归结为“推理优化”但从另一个角度看它们都是“省电策略”。尤其是当供电容量固定时同样的电力预算优化后的模型可以服务更多请求或者在同样的吞吐下留出更多功率余量。所以在AI应用开发和AI模型部署阶段除了关心延迟和精度之外建议把“单位请求功耗”或“单位Token能耗”也纳入评估指标。这不是锦上添花而是在电力受限场景下的硬性需求。3.2 自建还是调用API先算一笔电力账很多团队会纠结模型部署到底应该自建GPU集群还是直接调用云厂商大模型API。除了稳定性和数据合规因素外电力成本也可以作为决策参考。如果使用API你不需要关心电力因为电费已经折算在接口价格里而且云厂商通常有更大的规模和更高的能效。对于起步阶段、请求量不太稳定的项目API几乎是零门槛方案。一旦自建集群即使机器不跑任务机房基础设施、电力增容、设备折旧都在持续产生成本。如果请求量稳定且足够大自建可能更划算但前提是你把电力成本算清楚。比如集群满负载运行多少小时机房单度电价是多少制冷消耗是多少是否需要用更高功率机柜是否需要额外扩容配电。判断自建是否合适不只是对比GPU采购价格和API单价还要对比“可用电量”和“总拥有成本”。很多项目自建后才发现电费比预想的高是因为没有把PUE和闲置功耗算进去。3.3 AI应用开发中新增的“功耗预算”思维对普通应用开发者来说功耗预算也许听起来很远但实际已经开始影响开发方式。移动端AI、边缘设备、机器人、无人机等场景芯片功率和电池容量都是硬约束。你不能为了更高精度而选择一个功耗巨大的模型否则设备发热、续航下降、稳定性变差。于是AI工程实践中出现了很多和“资源预算”相关的设计在端侧跑小模型把复杂任务交给云端对输入数据做预处理减少模型计算量动态调整推理频率而不是每帧都跑模型用缓存机制避免重复计算。这些做法本质上都是在“用电量”和“任务质量”之间做平衡。过去我们习惯把算力当作无限资源AI应用开发也倾向于堆数据、堆模型、堆参数但在真实系统里电力从来不是无限的。谁先学会在功耗预算内做AI谁就更容易落地到真实场景。4. 评估一个算力项目先按这个顺序排查4.1 建议的排查链路从电柜到卡实际项目中判断一个算力方案能否落地建议不要先看显卡跑分而是按下面的链路排查看可用电力配额机房或场地能提供多大功率是否有富余是否需要扩容。看机柜空间和散热能力每个机柜能放多少台设备制冷是否支持高密度负载。估算整系统峰值功耗把所有设备的满负载功耗相加乘上冗余系数对照可用配额。评估长时间负载稳定性训练任务可能连续数周满载散热和供电系统能否持续稳定。最后再看算力性能在供电和散热约束内选择最合适的GPU型号和节点配置而不是盲目选最贵的卡。把顺序反过来恰恰是很多项目踩坑的原因先选定型号再计算算力最后到了部署才发现供电不够。算力产品再强物理条件不允许一切还是零。4.2 一个可复用的算力部署前检查表这里整理一个适合大多数自建或托管场景的检查表可以在项目启动之前先过一遍检查项说明建议场地供电总容量配电柜、变压器可提供的总功率留足余量不要满打满算机柜供电规格单机柜最大功率限制根据设备功耗选高密机柜或液冷机柜服务器整机功耗不只算GPU卡还要算整机其他部件查阅厂商规格或实测满载功耗散热方式风冷、液冷、精密空调高密度区域建议液冷或针对性空调送风PUE水平基础设施总能耗和IT能耗比PUE越低长期电费越可控冗余供电UPS、备用发电机组决定意外断电时能否平稳过渡峰值负载测试满载运行验证供电和制冷先跑24小时再上线扩容空间之后增加设备是否还有余量提前留出机位、电力和散热余裕表格看起来简单但很多项目就是栽在其中一两项上。最典型的是“理论功率足够”和“实际可用功率不同”机房合同写着的10kW机柜实际到末端可用可能只有8kW因为线路损耗、插座限流等因素都要考虑。4.3 三个最容易踩坑的环节第一个坑是只看单卡功耗。GPU TDP是单卡数字整机还有CPU、内存、网卡、风扇温度高了风扇提速还会额外增加功耗。所以在评估一台服务器时尽量直接查厂商公开的系统整机最大功耗而不是自己从单卡简单推算。第二个坑是低估制冷系统的影响。高密度GPU节点发热量非常大普通机房精密空调可能压不住热点。如果机柜排列不科学热空气循环不畅哪怕总制冷量够某个区域还是可能温度过高导致设备降频。这个问题的排查成本很高因为它不是简单的功率计算还涉及气流组织。第三个坑是忽略电力扩容周期。很多项目在规划时没有把电力扩容的审批和施工时间算进去导致设备到了但机房接不了。更麻烦的是一旦扩容由园区或供电部门负责进度不一定可控。所以项目排期里一定要把电力准备时间提前而不是等设备进场再考虑。注意如果场地条件不满足又确实需要短时间内上线AI服务最稳妥的办法是用云服务或托管在专业AI数据中心而不是强行改造当前机房。5. 从算力到电力AI竞赛正在变成系统效率竞赛5.1 单位Token能耗将成为新的性能指标过去我们评价一个模型主要看参数量、评测分数、生成质量。但AI大规模落地后能耗指标会越来越重要。就像传统软件工程会关注CPU和内存占用一样AI工程实践也会越来越关注单位Token或单位任务消耗的电力。这不是兴趣问题而是成本问题。如果两个模型输出质量接近一个每百万Token需要多消耗一倍电力那么在长时间、大规模运行下电力成本差异会直接体现在账本上。尤其是一些需要高并发、低延迟的在线服务能耗决定了毛利率。未来评估AI系统时应该把“能耗效率”和“算力效率”放在一起看。只追求模型精度不考虑电力成本在实验阶段可以接受但在生产系统中很难长期维持。5.2 地理套利能源便宜的地方会吸引更多算力电力约束还有一个有意思的影响算力资源会主动向电价更低、可再生能源更丰富的地区流动。一些大型数据中心建在水电资源丰富、气候凉爽的地区并不是偶然。低温环境能减少散热成本水电价格低能降低长期运营成本。对中小团队来说如果自建机房可以考虑电价和气候因素如果使用云服务不同数据中心区域的定价差异也可能反映当地电力成本。这其实是一种“地理套利”同样一颗GPU在不同电力成本的地方运行一年的总成本差距可能很大。尤其当训练任务时间以周为单位时电费差异会更明显。反过来这也解释了为什么电力充足、电价稳定、气候适宜的地区会更容易聚集AI基础设施。5.3 对技术人的启示把电力当做一个工程设计变量回到开头的故事。那次部署最后没有选择扩容机房而是把一部分推理任务切到了云端API本地集群只保留对延迟敏感的核心任务。模型本身没有改动但系统整体从“全部自建”变成了“混合架构”问题就解决了。这个过程中的关键转变是把电力从一个“没想到的坑”变成了一个“必须考虑的工程设计变量”。一旦开始这样思考很多决策会变得清晰选服务器时会主动问整机功耗和尺寸而不是只看卡的数量设计部署架构时会考虑哪些负载必须放本地哪些可以外包到云做模型优化时会把推理成本颗粒度细化到单次请求做预算时会把电费和制冷费明确列项而不是甩进“其他”。AI竞赛从算力到电力的转变本质上是在提醒我们任何技术系统的规模极限往往都是由最基础、最不性感的物理条件定义的。算力可以靠钱买电力需要物理空间、时间、基础设施和长期规划。所以下次听到某个AI项目很宏大、GPU很多时我可能会下意识追问一句电从哪来散热怎么解决机柜能撑多久这些问题听起来不那么酷但往往才是决定项目能不能长期跑下去的真正变量。
前阵子帮一个朋友评估内部AI推理项目过程很有意思。算法选型、模型权重、推理框架都定好了显卡也到货了结果项目卡在了一个完全预料之外的环节——机房配电柜没有多余容量。当时的反应几乎一致“加个机柜不就行了”然后就被电力扩容的时间表教育了一轮。也就是从那次之后我越来越确定一件事AI竞赛真正的隐性边界可能不是买不到算力卡而是没有那么容易买到足够的电力。算力可以被运输可以被租赁可以被云化但电力是绑在物理位置上的。你可以把GPU从华南寄到华北可以把训练任务从一个云服务商迁到另一个但你不能把电网也一起搬过去。电力供应、配电容量、冷却条件、机柜功率这些才是真正决定一个AI项目能不能落地、能不能持续扩大的现实约束。这篇文章不打算写宏观能源政策也不想只做算力科普。我想从一个工程实践者的角度把“从算力到电力”这件事拆开为什么电力会变成瓶颈算力指标背后到底藏了哪些电气参数以及我们在规划AI项目时应该建立怎样的判断框架。1. 先理解“算力不够”和“电力不够”是两种完全不同的卡壳1.1 算力可以买电力只能等过去两年AI项目遇到最多的问题叫“算力不够”。算力不够的解决方案相对直接加卡、换卡、上云、申请更多配额。只要预算充足算力是可以从市场上买到的。GPU卡有固定型号云厂商有相应实例租赁平台也有按小时计费的服务。哪怕暂时缺货也总有一些渠道能拿到资源只是贵一点的问题。电力不够则完全不是同一个逻辑。电力不是一台设备也不是一个可以随时调货的商品。它背后涉及电网容量、变电站、变压器、配电柜、线路载流量、备用电源、冷却系统。任何一个环节不满足项目就无法运行。更关键的是电力扩容的周期通常以月甚至季度计很多时候还涉及物业、园区、电力公司多方协调。算力不够你可以换供应商电力不够换的是物理位置动的是基础设施。从工程经验看算力不够是“资源调度问题”电力不够更像是“基础设施建设问题”。前者可以通过技术手段和商务手段快速解决后者只能靠时间和投入慢慢等。这也是为什么很多AI项目在规划阶段没有把电力当回事结果到了部署阶段被卡住。1.2 一旦集群规模上来电表会比温度计先报警单张GPU卡工作时功耗问题不明显。插在普通台式机里甚至不一定需要专门处理散热。但只要机器密度上来情况迅速变化。一台通用GPU服务器单卡功耗常见在250W到700W之间具体型号差异很大。如果一台机器插满8张卡再加上CPU、内存、硬盘、网卡和风扇整机功耗轻松到数千瓦。到了机柜层面一个标准机柜如果放4到8台这样的服务器供电需求会迅速逼近甚至超过普通机房机柜的设计上限。很多团队踩过的坑是只按“单卡功耗×卡数”来估算总功率忽略了整机其他部件和散热带来的额外负载。结果设备进场一上电测试配电柜跳闸才知道预留功率根本不够。更麻烦的是高密度计算还会导致机房热点空调系统制冷能力不足设备降频甚至停机。这其实是一个很容易被忽视的规律当算力集群规模还小的时候瓶颈在软件、框架和模型当规模变大之后瓶颈会从计算设备逐渐转移到供电和散热。电表读数虽然不会像温度计那么敏感但它往往在更早的时候就定义了系统的上限。2. 算力指标背后藏着一张完整的电力账单2.1 GPU参数表里真正要关注的不只是TOPS和TFLOPS很多朋友选型时习惯先看FP16算力、FP32算力、显存容量关注TFLOPs越高越好。这当然没有错但在实际部署中还有一个同样关键的数字热设计功耗也就是TDP或TGP。这个参数决定了这块卡满载运行时的功耗上限也直接决定了你需要怎样的供电和散热条件。日常讨论中大家喜欢列“显卡TOPS算力表”“GPU算力排行”比来比去都是性能数字。但真实项目里一块卡的算力再高如果放进一台供电不足、散热不够的服务器里也只能降频运行实际吞吐可能还跑不过一块功耗更低但温度控制良好的卡。换句话说算力表只能告诉你上限电力系统才决定你能接近上限多少。这里可以给出一个简单判断选GPU型号时把“每瓦算力”当作一个核心指标。同一代产品每瓦算力更高的卡往往更适合大规模部署因为它意味着同样的电力预算能带来更多有效计算。不要只看绝对算力还要看达到这个算力需要消耗多少电。2.2 从一块卡到一个集群功率是怎么累加的要真正理解电力约束需要把功率从单卡推到集群。以一个常见的训练节点为例假设每张卡TDP在300W左右8卡节点光是GPU部分就是2400W。加上两颗CPU、多根内存、NVMe盘、高速网卡和风扇整机功耗很容易到3000W以上。如果机柜里放4台这样的服务器机柜总功耗可能超过12kW。这还不包括机柜内交换机、监控设备和其他辅助设备的功耗。如果是推理集群情况略有不同。推理负载通常不是7x24小时满载但突发流量峰值同样会拉高功耗。更麻烦的是推理集群一般按在线服务设计需要持续供电和稳定制冷不能随便停机。所以规划时不能只看平均功耗还要看峰值功耗。实际项目中建议这样估算系统总功率列出所有设备的满负载功耗包括GPU节点、CPU节点、存储节点、交换机、防火墙。把整机功耗累加并乘上一个冗余系数常见做法是预留15%到30%的余量。查看机房机柜可用供电规格确认是否满足。确认制冷系统能否带走对应热负荷特别是高密度区域。最后才是考虑UPS和备用电源容量。这个顺序可以避免很多部署阶段的意外。很多人习惯先看服务器性能、再问折扣最后才想起电力这时候往往已经晚了。2.3 别忽略PUE买来的电力并不都用在计算上数据中心行业有个指标叫PUE全称是Power Usage Effectiveness用来衡量总能耗中有多少真正用在IT设备上。PUE越接近1说明电力越高效PUE达到1.5意味着每消耗1度电给计算设备用还要额外消耗0.5度电在制冷、供配电等环节。PUE对AI项目的影响很直接。同样是100kW的IT负载PUE 1.5的数据中心实际总耗电是150kWPUE 2.0则是200kW。对长期运行的训练任务来说这个差距会显著影响电费成本。普通团队可能觉得PUE是数据中心建设者才需要关心的问题自己租用机柜或机房托管就行。但如果你租用的是共享机房同样需要问清楚机柜供电规格是多少PUE大概多少是否支持高密度风冷或液冷备用电源续航多长时间。这些答案决定你后续能放多少设备、付多少电费、能承受多久的市电中断。注意规划AI集群时把电力成本纳入预算不要把电费当成固定成本忽略掉。训练一个较大的模型电力消耗可能达到一笔不可忽略的支出。3. 电力约束正在反向影响AI技术选型3.1 为什么量化、蒸馏、MoE 不光是模型技巧也是省电策略过去我们谈模型优化更多是从精度和速度角度考虑。但在电力约束下一些技术开始获得新的价值维度。模型量化可以把权重从FP16降到INT8甚至更低显存占用减少推理速度提升同时单位请求的能耗也会下降。模型蒸馏用一个小模型去模拟大模型的行为虽然需要先用大模型生成训练数据但部署阶段的成本会大幅降低。混合专家模型通过路由机制只激活部分参数同样能减少每token的计算量从而降低单次请求功耗。这些技术通常被归结为“推理优化”但从另一个角度看它们都是“省电策略”。尤其是当供电容量固定时同样的电力预算优化后的模型可以服务更多请求或者在同样的吞吐下留出更多功率余量。所以在AI应用开发和AI模型部署阶段除了关心延迟和精度之外建议把“单位请求功耗”或“单位Token能耗”也纳入评估指标。这不是锦上添花而是在电力受限场景下的硬性需求。3.2 自建还是调用API先算一笔电力账很多团队会纠结模型部署到底应该自建GPU集群还是直接调用云厂商大模型API。除了稳定性和数据合规因素外电力成本也可以作为决策参考。如果使用API你不需要关心电力因为电费已经折算在接口价格里而且云厂商通常有更大的规模和更高的能效。对于起步阶段、请求量不太稳定的项目API几乎是零门槛方案。一旦自建集群即使机器不跑任务机房基础设施、电力增容、设备折旧都在持续产生成本。如果请求量稳定且足够大自建可能更划算但前提是你把电力成本算清楚。比如集群满负载运行多少小时机房单度电价是多少制冷消耗是多少是否需要用更高功率机柜是否需要额外扩容配电。判断自建是否合适不只是对比GPU采购价格和API单价还要对比“可用电量”和“总拥有成本”。很多项目自建后才发现电费比预想的高是因为没有把PUE和闲置功耗算进去。3.3 AI应用开发中新增的“功耗预算”思维对普通应用开发者来说功耗预算也许听起来很远但实际已经开始影响开发方式。移动端AI、边缘设备、机器人、无人机等场景芯片功率和电池容量都是硬约束。你不能为了更高精度而选择一个功耗巨大的模型否则设备发热、续航下降、稳定性变差。于是AI工程实践中出现了很多和“资源预算”相关的设计在端侧跑小模型把复杂任务交给云端对输入数据做预处理减少模型计算量动态调整推理频率而不是每帧都跑模型用缓存机制避免重复计算。这些做法本质上都是在“用电量”和“任务质量”之间做平衡。过去我们习惯把算力当作无限资源AI应用开发也倾向于堆数据、堆模型、堆参数但在真实系统里电力从来不是无限的。谁先学会在功耗预算内做AI谁就更容易落地到真实场景。4. 评估一个算力项目先按这个顺序排查4.1 建议的排查链路从电柜到卡实际项目中判断一个算力方案能否落地建议不要先看显卡跑分而是按下面的链路排查看可用电力配额机房或场地能提供多大功率是否有富余是否需要扩容。看机柜空间和散热能力每个机柜能放多少台设备制冷是否支持高密度负载。估算整系统峰值功耗把所有设备的满负载功耗相加乘上冗余系数对照可用配额。评估长时间负载稳定性训练任务可能连续数周满载散热和供电系统能否持续稳定。最后再看算力性能在供电和散热约束内选择最合适的GPU型号和节点配置而不是盲目选最贵的卡。把顺序反过来恰恰是很多项目踩坑的原因先选定型号再计算算力最后到了部署才发现供电不够。算力产品再强物理条件不允许一切还是零。4.2 一个可复用的算力部署前检查表这里整理一个适合大多数自建或托管场景的检查表可以在项目启动之前先过一遍检查项说明建议场地供电总容量配电柜、变压器可提供的总功率留足余量不要满打满算机柜供电规格单机柜最大功率限制根据设备功耗选高密机柜或液冷机柜服务器整机功耗不只算GPU卡还要算整机其他部件查阅厂商规格或实测满载功耗散热方式风冷、液冷、精密空调高密度区域建议液冷或针对性空调送风PUE水平基础设施总能耗和IT能耗比PUE越低长期电费越可控冗余供电UPS、备用发电机组决定意外断电时能否平稳过渡峰值负载测试满载运行验证供电和制冷先跑24小时再上线扩容空间之后增加设备是否还有余量提前留出机位、电力和散热余裕表格看起来简单但很多项目就是栽在其中一两项上。最典型的是“理论功率足够”和“实际可用功率不同”机房合同写着的10kW机柜实际到末端可用可能只有8kW因为线路损耗、插座限流等因素都要考虑。4.3 三个最容易踩坑的环节第一个坑是只看单卡功耗。GPU TDP是单卡数字整机还有CPU、内存、网卡、风扇温度高了风扇提速还会额外增加功耗。所以在评估一台服务器时尽量直接查厂商公开的系统整机最大功耗而不是自己从单卡简单推算。第二个坑是低估制冷系统的影响。高密度GPU节点发热量非常大普通机房精密空调可能压不住热点。如果机柜排列不科学热空气循环不畅哪怕总制冷量够某个区域还是可能温度过高导致设备降频。这个问题的排查成本很高因为它不是简单的功率计算还涉及气流组织。第三个坑是忽略电力扩容周期。很多项目在规划时没有把电力扩容的审批和施工时间算进去导致设备到了但机房接不了。更麻烦的是一旦扩容由园区或供电部门负责进度不一定可控。所以项目排期里一定要把电力准备时间提前而不是等设备进场再考虑。注意如果场地条件不满足又确实需要短时间内上线AI服务最稳妥的办法是用云服务或托管在专业AI数据中心而不是强行改造当前机房。5. 从算力到电力AI竞赛正在变成系统效率竞赛5.1 单位Token能耗将成为新的性能指标过去我们评价一个模型主要看参数量、评测分数、生成质量。但AI大规模落地后能耗指标会越来越重要。就像传统软件工程会关注CPU和内存占用一样AI工程实践也会越来越关注单位Token或单位任务消耗的电力。这不是兴趣问题而是成本问题。如果两个模型输出质量接近一个每百万Token需要多消耗一倍电力那么在长时间、大规模运行下电力成本差异会直接体现在账本上。尤其是一些需要高并发、低延迟的在线服务能耗决定了毛利率。未来评估AI系统时应该把“能耗效率”和“算力效率”放在一起看。只追求模型精度不考虑电力成本在实验阶段可以接受但在生产系统中很难长期维持。5.2 地理套利能源便宜的地方会吸引更多算力电力约束还有一个有意思的影响算力资源会主动向电价更低、可再生能源更丰富的地区流动。一些大型数据中心建在水电资源丰富、气候凉爽的地区并不是偶然。低温环境能减少散热成本水电价格低能降低长期运营成本。对中小团队来说如果自建机房可以考虑电价和气候因素如果使用云服务不同数据中心区域的定价差异也可能反映当地电力成本。这其实是一种“地理套利”同样一颗GPU在不同电力成本的地方运行一年的总成本差距可能很大。尤其当训练任务时间以周为单位时电费差异会更明显。反过来这也解释了为什么电力充足、电价稳定、气候适宜的地区会更容易聚集AI基础设施。5.3 对技术人的启示把电力当做一个工程设计变量回到开头的故事。那次部署最后没有选择扩容机房而是把一部分推理任务切到了云端API本地集群只保留对延迟敏感的核心任务。模型本身没有改动但系统整体从“全部自建”变成了“混合架构”问题就解决了。这个过程中的关键转变是把电力从一个“没想到的坑”变成了一个“必须考虑的工程设计变量”。一旦开始这样思考很多决策会变得清晰选服务器时会主动问整机功耗和尺寸而不是只看卡的数量设计部署架构时会考虑哪些负载必须放本地哪些可以外包到云做模型优化时会把推理成本颗粒度细化到单次请求做预算时会把电费和制冷费明确列项而不是甩进“其他”。AI竞赛从算力到电力的转变本质上是在提醒我们任何技术系统的规模极限往往都是由最基础、最不性感的物理条件定义的。算力可以靠钱买电力需要物理空间、时间、基础设施和长期规划。所以下次听到某个AI项目很宏大、GPU很多时我可能会下意识追问一句电从哪来散热怎么解决机柜能撑多久这些问题听起来不那么酷但往往才是决定项目能不能长期跑下去的真正变量。
