月底对账，机房的电费单总让人停顿一下：机柜上架的数量没怎么变，电表却转得更快。运维说负载确实上来了，采购说合同里的规格一个字没改，财务只想知道钱花在哪。三拨人对着同一张表，说的其实是三件事。
买回来的是峰值，用掉的是碎片
选型的时候谈的都是峰值：能塞下多大的模型，能扛住多密的请求。真正跑起来，请求是零散的，白天一阵紧一阵松，夜里几乎空转。设备按最忙的那几个小时来配，账单却按整月结算，中间那段空档就成了说不清的成本。
这时候「算力」这个词显得有点含糊。它既可以指机房里装进去的容量，也可以指某一刻真正被用上的那一部分，两者之间常常差着不小的距离。采购看前者，运维盯后者，嘴上说的却是同一个词。
卡与卡之间，隔着带宽和等待
把任务拆到多张卡上，听起来是线性加速，实际常卡在搬运上。参数要在显存和计算单元之间来回走，卡与卡之间还要互相通报进度。通信一旦成为瓶颈，堆算力换来的收益会被迅速摊薄。单卡跑分好看，不等于整机跑得快。
另一头是排队。请求进来得先等调度，等显存腾出位置，等上一批算完。批处理开大一点，吞吐能上去，延迟也跟着涨；开小一点，响应好看了，设备又闲在那里。这类取舍没有统一答案，取决于业务能不能忍受多等那一小会儿。
加机器之前，先看看瓶颈在哪
遇到慢，第一反应往往是扩容。但慢的原因可能是模型本身太大、输入太长、缓存没做好，也可能是请求分布太偏。把模型压小、做量化、把长任务挪到夜里跑，这些手段不增加硬件，有时反倒能省下添几张卡的预算。
反过来也一样。有些任务确实吃算力，比如长上下文反复推理，或者需要大量并行试错的场景，这时候省下来的每一分容量都会立刻体现在等待时间上。判断的关键在于先弄清哪一段在拖后腿，而不只是回答「要不要加」。
所以那张电费单真正难解释的地方，不在数字本身，而在于它背后横着好几层工程：选型时的假设、调度里的取舍、模型与硬件的匹配程度。把这些拆开看，账单未必会变便宜，但至少能说清楚钱换回了什么。