鲲鹏超节点风冷液冷双旗舰：架构拆解与全栈落地实践

鲲鹏超节点这套东西，我在圈子里盯着好一阵了。这次升级一口气把风冷、液冷两条线都拉满，直接做成双旗舰，说实话挺符合当下算力基础设施的节奏。为什么这么说？因为现在做数据中心规划的人，最头疼的往往不是算力不够，而是算力堆上去之后，互联和散热成了新的瓶颈。尤其是大模型训练、科学计算这类场景，单台服务器早就撑不住了，多台机器能不能高效协同，直接决定整体效率。

这篇文章我想沿着这套架构把链路彻底拆一遍：超节点到底是什么、风冷和液冷两条路线怎么选、实际部署时该盯哪些细节，再到软件生态适合怎么做、散热系统怎么验证。内容上会兼顾两类人——一类是正在做机房扩容、算力规划的同学，另一类是设备到手准备做二次调优和业务迁移的工程师。这两类人关注的点不同，但底层逻辑是一样的：搞清楚这套东西能干什么、边界在哪、怎么落地。

1. 超节点架构拆解：为什么算力集群都在往“一个计算域”走

1.1 超节点到底解决了什么问题

先说个不太严谨但好理解的类比。传统服务器集群像是很多独立小作坊，每间作坊有自己的工人、设备和仓库，作坊之间靠卡车运货。今天这批货在A作坊加工完，运到B作坊继续加工，卡车在路上跑的每一分钟，两边设备都在等着闲置，效率就浪费在路上了。

超节点做的事情，本质上就是把若干小作坊直接改造成一个打通的大车间——所有计算芯片之间用高带宽、低延迟的互联通道直连，数据不再需要一段段搬运，而是在车间内部高速流转。这个概念在业内并不新鲜，但以往更多出现在GPU集群或专用超算里，现在鲲鹏这边把它做成了面向通用计算场景的整机形态，这就有意思了。

超聚焦一个实际痛点：通信开销。大模型训练或者大规模数据分析这类任务，拆成很多并行子任务跑在多台机器上，节点间通信如果不够快，就会频繁出现“算三秒、等五秒”的尴尬局面，硬件利用率被拖得很低。超节点把以往需要走网络的通信变成了域内的直连通信，延迟降低，带宽提升，并行效率自然上去了。

从规划角度看，还有一个容易被忽略的收益：部署和管理更简单了。以前几十台服务器组成集群，每台机器都要单独管理网络、存储、作业调度，出一点问题就要跨层排查。超节点把它包装成更大的逻辑单体，业务侧看到的资源更像“一台机器”，调度、监控、故障处理的复杂度都降了一截。

1.2 鲲鹏超节点的内部结构设计思路

鲲鹏超节点究竟怎么组织起来的，公开细节不完全充分，但从圈内讨论和架构常识来推，方向是很明确的：它把多个计算节点通过高速互联编织成一个计算域，共享存储和I/O资源，对外按需提供算力。

这里有个关键设计点，是计算、存储、I/O的解耦与池化。传统服务器把计算、内存、硬盘绑在一台机器内部，扩展性受物理形态限制。超节点把资源域化之后，某个业务需要更多计算密度时就增加计算板卡，需要更大缓存或更高I/O吞吐时就调整存储域的配置，不再受单机箱的限制。

这种思路对应的是工作负载复杂度上升的现实。早期互联网业务是典型的“无状态小请求”，单机处理没问题。但AI训练、基因组计算、实时数据分析这类任务，数据相关性极强，单机算力再强，数据搬运速度跟不上的话也白搭。超节点形态直接从架构层面把最大瓶颈拆掉了。

还有一点，超节点对芯片协同效率的提升非常明显。多个计算芯片共享一致的内存视图、采用低延迟直连交换，这就意味着很多原先靠软件去补偿通信开销的优化手段可以砍掉，代码层更简单，性能却更稳。

1.3 双旗舰的定位：兼容存量与面向未来

这次升级拿出来的是风冷、液冷双旗舰，我认为这透露出一个明确的信号：鲲鹏不是只服务新建的超大规模机房，也在认真考虑大量存量机房的升级诉求。

