浪潮构建智能体基础设施：每机架4万个智能体与多模型协同

引言

AI基础设施正在超越单次处理一个模型请求的时代。

一个生产级智能体不仅仅是接受提示并返回答案。它可能将任务分解为多个阶段、调用外部工具、维护上下文、与子智能体协调、审查中间输出，并长时间保持活跃状态。当企业一次性部署数千个这样的智能体时，基础设施需求与普通聊天机器人的推理截然不同。

在北京举行的2026开放计算技术峰会上，浪潮信息为这种新型工作负载提出了两个基础设施方向：

1. CPU原生液冷机架服务器，设计用于在一个机架内支持超过4万个并发智能体。
2. 将元脑SD200超级节点与EPAI多模型融合API相结合，允许多个大模型为复杂任务生成、审查和组合答案。

第一个方向侧重于规模：让大量长期运行的智能体保持在线。第二个方向侧重于质量：允许具有不同优势的多个模型协同工作，而不是强迫一个模型处理困难任务的每个部分。

智能体工作负载带来的不同基础设施挑战

传统的大模型推理通常遵循一个简单的模式：

1. 用户发送一个请求。
2. 模型执行推理。
3. 系统返回一个响应。
4. 会话结束或等待下一个请求。

而一个智能体应用的执行路径要长得多。

一个单一的业务任务可能涉及：

• 规划
• 任务分解
• 检索
• 工具调用
• 代码执行
• 权限检查
• 沙箱进程
• 多轮推理
• 子智能体协调
• 输出验证
• 结果聚合
• 长时间运行的状态管理

因此，基础设施不仅要支持模型推理，还要支持大量持久运行的软件进程。

在企业环境中，活跃的智能体数量可能从几十个上升到数千个甚至数万个。一些智能体可能持续运行，而另一些则动态创建用于短任务，并在完成后被销毁。

这改变了CPU和GPU资源之间的平衡。

GPU生成Token

GPU在以下环节仍不可或缺：

• 大模型推理
• 预填充与解码
• 嵌入生成
• 多模态处理
• 高吞吐量Token生产
• 模型并行执行

CPU运行智能体环境

CPU处理大量周边工作：

• 智能体进程调度
• 工具调用
• 上下文与状态管理
• 业务系统交互
• 沙箱执行
• 网络与存储操作
• 身份认证与权限
• 工作流协调
• 结果准备

模型可能负责生成推理或文本，但CPU通常运行智能体执行的操作环境。

因此，智能体基础设施正从以GPU为中心的设计，转向由CPU、GPU、网络、存储、散热和编排软件协同配合的系统。

为何CPU密度日益重要

在普通企业服务器中，CPU密度历来受限于功耗、散热、空间、线缆、风扇及维护需求。

智能体部署改变了经济模型。

若数千个智能体需要CPU资源进行编排、工具调用及隔离运行时环境，低密度CPU机架将占用更多机房面积、网络连接及配套基础设施。

与此同时，AI数据中心正朝着更高机架功率演进。

据消息源报告，浪潮信息预计国内AI机架功率将接近300千瓦，而部分全球设计已迈向兆瓦级机架系统。传统风冷通常限制在每机架数十千瓦，在此密度下将愈发困难。

因此，液冷不再是GPU专属问题。

支撑智能体工作负载的CPU机架，也必须匹配下一代AI数据中心的功率与散热架构。

单机架可支持超4万个智能体

浪潮推出了其宣称的业界首款CPU原生的液冷整机架服务器。

该系统基于液冷OCM 2.0架构，支持x86和Arm处理器。

其主要参数包括：

特性	厂商报告参数
单机架最大CPU数量	384
支持的智能体并发数	超过40,000个
处理器架构	x86和Arm
散热范围	CPU、内存、SSD、网卡、光模块及其他发热组件
计算密度	0.5U空间内集成4颗CPU
维护方式	液冷全生命周期维护
目标场景	高密度及吉瓦级AI数据中心

该系统并非将液冷视为服务器设计完成后的附加组件。

相反，计算布局与散热架构是协同开发的。

从CPU冷板扩展到全组件散热

传统冷板式服务器

可直接为处理器降温，但内存、网络、存储、电源组件及其他设备仍需依赖风扇散热。

随着密度提升，这种方式的效果逐渐减弱。

浪潮原生液冷架构将主要发热组件纳入统一散热体系：

• CPU
• 内存
• 网卡
• 光模块
• 固态硬盘
• 通信组件

此举减少了对内部气流的依赖，使组件布局更加紧凑。

紧凑型计算单元

该报告描述了一种紧凑型计算单元，将多组处理器及周边组件集成于轻薄机身内。

