Elice 规划温水 AI 数据中心并推出 Helpy Code

Elice 凭借两项“首次”登上 Google News：拟建设温水 AI 数据中心，以及其 Helpy Code 代理正式公开亮相。这家韩国公司计划部署 2,560 块 Nvidia B300 GPU，并配套可在企业私有环境中运行的软件。

这一组合的重要性超过任何一项单独公告。Elice 正将自己定位为一体化韩国 AI 技术栈的运营商，覆盖冷却管路、云端编排、企业知识以及生成代码。

这一战略也带来了严峻考验。高效 GPU 基础设施本就难建，而赢得开发者对编码代理的信任，则涉及另一套技术与商业难题。Elice 必须证明自己两者兼备。

该数据中心尚未通过公开的生产环境测量数据证明其承诺的运行效率。Helpy Code 也缺乏独立发布的基准测试、采用数据或详尽的模型披露。因此，这一故事讲述的是一项雄心勃勃的整合计划，而非已经完成的胜利。

Elice AI 数据中心究竟带来了哪些变化

Elice 正从运营较小型的模块化设施，迈向建设一座由政府支持、围绕高密度 Blackwell Ultra 硬件打造的集群。

8 月 4 日，Elice 表示已入选韩国政府一项旨在扩大国家 AI 算力的计划。韩国科学技术信息通信部与国家 IT 产业振兴院正主导该计划。

根据计划，该公司将建设并运营四个便携式模块化数据中心单元。每个单元将配备 640 块 Nvidia B300 GPU，合计 2,560 块 GPU。

便携式模块化数据中心将计算、电力、冷却和安全系统集成在预制模块之中。运营商可分阶段部署容量，而不必在现场一次性建成传统设施的全部组成部分。

Elice 表示，其模块化方式可缩短部署周期，并提升未来扩展的灵活性。不过，8 月的公告并未披露最终选址、施工时间表、电力容量或预计投产日期。

规划中的冷却系统是核心特征。根据该公司的冷却公告，该设施将循环温度达到或高于 40 摄氏度的冷却液，并利用室外空气排出热量。

温水冷却听起来有些反直觉，因为这种液体摸起来可能会让人觉得热。不过，它的温度仍远低于处理器运行温度，因此依然能够从服务器组件吸收热量。

更高的冷却液温度可减少将水冷却至远低于室外温度的需求。在适宜的天气与负载条件下，这一差异可减少压缩机的使用，降低冷却用电量。

该设计将采用直接液冷（DLC）。在 DLC 系统中，冷却液通过贴近高发热组件的冷板流动，而非主要依赖机房空气。

Elice 表示还开发了一种用于控制泄漏风险的分离式管路设计。这一点很重要，因为处理器、电力系统和网络设备附近存在液体，会带来风冷所没有的维护风险。

该公司的目标是将电能使用效率（PUE）控制在约 1.1。PUE 是数据中心总用电量与 IT 设备耗电量之比。1.1 意味着计算设备每消耗十个单位的电量，冷却及其他开销额外消耗一个单位。

目标并不等同于经审计的年度结果。PUE 会随利用率、室外温度、设施边界、冗余方案和测量方法而变化。

因此，必须等 Elice 的 B300 系统在持续的客户工作负载下运行后，才能评判这座 AI 数据中心。调试数据将比设计目标本身揭示更多信息。

该项目扩展了 Elice 已向韩国机构推广的模块化方案。其现有设施已支撑云计算、教育和研究工作负载，但拟议中的 B300 部署运行在完全不同的密度级别。

Nvidia 的参考架构表明了这一变化为何必要。一台 GB300 NVL72 机架的功耗最高可达 142 千瓦，并采用机架级液冷。

这种密度使冷却不再只是建筑配套服务，而成为计算架构的一部分。流量、冷却液温度、泵、热交换器、泄漏检测和软件监控，都可能影响可用 GPU 容量。

因此，该项目并非只是又一笔加速器订单。Elice 正围绕新一代计算的散热要求重新设计其物理基础设施。

为什么温水再次成为 Google News 关注焦点

温水冷却并非新发明，但不断上升的机架密度已将其从效率实验转变为部署要求。

