算力聚合平台需要哪些硬件支持

很多人手里有一批卡、想做个租卡或调度平台，卡挑好了却发现跑不起来：卡间通信跟不上、存储拖慢加载、平台侧一崩全盘任务掉线。这一篇不聊选哪张卡，只梳理聚合平台在硬件上必须补齐的几块，以及按什么顺序定规格才不返工。

很多人手里攒了一批卡，想做个租卡或者调度平台，卡选完了才发现跑不起来：卡之间通信跟不上、存储把加载拖成瓶颈、平台侧一崩全盘任务掉线。这一篇不聊该买哪张卡，只把聚合平台在硬件上必须补齐的几块拆开讲，并按不返工的先后顺序给你排一遍。

先明确一件事：聚合平台和单机工作室不是一回事。你要同时扛住对外接单、对内调度、对下管卡三条线，任何一条缺硬件都会以「平台在线但任务起不来」的形式爆出来。下面按节点、网络、存储、供电散热四块说，最后给落地顺序和对照清单。

一、算力节点：先定单机形态，再谈扩多少

单机里塞几张卡，直接决定机内互联方式选什么。卡间带宽不够时，多卡跑同一个模型会先卡在通信上，表现是利用率上不去、任务时间远超预估。判断思路可以参考站内「几张卡够用」那类估算方法，先算你主要接什么类型的单，再倒推单机形态。

• 区分训练卡和推理卡两种用途：聚合平台往往两者混卖，机型命名和实际配置要对得上，别只看商品页标题就下单
• 显存是硬门槛，能不能装下某个量化后的模型要先算清楚，别等客户下单才发现放不进去
• 算力节点要预留一张或几张小卡做调度、网关、监控这类常驻服务，不能把所有卡都卖出去
• 同一批机器配置尽量统一，混插不同型号会让调度逻辑和排障难度陡增

二、网络：聚合平台最容易低估的一块

网络是自建平台最常见的翻车点，因为它平时看着没事，一上量就原形毕露。最稳的做法是至少分两张网：一张跑对外业务流量，一张跑卡间与存储通信。混在一起时，一个客户传大文件就能把整机延迟拉高，而且你从监控上很难一眼看出是谁干的。

跨机多卡的任务对网络要求陡增，是否支持无损网络、能不能做流控，直接决定你接不接得下这类单。对外出口带宽和并发连接数要按客户量估，公网入口被打满时表现就是「平台在线但任务起不来」，这个排查顺序要提前写成文档，别临时现想。

网络规划没做够，后面加卡只是在给瓶颈加压力。

三、存储：分冷热两层，别用一块盘扛所有事

模型权重、数据集、客户输出文件这三类东西的读写特征完全不同：权重是反复读、很少改；数据集是读多写少但量大；客户输出是写完就该被拉走。混在同一套存储上，它们会互相拖慢，最后你分不清是谁的问题。

1. 先分层权重和常用数据集放高速本地盘或并行存储，冷备和归档放便宜的大容量盘。分层规则要写清楚谁负责搬运、多久搬一次。
2. 再估量平台侧的镜像、日志、账单数据涨得比想象快，容量规划留出增长余量。具体增速可以到 /about 看看检测口径里数据是怎么攒起来的。
3. 最后定备份明确恢复时间目标和恢复点目标，客户数据丢了比机器宕机更难处理，赔偿和口碑双输。

存储侧常见误判

• 把所有东西放一块大盘，靠目录区分——看起来省事，一压测就互相干扰
• 只算容量不算吞吐——容量够但并发读一上来照样卡
• 备份做了但从没试过恢复——真出事才发现恢复时间根本接受不了

四、供电、散热与机位：算力之外的硬约束

很多人把预算全砸在卡上，到了机房才发现电不够、散热压不住、承重不达标。单机柜功率密度决定你能塞几台机器，电不够时加卡就是加隐患，这部分成本最容易被漏算，也最容易在扩容阶段把你卡死。

功率密度

每个机柜能稳定供多少电，直接限制机器数量，不是想塞几台塞几台

散热方案

风冷还是液冷不是偏好问题，是场地允不允许的问题，跟机房条件绑定

配电冗余

UPS 和双路配电要做到能撑过短时波动，训练任务中断一次损失的不只是机时

机房侧要求

机位、承重、消防这些条款要在签场地合同前逐条确认，别等设备到了才返工

五、落地顺序与对照清单

硬件采购最大的浪费不是买贵了，是顺序错了导致返工。推荐的顺序是：先定用途（训练为主还是推理为主）→ 定单机形态 → 定网络与存储 → 倒推供电散热 → 最后才定采购数量。前一步没定死，后一步就先别签合同，这是省时间也省钱的做法。

每一步都留一张这样的对照表，验收方式写不清的那一项，就是后面扯皮的点。放量采购前先跑一轮真机压测，用站内 /tools/speed-test 这类方式先量出延迟基线，比盯着参数表可靠得多。定价口径也别拍脑袋，先去 /compute/gpus 和 /compute/platforms 把同类机型翻一遍，再到 /price-watch 核对当时的数字，避免自己定价和市场脱节。