去中心化GPU云底层是怎么搭的——去中心化云算力全景·第二章:技术架构

专辑说明

本文是《去中心化云算力全景》系列的第二章。系列共十章,每章独立成文。上一章(市场总览)覆盖了Neocloud的市场规模、定价结构和商业模式,本章深入技术底层,拆解GPU集群的三个核心技术层:互联网络、散热架构、GPU调度系统。

一、为什么技术架构决定了谁能真正做AI基础设施

AI大模型训练不是把GPU堆在一起就能工作的。

这句话听起来像废话,但它指向一个经常被忽视的事实:GPU集群的性能瓶颈,往往不在GPU本身,而在连接GPU的网络、为GPU散热的冷却系统,以及调度GPU工作的软件栈。

一个配置不当的集群,昂贵的GPU可能一半时间都在等待------等网络同步梯度,等散热系统降温,等调度器分配任务。

理解这三层技术架构,是判断一个GPU云平台是否真正适合AI工作负载的基础------无论它是超大云厂商、中心化Neocloud,还是去中心化GPU网络。

二、互联网络:InfiniBand还是以太网

这是GPU集群技术选型里争议最多的话题之一,也是最容易被过度简化的话题之一。

先把数字放出来再讨论:

InfiniBand HDR实现了稳定的0.6微秒端口到端口延迟。100Gbps以太网的基线延迟为1.2微秒,在拥塞情况下可以劣化到50微秒以上。 3exhosting

InfiniBand带宽效率约95%------200Gbps的InfiniBand实际吞吐维持在190Gbps。以太网的效率因配置而异:标准以太网约85%,经过调优的RoCE v2可达92%。 3exhosting

这两个数字背后的工程含义,需要结合分布式训练的工作原理来理解。

分布式训练为什么对网络这么敏感

在训练一个大型语言模型时,有一个操作会被执行数百万次:AllReduce。

AllReduce是NCCL(NVIDIA集体通信库)的核心操作,具体分两个阶段:首先是Reduce-Scatter,每块GPU将自己的梯度张量的一个分块发送给所有其他GPU,同时从其他GPU接收分块,最终每块GPU持有完整梯度的一个完全求和切片;然后是AllGather,每块GPU将自己的切片广播给所有其他GPU,最终所有GPU都拿到完整的平均梯度。

这个操作的频率与模型层数和训练批次密切相关------一个1000亿参数的模型,在一次完整的训练迭代里可能需要数千次这样的集合通信操作。

在分布式训练中,梯度同步发生数百万次,微秒级的差距会在跨越数千次迭代中积累成小时级的额外训练时间。 Invenia

更关键的是拥塞行为的差异:

拥塞行为是关键区别------InfiniBand在拥塞下性能平稳下降,以太网在入向拥塞(incast)下会崩溃。 3exhosting

入向拥塞(incast)是AI训练里的常见场景:AllReduce的AllGather阶段,所有GPU同时向同一个节点发送数据,形成"多对一"的流量模式,以太网在这种场景下的延迟会从正常的1.2微秒劣化到50微秒以上,而InfiniBand能优雅地降级处理。

2026年的真实格局:不是非此即彼

InfiniBand在2023年主导AI训练集群,市场份额约80%。到2025年中期,以太网在AI后端网络中取得领先,驱动因素是超以太网联盟(UEC)规范成熟以及超大云厂商公开验证了大规模RoCE的可行性。对于二线和三线公司,这意味着存在可行的生产级替代方案,替代过去200,000美元以上的InfiniBand交换机。 Energy-solutions

市场正在走向双轨未来:InfiniBand用于超大规模性能,以太网用于广泛可及性和具有成本效益的AI计算。 tech plus trends

NVIDIA Spectrum-X 800G以太网现已出货并经过Blackwell部署验证,缩小了InfiniBand在特定工作负载上的优势。NDR 400G InfiniBand仍主导训练集群,XDR 800G正在推出。AI集群网络越来越混合------InfiniBand用于训练,以太网用于推理。 3exhosting

实际选型的决策框架:

复制代码
集群规模 < 32节点:
→ 经过调优的RoCE v2以太网通常已经足够
→ 成本优势明显,运维复杂度更低

