很多团队想上算力中心，第一反应是「先买卡」，结果机房电力不够、制冷压不住、机柜承重不达标，卡到了也开不了机。这篇不聊榜单，也不聊租还是买，而是给一套从需求到验收的决策框架：先算清楚你要跑什么、要多少持续功率、什么网络拓扑、什么节奏扩容，再去对卡型和场地。每一步都给判断标准和落地动作，附带什么情况下这套框架不适用。
很多团队一说要建算力中心，第一反应就是「先抢卡」，结果机柜到了才发现电力不够、制冷压不住、楼板承重不达标，卡堆在仓库里就是开不了机。这篇不讲榜单，也不争论租还是买，只给一套从需求到验收的决策顺序：先把要跑什么、要多大的持续功率、什么网络、什么扩容节奏理清楚，再去对卡型和场地。
这套框架的目标是让你少走冤枉路，代价是前期要多花几天做功课。判断标准始终是同一句话：任何一项硬约束不达标，就回头砍规模，而不是硬顶上去。先看需求，再看场地，最后才看设备。
先定需求，再定场地：从任务清单倒推算力画像
决策者最容易犯的错，是把训练、微调、推理混成一笔账。这三类负载的显存下限、互联敏感度、可容忍排队时间完全不同，画像必须分开列。训练像长跑，看的是能否连续稳定跑几周；推理像潮汐，看的是高峰并发能不能扛住。两套口径混用，算出来的规模一定偏。
| 负载类型 | 关键约束 | 能容忍的排队 | 扩张信号 |
|---|---|---|---|
| 训练 | 显存下限、卡间与节点间带宽 | 几乎不能忍，断点代价高 | 单批任务时长变长、排队积压 |
| 微调 | 显存下限为主，互联要求中等 | 可排队，但不宜跨天 | 任务完成时间拖到次日 |
| 推理 | 晚高峰并发、响应延迟 | 高峰期不能忍 | 高峰期错误率或延迟抬升 |
- 把业务拆成训练、微调、推理三类，逐条写清显存下限、是否需要高速互联、可容忍排队时长；
- 把「峰值需求」和「持续需求」分开记：训练按连续数周的功率算，推理按晚高峰并发算，散热与配电口径不同；
- 参数规模与显存的对应关系拿不准时，到 /tools/model-sizing 和 /gpu-specs 按模型与量化档位对一遍，别凭经验拍数；
- 什么情况下不适用：只做小规模微调或纯粹调用外部 API 的团队，自建本身就过度设计，这套框架会把简单问题复杂化。
电力、制冷、承重：先过场地这关再谈卡
场地的硬约束顺序是固定的：可用功率决定单柜能塞几张高功耗卡，制冷方式决定你能稳定跑在什么功率密度，承重和层高决定设备能不能进场。配电改造的周期往往比采购卡还长，所以电力这一步要最先启动，而不是等卡到了再补。
- 摸清单柜可用功率向机房要真实的单柜供电上限，按目标卡型的整机功耗反推每柜台数，确认是否需要增容；验证方式是让机房出具书面可供电容量。
- 确认制冷能力问清是风冷还是液冷、对应可承受的机柜密度，液冷还要问管路改造由谁负责；验证方式是拿到改造工期与责任方。
- 核对承重与层高整机与满配机柜重量要落在楼板承重范围内，机柜高度与走线空间也要留够；验证方式是进场前做一次现场勘测。
- 检查网络进线与消防上行带宽、可用路由、消防与合规要求往往最后才被想起来；验证方式是让网络与安全负责人签字确认。
电价与供电稳定性别漏算，它不属于设备采购，却直接决定长期开销。具体怎么折算进三年账，可以参考 /guides/tco-rent-vs-buy 里的口径，按当地当时的电价与负载曲线去对，不要套用一个想当然的系数。任何一项硬约束不达标，就回头砍规模，把节奏拉长。
卡型、组网与存储：按任务匹配而不是按名气匹配
选卡先看卡间互联带宽，多机再叠加节点间网络。训练任务对网络瓶颈极其敏感，一次通信拖慢会放大成整体效率下降；推理任务对互联相对宽松，把训练级组网套到推理上是浪费。判断标准是：这条链路的瓶颈会不会出现在你的主任务上。
| 维度 | 训练重点看 | 推理重点看 |
|---|---|---|
| 互联 | 卡间带宽、节点间网络拓扑 | 单机内即可，跨机需求低 |
| 存储 | 训练数据读取带宽、checkpoint 落盘速度 | 模型加载速度、缓存命中率 |
| 调度 | 长任务不被打断、断点续训 | 高峰并发弹性、快速上下线 |
- 存储分热、温、冷三层：训练数据读取、checkpoint 落盘、历史归档各占不同带宽，落盘慢会直接拖垮训练效率；
- 国产卡能不能用，看框架适配与算子覆盖范围，别只看参数表，到 /sites 和 /guides/cluster-options 对照实际可得性与方案差异；
- 推理集群可以把网络和存储降一档，把预算留给并发调度与冗余；
- 什么情况下不适用：任务小到单机就能覆盖时，多机组网和分层存储都是浪费，先把单机跑满再谈扩张。
扩容节奏与验收：分批上、按指标验、留退路
一次上满最容易踩坑，因为你还不知道真实业务链路在这套硬件上跑起来是什么样。建议按可验证的小批次扩容：每批先跑通一条真实业务链路，拿到稳定性与吞吐数据后，再决定下一批买不买。这样即使判断错了，损失也被限制在一个批次内。
- 验收不要只看「能开机」，要测持续满载稳定性、故障恢复时间、显存与吞吐是否符合预期；
- 把「几张卡够用」算清楚再下单，口径参考 /tools/model-sizing 按模型和量化档位推一遍；
- 提前想好退路：卡型换代、任务下线、业务量下滑时，算力怎么转租或转做推理；
- 写清运维责任：谁盯电力、谁盯散热、谁盯驱动与调度，出问题找谁；责任不清的算力中心稳定性一定差。
故障恢复时间是常被忽略的验收项，它决定了一次意外中断的真实代价。测试方式很简单：在受控条件下模拟一次节点掉线，记录从发现到业务恢复的时长，以及这段时间里 checkpoint 能否正常恢复。这个数字比任何宣传材料都更能说明集群是否可用。
常见问题
直接买卡自建，和租算力比，决策分界线在哪？
看利用率。如果任务能持续把卡跑在较高负载、周期以年计，自建有账可算；如果负载波动大、项目周期短、或者还在试方向，租卡更灵活。真正的分界线不是规模大小，而是「你能不能让这批卡长期不闲着」，闲置的卡比租贵的卡还贵。
没有机房经验的小团队，第一步该做什么？
先别碰采购。第一步是把自己的任务画像写清楚：跑什么模型、什么量化档位、要多长时间、能容忍多久排队。然后拿着这份画像去问三家以上供应商的场地与电力口径，同时用站内 算力从哪买：租卡、按量还是签合同 对比租与建的账。画像不清就谈方案，一定被牵着走。
国产卡和进口卡混用可行吗？
技术上可以，但运维成本会明显上升：驱动、框架、调度、监控往往要维护两套栈，故障排查也更麻烦。只有当某类任务对国产卡有明确适配优势、且团队有人力维护双栈时才建议混用。否则优先统一一种卡型，把稳定性做扎实比凑性能更重要。