设计目标在于回收原本被以下组件占据的空间：

• 大型风扇
• 风道
• 冷却管道
• 内部线缆
• 传统服务器托盘

扁平化组件布局使单块大面积冷板能覆盖更多系统区域。

机架采用减缆或无缆化内部设计，支持不停机维护。浪潮表示，这提升了整机柜部署与维护效率。

OCM为何重要

OCM是开放计算模块的缩写。

模块化架构旨在将处理器模块与系统整体设计解耦。这种设计可更便捷地支持不同代际或架构的处理器，无需为每款处理器重新设计整机柜。

对企业及数据中心运营者而言，该方案可带来以下优势：

• 更多硬件选择
• 更易实现平台升级
• 减少重复设计工作
• 更好兼容x86与Arm架构
• 延长机柜基础设施生命周期

实际成效取决于生态兼容性、互操作性及配套组件的可用性。

规模不等于智能

运行数万个智能体解决的容量问题，并不能自动提升答案质量。

大语言模型各有专长。

某些模型可能更擅长：

• 逻辑推理
• 代码编写
• 长文本分析
• 技术研究
• 自然写作
• 结构化提取
• 多语言任务

即使超大规模模型也存在能力短板。

处理复杂任务时，单一模型可能遗漏关键问题，而其他模型能发现。单个模型还可能自信给出答案，却未暴露不确定性或考虑替代解释。

因此浪潮第二个基础设施方向聚焦多模型协作。

多模型协同处理同一任务

EPAI多模型融合API将复杂任务并行分发给多个候选模型。

每个模型独立生成答案。另设审核融合模型对候选答案进行比对，识别：

• 共同结论
• 矛盾判断
• 遗漏信息
• 独特见解

不支持声明：

• 需要协调的领域

随后平台会生成一个综合答案。

这并非简单的多数投票，也不是将所有回复直接拼接。预期工作流如下：

1. 候选生成
2. 跨模型审查
3. 差异与遗漏分析
4. 融合为最终输出

浪潮报告称，该系统在 DRACO 评估中达到 53.9%，优于该测试所用候选池中的每个独立模型。

该结果应视为平台报告的基准，而非宣称模型融合总能超越最佳单模型。性能将取决于候选模型、评估模型、路由逻辑、任务类型、提示词和评分方法。

简单任务仍使用单模型

若每个请求都运行多个模型，会不必要地增加成本和延迟。

因此，EPAI 区分了简短可预测任务与复杂任务。

适合单模型的任务

轻量级模型可能足以应对：

• 简单问答
• 格式转换
• 基础提取
• 分类任务
• 短工具调用
• 常规内容转换

更适合多模型融合的任务

多个模型可能对以下任务有用：

• 深度研究
• 技术对比
• 架构分析
• 复杂规划
• 长文本推理
• 高利害审查
• 证据模糊的任务
• 需独立验证的输出

这一路由原则对生产系统至关重要。

当潜在的质量提升能抵消额外token成本、GPU时间和响应延迟时，多模型协作才最具价值。

EPAI 多模型融合工作流

EPAI API 旨在将多模型编排隐藏在统一接口之后。

开发者向平台发送一个请求。EPAI 负责管理：

• 候选模型选择
• 并行任务分发
• 响应收集
• 评估模型执行
• 差异分析
• 最终答案生成

同一接口可集成到智能体应用和开发框架中，无需每个团队构建自定义模型路由和评估系统。

该架构适用于混合使用以下模型的企业：

• 开源模型
• 专有模型
• 通用模型
• 领域特定模型
• 本地部署模型
• 云端API模型

主要运维挑战在于，多个大模型可能需要同时保持可用。这将对加速器内存、互连带宽、调度和低延迟通信提出更高要求。

MetaBrain SD200 提供令牌引擎

MetaBrain SD200 超级节点是支撑多模型融合工作流的硬件平台。

该系统采用多主机、低延迟内存语义通信架构。据浪潮介绍，它能在单个系统内统一互连64个国产GPU加速器。

其设计包括：

• OCM 和 OAM 开放计算架构
• 3D Mesh 互连
• 统一加速器寻址
• 高速对等通信
• 大容量共享内存

能力

• 支持多个万亿参数级模型
• 软硬件协同优化

据称，该超节点可支持单个规模高达四万亿参数的模型，或由智能体应用同时使用的多个万亿参数级模型。

浪潮测试中Token生成时间达4.77毫秒

浪潮报告称，SD200将万亿参数Kimi K2.6模型的单Token生成时间缩短至4.77毫秒。

该公司还报告称，与之前的实现相比，首Token生成时间减少了35%。