集群规模 32-256节点(中等规模训练):
→ 需要评估工作负载的通信占比
→ 如果AllReduce时间 < 总训练时间的20%:计算受限,网络影响有限
→ 如果AllReduce时间 > 20%:通信受限,InfiniBand的优势开始显现

集群规模 256+节点(超大规模训练):
→ InfiniBand仍是黄金标准
→ 延迟一致性和拥塞处理能力是决定因素
→ GPT、LLaMA、Claude这类模型的训练首选

推理工作负载(所有规模):
→ 以太网通常已经足够
→ 推理的GPU间通信需求远低于训练
→ 成本效率优先,延迟要求相对宽松

InfiniBand的成本真相

InfiniBand硬件成本是以太网的2倍,但运营成本低40%。 3exhosting

InfiniBand交换机的采购价格确实高出很多,但有两个抵消因素:一是InfiniBand的自动化管理能力降低了运维人力成本;二是更高的带宽效率意味着同样的训练任务需要更少的GPU小时,在大规模训练里这个节省可以超过网络本身的成本差。

对于去中心化GPU网络,网络互联是最大的工程挑战之一:去中心化节点分布在全球各地,节点间通过公网连接,无法部署物理的InfiniBand互联,只能通过高性能公网连接和软件优化来弥补这个差距。这意味着去中心化网络更适合推理这类GPU间通信需求低的工作负载,而超大规模训练仍然需要中心化的专属集群来提供物理层面的高速互联。

三、散热架构:液冷为什么成了必选项

AI GPU的功耗密度,从根本上改变了数据中心散热的规则。

NVIDIA的GPU热设计功耗演进:A100(2020年)400W TDP,风冷可管理,约15kW/机架;H100 SXM(2023年)700W TDP,达到风冷极限,约40kW/机架;B200(2025年)1000W TDP,强烈建议液冷;GB200 NVL72(2025年)每GPU托盘1400W,液冷强制要求,约120kW/机架。 SitePoint

空气冷却在超过50 W/cm²热通量或约35kW每机架时变得不足。现代AI GPU如H100的86 W/cm²已超过这个阈值。机架密度超过35kW时,直接液冷是必要的。机架密度超过100kW时,浸没冷却是唯一可行方案,PUE可低至1.02。 Markaicode

2026年行业转变:标准机架正在从15kW移向30kW以上。GB200 NVL72以72块GPU在单一机架配置达到120kW每机架。 Mlops

三种冷却技术的PUE对比

PUE(电力使用效率)因技术而异:传统风冷1.50-1.80,带节能器的风冷1.30-1.50,直接液冷1.10-1.25,单相浸没冷却1.02-1.10,两相浸没冷却可达1.01-1.05。 Markaicode

PUE的含义是:每消耗1单位IT设备用电,数据中心总共消耗多少电。PUE 1.50意味着数据中心每消耗1.5度电,只有1度用于GPU计算,0.5度用于散热、照明等基础设施。PUE 1.02意味着基础设施开销只有2%。

水的导热能力约是空气的3500倍。通过液冷,运营商能够维持更稳定的内部温度,减少对昂贵GPU的机械应力并延长其寿命。 arxiv

一个真实的性能案例

一个研究计算总监有一个H100集群在运行一个70亿参数的微调任务,每周24小时×5天运行。每次运行到第六小时,GPU结温就会达到83°C,时钟频率降低。一个22小时的任务需要31小时才能完成。更换冷却回路后------相同的GPU,相同的工作负载------结温降至44°C。用液冷做同样的工作,GPU性能提升了约30%,不是因为换了更好的GPU,而是因为GPU终于可以在设计频率下持续运行而不降频。 arxiv

这个案例精准说明了散热架构的本质价值:GPU在高温下会自动降频保护自己,冷却系统不够好,你买了最贵的GPU但跑不出最高性能。

散热技术选型矩阵

