先给采购判断
GPUDirect Storage（GDS）不能只按“服务器有 GPU、存储支持高速访问”作出兼容判断。它依赖从应用、CUDA 与 cuFile 软件栈、GPU 驱动、PCIe 或其他互连拓扑、存储驱动、块设备、文件系统，到容器挂载命名空间的连续数据路径。任一层不支持、版本组合不匹配，或主机与容器看到的设备路径不一致，都可能使访问退回传统 CPU 中转路径，或在初始化、注册缓冲区、打开文件时直接失败。采购条款应要求供应方按目标部署形态提供可复现的支持范围与现场验证结果。
GDS 实际改变的是什么
GDS 面向存储与 GPU 内存之间的数据传输，通常由 cuFile 接口参与文件 I/O 路径。其价值不等同于“所有读取都会自动绕过 CPU”，更不意味着任何 POSIX 文件访问都会获得同一效果。NVIDIA 在GPUDirect Storage Overview Guide中说明了该能力的组件、部署约束和兼容性边界。采购时应把应用是否调用相应软件接口、运行时是否装载正确库、目标工作负载是否使用受支持 I/O 方式列为前置条件，而不是仅核对设备宣传页。
文件系统必须单独确认
文件系统是数据路径中的实现层，不是可省略的挂载参数。应确认计划使用的本地或网络文件系统、其客户端或内核模块、底层块设备及存储协议，是否处于目标 GDS 与驱动版本的支持组合内。还要明确数据文件所在挂载点、挂载选项、权限模型及故障切换后的实际落点。一个常见反例是测试文件位于本地受支持路径，而生产任务通过网络文件系统、符号链接或分层存储访问另一挂载点；应用虽然能够读取，却未必沿预期路径传输。任何涉及版本、硬件或第三方文件系统的结论，均应以对应官方文档和现场环境复核为准。
不要把驱动兼容拆开采购
GPU 驱动、CUDA、GDS 软件包、存储客户端与文件系统驱动应按一个组合管理。分别满足最低版本并不能证明组合可运行，因为内核版本、驱动接口和运行时库的搭配仍可能影响加载与 I/O 行为。采购技术响应中应要求列出操作系统与内核、GPU 驱动、CUDA、GDS、存储客户端和文件系统组件的准确版本，并说明升级顺序与回退版本。CUDA 的通用性能实践也强调应识别并减少不必要的数据移动，相关原则可参见CUDA C++ Best Practices Guide；但该原则不能替代对 GDS 支持矩阵的逐项确认。
容器路径是容易漏掉的一层
容器部署时，主机可用不代表容器内可用。需要确认容器获得了所需 GPU 运行时能力，GDS 用户态库与配置可见，目标文件系统挂载点以正确路径和权限传入，且容器内设备、挂载命名空间和安全策略没有阻断访问。还应核对作业编排系统是否会把数据卷重新挂载到不同位置，或在节点漂移后切换到不同存储后端。只在宿主机执行验证而不在最终镜像、最终运行参数和最终调度策略下复测，不能作为验收依据。
把验证写成可执行动作
- 绘制生产作业从文件路径到 GPU 内存的组件清单，标出每一层的厂商、版本、挂载点和责任方。
- 以目标节点、目标文件系统和目标容器镜像部署最小读写程序，同时记录库加载、设备发现和文件打开日志。
- 分别执行 GPU 缓冲区 I/O 与既有 CPU 缓冲区 I/O，对照应用日志、系统日志及 GDS 诊断输出，确认是否出现不支持、兼容模式或回退信息。
- 在权限收紧、节点重启、存储客户端重连和作业重新调度后重复测试，确认路径不会因运行条件变化而漂移。
验收指标应关注路径而非单次速度
建议将“能够完成一次传输”与“在目标环境持续使用预期路径”分开判定。可记录的指标包括：cuFile 初始化与文件注册是否成功、目标挂载点和设备是否被识别、诊断日志是否报告回退、容器内外文件标识是否一致、错误是否可定位到具体层级，以及在代表性并发下结果是否稳定。吞吐或时延只能作为工作负载相关的补充证据，不能脱离文件大小、并发、缓存状态、拓扑和存储负载作横向承诺。
预先约定回退路径
当某一层暂不支持或现场验证失败时，应保留传统 CPU 参与的数据传输路径，并明确应用配置如何切换、性能预期如何调整、错误如何告警。回退并不必然表示系统不可用，但必须避免业务在未知条件下静默改变路径。对于必须依赖 GDS 达到处理窗口的任务，应把“目标文件系统、目标容器和目标节点验证通过”设为上线条件；对于可接受传统路径的任务，则应把回退模式、资源占用和故障处置写入运行方案。
WeChat
Profile