8月26日，以“存力跃迁，AI破局”为主题，由DOIT传媒、华中科技大学计算机科学与技术学院、华中科技大学集成电路学院联合主办的2026全球闪存峰会在中国武汉盛大召开。
在当天下午的面向AI的存储系统创新与实践论坛上，百度智能云存储负责人段立国发表里题为《PFS L3 技术架构解析：为AI生产负载全新设计的并行文件存储》的主题演讲。
以下是演讲的详细内容：
今天想和大家分享的，是面对训练、推理、强化学习和 Agent 等生产负载，为什么需要重新设计并行文件系统。
1. AI Infra 演进趋势与并行文件存储（PFS）的范式重构
AI 正在经历从单一模型训练向规模化生产应用的关键跨越。随着基础设施全面迈向云原生，训练、推理、Agent、强化学习等混合负载交织演进，这一业务形态的转变正在重新定义并行文件存储的能力边界。
过去，PFS 主要服务于相对稳定的 HPC 或预训练场景；而现在，企业需要的不再仅仅是一套提供高带宽读写的存储系统，而是一套能够弹性供给资源、持续供给数据、高效流动数据并支撑多团队协同的 AI 数据基础设施。
AI 模型正快速向多模态、智驾、具身智能等领域延伸，视觉、点云、音频等非结构化数据占比超过 90%，数据规模呈指数级增长。这一趋势对存储提出了高性能与混合负载的双重考验：
- 复杂混合 IO：具身、智驾等多模态训练带来大小 IO 混合、随机与顺序混合的复杂 IO 模型，存储需要在各种 IO 形态下都保持高效的数据供给；
- 规模与成本的平衡：多模态数据暴增，存量数据长期占用高性能存储；企业期望存储能与对象存储无缝协同，实现冷热数据自动分层，在保证访问性能的同时控制长期成本。
模型竞争的重心正从预训练转向后训练、微调和强化学习。以强化学习为例，训练与推理在同一集群内高频交替：训练侧更新权重，推理侧批量 rollout 生成样本，再回传训练。训练与推理的边界因此逐渐消失，这对存储提出了新的要求：
- 权重高频同步：每一轮迭代，训练侧产出的权重需要立即保存并分发给大批推理实例，Checkpoint 从容错手段变成迭代闭环的关键路径，要求大容量、高并发写入及低时延读取；
- 统一数据空间：样本生成、经验回放、评测与训练共享同一份数据，在预处理、训练、微调、推理之间无迁移、无拷贝地高吞吐流转。
随着 AI 进入规模化落地阶段，行业模型、垂直小模型及基于多模型协同的 Agent 智能体快速普及。Agent 带来的记忆管理、工具调用等新负载，使存储从支持离线训练升级为支撑在线业务：
- 海量文件与元数据扩展：亿级至十亿级小文件场景下，要求元数据能力水平扩展，且时延不随规模退化；
- 强隔离与精细化管控：支持海量文件系统实例（子文件系统）、实时 Quota 统计、多租户隔离，满足多业务、多团队、多 Agent 的安全共存；
- 弹性供给与快速接入：推理服务随流量扩缩容，Agent 实例批量创建与释放，要求存储容量与性能按需供给、挂载链路秒级就绪，并兼容虚拟机、容器等多种计算环境；
把三条主线放在一起看，结论就非常清楚了。
负载演进带来的是多模态、智驾、具身智能爆发之后的混合 IO 与海量非结构化数据；架构演进带来的是后训练与强化学习驱动的训推一体、Checkpoint 高频读写；业务演进带来的是 Agent 与多租户规模化之后的海量小文件与在线业务。三条主线并不彼此独立，它们同时作用在同一套存储系统上，共同指向同一个结论：并行文件存储需要一次全面的能力重构。
落到具体能力上，可以归纳为五条要求：高吞吐并且混合负载下性能不退化、元数据可水平扩展、共享访问性能接近本地盘、冷热数据自动流动、多租户强隔离与弹性供给。
这五条要求，恰恰是过去的并行文件存储没有正面回答过的问题。传统 PFS 诞生于 HPC，成熟于大模型预训练，它的设计目标始终是把带宽做大、把单一任务跑完，面向的是稳定负载、固定集群与离线作业。
而今天的 AI 生产应用是另一套语境：Agent 需要千万量级的独立工作空间，强化学习需要训练与推理共享同一份数据、共享同一批算力，训推一体需要存储直接站在迭代闭环的关键路径上，在线业务还要求存储具备多租户治理与秒级弹性供给的产品化能力。这些诉求无法通过在旧架构上叠加局部优化来满足，必须从数据引擎、元数据底座、客户端、网络到产品形态逐层重新设计。
因此，我们对 PFS L3 的定位是一套 AI 原生的并行文件系统：它不是把面向 HPC 的并行文件系统平移到 AI 场景，而是以 AI 生产负载为第一设计目标重新构建的存储系统。
接下来的第二、第三部分，都是围绕这个定位展开的。
面对上述三大演进趋势，并行文件存储需要的不是单一性能指标的优化，而是围绕 AI 生产级工作负载，从存储引擎、客户端、网络、数据流动、产品功能五个层面完成系统化的重构升级。基于这一思路，我们推出了全新自研的并行文件存储 PFS L3 产品。
先看整体架构。
- 最上层是客户端，覆盖 overlay 虚拟网络上的公有云 GPU 与 CPU 实例，以及 underlay 物理网络上的集团 GPU 强化学习集群与 CPU Agent 集群，统一通过私有客户端与 SDK 接入，前端链路走用户态 TCP，数据链路走 RDMA。
- 中间是引擎代理 Proxy 层，负责请求路由与聚合。
- 底层是引擎：BlockServer 三副本引擎承担高性能持久化缓存，Aries EC 副本引擎承担低成本持久化，MetaDB 元数据引擎承担层级命名空间；数据流动引擎则打通 PFS 与对象存储 BOS。
这套架构的特点，是客户端、网络、存储引擎、数据流动四层协同设计，而不是单点能力的简单堆砌。
把业务挑战、技术实现与核心收益逐条对应起来，五大升级路径分别是：
- 存储引擎升级，重构数据引擎与元数据底座：针对多模态训练中大小 IO 混合的复杂场景，引入创新的混合数据引擎，兼顾大 IO 的高吞吐与小 IO 的低时延；同时打造可线性扩展的元数据底座，确保千亿级文件规模下元数据访问仍保持亚毫秒级的稳定低时延（详见 3.1）；
- 客户端升级，打造 AI 场景专属的高性能客户端：将共享存储的访问性能对齐本地 NVMe 盘，放大单 GPU 节点的入口带宽，支撑 Checkpoint 的高频读写与快速分发，满足训推一体对共享存储的高性能要求（详见 3.2）；
- 网络升级，深度调优 RDMA 高速网络：基于用户态 Polar TCP 完成前端网络调优，基于高速无损 RDMA 网络底座完成后端网络调优，解决大规模集群下的网络拥塞与负载不均，为上层应用提供低时延、高吞吐、高稳定的传输通路（详见 3.3）；
- 数据流转升级，实现文件与对象的无缝协同：构建 PFS 与对象存储 BOS 之间的高速数据流动能力，通过冷热数据自动分层与透明加载，让数据在性能与成本之间智能流动，实现全生命周期的成本最优（详见 3.4）；
- 产品功能升级，引入 AgenticFS 能力：通过 AgenticFS 提供海量子文件系统，保障多 Agent 混跑场景下的权限隔离、吞吐流控与容量实时统计（详见 3.5）。
3. 五大升级路径：关键技术实现
从百度沧海存储的技术产品架构可以清晰看到，我们基于统一的元数据底座 MetaDB 与统一的数据底座 Aries，构建了对象存储 BOS、文件存储 CFS、并行文件存储 PFS L3、块存储 CDS、类 HDFS 文件存储 AFS、极速文件缓存 RapidFS 等多条产品线。
元数据面上，MetaDB 同时提供适合对象存储 BOS 的平坦 Namespace，以及适合文件语义的层级 Namespace；数据面上，Aries 提供两种数据模型，Blob Model 服务于 BOS 的对象并行分块上传，Stream Model 服务于 AFS 的大文件顺序读写。
PFS L3 沿用了分层架构的思想，基于 MetaDB 构建层级 Namespace，基于 Aries append-only 的 EC 模式叠加 BlockServer，实现了 EC 副本之上的随机写，做到复杂度可控、性能领先。存储引擎升级正是沿着数据引擎与元数据底座这两条主线展开：数据引擎解决大小 IO 混合场景下吞吐与时延的兼顾问题，元数据底座解决超大规模文件数下的元数据扩展问题。
高性能数据引擎全部自研，采用分层架构，是 Aries 与 BlockServer 两套成熟能力的创新拼接：
- Aries Linked 引擎：append-only 的用户态存储底座，提供在线 EC 能力，支持任意比例的 EC 模式，最低支持 1.2x 副本，并与 BOS、网盘共用同一套 EC 底座；
- BlockServer 三副本引擎：在架构中承担高性能持久化缓存层的角色，文件按 offset 切成 Block，通过 Hash 均匀打散到不同的 BRG（Block Replica Group），集群吞吐随机器数线性增长。
两者的配合体现在写路径的分流上。大 IO，也就是不小于 512KB 的写请求，直接交给 Aries 完成在线 EC，拿到 Blob Id 之后再写 raft log，一次落盘、无需二次搬迁；小 IO，也就是小于 512KB 的写请求，先以三副本写入本地，quorum 即刻 ack 保证低时延，后台再由 compaction 聚合写入 Aries 转为 EC。
通过小 IO 走三副本保时延、后台聚合转 EC 降成本，大 IO 直接在线 EC 的混合策略，大小 IO 的性能得以兼顾，存储冗余成本从 3x 降至 1.29x，单 TB 容量可提供 250MB/s 的吞吐。
MetaDB 是百度沧海存储团队自研的元数据数据库，内部原名 TafDB，峰值处理数百万 QPS，管理十万亿级元数据记录，支撑 EB 级存储规模。
它以同一套数据库向上支撑三类命名空间：对象存储的平坦 Namespace、并行文件存储所需的 POSIX 语义层级 Namespace，以及数据湖对象存储与类 HDFS 文件存储 AFS 所需的 HDFS 语义层级 Namespace。这几类 Namespace 的访问语义并不相同，但它们对规模扩展、事务一致性、高可用与成本效率的要求高度共通，把共性下沉到底座、把差异留在上层，底座的一次性能优化或者一次扩展能力升级，多条产品线可以同步受益。
围绕这套底座，有三项工作先后发表于 CCF-A 类国际顶会。三者的位置不同：CFS 与 Mantle 是构建在 MetaDB 之上、面向不同语义的上层 Namespace 系统，MetaDB 则是底座自身的工作。下面按发表时间先后介绍。
- 《CFS: Scaling Metadata Service for Distributed File System via Pruned Scope of Critical Sections》｜EuroSys 2023
先看面向 POSIX 语义的 CFS。它要解决的是 POSIX 兼容性与写扩展性难以兼顾的问题，核心思路是修剪关键冲突域的范围来减少锁开销，具体有三点：一是元数据不再由专门的模块承担，而是拆解到负责目录与索引的 MetaDB、负责文件的 FileStore、负责 slow path rename 的 Renamer 以及客户端，每一部分按各自的特点独立扩展；二是在 MetaDB 中引入单分片原子原语，提升单分片处理性能的同时缩短请求耗时，消除虚假的跨分片冲突；三是放弃传统实现中的元数据代理层，由客户端直接提供完整的 POSIX 语义兼容性，客户端数量可以自由扩展。50 节点规模的测试中，各操作吞吐相比 HopsFS 与 InfiniFS 提高至 1.76 到 75.82 倍和 1.22 到 4.10 倍，平均时延最高降低 91.71% 和 54.54%，竞争越激烈、目录越大，优势越明显。这条路线正是今天 PFS L3 元数据能力的直接来源。
- 《Mantle: Efficient Hierarchical Metadata Management for Cloud Object Storage Services》｜SOSP 2025
再看面向 HDFS 语义的 Mantle。它要让对象存储的层级 Namespace 同时具备扩展性与高性能，难点有两个：一是长路径解析开销巨大，解析一个深层路径需要多次网络通信，而对象存储基于 RESTful API、Proxy 无状态，传统的客户端缓存难以实施；二是成千上万个任务并发操作同一目录时，分布式事务的读写冲突与重试会让吞吐断崖式下跌。Mantle 是全球范围内第一个公开的、完整解决这两个难题并且经受了超大规模生产环境长期检验的分布式层级 Namespace 系统，采用 IndexNode 与 MetaDB 的双层元数据架构，full-path 查找仅需单次 RPC。相比 Tectonic、InfiniFS、LocoFS，元数据访问时延降低 6.6% 到 99.1%，吞吐提高 0.07 倍到 115 倍，交互式 Spark 分析的作业完成时间缩短 63.3% 到 93.3%。
- 《MetaDB: Putting File-System Structure Back into Distributed Databases》｜NSDI 2027
最后是底座自身。用分布式数据库承载文件系统元数据，底层负责一致性、高可用与扩展能力，上层实现文件系统语义，是业界的主流路径，但这条路径有一个长期被忽视的代价：数据库并不知道自己存放的是一棵目录树，文件系统负载中最重要的结构信息，在进入数据库的那一刻就被抹平了。
被抹平的具体是三类信息。第一，数据库看不见目录树。生产负载中超过 97% 的目录修改只涉及单个目录，本应就地完成，但通用数据库不理解目录树的拓扑，常常把同一目录下的数据拆散到不同分片，一次局部操作因此被放大成跨分片的分布式事务。第二，数据库分不清元数据的主次。一次目录操作除了必须严格一致的主元数据，还要同步更新父目录属性、配额统计与二级索引，通用事务模型把它们一视同仁，父目录属性成为热点，关键路径被并不关键的工作拖慢。第三，数据库不了解元数据的生命周期。云存储中存在大量连续批量删除，被删除的数据不会立即消失，只留下层层墓碑标记，墓碑不断累积，listdir 这类范围扫描随之越来越慢。
MetaDB 的做法是跨层协同设计，把上层 Namespace 掌握的文件系统信息，传递给底层数据库的分片、事务与存储引擎：目录树的结构用于指导分片与执行，同一目录的操作就地完成；元数据的主次用于事务分级，关键路径不再被辅助更新拖慢；删除的生命周期规律用于存储引擎的空间回收设计，扫描不再被墓碑拖累。数据库由此从通用黑盒，变成真正理解文件系统的底座。相比上一代通用分布式数据库，高并发同目录操作吞吐最高提升 10.7 倍，所需元数据机器数量降低到原来的一半以下。
落到 PFS L3 上，我们复用的正是 CFS 这条 POSIX 语义路线：在 MetaDB 之上构建层级 Namespace，单文件系统做到千亿级文件规模，4KB IOPS 达到每 TB 2.1 万。
除了支持标准的 NFS/SMB 客户端之外，我们推出了高性能私有客户端 RapidFC（RapidFileClient），通过内核态多通道、三层缓存、零拷贝等三项关键技术满足极致性能需求，并实现对 PFS、BOS、CFS、RapidFS 等多种存储产品的多源统一访问。
- 第一是内核态多通道。客户端与内核之间建立多条并发通道，让请求充分并发、互不阻塞，从而提高极限吞吐；同时优化内核态与用户态之间的双向通信，大幅减少上下文切换与数据拷贝开销，降低请求时延。相对传统用户态客户端，可以实现数倍的性能提升。
- 第二是三层缓存。本地内存缓存与本地 NVMe 缓存承接本节点最近访问过的热数据，客户端共享缓存池则以 P2P 方式把模型权重、数据集这类高频数据在 GPU 节点之间就近共享。热点数据集、Checkpoint 快照、RAG 知识库文件优先在计算侧缓存命中，未命中才回源后端存储集群。在大规模多卡训练场景下，大量跨存储集群的南北回源流量因此转化为算力集群内部的东西流量，避免后端集群被反复冲击。
- 第三是零拷贝直通。在访问形态上，客户端提供两种接入模式，兼顾兼容性与极致性能：
- 标准 POSIX 挂载点面向通用业务，基于 FUSE 与自研用户态框架对外输出，上层 AI 训练框架、推理服务、Agent 应用无需改造业务代码，即可像访问本地磁盘一样访问并行文件存储，并可无缝对接 K8s CSI 容器生态，支持大规模 GPU 集群批量挂载与弹性扩缩容；
- 原生 lib SDK 面向性能敏感业务，业务程序直接链接 SDK，绕过 VFS 内核栈、规避 FUSE 层多次用户态与内核态上下文切换与内存拷贝，构建零拷贝的用户态 IO 路径，把共享存储的访问带宽向本地 NVMe 盘对齐。
需要补充的是，上述优化并不只作用于 PFS，访问 BOS、CFS、RapidFS 同样有效。用户无需额外的学习成本，通过同一个客户端、同样的使用方式，就能实现多源统一访问，并获得一致的端侧加速能力。
三项技术叠加之后，单客户端吞吐最高可达 40GB/s。
这既解决了传统用户态客户端的单节点带宽天花板，放大了单 GPU 节点的共享存储入口带宽，也通过计算侧缓存与东西流量分担，在万卡级集群下避免了 IO 风暴冲击后端存储集群。
文件存储与网络团队一起，围绕高速无损 RDMA 网络底座完成了端到端的全栈网络深度调优。网络底座的整体规划目标为 400Gb 级别；当前实际部署中，节点接入采用 200Gbps 双网卡完成落地，后续将随硬件能力提升逐步向 400Gb 目标演进。
从拓扑上看，客户端侧是虚拟网络中的多个 GPU、CPU 集群，后端是物理网络中的 Spine-Leaf 集群，调优工作覆盖前端链路、后端链路与接入层三段：
- 前端网络采用用户态 TCP。Polar TCP 是面向 RPC、基于 Polling 加速的高性能用户态协议栈，采用纯用户态 Polling 的 RTC（Run-To-Completion）线程模型，并进一步结合 DPDK、零拷贝、硬件卸载等多种用户态优化手段，减少用户态与内核态之间的切换开销，在前端和元数据链路上带来约 40% 的 IOPS 提升；
- 后端网络做 RDMA 深度调优。基于存储业务场景，围绕拥塞控制、网卡固件、队列深度、QP 数等关键参数寻找最佳配置组合，充分发挥 200G 网卡的多队列硬件能力，吞吐提升约 15%；
- 链路层启用 Jumbo 帧，提升单次通讯的有效负荷，吞吐提升约 20%；
此外还有两项与选路相关的优化。
- 一是物理网络直连通道，AI 应用和模型部署在虚拟网络的虚机与裸金属上，我们实现了上下行双向数据包走物理网络直连，打通从虚拟网络到物理网络的转发路径，在负载均衡选路的前提下把时延做到最短。
- 二是 Leaf-TOR 的 hash 极化治理，智能网卡与 TOR 各有独立的 hash 链路算法，incast 或者 hash 极化不可避免会让某一台 TOR 交换机成为流量汇聚热点，出现队列堆积与拥塞扩散；智能路由算法基于物理链路做路径主动规划，端网协同动态地把源目的 TOR 路径均匀打散，避免出现局部热点路径。
PFS L3 的数据流动能力，是自研并行文件存储 PFS 与对象存储 BOS 之间的双向数据互通能力，核心目标是让 PFS 在保持高性能计算访问的同时，通过 BOS 获得低成本的海量数据持久化能力，做到性能与成本兼顾。
已具备三大核心能力：
- 一是预热（Prefetch），支持将 BOS 中的元数据或元数据+数据一次性同步至 PFS 供计算使用；
- 二是导出（Export），支持将 PFS 数据主动推送至 BOS 做备份或持久化；
- 三是沉降（Archive）与按需加载（Lazyload），可将 PFS 中长期未访问的冷数据自动导出至 BOS 并清理本地数据，仅保留元数据；当用户后续访问该文件时无需等待，系统自动从 BOS 拉回数据，对用户完全透明。
整套方案基于策略与任务两层模型驱动：策略绑定 PFS 目录与 BOS 桶并配置预热、导出、沉降规则，任务则支持策略自动触发或手动一次性执行，并针对生命周期管理预置了数据缓存、数据训练、数据备份三类典型场景模板。一致性上坚持 PFS 是运行时的写权威、BOS 是冷数据的不可变持久副本，由 bitmap 作为路由的单一事实源，保证文件读永不读脏。
最终效果是，在统一命名空间之下，热数据留在 PFS、冷数据自动流向 BOS，最大支持 100GB/s 的数据流动速度。
Agent 规模化落地对存储提出的挑战集中在五个方面：空间隔离、容量 Quota、吞吐 QoS 实时统计、接入权限控制与海量规模，每一项都是一个关键技术点。AgenticFS 的目标，是在一套统一的文件系统底座之上，大规模管理海量独立的 Agent 工作空间，承载会话记录、记忆数据、Skill 脚本、RAG 知识库、Markdown 文档等持久化数据。关键技术点有四个：
- 子文件系统机制。以 FSID 为单位为每一个 Agent 划分独立工作空间，文件系统元数据管理持久化到 MetaDB 之后，创建与销毁都成为轻量的元数据操作，Agent 规模具备线性扩展能力，单一集群可管理千万量级的 Agent 工作空间；
- 目录隔离与独立 Quota 管控。每个目录独立配置容量配额与文件数配额，支持实时统计、动态修改，并可通过 API 自动化管控，防止个别 Agent 滥用存储容量、无限制生成小文件，从底层规避资源滥用风险；
- 多层次接入点与完备的权限控制。接入点实现了文件系统与子文件系统之间一对多的灵活权限控制，针对不同 Agent 实例配置读、写、禁止遍历等细粒度权限，严格限制 Agent 越权跨空间访问；
- 协议兼容与弹性挂载。兼容 NFS 协议，支持私有客户端、SDK 与 K8s CSI 组件，支持海量并发 mount 与秒级弹性挂载，匹配 Agent 沙箱高频创建与销毁的使用特征。
4. 最佳实践与总结
前面介绍的五大升级路径，已经在后训练等真实生产场景中完成规模化落地。下面分享一个来自大模型后训练强化学习场景的实践案例，主题是从本地准备加手工同步，走向统一共享存储加自动容错。
先看旧模式。在早期使用方式下，用户提交作业、占用 GPU 卡之后，第一件事是从远端把代码、数据、模型手动下载到本地，这一步大约要一个小时；下载完还要人工把数据从一个节点同步到其他所有节点，才能启动训练。这里有三个系统性的问题：一是准备期 GPU 占着卡但完全空转；二是漏同步某台机器这类低级错误很常见，排查起来却要花大量时间；三是最影响效率的问题，一旦机器故障或者重新提交作业，备份加下载的全流程就要重走一遍。按日均一次故障估算，每天大约有两个小时的算力空转在无效等待上。
再看新模式。我们把 PFS 共享存储在全资源池完成了自动部署和自动运维，同时在 RL 框架和平台容错层做了统一改造。核心变化有三点：第一，所有节点天然共享同一个 PFS 目录，代码、数据、Checkpoint、热启模型统一存放，手工同步这个环节直接消失了；第二，容错层检测到故障后，直接从共享目录恢复训练环境，基本做到零损耗恢复；第三，存储本身的稳定性，SLA 做到了 99.99%，挂载率保障 100%。
收益是实打实的：RL 作业默认跑在 PFS 上之后，周均节省卡时接近 3 万小时，而且随着 RL 大规模推广，这个数字还在持续放大。再配合与协同的故障治理，资源池的在线率从约 98% 提升到了 98.5%，为下一步冲 99% 打下了基础。
这个案例很好地说明了前面讲的能力如何组合落地：共享存储消除数据搬运，高可用支撑容错恢复，最终转化为算力利用率和研发效率的双重提升。
最后做一个整体总结。面向训练、推理、Agent、强化学习、仿真这些 AI 生产负载，PFS L3 给出的是一套分层的系统性重塑：存储引擎层是 Aries 与 BlockServer 组成的混合数据引擎，加上 MetaDB 统一元数据底座；客户端层是 RapidFC，包含内核态多通道、mount 与 lib SDK 双模式、多层缓存与 P2P 共享；网络层是无损 RDMA、用户态 TCP、物理网络直连、多 QP 调优与 TOR 反极化选路；数据流转层是 PFS 与 BOS 的透明协同，覆盖预热、导出、沉降与按需加载；产品功能层是 AgenticFS，包含子文件系统、目录强隔离、实时 Quota 与接入点权限。
支撑这五层的是同一套统一底座，它具备全自研、Serverless、弹性伸缩、EB 级规模验证四项特征，这也是 PFS L3 能够在多条产品线之间复用能力、快速演进的根本原因。
从三大演进趋势出发，到存储引擎、元数据底座、客户端、网络、数据流转、产品功能的系统性升级，PFS L3 已经完成从高性能存储系统到 AI 数据基础设施的范式重构。
面向 AI 生产化的持续深入，我们将与业务共同演进，让并行文件存储成为驱动数据、算力与应用高效协同的核心力量。以上就是今天的分享，谢谢大家。