三个阈值决定正确的冷却架构选择:机架密度超过20kW时,ASHRAE TC 9.9建议直接液冷,有散热物理学依据,不是厂商偏好。冷板安装在GPU芯片上,冷却液通过封闭或开放回路流动,PUE约1.10-1.20。这覆盖了2026年基于H100和H200硬件构建的大多数AI部署。超过50kW每机架(B200、GB200 NVL72及以上),浸没或专用高密度液冷基础设施是唯一可行方案。 arxiv

复制代码
机架密度分级与冷却方案选择:

< 15kW/机架(传统服务器密度):
→ 标准风冷,热通道/冷通道隔离
→ 成本最低,但不适合现代AI GPU

15-30kW/机架(H100单机架):
→ 带后门热交换器的高密度托管
→ 风冷极限区间,建议评估液冷

30-60kW/机架(多块H100或单块B200配置):
→ 液冷为必要选项
→ 直接液冷(直冷板)是主流方案
→ 安装成本:$15K-$25K/机架 + CDU基础设施

60-120kW/机架(B200全配置或NVL72):
→ 直接液冷或浸没冷却
→ 需要设施层面的改造
→ 安装成本:$20K-$40K/机架 + 设施改造

120kW+/机架(GB200 NVL72):
→ 浸没冷却是推荐方案
→ PUE可达1.02,与风冷的1.50-1.80相比
→ 节省30-40%冷却能耗,高电价地区ROI明显

液冷对去中心化GPU网络意味着什么

对于部署在全球各地的去中心化GPU节点,散热是一个特别重要的约束。不同地理位置的气候条件、电力成本、设施条件差异极大。

高端AI GPU(B200及以上)对液冷的强制要求,意味着去中心化网络中能够承接这类硬件的节点,必须具备相应的冷却基础设施。这实际上对节点运营商设定了更高的准入门槛,也是去中心化网络在管理节点质量时必须解决的工程问题。

四、GPU调度:实现95%+利用率的软件栈

硬件再好,如果调度软件不行,GPU依然会大量空闲。

GPU调度解决的核心问题是:如何在动态变化的工作负载(训练任务、推理请求、微调任务)之间,最大化GPU的实际计算时间,最小化等待时间。

分布式训练调度:NCCL与并行策略

大规模训练的调度本质上是多个并行策略的组合选择:

复制代码
数据并行(Data Parallelism):
- 每块GPU持有完整的模型副本
- 不同GPU处理不同的数据批次
- 通信:AllReduce同步梯度
- 适合:中等规模模型,GPU数量较少的场景

张量并行(Tensor Parallelism):
- 单个权重矩阵被切分到多块GPU
- 通常是节点内并行,通过NVLink直接通信
- 通信量大,依赖超高速互联(NVLink)
- 适合:超大模型的单层无法放入单块GPU

流水线并行(Pipeline Parallelism):
- 模型不同层分配到不同GPU
- 通过点对点通信传递激活值
- 不使用集合通信,NCCL影响小
- 适合:超大模型跨节点并行

对于vLLM推理的张量并行,主导设置是NCCL_P2P_LEVEL=SYS,以使用NVSwitch进行AllReduce。TP进程组使用与DP进程组分离的NCCL通信器。不要在并行维度之间共享通信器,初始化顺序对避免死锁很重要。

生产推理调度:vLLM与PagedAttention

对于推理工作负载,调度问题更加复杂:你需要在同一时间处理来自不同用户的请求,每个请求的上下文长度不同,需要的KV Cache大小不同,完成时间不确定。

vLLM的核心创新是PagedAttention,它以非连续块管理KV缓存内存,类似操作系统的虚拟内存分页。这大幅减少了朴素KV缓存分配中的内存碎片化,允许引擎从相同的VRAM预算中服务显著更多的并发请求。

2025-2026年vLLM发布中引入了解耦预填充/解码架构,将计算密集的提示处理(预填充)阶段与内存带宽密集的Token生成(解码)阶段分离。这允许对每个阶段采用不同的硬件或调度策略,提升整体GPU利用率。

KV缓存:被低估的推理瓶颈

vLLM GPU集群生产事故的最大单一原因是在节点间错误地调整KV缓存大小------导致在负载下出现级联抢占和P99延迟峰值飙升8倍。

