数据存储方案 | 第11期：推理的记忆，存在哪一层

存储专题 · 2026-11-01 · 九羲科技

数据存储方案 | 第11期：推理的记忆，存在哪一层

这周存储圈的三件事，乍看各管各的：HPE 说，推理的"记忆"不必反复重算，存进阵列里，H200 上首 token 快了 20 倍；华为在上海的会上，拿出了 GLM 5.2 的 7.3 倍吞吐；郑州的 2026 数据存储产业大会，则把一台 Gen5 企业级 SSD 和一块小小的启动盘摆到了台前。拼在一起，像同一笔账本——贵的资源（HBM、显存）越来越不够用，所有人都在回答同一个问题：数据到底该住哪一层？

这是「数据存储方案」专栏的第 11 期。三条主线的材料时间落在 10 月 17 日到 29 日：KV 缓存的两份实测、存力大会的实盘、10 万条向量的一次正面对决。量子、生物、玻璃这些前沿介质，本周没有可核实的实质突破——按宁缺毋滥的规矩，不占篇幅。

一、推理的"记忆"，开始住进存储阵列

智能体干活有个毛病：同一份上下文，它能翻来覆去地算好几遍。一个 agent 查资料、另一个评估、第三个核验，后面的步骤回头再看系统已经处理过的材料。有些重复是必要的，全部重算不是。

KV Cache 就是干这个的：把注意力机制算过的 Key、Value 存下来，兼容的请求直接复用，模型动笔前少算很多。麻烦的是，显存既不大，也不便宜。长上下文加多并发一挤，可复用的缓存被淘汰，等再需要时，推理引擎只好重新建——GPU 多干活，人多等待，还没多出半点新见解。

HPE 的解法：给 Alletra Storage MP X10000 加了个新差事——当推理状态的共享下沉层。那些本来要被赶出昂贵 GPU 内存、事后重算的推理状态，住到它这儿。用 RDMA for S3 加速存储数据路径，核心主张就一句话：能复用的上下文，取出来用，别让 GPU 再算一遍¹。

数字是第三方验证的。测试由 Kamiwaza 用 NVIDIA H200、Kamiwaza AI platform 跑的：Nemotron 70B，30 多个并发智能体，大上下文多智能体推理。结果：首 token 时间快了 20 倍，有效推理吞吐高了 17 倍——对比基线是同一负载、不做 KV Cache offload 的跑法¹。The Register 顺手补了一句大实话：20 倍是测试结果，不是普惠 entitlement；上下文长度、并发、缓存命中率、传输开销决定真实回报。买之前，先搞清楚自己应用里有多少重复计算是真能省掉的¹。

华为走的同一条路，数据是自己的。10 月 22 日 ODCC 组织的高级存储大会（上海站），华为披露：KV Cache offload 在 GLM 5.2 的实验室场景里，推理吞吐 7.3 倍；存储-网络协同的 I/O 调度，又多抠出 20% 的效率²。这不是凭空冒出来的——9 月 HUAWEI CONNECT 上，华为刚升级了 Stellar AI Fabric，并发布了 OceanStor M900 Context Memory Storage，设计目标就是把 KV Cache 从片上内存、DRAM 延伸进一个共享的分级池²。10 月这场，更像给既定方向补了一组测量数。

成色说清楚。HPE 这篇是付费内容（HPE 供稿），测试由第三方 Kamiwaza 验证；华为的是厂商在会议上披露的 lab 数据，没有公布完整测试配置²。两家都没说"所有负载都这样"。但方向是一致的：存储决策，正式进入 AI 经济学的讨论桌——以前大家盯模型价格，现在该盯的，是让昂贵的加速器把同一份上下文算第七遍的钱。

二、启动盘这块小地基，撑着万卡集群

10 月 28–29 日，"2026 数据存储产业大会"在郑州 JW 万豪开幕，主题"存力筑基，共启 AI 新机遇"。大会自己下的判断很直白：产业的核心矛盾，已经从"算力够不够"转向"数据能不能喂饱"——GPU 因为等数据而闲置的损耗，正在被急剧放大³。

