120T全闪塞进一台服务器！给DGX Spark造一块“外置内存”

一台2U服务器里，塞进8块15TB级E1.S SSD，接上100GbE网络，连NVMe都纳入水冷系统，这已经不是常见的家庭实验室配置。

但Raid Owl折腾这台机器，并不只是为了做一台高速存储服务器。

最近一段时间，他一直在自己的DGX Spark集群上运行本地AI，也开始注意到推理过程中一个越来越占资源的问题：KV Cache。

大模型处理完Prompt后，会把一部分中间计算结果保留下来，后续生成Token时继续使用。上下文越长、并发越高，这部分缓存占掉的内存也越多。通常它就放在GPU附近，占用的也是最宝贵的一类资源。

他因此想做一个实验：如果把KV Cache放到另一台服务器，甚至进一步写进NVMe，实际效果会怎么样？

为了测试这个问题，他专门搭了一台120TB级的全闪服务器，然后把它接入DGX Spark集群。

先解决存储：8块E1.S组成120TB全闪池

这台服务器使用Sliger CX2257G 2U机箱。选择它的一个重要原因，是前面能够提供四个5.25英寸设备位，同时内部还能容纳一套水冷系统。

其中一侧放置水泵和储液罐，另一侧安装了两组NVMe硬盘仓。上面一组支持8块M.2，下面一组支持8块E1.S，每个盘位都可以提供PCIe x4连接，并通过MCIO接入主板。

硬盘仓本身也带有液冷设计。SSD插入后会直接贴合冷板，通过水路带走热量。因为两组NVMe冷板内部的管路比较细，他还额外加入第二个水泵，提高水路压力，同时给散热系统留出冗余。

这次实际安装的是8块Solidigm D5-P5430，每块容量15.36TB，总容量接近120TB。这是一款面向数据中心的QLC SSD，重点考虑高容量、功耗和单位容量成本。

为了测试最高吞吐，他直接把这些SSD组成RAID 0。

本地测试中，这套阵列的顺序读取达到约46GB/s，顺序写入约20GB/s，随机读取超过100万IOPS。这样的速度已经超过100GbE网络能够实际承载的水平，因此到了远程访问环节，限制性能的因素不会只来自SSD。

液冷效果也比较明显。连续对SSD和CPU进行压力测试时，硬盘温度只到40多摄氏度；后续长时间运行缓存测试，温度基本保持在40℃以内。整机空闲功耗约130W，缓存持续工作时约170W。

硬件准备完成后，这台服务器被接入他的DGX Spark集群，接下来才进入这次实验的核心部分。

从本地到远程，把KV Cache分成四层

KV Cache可以理解为大模型在推理过程中保存下来的中间计算结果。

模型第一次处理Prompt时，需要进行Prefill，把整段上下文计算一遍。完成之后，对应的Key和Value会被保存下来。之后继续生成Token时，模型可以直接利用这些结果，不必再次计算前面的全部内容。

问题也随之出现。Prompt越长，同时运行的请求越多，KV Cache占用的内存就越大。在一些推理场景里，它消耗的空间甚至可能超过模型权重。

vLLM本身支持在空间不足时，把KV Cache转移到系统内存。这次实验使用的LMCache，又把缓存范围扩展到了其他计算节点和远程存储。

他在多台DGX Spark上运行Qwen3-8B FP16，每台机器部署一个独立的模型实例，然后为KV Cache设置了几层不同的位置。

最靠近计算的是本地缓存，也就是L0；L1通过P2P从其他Spark节点获取KV Cache；L2进入那台远程服务器的系统内存，并使用Redis和Valkey作为后端；L3则落到120TB NVMe存储池，通过NFS over RDMA进行访问。

这样一来，同一段已经计算过的上下文，就有机会在不同模型实例之间重复利用。GPU本地空间有限时，也可以把部分缓存放到容量更大的远程设备上。

这个思路在结构上很清楚，但实际跑起来之后，他很快遇到了问题。最初的测试结果中，本地缓存明显最快，后面的P2P、远程内存和NVMe差距却很小。经过几天排查，他才发现P2P缓存一直在静默失败，系统直接跳过了这一层。

问题修复后，P2P的性能明显提高，这也符合预期：从相邻Spark节点直接获取缓存，数据路径比访问远程服务器更短。

但继续往下，远程内存和NVMe的优势就没有那么明显了。

远程缓存只快约10%，但重启之后还能继续使用

在他的测试中，通过Redis访问远程内存，以及从NVMe读取KV Cache，与直接重新计算相比都没有拉开很大差距，大致只有10%左右的优势。

原因也比较容易理解。Redis的数据虽然放在内存里，但节点之间还要经过TCP通信；NVMe服务器使用了RDMA，数据访问前面仍然有NFS这一层。整套系统最终性能取决于完整的数据路径，底层SSD的46GB/s读取速度只是其中一个环节。

如果只看TTFT，也就是首Token延迟，这组结果并不算突出。但随后的一次重启测试，让NVMe缓存表现出了另一项特性。

他先按照固定方式向模型发送一批请求，让生成的KV Cache进入NVMe存储池。之后把整套系统完全关闭，再重新启动，然后重复发送相同请求。

此前保存在SSD里的缓存依然存在，重新启动后可以直接命中，测试中的命中率达到100%。模型因此省去了重新构建对应上下文的Prefill过程。

实验进行到后期，他已经在NVMe池里积累了超过1TB的KV Cache。

对于他的家庭实验室，这套方案显然有些重。他平时主要使用DGX Spark集群运行一个大型模型，本地缓存和节点间共享已经能够满足多数需求，因此暂时没有计划长期保留完整的远程KV Cache架构。

但这次测试至少验证了一件事：KV Cache可以离开单台GPU，也可以离开单台计算节点，继续存放在远程内存和NVMe中。

更值得注意的是持久性。放在显存和系统内存中的KV Cache，服务器重启后通常就会消失；写进NVMe后，之前已经完成的计算结果可以继续保留。

对个人用户来说，这种能力未必有多大意义。可如果推理集群同时服务大量用户，长期积累的KV Cache达到数TB甚至更大规模，服务器维护、升级和重启之后是否需要全部重新计算，就会成为一个实际的成本问题。

这也是他做完整个实验后留下的一个观察：随着AI推理规模扩大，存储系统除了放模型权重和数据集，也可能开始承担一部分推理缓存。