戴尔科技如何不让存力拖算力的后腿

在智能技术加速发展的早期，行业经常讨论一个问题：如何不让存力拖算力的后腿？

当时，大模型应用主要集中在训练环节。海量数据需要持续送入


GPU


，存储吞吐一旦跟不上，昂贵的计算资源就可能因为等待数据而陷入闲置。

因此，早期智能基础设施对存力的要求十分明确：数据要供得上，GPU要跑得满。

但随着智能技术从集中式训练走向规模化推理，问题正在发生变化——智能应用不仅要“算得快”，还要记住更长的对话、理解更多文档、维持持续运行的任务状态，并同时服务大量用户与智能体。

这意味着，GPU面对的不再只是“有没有数据可算”，而是另一个越来越突出的挑战：需要保留的上下文，正在变得越来越多。

GPU没有变慢

“工作记忆”却越来越重

一次简单的智能问答，通常不会给基础设施造成太大压力。但在企业实际应用中，智能系统正在变得越来越“有记忆”。

例如，一名智能助手可能需要阅读数百页资料，记住此前多轮交流，持续调用不同工具，并在较长时间内维持任务状态；多个智能体之间，还可能共享信息、相互协作。

为了避免模型每生成一个新Token都重新计算此前已经处理过的全部内容，推理系统会将相关中间计算结果保存在KV Cache中。

简单而言，可以将KV Cache理解为模型推理时的“工作记忆”。 有了这部分记忆，模型就不必每次都从头阅读完整的历史上下文，可以直接调用已经完成的计算结果，更快地继续生成内容。

问题在于，随着模型规模扩大、上下文变长，以及并发会话数量增加，KV Cache占用的空间也会快速上升。

在单个会话中，它可能占用数GB内存。当生产环境同时服务大量用户时，累积规模甚至可能达到TB级，远远超出单个GPU显存乃至服务器内存能够轻松承载的范围。

而GPU上的高带宽内存，本应优先服务于高密度计算。如果大量空间被KV Cache占用，系统便可能面临两种选择：

清理已有缓存，在后续请求中重新计算上下文

增加更多GPU，为不断增长的“工作记忆”寻找空间

前一种方式会延长响应时间，让GPU反复完成已经做过的工作；后一种方式则会增加采购成本、能耗和系统复杂度。换句话说，GPU仍然很强，但其性能正在被越来越重的上下文“记忆负担”所牵制。

与其继续堆GPU

不如先把“记忆”放对地方

要解决这一问题，思路不一定是继续增加计算资源。另一种方式是，将暂时不需要驻留在GPU显存中的KV Cache，卸载到高速、可扩展的共享存储中，当后续推理需要调用这些上下文时，再快速将其取回。

整个过程可以概括为：

上下文完成一次计算，生成KV Cache；

KV Cache进入共享存储；

后续请求直接调用，不再重复完成完整的预填计算。

这样一来，存储不再只是保存原始数据和训练数据集，而是成为GPU显存之外的一层上下文承载空间。

在此背景下，戴尔科技验证了一套高度模块化且可扩展的智能推理软件栈。该架构无缝整合了vLLM推理引擎、LM Cache核心组件、NVIDIA Dynamo框架以及高效的戴尔专用


连接器


，可以将KV Cache卸载到戴尔Powe


rS


cale、ObjectScale和Lightning File System (Lightning FS)中。

通过文件或对象存储以及R


DMA


高速数据传输，KV Cache能够在计算节点与共享存储之间快速移动，使多个推理节点可以调用和复用已经生成的上下文，并将缓存容量扩展到GPU和


CPU


内存之外。

这一架构所改变的，不只是KV Cache的存放位置。它还意味着，企业不必为了增加上下文容量而一味增加GPU，可以根据实际负载，分别扩展计算能力和上下文承载能力。

让GPU负责计算，让存储负责承载和流动上下文，各自发挥更合适的作用。

少一次重复计算

快的不只是“第一句话”

为了验证这一架构的实际效果，戴尔科技使用Llama 3.3 70B模型、4块NVIDIA H100 GPU，对不同上下文长度下的首Token响应时间进行了测试。

在131K Token的长上下文测试中，标准vLLM需要在GPU上重新完成KV Cache计算，首Token响应时间约为17.34秒。

采用戴尔智能存储引擎进行KV Cache卸载和复用后，PowerScale、ObjectScale和Lightning均实现了约1秒或更低的首Token响应时间，最高提升约19倍。

在相同模型与131K Token上下文条件下，当标准vLLM配置从4块H100扩展到8块H100后，首Token响应时间由约17.34秒降至12.3秒；而采用KV Cache存储卸载的架构，依然能够维持约1秒的响应表现。

进一步测试显示，这一性能提升并非只出现在超大规模模型上。在相同测试配置与方法下，戴尔科技将模型替换为参数规模更小的Qwen3-32B。

可以看到，在131K Token完整上下文条件下，标准vLLM的首Token响应时间为11.82秒，而采用PowerScale或ObjectScale进行KV Cache卸载后，首Token响应时间约为0.8秒，提升约14倍。

这一结果进一步表明，即使模型参数规模有所降低，长上下文带来的重复预填计算仍可能成为推理效率的重要制约。通过戴尔科技基于vLLM、LMC


ac


he与NIXL构建的KV Cache卸载架构，系统能够在不同模型规模下持续减少重复计算，并获得稳定、可扩展的首Token响应性能。

对于企业而言，当KV Cache能够从有限且昂贵的GPU显存扩展至共享存储，计算资源便可以更多地用于真正的模型推理，而不必反复处理已经计算过的上下文。

在相同GPU资源下，系统有机会承载更长的上下文和更多并发会话，面对不断增长的智能体任务，也不必简单地将“继续增加GPU”作为唯一扩展路径。

更重要的是，计算能力与上下文容量开始能够根据实际需求分别扩展。

当业务需要提升推理吞吐时，可以扩展计算资源；当长文档、多轮会话和持续运行的智能体产生更多上下文时，则可以扩展存储容量和数据访问能力。计算、网络与存储不再被固定比例绑定，而是形成更灵活的协同架构。

写在最后

从早期的“防止GPU闲置”，到如今通过卸载KV Cache来全面激活智能基础设施的上下文工作记忆，存力在智能基础设施中的作用正在进一步延伸。

真正决定智能应用能否规模化落地的，不只是拥有多少GPU，更在于数据与上下文能否被高效承载、快速流动和持续复用，让每一份算力都更充分地转化为智能生产力。

当上下文成为新的关键资源，存储还将如何继续演进？PowerScale、ObjectScale与Lightning等创新，又将为新一代智能负载打开怎样的空间？

答案，即将在戴尔科技峰会上海站进一步揭晓。

更多前沿技术进展与落地实践，敬请关注！