存量机房最常见的问题是物理条件受限。很多机房当初是按风冷标准设计的，楼层承重、机柜尺寸、配电容量、冷却系统都是按传统功率密度规划的。如果新一代设备只提供液冷方案，这些机房要么大规模改造，要么干脆上不了设备，升级成本太高，动力不足。风冷旗舰的存在，就是为了让这类用户可以不做“伤筋动骨”的改造，直接通过机柜内的风冷方案把算力密度提上去。

液冷旗舰面向的则是另一类用户：新建机房或者有条件做液冷改造的场地。液冷能把单机柜功率密度拉高到风冷难以企及的水平，同等占地面积内塞进去更多算力，对空间成本敏感的一线城市机房来说，吸引力非常大。

所以双旗舰并行的本质，是用两条产品线覆盖两种截然不同的基础设施条件，而不是简单去争执风冷和液冷哪个更好。设备选型从来不是单项指标PK，而是运行环境、改造成本、运维能力、业务增速的共同权衡。

2. 风冷与液冷的技术选型逻辑：两条路线不再模糊

2.1 风冷方案的边界条件与适用场景

风冷发展到今天，技术已经相当成熟。它的思路本质是用风扇强制空气流动，把CPU、内存、硬盘上的热量带出机箱，再由机房空调把热量最终带走。优势很明显：技术成熟、维护简单、改造容易，几乎所有传统机房都能兼容，而且散热系统的备件和运维经验都很充足。

但风冷的物理上限也很清楚。空气的比热容低、热传导效率一般，要带走大量热量就只能加大风量，结果是噪音飙升、风扇功耗上升、机房空调负担加重。业内一个笼统的经验值：传统风冷机柜的功率密度做到15kW以内是比较稳的区间，超过这个数值，散热成本和噪音控制都会变得很不舒服。

风冷旗舰适合的场景其实很典型：中等规模的业务扩容、已经建好机房的政企和行业用户、对功率密度要求不极致的通用算力池、边缘节点。这类场景不需要追求极限的每机柜千瓦数，更看重的是设备拿来就能跑、坏了会修、扩容时不大动干戈。

我观察到很多用户对风冷方案有一个误解，觉得“风冷就是低端货”。实际不是这样。风冷方案在设计上同样要抓细节——前面板进风温度控制、风扇冗余策略、气流走向设计、灰尘过滤，每一项都会直接落在硬件的长期稳定性和寿命上。风冷旗舰的意义不在于“能用”，而在于把风冷这条成熟路线做到比较极致的水准。

2.2 液冷方案的技术拆解与落地成本

液冷的核心逻辑是换一种温度传递介质：用水或冷却液替代空气，直接把热量从芯片带走。因为液体的比热容和热传导效率远高于空气，同样的热量可以用小得多的体积和流量转移走，所以机柜内的功率密度可以大幅提升。

液冷按照接触方式主要分两支：冷板式和浸没式。冷板式是把冷板贴在发热芯片上，冷却液流过冷板内部带走热量，其他部件仍然靠空气辅助散热。浸没式则把整台服务器泡在绝缘冷却液里，散热更彻底，但对冷却液、结构强度、维护方式的要求都高。从目前的产业落地情况看，冷板式是更主流、更容易被接受的大规模部署方案。

液冷带来的收益最直观：单机柜功率密度可以做到50kW甚至上百千瓦，比风冷高一个数量级。对机房空间紧张、算力需求增长快的用户来说，这是解决“电够了但位置不够”问题的有效途径。

代价也很真实。首先是前期的机房改造，液冷需要部署冷却液分配单元（CDU）、布设管路、做漏液监测和防护，改造周期和成本都比风冷高。其次是运维方式变了，不再只是换风扇清灰尘，还要关注冷却液液位、水质、泵的状态、管路密封，运维团队得具备新的技能。最后是系统冗余，液冷系统一旦出问题，影响范围往往是整个机柜甚至更大范围，所以对设备本身的可靠性设计要求更高。

2.3 关键部件：离心式液冷泵的选型与流量计算