忆联（Union Memory）把两样东西摆上了台面。先说小的：企业级 M.2 启动盘 UM301a，PCIe Gen4，DRAM-less 架构——直接取消独立 DRAM 缓存，从物理层面消除了 DDR UNC 可能引发的宕机隐患。NVMe 1.4b，480GB / 960GB / 1.92TB 三档，顺序读 5000MB/s，随机读 350K IOPS，带掉电保护和带外管理³。为什么是启动盘？节点扩容、固件更新、故障重建时，启动盘要快速拉起系统、完成集群握手——这一步慢一拍，整排 GPU 就在那儿空转。AI 集群的第一道关口，恰恰是这块最不起眼的盘³。

再说大的：UH812c，PCIe Gen5 企业级 SSD，自研主控加自研固件。顺序读写 14.9 / 12 GB/s，随机读写 3500 / 1200K IOPS，面向 AI 训练、数据库、高频交易。PCEVA 对 7.68TB 容量点的评测里，4K 随机读写跑超了标称值，VDBench 150 万+IOPS 混合读写、OP 到 6.4TB 后的稳态 220 万+IOPS³。同场还有 UH812a：首个通过 Intel BHS 平台全面验证的国产 Gen5 eSSD，LDPC 纠错，全生命周期性能浮动小于 10%，连续读写 14.9GB/s³。

大会本身的动作也值得记：发布了《数据存储产业发展研究报告（2026 年）》和《数据存储产业与技术全景图》，启动 AI 存储领域两项团体标准加一项国家标准——方向正是"存算协同""长上下文记忆""KV Cache 分级"³。第一节里 HPE 和华为折腾的那条路，正在被写进标准。

成色：美通社企业新闻稿口径，性能数字是厂商宣称叠加第三方评测引用（PCEVA）。"连续四年稳居中国企业级 SSD 国产厂商第一"这类话，听个响就好³。

三、向量到底住 Postgres 里，还是另起炉灶

RAG 的存储层，选型争论一直没停：向量是住在已有的 Postgres 里（pgvector），还是另起一个专用向量库？10 月 17 日，一位开发者（Waseem Anjum）在 Medium 上交了一份亲手跑的答卷⁴。

做法很实在：10 万条 OpenAI embeddings（1536 维，公开的 DBpedia 数据集，典型的 RAG 形状），同时装进 pgvector 0.8.7（PostgreSQL 18.6）和 Qdrant 1.19.2，同一台 8vCPU / 15GB 的机器，测召回、时延、构建时间、过滤查询。Pinecone 只按官方文档列了规格，没实测——作者明说"没跑过的不编数字"，这态度先加一分⁴。

先看硬数字。pgvector HNSW 默认参数（ef_search=40）：recall@10 0.948，中位时延 1.45ms；ef 拉到 100：0.978 / 2.60ms；拉到 200：0.988 / 4.02ms。Qdrant ef=40：0.985 / 2.63ms；ef=100：0.997 / 3.73ms。同等召回下，Qdrant 快大约 1.5 倍⁴。索引体积有个巧办法：pgvector 用 halfvec 存 1536 维向量，索引从 781MB 压到 391MB，召回只掉约半个点⁴。构建速度：pgvector COPY 导数 3.9 秒、建 HNSW 索引 69.1 秒；Qdrant 从第一个上传到索引建完 30.8 秒⁴。

过滤查询是分水岭。10% 选择率的过滤：Qdrant 的 payload index，0.993 召回 / 2.11ms；pgvector 默认 HNSW 是"先扫图、后过滤"——ef=40 时平均只返回 3.92 行（要 10 行），得开 iterative scans 才能到 0.953 / 3.37ms⁴。换句话说，pgvector 的过滤查询不调参数会静默少返回，这是个坑，生产环境得知道。

作者的选型结论很克制：已经有 Postgres、向量几百万以内——pgvector 起步，一个库搞定事务、行级权限、备份，省掉双系统同步的麻烦；向量搜索是主业、重过滤、海量——Qdrant；团队不想运维数据库、流量忽高忽低——Pinecone（serverless，但最终一致，Standard 50 美元/月起）⁴。迁移也有交代：主键对齐、双写、拿真实查询对召回，切读之前先并排跑⁴。

成色：个人实测，一台机器、10 万向量，"同等硬件同等数据"下成立；外推到千万级、分布式，另测再说。标成色：单方实测⁴。

· · ·

扫码加入九羲服务器AI落地群

文章、视频等内容为九羲科技原创，转载请注明出处

合作 | 联系我们：jx@jiuxii.cn

脚踏实地 行知合一

互相成就 拥抱未来