夜里巡机房，最显眼的常常不是闪烁的指示灯，而是机柜门上的温度贴。新机器上架前，讨论总集中在芯片型号和单卡性能；真正跑起来，先撞上的却是供电、散热、网络和调度。这个落差，正是今天谈算力时最容易被略过的一段。
先把机柜看明白
一张加速卡能放进机柜，不等于它能长期跑满。高密度设备把电流和热量一起推高，配电容量、制冷余量、线缆走向都会变成约束。很多扩容计划卡在这里：不是买不到设备，而是机房没有足够空间和电力把它们稳定地养起来。于是，算力的第一层现实不是峰值数字，而是可持续运行的机柜环境。
跑满和跑好不是一回事
设备通电后，利用率才开始说话。任务排队、数据读取、卡间通信、内存带宽，任何一环慢下来，整块加速卡都可能空转。训练任务怕等待，推理任务怕抖动；前者关心集群吞吐，后者关心尾延迟。把这些差异混成一个笼统的容量指标，很容易得到看似充裕、实际难用的结果。有效算力，往往藏在调度策略和任务形态的匹配里。
软件也在决定路好不好走
同一套硬件，换一种编译方式、算子实现或批处理策略，表现可能明显不同。算子融合减少来回搬运，量化压缩降低内存压力，调度器把相似任务放在一起，都是在把硬件的路修平。反过来，框架版本不匹配、驱动层不稳定，也会让昂贵的设备频繁闲置。谈扩容之前，先看软件栈是否跟得上，常常比追加设备更实际。
并非所有任务都该挤进大集群
有些任务对时延敏感，数据也不适合离开本地，放在边缘侧的小型设备上反而省事；有些任务可以容忍排队，适合集中起来错峰运行。把两者都塞进同一个池子，管理复杂度会上升，利用率却未必改善。边界划清楚，集群做它擅长的大吞吐任务，边缘承接即时响应，整体体验会更稳。
评估时多看几个笨问题
机柜还能加多少功率？网络会不会先堵？任务平均排队多久？失败重跑占多少时间？软件升级谁来兜底？这些问题不新，却比一张漂亮的峰值表更能说明问题。算力真正稀缺的地方，往往不是纸面峰值，而是从设备上架到业务稳定运行之间的那段工程能力。