AI 的废热,得找个邻居
BBC 报道的 Exmouth 游泳池案例,正好可以作为 AI 基础设施的一个试金石:废热只有当算力需求和热需求放在一起时,才能真正变成可持续资产。
AI 驱动 · 每小时限 20 次请求

这篇 BBC 关于 Exmouth 休闲中心的报道 之所以让人印象深刻,其实是规模。一台洗衣机大小的数据中心,电脑泡在油里,配上热交换器,就能把公共泳池的水加热到大约 30°C,一年里大约六成时间靠它供热。Deep Green 把设备免费提供给这家市政休闲中心,算力卖给客户,还告诉 BBC 会报销设备运行的电费。
我的看法是,这比大多数 AI 基础设施的公关稿更站得住脚,因为物理过程和买单方都看得见。泳池需要热,服务器在产热。难点不在口号,而在于:到底有多少真实的算力需求,能放到附近有人能用掉这些热量的地方。
答案快照
| 问题 | 我的看法 |
|---|---|
| 发生了什么? | BBC News 报道,Deep Green 在 Exmouth 休闲中心部署的小型数据中心,用矿物油冷却和热交换器为泳池供热。 |
| 为什么重要 | 它把数据中心的废热变成了本地供暖输入,而不是只把热量当作一个散热问题来处理。 |
| 谁受益? | 休闲中心这类有稳定热需求的场所,以及愿意使用分布式高性能计算方案的算力客户。 |
| 限制在哪 | 泳池能免费用热,前提是算力端有付费负载;服务器不够时,泳池仍然需要备用热源。 |
| 我的观点 | AI 废热只有当算力需求和热需求被设计成邻居时,才会变成真正有用的基础设施。 |
巧妙之处在于管道
基础工程其实非常朴素。BBC 描述的是一个白色箱子里的电脑泡在油中,热油被泵过热交换器来加热泳池水。CIBSE Journal 的案例研究补充了有用的细节:Exmouth 的安装用的是浸没式冷却,整台电脑泡在油里散热,而不是靠冷风吹;管道也做了保温,让更多热量被回收利用。
这一点很重要,因为它让这个想法不至于听起来像魔法。数据中心仍然在耗电,几乎所有电能最终都变成了热。区别在于,这些热量被送进了休闲中心本来就要加热的水里,而不是像传统散热方案那样直接排到空气中。
CIBSE 报告预计未来一年能节省 22,000 英镑的供暖费用,Ars Technica 的报道则给出约 20,000 英镑的预期节省,并提到 Deep Green 声称泳池的燃气供暖用量减少了 62%。我不会把这些数字当作普遍结论,但会把它们当作特定场景下的证据:在合适的条件下,这些废热确实大到值得认真对待。

游泳池是理想的用热方
泳池比含糊其辞的"社区福利"更像一个真实的热需求买家。它本来就潮湿,本来就有管道,本来就在为供暖买单,能源涨价时也首当其冲。BBC 文章提到,Exmouth 休闲中心预计当年能源账单将增加 100,000 英镑,并把这件事和一个更大的压力点联系起来:BBC News 此前报道,自 2019 年以来已有 65 家游泳池关闭,能源成本上涨是重要原因之一。
但这并不意味着服务器箱子可以替代供暖系统。Ars 指出,泳池仍然保留了燃气锅炉,在需要时用来补温。这个限定反而让故事更可信。诚实的说法不是"服务器可以到处取代锅炉",而是"在某些场景下,当算力和热负荷放在一起时,可以抵消相当一部分热需求"。
这也是我觉得公共叙事常常过于顺滑的地方。废热再利用不等于零影响计算。更准确的说法是"一热两用":既然这些计算本来就要发生,不如把设施设计成让废热去替代本地供暖输入。
商业模式是最脆弱的一环
Deep Green 自己的模式依赖于卖算力。BBC 说这家公司向客户收取用于 AI 和机器学习的计算资源费用。TNW 后来的报道提到,Deep Green 在获得 Octopus Energy 投资后,计划扩展到 100 到 150 个游泳池,但也引用了公司的说法:需要更多企业放弃传统数据中心,转而使用他们的服务器,才能把热量送给社区。
这是我觉得最关键的限制。用热方可能很开心,但系统能运转,并不是因为泳池有闲置空间。它成立的前提是 Deep Green 能持续让服务器跑满那些适合这种部署模式的负载。一篇围绕 Ars 文章的 Hacker News 讨论也浮现了同样的担忧:评论者在问,谁会买这种小规模、本地化的托管算力?Deep Green 又能不能聚合到足够多的分布式算力需求?
我不认为这种质疑能否定这个想法,但它把执行门槛摆到了台面上。一个分布式数据中心网络,得卖出可靠性、支持、安全、连接性、硬件维护和负载适配能力。废热的故事也许能吸引注意力,但算力客户买的终究还是基础设施。