液冷系统里，离心式液冷泵是非常重要的部件，它决定了冷却液能不能在整个回路里稳定流动。选型主要看三个指标：流量、扬程和效率。

流量决定冷却能力，计算方法是把系统需要散掉的热量换算成冷却液流量。假设一套超节点液冷系统的总散热量是60kW，液冷承担80%的散热比例（另外20%还是靠风冷辅助），冷却液进出口温差取10℃，冷却液按25%丙二醇水溶液处理，它的密度约为1030kg/m³，比热容约为3.8kJ/(kg·℃)。

需要的质量流量算出来是：

60000 × 0.8 ÷ (3.8 × 1000 × 10) ≈ 1.26 kg/s

换算成体积流量约是1.22 L/s，也就是每分钟73升上下。这只是满足基本散热需求的流量，设计时通常还要留15%-20%的余量，以应对冬季低温导致的液体黏度变化、管路老化带来的压降上升等问题。

扬程则要克服整个液冷回路的阻力，包括管路沿程阻力、弯头局部阻力、冷板内部流道阻力、快接头和过滤器产生的压损。这个值不能靠直觉，最好用仿真或者实测数据来确定，留不足会导致远端分支流量不足、局部过热，留太大则白白增加泵的功耗。

选泵时还有一个容易忽略的点：泵的工作点要和系统阻力曲线匹配。泵的流量-扬程特性曲线是一条下降曲线，系统阻力曲线是一条上升曲线，两条曲线的交点才是实际运行点。光看泵铭牌上的最大流量和最大扬程没有意义，要看它在你这套管路阻力下还能不能提供足够流量。很多液冷系统调试时流量不够，问题往往就出在这里。

3. 全栈落地实操：部署配置、性能验证与软件适配

3.1 机柜改造与部署前置检查

不管选风冷还是液冷，部署前的现场勘查都必须做细，不能设备到了现场才发现条件不满足。

风冷方案相对省事，但仍要核对几项：机柜深度是不是满足设备要求、前门进风空间够不够（建议至少留出10cm以上的进风间隙）、机房空调能否满足新增的制冷负荷、供电和网络布线是不是够用。风冷最怕的是机柜放得太密，前后门被堵死，冷空气进不去，热空气出不来，再强的设备散热设计也白搭。

液冷方案的前置检查要多很多维度。首先是机柜承重，液冷系统加上冷却液的重量不小，尤其多台设备并排时，楼板承重必须复核。然后是管路走向，CDU放哪里、主供水管回水管怎么走、接头位置好不好检修，这些在施工前就要定好，不能等装完了再想改。

管路连接后的检漏是液冷部署里最耗时但也最关键的一步。建议的做法是：管路接好后，先用气压检漏，逐步加压并保持一段时间，观察压力是否下降。然后再注液循环，循环过程中重点检查所有接头、阀门处有没有渗漏迹象，用纸巾或检漏试纸逐点擦拭，不要嫌麻烦。我见过有人图省事只看压力表没掉压就认为没事，结果第二天发现某个接头处只是渗得非常慢，量不大但一直在滴，好在发现了，不然后果很难看。

另外，液冷系统里面加装的漏液检测传感器，位置和数量都有讲究。最容易被漏液影响的是电源和板卡连接器，传感器要优先覆盖这些区域；传感器的数量宁多勿少，因为漏液往往是从一个非常不起眼的缝隙开始，等到肉眼可见就已经比较严重了。

3.2 散热系统联动与性能基准验证

设备上电之后，第一件事不是直接跑业务，是验证散热和系统联动是否正常。

风冷模式下，进入BIOS或管理界面，确认所有风扇模块被正确识别、转速反馈正常。有些机型支持风扇策略配置，可以设置“性能模式”和“静音模式”。刚上电调试时建议先用性能模式，让风扇维持一个相对高的转速基准，排除散热干扰，等后续负载验证稳定了再按机房噪音要求调策略。

值得做的一个测试是温度爬坡测试：开启一个持续高负载的基准测试（比如跑一段矩阵计算），观察CPU温度曲线和风扇转速曲线是否同步变化。正常情况下，温度上升之后风扇转速会跟着上升，温度回落时转速缓慢下降。如果温度升高但转速纹丝不动，那就说明风扇策略或温度传感器链路有问题，需要尽早排查。

