2026中国太空算力10大关键技术④:空间热控系统
近一年来,太空算力话题持续升温,越来越多的规划与讨论浮出水面。你好太空也与多家行业内企业展开了一系列访谈,深入了解行业一线实践与真实挑战。结合自身对行业的观察与思考,我们尝试梳理了太空算力行业的10大关键技术,形成一套初步的分析框架,供从业者与关注者参考。
本期我们就来聊聊:2026中国太空算力10大关键技术④:空间热控系统。
01
为什么空间热控系统很重要
在多数关于太空算力的讨论中,常能看到一种说法:太空算力可帮助解决地面数据中心冷却水和电力消耗过多的问题,仿佛芯片在太空中散热是一件轻而易举的事。实际上,太空与地面截然不同。在地面数据中心,热量可以通过对流、传导和辐射等方式排散;但在太空真空环境中,由于缺乏能够形成对流的介质,最终向深空排热只能依赖热辐射。
然而传统热控体系的散热能力并非无限:在典型工况下(辐射器温度约300–350K、发射率约0.9时),每平方米辐射器约能排出400–800W热量。而当太空算力时代到来,单星计算载荷功率大幅跃升。以SpaceXStarmind星座规划为例,StarmindAI1的计算载荷峰值功耗约250kW,平均功耗约175kW,其载荷由大量高功耗AI加速器组成,芯片级热流密度远超传统航天器电子设备。
面对如此量级的散热需求,传统热控体系已难以满足算力芯片的散热需求。太空算力对空间热控系统提出了新的要求。
首先是大面积排热能力和高温差耐受能力,根据斯特藩-玻尔兹曼定律,辐射散热功率P=εσA(T⁴-T₀⁴),其中ε为表面发射率,σ为常数,A为辐射面积,T为辐射器表面温度,T₀为宇宙背景温度。散热功率与面积成正比,与温度的四次方成正比。但面积越大,结构质量和收拢体积越大,在整流罩容积和发射质量预算固定时,挤占计算载荷配额;温度提升则受限于芯片结温上限。两者共同决定了单星功率上限。
其次是长寿命稳定运行能力。算力星座的商业模式要求卫星在轨运行多年,热控系统作为持续工作的分系统必须在微重力、辐射和极端温度交变环境下长期可靠运行。一旦流体回路发生泄漏或泵组失效,芯片热量无法排出,整星计算功能可能迅速瘫痪。因此,热控系统的可靠性直接影响卫星能否持续产生商业价值。
02
目前技术发展现状
如前文所述,太空算力对空间热控系统提出了大面积排热、高温差耐受和长寿命稳定运行等要求。就当前的技术成熟度而言,行业主要存在两条技术路线:一条是以液体直接接触芯片的液冷/浸没式液冷路线,追求芯片级传热效率的最大化;另一条是以热管、两相流体回路和泵驱动回路为基础的传统回路散热升级路线,追求热量输运能力和辐射面积的系统性提升。
路线一:液冷/浸没式液冷
浸没式液冷将计算芯片或整块板卡直接浸入绝缘冷却液中,通过自然对流或泵驱循环带走热量,再传递至空间辐射器,其优势在于能够显著提高芯片级热传导效率。但太空应用需解决微重力下液体稳定性、工质泄漏、系统重量,以及宇宙辐射和极端温差下的密封与材料兼容性问题。
该路线目前基本仍处于探索试验阶段。国内浸没式液冷技术大多集中于地面数据中心,曙光数创、兰洋科技等企业已有成熟的地面产品,但尚未发布公开的太空算力热控产品。在太空算力方向,地卫二公布了自主研发的“太空浸没式液冷系统”,用于解决高能量密度芯片在太空特殊环境下的散热问题。
国外,Starcloud在其白皮书中提出了芯片端采用液体冷却或两相浸没式冷却的方案,先吸收GPU产生的热量,再利用两相流体循环将热送至远端辐射器。APR Technologies的Rheion架构则基于电流体动力学(EHD)微泵驱动的介电冷却液循环,可从组件级液冷逐步扩展至全浸没式冷却。该公司已与Airbus UpNext签署协议,将在SpaceRAN演示器上测试基于Rheion技术的热开关,计划2028年开始在轨测试。
路线二:传统回路散热升级
传统回路散热升级路线以热管、两相流体回路和泵驱动回路为核心,将热量从芯片输运至大型辐射器,侧重于热量输运能力和辐射面积的系统性提升。当前攻关方向包括:提高散热温度、扩大辐射面积以适应百千瓦级热负荷、降低单位质量散热代价以腾出计算载荷质量配额,以及提升流体回路在长期在轨运行中的可靠性。
国内,多家企业正围绕太空算力场景推进传统回路散热升级。锐莱热控、国科环宇等企业的泵驱动液冷方案及流体回路方案已实现在轨运行。热数科技承担了国星宇航太空计算星座021任务”12颗星所有卫星的热控和结构产品研发工作。
国外,SpaceX在StarlinkV2版本卫星上采用了泵驱动液冷方案。AI1算力卫星即采用该方案,单星计算载荷峰值功耗250kW、平均功耗175kW,配备160平方米可展开液体辐射器,设计热流密度约1400W/m²,内部集成冗余泵回路并配备微流星体防护。国际空间站已采用机械泵驱动液氨热控系统运行多年,排热能力达70kW,但其能否可靠扩展至数据中心级别的热量排放,目前仍是未知数。
03
行业格局
太空算力热控领域正形成三类参与主体并行的格局:一是传统专业热控企业向太空算力场景延伸,二是卫星平台企业将热控纳入自研体系,三是国家队科研院所承担关键技术攻关与在轨验证。三类主体各有侧重,共同构成当前行业的基本盘。
传统热控企业
微焓科技:核心团队来自清华、中科大、华科等高校,面向太空算力场景,其积累的相变储能、流体回路驱动、智能热控涂层等空间算力热管理核心关键技术,可为高功耗在轨算力载荷提供从被动散热到主动温控的全谱系方案。在流体回路液冷系统方面,微焓科技为“睿格星云”星座首发技术验证卫星提供了整套主动热控系统。此外其还与航升卫星、椭圆时空联合发布了ThermaOS卫星AI热管理操作系统。
深轨变幻:面向商业航天、太空数据中心等高功率场景,提供从核心材料、热控组件到系统级热管理的一体化服务,其热控产品已累计服务超过70颗卫星。在太空算力方向,公司为首颗天雁27星量身定制了一体化热控白漆膜及隔热组件,有效增强整星散热性能;同时作为鸿鹄03星热控分系统供应商,提供了槽道热管、航天特种热控涂层、加热器等被动热控全套解决方案。
锐莱热控:其核心团队具有中科院和航天五院背景,曾参与载人航天、空间站、探月工程等国家级项目。在液冷卫星系统领域国内市场占有率达90%,国内主要算力星座的泵驱动液冷方案及产品多由其提供。搭载其单相流体回路的银河灵犀03星已在轨稳定运行3年;2026年7月和8月,辰光一号、蓝箭鸿擎鸿鹄03星搭载的液冷流体回路也先后在轨顺利运行。
热数科技:具备航天热控与AI数据中心液冷技术双重能力,公开信息显示其热控产品已服务超过200颗在轨卫星。公司正构建覆盖取热、输热、排热与智能运维的系统级热管理能力,2026年发布全柔性可展开辐射器,该产品采用“剪刀叉式展收机构+碳纤维卷筒卷绕”方案。可实现高达60%的减重(总重≤40kg)。
卫星平台企业
国星宇航:目前已完成两组太空计算星座的发射。2025年5月,021任务12颗卫星入轨,热控和结构分系统由热数科技承担。2026年10月,“星算”计划02组8颗卫星由国星宇航自主研制并成功发射,将进行万瓦级液冷流体回路、超大尺寸展开式辐冷翼等关键技术在轨验证。
地卫二:正自研高导热复合材料并配合展开式辐射器,未来还计划引入自研热泵技术,其与东方星链共同推进“太空之弦”计算星座,远期规划部署超过1000颗太空智能体,计划2027年发射G1星,计算负载11.5kW、算力40–60P,并部署集成太空液冷系统的智能计算节点,以优化卫星散热表现。
国家队科研院所
航天五院501部 :501部为问天实验舱研制了三套液冷系统,将设备和试验载荷产生的热量收集并辐射至外太空,可支持数千瓦级以上试验载荷的散热。在太空算力方向,501部所属的航天器热控全国重点实验室在2026年度开放基金项目指南中,将“太空算力卫星先进能源与热管理技术”列为重点研究方向之一。
04
行业目前面临的技术难题
第一,可靠性与长寿命验证不充分。太空算力对空间热控系统提出了多年乃至十年以上稳定运行的要求,但部分新型液冷架构仍缺乏足够的长期在轨验证数据。泵、阀门及旋转流体接头等关键部件的寿命与可靠性,以及工质、管路和换热界面的长期性能变化,都会影响系统的持续运行能力。
第二,动态负载适应与热控响应能力面临更高要求。太空算力载荷以AI模型训练、大规模并行推理等任务为主要应用场景,计算任务的启停、批次切换及负载调度可能导致载荷功耗在较短时间内快速变化。这对空间热控系统的负载适应能力、温度稳定性和控制策略提出了更高要求。
第三,地面测试难以完全复现长期在轨真实工况。地面热平衡试验、热真空试验与数值仿真虽然能够验证热控系统的设计性能,但试验环境与真实轨道热环境之间仍可能存在差异,模型预测结果也需要通过在轨测量数据持续修正。因此,对于面向大功率算力载荷的新型热控系统,如何结合地面试验、仿真分析与在轨飞行验证,逐步降低系统性能预测的不确定性,仍是行业需要解决的重要问题。
05
未来趋势
向星座级协同热管理演进:随着单星计算载荷功率持续提升、星座组网规模不断扩大,太空算力基础设施有望从当前的百千瓦级单星系统,逐步向兆瓦级乃至更大规模的集群化系统发展。在这一过程中,热控系统将从以单星独立温控为主,向星座级协同热管理演进——通过共享各节点的功耗、温度及设备健康状态等信息,结合AI训练与推理任务的负载预测和调度,提前优化热控运行策略,协调不同节点的功耗分配与散热能力,在满足芯片温度约束的前提下提高整体算力资源的利用效率。
向模块化、冗余化和系统级故障管理演进:随着商用太空算力星座逐步走向规模化运营,热控系统需要满足长期在轨运行、低人工干预和高可用性的要求。其设计理念将从侧重单点部件可靠性,进一步向模块化、冗余化和系统级故障管理演进。未来,具备自主感知、智能调节和健康管理能力的空间热控系统,将成为支撑太空算力基础设施长期稳定运行的重要技术保障。