Elice 宣称中的“首次”，适用于韩国 AI 数据中心的一个特定类别。不应将其理解为全球首次采用温水计算。

研究人员和超级计算机运营商多年来一直在测试类似设计。IBM 的 Aquasar 原型机循环温度最高达 60 摄氏度的冷却液，并将回收的热量用于建筑供暖。

由此产生的 Aquasar 研究报告称，热水无需传统制冷即可带走处理器热量。该项目还在该装置中实现了 80% 的热回收效率。

IBM 后来还使用温水入口冷却 Summit 和 Sierra 超级计算机中的 CPU 和 GPU。这些系统针对高密度组件采用直接水冷，同时为低密度硬件采用风冷。

这些先例并不能验证 Elice 的具体设计。它们只是说明，温水冷却拥有可信的工程发展史，并非单纯的营销标签。

Google News 的重新关注反映了规模上的变化。AI 服务器如今在每个机架内集中更多电力，产生的热量仅靠空气已难以高效转移。

风冷首先将芯片热量传递给服务器内部气流。设施风扇随后再将热空气送往冷却设备，增加了多个热传递与机械步骤。

直接液冷缩短了这一路径。水的传热效率也高于空气，使运营商能以更低的风扇功耗移除集中负载。

美国能源部的冷却指南解释称，液冷系统会将服务器热量转移到闭环系统中，再经由冷却液分配单元处理。与实现相近散热量所需的风扇相比，泵通常耗能更低。

温水还带来另一项潜在效率收益。可接受更高冷却液温度的设施，有更多机会通过室外空气排热，无需运行高耗能的冷水机组。

IBM 与美国能源部联合进行的一项测试展示了这一潜力。其长期研究让一座无冷水机组的温水设施连续运行超过 60 天。

研究人员称，该研究期间的平均冷却能耗相当于 IT 能耗的 3.5%。这一结果来自受控测试设施，因此不能直接套用于 Elice 规划中的集群。

韩国的气候也使比较更为复杂。炎热潮湿的夏季条件会减少仅依靠室外空气即可满足全部冷却负载的时长。

设施设计必须在这些困难时段避免 GPU 降频，同时还需管理水质、腐蚀、泵故障、冷却液压力及不断变化的服务器配置。

用水量是另一项差异。温水运行可以降低冷水机组的用电量，但并不自动意味着设施无需用水。

最终的用水足迹取决于排热设备。干式冷却器、冷却塔、混合系统以及当地气候条件，会在电力与用水之间形成不同取舍。

Elice 的公告说明了温水和室外空气冷却，但未提供预期用水效率数值、余热利用计划，或其排热系统的完整描述。

这些缺失并不会否定该项目。它们意味着，其环保标签的范围仍大于公开可得的运行证据。

如果 Elice 能全年维持 1.1 的 PUE，那么设施开销将相对有限。然而，PUE 并未说明电力的碳强度，也未说明耗水量。

因此，Elice 论点中最有力的版本是较为有限的：温水冷却可减少用于搬运热量的能源，尤其是在室外条件支持无压缩机运行时。

较弱的说法则是将一项设计选择视为设施环境表现更优的证明。要得出这一结论，需要 Elice 尚未公布的年度能源、用水、利用率和排放数据。

Helpy Code 将私有知识接入计算技术栈

Elice 正将基础设施扩张与一款编码代理结合，旨在将敏感代码和组织上下文保留在受控环境中。

8 月 18 日，Elice 将 Helpy Code 作为其 Elice AX 企业软件产品组合的一部分推出。该公司同时展示了 Helpy Context、Helpy Vision 和 Helpy Chat。

Helpy Code 是代理，而非基础的代码自动补全功能。编码代理可在用户监督下检查代码仓库、规划改动、生成文件，并执行多步骤开发工作。

现有公告并未详述其支持的全部代码仓库、编程语言、模型或开发环境，而是强调部署架构以及对内部知识的访问。

Elice 表示 Helpy Code 可在本地部署，这意味着组织可在自身控制的基础设施内运行它。该设计面向不能随意将源代码发送至外部服务的企业和公共机构。

该代理整合了 Elice 的另外两个组件。Helpy Vision 可将文档、图表和表格转换为软件可处理的结构化信息。

