AMD在10月5日的ROCm技术文章中介绍10.1版本，重点之一是存储到GPU的数据路径，并涉及hipFile及NUMA感知的主机内存分配。这些属于具体软件能力更新，是否改善某个应用，需要检查硬件、驱动和程序使用方式是否满足条件。
从性能分析角度看，加速器等待数据时，再高的理论计算能力也无法直接转化为任务进度。因而，研究数据在哪里、经过哪些环节，往往与优化计算本身同样重要。
数据进入GPU之前，可能已经等待多次
一个任务可能先从存储读取文件，再由CPU解析和转换，随后把数据交给加速器。如果其中某一步串行处理或速度较慢，后续设备就会间歇等待。
这类问题并不一定表现为硬件故障。系统可以正常运行，只是GPU利用率不稳定、任务时间偏长。绘制读取、处理和计算的时间线，通常比单独查看某一时刻的利用率更容易找到原因。
缩短路径与减少重复处理要同时考虑
优化数据路径的目标，是减少不必要的等待和搬运，但并非所有数据都能够跳过原有处理。格式转换、解压或校验仍可能是业务必需步骤，需要明确它们应该由谁完成。
如果同一份数据在多个阶段反复复制，可以检查是否有共享或复用的空间；如果数据只能顺序产生，则应考虑流水化，让不同阶段尽可能重叠。这些思路应通过测量验证，而不是仅凭架构图推断收益。
内存位置也会影响访问成本
在多处理器系统中，数据分配位置与使用它的计算资源之间可能存在距离差异。软件若不了解系统结构，就可能产生额外访问成本。相关分配能力提供了优化工具，但仍需要应用正确使用。
部署时可以记录进程位置、设备连接和内存策略，并在相同条件下比较结果。否则，同一程序两次运行出现差异，很难判断来自软件更新，还是资源分配变化。
升级前后应保持测试条件一致
模型、输入规模、批量大小与存储状态，都可能影响结果。若升级软件的同时更换了其他参数，就难以确认改进究竟来自哪里。
较有参考价值的验证，应包含任务完成时间、数据准备耗时、资源占用和错误情况。某项局部指标改善后，也要看它是否缩短了整体流程，避免只是把等待移动到了另一个环节。
存储与计算需要共同规划
对于频繁保存检查点、加载大文件或切换模型的任务，存储能力可能直接影响计算设施的使用效率。采购时将二者分开评估，容易出现算力充足但数据供给不足的情况。
ROCm 10.1把数据移动列为重点，反映了软件优化范围的扩展。对用户来说，下一步应是拿真实任务定位瓶颈，再检查这些功能是否能够解决对应问题。版本更新提供可能性，端到端测量才负责确认效果。