一、文件存储CPFS能力创新
分享人：阿里云智能资深产品专家 李洋
1.AI渗透各行业，对存储提出新要求
在过去的一年里，AI技术迅速渗透到各行各业的每一个角落。在日常生活中，无论是自动驾驶技术的广泛应用，还是智能助理的贴心服务，都给我们的生活带来了极大的便利。同时，AI在IT行业也开辟了一个万亿级别的庞大市场。相信当大多数人提到AI时，首先映入脑海的可能是强大的算力以及GPU。如果把算力和GPU比作极为先进的发动机，那么数据无疑是驱动这台发动机运行不可或缺的燃料。仅有先进的发动机并不足够，还需要有更高质量的燃料及其稳定供给，才能在激烈的AI竞争中脱颖而出。这由此引发了AI场景下对存储的迫切需求与全新挑战。通过与AI领域，特别是虚拟场景中的客户深入交流，我们将客户对于存储，尤其是高性能CPFS存储的具体要求、面临的挑战及实际需求进行了系统归纳，大致可以分为以下五类。
2.对存储的关键需求
首先，性能方面是客户在GPU场景中选用CPFS进行训练的首要考量。随着多模态技术的兴起以及客户算力规模和数据量的不断扩张，对存储性能的需求也随之水涨船高。
第二方面，规模与数据量的双重增长对存储的弹性能力提出了更多要求与挑战，这涵盖了容量弹性、性能弹性，以及在容器化应用场景下对挂载密度的灵活适应性。
第三方面聚焦于稳定与安全。对于任何客户而言，确保稳定与安全都是业务能够顺利运行不可或缺的前提。
第四方面，成本问题不容忽视。即便是在AI这一资金密集型领域，GPU、存储以及数据成本仍然是每位客户高度关注的要点。
最后一个方面往往容易被许多人所忽略。随着AI热潮的席卷，大量算力资源、多样化的芯片、厂商及品牌，乃至不同的算力平台给客户带来了诸多困扰。具体而言，当客户使用不同的算力平台时，如何更有效地对接存储，即如何通过一套存储系统来适配多种算力，从而在性能与成本之间达到最优平衡，成为了亟待解决的问题。
3.大模型的演进不断挑战存储性能极限
几乎所有大型模型训练场景都不可避免地涉及三种IO类型。首要的是数据集加载，特别是大规模数据集的加载。以ChatGPT为例，从GPT-3到GPT-4，其模型参数增加了十倍，而相应的数据集规模更是增长了50倍。这给存储系统带来了前所未有的性能压力，每个GPU节点都渴望迅速拉取训练所需的数据集，并加载到显存中，以便展开更加高效的训练。此外，在处理序列数据时，往往会遇到数以十亿计甚至上百亿的小文件，这对元数据处理性能构成了严峻挑战。
提及训练，就无法避开检查点这一话题。在训练过程中，存在诸多不可预测的风险。若训练结果或模型未能达到预期，最不愿见到的便是从头再来。因此，所有进行训练的客户都会在漫长的训练历程中，不断进行存档，犹如在游戏中挑战大Boss前进行存档一样，为应对可能的挑战做好准备。然而，当GPU服务器进行Checkpoint操作时无法进行训练。这意味着，一方面，客户希望更频繁地保存中间状态，以便在出现问题时可以回退到最近的时间点；第二方面，又不希望这一过程占用过多时间，导致昂贵的GPU资源利用率下降。这无疑给存储系统带来了更大的挑战，即如何缩短写入时间至最优。第三方面，当算法工程师对模型进行调优时，常常会有多位工程师在多个GPU节点上同时拉取同一份模型文件。这些GPU节点可能多达数十台甚至上百台。当如此多的GPU节点同时从CPFS或存储系统中拉取同一个数据块时，无疑会形成数据热点和IO拥堵。如何解决这些问题，将直接影响客户在训练场景中的效率和性能。
我们曾介绍了CPFS性能，展示了CPFS存储端的极限能力，包括每秒27TB的吞吐能力、2亿IOPS以及极低的时延。然而，在实际应用场景中，当客户真正使用时，这些极限能力可能并不总能切实提升日常工作效率。因为我们发现，对于客户实际运行的训练任务而言，最重要的是端到端地识别IO链路上的瓶颈及关键节点。解决这些瓶颈问题，正如木桶理论所述，系统的整体性能取决于最短的那块木板。
4. 端到端全链路性能提升
在过去的一年中，CPFS在性能方面的核心提升并非单纯追求存储的极限性能，而是着重于端到端的整体优化。一方面，从前端计算入手，通过软硬件的紧密结合，充分利用计算侧GPU服务器上智能网卡的能力，对存储的传输协议和通道实施协议硬件卸载及性能调优，确保每个GPU节点都能达到25GB的吞吐量和卓越的性能表现。这意味着，在拉取数据集或写入检查点时，每个节点都能迅速体验到CPFS本身所带来的高性能优势。
另一方面，在计算前端，利用了GPU服务器上闲置的资源，例如将CPU内存或本地的MNE资源，整合为分布式缓存。当多台GPU服务器的多个节点需要共同拉取同一份数据或同一个数据块时，通过缓存的点对点加速能力，可以将数据模型文件分割成多个部分，每个节点负责拉取其中的一部分。然后，利用各个节点之间东西向的闲置网络流量通道，实现GPU节点之间的数据互通，从而高效地实现多个节点快速拉取同一个文件的目的。
5.多样化的场景带来资源弹性的挑战
如今，CPFS在性能方面的追求已不再局限于单纯的极限能力，而是更加注重可预测的硬性对应性能密度。也就是说，客户只需根据所购买的容量，就能预知将获得的CPFS性能和吞吐能力。同时，客户的存储数据是分层管理的，其中热数据存储在CPFS中，而原生数据集及归档数据则可放置于OSS上。在CPFS与OSS这两个存储产品之间，性能数据流动得到了显著提升，两者之间的高速通道已打通，实现了每秒100GB的高速吞吐能力。
去年，大模型训练主要以文本为主，尽管模型参数在不断扩大，但很多客户的数据总量仍维持在百TB级别。然而，今年年初，多模态技术成为了业界的新风向，带来了数据量级的显著提升，这也对去年产品的文件系统在容量、性能等方面的上限提出了严峻挑战。AI大模型训练场景与传统应用截然不同，所有应用和算力都原生生长在容器化环境中，一台GPU服务器往往会被切割成多个容器。因此，这就需要对GPU节点上挂载的CPFS文件系统进行更高密度的弹性调整。
6 弹性能力增强：大规模，更高密度，按需扩容
为此，CPFS产品在以下三方面进行了能力增强：首先，将原本针对HTP场景以集群形式交付的高性能文件存储，进化升级为全托管的服务化形态。用户只需按照容量和与容量匹配的性能进行购买和使用，集群和服务器相关的维护操作对用户来说变得无感且透明。其次，文件系统的容量空间得到了显著扩展，从去年单文件系统1TB的容量上限，提升至今年的12TB，单个文件系统的容量扩容能力提升了11倍。最后，在挂载密度方面，现在支持在单个GPU节点上，客户至少可以开启40个容器来分割计算资源，而这40个容器各自都可以挂载独有的CPFS文件系统，从而大大提高了资源利用率。值得一提的是，数据安全问题在任何时候都至关重要。
7.数据安全威胁及应对策略
在存储领域，客户数据所面临的数据安全问题始终是一个巨大的挑战与隐患。由于攻击者的出现方式和时间永远无法预知，我们如同处于明处，而威胁则潜藏于暗处。这些攻击可能源自外界的恶意行为，也可能因内部失误而引发。作为产品提供者，我们必须不断提升自身实力，努力缩小客户在数据安全风险面前的暴露范围。
在过去的一段时间里，着重提升了以下三方面的产品能力。首要任务是防止非授权访问。特别是在多租户环境中，我们深入审视了整个数据链路和管控链路，从架构到代码，确保所有对数据的操作，包括文件系统的挂载和IO访问，都必须在客户拥有并授权的前提下进行。为此，我们内部进行了红蓝对抗演练，实施了加固措施，并对代码进行了严格的测试与优化。
然而，即便是在安全、授权的访问情境下，许多客户仍然希望了解谁在何时访问了哪些数据。因此，我们推出了与阿里云日志服务SLS相结合的新功能。该功能能够记录用户每个ID对CPFS上关键数据的访问行为日志，并将其存储在日志服务SLS中。这样，客户便可以轻松利用日志服务提供的成熟查询分析手段，随时了解数据的访问情况，为内部审计提供有力的工具支持和便利。
此外，阿里云及我们的存储团队每年都会收到一定数量的工单，其中不乏因工程师失误操作或沟通错误导致的数据删除问题，以及全球范围内肆虐的勒索病毒等威胁。在这些情况下，一份安全可靠、可恢复的备份显得尤为重要。为此，我们在上个月通过阿里云的云备份产品正式推出了对CPFS计算版数据源的支持。客户可以通过控制台和API形式实现全自动化操作，轻松完成对CPFS上关键数据的备份和恢复。因此，我们强烈建议CPFS的所有客户都使用备份功能来保护他们的数据。
在前面的分享中，我们提到了Access Point的概念。对于许多人来说，仅仅拥有精细的文件系统级别权限可能并不足够。特别是对于那些负责大企业IT基础设施的负责人而言，他们可能需要面对内部多个团队共享维护的AI基础设施，并希望避免团队之间的互相访问，特别是在发生数据误删等复杂情况时。因此，我们在阿里云的SLS和NAS产品上已经推出了一段时间的Access Point功能。如果你已经使用过NAS服务，那么你应该已经体验过Access Point的便利。同样地，我们即将在CPFS上推出的Access Point接入点也是为了实现这一目标，它能够让客户在一个文件系统内针对不同的用户、团队和应用单独设定权限，明确界定他们能够做什么和不能做什么。
8. 降本增效是每个客户面对的挑战
成本，这一话题如同在足球经理游戏中那般，是无法回避的现实考量。在实际应用中，成本同样是每位客户必须审慎权衡的因素。我们综合分析了客户对于成本降低的需求，以及我们作为存储产品所能提供的解决方案，发现有三个关键方面可以在成本上为客户实现更优的效益和回馈。
首先，客户的应用场景多样，对性能等级的要求也不尽相同。因此，没有必要将所有数据都存放在最热门、可能也是成本最高的存储介质上。这要求我们具备识别客户数据性能需求的能力，并将数据按照其性能规格匹配到相应的存储解决方案中。
其次，客户数据的热度会随时间或业务逻辑的变化而波动。为此，我们需要一种智能机制来识别数据的热度变化，并能自动地在不同规格的存储产品间进行数据迁移，以在性能和成本之间取得最佳平衡。
最后，随着时间的推移，AI技术每天都会产生大量数据。在数据的长期保存方面，CPFS作为高性能存储可能并非最优选择。因此，CPFS进行了多项产品改进。一直以来，CPFS提供了四个性能规格，分别是100MB/s/TiB、200MB/s/TiB、智算版400MB/s/TiB和智算版大容量400MB/s/TiB（单位为每秒每TB的性能密度）。客户可以根据自己的性能需求选择合适的CPFS性能规格。针对大模型场景对高性能的迫切需求，我们今年在400兆基线的基础上推出了大容量规格，文件系统上线容量提升至12TB，并且容量售卖单价降低了25%。
接下来，我们计划将混合闪存（SSD与HDD结合）技术引入CPFS产品中，为用户提供一个创新的文件系统。在这个系统中，用户将获得一个SSD库和一个HDD库。借助先进的技术手段和业务洞察力，用户可以自主决定哪些数据存放在SSD库中，以享受更高的性能，而哪些数据则放置在HDD库中，以降低成本。同时，这两个库之间能够实现数据的无缝迁移，帮助用户在性能和成本之间找到最佳的平衡点。
单纯地降低存储价格对于成本优化而言是远远不够的。很多时候，通过数据治理所带来的成本回报往往超乎我们的想象。因此，我们即将推出目录配额功能，该功能能够应用于以下场景：在一个大型企业中，可能有数十个甚至上百个小团队共同使用AI基础设施和CPFS文件系统。然而，个别团队或应用可能会因为缺乏限制或存在bug而产生大量的临时文件，导致整个文件系统的容量被迅速耗尽，进而影响所有用户的应用运行。为了解决这一问题，我们推出了配额功能，这相当于为每个团队或用户分配了独立的资源配额，让他们对自己的成本和容量负责。通过这种方式，可以更有效地控制整体容量和成本。
9. 统一形态对接多种算力平台
接下来介绍算力形态的多样化。去年，对于使用阿里云计算平台的用户来说，可能已经了解到邻居平台提供了单租户、多租户、半托管、全托管等多种形态。在过去，对于单租户邻居和多租户邻居，我们分别提供了独立的、配套的精细文件系统和产品。这意味着，如果一个客户同时需要使用单租户和多租户环境，他们需要购买两套系统，这不仅给客户带来了不便，也造成了经济上的浪费。
针对算力平台的不同形态和实际应用场景，采用了CPFS来提供全面支持。无论算力是单租户还是多租户模式，只要处于同一地域，都可以挂载同一份文件系统，实现数据的共享与高效利用。
10.CPFS 能力全面升级，助力企业加速 AI 发展
接下来，简要回顾并总结CPFS产品能力的升级情况，并分享一些作为AI服务提供者的个人感悟。一年前，我们的主要精力和关注点还集中在追求更高的极限性能上，就像学生时代追求更高的分数一样。然而，随着过去一年多的时间，AI训练在更多客户场景中得到了应用，我们服务了越来越多的客户。在与客户的深入交流和支持过程中，我们逐渐理解了客户的真正需求。因此，CPFS的产品能力增强并非局限于某一方面，而是实现了全面的提升，包括性能端到端的优化以消除瓶颈，为客户实际应用带来真正的价值；Serve less的平滑弹性扩展；稳定安全的系统加固；成本的有效优化；以及对多算力平台的广泛支持。
11.月之暗面使用 CPFS 加速模型训练
分享客户案例——Kimi。它可能是最全面使用或享受到我们产品能力增强的客户之一。简单来说，预案的原始数据集存放在OSS上，许多预处理工作也在OSS上完成。之后，通过高性能的数据流动技术，这些数据被拉到GPFS上进行训练，这个过程对性能和带宽的要求非常高，达到了TB级别。在数据写入和切换时，频率也非常高，给存储系统带来了很大的压力。同时，关键业务路径上还存在许多小IO操作，这意味着我们需要在大块数据吞吐和小IO操作之间找到平衡点，既要快速完成大块数据的处理，又不能让小IO操作受到影响。在满足这些条件的前提下，预案频繁产生的气化模型文件最终会落回到OSS上，并且根据业务逻辑，这些数据和模型文件会时不时地被拉回到CPFS上做进一步的处理。预案使用的是我们的大容量规格产品。
二、CPFS在LLM训练中的创新与演进
分享人：阿里云智能集团资深技术专家 徐立
1. 大模型训练对存储的挑战
首先，来看大语言模型训练中对存储所提出的重大挑战。第一个挑战是模型参数的十倍增长，这背后所反映的是计算规模的急剧扩大。如今，常规训练所使用的计算卡数量已基本达到万卡量级。第二个挑战来自于数据集，例如最近Meta发布的Llama3.1模型，其Token数高达15万亿，参数量也达到了405B。这背后实际上揭示了存储规模的庞大需求，存储规模的需求体现在两个方面：一方面是文件数量的激增，尤其是小文件数量特别多，特别是在自动驾驶等场景中，小文件的规模更为庞大；另一方面，随着多模态技术的演进，大文件的数量也会逐渐增加，文件总数最大可能达到数十个PB的规模。第三个挑战是CheckPoint的频繁性，其时间间隔不断缩短，这反映的是容错规模的扩大。因为在万卡规模的集群中，GPU的故障率相对较高，随着集群规模的增大，整个集群的故障率也会不断上升。因此，为了减少GPU算力的损失，CheckPoint的时间间隔需要更短。同时，现在的GPU训练框架，如PyTorch等，基本都标配了异步IO功能，这使得CheckPoint的频率以及每次CheckPoint的时间也在不断缩短。第四个挑战是在训练启动或Phiolo情况下，所有计算卡需要同时加载模型文件，这对模型加载的延迟提出了更高的要求。这是从去年的千卡规模到现在的万卡规模变化所带来的参数和数据规模上的显著变化。
2. 存储诉求关键要点
从存储的角度，可以总结为以下四个关键点。首先是瞬间冲击的Burst IO问题，这主要体现在CheckPoint过程中，CheckPoint变得更加频繁，且要求瞬间完成。第二点是最大延迟的稳定性，这不仅仅针对切换操作，需要在极短时间内完成，同时在GPU的关键路径上，如读请求、元数据请求以及小块写请求等，都需要保证可预期的延迟。第三个方面是持续的高QPS和高吞吐，这主要体现在数据集的处理上，例如一些元数据操作，如查找或获取操作，我们观察到至少达到百万级别的QPS，同时吞吐最大可达到数百GB。最后一点是存储系统的稳定性和安全性，这是存储系统的基石。
接下来，我们进一步剖析整个训练的IO模式。之前已经提到过，左上角的图表展示了训练过程，包括数据并行、模型并行以及张量并行等持续迭代的训练步骤。在这个过程中，主要涉及两类数据：数据集和检查点数据集。从去年的文本数据到今年的多模态数据，数据集发生了一些变化。数据集分为小文件和多模态大文件两类。小文件包括一些文本文件和自动驾驶类文件，其中部分小文件规模较大，接近百亿级别，并且其请求的QPS非常高，例如自动驾驶类文件的读或查找操作，最大能达到数千万的QPS。多模态大文件则主要特点是容量大，达到PB甚至数十PB的规模，并且在实际应用中，多模态数据的访问吞吐变得更高，有数百GB的读吞吐需求。
对于CheckPoint而言，可以分为两类：一类是模型检查点，用于推理过程中的分发；另一类是每张GPU卡优化器中间状态的CheckPoint。这些CheckPoint会在瞬间写入存储系统，对整个存储系统的聚合写带宽提出了非常高的要求。在实际应用中，我们观察到有数十GB甚至百GB吞吐的工作负载。
在训练任务启动或切换时的读操作，主要体现在聚合节点去拉取模型文件。我们对存储的诉求进行了关键要点的总结，主要包括以下几个方面：第一是Burst写吞吐以及最大延迟的可控性，前面已经提到写吞吐可达数百GB，并且P99延迟要更加可预期。第二是分布式元数据的管理，面对百亿级别的文件量，无论是小文件还是其他文件，如何更好地管理这些文件，对元数据的性能，如查询和访问性能，有非常高的QPS要求。第三个方面是数据集的高效访问，特别是在规模化计算力下访问存储时，体现的是并行访问的吞吐能力。第四个方面是P2P分布式读缓存的加速，这主要体现在同一个模型文件在FIOS加载或启动时的加载速度上，我们也观察到有数十GB甚至百GB的吞吐需求，这是对存储读吞吐的一种考验。最后一个方面是高性能存储离不开硬件的支持，我们更需要全闪存储介质以及RDMA高性能网络的加持。
3. 大模型加速 CPFS 技术创新
进一步探讨CPFS在大模型加速方面的技术创新。现在我将从技术和架构的角度来深入剖析。
整个架构自上而下是一个分布式的并行架构。架构的最上层是弹性文件客户端，它能够利用GPU服务器上的内存和本地磁盘构建成分布式缓存，为读写访问提供加速能力。第二个关键部分是存储虚拟网络通道，这是一个至关重要的技术，它利用GPU上的智能网卡提供高性能且安全的存储访问通道。第三个方面是RDMA网络，这不仅体现在存储集群内部的RDMA网络，也体现在计算和存储之间的RDMA连接，并且计算和存储之间的网络实现了存算分离。再往下一层是CPFS的集群构建，它提供了全分布式的元数据管理以及数据并行管理能力。在架构的最底层是硬件介质，这里使用了全闪的物理存储服务器，通过存储服务器资源的优化来提供多种Serverless能力。
这里的关键的性能指标。例如，单路的4K读操作能够达到200微秒。在10万卡这种大规模集群上，整个集群的总吞吐能达到20TB。此外，还包括3亿的总OPS。最底下的指标是在真实的通义千问大模型训练中，昨天发布的通义千问在CPFS上进行训练时，在数千卡规模的训练中，我们观察到数据集的访问有240GB的持续吞吐能力，并且在瞬间能够达到80GB的吞吐。
4. 各层技术展开
接下来，一层一层地展开介绍每一层的技术。首先是弹性文件客户端，它主要利用计算侧，特别是GPU侧的内存和本地磁盘来构建分布式缓存加速。同时，它构建了单机缓存和分布式缓存，并在分布式缓存上提供了P2P加速。P2P加速主要针对同一份文件在瞬间被多个计算节点访问的场景，提供加速效果。我们提供了单个计算节点在顺序读场景下的3GB吞吐能力，并且聚合带宽可以随着计算节点的水平扩展而提高，提供更高的聚合水平扩展能力。
5. 弹性文件客户端（EFC）为大模型提供读写缓存加速
关于弹性文件客户端，它与底层的存储集群之间通过EFC通道提供物理硬件的数据直通能力以及对应的RDMA技术。这种技术能够支持多连接负载均衡，满足高吞吐、低延时的需求。EFC也是面向容器的，完全兼容POSIX标准，提供容器级别的隔离和QOS能力。同时，它还面向容器提供了Access Point来做权限访问控制。
6. Virtual Storage Channel为大模型提供高性能安全存储访问通道
前面已经提到，我们面对不同的计算场景时，存在很多复杂的异构计算环境，如不同算力、不同网络环境、不同网卡等。在这样复杂的异构环境下，要为每个租户提供高效且安全的存储访问，同时还要保证非常高的吞吐和低延时的存储性能要求。VSC在这方面做了一些技术架构上的创新。第一方面是实现各种计算环境的统一，这是非常重要的一点。它能够将我们的计算上层（包括单租户、多租户、物理机以及容器，如安全容器和Runc容器）统一起来，通过一套技术架构去访问底层的存储。第二方面是提供安全高效的访问通道，支持软硬一体的技术，单个计算节点能够达到25GB的吞吐访问能力。第三方面是能与存储系统紧密关联，与CPFS做好协同，提供请求级别的负载均衡。另外，VSC还通过了标准的RDMA v2协议，提供高性能的存储网络协议。
右边的架构图展示了VSC的Agent有多种部署形态，既可以部署在智能网卡上，也可以部署在物理服务器上，起到弹性客户端和存储服务节点之间的桥梁作用。
7. I/O 调度提升有效吞吐和控制最大延时
在IO调度方面，我们致力于在有效吞吐与控制最大延迟之间找到平衡。随着万卡规模逐渐成为常态，CheckPoint的瞬时写操作愈发频繁且密集。为了提升存储系统的整体效率，我们在以下几个方面进行了优化。
首先，着重控制了P99延迟，这涵盖了CheckPoint操作以及PyTorch框架下的各类I/O操作，如数据集读取、数据操作、元数据访问和日志写入等。具体而言，我们采取了多项措施：在存储系统中，当没有CheckPoint时保持系统平稳运行，而当CheckPoint发生时，迅速应对以避免队列拥塞。我们实现了IO的异步处理和聚合，同时针对不同类型的请求（如写、读和元数据访问）设置了独立的队列，以确保延迟的可预测性。即使对于同类请求，我们也提供了多个队列来优化处理。当队列长度超过阈值时，我们会尝试丢弃部分请求以减轻系统压力。此外，对于延迟特别敏感的IO，我们设立了高优先级队列，确保它们能够迅速完成。这些措施在高负载情况下有效减少了超时和底层存储系统上的无效IO，从而提升了有效吞吐。
其次，在避免热点方面，我们实现了集群IO的负载均衡。这主要通过客户端与服务端之间的协同工作来实现。利用前面提到的EFC技术，结合存储系统的感知能力和数据的局部性特征，我们将IO调度到负载较低的服务器上。同时，在底层存储集群层面，我们对数据进行了分片处理，并将这些分片充分分散到不同的存储单元中，以实现IO在整个集群上的均衡分布。
最后，在有效吞吐的控制方面，我们设定了合理的吞吐水位。当检测到集群接近或达到这一水位时，我们会及时扩容，以确保有效吞吐的可预期性和可扩展性。
再往下一层，CPFS与底层对象存储之间的数据流动速度对于提升数据集训练效率至关重要。特别是在多模态数据广泛应用的情况下，许多数据存储在对象存储上，而CPFS则作为桥梁，将OSS的数据高效流动到CPFS上进行高性能IO访问。为此，我们进行了以下技术创新：一方面，我们实现了单个文件5GB的数据流动能力，支持从OSS到CPFS的导入以及从CPFS到OSS的回流。这通过数据分片技术和多节点调度来实现。同时，在数据传输过程中，我们采用了CRC校验来确保数据的准确性，并且这些校验是并行进行的。另一方面，在单个区域内，我们支持高达100GB的数据流动。为此，我们配备了弹性的传输资源，这些资源能够按区域动态扩容。在数据传输过程中，我们通过性能隔离和优先级控制来确保训练任务不受影响。
接下来，了解一下整个存储的网络架构。一个高性能的存储系统离不开高性能的网络架构。正如NV首席执行官所说：“网络是计算机。”在AI训练中，除了GPU之间的通信外，GPU与存储之间的通信也是网络流量的重要组成部分，特别是在CheckPoint和数据集方面。
阿里云在最近的会议中发布了HPN7.0网络架构。如右下角所示的网络架构图，其中包含了200G的网络带宽、1:1的收敛比、交换机的双平面转发以及RoCERDN等先进技术。这里我们主要关注的是存储系统的设计。从图的右下角可以看出，存储系统是以独立的Pod形式进行设计的。在GPU上配置了8+1张网卡，其中八张用于GPU之间的通信，而另外一张则专门用于CPFS的数据流量。这张网卡在物理层面实现了与计算流量的隔离，GPU上的IO数据通过这张网卡直接连接到存储分区的交换机上，无需经过计算节点的交换机。这样的设计在物理层面实现了网络隔离，使得计算和存储能够互不干扰地运行。这就是我们的网络架构设计思路。
8.CPFS Serverless 化提升稳定安全能力
在过去的一年里，我们不仅专注于性能优化，还投入了大量精力进行多租Serverless化的工作，旨在提升系统的稳定性和安全性。在全托管服务领域，我们显著提升了用户体验，例如，文件系统的管理、创建以及扩容等操作均可实现分钟级别的响应速度。此外，得益于CPFS在计算端的EFC技术，结合DPU和服务器架构的优化，我们的系统能够支持多种计算形态和网络形态，确保一份数据能够被多种算力高效访问。关于系统的弹性能力，前文已有详细介绍，此处不再赘述。
在安全和隔离方面，从管控层面入手，实现了资源组的隔离管理，支持对文件系统和挂载节点的独立管理。在数据管理和隔离层面，单个计算节点能够安全地挂载并支持多租户的安全访问，同时，我们支持多租户的扩展，并通过性能隔离技术，确保不同租户之间的服务质量不受影响。为了进一步提升系统的稳定性和安全性，我们提供了系统级的回收站功能，有效防止数据误删。此外，我们还对端到端的高危操作（特别是删除操作）进行了审计日志记录。最后，在可观测性和可度量性方面，我们提供了针对任意类型IO的审计日志，以满足用户的多样化需求。
