存储供应商，陷入困境

如果您希望可以时常见面，欢迎标星收藏哦~

来源：内容 编译自 blocksandfiles 。

存储供应商面临的最大问题是人工智能——如何存储数据，并使其可供人工智能代理和模型访问。以下是他们如何应对这一挑战。

在存储管理中使用人工智能几乎是轻而易举的事。它提高了存储管理员的效率，并且对网络安全至关重要。关键挑战在于存储人工智能数据，以便模型和即将上线的代理能够通过人工智能数据管道快速访问这些数据。存储硬件或软件供应商是否为此做出了特殊安排，或者依赖于在光纤通道、以太网和 NVMe 上运行的标准块、文件和对象访问协议，并由中间人工智能管道软件使用这些协议从其存储中选择和提取数据？

基础存储硬件和软件供应商都采取了不同程度的特殊安排，首先是采用 Nvidia GPUDirect 支持，以便更快地将原始数据发送到 GPU。这项服务最初仅限于文件，但现在已扩展到通过 RDMA 传输 S3 的对象。其他 GPU 或 AI 加速器硬件供应商没有与 GPUDirect 等效的服务。在流水线的每个阶段，原始数据都会逐步转换为 AI 模型可用的最终数据集和格式，这意味着非结构化文件和对象数据的向量嵌入。

数据仍然存储在磁盘或 SSD 驱动器硬件上，但管理这些数据的软件可以从存储阵列控制器变为数据库或数据湖，再变为矢量存储，可以是独立的，也可以是数据仓库、数据湖或湖屋的一部分。所有这些都可以在公共云中进行，例如 AWS、Azure 或 GCP，在这种情况下，存储供应商可能不参与。假设我们正在研究本地环境或公共云，在那里使用存储供应商的软件，而不是原生的公共云存储设施。数据源可能是标准存储供应商的存储库，也可能是某种流数据源，例如日志生成系统。收集的数据进入存储供应商的系统或数据库、数据湖或数据湖屋。然后对其进行处理和转换。

在生成式人工智能大型语言模型 (LLM) 能够使用非结构化数据（例如文件、对象或日志）之前，必须先对其进行识别、定位、选择和向量化。之后，需要将向量存储起来，可以存储在专门的向量数据库中，例如 Milvus、Pinecone 或 Qdrant，也可以存储在数据库/数据湖/数据湖屋 (Lakehouse) 中。所有这些工作都位于人工智能管道的中上层，该管道接收收集到的原始数据，进行预处理，然后将其交付给 LLM。

基础存储供应商可以说他们存储原始数据并使用标准协议将其发送出去——仅此而已。Qumulo 的立场是：不支持 GPUDirect，并且通过其NeuralCache使用 AI仅用于增强其内部运营。（但 Qumulo 确实表示，如果需要，它可以快速添加 GPUDirect 支持。）几乎所有以企业为中心的原始存储供应商都支持 GPUDirect，并且具有不同程度的 AI 管道支持。VAST Data 则全力以赴，构建了自己的 AI 管道，其数据库支持矢量，实时数据提取到 AI 模型，事件处理以及 AI 代理构建和部署设施。这与 Qumulo 的立场截然相反。其他存储系统供应商的定位介于 Qumulo 和 VAST Data 极端之间，处于不同的位置。

Cloudian、Dell、DDN、Hammerspace、Hitachi Vantara、HPE、IBM、MinIO、NetApp、Pure Storage、Scality 和 VAST 均支持用于文件和对象的 GPUDirect。对于多产品供应商（例如 Dell 或 HPE），其所有文件和对象存储产品线的支持不一定是统一的。

比 GPUDirect 支持更进一步的是 Nvidia 的 BasePOD 和 SuperPOD GPU 服务器系统认证。戴尔、DDN、日立 Vantara、HPE、华为、IBM、NetApp、Pure Storage 和 VAST 等供应商均已获得此类认证。Infinidat、Nexsan、StorONE 等规模较小的供应商目前尚未获得此类认证。

更进一步的是与 Nvidia Enterprise AI 软件集成，包括其 NIM 和 NeMo 检索器微服务、Llama Nemotron 模型和 NIXL 例程。戴尔、DDN、日立 Vantara、HPE、NetApp、Pure 和 VAST 都这样做。

