话题将深入探讨 CPFS 端到端性能优化策略，重点关注计算端缓存加速、智能网卡加速、数据并行访问及数据流优化，旨在构建高吞吐、低延迟的存储系统，为 LLM 训练提供强大支持。通过详细案例分析，我们将展示 CPFS 如何在 LLM 训练中发挥关键作用，不仅大幅提升存储性能，还能有效提高 GPU 利用率，从而加速大模型训练进程。
分享文件存储CPS，在 LLM 场景下的一些高性能存储技术。话题主要会围绕着三个核心部分去展开。第一部分就是介绍大模型发展对文件存储CPS带来的需求变化，尤其在性能、规模可扩展性以及数据管理方面的考验。总结面对这些挑战时如何通过技术创新来提升整个文件存储CPS的性能。最后总结并展望未来如何更好的支撑大模型的发展。
一、 大模型对存储存储性能挑战
首先分析大模型对稳定存储CPS带来的性能挑战。在如今整体的人工智能领域，大模型正在以一个前所未有的速度在飞速的发展，它的规模和复杂度也都远超以往。CPS它作为一个并行的高性能的文件系统，它不仅去提供了一个高IBS高带宽，还提供了一个低延时的这样一个高性能的一个RO。具体而言会面临三方面挑战。
1.计算规模不断扩大
第一是计算规模的一个爆炸式增长，现在大模型训练里面模型参数每年都以10倍的这样一个速度的增长，现在的一个参数规模已经从千万到万亿规模，在整个模型参数规模到十万亿的时刻也很快就会到来，这样模型的增长就很好的推动了计算侧需求。另外，整个大模型的能力也在不断的进化，开始只能进行一些文字对话，到后来可以生成视频。包括open ai发布的 OR 可以进行问题的分析和推导，能力越强所需要的算力就越多，从具体的训练而言，训练规模由原来的千卡已经快速的跨越到万卡甚至十万卡，发展趋势不仅仅考验了横向扩展能力，大量的计算节点带来的 checkpoint 的读写对存储的性能的考也是前所未有的。
2.算力多样性
面临着多种个人的算力。比如自研的、商用的，商用之间还有一些不同厂家的。在面对不同的硬件类型的时，必须具备一些高度的灵活性和兼容性来无缝的去对接不同硬件类型，除了能使用上这些硬件类型，还要保证在不同的硬件类型下，文件存储CPS还要具备高性能的访问能力。
3.数据集 50X 的增长
模型每年10倍的增长，很大的推动了数据集的增长，数据集呈现出一个每年50倍的增长速度，增长速度对存储的一个容量带来的挑战也是空前的。需要我们必须具备一些更加智能的数据管理以及生命周期管理策略，来支持日数据能够被快速访问。同时必须能够有效的利用一些温冷的传统资源，效率和成本之间进行平衡。所以面对这些挑战，必须去进行一些技术创新，才能满足大模型未来对存储的需求。
二、大模型全流程储存性能优化实践
1. 面向大模型场景的 IO 加速和优化
在整个训练过程中，一个高性能 IO是非常关键的，它直接影响了训练的速度和GPU利用率。首先看在数据集访问的场景。数据集的访问特征。在训练的一个完整的 epoch 过程中，会把整个数据集都加载一遍，epoch 最关键的是分为三步。
第一步会把完整的数据集进行在GPU 期间进行锻炼，之后会把完整的 epoch 分成多个批次，即多个iterations。在一个具体的单位里，首先会去读数据集，把这个数据给读上来喂给GPU，由GPU去训练，训练完之后和GPU之间做一些前院传播和后院传播就完成了，等所有完成了之后，epoch 结束会周期性的，有策略的选择去把 check point 保存。 供以后的故障恢复使用，可以看到在整个的 epoch 过程中，是把完整的数据集都去加载了一遍。但是在实际的训练过程中，往往为了最后训练的模型效果，训练最终会进行多次 epoch 训练。意味着完整的数据集在一次训练过程中是被反复加载的。这样重复反复加载的一个访问特征，需要去思考一个问题，即如何尽可能的去缩短它访问存储的 IO延时，尽快的把数据喂给GPU，从而提升整个训练过程的效率。
在大模型的加载过程中，复杂度其实也不容小觑，大模型的加载不同于小模型加载。大模型加载需要所有的GPU都参与，所有的GPU在同一时刻以及一定的时间内，必须把模型完整的加载到GPU显存里面。对文件存储而言，不仅仅意味着需要提供高流量，同时访问特质还呈现出比较明显的访问热点问题，由于每个GPU都需要独立的把模型加载到自己的选择里，可以想象有一本书，但是很多人都要去阅读它，这本书呢就会被所有人反复阅读。这个现象就是访问热点，访问热点本身会去加重存储设备的负担，进而成为 IO路径上的一个瓶颈，最终影响整体的效率，影响训练速度。
IO 加速：计算侧分布式 P2P 读缓存
为了去解决这些复杂的问题，引入了计算侧分布式 P2P 读缓存，在这个分布式缓存里面，首先在端上构建了一个单机和分布式的两极缓存。尽量的把数据集都加载到缓存里面，让它更靠近GPU，因为越靠近IO力度就越大，访问性能越快，其中单机缓存是用于缓存更热的数据，当应用访问数据集时是不需要经过网络的，可直接在本地访问，延时在幽秒级别，这种分布式缓存提供更大的一些容量可以缓存数据集乃至全部的数据集。同时这种分布式缓存还提供了计算侧，多计算侧的聚合带宽问题为整个训练过程中的吞吐提供了高聚合的带宽。另外，利用这种分布式的能力解决了在模型加载过程中的访问热点问题，把一个大模型切成很多块，这些块相当于分散在计算侧缓存里把热点散开。另外在这个计算测级C，拉取模型的时候，可以直接点对点拉取，拉取的效率非常高效的。分布式的读缓存方面，在开始的设计的时候，一定要保证性能的可扩展能力，要跟着计算节点的规模扩大而扩大。因为只有这样设计才能满足如今计算规模不断扩大，而他对文件存储性能的扩展的需求。缓存介质既可以支持内存，也可以支持本地内即本地磁盘。所以只要在计算册有一些闲置的一些资源，都可以使用这个加速能力，同时这一套能力，通过软件配置的，所以只要在客户端通过配置，那么就可以使用到加速能力。
通过优化整体的性能，提升效果非常明显。其中，单机吞吐提升3倍，多机吞吐线性扩展。性能扩展能力也是展现出了一个非常这个优秀的线性扩展能力。意味着不管在小模型加载，还是大模型场景下，缓存能力都可以提供非常优秀的性能能力。
训练过程中会遇到的另外的问题，常见实际线上生产过程中的流量情况，分别是 check point 写瞬间流量，checkpoint 读瞬间流量。它们有两个特点，第一，它们的峰值持续的时间非常短，一般都在一两分钟。第二，流量高峰和平常的流量和中间的差距非常大，有几十倍甚至那个上百倍的差距。
以 checkpoint 的写为例，探究瞬间的冲击流量对整体的系统冲击有多少影响，发现冲击是由一 checkpoint 所带来的，原来在训练过程中是同步的，和训练是创新的去执行的，训练完打 checkpoint 的时候，checkpoint从显存里面到后端的存储上，直到存储完之后才继续进行，期间整个gpu算力是闲置的，包括客户和在阿里上的一些平台，整体为了提升gpu利用率，把同步 checkpoint 变成了一个异步 checkpoint ，也就是当 checkpoint 从gpu显存里面，拷到cpu的内存上的过程就完成了。gpu 这时候继续训练，后台会从内存里面再去存储，从这个场景就可以看出，IO场景就变得更加复杂，变成冲击的写和训练过程的 IO相互叠加。在没有去打 checkpoint 的时候，整个后端存储集群的负载是非常低的，队列的深度也比较浅。所以只要有个训练中的 IO过来，请求基本上立刻被处理，延时也都是毫秒级别。但当有 checkpoint 写的瞬间冲击的流量进来的时候，就会把后端的这个服务器的所有的负载都打高，表现为 IO请求的队列变得很深。这时候如果有训练过程中有毒或者一些 IO 过来的话，IO在这个队列里等待的时间就势必会加长，平均延时就会上升，导致整体的训练的效率的下降。
对这个问题进行分析，是 IO 隔离性的问题，针对不同类型 IO ，分别用不同的队列去隔离开，这样就可以做到 checkpoint 写对读或者说对原数据操作是不会受到影响的。有了这步优化之后，它对毒和原数据没有影响，但发现实际的用户的训练的一些任务时长很长，整体的基本利用率还是很低。其实他在训练过程中，除了读数据集，还有写日志，包括 checkpoint 的写答。若写请求用一个队列，这个瞬间的 checkpoint 大并发的请求对训练过程中并发量很小的写，有很大的冲击。最坏情况甚至会把这些写给饿死，那么就会出现一些秒级 IO，进而影响整体的训练效率。因此针对不同类型的 IO 也会按文件力度去拆队列，同时配上 IO 调度的算法，保证既有小并发的写的时候延时不会被饿死，同时在没有小并发量写的时候，又能把 checkpoint 的吞吐能够使用到整个文献系统的上线。
最后提供了 IO 的优先级，因为实际训练过程中有些应用对 IO 延时非常敏感，希望 IO 服务端能够立刻被处理，不希望等待被调度。这里可以针对一批文件或者一些对延时非常敏感的文件进行 IO 优先级的设计， 这样的设计第一时间是不需要经过 IO 调度，直接发给后端的存储设备，从而来保证延时。
优化不仅涉及个客户端，还包括客户端内核，以及在网络设备上存储服务的后端。所以优化效果非常明显。在有 checkpoint 写的时候发现其他类型的 IO，它和没有 checkpoint 写的 IO基本上延时和之前是一样的。
在实际的过程中，存储服务器上只要有些热点或一些负载不均衡，也会直接导致训练效率的下降。问题本质上和冲击问题类似，冲击把 IO的平均延时上升，但是负载不均衡，会导致 IO 毛刺，延时很高。导致整体的训练效率的下降，整个大模型训练过程不仅要求可以提供一个高吞吐，对延时的要求非常敏感。不仅要求平均延时好，而且要求 P99 的延时也非常好，在整个基础训练过程中它的最小力度就是一个iteration，那这个地方最关键的三步发生在最后一步，前向传播后向传播里面。前向传播后向传播需要所有gpu同步的进行操作，意味着如果有一部分gpu，读数据集包括训练已经完成了。但是少数的gpu因为读数据集出现毛刺还在训练，所以已经训练完的 GPU 他必须等还没有完成训练的gpu，这个期间整体的 GPU 是空闲的。P99 的一个 IO 延时是把整个集群的机构进行了影响，影响面积非常大。
为了解决这个问题，在系统里面，是有确定负载均衡的，但因为在大模型场景下，IO 的特征的一些手段，在这个场景下失效了，我们原来的这种的负责均衡，是面向这种更通用的产品，为了这种调度相对而言比较能保守，每台服务器上，都是统计自己过去一段时间的负载，而这个负载不是秒级的，是过去分钟级别的负载，在收集方面呢也不是实时的去感知，是周期性的去收集负载。负载收集上来才能最后去发生调度，所以可以看到响应速度非常慢，前面 checkpoint的整体的一个流量的冲击，它本身也就在一两分钟，等反应过来流量已经过去，也就失效了。
为了解决这个问题，必须在 IO链上能够如 request 级别去秒级别的感知负载，并且去把发生负载进行切换。做法需要客户端和服务端一起去配合才能完成。这个首先呢，我们服务端你必须能够秒级的去感受这负担，在服务端是有这个能力的，因为知道当前的 qos，以及当前的对立情况的，根据这个情况。客户端能实时的在 request 的级别感觉这个负载之后，可以采取一些策略，那么针对这种情况，可以去把这个他阀门的链接重新建立到其他机器比较负载比较低的机器上，通过这样的方式，可以做到秒级的负载均衡。
负载技能最终还是靠着单机的秒级的响应，和整个集群级别的控制一起配合，才能很好的控制延时，靠单机的秒级反应有可能在一些负载比较高的情况下，可能会造成一些血崩的问题。好处说它的响应很快，整个集群的负担是能看到全局的信息，但是反应速度比较慢。所以这两种策略必须结合，最终才能满足P99的整体延时。
2.高性能的存储算间通路技术
存算通路是什么，在 CPFS产品整体的架构中包括了最上面从计算侧的GPU机器上会有CPFS的EFC客户端，机器上也会插着DPU的一块智能网卡。请求经过网络之后会来到CPFS的大规模的存储后端。在这样的一个链路中间，将 EFC 发出请求开始，到后端收到请求为止的整个过程，把它抽象为一个存算间的通路，很明显可以看到通路是处在用户访问CPFS的必经之路上的主干道。性能就会影响CPFS 的整个的产品的性能表现。
如何去优化访问存储的一个主干道，关注的一些性能指标其实主要有三个方面。
第一，希望他具整个这个通路具有一个高吞吐能够把最新的400g的物理网链路的能力用满。
第二个角度，希望能够具有极低的延迟，能够端到端提供一个良好的低延迟的体验。
第三点很重要，当一些分布式存储里面一些异常情况发生的时候，希望它带来的异常的长尾的延迟也能够被控制到比较低。如果有这样的一些性能目标的达成，一方面用户能够获得很好的存储的性能体验，同时宝贵的gpu时间就能够得到更加充分的利用，来提升用户的计算资源的使用效率。
如何去达成这样的一些目标，主要进行两个方面的努力。第一个方面的优化，会把存算之间的通路做端到端拆解，来在端到端的去实施一些软硬件协同的优化。包括了有 dpu 卸载以及数据零拷贝以及高性能的传输层等等。
第二个方面是与存储的应用去进行进一步结合，是与大规模的分布式存储去进行协同优化，利用更多存储层面的一些应用信息来优化整个端到端的性能表现，这里面就包括了提供精准会话的机制，同时在请求往存储端去分发的时候会进行请求分发的优化。最后在计算存储之间，从上面对它的连接模式优化。
从这两个大的方面，来分别的展开具体的一些优化工作。首先，全链路的软件协同优化的重要的一点是，先要看计算到存储的全链路到底是什么样。从GPU机器上的CPI的客户端下来之后，会先到本机的GPU的智能网卡，最后到存储。因为这个架构里面很关键的一点是，中间引入了DPU模块。宏观上是重构了一个像阿里云这样的云平台，和最终使用云平台用户之间的协作边界，能够更好更优的进行协作。GPU模块的引入让很多平台层的软件，是可以被卸载到DPU上面进行运行的，而不会再占用用户测host里面的计算和存储资源。
所以会带来几个好处，首先整个平台层软件的运行是不会占用用户的比较高性能宝贵的CPU资源，间接提高了用户性能的体验，同时独立的DQ组件能够与用户的计算环境进行隔离，避免在CPU等等这样的一些硬件资源上的争抢。有了独立的环境之后，可以把一些性能的优化快速在这样的环境中进行迭代和发布。从而能够在对用户产生比较少的侵入的情况下快速的释放一些高性能技术的红利。有GPU卸载能力后做卸载，把平台层的一些软件给卸载到DPU上来运行。软件本身是使用了一些高性能的这样一种软件架构，比如 run to completion 软件架构以及cpu polling来降低延迟，同时整个软件能够运行在用户态避免内核态的一些开销。软件本身会产生很多CPU的开销。如果运行在后测，对后测CPU的浪费是比较严重的。但有了GPU之后，可以在dpu上比较低成本的CPU上去运行这样的软件，既能够快速的去迭代，同时也能够提升整个系统的性能和效率。
如果只是简单的做这样卸载的话，其实并不能达到最优的效果。有了卸载之后可以进一步的来做全链路的优化。进一步的去看这个GPU这里的一个数据链路，会发现最开始用户的数据会存在后侧的内存的buffer 里，如何把用户buffer的数据最快速的发送到存储侧，分析认为最快速的方式就是直接从用户buffer里去到存储侧。而不是经过一系列的各种软件的拷贝或者转发，为了达到物理上最优的效果，进行了计算侧的存储的控制路径和数据路径的一个分离。达到的效果是会产生绿色的高性能的数据链路，同时能够有蓝色的控制链路，控制链路会使用到DPU上的这个CPU资源。通过分离把数据链路上大块的数据的拷贝传输等卸载到DP上的专用的A或者P的硬件上来高效的进行。能够把CU上的CPU资源能够更多的释放控制链路，从而提升用户体验，有了这样的分离之后，进一步可以在这个数据链路上做很极致软硬件一体的零拷贝，一方面包括了整个的软件层次，从上到下能够直接把用户的buff发出去，不产生额外的拷贝，另外一方面，也包括了把 buffer 传输完全的卸载到硬件上来进行。有了这样的设计之后，对于整个计算侧的网络以及PC带宽等等这样的一些硬件资源，就能够有最有效的最极致的利用，从而提升系统的性能。数据往外经过零拷贝的处理，往外发送的时候不可避免的到怎样在网络上高效的去传输数据。
端到端链路的下一层，计算和存储之间高性能的网络传输。在这个网络传输上，有两个技术路线在一起做，第一个是 rocev2 rdma 传输层，在业界是广泛使用的，低延迟高吞吐，整个协议上能够完整的卸载到硬件上，也积累了大量的商用的经验，把这些经验复用到计算到存储在AI场景里面。我们如果通过一些自研的手段，可以进一步的去优化它的。因此，也做了自研的HPT rdma 的技术，特点是把整个的网络协议以及网络软件和网络硬件几个部分，端到端完全进行了软硬件一体协同的优化。就可以提供更多的网络层次的优化能力，比如说在HP里面能够支持网络的多度并行的技术，能够在某些网络路径异常时快速跳过网络路径。从而保证一个异常场景下，整个用户的长尾延迟被很好的控制。同时整个高性能网络的传输范围能够扩大到乘域的范围，而不局限在数据中心内部。好处是可以在更广阔的计算资源的范围内，让用户来体验到高性能网络的效果。通过自研的软硬件，在网络的端上能提供的网络链接的数量也会大幅的提升。有了更多的网链接可以利用这些网络链接来提升发送请求时候的并发度，从而降低排队延迟以及提高整个系统的吞吐。
这三个都是在从计算到存储这样一个全链路上，去进行的一些软硬件协同的优化。然后有了这样的一些优化之后，可以打造一个非常极致的计算到存储的一个高速高速公路，把高速公路应用到大规模的分布式存储的时候，还是会遇到一些新的挑战。因为分布式存储，后端会有大量的存储节点组成，每个存储节点也都可能会有异常。
所以如何去把高效的把这些存储节点能够能力发挥出来，需要进一步的从与存储的系统协同的角度去进行优化。就是与大规模分布式存储的协同优化。在这个协同优化里，第一点是在当计算端要访问存储的时候，首先就会面临请求往什么存储上发，最简单的做法让请求可以任意到存储节点去，其实就会带来一些对性能不太好的后果，多个存储节点都会需要维持和感知请求相关的一些状态信息，这里面就会引入额外的模块间的交互，增加延迟以及降低整个的存储，为了能够最高效的来处理对于文件的请求，引入了会话机制这个会话机制，让文件的请求比较固定的在一个节点上处理，会话机制进一步做成了精准的会话机制，精准主要体现在：由于整个软件站都是高性能的run to completion ，会在线程上一路运行到底来达到最好的性能，跟线程是有关联关系的。因此会话机制是支持了请求能够精准的投递到服务端的线程上去让请求让会话能够精准的绑定到服务端线程，从而达到最小的系统延迟。
第二个精准体现在存储侧有大规模节点的时候，有些忙有些闲，建立到忙的节点上的时候性能也会有下降。为了能够更精准的去选择到好的存储节点，提供了存储协同的会话的负载均衡机制。会话建立到哪个存储节点上，可以利用存储层的一些路由的一些建议和信息，把它输入到计算侧的会话建立机制里面。这样对存储层最友好，对均衡的方式来分布这些会话，从而来达到更好的性能。有了会话机制之后，就能够去处理请求。
但是再具体的看每一个请求如何被处理的时候，还有进一步的优化空间，第二个优化点就是进行请求分发的优化。对于请求分发而言，整体上希望达到趋利避害。趋利就是挑一些对请求处理起来更友好的节点来来进行处理。比如要读一个数据，数据最终会存在于某物理的盘上面，盘也会插在某一个存储的节点上，由这个盘所在的存储节点来处理请求性能最高，因为能避免一些网络上的额外跳出，来来提高吞吐以及减少延迟。所以能提供的优化机制就是能够让计算侧能够感知到存储侧的一些数据的分布信息，从而能够让计算侧能够找到想要访问的最好的节点。比如在读的场景里面就可以一跳的来读到存储侧的盘所在机器，从而能够达到最极致的延迟，同时也避免存储侧要去把请求转发一下，带来存储在网络上的一些带宽的开销。
第二个方面是避害。避害就是希望规避一些不太好的节点。也是在分布系统里非常常见的，有些节点由于负载高或者crash等等原因，导致节点暂时是不可用。如果在计算册还在让请求等待不好的节点的时候，会大幅的去增加用户的延迟，这样这些时间其实是被浪费掉，节点可能短时间也不会回来。在这里做优化是通过能够让存储能够协同，控制在计算侧整个的一个超时 timeout 的策略，能够以比较合理的timeout来等待存储侧的响应。这样，当存储册有一些异常的时候，能够快速的out掉，把请求给路由到另外比较好的机器上，就能够去控制整个在异常情况下的长尾的延迟。这是请求分发上进行趋利避害。
请求分发确定往哪分发之后，会进入到在网络链路层怎么样把请求发出去，进入到传输层怎么样做网络连接的策略问题。由于在AI场景里面，计算侧和增的规模都比较大，比如计算侧都在追求万卡、10万卡这种越来越大的规模，它访问存储就会带来在存储侧所产生的网络连接数量会非常庞大。而网络连接的数量在网络硬件上是有一些上限的约束。这样的背景之下，很多系统里的选择会在大规模下去让计算存储之间用一个网络连接。在很多系统里看到的这种设计比较简单，缺陷也比较明显，单个网络连接它能提供的并发能力是有限的，所以当AI场景下有大规模的这种请求发的时候，就会在网络链接上产生排队的延迟，从而降低整个系统的能力。因此对这个问题研发了一个smart link的技术。思路是当用户的规模没有那么大的时候，可以智能的让网络连接更多一点。能够去提供在single link模式下面能够额外的提供 sparse link，fullmesh 两种方式，sparse link 不止建一条链接，可以建多条链接。
但这个具体有几条链接根据当时整个系统的负载情况来进行动态的确定。最终能够进化到 fullmesh 形式，能在计算和存储之间两两都能够去建立链接，从而来提供最好的并发度，能够极大的去降低排队延迟，并且提高吞吐。有了这种模式之后，根据整个系统存储测以及计算的一些情况，来动态的进行模式的切换，也就是在传层链接策略上面所做的主要优化。以上主要从两个方面来介绍了这样的优化。第一是与在整个全链路上，能够协同的去把链路打磨到极致的性能。第二是进一步的来与存储的系统软件来进行协同，来能够达到结合应用信息的最优的优化，这些数据怎么样进入到系统，涉及到了整个数据流动相关的一些高性能技术。
3.智能数据管理
在大语言模型下，数据流动的使用的这个场景主要分为有四个部分。第一个部分是数据集的方面，训练需要用到的数据集，一开始数据集，可能存在oss存储的上面。如果要进行训练使用高性能的存储，需要把这部分数据流动到CPFS上面。第二点是进行数据训练完之后，这个数据集会发生一些变化。这些变化也需要流转到oss上面，最后还有一种数据类型，就是checkpoint，checkpoint 放的数据是整个训练的过程很多的轮次，每个轮次都会产生的checkpoint 的数据，checkpoint 的数据可能会达到百gb级别的量，经过非常多的轮次之后它的数据量也会变得非常多，如果还存在cps之上就占用了存储成本比较高，所以需要定期流动到oss上面，其他的一些训练的任务可能会基于这一次结果进行继续的训练，所以在oss之上，还会流转到其他 cpfs 之上，为其他的训练任务来提供数据。大概有四种类型，总结数据集合oss和cpfs之间的流动和checkpoint的数据在oss和cpfs之间的流动
checkpoint的数据在oss和cpfs之间的流动场景里面要求流动的性能要特别快。数据集在训练之前，先要从oss 流转到cpfs里边，如果它流转的速度很慢，会导致gpu等待的时间会很长。所以这个性能的要求就很很高，比如训练数据或checkpoint 的数据，要尽快的能够从oss流转到cpfs 里面，还有一个场景是训练产生的checkpoint ，如果流转的慢了产生了非常多的数据，会把的 cpfs 空间使用的比较多使用的比较满。gpu的训练就要等这部分空间，如果流转的很快，就会节省很多gpu的时间。
比如百万级的图片可以在分钟级别就流转完成，比如 checkpoint 可能是百 G 别的，它可以秒级就流转完成，在这整个流转的过程中有一个极致的可靠性，比如数据是不能够传错的，内容是不能错的，文件的数量也是不能丢的，有一些列一系列的这个机制来保障这些数据的可靠性。还有一部分呢就是整个流动的过程中都是实时可监测可监控的，可以看到流出了多少数据留了多长时间，流到了哪里。还有一个就是对于cpfs 集群来讲，大概有两部分的io的情况，一部分是训练的那部分io还有一部分是流转的这个io，要做的目标就是尽量减少流转的数据对于正常训练io的影响，最后一点就是整个数据流动产品的适用性，通过类似的架构简单的配置特别易用的方式来适用具有极强的适用性。
数据流动的过程中，过程总共就有三步。第一步是识别到有哪些文件要传输，第二步是如何利用集成的领域达到高性能流转目标，第三个是流转过程中怎么样去计算这些数据的调研。识别到哪些数据需要传输有一个对比，用传统的这种方式，从oss到CPFS或者是反向的数据流动，当要去扫描非常复杂的目录的时候，性能是不会特别高的。通过一系列的优化，比如感知原端的整个目录数的结构，去并行的去扫描，相比于传统的工具，会有10倍以上的性能提升。另外，原端和目的端可能有一些文件已经存在了，就没有必要再流动过去，扫描这个目的端，对原端和目的端进行对比，就可以识别出来哪些数据是真的要传，哪些是不要传的，去传输一些增量的结果。
集群式的传说扫描完了的结果如何能够把性能传输做的最好，就是利用集群的这个方式，比如说大文件的例子，一个大的文件怎么能够传输的更快？就是把这个大文件切很多分片，把这些分片做一些并行的任务，能够保障大文件传输的特别快。这有一个性能的指标，即大文件的传输通过这种方式，可以达到5g每秒的速度。另外还有一些场景里面，比如说类似图片文件的小就非常多的图片的文件，去做一些任务上的合并，小文件考验的是存储节点的原数据的能力，大文件考验的是存储节点吞吐的能力，如果整个集群上的任务编排的不合理，会导致某一些节点的原数据先达到瓶颈。有一些节点的数据吞吐的部分先达到瓶颈，所以就不能达到一个很好的传输的目的，通过将大大小小文件的任务进行一个合理的编排能够让集群达到 100gb吞吐的能力。
不同的用户之间流转的任务可能是不同的，有的用户文件特别多，既有大文件也有小文件，可以通过对每一个任务的每一个用户的任务进行一个合理的编排，比如扫描的任务和复制的任务，怎么样去做流水线化的编排，不同的客户之间任务有大有小，要做的目标就是如果对于需要流转特别多数据量的场景，尽量要加快流转速度不需要占用特别多的时间，对于小用户，要保证它和大文件，大量数据的任务的运行同时，保证不会饿死。所以就会把大量数据任务做一个合理安排。cpfs 大概会有两种类型的IO 的请求，一种是说GPU 训练的IO，还有一种情形就是数据流动和 gpu 训练的之间，他们会出现 cpu 争抢的情况，影响训练的速率。通过接入了CPFSQos 系统，可以去控制优先级，保障GPU的IO 能够优先的去完成，数据流动的这一部分的优先级会降低一些，去做一些对于训练上比较小的这种影响。
做整个传输过程中数据上的保障，大文件的情形会切很多的分片，并行的去传输。对于每一个分片来讲，都会去独立的去计算校验，边读出来数据边做校验，传输到目的端，对于每个分片还是会做一次校验，把整个大文件在目标端去合并出来。一个大文件出来，对于大文件的整体和原端的整体，会去做一次校验的对比，保证大文件在合并或者传输过程中，文件的内容不会发生变化的，保证文件的内容是正确的。第二就是很多小文件的编排上，放到了同一个任务里边，小文件就不会再切片了。小文件边读边校验，写到目的端，再把这个校验的数据读出来。所有的这些切分，所有这些数据集切分出来的任务，都会形成一个数据的报表，报表里面会讲传输的数据内容有多少，文件量有多少，最后会把报表进行一次合并，和原端扫描的结果进行一次对账的处理，去判断出整个同步的过程中会不会有出现数据错漏的情况。通过校验文件列表，能够保证整个过程中不会有文件出现漏传的情况，传输的过程中流水线有异步校验的能力。
关于查看数据流动，其实是后台的任务，用户想要看到这部分的内容情况，也十分的必要，因此提供了数据流动的可观测性。CPFS大概有两种类型的IO，一个是GPU训练的，一种是数据流动的，就相当于前台和后台的IO，CPFS会对于这些IO进行实时的数据的采集，采集的内容就主要有读写的吞吐，读写的IOPS有哪些内容，用户可以很方便的从两个渠道来获取监控的信息，一个是CPFS的控制台。这部分数据也接入了云监控产品，可以从云监控产品看出来数据流动的情况。
数据流动的服务是一个 serverless 服务，用户在使用的过程中，不需要额外的计算资源，用户也不需要感知整个调度的系统是怎样的，扫描集群有多少，复制集群有多少。是简单易用的，只要明白三件事。第一件事，明白数据源在哪里，第二件事，明白数据要布到哪里，第三是以什么样方式去做同步，只要知道第三件事就可以就总结，大概数据源从哪里来到哪里去，用什样的方式。
用这个服务有两种方式，一个是可以通过控制台手动的去配置，配置的项就大概有三项，可以通过控制台简单的去配置，还有一部分企业的能力。可以通过open API自动化调用这样的功能。第三部分就是训练前的这个数据集合，比如说放在oss之上的这个数据，和真正需要训练的数据所处的团队可能是不同的团队，也可能是不的公司，可能导致资源是跨账号的。oss上的数据可能属于另外一个团队，推理训练又是其他的团队。团队之间用的是不同的账号，那么数据流动，也提供了这种跨账号的能力。通过授权，就可以实现oss跨账号的数据同步能力，而且在同步的过程中也提供了大概有三种策略。第一个是策略主要解决的问题和目标端有一些冲突的时候，比如说目标端已经有了一部分文件再同步，同步过来这一部分文件会出现冲突的情况，冲突的情况下可以有多种策略可以选择。
如果目的端出现了同名的文件，可以选择跳过，也可以选择强制去覆盖，也可以选择去比较他们的更新时间。更新时间以更新的为准，数据流动服务，发起这个任务之后，会形成一个报表。每个任务都有一个报表，报表里面会非常详细的记录，数据流动的任务同步了多少数据，同步了多少数据量，每个文件同步的每个文件的大小，每个文件的修改时间，还有每个文件的校验是什么，这些都可以看到，能够审计到所有数据流动的情形。
三、总结
CPFS 在大语言模型AI训练的场景里面，做了很多创新和加速。比如IO级别的，根据不同的IO特点做了整个IO级别的一体优化。软硬协同，通过DPU卸载，零拷贝，传输层加速等技术。打通了oss和CPFS之间高性能数据流动的部分。