KV Cache是推理时存储注意力计算中间结果的内存区域。对于长上下文推理,KV Cache的内存需求可能超过模型权重本身。正确的KV Cache管理,是生产推理服务P99延迟稳定性的核心保障。

GPU利用率的三种优化机制

复制代码
MPS(多进程服务):
- 让多个进程共享同一块GPU的SM(流式多处理器)
- 适合:推理任务,单个请求无法填满GPU计算资源
- 注意:需要隔离内存访问,避免进程间干扰

时间切片(Time-slicing):
- GPU在不同任务间轮流切换
- 最简单,但上下文切换有开销
- 适合:低优先级的后台任务,对延迟不敏感

MIG(多实例GPU):
- 在NVIDIA A100/H100上可用
- 将单块GPU物理分割为最多7个独立实例
- 每个实例有专属的SM、内存、带宽
- 适合:需要严格隔离的多租户环境

GPU共享(MPS、时间切片、MIG)、NUMA感知调度和RDMA数据传输最大化GPU利用率,减少空闲周期。

Kubernetes在GPU集群调度中的角色

Kubernetes自动化GPU资源管理,确保跨多台机器高效调度和扩展,实现在大规模数据集上更快的训练。

在vLLM GPU集群架构中,使用Ray作为分布式调度器,结合Karpenter进行自动扩缩容,在p4d.24xlarge(8×A100 80GB)上测试,处理每秒1200个请求的场景中,通过Ray调度器实现自动故障恢复------当一个GPU worker失败时,Ray调度器将其标记为不健康,Karpenter扩缩容器旋转替换Pod。

五、去中心化GPU网络的技术挑战与解题思路

把上面的三层技术架构(网络互联、散热、调度)放到去中心化GPU网络的背景下,会发现一些独特的工程挑战。

挑战一:节点间无法部署物理高速互联

中心化Neocloud可以在数据中心内部署InfiniBand交换机,实现GPU间0.6微秒延迟。去中心化网络的节点分散在全球,节点间只能通过公网连接。

解题思路:针对不同工作负载分配不同的节点组合。

复制代码
推理工作负载(GPU间通信需求低):
→ 全球分布式节点,地理就近调度
→ 公网延迟对推理性能影响有限
→ 去中心化网络的优势:故障容忍、低成本

大规模训练(GPU间通信密集):
→ 专属集群模式:在同一数据中心集中部署
→ 节点内仍可使用高速互联(如Axe Compute的B300集群)
→ 去中心化网络提供的是:硬件储备和调度能力
  (不是把2304块GPU分散到全球各地跑训练)

Aethir为Axe Compute配置的2304块NVIDIA B300集群,部署在美国Tier 3数据中心,物理层面集中,满足高速互联要求------这正是去中心化网络支撑专属集群部署的正确实现方式。

挑战二:节点质量参差不齐

去中心化网络的节点由不同运营商在不同地点运行,硬件型号、散热条件、网络质量都可能差异极大。

解题思路:建立节点质量评估和分层机制。

复制代码
节点质量分层:

A级节点(企业级):
- 专业数据中心环境
- 液冷或高密度散热基础设施
- SLA保证的网络连接
- 可承接大规模训练和生产推理

B级节点(半专业):
- 良好但非专业数据中心环境
- 风冷为主,适合H100及以下
- 稳定但不保证最低延迟
- 适合实验性训练和弹性推理

C级节点(社区级):
- 家庭或小型办公室环境
- 散热条件受限
- 网络稳定性不保证
- 适合非关键工作负载

挑战三:故障处理与任务迁移

中心化集群的故障处理依赖数据中心的统一运维体系。去中心化节点的故障更难预测,需要软件层面的自动恢复机制。

解题思路:无状态任务设计 + 自动检查点 + 快速迁移。

复制代码
推理任务的故障处理(相对简单):
- 推理是无状态的,单次请求失败直接重试
- 路由层自动将请求切换到健康节点
- 用户感知:单次请求延迟增加,无服务中断

训练任务的故障处理(复杂):
- 需要定期保存检查点(Checkpoint)
- 节点失败时从最近的检查点恢复
- 检查点频率是容错能力和额外开销的平衡
- 去中心化训练需要更高频率的检查点来降低损失

