深夜调一个推理服务，日志停在加载权重那一行。机器是租来的，卡不算旧，可它就是慢。这时候才会意识到，采购单上那串标称的算力，和屏幕上跳动的进度条，中间隔着一大堆别的东西。
峰值写在纸上，吞吐长在系统里
厂商给的数字，通常是在理想条件下测出来的：大矩阵、连续访存、没有别的东西抢资源。可真实业务不这样跑。请求有大有小，有长有短，中间还夹着调度、序列化和网络往返。决定体验的往往不是那串峰值，而是内存带宽够不够、卡间互联快不快、批处理拼得好不好。
同样一批机器，换个推理框架、调一下批大小，吞吐可能差出一截。这部分差距不是买来的，是磨合出来的。
排队的十分钟，也算在成本里
很多团队碰到的麻烦不是没有机器，而是机器在忙别的。任务提交上去，排队等资源，等的时间比跑的时间还长。这时真正的瓶颈是调度策略：谁能插队，谁必须让路，长任务怎么不被短任务饿死。
只看总量，容易误以为资源充足；按队列去看，才发现某些时段、某些卡型永远紧张。「利用率」这个词因此变得微妙——平均值好看的集群，也可能让某个业务干等半小时。
- 提交到开始运行之间的等待，很难被传统监控捕捉；
- 忙闲不均往往集中在少数时段，扩容解决不了全天。
电和热，绕不开的物理层
机柜的功率上限、机房的散热能力，甚至楼层承重，都会在某个点上变成硬约束。加卡不是插上就能用，供电和制冷跟不上，多出来的那部分算力只能闲置在那里。这也是为什么有些团队愿意把批量任务挪到别处，把靠近用户的推理留在本地。
不是所有问题都该往里堆
有些需求其实不需要更大的模型。把模型做小、把高频请求的结果缓存住、把一部分推理放到端侧，往往比申请更多资源见效更快。反过来，也确实有任务只能靠规模解决，那就老老实实排队、扩容、把成本算清楚。
区分这两类需求，比笼统地喊「资源不够」有用得多。前者考验工程判断，后者考验预算决心，混在一起谈，讨论就会失焦。
回到那个深夜。真正让人焦虑的从来不是数字不够大，而是不知道慢在哪里。把链路拆开，逐段量一遍耗时，很多问题会自己浮出来；剩下那些确实要加机器的部分，才值得拿去谈预算。