更进一步的举措是提供完整的数据准备和转换、AI 模型支持、代理开发和代理环境，例如 VAST 在其 AI 操作系统上所做的工作，而戴尔、日立 Vantara 和 HPE 则通过合作伙伴，凭借其 AI 工厂的开发，朝着这个方向迈进。其他供应商似乎都无法做到这一点，因为他们缺少 AI 堆栈基础设施的关键组件，而 VAST 已经构建了这些组件，而戴尔、日立 Vantara 和 HPE 至少可以部分开发这些组件。从存储行业的角度来看，VAST 在这方面是一个异类。它究竟会继续保持领先地位，还是最终吸引追随者，目前尚无定论。

这一切都以 Nvidia 为中心。三大公有云都有各自的加速器，并将确保这些加速器能够快速访问其自身的存储实例，例如亚马逊的S3 Express API。它们都拥有 Nvidia GPU，并且了解 GPUDirect，因此理应寻求在自己的加速器上复制其数据访问效率。

转向不同的 GPU 调节策略可能意味着查看KV 缓存。当在 GPU 中执行 AI 模型时，它会将其令牌和向量作为键和值存储在 GPU 的高带宽内存 (HBM) 中。此键值缓存的容量有限。当它已满并且正在处理新的令牌和向量时，旧的令牌和向量将被覆盖，并且如果需要，必须重新计算，从而延长模型的响应时间。将逐出的 KV 缓存内容存储在 GPU 服务器上的直接连接存储（第 0 层）中，或存储在联网的、可通过 RDMA 访问的外部存储（第 1 层）中，意味着可以在需要时检索它们，从而缩短模型的运行时间。

Hammerspace、VAST Data和WEKA这三家并行文件系统服务供应商都支持 Nvidia GPU 服务器的 KV 缓存卸载。这项技术似乎也能得到所有其他支持 GPUDirect 的供应商的支持。同样，它是 Nvidia 独有的，这巩固了 Nvidia 作为绝对主导的 AI 模型处理硬件和系统软件供应商的地位。

云文件服务供应商——CTERA、Egnyte、Nasuni 和 Panzura——都面临着利用其数据支持 AI 推理的需求，这意味着需要通过 AI 数据管道将数据输入到支持 GPU 的边缘或中央系统。他们会支持 GPUDirect 吗？Nvidia 会为他们开发边缘企业 AI 推理软件框架吗？

Arcitecta、Datadobi、Data Dynamics、Diskover、Hammerspace 和 Komprise 等数据管理和编排供应商都在积极参与 AI 数据管道工作，因为数据的选择、筛选和移动是他们的核心竞争力。我们尚未看到他们与 Nvidia 合作或获得 Nvidia 认证，成为其 GPU 的存储数据源。除了 Hammerspace 之外，从 Nvidia 的角度来看，这些供应商似乎只是个配角，就像云文件服务供应商一样。

回到主流存储供应商，上述所有调整都适用于存储在供应商自有存储中的数据，但也存在备份数据（访问权限由备份供应商控制）和存档数据（访问权限由其供应商控制）。我们之前曾写过，存在三个独立的AI数据管道，并且逻辑上需要一个单一的管道，而备份供应商则完全有能力提供它。

我们认为存储系统供应商对此无能为力。备份供应商众多，他们不愿向客户授予访问其备份存储中数据的 API 权限。

设想一个大型分布式组织，拥有多家存储系统供应商、一些公共云存储、一些云文件服务系统、一些数据保护供应商、一个档案库以及一些数据管理系统，那么制定一项策略，使其所有存储信息可供AI模型和代理使用将极其困难。我们可能会看到这样的组织精简其存储供应商名单，以摆脱这种困境。

https://blocksandfiles.com/2025/05/24/ai-the-single-largest-storage-supplier-issue/

半导体精品公众号推荐

专注半导体领域更多原创内容

关注全球半导体产业动向与趋势

*免责声明：本文由作者原创。文章内容系作者个人观点，半导体行业观察转载仅为了传达一种不同的观点，不代表半导体行业观察对该观点赞同或支持，如果有任何异议，欢迎联系半导体行业观察。

今天是《半导体行业观察》为您分享的第4048期内容，欢迎关注。

『半导体第一垂直媒体』

实时 专业 原创 深度

公众号ID：icbank

喜欢我们的内容就点“在看”分享给小伙伴哦