Helpy Context 将文档、人员、项目和权限组织成知识层。Elice 将其描述为内部本体，即组织概念及其关系的结构化地图。

这些系统结合后，旨在让 Helpy Code 获得的不仅是代码仓库访问权限。该代理在准备代码改动时，还可检索架构政策、项目归属、内部标准和技术文档。

这种上下文的重要性可能不亚于模型能力。一个技术上有效的补丁，仍可能违反公司的部署规则、命名规范、安全政策或未被记录的服务依赖关系。

Elice 表示，基于角色的访问控制决定代理可检索哪些知识。该公司还表示，信息可保留在客户环境内部。

这些是公司声明，并非独立的安全研究结论。Elice 尚未发布 Helpy Code 的威胁模型、外部渗透测试，或关于生成式操作如何隔离的详细说明。

该公司还声称，该智能体的运行成本低于前沿模型的五分之一。这一比较缺乏足够的公开方法论，因而无法评估。

目前仍不清楚其中纳入了哪些模型、工作负载、Token 用量、基础设施开支或人工成本。因此，这一数字应被视为 Elice 的市场定位，而非已确立的经济结论。

重要的产品理念并不依赖于这个数字。Elice 试图销售的是一套纵向整合的系统：本地基础设施支撑本地模型、企业知识与能够采取行动的智能体。

其 AX product suite 将 Helpy Code 与文档分析和知识结构化连接起来。这种架构面向的客户，其对编程智能体的主要顾虑在于控制能力，而非原始性能。

一家受监管的公司可能需要限制哪些模型能够接收源代码。它也可能需要日志来显示智能体读取了哪些文件、执行了哪些命令。

公共机构可能还面临额外的主权要求。它们可能需要本国托管、受控的网络访问，以及围绕敏感数据集设定清晰边界。

Elice 的云业务和模块化数据中心业务，使其在这类销售沟通中占据了不同寻常的位置。该公司可以通过同一合作关系提供实体算力容量、云编排和应用软件。

这种整合类似于在更大组织尺度上构建的 searchable knowledge base。当编程智能体能够检索可信的技术上下文，而不是根据孤立文件猜测时，它们会变得更有用。

这种关系也可以反向成立。Helpy Code 和其他智能体能够为 Elice 的 GPU 云、存储、网络和数据中心容量创造需求。

这一反馈循环才是两项公告之间真正的战略联系。设施为智能体提供算力，而智能体则为客户使用该设施的算力提供理由。

Elice 正在以一体化技术栈挑战专业厂商

主要竞争在于一体化控制与可由客户从多家供应商组合的专业化服务之间的较量。

Elice 进入的并非一个空白的编程智能体市场。开发者已经可以使用由大型模型提供商、云平台和软件开发公司支持的产品。

这些服务受益于广泛的分发渠道、频繁的模型更新和庞大的开发者社区。其中一些还与主流代码仓库、编辑器、问题跟踪器和部署系统深度集成。

Elice 不能假定拥有基础设施就能带来更好的编程体验。开发者将通过补丁质量、延迟、工具可靠性、审查负担以及与既有工作流的兼容性来评判 Helpy Code。

该公司的优势有所不同。Elice 可以主张，客户无需自行拼装模型网关、私有云、文档解析器、知识层和编程界面。

其 full-stack strategy 还包括 ECI——一项用于配置 GPU 和 NPU 资源的基础设施服务。ECI 支持虚拟机、存储、网络、监控和自动化基础设施管理。

这为韩国企业形成了一个连贯的销售叙事。Elice 可以部署模块化设施，编排其加速器，结构化私有信息，并在其上部署智能体。

专业化方案为客户提供更多选择。组织可以分别为基础设施、基础模型、检索、安全和开发者工具选择不同供应商。

这种灵活性可以降低对单一供应商的依赖，也让团队能够替换薄弱组件，而无需迁移整个系统。

一体化改变了这种权衡。一家供应商可以简化责任划分和数据治理，但客户也会更容易受到其技术路线图和运营稳定性的影响。

Elice 必须证明其整合能够带来可衡量的收益。如果每个产品都落后于专业替代方案，仅仅列出一串互联产品还不够。

