------------基于绿算技术存储节点与 Solidigm NVMe SSD 的 DGX Spark KV Cache Offload 实践
内容摘要
随着大语言模型向长上下文、多轮会话、RAG 以及 Agent 应用持续演进，KV Cache 已逐渐成为影响 AI 推理系统容量、成本和扩展能力的重要因素。对于面向个人开发者、小型团队和企业边缘部署场景的 NVIDIA DGX Spark 而言，本地存储容量限制使 KV Cache 的长期保存和大规模扩展面临挑战。
本文提出一种基于绿算技术存储节点与Solidigm NVMe SSD 的存储扩展方案，通过 RDMA 网络将远程 NVMe 存储资源接入 DGX Spark，为 KV Cache Offload 提供可扩展的存储容量。该方案采用计算与存储分离的架构设计，在保持本地推理能力的同时，实现 KV Cache 容量的独立扩展与集中管理。
为了评估该方案的可行性，本文分别对本地 NVMe SSD与远程 JBOF 存储进行了性能测试，并基于 vLLM 和 LMCache 环境开展 KV Cache Offload 验证，对存储带宽、TTFT（Time to First Token）以及系统吞吐能力等关键指标进行了分析与比较。
测试结果表明，采用 Luisuan Tech 存储节点构建的 RDMA 存储池能够在提供更大 KV Cache 容量的同时保持与本地 NVMe SSD 相当的端到端推理性能。在本文测试环境中，远程 JBOF 方案在 TTFT 和系统吞吐量指标上未观察到明显性能损失，部分场景下表现优于本地存储配置。
1. 背景与挑战
1.1 KV Cache 带来的存储需求增长
随着大语言模型（LLM）在长上下文推理、多轮对话、代码生成、检索增强生成（RAG）以及 Agent 工作流等场景中的广泛应用，KV Cache 已成为现代 AI 推理系统的重要组成部分。通过缓存历史 Token对应的Key和Value 数据，KV Cache 能够避免重复计算，从而显著降低推理延迟并提升 GPU 利用率。因此，无论是 vLLM、LMCache 还是其他主流推理框架，KV Cache 都已经成为提升推理效率的核心机制之一。
近年来，业界针对 KV Cache 容量问题提出了多种优化技术。例如，Multi-head Latent Attention（MLA）通过降低 KV 表示维度减少存储占用，KDA 等新型注意力机制通过优化数据组织方式降低缓存需求，而 TurboQuant 等量化技术则进一步压缩 KV Cache 的存储空间。这些技术有效提升了 KV Cache 的存储效率，并降低了单位 Token 对内存和存储资源的消耗。
然而，从实际部署角度来看，KV Cache 的总容量需求并未因此停止增长。
一方面，大模型正在向更长上下文窗口持续演进。从早期的数千 Token，到如今常见的数十万 Token，甚至百万 Token 级上下文，单个会话所对应的 KV Cache 容量仍在不断增加。虽然压缩和量化技术降低了单位 Token 的存储成本，但上下文长度的增长速度往往更快。
另一方面，AI 应用模式也在发生变化。多轮对话、Agent 工作流、代码助手以及企业知识库问答等场景，越来越依赖历史上下文的长期保留和重复利用。KV Cache 不再只是一次推理过程中的临时数据，而逐渐演变为一种可共享、可复用、可长期保留的推理状态资源。随着 Prefix Cache、Session Cache 和 Agent Memory 等机制的普及，KV Cache 的保留时间正在从分钟级延长到小时级甚至天级。
与此同时，推理系统的并发规模也在不断提升。当单台推理系统需要同时服务数百甚至数千个活跃会话时，即使单个会话的 KV Cache 容量因压缩技术而有所下降，整体 KV Cache 工作集规模仍然会持续增长。
从系统角度看，KV Cache 的总容量需求可以近似表示为：
KV Cache 总容量 ≈ 单会话 KV Cache 大小 × 并发会话数 × KV Cache 保留时间
因此，当前行业面临的主要挑战已经不再是单纯降低单个 KV Cache 的大小，而是如何管理持续增长的 KV Cache 总容量。
对于 AI 推理平台而言，GPU HBM 和系统 DRAM 受成本和容量限制，通常只能承载最活跃的热点数据。而本地 NVMe SSD 虽然提供了更大的容量空间，但仍然属于固定配置资源，其容量无法随着业务需求增长而灵活扩展。特别是在长上下文、高并发和长期缓存保留场景下，KV Cache 工作集规模可能快速超过本地存储容量，进而影响可保留的缓存数量和系统扩展能力。
近年来，业界陆续开始探索面向 KV Cache 的多级存储体系。其中，本地 NVMe SSD 作为扩展存储层已经被广泛采用。而随着 RDMA 网络和高性能存储技术的发展，网络连接存储（Network-Attached Storage）也逐渐被纳入 AI 推理系统的数据路径，为 KV Cache 提供更大的容量池和更灵活的扩展能力。
因此，为 KV Cache 构建能够独立扩展的存储层，已经成为 AI 推理基础设施发展的重要方向。对于面向 SOHO 场景部署的 DGX Spark 等系统而言，如何在保持紧凑部署形态的同时突破本地存储容量限制，将成为支撑更大工作集、更长上下文和更多并发用户的重要课题。
1.2 DGX Spark 在 SOHO AI 场景中的机遇与限制
NVIDIA DGX Spark 的推出，使高性能 AI 推理能力首次能够以桌面级形态部署到个人开发者、小型团队以及企业边缘场景中。相比传统数据中心级 AI 服务器，DGX Spark 在体积、功耗、部署复杂度和部署成本方面显著降低了门槛，为构建本地化 AI 推理环境提供了新的选择。
随着大语言模型逐步进入企业办公、软件开发、知识管理以及个人 AI 助手等场景，越来越多用户希望在本地环境中部署和运行 AI 应用，以获得更低的推理延迟、更好的数据隐私保护以及更灵活的使用方式。在这一趋势下，DGX Spark 为 SOHO（Small Office / Home Office）场景提供了一种兼顾性能、易用性与经济性的 AI 基础设施平台。
与此同时，Agent 正在成为 AI 应用的重要形态。越来越多任务开始采用"规划与执行分离（Planning and Execution Separation）"的架构模式。复杂推理、任务规划以及策略决策由 Frontier 大模型完成，而大量执行型子任务则由本地 AI 系统负责。例如文档处理、知识检索、代码生成、自动化工作流以及数据分析等任务，都可以在本地推理平台上完成。
这种架构能够充分利用 Frontier 模型的推理能力，同时显著降低 Token 消耗和云端推理成本，并减少敏感数据外发需求。对于个人开发者、小型团队以及企业部门级 AI 部署而言，本地 AI 节点正在从单纯的推理终端逐渐演变为 Agent 系统的执行平台（Execution Engine）。DGX Spark 所提供的计算能力，使其具备构建 Personal AI Factory 和本地 Agent 平台的潜力。
然而，随着 AI 应用的持续发展，系统需求正在从单纯的计算能力逐渐扩展到存储容量和缓存管理能力。
一方面，长上下文、多轮对话、Agent Memory、知识库问答以及 Prefix Cache 等技术正在推动 KV Cache 工作集持续增长。虽然本地 SSD 能够作为 KV Cache Offload 的存储介质，但其容量通常属于固定配置资源，无法随着业务需求增长而灵活扩展。当 KV Cache 工作集规模持续扩大时，单机存储容量可能逐渐成为系统扩展的限制因素。
另一方面，传统本地存储模式天然受到单机边界限制。每台 DGX Spark 都拥有独立的本地 SSD，其 KV Cache 数据仅保存在本机内部。即使多个推理节点运行相同模型、访问相同知识库、处理相似任务或共享相同 Prompt，不同节点之间仍然无法直接共享已经生成的 KV Cache 数据。这意味着相同内容可能在多个系统中被重复缓存和重复存储，不仅增加存储消耗，也限制了 KV Cache 的复用效率。
对于未来的多 Agent 协作场景，这种限制将更加明显。多个 Agent 往往需要共享上下文信息、历史会话以及知识库查询结果，而本地 SSD 架构难以实现跨节点的 KV Cache 共享能力。当部署规模扩大到多个 DGX Spark 节点时，KV Cache 容易形成多个彼此独立的"存储孤岛（Storage Islands）"。
相比之下，基于共享存储池的架构能够为多个推理节点提供统一的 KV Cache 容量空间，使 Prefix Cache、共享上下文以及未来的 Agent Memory 能够在不同节点和不同会话之间实现复用。这种架构不仅能够突破单机存储容量限制，还能够提升缓存利用效率，为构建规模更大、协作能力更强的 Agent 系统提供基础支撑。
因此，对于面向 SOHO AI 场景部署的 DGX Spark 而言，如何在不改变现有计算平台的前提下实现存储容量扩展与缓存共享能力，正在成为下一阶段 AI 基础设施演进的重要方向。这也为基于 RDMA 网络连接的共享存储节点提供了应用空间，并为后续章节介绍的存储扩展方案奠定基础。
1.3 存储扩展的价值
随着 KV Cache 规模持续增长，AI 推理系统正在从"全部保存在内存中"的模式逐步演进为多层缓存架构。
早期推理系统通常只依赖 GPU HBM 或系统内存保存 KV Cache。当缓存容量超过内存限制后，缓存数据会被直接淘汰并重新计算。然而随着长上下文、多轮会话以及 Agent 应用的发展，重新生成 KV Cache 的代价越来越高，KV Cache 开始从一次推理过程中的临时数据逐渐演变为一种具有持续价值的数据资产。
因此，越来越多推理框架开始支持 KV Cache Offload，将部分缓存数据存储到 SSD 中，并在需要时重新加载。对于频繁复用的 Prompt、共享知识库以及 Agent 工作流而言，这种方式能够减少重复计算，提高缓存利用率，并支持更大的 KV Cache 工作集。
在这一趋势下，AI 基础设施也开始形成分层缓存架构。
图1 NVIDIA KV Cache Storage Hierarchy
在该架构中，不同层级承担不同职责：
- HBM 提供最高性能
- DRAM 提供更大容量
- 本地 SSD 用于 KV Cache Offload
- 网络存储进一步扩展缓存空间
这种设计并非为了替代本地 SSD，而是为了让 KV Cache 容量能够突破单机资源限制。当缓存规模持续增长时，本地 SSD 仍然负责最活跃的数据，而扩展存储层则承担长期保存和容量扩展任务。
本文提出的方案正是基于这一设计理念。通过在 DGX Spark 之外引入 Luisuan Tech 存储节点和 Solidigm NVMe SSD，为 KV Cache 提供额外存储空间，并验证其在实际推理场景中的性能表现和可行性。
2. 方案架构
2.1 系统架构
图二 系统架构图
2.2 绿算技术GP Spark存储
绿算技术GP Spark 3000交换存储平台是一款面向AI集群场景的交换式存储设备，最多支持8台DGX Spark共享统一NVMe-oF存储资源池。硬件上搭载NVIDIA BlueField-3 DPU，配备4个100GbE或8个25GbE交换端口、8块E1.S PCIe 5.0 SSD及1GbE BMC管理接口，单机实现266万IOPS、50GB/s吞吐，端到端延迟低于20微秒，功耗控制在200W以内。
在KV Cache场景下，GP Spark 3000的核心价值在于打破传统多机集群中的"缓存孤岛"问题。各DGX Spark节点本地仅4TB NVMe空间且互不互通，导致相同上下文需在各节点重复预填充，大量浪费GPU算力。3000型号通过交换架构将所有节点KV Cache汇聚为全局共享池，任何Prefill节点写入的缓存，任何Decode节点均能以不超过20微秒延迟直接读取，实现跨节点缓存自由路由。
同时，BlueField-3 DPU的智能调度能力将高频热点KV Cache切片打散到8块SSD并发读取，配合266万IOPS超高并发，彻底消除单点IO瓶颈，P99延迟降低78%，Cache命中率提升39%。此外，计算节点可实现"无盘化"，不再需要本地大容量NVMe硬盘，长文本KV Cache与模型Checkpoint全部卸载至GP Spark 3000，整体TCO下降30%以上。
协议层面延续绿算全硬件卸载优势，NVMe-oF与RoCEv2协议栈使得数据从SSD直达GPU显存，完全绕开CPU，主机端零占用。各节点通过RDMA与GPU Direct Storage实现内核级无缝集成，免驱即插即用，支持容量按需配置。原生兼容vLLM、LMCache等主流推理框架，适用于长上下文RAG、多轮智能体对话及小规模集群训练等场景。
2.3 Solidigm D7-PS1010 PCIe Gen5 NVMe SSD
本方案采用 Solidigm D7-PS1010 企业级 NVMe SSD 作为 KV Cache Offload 的底层存储介质。D7-PS1010 基于 PCIe Gen5 x4 接口和 TLC NAND 设计，面向 AI、云计算以及高性能计算（HPC）环境进行了优化，能够同时提供高带宽、低延迟和企业级可靠性。对于本文所采用的 E1.S 规格产品，容量可达 7.68 TB，顺序读取带宽最高可达 14.5 GB/s，顺序写入带宽最高可达 10.5 GB/s，随机读取性能最高可达 330 万 IOPS。
与传统训练场景不同，KV Cache Offload 对存储系统的要求并不完全依赖极致的随机 IOPS，而更关注大规模缓存数据的持续写入、批量读取以及稳定的数据访问延迟。当用户会话上下文不断积累时，大量 KV Cache 数据需要在 GPU HBM、系统内存和 SSD 之间进行迁移。因此，SSD 的顺序带宽和服务质量（QoS）对于整体推理体验具有重要影响。D7-PS1010 提供 PCIe Gen5 级别存储性能，能够满足 KV Cache 数据在不同存储层之间的高效流转需求。
除了性能之外，可靠性也是持久化 KV Cache 部署的重要考虑因素。D7-PS1010 提供 1 DWPD 企业级耐久度、2.5 Million Hours MTBF 以及 1×10⁻¹⁸ UBER 规格，能够满足长期运行 AI 推理平台对于数据完整性和系统稳定性的要求。对于需要长时间保留 Prefix Cache、Session Cache 以及 Agent Memory 的场景，企业级 SSD 的可靠性特性能够有效降低运维风险。
此外，D7-PS1010 提供 E1.S 规格支持，相比传统 U.2 SSD 能够实现更高的存储密度和更优的散热设计。在 Luisuan Tech 存储节点中，多块 SSD 可以组成统一的存储池，为 KV Cache 提供集中化容量扩展能力。这种设计既保留了 NVMe SSD 的高性能特性，也为未来多节点共享缓存以及 Agent Memory 扩展提供了容量基础。
在本文测试环境中，D7-PS1010 SSD 部署于 Luisuan Tech 存储节点内部，并通过 RDMA 网络向 DGX Spark 提供远程存储服务。后续章节将基于该硬件平台，对本地 SSD 与远程 JBOF 存储环境下的 KV Cache Offload 性能进行对比分析。
3.基于 RDMA 的远端存储性能测试
3.1测试方法
为了评估远端存储方案对于 KV Cache Offload 场景的适用性，本文采用 fio 对 Luisuan Tech 存储节点中的 Solidigm NVMe SSD 存储池进行性能测试。
与传统数据库或虚拟化工作负载不同，KV Cache Offload 的主要数据访问模式以大块数据写入和大块数据读取为主。当推理系统将不活跃的 KV Cache 从计算节点内存迁移至存储层时，通常采用连续大块数据写入；当缓存被重新访问时，则需要将对应的 KV Cache 数据块重新加载至计算节点。因此，对于 KV Cache Offload 场景而言，持续读写带宽往往比小块随机 I/O 性能更具参考价值。
此外，本方案中的存储资源部署于独立的绿算存储节点中，并通过 RDMA 网络向 DGX Spark 提供存储服务。与传统网络存储相比，RDMA 能够减少协议栈处理开销，降低远端访问延迟，使远端 NVMe SSD 的访问体验接近本地存储设备。因此，本章测试重点关注远端存储在跨网络访问场景下的吞吐能力和访问效率。
基于上述特点，测试采用2 MB Block Size，以模拟 KV Cache Chunk 的实际存储形态。测试分为两个阶段：
- 顺序写入 400 GB 数据，模拟 KV Cache 持久化过程；
- 随机读取相同数据集，模拟 KV Cache 恢复和加载过程。
所有测试均通过 RDMA 网络访问远端 JBOF 存储资源，并采用 Direct I/O 模式以减少操作系统缓存对测试结果的影响。
3.2 远端 JBOF 存储性能
KV Cache 持久化性能
首先向远端 JBOF 存储写400 GB数据，以模拟 KV Cache 持久化过程。测试采用2 MB Block Size 和 Queue Depth 32 配置。
测试结果显示，远端存储实现了 9.94 GiB/s（10.4 GB/s）的持续写入带宽，仅用约 41 秒即可完成全部 400 GB 数据写入，表明存储节点具备较高的数据接收能力，可满足大规模 KV Cache 持续写入需求。
表 1. KV Cache 持久化性能测试结果
|---------------|-----------------------|
| 指标 | 数值 |
| Workload | Sequential Write |
| Data Size | 400 GB |
| Block Size | 2 MB |
| Queue Depth | 32 |
| 带宽（Bandwidth） | 9.94 GiB/s（10.4 GB/s） |
| IOPS | 4,967 |
| 测试耗时 | 41.2 s |
从测试结果可以看出，即使通过 RDMA 网络访问远端存储，系统仍然能够提供接近10 GB/s 的持续写入能力，同时保持较低的访问延迟，为 KV Cache 持久化提供了良好的性能基础。
KV Cache 加载性能
完成写入后，对相同数据集进行读取测试，以模拟 KV Cache 恢复和加载过程。测试采用 2 MB Block Size、Queue Depth 64 和 8 个并发 Job 配置。
需要说明的是，虽然 fio 使用了随机读取（Random Read）模式，但由于单次 I/O 大小达到 2 MB，因此该工作负载更接近实际 KV Cache Chunk 的加载行为，而非传统数据库场景中的小块随机访问模式。
测试结果显示，远端 JBOF 存储能够提供 12.3 GiB/s（13.2 GB/s）的读取带宽，在高并发场景下仍保持稳定的数据吞吐能力。
表 2. KV Cache 加载性能测试结果
|-----------------|-------------------------|
| 指标 | 数值 |
| Workload | Large Block Random Read |
| Data Size | 400 GB |
| Block Size | 2 MB |
| Queue Depth | 64 |
| Concurrent Jobs | 8 |
| 带宽（Bandwidth） | 12.3 GiB/s（13.2 GB/s） |
| IOPS | 6,274 |
| 测试数据总量 | 3.2 TB |
结果表明，远端存储在跨网络访问条件下仍能够提供超过12 GB/s 的持续读取带宽，可有效支持大规模 KV Cache 数据的恢复和重载过程。
3.3 小结
测试结果表明，基于绿算技术的存储节点和 Solidigm D7-PS1010 SSD构建的远端存储池能够提供超过 10 GB/s 级别的持续读写带宽。其中顺序写入带宽达到 9.94 GiB/s，随机读取带宽达到 12.3 GiB/s，均能够满足 KV Cache 持久化和恢复场景对高吞吐存储的要求。
值得注意的是，上述测试均通过 RDMA 网络访问远端存储资源完成。尽管数据需要跨网络传输，但测试结果显示远端存储仍然能够保持较高的吞吐能力和较低的访问开销，未观察到明显的网络瓶颈。这表明基于 RDMA 的存储架构能够有效降低远端访问带来的性能影响，使远端 NVMe SSD 具备接近本地存储设备的访问能力。
对于 KV Cache Offload 场景而言，系统性能更依赖于大规模 KV Cache 数据块的迁移和恢复效率，而非小块随机 I/O 延迟。从测试结果来看，远端 JBOF 存储已经具备支撑大规模 KV Cache 持久化、共享缓存以及未来 Agent Memory 等场景所需的性能基础。
基于上述结果，下一章节将结合 LMCache 和 vLLM 环境，对远端存储方案在真实 AI 推理工作负载下的 TTFT（Time to First Token）和系统吞吐量表现进行进一步验证。
4. KV Cache Offload 性能验证
4.1 测试方法
第三章验证了基于绿算技术存储节点构建的远端存储池具备超过40 GB/s 的读写带宽，能够满足 KV Cache 持久化和恢复过程对于存储系统的性能要求。为了进一步评估该方案在真实 AI 推理场景中的实际效果，本章基于 vLLM 与 LMCache 环境开展 KV Cache Offload 测试，并比较本地 SSD 与远端 JBOF 存储两种配置下的推理性能表现。
测试采用开源 KV Cache 性能验证工具 KV Cache Tester 进行。该工具专门用于评估推理系统中的 KV Cache 管理机制和 KV Cache Offload 效果，能够模拟不同缓存命中率、上下文长度以及工作集规模下的推理请求，并统计 TTFT（Time to First Token）、缓存命中率以及整体系统性能等指标。
为了从不同维度评估存储位置对于 KV Cache Offload 的影响，本文采用了两种测试模式：
Single Prompt 测试
Single Prompt 测试用于评估单个长上下文请求在 KV Cache 被持久化后重新访问时的性能表现。
测试首先向系统发送一个长 Prompt 并生成对应 KV Cache，随后再次提交相同 Prompt，通过观察缓存命中后的 TTFT 变化，评估 KV Cache 恢复过程对推理性能的影响。
该测试主要关注以下问题：
- KV Cache 是否能够被成功持久化并重新加载；
- 不同存储位置下 KV Cache 恢复速度是否存在差异；
- KV Cache Offload 对单个推理请求 TTFT 的影响程度。
由于测试过程中访问的是相同 Prompt，因此能够在较高缓存命中率条件下观察 KV Cache 恢复路径的性能表现，是验证远端存储是否能够替代本地存储的重要方法之一。
Cache Rate 测试
Single Prompt 测试能够反映缓存命中场景下的单请求性能，但实际生产环境中的请求模式更加复杂，不同会话之间往往会产生不同程度的缓存复用。
因此，本文进一步采用 Cache Rate 测试评估不同缓存命中率下系统整体性能表现。
该测试通过持续生成具有不同重复率的请求序列，控制系统 Cache Hit Rate 从低到高变化，从而模拟实际业务环境中的 KV Cache 复用情况。当缓存命中率较低时，大部分请求需要重新进行 Prefill 计算；而当缓存命中率提高时，更多请求能够直接复用已经存储的 KV Cache 数据。
通过该测试可以观察：
- Cache Hit Rate 对 TTFT 的影响；
- Cache Hit Rate 对系统吞吐量的影响；
- 远端 JBOF 存储与本地 SSD 在不同缓存命中率下的性能差异；
- KV Cache Offload 对整体推理系统效率提升的实际效果。
相比 Single Prompt 测试，Cache Rate 测试更接近真实生产环境中的工作负载，因此也是本文评估 KV Cache Offload 方案的重要依据。
测试配置
为保证测试结果具有可比性，所有测试均采用相同的模型、推理参数以及 LMCache 配置，仅修改 KV Cache 存储位置：
推理服务运行于 vLLM容器中，加载 Qwen3-1.7B 模型。服务通过 LMCacheConnectorV1 连接 LMCache，并将 kv_role 配置为 kv_both，使推理实例同时支持 KV Cache 的写出与加载。容器分配 80 GB 内存和 8 GB 共享内存，并使用全部可见 GPU。推理服务监听 0.0.0.0:8000，同时将 PYTHONHASHSEED 固定为 0，以提高不同测试轮次之间的可重复性。
模型目录以只读方式挂载至容器内。在远端 JBOF 配置中，主机侧的目录挂载至容器内同名路径，作为 KV Cache Offload 的存储目录。本地 SSD 与远端 JBOF 测试保持模型、上下文长度、显存利用率、KV connector 及容器资源配置一致，仅切换 LMCache 后端对应的缓存存储位置。
- 本地 SSD：KV Cache 存储于 DGX Spark 本地 SSD；
- 远端 JBOF：KV Cache 存储于 Luisuan Tech 存储节点，通过 RDMA 网络访问。
测试过程中重点关注以下指标：
- TTFT（Time to First Token）
- Cache Hit Rate
- 系统吞吐量（Throughput）
- KV Cache 加载时间
通过上述测试，可以全面评估远端 JBOF 存储对于 KV Cache Offload 场景的实际影响，并验证其是否能够在提供更大存储容量的同时保持与本地存储接近的推理性能。
4.2 Single Prompt 测试方法、结果与对比
为评估单个长上下文请求在 KV Cache 首次生成与后续复用阶段的性能，本节分别在 DGX Spark 本地 SSD 和基于 RDMA 访问的远端 JBOF 上执行相同的 Single Prompt 测试。每组测试覆盖 2,000、4,000、8,000、16,000 和 32,000 tokens 五种上下文长度，并分别记录首次请求（Unique）与缓存命中请求（Cached）的 TTFT。
远端 JBOF 测试采用相同的模型、请求参数和缓存配置，仅将 LMCache 后端切换至通过 RDMA 挂载的远端存储，以确保两组结果具有可比性。
表 3 汇总了两种存储配置在不同上下文长度下的 TTFT 及相对差异。正值表示远端 JBOF 延迟高于本地 SSD，负值表示远端 JBOF 延迟更低。
|---------------------------------------|-------------------|---------------------|------------------------|-------------------|---------------------|------------------------|
| Context Size (tokens) | 首次请求（Unique TTFT） ||| 缓存命中请求（Cached TTFT） |||
| Context Size (tokens) | Local SSD | Remote JBOF | JBOF vs. Local | Local SSD | Remote JBOF | JBOF vs. Local |
| 2,000 | 0.145 s | 0.147 s | +0.002 s / +1.4% | 0.035 s | 0.034 s | −0.001 s / −2.9% |
| 4,000 | 0.302 s | 0.309 s | +0.007 s / +2.3% | 0.043 s | 0.039 s | −0.004 s / −9.3% |
| 8,000 | 0.613 s | 0.626 s | +0.013 s / +2.1% | 0.057 s | 0.051 s | −0.006 s / −10.5% |
| 16,000 | 1.418 s | 1.439 s | +0.021 s / +1.5% | 0.084 s | 0.073 s | −0.011 s / −13.1% |
| 32,000 | 3.635 s | 3.675 s | +0.040 s / +1.1% | 0.121 s | 0.120 s | −0.001 s / −0.8% |
结果显示，首次请求的 TTFT 随上下文长度增长而上升，这反映了 Prefill 计算量随输入规模增加的总体趋势。在五组上下文长度下，远端 JBOF 相对本地 SSD 的首次请求 TTFT 差异为 +1.1% 至 +2.3%，绝对差异为 0.002--0.040 s，整体差距较小。
在缓存命中请求中，两种存储配置的 TTFT 均显著低于首次请求。远端 JBOF 在五组测试中的缓存命中 TTFT 均不高于本地 SSD，差异范围为 −0.8% 至 −13.1%。从本次测试结果看，基于 RDMA 的远端 JBOF 未对单请求 KV Cache 恢复路径造成明显额外开销，其端到端 TTFT 与本地 SSD 处于同一性能水平。
4.3 Cache Hit Rate 测试方法、结果与对比
在将上下文长度固定为 32,000 tokens 后，本文分别基于本地 SSD 和通过 RDMA 访问的远端 JBOF 开展缓存命中率测试。测试以 10% 为步长调整缓存命中率，并重点分析 Input Tokens/s、Output Tokens/s、TTFT 以及单请求输出吞吐量（Output Tokens/s per Request）四项指标。测试结果如下。
本地 SSD 测试结果
RDMA JBOF 测试结果
总体来看，在模型、上下文长度及其他推理参数均保持一致的条件下，本地 SSD 与远端 RDMA JBOF 在不同缓存命中率下的各项性能指标未呈现明显差异。两种存储配置的 Input Tokens/s、Output Tokens/s、TTFT 及单请求输出吞吐量整体保持在相近水平，表明通过 RDMA 访问远端 JBOF 并未对不同缓存命中率下的端到端推理性能造成明显额外开销。
5. 总结与展望
本文验证了基于 RDMA 网络的远端存储在 AI KV Cache Offload 场景中的可行性。测试结果表明，与本地高性能 SSD 相比，远端存储所引入的性能开销较小，整体端到端推理性能基本处于同一水平。这说明，通过高带宽、低开销的 RDMA 数据路径，可以在突破单机存储边界的同时，避免对 TTFT 和系统吞吐能力造成明显影响。
与容量固定的本地 SSD 相比，远端存储池能够提供更大的可扩展容量，从而保存更多 KV Cache 内容。更充足的缓存空间可以减少因容量不足导致的频繁淘汰和重复计算，提高历史上下文与共享前缀的复用效率，并使 AI 推理时延和吞吐表现更加稳定。
作为面向边缘侧和 SOHO AI 场景的存储扩展方案，该架构在保持 DGX Spark 紧凑部署形态与本地推理能力的同时，为 KV Cache 提供了独立扩展和集中管理的容量基础。未来，随着长上下文、多轮会话、RAG 和多 Agent 协作工作负载持续增长，共享远端存储还可进一步支持跨节点的 Prefix Cache、Session Cache 以及 Agent Memory 复用，为小型团队和边缘部署构建更具扩展性的 AI 推理基础设施提供新的实现路径。
Reference