六、不同工作负载的基础设施选型指南

基于以上三层技术分析,给出一个面向实际决策的工作负载-基础设施匹配矩阵:

工作负载类型 互联需求 散热需求 调度复杂度 推荐架构
超大规模训练(1000B+参数) InfiniBand必须 液冷必须 高(多维并行) 中心化专属集群
中等规模训练(7B-70B) RoCE以太网足够 液冷建议 Neocloud保留实例
生产推理(低延迟API) 以太网足够 取决于GPU型号 中(KV Cache管理) 去中心化+专属混合
AI Agent持续运行 以太网足够 取决于GPU型号 低(单任务流) 去中心化(高可用优先)
微调(LoRA/QLoRA) 以太网足够 风冷或液冷 弹性实例
实验开发 以太网足够 风冷足够 现货实例或本地Ollama

Aethir Claw的技术实现

Aethir Claw是运行在Aethir GPU基础设施上的AI Agent托管平台,它的技术设计与上述工作负载特性高度匹配:

每个Agent实例分配完全隔离的VPS环境,有独立的内存、API密钥和会话状态,避免多租户环境中的资源竞争(坑点七中提到的"噪音邻居问题")。Aethir Mesh提供开源模型的统一推理接口(DeepSeek V4、Kimi K2.6等),推理在Aethir网络内完成,不出圈。ClawHub到2026年中已积累超过44,000个社区构建的技能和150万个活跃Agent,印证了这套架构在实际生产负载下的可行性。

七、2026年技术路线图:接下来会发生什么

网络层:以太网继续追赶,但未来是双轨制

超以太网联盟(UEC)于2024年发布UEC 1.0规范,合规产品预计2025-2026年推出。1.6T光学接口开始出现在2026-2027年的路线图上。AI集群网络越来越混合------InfiniBand用于训练,以太网用于推理。 3exhosting

这意味着未来的GPU集群将越来越多地采用混合网络架构:节点内(intra-node)使用NVLink高速互联,节点间(inter-node)训练流量走InfiniBand,推理流量走高性能以太网。单一网络技术统治一切的时代,正在被更细粒度的分工所取代。

散热层:浸没冷却走向主流

2026-2027年:单相浸没冷却在超大规模AI基础设施中实现主流认可。

浸没冷却的普及,将允许更高的机架密度,进而允许在同等数据中心面积内部署更多GPU。这对去中心化网络的节点容量有直接影响------支持浸没冷却的节点,可以在相同物理面积内提供更多算力。

调度层:推理优化成为主战场

随着推理工作负载的权重持续上升,推理调度技术成为最热门的工程方向:

KV Cache的管理和优化(PagedAttention已经是标准配置)、预填充和解码的解耦(vLLM的disaggregated架构)、跨节点的推理流量智能路由------这些技术正在快速成熟,并将直接影响去中心化GPU网络在推理场景下的性能表现。

八、常见问题(FAQ)

InfiniBand和以太网用于AI训练,到底该选哪个?

对于32节点以上的集群,InfiniBand通常提供更好的延迟和扩展性。对于较小或实验性的设置,以太网可能已经足够。具体来说,如果你的AllReduce通信时间占总训练时间不足20%,你的工作负载是计算受限的,InfiniBand的网络延迟优势影响有限。如果超过20%,InfiniBand的优势开始显现,尤其是超过32节点的大型集群。推理工作负载通常以太网已经足够。 tech plus trends

B200 GPU为什么强制要求液冷?

直接液冷是GB200 NVL72系统的强制要求。风冷无法消散140kW每机架的热量。部署Blackwell的设施必须安装直接液冷基础设施,包括冷却液分配单元(CDU)、泄漏检测和兼容的机架设计。后门热交换器在这种密度下是不够的。B200的1200W液冷TDP在8GPU配置下,整台服务器功耗在16-20kW范围内,远超风冷能处理的上限。 arxiv

什么是PUE,AI数据中心的目标PUE是多少?

