散热太空辐射成本「写一首关于身处太空的俳句。」几天前谷歌的工程师通过地面站将这样一条提示词发送给了运行在地球轨道上的卫星。收到指令后卫星搭载的 TPU 启动预先部署的 Gemma 4 开始执行推理任务。随后当卫星飞经挪威斯瓦尔巴群岛附近时地面站终于收到了来自太空的回复。Blue marble below蓝色星球在下Data streams in silent grace数据悄然流转Starlight feeds my core.星光供养我的核心不久前谷歌 CEO Sundar Pichai 兴奋地分享了这一消息并将其称为 Project Suncatcher 的「Hello World」时刻。这也是数据中心级 TPU 首次在轨道上生成并回传完整的 AI 响应。从去年宣布要把 AI 算力送上太空到如今真的收到来自轨道上的一首诗谷歌的太空数据中心计划终于迈出了实际运行的一步。谷歌 TPU真的在太空跑起来了这次实验的起点要追溯到一个月前。10 月 1 日谷歌与卫星公司 Planet 合作研制的 Project Suncatcher 原型卫星搭乘 SpaceX 的 Transporter-18 拼车任务进入地球轨道。在此后的数周里工程团队陆续完成卫星各个系统的调试启动主机及 TPU 计算设备并开展早期机器学习测试。直到本周团队终于尝试让卫星执行一次真正的生成式 AI 任务。完成首次响应后团队还尝试让模型生成其他形式的太空主题诗歌并通过自然语言提示词查询计算载荷的技术状态。谷歌表示后续实验将逐步转向更加实际的系统测试以观察 TPU 在轨道热应力和辐射环境下的表现。据 TechCrunch 报道这颗原型卫星搭载了四颗 Google TPU最高可以提供约 1kW 的电力但由于当前系统的供电限制每次只能启动其中一颗 TPU运行时间约为 20 分钟。这也让人想起一年前谷歌刚刚提出这一计划时的情景。2025 年 11 月我们曾在 AI 太空竞赛英伟达 H100 刚上天谷歌 Project Suncatcher 也要将 TPU 送上天中介绍过这一项目。按照最初公布的安排谷歌计划在 2027 年初与 Planet 合作发射两颗原型卫星测试 TPU 在轨运行以及星间光通信等关键技术。此后谷歌进一步调整了实验进度利用 Planet 的卫星平台提前开展第一阶段验证并在今年 10 月成功将 TPU 送入轨道。谷歌也并不是第一家将大模型带入太空的公司。去年 11 月初创公司 Starcloud 就把一颗搭载英伟达 H100 GPU 的 Starcloud-1 卫星送入轨道并在随后完成了大语言模型运行以及基于 nanoGPT 的小型模型训练实验。今年 8 月SpaceX 与英伟达又宣布合作开发 Starmind AI1计划使用 Rubin GPU 和 Vera CPU 构建更大规模的卫星计算载荷。从英伟达 GPU 到谷歌 TPU太空 AI 计算正在吸引越来越多科技公司参与。从一颗 TPU到真正的太空数据中心为什么要如此大费周章把 AI 芯片送上太空这个问题在过去一年里反复出现在各家公司的评论区。其实答案很简单就是电力供应。根据谷歌此前公布的研究结果在适当的轨道条件下太空太阳能电池板的发电量最高可以达到地面条件的约 8 倍。如果卫星运行在晨昏太阳同步轨道上还能够获得接近持续的日照甚至不用过多依赖大型电池。围绕这一目标Project Suncatcher 采用的并不是建造一座大型空间站式数据中心的思路而是让大量相对小型的卫星组成紧密编队每颗卫星都搭载太阳能电池板和 TPU再利用自由空间光通信技术把它们连接起来。在谷歌此前发表、现已发表于《Joule》的研究论文中团队展示了一个由 81 颗卫星组成的编队设计示例。这些卫星运行在平均高度约 650 公里的近地轨道上整个集群半径约为 1 公里部分相邻卫星之间的距离会在约 100 至 200 米的范围内变化。为什么要让卫星飞得这么近简单来说就是方便通信。在地面数据中心大规模模型训练通常需要把任务分配给许多加速器共同完成而不同芯片之间又必须频繁交换中间计算结果。如果通信带宽不足或延迟过高即使拥有足够多的计算芯片整个系统的性能也可能受到严重限制。谷歌希望将类似的分布式计算方式搬到太空因此卫星之间需要建立远高于传统卫星通信需求的带宽连接。根据团队的研究未来要实现与地面数据中心相近的计算能力星间链路的传输速率需要达到 10 Tbps 。为了接近这一目标谷歌正在研究利用密集波分复用和空间复用技术提高激光通信带宽同时让卫星以相对紧密的编队运行。此前的地面实验中团队已经通过一对光通信收发设备实现了单向 800Gbps、双向合计 1.6Tbps 的传输速率。这是相当可观的数字但距离未来所需的星间通信能力仍有差距而且地面设备之间的通信与多颗卫星在轨道上持续高速运动时保持稳定连接也完全不是同一种工程难度。为了让数十乃至上百颗卫星长期保持合适的相对位置谷歌还需要考虑地球非球形引力场、大气阻力以及轨道摄动等因素并通过物理模型和机器学习方法辅助编队控制。与此同时卫星之间的数据交换只是问题的一部分地面与卫星之间的数据传输问题更难解决。特别是对于需要频繁读取大量地面数据、更新模型参数或响应用户请求的任务如何在通信窗口、传输带宽和延迟之间取得平衡同样会影响实际运行效率。相比之下在轨处理地球观测卫星产生的数据如果能够在轨道上直接完成图像分析再将结果而不是全部原始数据传回地面就有机会减轻下行通信负担。这是太空计算最有优势的领域。不过谷歌的目标显然不止于此。它想验证的是未来是否能够在太空中形成真正具有规模化能力的 AI 计算集群。这种构想也遭到不少网友质疑。此前 Reddit 的 r/space 社区中有人专门提出一个问题既然太空数据中心的建设和维护如此困难为什么不把数据中心放在海底这一问题并非没有现实基础。微软此前开展的 Project Natick 就曾验证水下数据中心的运行可行性而在冰岛、北欧等寒冷地区建设数据中心也已经是降低部分冷却负担的一种现实选择。上太空的问题在于即使能够在太空中获取更多太阳能所能提供计算能力真的值得这样大费周章吗答案显然还没有那么简单。散热太空辐射成本10 月 30 日的消息公布后X 上围绕太空数据中心可行性的讨论再次出现。用户 Luke Leisher 颇为讽刺地表示「这怎么可能互联网最聪明的人不是告诉我物理定律已经决定轨道数据中心完全不可能实现了吗」另一位用户 Robert de Negro 则提出了一个更具体的问题真正的难点可能是规模。假如一颗卫星最终要搭载大量计算设备那么管理数十甚至数百颗芯片产生的热量与管理少量芯片完全是两回事。说到底太空中的散热还是绕不开的问题。在地球上计算设备可以通过空气流动、液体冷却等方式带走热量热量最终再通过相应设施排向周围环境。但在接近真空的太空中没有可供利用的空气对流芯片产生的废热最终主要依靠热辐射向外释放。这意味着太空数据中心必须通过导热结构和冷却工质将计算设备产生的热量传递到具有足够面积的散热器再以电磁辐射的方式排出。谷歌此前介绍过一套结合热管和散热器的冷却方案并已经在模拟太空热环境的热真空实验舱内进行了测试。虽然这种技术路线在航天领域并不陌生但随着计算设备的功率不断增加散热系统的面积、质量以及与其他卫星设备的结构关系都必须重新设计。目前 Project Suncatcher 的原型卫星搭载四颗 TPU却还只能一次启动一颗、持续运行约 20 分钟正说明现阶段的功率和热管理能力距离大规模持续计算仍有很大提升空间。而且散热问题最终又会回到成本上。在 Hacker News 的相关讨论中一些网友认为争议并不在于人类是否知道如何通过热辐射散热而在于为了排出足够多的热量需要增加多少散热器、导热管路和其他配套设备。一旦这些额外重量被计算进去卫星的发射成本也会随之上涨。另一个需要长时间验证的问题是太空辐射。对于依靠太阳能发电的卫星来说太阳光是重要的能源来源但太阳高能粒子、银河宇宙射线等辐射环境也可能影响电子设备。高能粒子与芯片中的敏感区域发生相互作用时可能造成存储器中的数据位翻转导致原本的 0 变成 1或让某些计算结果出现错误。对此谷歌此前已经开展过专门的地面实验。研究团队使用 67MeV 质子束测试了第六代 Trillium TPU观察总电离剂量和单粒子效应对芯片的影响。结果显示高带宽内存系统是较为敏感的部分但相关异常直到累积剂量达到约 2krad (Si) 时才开始出现接近有屏蔽条件下预期五年任务剂量的三倍。在单颗芯片最高 15krad (Si) 的测试剂量下团队也没有观察到能够归因于总电离剂量的永久性硬故障。这样的结果让谷歌对现有 TPU 的太空适应性更加乐观但地面粒子束实验毕竟无法完全模拟真实轨道环境中的长期辐射、热循环和其他复杂因素因此此次卫星任务的重要目的之一正是进一步验证芯片在真实环境下的表现。即使散热和辐射问题都能得到工程上的解决谷歌还必须面对计算设备的长期维护和更新换代。地面数据中心可以随着 AI 芯片性能提升逐步更换旧设备供电、网络和冷却基础设施则能够继续使用。但对于卫星而言芯片、太阳能电池板、散热器和通信系统往往高度集成设备发生故障或计算芯片逐渐落后之后如何继续利用其余基础设施就成为一个复杂的问题。Hacker News 上也有人特别指出太空计算设施可能面临与地面数据中心不同的折旧逻辑如果一颗卫星上的 GPU 或 TPU 已经失去竞争力即使它的太阳能板和散热系统仍能使用也未必容易继续发挥原有价值。这还没有考虑航天器可能遭遇的轨道碎片、微小陨石以及卫星需要定期进行轨道维持、最终离轨处置等额外问题。因此关于太空数据中心的争论最后往往都会落到同一个问题上成本。谷歌此前发表的研究论文中就专门对未来的发射成本进行了分析并给出了一个重要的参考数字 ——每公斤 200 美元。在这一假设下将发射成本按照设备使用寿命和供电功率摊销后可能对应每千瓦每年约 810 美元的成本。作为对照论文引用的美国地面数据中心能源支出约为每千瓦每年 570 至 3000 美元。这么看来太空数据中心有一定的可行性。但谷歌这个计算非常粗糙Reddit 上还有网友一眼就看到问题。「发射成本每公斤 200 美元」谷歌这个计算有个假设前提那就是未来火箭复用能力和发射规模继续提高并能够维持历史上观察到的成本下降趋势。按照论文估算要沿着这一趋势在 2035 年前后达到每公斤 200 美元的成本水平可能需要实现每年约 180 次 Starship 发射的规模。显然是有点乐观估计的成分了。事实上谷歌自己也不傻并没有对太空数据中心的短期商业化抱有期待。今年 10 月 1 日在接受 NPR 采访时Project Suncatcher 项目负责人 Travis Beals 就表示他不认为太空数据中心能够在未来五年内变得比地面更加便宜真正形成经济竞争力可能还需要更长时间。谷歌将 Project Suncatcher 定义为一项长期的「登月计划」接下来按照目前公布的路线谷歌计划在 2027 年发射两颗具备高速光通信能力的卫星进一步验证星间互联以及分布式机器学习任务所需的技术条件。至于将这一系统进一步扩展成真正具有商业竞争力的太空数据中心还需要更长时间的技术积累以及发射成本、硬件可靠性和系统架构等多方面的共同进步。对于谷歌试图建立的太空 AI 计算网络而言这首小诗还只是第一声回应。原文链接史上首次谷歌TPU在轨运行Gemma 4-36氪我的专辑《人工智能生命体 新启点》CSDN平台https://blog.csdn.net/2501_91883294/article/details/147616608?sharetypeblogdetailshareId147616608sharereferAPPsharesource2501_91883294sharefromlink
企业数字化 ERP 产品动态
相关推荐
10 月 27 日那个检查点,把「一次生成成功」从碰运气变成了常态 10 月 27 日那个检查点,把「一次生成成功」从碰运气变成了常态
做 3D 代码生成这件事,评估口径很容易跑偏。社区里几乎所有的讨论都停留在“这图好看不好看”“这次生成的樱花树有没有氛围”——但对于一个输出「单文件 HTML 内联 JavaScript 远程加载… · 2026/11/3 10:47:16
上线一周逼近 3 万次下载:一个只写 3D 场景代码的 4B 模型,凭什么被抢着拉 上线一周逼近 3 万次下载:一个只写 3D 场景代码的 4B 模型,凭什么被抢着拉
最近技术圈有个挺反常的现象。
各家大模型都在拼参数、拼榜单、拼谁更“全能”,动辄千亿级、上万亿级。可这周被开发者疯狂下载的,却是一个只有 40 亿参数… · 2026/11/3 10:47:16
AI大模型别只盯着模型和参数了,AI 智算网络才是你该押注的方向 写给每一个在 AI 浪潮里焦虑的学生和初学者 一、AI 大模型 ≠ 模型本身,它背后还有一张"看不见的网"
现在打开任何技术社区、B 站、公众号,满屏都是:
GPT-5 又来了某某模型参数突破万亿某某框架训练速度又翻倍了LoRA、QLoRA、Mo… · 2026/11/3 10:47:16
Swisslog百年转型:从电气小厂到物流自动化巨头的历程 1. Swisslog百年转型史:从配电小厂到物流自动化巨头的蜕变1900年,瑞士阿尔劳小镇上,两位电气工程师创立了一家名为SprecherSchuh的小型配电设备厂。谁曾想到,这家最初生产电气控制柜的小作坊,会在125年后发展成为全球物… · 2026/11/3 16:35:57
VMware搭建Linux环境全攻略与性能优化 1. 为什么选择VMware搭建Linux环境 在本地计算机上运行Linux系统,虚拟机方案始终是开发者和运维人员的首选。相比双系统安装,VMware Workstation这类虚拟化软件提供了更灵活的解决方案——既能保留原有操作系统,又能获得完整的Linux体验。 我… · 2026/11/3 16:35:57
Prometheus告警规则模板:从资源到应用,告别误报与噪音 告警规则这件事,我见过太多团队栽在同一个坑里:Prometheus 部署得漂漂亮亮,Grafana 大盘也画得有模有样,结果真出故障的时候,要么一条告警都没响,要么半夜被三百条重复通知炸醒,爬起来一看全是同… · 2026/11/3 16:35:57
CAN物理层7项硬核测试实操指南 简介:本资源是一份面向高校电子/车辆工程专业学生及嵌入式开发初学者的CAN总线物理层测试实践文档,聚焦车载通信硬件可靠性验证核心能力培养。文档系统覆盖终端电阻、高低压通信范围、显性/隐性输出电压、上升沿与下降沿时间等7项关键物理层测试… · 2026/11/3 16:35:57
Verilog状态机设计:从题目抽象到可综合RTL的实战指南 1. 从一道“其他状态机题目”说起:为什么这类题总让人卡壳做Verilog笔试题或者课程设计的时候,很多人都有过这种体验:一段式、两段式、三段式状态机写得滚瓜烂熟,交通灯、序列检测、自动售货机这些经典题目也能默写出来࿰… · 2026/11/3 16:35:57
用C++从零手写CNN恶意软件检测:完整实现与踩坑记录 作为一个平时主要用 Python 写深度学习、但偏偏要在某些场景下用 C 把模型落地的人,我对“C 深度学习”这几个字真是又爱又恨。这个系列前面聊了环境搭建和基础张量操作,这篇“第三弹”我想直接来点硬核的:不聊理论推导,而是逐步用… · 2026/11/3 16:34:55
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 13:10:28
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 6:04:24
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 5:52:46
STM32F411RE与MAX14431实现SPI隔离:工业现场抗共模干扰实战 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 1:01:59
ESP32+大模型AI硬件开发:从Demo到产品的8个工程问题 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 1:01:59
基于MAX14431BAEE+与PIC18F85J10的SPI隔离方案设计与实践 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 1:01:59
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 13:10:28
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 6:04:24
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 5:52:46