这是一个编码代理在RTX Pro 6000上逐步完成任务的过程。在第一轮中，它大约在0.12秒内完成回答。你可以看到速度逐渐变慢，对吧？第23、24轮。最后在第25轮时，在写出第一个字之前竟然花了19秒。这是因为每一轮它需要读取的内容越来越多。[音乐] 对于代理而言，缓存并不会带来线性的加速效果，其影响是倍增的。随着对话每一轮的推进变得越来越长，而你添加的每一个代理都在一块GPU上重新读取自己的历史记录。

在这段视频中，我将介绍KV缓存对代理的作用，以及LM Cache在其中扮演的角色。想想有多少网站存储着你的个人信息：GitHub、开发者工具，还有多年前注册的各种随机服务。数据经纪人收集这些细节并出售它们。你的个人信息不应该如此容易被找到。几十个国家隐私法赋予你要求数据经纪人删除个人信息的权利，但想要追踪数百个经纪人、提交请求并检查个人信息是否再次出现，那简直是难如登天。

这就是Incogn发挥作用的地方。它自动发送这些删除请求，并代表我与经纪人跟进。我的仪表板识别出包含我详细信息的231个数据库，其中大多数已经被清除。如果我在另一个网站上发现我的信息，我可以通过自定义删除提交链接，由隐私专家为我处理删除事宜。他们找到数据、请求移除并持续跟进。为了提供额外的保障，Deoid已验证了Incogn的数据删除流程。

虽然它不涵盖政府记录或随机的社交帖子，[音乐] 但它可以处理数据经纪人和符合条件的网站。如果你愿意尝试，还提供30天退款保证。通过Incogn夺回你的个人信息。访问incogn.com/exist并使用代码lexiscin享受年度计划60%的折扣。链接在下方。现在，回到视频内容。这里有一个名为LM Cache的项目。

它是针对VLLM的缓存层，而VLLM是一个运行大型语言模型的开源服务器。但VLLM本身已经内置了缓存功能，那么LM Cache究竟做了哪些VLLM做不到的事？两者与完全没有缓存的情况相比又如何呢？首先，让我们看看缓存究竟为你节省了什么。在模型写出第一个字之前，它会读取整个提示词并在阅读时做笔记。

为了简单起见，我们称之为“笔记”。技术上这被称为KV缓存（Key-Value Cache），你可能以前听过这个术语。K和V分别代表键值对。就像备考一样，如果你保留笔记，下次重读书籍时就不必通读全书，只需阅读老师教授的新内容即可。专业提示：[音乐] 顺便说一句，我很久没上大学了，我不知道现在的孩子们还是这样做的吗？

这是同样的30轮会话。这是无缓存的情况。看看每一轮需要进行多少提示词处理，内容越来越多、越来越多。到结束时它重读了115,00个令牌（tokens），整个会话超过200万个令牌。而有了缓存，这是VLLM的前缀缓存（prefix cache）。顺便说一句，使用缓存时，每一轮它读取的内容从未超过约10,00个令牌。阅读量大减了14倍，但这些笔记并非没有代价。

它们存储在紧邻模型的GPU显存中。模型本身已经占据了显卡的大部分空间，剩下的才是你用于存储笔记的预算。这通常就是为什么你不希望在一个拥有32GB显存的5090显卡上运行一个32GB的模型，因为嘿，我们需要为笔记留出空间。当显存填满时，最旧的笔记会被丢弃，下次重新运行它们时，你又回到了重读一切的状态。

那么，你把笔记存放在哪里呢？我比较了四种设置：第一种是无缓存，每次重读所有内容。我们已经见过那是什么样的情况了对吧？第二种是VLLM预构建的前缀缓存，它有帮助。只要提示词以相同的方式开头并保持在VLLM进程内的GPU显存中，它就会重用这些笔记。顺便说一句，在我测试的VLLM版本中这是默认开启的。

所以当我进行无缓存运行时，我实际上不得不将其关闭。第三种是VLLM自己的CPU卸载功能，它允许这些笔记溢出到常规RAM（系统内存）中，但仍然位于VLLM内部。第四种是我们的新朋友LM Cache。它将笔记保存在VLLM之外的单独服务器中，存储在RAM中，有时甚至存储在NVMe驱动器（SSD）上。

这一点很重要要知道，因为当VLLM进程死亡或你重启电脑时会发生什么？[音乐] 我最初在DGX Station GB300上运行Qwen 2.5 7B模型。这是一个相当大的模型尺寸。我喂给它一个32,00令牌的文档，提出问题然后又再次询问它。无缓存情况下大约需要1.35秒，而使用我提到的任意一种缓存方式都要好得多。