作为这一技术栈的一部分，Helpy Code 具有三项看似合理的优势：它可以将选定数据保留在本地区域内，检索受治理的内部知识，并运行在为客户配置的基础设施上。

每一项优势也都带来疑问。区域内处理取决于实际的模型路由，而不只是用户界面的位置。

知识检索取决于文档质量、权限和时效性。本地部署则依赖能够维护模型、索引、智能体运行时和安全控制措施的管理员。

基础设施方面也存在类似的权衡。便携式模块可以减少施工工作，但模块化建筑仍然需要电力连接、网络、许可、维护通道和散热条件。

三个月的模块组装声明，并不保证三个月内即可提供服务。电网并网和加速器交付可能决定真实进度。

Elice 还高度依赖 Nvidia 的硬件路线图。其规划中的集群采用 B300 GPUs，而未来设计预计将使用密度更高的 Vera Rubin 系统。

这种对齐使其能够接入被广泛采用的计算平台，同时也让 Elice 面临产品迭代、供应限制和机架需求快速变化的风险。

该公司讨论过将基于 Ethernet 的集群作为以 InfiniBand 为中心设计的替代方案。Ethernet 可以提供更广泛的供应商选择，但大型训练集群需要谨慎的拥塞控制和运营调优。

因此，购买一体化技术栈的客户，实际上是在购买 Elice 跨越多个层级的工程判断。网络、冷却、检索或智能体安全的任何一环失效，都可能削弱整个方案。

这也是 Elice 的战略所施加压力不止于其他韩国云服务商的原因。它同样挑战那些预期企业会通过海外公有云使用编程智能体的软件供应商。

结果不会由谁发布了最长的产品清单决定。它取决于一体化控制能否在不制造运营摩擦的情况下，提升安全性、成本效率和开发者产出。

Google News 标题未能证明什么

该标题将两项有前景的公告合并在一起，但二者均尚未达到公开证据能够支持最宽泛解读的程度。

温水设施目前仍是一个建设和调试项目。Elice 已公布 GPU 数量、冷却方式、模块化布局和目标 PUE，但尚未公布生产遥测数据。

读者还应将“South Korea’s first”视为公司框定的类别性声明。这一表述取决于如何定义 AI 数据中心和温水部署。

此前韩国的研究或高性能计算设施，可能采用了相关冷却技术，但未必与 Elice 的商业模块化配置相同。公开报道尚未建立一份全面的全国性清单。

“build”一词还存在另一层歧义。Elice 表示将通过政府支持的项目建设并运营该设施，但其公告没有给出完成日期。

GPU 分配并不等于可用计算容量。服务器必须通过验收测试，网络必须能够支撑分布式工作负载，冷却系统也必须在不同利用率下保持性能。

PUE 同样很容易被过度解读。1.1 的目标表明配套基础设施较为高效，而非 AI 模型本身高效，也不代表客户利用率高。

即使冷却表现出色，闲置设施仍可能浪费资本。即使设施繁忙，如果其电力来自高排放的发电方式，仍可能具有较大的碳足迹。

Helpy Code 面临的是另一种验证缺口。Elice 尚未发布可在不同编程智能体间比较的基准测试，也未公布企业部署中的任务完成率。

软件工程基准测试同样存在局限。它们可以衡量智能体是否解决了选定的代码仓库问题，却未必能反映安全性、可维护性或人工审查所需时间。

更重要的证据将来自生产团队。有效指标包括被接受的补丁、被回滚的改动、审查时长、事故率和节省的开发者时间。

安全声明同样需要具体说明。本地部署可以减少向外部服务传输数据，但并不能消除所有风险。

智能体可能访问超出任务预期范围的文件，可能执行不安全的命令、通过日志暴露机密，或遵循嵌入文档中的恶意指令。

基于角色的检索控制只有在权限准确时才有帮助。组织往往因旧有协作系统而存在文件所有权不一致和访问权限过宽的问题。

Helpy Context 必须在保持信息最新的同时维护这些边界。否则，Helpy Code 可能依据过时指南采取行动，或向错误的开发者泄露资料。

模型来源是另一个尚未解决的问题。Elice 表示该系统可以支持安全的企业环境，但其公开公告并未说明 Helpy Code 默认使用的模型。