液冷模式下，验证流程更长。先确认冷却液循环方向正确——这个听起来荒谬，但真的发生过管路接反导致局部不降温的情况。然后看泵的反馈信号是否正常，确认流量数值和设计值是否接近，如果偏差较大，要回头看是不是管路中有气阻或者过滤器脏了。最后再做同样的温度爬坡测试，但观察重点不在风扇，而在冷却液进出口温差上。温差过小说明热量没被有效带走，温差过大都说明流量可能偏低，两种情况都需要处理。

性能基准测试建议至少跑两类：一类是CPU密集的算力测试，验证计算能力本身；另一类是内存和I/O带宽测试，验证超节点域内数据搬运能力。有一个细节：如果超节点被软件识别为多颗物理芯片，测试时要注意进程绑定和NUMA感知，否则操作系统自动调度可能把线程分配到远端内存访问上，测出来的数据会非常难看，还会误判为硬件问题。

3.3 软件生态适配：鲲鹏920上编译部署ONNXRuntime

硬件只是地基，软件生态适配才是决定设备能不能真正用起来的关键。以网上讨论度很高的“鲲鹏920适配ONNXRuntime框架”为例，这个场景其实很典型：拿到国产ARM服务器，想在现有推理服务里跑ONNXRuntime，直接pip安装不行，性能不理想，得自己编译适配。

源码编译ONNXRuntime的基本思路是先准备依赖环境，再针对ARM架构做构建：

# 安装基础依赖 sudo apt-get update sudo apt-get install -y cmake protobuf-compiler python3-dev python3-pip # 安装Python构建依赖 python3 -m pip install numpy packaging pybind11 # 克隆源码（注意加--recursive拉取子模块） git clone --recursive https://github.com/microsoft/onnxruntime cd onnxruntime # 针对ARM64构建Release版本 ./build.sh --config Release \ --build_platform linux \ --arch arm64 \ --parallel 16 \ --enable_pybind

编译过程中最容易出问题的环节是子模块拉取不完整，或者是protobuf版本不兼容。建议在克隆后先检查子模块目录是否为空，然后再开始构建。编译时间跟机器核数有关，32核以上的机器大概在二三十分钟，建议编译时用一个独立的screen或tmux会话，避免终端断开导致任务中断。

编译完成后，生成的onnxruntime Python包所在路径一般是build/Linux/Release/dist/。安装时最好用一个独立的Python虚拟环境，避免干扰系统自带的Python环境：

python3 -m venv ort-env source ort-env/bin/activate pip install build/Linux/Release/dist/onnxruntime-*.whl

验证是否真正跑在了ARM优化内核上，可以写几行简单代码确认：

import onnxruntime as ort import numpy as np sess = ort.InferenceSession("model.onnx", providers=["CPUExecutionProvider"]) x = np.random.rand(1, 3, 224, 224).astype(np.float32) out = sess.run(None, {sess.get_inputs()[0].name: x}) print("run ok, output shape:", out[0].shape) print("available providers:", ort.get_available_providers())

如果只追求“能跑”，直接用官方预编译包当然省事。但需要追求极致性能时源码编译的价值就体现出来了：可以针对ARMv8.2及以上的指令集特性做优化，可以按实际算子的需求裁剪不需要的组件，构建出来的运行库更干净，性能也更可控。要留意的是，线上环境的GCC版本、Python版本和编译环境要一致，不然换一台机器就要重新编译。

我实测下来有几个体会：一是ONNXRuntime配合ARM的线程池配置往往比默认配置更有收益，高并发场景下适当调低线程数、配合多实例部署，反而吞吐更高；二是推理前用CPUEP还是需要做预热，第一次推理会触发算子初始化；三是在鲲鹏平台上，int8量化模型的收益通常比浮点模型更明显，如果你的精度要求允许，优先考虑量化。

4. 从仿真到排障：液冷系统验证方法与常见问题速查

4.1 用一维系统仿真验证液冷设计

