深夜提交一个训练任务，第二天早上打开屏幕，进度条还停在原地。日志里没有报错，只有一行排队等待的提示。人困了可以睡，机器不会累，可任务就是没往前走。
这种时刻容易让人产生一种错觉：问题出在算力不够。再多一些卡，多租一点机器，是不是就顺畅了？现实往往没这么简单。
一条流水线上，慢的那一段决定节奏
算力常被当作一个可以计数的东西——多少张加速卡、多少浮点运算。这个数字直观，好写进采购单，也好写进汇报。但真跑起任务来，决定快慢的环节远比这个数字多。
数据从存储搬到内存、再搬到显存，中间任何一段带宽吃紧，加速卡就会空转；一批任务的批次大小设得不合适，显存占满了，计算单元却在原地等；几个任务混跑，调度策略粗糙，就会出现有人排队、有人闲置的场面。这些细节不会出现在任何一个“总规模”的描述里，却实实在在决定了同样的硬件一天能跑完多少活。
看算力，与其看容量，不如看流动。一条流水线上，慢的那一段决定整体节奏，快的那一段再多也补不回来。
等的人，也是成本
还有一个常被忽略的环节：人。
任务排队时，工程师并不能去干别的。他要盯着日志，要在任务失败后重跑，要在资源到手后抢时间调参。这些时间没有计入任何一张硬件账单，却是真实发生的支出。有些团队宁可多申请一倍资源，也要减少这种等待——不是因为能算得更多，而是因为人的节奏一旦被打断，很难接上。
于是出现一种矛盾：一边是资源闲置，一边是人在排队。中间隔着的往往不是硬件，而是调度规则、权限流程和任务粒度。把大任务切小、给不同优先级留出通道、让空闲资源能被回收再分配，这些琐碎的工程活，效果有时超出预期。
有些问题，不该交出去
也要承认另一面：并非所有慢都值得用资源去换。
有些需求其实一次规则判断或一个小模型就够，却因为“上大模型”听起来更先进，被塞进了昂贵的流程里；有些效果问题本质是数据脏、标注乱，加机器只会让错误跑得更快。判断一个任务该不该占用这些资源，需要的不是硬件知识，而是对业务本身的清醒。
回到那个排队的夜晚。真正该问的或许不是“还能不能再要一点”，而是这个任务非跑不可吗、能不能拆小、跑完之后有没有人用。这些问题不太好回答，也不太好写进报告，但它们比多几台机器更接近事情的本质。