它们范围在112到122毫秒之间，抱歉是毫秒。是的，快得多。事实上快了约11或12倍。现在，1.35秒听起来并不多，但对于无缓存情况下的代理来说，它在每一轮都要支付这个代价。我们知道等待代理做事是什么感觉对吧？是的，我们被宠坏了。接下来我增加了难度：如果文档不能全部放入GPU显存中怎么办？

DGX Station只能容纳不到100万个令牌的笔记，所以我发送了48个文档。那是150万个令牌。我也为此制作了一张图表，显示了VLLM的GPU缓存（橙色柱状图）。在48个文档上命中率为0%，这很糟糕。它在16到48个文档之间就填满了，然后就把旧内容踢出去了。

当我回到某个文档时它已经不见了。所以最终结果与完全没有缓存一样慢。然后我让缓存溢出到常规RAM中。哦，该工作站拥有巨大的CPU内存空间（LPDDR5X），实际上它与HBM（高带宽内存）处于同一池中，就像统一内存一样。之前我们使用的是紧邻GPU的HBM。

无论如何我制作了一个关于DGX Station及其内存工作原理和分解的详细视频，如果你感兴趣可以在下方找到链接。VLLM自己的卸载功能耗时164毫秒。所以我们在那里获得了99.9%的命中率，而LM Cache为140毫秒，几乎相同。两者都解决了这个问题。好吧这很棒对吧？

然后我用16个客户端或约144个并发请求来测试它。无缓存情况下需要187秒，那是一段漫长的时间。VLLM的GPU前缀缓存为107秒；使用来自VLLM的CPU系统RAM卸载则为69秒。你们中的一些人可能会在下面评论说，那原本是一个3分钟的任务现在只需1分多钟即可完成。但LM Cache和VLLM的卸载功能几乎持平。

如果LM Cache没有更快，那它是做什么用的呢？所以我重启了VLLM。在重启后VLLM的前缀缓存……

重启耗时约1.35秒，CPU卸载时间相同。它们都丢失了所有数据，因为它们的笔记和缓存位于我刚刚终止的进程中。LM Cache瞬间响应，仅需141毫秒，命中率高达99.9%。此时差异显现：它的笔记存储在独立服务器上，该服务器一直运行着。当VLM重新连接时，它接续了之前的工作。我第一次尝试此操作时，新的VLM崩溃了，提示GPU内存不足。

此时，LM Cache仍占用着已终止进程留下的约89GB GPU显存，持续了2分钟。通常重启需要150秒，这次耗时27秒，其中136秒都在等待内存释放。对于该等待时间有一个设置项，我尝试设为6秒被拒绝，最小值为30秒。在30秒设置下，整个重启过程缩短至173秒。这比纯VLM慢20到30秒，但仍远优于之前的277秒。

接下来，我给LM Cache分配了40GB RAM加一个NVMe驱动器。仅使用RAM时耗时约1.4秒，全部未命中；使用磁盘缓存时为265毫秒。重启后仍为265毫秒，因为它直接从磁盘读取了缓存笔记，一切正常。首先是Cash [音乐] 混合模式：即使文档以不同顺序出现，也能复用其中的片段。

为何需要此功能？如果你考虑一个RAG应用或智能体，它针对大量不同问题提取相同的几份文件，只是每次顺序不同。前缀缓存仅在提示词完全相同时有效，但情况并非总是如此。当我打乱 [音乐] 文档顺序时，不到5%的内容来自缓存。但不幸的是，该模式尚不支持VLM，因此无法测试。

接着使用另一款模型DeepS V4 Flash。VLM显示其GPU缓存可容纳约140万token，于是我向其输入320份文档（约1000万token）以溢出缓存，但它从未耗尽。GPU内存命中率高达98%。此外，其每个token的笔记极小，约1700万token可放入GPU。VLM自身的估算误差超过10倍，导致溢出测试未能真正溢出。

但在重启测试中LM Cache仍胜出。VLM刚重启后，16份文档在LM Cache下耗时5.7秒，而仅用VLM缓存则需13.8秒左右。随后我尝试了另一款较新的模型Quen [音乐] 3.8 Flash Next。这是一个混合模型，结合了两类层结构，因此其笔记或KV Cache形状不同于普通模型。VLM自身的CPU卸载功能甚至无法在其上启动。