客户需要知道提示词是否会到达第三方端点、推理日志存储在哪里，以及其数据是否会影响后续模型训练。他们还需要能够更换模型提供商的控制机制。

这些问题并不是否定该产品的理由。它们是将受控演示与生产采用区分开来的实际要求。

公告的时间安排同样值得谨慎看待。Elice 将数据中心公告标注为 8 月 4 日，将 Elice AX 公告标注为 8 月 18 日。

8 月 18 日的公告称，公司将在 6 月 19 日至 6 月 21 日举办的 AI Summit Seoul & Expo 展示其产品。这一日期顺序使人不确定英文公告是否是在相关活动之后才发布。

公开记录仍然能够确认产品名称和 Elice 所述的架构。它并不支持在没有限定的情况下，将每个公告日期都视为实际首次演示日期。

因此，Google news 读者看到的是一个被压缩的叙事。其背后的故事由独立的基础设施和软件项目构成，而 Elice 正有意将它们呈现为一项统一战略。

这一战略值得持续关注。其最重大的声明仍有待衡量。

三个信号将显示 Elice 能否兑现承诺

调试结果、Helpy Code 部署情况和客户工作负载数据，将决定 Elice 是否真正建立了一门业务，还是只画出了一张有说服力的示意图。

第一个信号是 2,560-GPU 集群获得确认的运营里程碑。Elice 应说明全部四个模块何时投入生产，并公布持续负载下的测量结果。

年化 PUE 将比短期调试结果更具参考价值。耗水量、冷却液温度、设备可用性和天气条件也能提供必要背景。

若持续表现接近 1.1，将强化 Elice 的冷却论点。重大延误、对冷水机的大规模依赖，或可用 GPU 容量较低，都将削弱这一论点。

第二个信号是来自 Helpy Code 部署的证据。该公司无需披露客户源代码，但可以公布匿名化的运营指标。

有用的证据包括已完成任务、补丁接受率、审查时间、失败率和安全干预情况。独立客户的说明将比演示脚本更具分量。

Elice 还应说明 Helpy Code 的模型架构和数据路径。采购方需要清楚了解模型选择、本地推理、外部端点、权限和审计日志等问题。

在受监管企业内部实现生产级采用，将支持其一体化控制的论点。仅开展有限试点而未形成持续使用，则意味着私有化部署本身不足以克服工作流程中的阻力。

第三个信号是 Elice 全栈产品的利用率。该公司必须证明，客户正将其 GPU 用于持续的训练、推理或智能体工作负载。

高利用率将把数据中心投资与真实需求联系起来。这也将检验 ECI 能否在维持网络、存储和散热性能的同时调度大型集群。

低利用率则会暴露基础设施扩张中的核心风险。加速器迭代很快，而供电和散热系统需要长期资本投入。

客户还应关注 Elice 是否能赢得政府支持项目之外的工作负载。公共项目能够创造有价值的国家级算力，但商业需求更能直接检验定价和服务质量。

竞争对手的反应也是这一信号的重要组成部分。韩国电信集团、云服务商和系统集成商可以将本土基础设施与第三方编程智能体结合起来。

全球供应商同样可以强化私有化部署和区域处理选项。这些举措将削弱 Elice 一体化方案的独特性。

Elice 不必击败每一家专业供应商。它需要让数据边界严格的客户更容易治理和运营这一整套系统。

对于开发者而言，眼下的问题很实际：Helpy Code 是否足够了解组织情况，能够减少审查工作，同时又不会获得过多访问权限？

对于基础设施采购方而言，问题可被量化：温水模块化散热能否让 B300 集群在完整运营年度内保持可用和高效？

对于知识团队而言，挑战是基础性的。当文档、权限和所有权仍然混乱时，智能体便无法可靠地使用私有上下文。

最新的 google news 关注为 Elice 带来了曝光度，但曝光度并不能解答这些问题。下一次有意义的更新应包含运营证据，而不是又一组产品标签。

关注首批生产模块、首个由独立方描述的 Helpy Code 部署案例，以及首批持续利用率结果。这些信号结合起来，将显示 Elice 的韩国一体化 AI 技术栈是否能在展会现场之外真正发挥作用。