AI 的背景让这件事不再小众
这篇 BBC 报道最初发于 2023 年 3 月,当时读起来像一个聪明的地方能源小方案。到了 2026 年,它更像是一个更大基础设施问题的早期版本。Deep Green 现在的官网已经把公司定位转向 AI 和高性能计算的协同部署,并在曼彻斯特有实际运营的站点。官网称其 DG01 曼彻斯特站点为 Move Urmston 休闲中心供热,每年节省约 80,000 英镑的社区供暖费用,减少 100 到 150 吨二氧化碳排放。
这件事之所以重要,是因为数据中心需求已经不再是一个背景性的技术问题。国际能源署的 Energy and AI 报告指出,2024 年数据中心约占全球电力消耗的 1.5%,即 415 TWh,并预计到 2030 年数据中心用电量将翻倍以上,达到约 945 TWh。同一份报告也强调,本地层面的影响可能远比全球占比所显示的更为显著。
正因如此,废热再利用不应该被当作全部答案。它只是更大能源问题中的一个设计杠杆。把算力放在有用的热负荷附近,可以减少浪费,但不会抹掉电力需求、电网约束、资本开支,或者供电本身的碳排放结构。
距离和温度决定了大半
最有力的质疑,不是说废热是假的,而是说废热往往很别扭。Ars 的报道很好地概括了这个更大的挑战:热量的分配可能涉及成本、本地区域供热的接入条件、技术限制,以及用热方可能还需要热泵,因为可用的热量本身温度并不总是够高。物理距离很重要,热流的温度同样重要。
这也是为什么泳池这个例子异常干净。休闲中心有持续的水循环、很大的热容量,以及一个可以稳定接受热量输入的供暖负荷。换一个远处的住宅项目、一片办公区,或者一个季节性用热方,难度可能大得多。同一台服务器的热量输出,在一栋楼里可能很有价值,跨过某条边界就几乎没用了。

我的结论
我喜欢 Exmouth 这个故事,因为它把一个巨大的 AI 能源争论,缩成了一个具体的循环。它不再泛泛地说数据中心应该可持续,而是在问:一台服务器箱子,能不能坐在一个真实的热负荷旁边,减少一张真实的账单。
但我不会把它包装成通用解法。更务实的教训是:把算力放到废热有买家的地方,证明负载是真实的,保留备用系统并如实交代,在现场测量净结果。如果 AI 的扩张还要继续把发热的机器塞进一栋栋建筑,那最站不住脚的回答,就是假装热量会自己消失。更有用的回答,是为它设计合适的邻居。
许可
新闻文本 © 2026 Mark Huang。 新闻文本可在非商业场景下分享或翻译,但需署名并链接到 https://markhuang.ai/zh/news/ai-heat-needs-a-neighbor.
建议署名: 基于「AI 的废热,得找个邻居」(作者:Mark Huang),原文发布于 https://markhuang.ai/zh/news/ai-heat-needs-a-neighbor。
相关新闻
Hy3 把价格写进了评测
腾讯 Hy3 的发布最值得关注的是一次成本与工作流的押注:开源权重、长上下文、低价路由能否成立,取决于 Agent 在腾讯自家评测之外是否依然可靠。
AI 记账需要一套管控框架
Toot 的 GLM 5.2 VAT 基准测试是 AI 记账领域一个认真信号,但我认为,只有当产品核心是异常路由、审计证据、确定性校验和人工升级时,便宜的准确率才真正有意义。
Bun 的 Rust 重写,是一场验证考试
Bun 团队把运行时从 Zig 迁到 Rust,并用 Claude 跑了一套 AI 辅助的动态工作流。这个故事最值得拆的不是速度本身,而是他们怎么验证这次迁移:测试套件不删不改、对抗性审查、模糊测试、灰度发布、unsafe 代码收敛——这些环节撑不撑得住,才是 AI 辅助大规模移植能不能落地的真正判据。