因此，当你观看此视频时，部分信息可能已过时或已修复。LM Cache仅在我为其重建新版本后才生效。运行后，重启后的16份文档轮次在LM Cache下耗时12.3秒，VLM为27.4秒。最后，是时候进行编码智能体测试了，这是我最关注的工作负载。我在DJX Spark上使用较旧但仍有效的OSS120B模型运行了脚本化会话。

这意味着真实文件和日志以完全相同的方式回放给每个设置。每场会话运行30轮 [音乐]，对话增长至近10万token。我按分钟计算回合数，即智能体收到的回复数量。在后期轮次中，8个智能体在无缓存情况下等待104秒（每回合近2分钟）。有缓存时仅需2.1秒，每分钟回合数提升5.6倍。

我想并排展示这一结果。这是在RTX Pro 6000上运行的。一边有缓存，另一边无缓存，同时在同一GPU上进行。看第4到6轮：有缓存侧已缓存高达27,000个token，但仍慢至3到4秒。按此缓存量本应只需1秒左右。怎么回事？原来VLM将它们批量处理了，导致快速请求等待慢速请求。

如果缓存请求与大型未缓存请求共享GPU，它将失去大部分优势。因此我改变了方法：单独记录每个设置（独占GPU），然后以真实时间回放它们 [音乐]。这是运行Quen 3.827B FB8的RTX Pro 6000。智能体会话增长至115,000个token。一个智能体在无缓存时每分钟完成5.2轮，VLM前缀缓存为12.9轮，LM Cache为12.8轮（提升约2.5倍）。

使用八个智能体时，无缓存每分钟仅约8轮，有缓存则近60轮。分摊到八个智能体：无缓存时每个每分钟约1轮，有缓存时每个约7轮。无缓存在扩展性上表现极差，因为GPU忙于读取数据。每回合它都需读取整个提示词；有缓存时仅读约7%。两种缓存均保持扩展性，在此案例中LM Cache接近VLM缓存性能。

随着智能体持续运行，后期轮次（此处为21至30轮）也体现了这一点。无缓存时，随着智能体从1个增至8个，权重时间从约14秒增至28秒再到42秒。而开启任一缓存后，时间仅为0.5秒至约2秒。回到视频开头的智能体会话测试，这次包含两种缓存和重启功能。这是有趣的部分：在第15轮时，两种缓存均在约半秒内响应。

然后我重启了VLM。在第16轮，VLM缓存耗时9.5秒，未复用任何内容需重建。而LM Cache仅需1.1秒。在整个30轮会话中（不含重启本身），它复用了近6万token。无缓存时耗时约350秒，VLM缓存为65秒，LM Cache为55秒。这几乎是6分钟对比约1分钟。

公平地说，如果计入重启时间，LM Cache实际上比VLM缓存落后约20秒，因为LM Cache的重启耗时88秒，而VLM为58秒。缓存并未让智能体更聪明，只是防止它重复阅读相同内容。LM Cache保留了这些笔记（即KV缓存）。我不太喜欢说“Cash [音乐]”，所以用“Notes”称呼它比较好。

就像有些人不喜欢说或听到Moist一样，我也不想多说Cash这个词。好吧，这次我们称之为粉色和紫色缓存。我在两台不同机器上使用两种模型运行了智能体测试，结果相同：在Spark上每分钟回合数提升5.6倍，在RTX Pro 6000上提升7.5倍。运行的智能体越多，收益越大；投入越多，节省越多。

别管那些了。如果你在自己的硬件上运行编码代理，请使用 KV 缓存。如果你使用的是视觉语言模型（VLM），前缀缓存默认就是开启的，所以保持开启即可。如果所有内容都能放入 GPU 显存中，那就足够了；但如果放不下却能在 RAM（内存）中容纳，那么 VLM 自带的 CPU 卸载功能就能跟上 LM Cache 的速度。

不过，你的服务器可能会重启，而你并不希望每个代理启动时都面临冷启动问题；或者当数据规模甚至超出了 RAM 的容量，那就是时候开启 LM Cache（语言模型缓存）了，这时它才真正体现出价值。但你要为此承担更多的复杂组件、更慢的启动速度，以及因各种新特性而在较新的模型上遇到的配置麻烦。

现在，如果你想从头到尾观看那个 DJX 站点的实际演示，请看这里的相关视频。还有我使用四张 RTX Pro 6000 显卡搭建的服务器配置，也请看这个视频。感谢观看，我们下次再见。