液冷系统设计阶段就要把“水账”算清楚，而不是等设备装完再发现问题。系统中用到的仿真工具比较多，比如Amesim、Flowmaster、6SigmaRoom这类一维系统级仿真软件，各自擅长侧重点不同，但思路一致：把液冷回路建模成一个个元件的组合，通过求解流量-压降平衡来预测整个系统的运行状态。

Amesim做液冷仿真时，核心元素包括泵、换热器、冷板、管路、阀门、膨胀罐等。建模的第一步是把真实系统的拓扑画出来，标注每段管路的长度、内径、弯头数量、接头类型，这些细节直接影响压降计算精度。第二步是设置泵的特性曲线，这个数据可以从泵厂商样本里拿到，标注不同流量下的扬程。第三步是设置冷板的热阻模型，把发热功率和冷却液温升关联起来。

仿真能发现的问题比想象中多：某个支路流量分配不均、泵的扬程不够导致末端流量偏低、管路中某个位置容易滞留气泡、冷板进出口温差超过设计值。这些问题如果在设计阶段就暴露，改起来只需要改模型参数，成本趋近于零。等设备到现场再发现，就要动管路、换泵、加阀门，代价就完全不同了。

有一种常见的误用是仿真模型建得太粗。管路长度拍脑袋写、弯头数量少算几个、泵特性曲线简化成直线，算出来的结果偏差很大，反倒不如有经验老师的估算准。仿真工具的价值在于精度，投入的时间必须花在模型细节上，否则结果没有参考意义。

4.2 常见问题排查速查表

把我在实际项目中经常遇到的问题整理成了一张表，虽然不能覆盖所有情况，但遇到对应现象时可以快速缩小范围，节省不少排查时间。

4.3 排障经验：两段真实踩坑记录

说两个我实际遇到的案例，供参考。

第一个案例是液冷系统流量低。现象是几台设备同时运行烤机测试，设备A的CPU温度比其他设备明显偏高，冷板进出口温差偏大。排查过程很有意思：泵的反馈转速正常、过滤器刚换过、阀门开度也查了，一切指标看起来都对，但流量就是偏低。

最后定位到的问题很隐蔽——管路最高点积了一小段气。冷却液循环中气体逐渐聚集在管路高点，形成一个气袋，导致有效流道变窄，流量下降。当时排查了很久，最后在管路最高点的排气阀上做了手动排气，流量立刻恢复了。从那以后我养成了一个习惯：液冷系统试运行的头几天，每天早上都把各高点排气阀打开放一放气，等运行稳定了再关闭。

第二个案例是风冷服务器在机房空调正常的情况下频繁高温告警。空调出风温度测过是达标的，但设备进风口实测温度已经超过30度。原因是机房机柜摆放过于密集，前排机柜排出的热风直接被后排机柜吸进去，形成了“热风短路”。空调整体制冷量是够的，但气流组织不对，冷却效率大打折扣。这是典型的风冷环境设计问题，调整机柜间距或者加装挡风导流板之后，问题立刻缓解。

这两个案例放进来看，散热系统的问题往往不是某一个部件坏了，而是系统层面没协调好。无论是风冷还是液冷，都要用系统思维去排查，只盯着单个组件容易走弯路。

结尾

写到这，核心内容基本都覆盖了。从我个人实际操作体会来说，风冷和液冷双旗舰并行最有价值的地方在于，给了不同基础设施条件下的人一个合适的上车路径。风冷方案能让你在现有机房条件下快速用上超节点架构，液冷方案则给追求极致密度的人留足了空间。没有哪个方案绝对更好，只有哪个方案更适合自己的场地、团队和业务阶段。

最后再分享一个小技巧：不管选哪条路线，进场之前先把自己的负载特征摸清楚。如果你的业务是大量短任务并行，延迟和调度效率是关键；如果是长时间高负载训练，散热持续性和稳定性更关键。用负载特征去倒推散热方案和配置参数，比拿着参数表逐项对比要有用得多。这套设备的生态还在快速完善中，软件层面的适配工作会越来越多，建议团队里尽早有人开始做源码级别的适配验证，积累经验这件事，越早做越值。