这些数据指特定优化和测试环境下的结果，不应解读为每个模型、部署、提示长度、并发级别或生产工作负载的保证延迟。

这些改进归功于多项技术。

多Token预测

自回归模型通常先生成一个Token，验证新状态，再生成下一个。

多Token预测试图在一步内生成多个候选Token，并一同验证。

当预测精度较高时，可以减少顺序解码的轮次。

W4A8量化

优化在混合专家模型的部分负载中使用了INT4权重和INT8激活计算。

与BF16计算相比，这可减少：

• 内存带宽压力
• 加速器内存使用
• 计算需求
• 每Token推理成本

量化可能影响模型质量，因此生产团队需要基于自身负载评估准确性，而非仅依赖速度结果。

即时内核编译

JIT编译在运行时根据张量形状、布局和数据类型生成专门的加速器内核。

与通用的静态实现相比，专用内核可减少不必要的分支，并改善内存访问。

预填充-解码分离

提示预填充和Token解码具有不同的性能特征。

将两个阶段分开可以差异化分配资源，并异步传输KV缓存，减少计算与通信之间的争用。

模型兼容性

浪潮表示，SD200已完成对多个主流开源模型的性能优化，包括：

• Kimi K2.6
• DeepSeek V4
• GLM 5.2
• MiniMax M3

兼容性并不一定意味着每个模型都能达到相同的延迟或吞吐量。

模型架构、参数数量、MoE设计、上下文长度、量化、批处理和服务软件都会影响性能。

企业版降低部署门槛

64加速器超节点适合大型AI基础设施项目，但对许多企业来说规模过大、成本过高。

浪潮信息还推出了元脑SD200企业版。

企业版将纵向扩展的计算域从64个加速器缩减至16个，旨在本地部署万亿参数模型。

其宣称的特性包括：

• 16个加速器统一互连域
• 原生内存语义通信
• 统一寻址
• 太字节级统一加速器内存
• 万亿参数推理的首个令牌生成时间提升超过40%
• 本地支持领先的开源万亿参数模型
• 迁移与适配成本低于完整的SD200系统

该企业版主要针对以下工作负载：

• 长文档理解
• 复杂逻辑推理
• 私有模型部署
• 多智能体协作
• 内部研究
• 敏感业务应用

它为那些需要本地模型控制但无法论证64加速器超节点合理性的组织提供了更小的切入点。

基础设施栈正变得更集成

在OCTS 2026上发布的产品展示了三层架构。

层	主要职责
软件平台	模型接入、任务路由、编排、权限、评估和结果融合
CPU基础设施	智能体进程、工具调用、沙箱执行、上下文管理和业务系统交互
GPU超节点	大模型推理、高吞吐量令牌生成和多模型执行

只有当所有三层协同工作时，系统才能正常运作。

一个快速的GPU集群无法弥补薄弱的智能体调度。一个高密度的CPU机架若无法访问强大的模型，也无法提升推理质量。如果底层模型无法被高效加载或连接，一个复杂的融合API也无法提供有用的延迟。

这是智能体基础设施竞争的主要变化。

早期市场主要关注一台服务器对单个大模型的支持程度。智能体时代则将注意力转向了系统级性能：

• 能有多少智能体进程保持在线？
• 它们调用模型和工具的速度有多快？
• 能否同时运行多个模型？
• 内存是如何共享或隔离的？
• 权限是如何执行的？
• 平台能否对简单和复杂任务执行不同的路由？
• 系统在高压并发下能否保持稳定？
• 它生成有用令牌的效率有多高？

企业在部署前应评估什么

厂商提供的亮眼数字很有用，但不足以用来选择智能体基础设施平台。

一次生产环境评估应衡量完整的工作负载。

1. 智能体并发

不仅要统计活跃用户，还要统计：

• 每项任务的子智能体
• 工具进程
• 沙箱
• 后台作业
• 持久化会话
• 峰值突发
• 故障恢复进程

2. 每个智能体的CPU和内存

一个轻量级

检索智能体与一个配备独立开发环境的编码智能体，其资源需求特征截然不同。

“每机架智能体数量”这一指标必须映射到目标应用的实际内存、CPU、存储和网络需求上。

3. 模型延迟

需测量：

• 首令牌生成时间
• 令牌间延迟
• 端到端任务耗时
• 队列延迟
• 工具调用延迟
• 并发场景下的延迟

基准测试中较低的令牌生成时间，并不能保证端到端工作流的低延迟。

4. 多模型经济性

多模型融合虽可提升质量，但可能导致推理成本成倍增加。

团队应对比：

• 单模型精度
• 融合模型精度
• 消耗的令牌数
• GPU 利用率
• 响应时间
• 审查模型成本
• 失败率
• 人工审查减少量

