1. 一个标题引发的行业地震为什么存储股会慌DeepSeek新模型发布那天我正蹲在几个硬件群里看热闹。消息刚出来不到半小时群里就炸了锅——有人在转存储板块的行情截图有人在算自己刚囤的几块NVMe SSD是不是要砸手里还有人半开玩笑地说早知道不买那么大的硬盘了。这个标题1/4显存、1/8硬盘看着像个营销噱头但作为一个常年折腾本地部署、也跟过几轮模型架构迭代的人我第一反应是这次可能真不是标题党。先把话说清楚这个1/4显存、1/8硬盘说的不是模型体积直接砍到这么小而是指在推理阶段的显存占用和KV Cache落盘/存储开销这两个维度上相比传统稠密模型或者上一代方案有了数量级的优化。存储股为什么会慌因为过去两年整个AI硬件叙事里最硬的一条逻辑就是模型越大显存和存储需求越猛HBM涨价、企业级SSD缺货、DRAM合约价一路走高全是建立在这个假设上的。现在DeepSeek用一套组合拳告诉你这个假设未必成立至少不是线性成立的。我自己是从本地部署DeepSeek系列模型开始真正理解这件事的。最早跑稠密模型的时候一张24G显存的卡跑个中等规模模型都费劲KV Cache一长就直接OOM。后来MoE架构普及参数量上去了但激活参数少推理成本降了一截。再到这次新模型把KV Cache的存储和显存管理做到这个程度我才意识到真正被冲击的不是要不要买硬件而是买多少硬件、按什么比例配这套沿用已久的经验公式。这篇文章我想聊的不是股价涨跌那玩意儿谁也说不准。我想聊的是这套1/4显存、1/8硬盘背后的技术逻辑到底是什么MoE、KV Cache、HBM、SSD这几个关键词是怎么串起来的以及作为一个实际要部署模型、要配机器的人你应该怎么理解这件事、怎么调整自己的硬件策略。不管你是刚入门想本地跑个模型玩玩还是已经在做推理服务、要算成本账这里面的门道都值得掰开揉碎讲一遍。2. 拆解1/4显存、1/8硬盘数字背后的技术账2.1 先搞清楚这两个数字到底在说什么很多人看到1/4显存第一反应是模型变小了其实不是。这里的1/4指的是在相同上下文长度、相同并发的条件下推理时占用的显存相比传统方案降到了四分之一左右。这里面最大的一块贡献来自KV Cache的优化而不是模型权重本身。KV Cache是什么打个比方你让模型读一本长篇小说然后回答问题模型每读一个字都要记住前面所有内容的要点这些要点就是KV Cache。传统做法是把这些要点全部堆在显存里上下文越长、并发越高堆得越多显存直接爆掉。而新方案通过更激进的量化、分层存储、以及把一部分不活跃的KV Cache挪到更便宜的存储介质上把显存占用压了下来。1/8硬盘则更微妙。它不是说硬盘需求变成八分之一而是指在KV Cache落盘、模型分片存储、以及检查点管理这些环节上单位有效负载所需的存储空间和IO压力大幅下降。过去大家配机器习惯性认为模型多大硬盘就得留几倍空间现在这个倍数关系被打破了。2.2 MoE架构让参数量和计算量脱钩要理解这套优化绕不开MoE混合专家架构。传统稠密模型是每个token都要过一遍全部参数参数量等于计算量。MoE的思路是把模型拆成很多个专家每个token只激活其中一小部分专家。这样总参数量可以做得很大但实际参与计算的参数很少。我拿一个具体场景说明。假设一个MoE模型总参数671B但每个token只激活37B。那么推理时真正需要加载和计算的就是这37B对应的专家其余专家可以放在慢速存储上待命。这就直接改变了显存和存储的配比逻辑——你不需要把全部参数塞进显存只需要保证当前激活的专家在显存里就行。但MoE也有代价。专家调度本身有开销如果调度策略不好会出现某些专家被频繁激活、某些专家常年闲置的负载不均问题。而且专家切换意味着频繁的显存和存储之间的数据搬运这对IO带宽是考验。所以MoE能不能真正省资源很大程度上取决于调度和缓存策略做得好不好。这次新模型让人关注的点恰恰是它在专家调度和KV Cache管理上做了比较激进的工程优化。2.3 KV Cache优化从全放显存到分层存储KV Cache的优化是这次最核心的技术点我拆成几个层次讲。第一层是量化。KV Cache本质是一堆浮点数传统用FP16存现在可以量化到INT8甚至更低。量化会损失一点精度但对很多任务来说影响可控。这一层能把显存占用直接砍半甚至更多。第二层是分层存储。不是所有KV Cache都一样重要。最近刚生成的token对应的KV Cache访问频率高老的、远的token访问频率低。于是可以把热数据放显存HBM温数据放内存DRAM冷数据放SSD。这就是为什么标题里同时出现了HBM和SSD——它们在这个架构里是协同工作的不是互相替代。第三层是淘汰与压缩。对于特别长的上下文一些明显不重要的KV Cache可以直接丢弃或者用更紧凑的方式表示。这有点像人读长文时会自动忽略无关段落只记住关键信息。这三层叠加起来才有了1/4显存的效果。而1/8硬盘则跟KV Cache落盘的格式、压缩率、以及写入策略有关。如果落盘时做了压缩和去重单位上下文的存储开销自然大幅下降。2.4 HBM和SSD不是替代关系是分工关系很多人误以为这个优化意味着HBM不重要了SSD要起飞了这个理解是偏的。真实情况是两者的分工更清晰了。HBM的特点是带宽极高但容量有限、价格昂贵。它适合放最热的数据——当前激活的专家权重、最近窗口的KV Cache。SSD的特点是容量大、价格相对便宜、但带宽和延迟远不如HBM。它适合放冷数据——不活跃的专家、历史KV Cache、模型检查点。新模型的价值在于它让这个分工变得更精细、更自动化。过去你可能需要手动决定什么放显存什么放硬盘现在框架层面帮你做了。这就意味着同样一块HBM能服务的有效负载更大了同样一块SSD能承载的上下文更长了。存储股慌的不是需求消失而是需求结构变了——企业级高带宽SSD和HBM的配比可能要重新算而大容量、中等带宽的SSD需求可能反而上升。3. 从架构到落地本地部署时这些参数怎么调3.1 显存预算怎么算一个可复用的估算方法光讲原理没用实际部署时你得会算账。我分享一个自己常用的显存估算思路虽然不同框架有差异但大方向是一致的。推理显存占用大致等于三部分模型权重 KV Cache 激活值和临时缓冲。模型权重这块MoE模型要看你加载了多少专家。如果框架支持专家按需加载那常驻显存的只是当前激活的专家加上一些缓存。KV Cache这块公式大致是2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 并发数 × 每元素字节数。这个公式里序列长度和并发数是你能控制的变量量化精度决定了每元素字节数。我举个实际例子。假设一个模型有60层注意力头配置是64头、头维度128序列长度8192并发4KV Cache用INT8存储每元素1字节。那么KV Cache大小约为2 × 60 × 64 × 128 × 8192 × 4 × 1 字节算下来大概是32GB左右。如果用FP16就是64GB。这就是量化带来的直接差异。实际部署时我会先按这个公式估一个上限然后留20%到30%的余量给激活值和碎片。如果显存不够优先降并发其次降序列长度最后才考虑降量化精度——因为量化精度对输出质量的影响是最直接的。3.2 专家调度策略别让SSD成为瓶颈MoE模型部署时专家调度是性能的关键。我踩过的坑是一开始把所有专家都放在SSD上以为按需加载很省显存结果推理速度慢得没法用。原因是专家切换太频繁SSD的随机读延迟成了瓶颈。后来调整策略把高频激活的专家常驻显存低频的放SSD并且给专家加载加了一层预取——根据当前token的上下文预测接下来可能激活哪些专家提前加载。这个改动让吞吐提升了好几倍。具体怎么判断哪些专家高频我的做法是跑一批代表性输入统计每个专家的激活次数然后按热度排序。热度前30%到40%的专家常驻显存剩下的放SSD。这个比例不是固定的取决于你的显存大小和任务类型。如果你的任务领域很集中可能前20%就够了如果任务很杂可能要到50%。提示专家热度统计一定要用你自己的真实业务数据不要用网上的通用benchmark。不同领域的专家激活分布差异非常大用错了数据会导致缓存策略完全失效。3.3 KV Cache落盘格式选择和IO优化KV Cache落盘这块格式选择很关键。我试过几种方案直接存原始浮点数组最简单但最占空间存压缩后的格式省空间但增加CPU开销。实测下来如果SSD空间不是特别紧张用轻量压缩比如简单的差分编码性价比最高。IO优化方面有几个点值得注意。第一是批量写入不要每生成一个token就落盘一次攒一批再写减少IO次数。第二是顺序写优先SSD对顺序写的友好度远高于随机写尽量让KV Cache按顺序追加。第三是预留OP空间SSD的过度配置over-provisioning对写入性能影响很大如果这块盘专门用来做KV Cache落盘可以适当多留一些OP空间。关于SSD的过度配置很多人不知道是什么意思。简单说就是SSD实际容量比标称容量大一点多出来的部分用作垃圾回收和磨损均衡的缓冲。厂商默认会留一部分但如果你自己组RAID或者做特殊用途可以手动调整。对于KV Cache这种高频写入场景多留OP能明显延长寿命、稳定性能。3.4 一个真实的部署配置参考我把最近一次部署的配置列出来供参考。硬件是一台单卡工作站显卡显存48GB内存256GB系统盘和模型盘是两块2TB的NVMe SSD另外挂了一块4TB的SATA SSD专门做KV Cache落盘。模型是MoE架构总参数规模中等偏上。部署时权重放在NVMe盘上常驻显存的专家占40%KV Cache热数据在显存、温数据在内存、冷数据落SATA SSD。实测在8K上下文、并发4的情况下显存占用稳定在40GB左右没有OOM首token延迟和吞吐都在可接受范围。这套配置的关键在于把不同热度的数据放在了不同介质上而不是一味堆显存。如果全放显存48GB根本不够如果全放SSD速度又太慢。分层才是正解。4. 存储股慌的逻辑需求结构变了不是需求没了4.1 过去两年的硬件叙事是怎么建立的要理解存储股为什么慌得先理解过去两年市场是怎么给存储定价的。核心逻辑就一条AI模型越大对显存和存储的需求越猛。这个逻辑推导出一系列结论——HBM供不应求、企业级SSD缺货、DRAM合约价上涨、存储厂商扩产。这个逻辑本身没错但它隐含了一个假设需求和模型规模是线性甚至超线性关系。模型参数翻倍显存需求翻倍存储需求翻倍。整个产业链的扩产计划、定价策略、库存管理都建立在这个假设上。DeepSeek这次的动作动摇的正是这个假设。它证明了通过架构优化和工程手段可以在模型能力不降的前提下把单位有效负载的硬件需求压下来。这就意味着即使模型继续变大硬件需求的增速也可能远低于预期。4.2 被冲击的和被利好的分别是谁我自己的判断是这次冲击是结构性的不是全面的。被冲击最明显的是高端HBM和企业级高带宽SSD的超额需求预期。过去大家按最坏情况备货现在发现可能用不了那么多库存压力就上来了。尤其是那些专门为AI训练和推理优化的高溢价产品需求弹性会比较大。被利好的是大容量、中等带宽的SSD和内存。因为分层存储策略需要大量便宜的存储介质来放冷数据。你不需要最快的盘但你需要很大的盘。这对消费级NVMe和SATA SSD其实是好事。还有一个容易被忽略的点端侧和本地部署。当推理成本降下来更多任务可以在本地跑不需要全部上云。这会带动一波个人工作站和小型服务器的硬件需求虽然单价不高但量大。4.3 对普通用户和开发者的实际影响对普通用户来说最直接的影响是本地跑大模型的门槛降低了。以前你可能需要一张很贵的卡才能跑动某个模型现在同样的卡能跑更长的上下文、更高的并发。这对想在自己电脑上折腾模型的人是实打实的好消息。对开发者来说成本账要重新算。如果你在做推理服务过去可能按每路并发需要多少显存来配机器现在这个数字变了你的单位成本结构也变了。我建议做推理服务的团队重新跑一遍容量规划别沿用旧公式。对做硬件的厂商来说产品定义可能要调整。过去拼的是峰值带宽和极致性能现在可能更要拼容量、能效比和每GB成本。谁能把大容量存储做得更便宜更稳谁就能吃到这波结构性变化。5. 实操避坑本地部署MoE模型和KV Cache管理的经验5.1 常见问题速查表我把本地部署这类模型时最常遇到的问题整理成表方便对照排查。问题现象可能原因排查方向解决思路推理时OOMKV Cache超预算算KV Cache公式看序列长度和并发降并发或序列长度或提高量化等级首token延迟高专家加载慢看专家是否在SSD上频繁切换提高常驻显存专家比例加预取吞吐上不去SSD随机读瓶颈监控SSD IOPS和延迟改顺序写加OP空间换更快的盘输出质量下降量化过度对比不同量化等级的输出提高KV Cache精度或只对冷数据量化显存碎片严重频繁分配释放看显存分配日志预分配显存池减少动态分配落盘文件暴涨未压缩未去重看落盘格式和大小启用压缩定期清理冷数据5.2 几个我踩过的坑第一个坑是盲目追求低显存。刚开始我为了在有限显存上跑更大的模型把量化等级压得很低结果输出质量明显下降回答开始胡言乱语。后来才明白量化要分对象——模型权重量化影响大KV Cache量化影响相对小。优先量化KV Cache模型权重尽量保持高精度。第二个坑是忽略SSD寿命。KV Cache高频落盘对SSD的写入量很大我有一块盘用了几个月健康度就掉得厉害。后来换了带更高TBW的企业级盘并且调整了落盘策略减少不必要的写入情况才好转。如果你打算长期跑SSD的TBW指标一定要看。第三个坑是专家缓存策略一刀切。我一开始对所有任务用同一套专家缓存配置结果发现有些任务快有些任务慢。后来按任务类型分别统计专家热度做了多套配置性能才稳定下来。5.3 关于内存现在还紧张吗的实话这个问题最近被问得很多。我的观察是紧张与否取决于你站在哪个位置。对于做超大模型训练的团队高端HBM和高速互联依然是瓶颈该紧张还是紧张。但对于做推理、做本地部署、做端侧应用的人来说选择变多了不一定非要最顶配的硬件。内存和存储的紧张很大程度上是结构性错配——高端产品紧张中低端产品过剩。这次架构优化会加速这种错配的调整。作为使用者你的策略应该是别盲目追高配按实际负载配硬件把省下来的预算花在容量和冗余上。6. 后续可以怎么扩展几个值得关注的方向6.1 端侧部署的可能性这套优化思路如果继续演进端侧部署会越来越现实。现在手机上跑小模型已经可行如果KV Cache管理和专家调度能进一步轻量化未来在笔记本甚至手机上跑中等规模MoE模型不是梦。这对隐私敏感、离线场景、低延迟需求的应用是重大利好。6.2 存储产品的重新定位对做存储的厂商来说产品线可能要重新思考。过去大家拼的是最快现在可能要拼最合适。针对AI推理场景优化的存储产品可能不需要极致带宽但需要大容量、高耐久、低功耗、好管理。这是一个新的产品定义空间。6.3 推理框架的竞争焦点框架层面的竞争会从支持多少模型转向调度和缓存做得多细。谁能把KV Cache分层、专家预取、显存复用这些工程细节做到极致谁就能在同等硬件上跑出更好的性能。这对做推理框架的团队是机会也是挑战。6.4 我个人的一点判断折腾了这么多轮模型部署我最大的体会是硬件和算法是互相塑造的。算法优化会改变硬件需求结构硬件进步又会解锁新的算法可能。这次DeepSeek的动作本质上是算法侧的一次主动调整它逼着硬件侧重新思考产品定义。作为使用者与其焦虑硬件会不会贬值不如把精力放在理解这套新逻辑上——理解了逻辑你自然知道该买什么、该怎么配、该怎么用。硬件会过时但理解需求结构的能力不会。
