夜里路过机房，先听到的是风扇，不是芯片。屏幕上跳动的利用率曲线看起来平静，真正让人停下来的，往往是电费、散热和任务排队叠在一起的那一刻。
谈算力时，容易先想到芯片。可在实际系统里，芯片只是起点。内存带宽决定数据能不能及时送到，网络决定多台机器能不能协同，存储决定等待会不会把计算单元晾在原地，调度则决定这些资源被切成碎片，还是被组织成可用的整体。
所以，算力更像一条被组织起来的生产线，而不是一个可以单独搬运的零件。看单点峰值，容易得到漂亮的数字；看持续吞吐，才会接近业务真正感受到的速度。这中间的差距，通常不来自某一个部件，而来自系统里那些不显眼的接缝。
先问任务，再问配置
评估算力，先回到任务本身。不同任务对资源的胃口并不一样：
- 推理服务关注单位时间能处理多少请求、延迟是否稳定；
- 训练任务关心迭代周期、检查点写入和故障恢复；
- 离线批处理则要看窗口期内能否跑完，以及闲时资源如何回收。
把这些混在一起谈，配置单就会变成一堆看似专业、实际难以对应的名词。一个常见误区，是把采购清单当成能力清单。机器到位，只说明资源存在；调度、监控、容错和权限治理跟上，资源才会变成可交付的能力。否则，空闲的卡和排队的任务可以同时存在，账面资源很多，业务侧却仍在等。
云与自建，不必先站队
云上资源灵活，适合需求波动明显、验证周期短的场景；自建环境可控，适合长期稳定、对数据位置和网络路径有要求的任务。两者并非简单的二选一。混合使用、按任务分层，往往能把争论拉回具体问题。关键在于把成本、时延、合规和运维负担放在同一张表里看，而不是只盯单价。
还有一个容易被忽略的环节：可观测性。没有细粒度监控，就不知道资源花在哪里；没有队列等待和失败重试的记录，就很难判断瓶颈在计算、网络还是存储。可观测性不是附属功能，它让算力从“买了多少”转向“用成了什么”。
对多数团队来说，务实的做法是先选一个真实任务做小规模压测，记录等待时间、资源空转和故障恢复过程，再决定扩容方式。这样得到的结论未必漂亮，却贴近日常运行。
机房里的风扇还会继续转。资源这件事，最终落在任务是否按时完成、资源是否被持续使用、故障是否可被及时发现这些朴素问题上。把这些边界看清，配置单上的词才有意义。