推开数据中心那扇门，冷通道里是凉的，走到机柜背面，热风直接扑到脸上。做过运维的人对这种温差有生理记忆：前半截是设备在干活，后半截是钱在往外走。讨论算力的时候，人们习惯盯着芯片型号和参数表，可真正决定一套系统能干多少活的，往往就藏在这阵风里——电、散热、网络、调度，缺一样都跑不顺。
一度电能换来什么，取决于你在哪儿等
同一批机器，放在电价低、气候冷的地方，和放在夏天漫长、寸土寸金的城区，账目完全不是一回事。制冷从来不是配角。风冷能撑住的功率密度有上限，再往上走就得换液冷，而液冷意味着机房的管路、承重、运维流程都得重做。很多项目在预算表上只写了设备，没写这些改造，落地时才发现超支的部分不在芯片上。
网络也是同一类问题。一批机器连成集群，卡与卡之间的通信跟不上，整体吞吐就被拖住。这时候继续加机器，效果并不线性。采购单上写着规模，实际跑起来是另一回事。
利用率是个不太好听的词
硬件买回来、上架、点亮，指标很好看。但一天里真正满载的时间有多少？不少集群的忙碌时段集中在任务排队的那几个小时，其余时间在等数据、等调度、等人写代码。设备折旧照常走，电费照常交。
所以有些团队开始把注意力从“要不要再买”转到“现有的够不够用”。调度策略改一改，训练和推理错峰，长任务和短任务混排，同一批机器能多挤出不少时间。这类工作不显眼，写进汇报里也不出彩，但对成本的改善是实打实的。
不是所有问题都该往算力上加
这句话在项目会上不太受欢迎，但确实常见。有的模型效果上不去，瓶颈在数据——样本重复、标注口径不一致、覆盖的场景不全。有的业务卡在流程上，跑得再快也没人接。这时候加机器，只是把排队时间缩短，方向本身没变。
边界大概就在这里：它能把“想得到但做不动”的事变可行，却没法让一个没想清楚的问题变清楚。判断方法也不复杂——先看现有资源是不是真的用满了，瓶颈在计算、在存储、还是在人。如果答案不在计算，钱花到别处更划算。
另一头：把一部分计算挪到数据旁边
推理和训练不一样。训练可以集中在一个大集群里慢慢跑，推理面对的却是随时到来的请求，延迟一高，体验就塌。把所有请求都送回中心机房，带宽和响应时间都是成本。于是有些场景开始把计算放在离数据近的地方——车间、门店、摄像头旁边的小盒子。
边缘设备的资源有限，反而逼着人把模型做小、做专。这不是退步，是取舍：大部分常规请求就地处理，只把拿不准的少量样本送回中心。整体上，中心的压力降了，响应也快了。
回到那阵热风
机柜背面的温度，其实是整套系统运行状态的外在表现。风很热，说明机器在忙；风只是温的，说明在空转。与其只问“够不够”，不如也问一句“用没用”。
一套系统的健康度，大概不看峰值能冲到多高，而看它闲着的时候在做什么。