机柜功率和总算力算完，瓶颈居然不在电

电够用，不代表机柜能塞满卡。电批下来了，机器也上架了，跑起来才发现排队、抖、慢、时不时卡一下——回头一算，机柜功率和总算力都对得上，电表也没超，可问题还是一堆。这种场面我见得不算少，卡住人的东西，十有八九跟电没关系。

机柜功率和总算力的账，算法不止一种

有人只算单柜标称多少 kW，有人只算买了多少张卡、单卡多少 TFLOPs，两个数字往一块一放，觉得齐活。中间那一层最容易被跳过：PUE 怎么摊、制冷冗余留多少、从配电柜到机柜这一段有没有损耗、UPS 效率打几折。这些口径各家不一样，有的按整机房年平均，有的按设计值，有的按实测峰值，同一套设备换个口径能差出一截余量来。所以别拿两个数直接相乘就拍板，先把口径问明白，具体还是以服务商或官方页面说明为准。

散热先撞墙，风冷的余量没想的多

功率一加上去，最先出状况的往往是温度，不是电表。风扇转速拉满、进风温度顶到上限、热点区域降频，性能就这么一点点被吃掉，你在监控上看到的只是曲线不够漂亮。风冷不是不能用，是过了某个密度之后很勉强，尤其机柜前后风道被线缆堵住的时候，标称能带多少和实际能带多少是两回事。液冷看着省事，也得看冷板覆盖到哪儿——有的方案只管着 GPU，内存、VRM、网卡还在吹风，那机柜里就依然是两套散热体系在打架，管路改造、快接头漏液风险、维护窗口都要提前想。不确定的型号参数，翻厂商手册或者让服务商给个实测口径更靠谱。

卡越多，越像网络瓶颈

单机八卡自己跑，效率看着挺美；一拉成集群，整体吞吐掉一截，这种事太常见。东西向流量才是大头，参数同步、梯度交换、模型分片，全在机柜之间来回窜。收敛比一收紧，链路一拥塞，卡就在那儿等着。等你把带宽堆上去，又会发现交换机端口数不够、光模块型号对不上、U 位被走线占掉、桥架塞不进新的一捆线。所以算力往上翻的时候，网络这块最好同步翻，别想着后补——后补的成本通常比一开始就规划高。

存储和内存带宽，这道墙藏得比较深

训练这活儿不是一直在算。大量时间花在读数据、等加载、写 checkpoint 上。存储 IOPS 跟不上，卡就空转；内存带宽不够，模型加载慢得像老牛拉车；再往下还有单机内部的总线带宽，卡和卡之间那点通道能不能喂饱，也是账。这些指标平时没人盯着，出问题的时候又特别像“机器坏了”，排查起来绕远路。上架之前拿真实的数据集跑一遍端到端，比对着参数表推演靠谱得多。

账面上有卡，实际在排队

还有一个更软性的瓶颈：调度。卡型混着买、碎片化占着大卡跑小任务、队列里堆着一堆等资源的作业，账面上的算力很漂亮，能立刻用上的没那么多。利用率这东西，比总峰值更能说明问题。看监控的时候别只看峰值，看一天里卡真正在干活的时长，那个数字往往更扎心。

机柜功率和总算力之外，承重和工期也别漏

机房那边还有几本账跟功率平行：楼板承重够不够、层高能不能走新桥架、消防和漏水检测要不要改、改造期间停机窗口有多长。这些东西跟算力一点不沾边，可它们卡住项目的概率一点不低。尤其是老机房上高密机柜，承重和散热常常是一起被顶到墙上的，先做现场勘察再谈配置，顺序别反。

落到你租的那台机器上，这些账有什么意义

云上买实例，宣传页上那个算力数字，多半是在理想条件下测出来的。你得往下看几行：CPU 是不是共享的、有没有超分、内网带宽给到多少、云盘是哪种类型、IOPS 上限多少、是不是独享资源。同一档配置换个存储类型，跑分能差出一截。做站的人感受更直接——数据库慢查询多、图片加载磨蹭，很多时候不是算力不够，是磁盘和网络那头在排队。挑机器的时候把这几项摊开对比，比只盯价格实在。

临走给个能直接照着问的清单：单柜实际可用功率按什么口径算、制冷方式跟你的密度匹不匹配、内网带宽和收敛比写没写进说明、存储 IOPS 有没有上限、资源是独享还是共享、承重和改造工期谁负责。这六条问清楚，比在纸面上把机柜功率和总算力乘来乘去强。电是门槛，过了门槛之后真正的仗在别处打。