📋 要点 1. RAG成为NAND需求主线：用户数据被AI索引化后，原始文件会被放大为多倍SSD需求，推动企业级SSD持续扩容。 2. 需求不是一次性建库：每年新增的PDF、代码库、企业知识库和多模态内容都会继续被RAG化，形成持续数据流需求。 3. 推理架构带来额外弹性：KV Cache、Rubin
要点
1. RAG成为NAND需求主线：用户数据被AI索引化后，原始文件会被放大为多倍SSD需求，推动企业级SSD持续扩容。
2. 需求不是一次性建库：每年新增的PDF、代码库、企业知识库和多模态内容都会继续被RAG化，形成持续数据流需求。
3. 推理架构带来额外弹性：KV Cache、Rubin SSD/CMX、User Memory和Agent Trace共同补充需求，但RAG仍是最核心驱动。
近期针对AI SSD存储需求进行了多轮调研。相比传统服务器周期，本轮NAND需求上修并不是简单来自服务器数量增长，而是AI应用改变了数据的使用方式：用户上传的数据不再只是被保存，而是需要被切块、向量化、建索引、热备份，并在推理过程中被反复检索和调用。
换句话说，AI不是让平台“多存一点数据”，而是把同一份数据加工成多层数据资产。一份PDF、一段代码库、一套企业知识库，过去可能只需要存在对象存储里；现在如果要被AI总结、问答、引用和长期记忆，就需要额外生成embedding、vector index、metadata、检索日志和热备份。正是这层“AI索引化”，使NAND需求增速显著高于大部分CSP原先的预期。
本轮NAND需求的核心主线是RAG/Embedding Index。除此之外，用户原始内容、User Memory、Agent Trace、Inference Logs、Training Data Lake、Checkpoint、KV Cache、Rubin SSD/CMX等都会共同拉动SSD需求。但主次要分清：RAG是主引擎，用户原始内容是底座，其他需求是侧翼和架构弹性。
一、AI为什么会重构NAND需求？
传统互联网时代，用户上传一份文件，平台主要做的是保存、分发和推荐。比如用户上传一张图片、一段视频、一份PDF，平台把它存下来，未来用户需要时再读出来。
AI时代不一样。用户上传一份文件后，平台不仅要保存原文，还要让模型能够理解和调用这份文件。这个过程会产生一整套新的存储需求：
· 原始文件要保存；
· 文件要切成小块；
· 每个小块要生成embedding；
· embedding要形成向量索引；
· 索引要热备；
· 检索过程会产生日志；
· 用户长期使用后会形成personal memory；
· Agent执行任务时还会生成trace、工具调用结果、截图和安全审计数据。
所以，AI对NAND的拉动不是单一来源，而是多层叠加。过去一份数据可能只存一份；现在一份数据会衍生出索引、日志、记忆、评测和训练回流数据。
这可以写成一个简单公式：
NAND需求 = 用户新增数据量 × AI索引化比例 × 数据膨胀系数 × 热存储比例 × 保留周期
如果只看服务器数量或GPU数量，就容易低估NAND需求。因为同样一台服务器背后，数据形态已经变复杂了：它不只是服务模型推理，还要服务检索、记忆、日志、评估、安全和训练回流。
二、RAG/Embedding Index是本轮NAND需求的主引擎
本轮AI NAND需求最核心的主线是RAG和Embedding Index。
RAG的作用很简单：让模型能够从用户文件、企业知识库、代码库、内部文档、多模态内容里检索信息。没有RAG，模型只能依赖训练时学到的知识回答；有了RAG，模型可以先去用户数据里找答案，再基于检索结果生成回答。这意味着，用户上传的数据不再只是静态保存，而是要变成AI可以实时调用的索引。
可以把它理解成一道小学数学题：
假设用户上传了一个100MB文本文件。以前，平台主要存这100MB。
现在，如果这100MB文件要做RAG，系统会把它切成很多小块，然后给每个小块生成embedding。假设单份RAG热索引大约是原始文本的4倍，那么需要：
$100 \text{MB} \times 4 = 400 \text{MB} \text{SSD}$
如果这份数据非常重要，需要在SSD里做双主热备，那么需要：
$400 \text{MB} \times 2 = 800 \text{MB} \text{SSD}$
所以：
100MB原始文件 → 400MB单份RAG热索引 → 800MB双主热备SSD需求
这就是RAG对SSD的4-8倍放大。
因此，需求测算可以用三档：
· 保守情景：4x，只算单份RAG热索引。
· 中性情景：6x，部分数据双热备，部分数据单热备。
· 乐观情景：8x，核心热数据全部SSD双主热备。
这已经足够解释为什么RAG会明显拉动企业级SSD。用户上传的数据本身可能只增长30%，但如果这些数据被RAG化后要放大4-8倍，最后落到SSD采购上的增量会大得多。
更重要的是，RAG不是一次性建库需求，而是持续的数据流需求。只要用户每年继续上传新文件，企业每年继续接入新知识库，代码库继续更新，多模态内容继续增长，每年都会有新的数据需要被RAG化。
继续举个简单的例子：
简单看，若2025年行业SSD需求为100，2026年RAG带来30的新增需求，则总需求升至130。若2027年新增被RAG化的数据量翻倍，RAG新增需求也将从30升至60，总需求进一步升至190。
这说明，RAG不是一次性建库需求，而是随新增用户数据持续增长的数据流需求。只要用户上传文件、企业知识库、代码库和多模态内容继续增加，且AI索引化比例继续提升，RAG对SSD的拉动就不会自然衰减，反而可能继续放大。
三、除RAG外，AI还带来哪些NAND需求？
虽然RAG是主线，但NAND需求不能只写RAG。完整的AI存储需求至少还包括四类：用户原始内容、User Memory、Agent Trace/Inference Logs、Training Data Lake/Checkpoint。
第一，用户原始内容是RAG的底座。
RAG需求不是凭空出现的，它的前提是用户和企业不断上传新数据。对于Meta这类UGC平台，用户每天都在上传图片、视频、短视频、聊天内容和创作者内容。对于OpenAI、Anthropic、Google、Microsoft这类AI平台，用户和企业会上传PDF、PPT、Excel、代码库、会议记录、合同、客服文档和内部知识库。
这些数据本来就需要存储。AI的变化在于，它会在原始存储之上再叠加一层索引层。
以前：
上传100MB = 存100MB
现在：
上传100MB = 存100MB原始文件 + 生成400-800MB RAG热索引
所以，AI不是替代传统对象存储，而是在传统对象存储上增加了“AI可调用层”。原始内容是底座，RAG是放大器。原始数据越多，被AI索引化的比例越高，SSD需求弹性越大。
第二，User Memory会让AI存储从“文件”变成“长期记忆”。
AI助手早期像一次性聊天工具。用户问一句，模型答一句，任务结束后上下文就可以丢掉。但如果AI助手未来变成personal agent，它就需要记住用户的长期偏好、历史任务、常用文件、工具调用习惯、工作流和个性化设置。
这会形成一套用户级持久记忆系统。
比如，一个投资人经常让AI分析AI产业链，系统就需要记住他关注的公司、指标、报告格式和风险偏好。一个程序员经常让AI改代码，系统就需要记住他的代码库结构、风格偏好、历史bug和常用工具。一个企业用户经常让AI处理内部流程，系统就需要记住组织架构、权限、业务文档和历史任务。
这些长期memory不适合全部放在HBM或DRAM里。高频、实时部分可能在内存里，但长期、低频、可检索的记忆更可能落在SSD和分层存储里。
第三，Agent Trace和Inference Logs会让NAND需求更厚。
Agent不是简单问答。Agent会调用工具、打开网页、读取文件、执行代码、截图、报错、回滚、重试，最后再生成结果。每一步都可能形成trace。
一个Agent任务可能包括LLM文本交互、工具调用结果、网页截图、代码执行结果、错误日志、回滚记录、安全审计、模型评估、用户反馈和replay数据。这些数据不一定全部长期保留，但平台会保留其中一部分，用于调试系统、评估模型、安全审计、回放失败案例和提取高质量训练数据。
这类需求不能写成最大驱动，因为Agent Trace会被采样、压缩、摘要和分层存储。但它的意义在于，AI系统越复杂，需要保存的过程数据越多。NAND不只是在保存用户文件，也在保存AI系统运行过程中的“黑匣子”。这些数据让NAND需求更厚，也让存储需求更难完全按传统互联网模型预测。
第四，Training Data Lake、Checkpoint和模型版本管理提供工程侧底座。
训练一个大模型，不是只保存最终模型。厂商还要保存原始训练数据、清洗后数据集、训练数据湖、checkpoint、中间版本、fine-tune版本、安全版本、benchmark数据集、replay数据和评测结果。
模型迭代越快，这部分需求越稳定。一个模型公司可能同时维护基础模型、推理模型、代码模型、多模态模型、安全增强版本、企业定制版本、A/B测试版本，以及不同尺寸和不同延迟版本。每个版本背后都有权重、checkpoint、评测数据、日志和回放数据。
训练侧存储需求不像RAG那样直接跟用户日活和上传数据绑定，但它提供了稳定的工程侧底座。模型越多、版本越多、迭代越快，工程侧NAND需求越稳定。
四、KV Cache、Rubin SSD与Cerebras：推理架构如何影响NAND？
除了RAG之外，推理架构变化也会影响NAND需求。但这里要分清主次：KV Cache和Rubin SSD是NAND的架构弹性，不是比RAG更确定的主线；Cerebras/LPU可以提升decoding效率，但不能简单推导为NAND空头。
先看KV Cache。
KV Cache可以理解成模型处理上下文时产生的中间状态。用户输入长prompt后，模型会为这些tokens生成KV Cache。如果未来还要继续使用这些上下文，存下KV Cache可以省掉一部分重新计算成本。
所以KV Cache offload的逻辑是“以存代算”：把一部分KV Cache放到SSD里，未来就不用每次重新计算。
但这个需求不是绝对刚性的，因为它取决于一个简单的成本比较：
如果存SSD更便宜，就存下来；
如果重新计算更便宜，就重新计算。
假设存一段KV Cache到SSD要花10元。
如果重新计算只要5元，厂商就会选择重新计算。
如果重新计算要20元，厂商才会选择存SSD。
所以KV Cache对SSD的需求，取决于SSD价格、算力价格、prefill集群效率和用户体验要求。随着SSD价格上涨，部分厂商会重新建设prefill集群，用重新计算替代长期存储KV Cache。这意味着KV Cache曾经是SSD需求的重要增量，但它不是最稳定的长期主线。
不过，这不代表KV Cache可以完全忽略。长上下文、多并发、多Agent任务下，KV Cache仍然会膨胀。
在PD分离架构下，Prefill节点负责处理输入tokens，Decoding节点负责逐token生成输出。Prefill节点会生成KV Cache，Decoding节点需要读取这些KV Cache。问题是，Prefill和Decoding不在同一台服务器，是跨机柜的，因此中间需要一个池化层来传输和读取KV Cache。
这个池化层可以有两条路线：
一条是CXL DRAM；
另一条是SSD池化，比如Rubin SSD/CMX。
如果SSD池化方案成为主流，SSD就不只是普通存储设备，而会进入推理架构的中间层，承担KV Cache池化和高性能数据传输功能。这会提高AI集群里高性能企业级SSD的配置比例。
但这部分需求属于“上行弹性”，目前还不是确定性主线。因为它仍然面临几个变量：CXL DRAM路线是否胜出，Rubin SSD是否大规模落地，Decoding节点是否通过LPU、TPU等方案加速，以及如果Decoding速度提升，中间态需要保存的时间是否变短。
再看Cerebras/LPU路线。
笔者调研的专家普遍看好Cerebras/LPU，核心逻辑是通过片上SRAM常驻模型权重，减少Decoding阶段的数据搬运。这个逻辑在短上下文、低并发、极致低延迟场景下有价值。它确实可能提高Decoding速度，缓解GPU+HBM架构下的显存带宽瓶颈。
但笔者认为不能因此推出“KV Cache都能放SRAM，所以不需要offload”。原因是KV Cache不是固定大小，而是随着context长度和并发请求数线性增长。单个200k context请求可能产生约4GB KV Cache；100个并发就是约400GB。如果再叠加多Agent、多轮任务和工具调用，KV Cache会继续放大。
所以，Cerebras/LPU更像Decoding加速方案，而不是对NAND需求的根本否定。它可能降低部分Decoding场景对HBM带宽的依赖，也可能缩短部分中间态停留时间，但在长上下文、多并发、多Agent任务下，KV Cache仍然需要外部存储层承接。更重要的是，Cerebras/LPU主要影响KV Cache和Decoding链路，并不影响RAG、Embedding Index、用户原始内容、User Memory、Agent Trace和Checkpoint这些NAND需求主线。
因此，本章结论是：
推理架构对NAND有两面影响。KV Cache可以recompute，使部分SSD需求有弹性；但长上下文、多并发和Agent任务又会让KV Cache继续膨胀。Rubin SSD/CMX可能让SSD进入推理中间层，是NAND的上行弹性；Cerebras/LPU可以加速Decoding，但不能完全消除KV Cache分层需求，更不能推翻RAG带来的NAND需求主线。
五、为什么短期SSD价格强势来自真实需求？
短期SSD价格强势，不能简单理解成CSP囤货。更准确的说法是：
真实AI需求是基础，供给周期错配是原因，大厂保供采购进一步放大了紧缺。
第一层是真实需求。
如果2026年NAND需求增长主要由RAG、Embedding、推理存储、User Memory、checkpoint和AI workloads拉动，那么这不是虚假需求。CSP不是为了囤货而囤货，而是因为AI应用真实吃掉了更多企业级SSD。
尤其是RAG，一份原始数据被AI索引化后，可能放大成4-8倍热SSD需求。只要用户上传文件、企业知识库、代码库和多模态内容继续增长，RAG就会持续消耗SSD。
第二层是供给周期。
企业级SSD扩产、高层数NAND放量、QLC导入、良率爬坡都需要时间。需求突然上来，供给无法立刻跟上，价格自然强势。
第三层是大厂保供。
对于CSP来说，AI用户和AI产品体验优先级很高。如果因为SSD不够导致新功能上线延迟、RAG检索能力不足、用户memory不可用，损失的不只是当期成本，而是用户心智和产品竞争力。因此大厂会提前锁货，把真实需求进一步放大成更强的采购周期。
所以，短期SSD价格强势首先来自真实AI需求，其次来自供给周期错配，大厂保供采购只是进一步放大了紧缺。
这也是NAND多头逻辑最重要的部分：如果RAG已经能解释2026年相当部分新增需求，那么2027-2028年不应简单假设需求自然回落。关键要看新增用户数据、RAG渗透率和热存储比例是否继续提升。
六、风险与跟踪指标
虽然AI NAND需求有真实支撑，但中长期仍然有几个风险需要跟踪
第一个风险是RAG膨胀系数下降：如果GREP、倒排索引或混合检索方案替代部分向量检索，那么RAG对SSD的膨胀系数可能下降。比如原来按6x-8x算，未来可能降到4x或更低。但这不意味着需求消失，而是弹性下降。只要用户数据继续增长，AI索引层仍然会消耗SSD。
第二个风险是采样率和保留周期优化：对于Agent Trace、Inference Logs、Telemetry这类数据，平台可以降低采样率、缩短保留周期、压缩摘要或转冷存。这样会压低日志类NAND需求。但对RAG热索引来说，优化空间较小，因为它直接影响AI产品能不能检索用户数据。
第三个风险是KV Cache更多转向recompute：如果算力继续变便宜，prefill集群效率继续提升，厂商可能减少长期KV Cache存储，把这部分需求转向重新计算。这会影响KV offload相关SSD需求。
第四个风险是CXL DRAM替代SSD池化：如果推理中间态最终由CXL DRAM解决，而不是Rubin SSD/CMX，SSD在推理架构中的新增弹性会下降。
第五个风险是Cerebras/LPU等Decoding加速降低中间态停留时间：如果Decoding速度大幅提升，KV Cache中间态需要存放的时间会缩短，对SSD容量需求有压制。但这主要影响KV Cache和推理池化，不影响RAG、Embedding、User Memory和对象存储主线。
第六个风险是供给在2027-2028年追上需求：NAND仍然是周期行业。若高层数NAND放量、企业级QLC供给增加，而需求增速边际放缓，价格可能松动。
结论
本轮AI NAND需求的核心，不是“AI数据变多”这么简单，而是用户数据被AI索引化后，变成了可检索、可调用、可记忆、可回流训练的热数据资产。
其中，RAG/Embedding Index是最核心的主线。用户上传100MB原始文本，单份RAG热索引可能变成400MB；如果核心数据做SSD双主热备，可能变成800MB。冷备通常放HDD，因此不应把所有灾备都计入SSD，但4-8倍的热索引膨胀已经足够解释企业级SSD需求为什么被显著放大。
更重要的是，RAG不是一次性建库，而是持续的数据流需求。只要用户每年继续上传新文件，企业知识库继续接入，代码库、多模态内容和个人memory持续增长，每年新增数据都会继续被AI索引层放大。因此，如果2026年RAG已经贡献了显著NAND新增需求，那么2027-2028年随着新增数据量和RAG渗透率继续提升，RAG对SSD的拉动可能不是衰减，而是继续放大。
因此，短期SSD价格强势不是单纯备货，而是“真实AI需求 + 供给周期 + 大厂保供”的结果。中长期需要跟踪RAG膨胀系数、热存储比例、KV Cache recompute、Rubin SSD落地、CXL DRAM竞争和NAND供给释放节奏。但从当前调研看，本轮AI NAND需求的本质，是AI把用户数据从静态文件变成了可调用的存储资产，而企业级SSD正是这套资产体系的核心承载层。