引言
随着人工智能与大语言模型的飞速发展，GPU 的角色正在从 CPU 的协处理器，逐渐转变为系统的计算中心。然而，数据 I/O 却日益成为其性能瓶颈。如何让 GPU 高效直通存储，尤其是在处理 AI 推理中海量小 I/O 请求时，已成为系统研究的前沿课题。
近期，我们解读对比了 GPU 文件系统方向的两篇顶会论文——来自于厦门大学/上海交通大学张一鸣教授团队的 GeminiFS (FAST 2025) 和来自于伊利诺伊大学香槟分校 Jian Huang 教授团队的 GoFS (SOSP 2025)。其中，GeminiFS (FAST 2025) 这项工作源于作者在华为实习期间面临的真实业务挑战，在短短四个月的极限开发和投稿过程中，他和团队实现了一个创新的“GPU 伴生文件系统”。
GeminiFS为 GPU 设计了一个由 CPU 主管的伴生型文件系统；GoFS则绕过 CPU 构建了一个由 GPU 主管的文件系统。
存储前沿技术评论，公众号：存储前沿技术评论【论文解读】如何构建 GPU 文件系统：缘起 GeminiFS (FAST'25) 和 GoFS (SOSP'25)
本文对 GeminiFS (FAST 2025) 论文的第一作者——来自厦门大学的博士生仇实进行专访，带您深入了解：
这项研究工作背后的灵感来源、投稿历程；
GPU 文件系统的研究动机、技术挑战、发展趋势；
一位博士生在系统研究与产学研结合中的成长与思考。
专访内容
1、GPU文件系统是当前一个具备开拓性的方向，请谈谈发现这个方向和形成idea的机缘，以及开展 GeminiFS (FAST 2025) 研究工作的历程。
GeminiFS 是我在华为2012理论研究部实习的时候完成的，我在华为的导师姚信博士给了我一个业务需求，就是在单台服务器内实现大模型的训练/微调。但是当时910B的HBM以及主机内存加起来都不能满足训练内存需求，只有将中间参数通过卸载到SSD上才能满足内存需求。当时华为NPU的访存仍然需要通过传统的文件系统加载到主机内存，然后再通过内存拷贝的方式实现，NPU I/O性能极差，甚至没有类似英伟达GDS的能力。因此我们就开始了NPU直通存储方向的研究。
我们一开始测试了英伟达的GDS，但是我们发现他小I/O，多线程的性能极差，甚至还不如传统路径。于是尝试使用SPDK或者io-uring NVMe passthrough等一些程序直管存储的方式优化I/O性能，但是这种方式缺少文件系统管理，我们需要仔细分配每个内存对象读写的起始地址，适配到现有训练框架的工作量让我们绝望。我们又尝试用了一些开源的用户态文件系统，但是在多卡多进程的情况下根本没办法共享NVMe设备，进程间数据共享的效率很低。这让我们意识到一个中心化的文件系统仍然是十分必要的。
恰巧那年，看到了ASPLOS'23 上的BaM，并仔细阅读了其代码，其GPU进程使用NVMe设备和SPDK一样。但是我们发现其NVMe驱动里的Admin队列仍然在主机上，而I/O队列被一个GPU进程管理。于是就有了这样的想法：内核里的NVMe队列是否也能细粒度的分割，这样内核的文件系统仍然存在，而GPU进程使用一部分NVMe队列进行直通以提高I/O性能。只需要在CPU 和 GPU之间高效的共享元数据就可以实现一个共享的文件系统。后面，我和我的导师张一鸣老师以及港科大陈凯老师讨论了一下这个idea，他们十分认可并且在讨论中对idea进行了拔高，于是有了伴生文件系统GeminiFS 。
2、FAST 评委是如何看待这项工作的？有评委给了最高分5分，这在顶会评审中十分难得，但也有评委给分较低，他们有哪些主要的认可和质疑？
这次FAST分数是53322。我觉得能一投就中是很幸运的。当然5个评委对我们设计的创新型性、合理性以及性能都表示了肯定。质疑主要来自于1.当前的设计是否能支持完美的访问控制和崩溃一致性；2.对于动态的负载该怎么处理；3.以及当时的实验GPT2-124M training似乎并不需要SSD。
访问控制和崩溃一致性是我们的设计一开始缺乏思考的。但是这在我们设计上并不难实现，于是我们在rebuttal的时候详细陈述了如何通过主机侧内核实现进程间的访问控制。但是不得不承认恶意的GPU直通的I/O是没办法的，不过可以借鉴Devfs(fast'18)在硬件内部提供访问控制。
至于动态的负载，在AI场景下可以通过预先分配一些文件进行解决，我认为并不是Gofs里说的那么难以解决。
Geminifs的实验确实并不那么完善，因为当时从0到投稿只有4个月的时间，我和我的小伙伴胡意凡，刘伟楠每天的睡眠时间都不到6个小时。我们最终实现的版本只有C++接口还有很多bug。然而现有的LLM训练/推理框架都是十分复杂的。我们只能和较为简单的LLM.c进行集成。针对这个问题，我们rebuttal的时候严格论证了实验的合理性。
3、你在华为公司实习了两年，通常在公司做的事情偏工程性，而对于博士生，做研究和发论文是第一要务。特别地，你做的是系统研究，既要求理论创新，又对工程能力要求高。这段实习经历对这项研究工作、乃至你的读博生涯产生了哪些影响？
虽然我在公司实习，但是我所在理论研究部主要面对业务上一些需求和问题开展研究，并给出理论模型和解决方案。我当时的领导张弓还有姚信博士总是能拉到一些有趣但是很棘手的研究，并且讨论是否能用一些新的方法或者硬件解决问题。比如我实习第一个活是DPU文件系统，目标是在DPU上构建一个面向BOF的文件系统然后向主机应用直接提供文件系统，以减少主机测CPU的使用。
从博士生发论文的角度来看，这段研究比较失败的。项目过程中基本是都是工程的活，最后因为软件环境受限这个研究也无疾而终。但是我接触了大量底层硬件的代码还有文件系统相关的知识，较大的提升了工程能力。另外失败经历也促使我会在可用性，软件/硬件可行性以及可扩展性等多个维度去批判一个工作的合理性，后续开展的研究也会更希望其能落地。
4、GPUDirect Storage (GDS) 在I/O数据面绕过CPU，BaM进一步在控制面绕过CPU，而GPU文件系统在此基础上提供文件抽象。这背后的核心驱动因素是减少I/O处理软件开销，包含CPU与GPU之间的同步开销和CPU软件栈开销。这些开销在小I/O负载下十分凸显。然而，GPU采用高并行的计算架构，只有输入大量数据才能发挥它的带宽优势，GPU应用的设计原则应该是尽可能生成大尺寸I/O请求。那么，哪些GPU应用场景包含大量小I/O请求？以及，大I/O负载下软件处理开销相对低，GDS的性能表现如何，bypass CPU是否必要？
现在AI场景下，GPU访存主要的需求可能有训练数据集，KV Cache/RAG，checkpoint。其中Checkpoint的I/O粒度通常比较大，且并发度并不大，GDS/GDR也可以有较好的性能，并不需要bypass CPU。训练数据集的大小一般是是几十KB到几百KB，已经算是比较小的I/O了。因此许多工作会将许多输入压缩成一个大文件传输。在训练这种可以预加载的场景还是比较有效的。
而KV Cache是典型的小I/O负载，KV矩阵的大小受到模型设计、量化策略以及并行计算策略等策略影响比较大。而且，目前主流的LLM推理框架（如vLLM、Sglang）为提高计算效率和减少内存碎片，都会采用内存分页的方式将GPU内存分成固定大小的页。然而，在这种内存布局下，将一段逻辑上连续的KV换出到NVMe上时，内存碎片会转化为IO碎片。以一个64层的模型为例，如果要换出128K长度的KV，需要传输的内存对象的数量为2*64*128K。即使将多个token（比如16）合并成一个Block，就会造成上百万的离散小I/O。
现在高效的传输放啊通常是利用GPU kernel进行数据聚合然后内存拷贝，最后再写回SSD，仍然会有一定的传输与操作开销，导致GPU阻塞。在较长的KV传输场景下，CPU控制开销是十分巨大的，在这种情况下就非常适合将控制路径卸载到GPU上。
GDS有限的并行性肯定是完全无法适应这样的负载的，其GDS较大的控制开销以及有限的并行性反而会导致较差的性能。另外大家可以关注一下我们NICELAB最新的工作Phoenix SC'25，对现有的GDS框架进行了优化，实现了并发性能的大幅提升。
除了AI，典型的应用是GNN，GPU对于边的访问一般也都是小I/O。
5、为GPU构建文件系统是一个大胆创新的想法，请深入介绍下：在你看来，相比于现有系统，GPU文件系统的核心优势是什么？
目前看来，GPU文件系统的核心优势首先是性能优势，其避免了多次内存拷贝，可以利用GPU的并发能力提高NVMe设备的利用率，节省CPU。这在GPU访问一些即将到来的新型硬件比如NVIDIA与Kioxia联合研发的100M IOPS SSD上是有绝对优势的。
GPU文件系统另一个核心优势是更加贴近现在的AI计算模式。比如访存算子和计算算子可以加到同一个流内，计算算子结束后自动触发访存，大幅减少了调度难度和开销。另外访存算子也可以利用GPU的能力比如计算图，动态并行等能力，可以和很好的融入现有的AI框架并进行协同优化，而不是一个单独的第三方组件。
6、设计和实现GPU文件系统面临哪些关键挑战？在你看来，这些挑战在现有GPU架构下是否有破局之道？如果我们拍脑袋畅想未来，GPU架构可以如何演进，以高效地运行文件系统？
我觉得设计GPU文件系统最难的就是如何保证数据安全，可用性以及提升其可扩展性。首先，一个“完备的”文件系统通常在操作系统内核中运行，依赖OS提供的特权级来保证安全和隔离，而GPU Kernel 本质上是在GPU用户态运行的，它无法从硬件层面隔离文件系统守护进程和用户GPU程序。
另外一个困难是崩溃一致性，传统文件系统依赖日志来保证一致性。但日志系统依赖严格的顺序写入和屏障，GPU缺少对于完善的锁/临界区的支持。且在GPU的大规模乱序并行环境中极难高效实现。这在AI场景下还能接受，如果拓展到更加通用的场景是需要认真对待的一个问题。
从使用便利的角度来看，GPU文件系统的使用的内存仍然比较难处理。因为GPU内存都是由CPU调用GPU驱动分配的。GPU文件系统在处理IO请求之前，还必须调用驱动将虚拟GPU内存转换成NVMe设备可识别的PCI Bar地址，这都依赖CPU。GPU文件系统要想完全避免CPU就得提前完成内存分配与注册。在动态负载下，内存与元数据内存也都是动态的，很难不引入CPU开销。
对于上述几个问题，GPU和CPU共享内核是一个有效的解决方案，将伴生文件系统嵌入到内核里，然后CPU和GPU共享一块内存地址空间。由CPU来处理这些较为复杂且频率不高的操作，但这需要CPU和GPU之间通过高性能总线直连以及内核的支持。类似苹果MAC以及NVIDIA-C2C。
另外一个难题是可扩展，目前的GPU文件系统的访存范围还只限制在单机。通过GPU init RDMA或许可以访问传统文件系统。但是无法实现元数据的传输，可能需要依赖新型的高速一致性总线比如CXL/UB/NVlink。
7、你现在博四了，未来找工作有什么打算？期望去学术界还是工业界？
说实话还是想去工业界多一点。现在AI应用迭代速度很快，在学校开展系统方面的研究很难落到真实的系统环境。尤其是存储方向，通常都被看做一个第三方组件，很难发挥存储系统的最大价值。另外，一些新型设备，比如华为UB或者英伟达正在推动的亿级IOPS的存储盘，需要很高的投资，在学校可能接触到有点困难。如果有AI团队对我研究感兴趣，欢迎联系我:)。