5. 冷却与设施兼容性

原生液冷机架需要配套的设施基础设施。

需检查：

• 冷却液分配单元
• 供回水温度
• 压力与流量要求
• 泄漏检测
• 维护流程
• 余热回收方案
• 机架供电能力
• 数据中心地面承重

6. 模型与加速器可移植性

开放模块标准可提升灵活性，但实际可移植性取决于软件兼容性。

需验证：

• 模型框架
• 推理引擎
• 量化支持
• 内核可用性
• 驱动成熟度
• 监控工具
• 加速器替换
• 升级流程

7. 可靠性与治理

长期运行的智能体需要针对以下方面实施强管控：

• 身份认证
• 权限设置
• 密钥管理
• 网络访问
• 沙箱环境
• 审计日志
• 速率限制
• 人工审批
• 模型路由
• 数据留存

基础设施的密度不应以牺牲操作隔离性为代价。

常见问题解答

什么是浪潮的 CPU 原生液冷智能体机架？

这是一种围绕冷却系统设计的全机架 CPU 服务器，而非在传统风冷设计上添加液冷。浪潮称其可容纳多达 384 颗 CPU，并支持超过 40,000 个并发智能体。

一个机架真的能运行 40,000 个 AI 智能体吗？

该数字是浪潮参考架构供应商报告的最大值。实际容量取决于每个智能体所需的 CPU、内存、存储、网络和沙箱隔离资源。

为什么 AI 智能体需要这么多 CPU？

语言模型可能运行在 GPU 上，但智能体还需要 CPU 来执行调度、工具执行、状态管理、业务系统访问、安全检查以及隔离运行时环境。长时间运行和多智能体工作流会进一步增加这种 CPU 需求。

什么是 OCM 2.0？

OCM 是一种开放计算模块架构，用于将计算模块与更广泛的机架设计分离。浪潮的液冷 OCM 2.0 系统支持多种 CPU 架构和全组件液冷。

什么是 MetaBrain SD200？

MetaBrain SD200 是浪潮推出的 AI 超级节点，专为大型模型推理和多模型工作负载设计。它采用 64 加速器扩展架构，支持统一寻址和高速互连。

什么是 EPAI 多模型融合 API？

这是一种 API，能将一个任务发送给多个候选模型，收集它们独立的回答，并

采用审查与融合模型，在生成最终响应前识别共识、分歧、遗漏及独特见解。

多模型融合是否总优于单一模型？

否。多模型可提升复杂任务表现，但会增加令牌消耗、计算成本与延迟。简单任务更适合路由至单个轻量级模型。

SD200与SD200企业版有何区别？

完整版SD200采用64加速器扩展域以承载超大规模工作负载，SD200企业版则将域缩减至16加速器，面向需要以较低基础设施门槛部署本地万亿参数模型的企业。

相关工具

• 浪潮EPA企业级AI平台：支持模型管理、应用开发、检索、部署及多模型工作流。
• 浪潮液冷解决方案：部署液冷CPU/GPU服务器的基础设施方案。
• 开放计算项目：为服务器、机架、电源、散热及数据中心开发开放硬件设计的行业社区。
• Kimi：月之暗面旗下助手与模型平台，其优化结果被引用至浪潮SD200。
• DeepSeek：AI模型供应商，其开源模型已纳入SD200兼容性列表。

相关链接

• 浪潮智能体基础设施公告：涵盖液冷CPU机架、SD200与企业级超节点的官方发布。
• MetaBrain SD200 4.77ms性能公告：浪潮关于SD200优化及令牌生成结果的技术概览。
• EPA多模型融合API：候选生成、审查、融合机制及DRACO评分的官方说明。
• 浪潮EPA产品页面：企业级大模型开发平台的产品信息。
• 浪潮液冷数据中心解决方案：液冷数据中心部署方案的官方信息。
• 2026开放计算技术峰会：OCTS 2026活动页及相关开源计算公告。
• 开放计算项目基金会：开放基础设施标准与社区项目的官方信息。

总结

浪潮在OCTS 2026的公告解决了企业智能体引发的两大问题。

CPU原生液冷机架聚焦扩展性，为智能体调度、工具、沙箱、上下文管理及长流程运行提供密集型环境。SD200与EPA多模型融合工作流聚焦智能性，使多个大模型协同处理复杂任务，由审查模型整合输出结果。

更广泛的启示是：智能体基础设施不能被简化为单一更快的加速器。生产系统需要协调

CPU、GPU、内存、互连、冷却、编排、权限与评估。

智能体基础设施的核心衡量标准正从单一模型运行效能，转向整个系统能否高效调度数千个智能体并持续产出可靠结果。