HBM 不够用了,AI SSD 迎来爆发前夜 文章

InfoQ 中文2026-08-07BLOGzh作者: Ian

详细信息

来源站点
InfoQ 中文
作者
Ian
文章类型
BLOG
语言
zh
发布日期
2026-08-07

摘要

HBM 装不下、数据搬不动,SSD 开始进入实时路径大语言模型推理正在同时撞上两堵墙:一堵是容量墙,另一堵是 I/O 墙。模型参数持续扩大,长上下文、多轮对话和智能体任务又让 KV Cache 快速膨胀;MoE 模型虽然降低了单次计算的激活参数量,却需要保存远大于显存或内存容量的专家权重。在云侧算力中心,昂贵的 HBM 被模型权重和 KV Cache 长期占用,GPU 有效利用率受制于数据搬运;在边缘侧和端侧,有限的 DRAM 或统一内存则直接限制了本地可运行模型的规模。当显存和内存越来越难以独自承接推理负载,SSD 开始从模型文件的静态存放设备进入大模型推理的实时数据路径,成为 HBM、VRAM 和 DRAM 之后的一层正式存储层级。这一变化最早在推理基础设施和集群架构中得到清晰体现。月之暗面的 Mooncake 采用以 KV Cache 为中心的分离式推理架构,将 GPU 集群中原本未被充分利用的 CPU、DRAM 和 SSD 组织为分布式缓存资源[1];Mooncake Store 进一步支持由 DRAM 与 SSD/NVMe 构成的多级缓存,使冷数据能够在容量更大、成本更低的闪存层长期保留[2]。2026 年,英伟达推出 CMX 上下文内存存储平台,在 Vera Rubin 基础设施中增加一个面向 KV Cache 优化、通过以太网连接的闪存层级,由 BlueField-4 负责 NVMe SSD 管理、数据保护和网络传输。英伟达将其定义为介于 GPU 内存与共享存储之间的 pod 级上下文层[3]。产业信号已经很明确:SSD 正在成为推理系统需要直接调度的资源,而不再只是模型加载前后的外围设备。问题是,推理系统开始调用 SSD,并不等于传统 SSD 已经适合承担常驻推理任务。传统 SSD 面向文件和块数据存储设计,性能指标主要围绕顺序带宽、随机 IOPS、数据可靠性与单位容量成本展开;LLM 推理需要的却是具有严格时序约束的数据供应。KV Cache 会在prefill 阶段集中生成并持续写入,在后续请求中按会话、模型层和 Token 位置反复读取;MoE 推理则需要根据路由结果,在每一层计算前及时取得特定专家权重。