PUE(电力使用效率)= 数据中心总用电 ÷ IT设备用电。PUE越接近1,能源效率越高。传统风冷数据中心PUE约1.50-1.80;直接液冷1.10-1.25;浸没冷却1.02-1.10。Google等超大云厂商的最优PUE约1.08-1.10。单相浸没冷却在优化部署中实现1.03-1.08的PUE,两相浸没可达1.02-1.05。与风冷基线相比,节省30-40%的冷却能耗,在高电价地区(超过$0.12/kWh)或高占空比设施(AI训练,每年超过8500小时)中有显著的TCO优势。

去中心化GPU网络如何处理大规模训练的高速互联需求?

去中心化网络无法在分散的全球节点之间部署物理InfiniBand。正确的解法是:大规模训练采用专属集群模式,在同一数据中心集中部署节点,保证高速互联;去中心化网络提供的是硬件储备和调度能力。Aethir为Axe Compute配置的B300集群部署在美国Tier 3数据中心,正是这种模式的实际案例。去中心化网络的优势体现在推理和Agent工作负载上,而不是要求极高GPU间通信带宽的超大规模训练。

vLLM的PagedAttention解决了什么问题?

vLLM的核心创新PagedAttention以非连续块管理KV缓存内存,类似操作系统的虚拟内存分页,大幅减少了朴素KV缓存分配中的内存碎片化,允许从相同VRAM预算中服务显著更多的并发请求。简单说:在没有PagedAttention的系统里,不同长度的推理请求会导致大量显存碎片,同一时间能并发处理的请求数量受限;PagedAttention让显存利用率大幅提高,相同硬件可以服务更多并发用户。

去中心化GPU网络如何保证节点质量?

节点质量管理是去中心化网络面临的核心工程挑战。通常的解法是建立节点质量分层机制------通过持续的性能测试和监控,将节点分为不同等级,路由不同类型的工作负载到匹配质量等级的节点。高价值工作负载(企业级推理、长期训练任务)被路由到经过验证的高质量节点,弹性工作负载则可以使用更广泛的节点池。Aethir网络长期维持95%以上的GPU利用率,是节点质量管理有效性的一个侧面验证。

数据来源

· Introl: InfiniBand vs Ethernet for GPU Clusters 2026

· Arc Compute: Network Fabric for AI Clusters

· SLYD: AI Data Center Cooling Requirements 2026

· Adam Silva Consulting: Data Center Cooling Economics 2026

· vLLM Production Architecture Guide 2026

· Spheron: NCCL Tuning for Multi-GPU LLM Training 2026 3exhosting + 3

下一章预告:

第三章将从技术架构转向商业逻辑------Neocloud这门生意的成本结构是什么,利润从哪里来,不同规模的玩家如何竞争,以及当GPU价格持续下降时,Neocloud的护城河在哪里?

相关推荐
品牌测评3 小时前
Token Plan平台分享|七条算力订阅路径拆解
大数据·人工智能·架构
人间凡尔赛4 小时前
eBPF + WebAssembly 正在重写服务网格数据平面:2026 云原生架构的“去 Sidecar“革命
后端·云原生·架构
Dr.kangder5 小时前
嵌入式软件测试(十五)——模型检查技术原理与应用
软件测试·测试工具·架构·嵌入式·静态分析
一次旅行6 小时前
ViT/CLIP/LLaVA/GPT-4V/VideoLLM多模态架构全解:原理仿真+工业落地选型+完整推理代码
人工智能·算法·架构
badhope8 小时前
MCP协议:号称要统一AI工具调用,但大多数人连第一步都走不对
后端·架构
德迅云安全-上官8 小时前
安全加速SCDN与普通CDN深度对比:原理、架构、场景与选型全解析
安全·架构
小林ixn8 小时前
从混乱到清晰:项目架构与自定义 Hook 的双重实践
react.js·架构·前端框架
@insist1239 小时前
系统集成项目管理工程师-架构基础与系统架构
架构·系统架构·软考·系统集成项目管理工程师·软考中项·软件水平考试
Dr.kangder10 小时前
嵌入式处理器虚拟化仿真技术(九)——SimpleScalar原理与应用
嵌入式硬件·架构·嵌入式·虚拟化·仿真