Google 迎来「DeepSeek 时刻」：TurboQuant算法实现bit无损、×加速、×压缩、零预处理

AI训练存储选型的演进路线第一阶段单机直连时代早期的深度学习数据集较小模型训练通常在单台服务器或单张GPU卡上完成。此时直接将数据存储在训练机器的本地NVMe SSD/HDD上。其优势在于IO延迟最低吞吐量极高也就是“数据离计算最近”。缺点也很明显数据孤岛多台机器无法共享数据数据拷贝scp/rsync)及其耗时。容量受限本地磁盘容量有限。数据安全数据没有冗余机器或盘挂了数据可能就丢了。第二阶段传统共享存储时代NFS/NAS到后来开始团队协作训练规模也变大则需要多机多卡分布式训练同时出于使用方便大家希望像操作本地文件一样操作共享数据。此时开始以NFSNetwork File System)挂载传统的NAS存储阵列来使用。其优势在于POSIX兼容不需要修改PyTorch/TensorFlow代码直接读写文件路径共享也十分便利所有节点看到的目录结构一致。缺点则在于元数据性能瓶颈NFS在处理海量小文件的open,lookup操作时元数据服务器可能被瞬间打死。另外所有计算节点抢占同一个NAS的出口带宽也可能导致GPU等待IO造成GPU无法维持高使用率。第三阶段大数据融合时代HDFSGoogle等大厂入局Hadoop诞生。数据存储在HDFS上通过一些软件层面的优化将大量小图片打包成大文件变成“顺序读”训练代码通过API读取。这样就能够极大地利用HDFS的设计初衷吞吐量极高、大规模顺序读同时还能利用现成的大数据基础设施。但同样有缺点生态割裂PyTorch对HDFS支持不如TensorFlow友好。随机访问差对于需要频繁Shuffle(随机打乱)的数据集HDFS性能不佳。Java开销HDFS客户端通常较重占用CPU资源第四阶段高性能并行文件系统HPC/Parallel FS)此时的AI领域进入超算时代模型越来越大对低延迟和超高带宽的要求极高。此时的方案是借用超算HPC领域的Lustre或GPFSIMB Spectrum Scale)。优点在于专为高并发设计可以轻松喂饱数千张GPU支持POSIX且元数据性能极强。缺点则在于贵运维难Lustre等系统内合级调优十分困难一旦集群崩溃恢复十分困难扩容困难很难像云存储那样弹性伸缩。第五阶段存算分离与分层架构Object Storage Cache)当前这个时代即云原生时代数据集达到PB级别成本成为了核心考量。对象存储最便宜且容量无限但性能尤其是元数据不够好。 此时针对元数据有了若干解决方案方案一 原生对象存储格式优化这种方案将数据存储在S3客户端使用S3 SDK进行对接以对象存储的接口访问文件。同时降低小文件数量对小文件进行打包。此处的缺点则在于丧失了POSIX标准。方案二对象存储高性能文件网关这是目前的最终形态也是本文将要讲的形态。其底层数据存储在对象存储中S3、COS、OSS、ceph在用户和对象存储层中加一个中间层作为文件系统层负责将文件系统与对象存储的操作进行翻译转换从而实现POSIX兼容。而最重要的是在GPU训练节点的本地NVMe SSD上建立热数据缓存以提升IO能力。此时第一次读取时从对象存储拉取数据过程稍慢而后续的读取则可以直接走本地缓存极快。而一些实现如JuiceFS)将元数据独立放在Redis/TiKV中可以完美地解决对象存储list对象的性能问题。据最新的企业版JuiceFS文档说明当前单机文件系统已经可以支持5000亿级别文件本文将以“对象存储高性能文件网关”的技术路线的现状进行分析描述业界若干实现的设计思想抛砖引玉。Object Storage Cache的一般性设计原则本小节介绍Object Storage Cache的一般性设计原则。在介绍之前首先需要理清楚文件系统与对象存储的区别是什么文件系统对接对象存储需要做哪些工作之后才考虑性能的优化与可靠性的优化。文件系统与对象存储的异同点分析文件系统的核心特征如下所示层级结构数据以目录树的形式组织文件包含在目录中目录又包含在父目录中。寻址方式通过路径名来访问。数据可变性支持原地修改。应用程序可以打开一个文件seek到特定偏移量然后只修改文件中间的几个字节而无需重写整个文件。操作接口基于系统调用如open(), read(), write(), seek(), close(), flock()等。元数据如权限、创建时间、大小与文件数据紧密绑定通常存储在inode中。强一致性在单机文件系统中写入数据后随后的读取操作立即能看到新数据。原子性许多元数据操作如rename通常是原子的。对象存储的核心特征如下所示扁平结构数据存储在“桶“中没有真正的文件夹或目录层级。虽然看起来像目录但这只是对象键名key)中的前缀字符串。寻址方式通过key访问需要结合对象存储访问域名/IP来访问。数据不可变性对象通常被视为原子单元。无法修改对象的中间部分。如果要修改部分数据必须新上传一个对象来覆盖旧对象Read-Modify-Write。操作接口基于RESTful API(HTTP)主要操作是PUT上传/覆盖GET下载DELETE删除HEAD获取元数据不支持seek或部分写入。一致性模型不同的对象存储实现下有不同的一致性模型。可能是强一致性如ceph也可能是最终一致性。整理如下表所示image将对象存储S3 协议等挂载为本地文件系统FUSE是业界的常见需求目的是为了让不支持 S3 API 的传统应用也能利用对象存储的低成本和无限容量。由于我们在上一部分分析了“文件系统”与“对象存储”存在巨大的语义鸿沟因此这些 FUSE 工具的核心设计难点都在于如何用笨重的 HTTP 对象接口去模拟灵活的 POSIX 文件接口。业界主流有两个设计流派直接映射型1:1 Mapping文件对应对象元数据存放在对象头中。元数据分离型Metadata Separation数据存在对象存储元数据存放在独立的数据库中。对象存储的 FUSE 并不是完美的。直接映射型保留了数据的通用性但牺牲了性能和语义元数据分离型重建了文件系统语义和性能但把对象存储降级为了纯粹的“硬盘”牺牲了数据的通用访问性。设计优劣势分析1. 直接映射型 (S3FS, Goofys, Rclone)设计优点通用性强 写入的数据就是标准的 S3 对象。你用 S3FS 传上去的图片可以直接用浏览器通过 S3 URL 打开也可以被其他不使用 FUSE 的程序处理。部署简单 无需额外部署数据库只要有 S3 账号就能用。无状态 客户端挂了重启即可不依赖外部元数据服务。设计劣势元数据性能灾难 S3 处理元数据非常慢。执行 ls -l 可能会很慢还可能造成集群slow op。重命名原子性缺失 在 S3 中没有“重命名目录”的操作。重命名一个包含 1000 个文件的目录S3FS 需要执行 1000 次 Copy 1000 次 Delete。这不仅慢而且如果在中间崩溃目录会断裂一半在旧名一半在新名。无法支持随机写/追加写 修改 1GB 文件的最后 1 个字节S3FS 必须下载 1GB - 修改 - 上传 1GB。效率极低。2. 元数据分离型 (JuiceFS)设计优点极致性能 元数据操作ls, getattr, rename都在 Redis/SQL 中完成延迟是微秒级与本地文件系统无异。完全 POSIX 兼容 通过将文件切块Chunking实现了对象存储本身不支持的“随机写”和“追加写”只用重传修改过的那个 Block。原子性保障 重命名目录只是数据库里的一个事务瞬间完成且原子。缓存能力 通常带有强大的本地缓存机制利用本地磁盘缓存 S3 的数据块。设计劣势数据不透明黑盒 你在 S3 Bucket 里看到的不再是 photo.jpg而是 chunks/1/123_456 这样的分块数据。脱离了 JuiceFS 客户端你无法直接识别和使用 S3 里的数据。运维复杂度 需要额外部署和维护一个高可用的元数据引擎如 Redis 集群或 RDS。炯下沂前