跳到主要内容
检索

# KV缓存

36 篇关联报道

订阅更新
  1. arXiv

    VerKV把KV缓存压到GPU只留3.13%:先估注意力误差,再按需从CPU取回

    长上下文推理时KV缓存随序列长度线性增长,常超出GPU显存。VerKV把完整缓存留在CPU内存,GPU上只保留按重要性分数做泊松抽样得到的少量token,每个解码步先用证书估计注意力误差,超出容差才从CPU取回额外条目。在Qwen3-4B、Qwen3.5-9B和Ministral-3-8B三个模型、RULER与LOFT两个基准的32K和128K上下文上,GPU常驻缓存为3.13%时三者分别保留94.6%、84.6%和79.6%的全量质量,而Fast KVzip和KVzip在同样3.13%下只剩1.9%至11.9%。

  2. researchsquare.com

    编码智能体压缩上下文不必改写历史:ObsDrop只释放过期KV,16个并发智能体下吞吐最高5.37倍

    编码智能体每轮只往历史末尾追加内容,不压缩时前缀缓存复用率可达98%至99%,但文本级上下文压缩一旦改写早先的token,后面的KV就要全部重算。ObsDrop把压缩从提示词移到KV缓存:逻辑token前缀保持不变,只释放过期工具观测占用的KV并从注意力中排除,已在SGLang与Sparse-vLLM中实现。在16个并发智能体下,相对不压缩,FlashInfer后端吞吐提升2.45至2.85倍,Triton后端峰值5.37倍,任务质量接近不压缩。

  3. PyTorch

    Meta 的 816B 稀疏模型搬上单台四芯片 TPU:整步合成一个内核,单请求每 token 快 1.94 倍

    Meta 的开源混合专家模型 Muse Spark Open 总参数 816B、每 token 约激活 42B,此前在 TPU v7 上服务时,一次验证步的耗时是单纯从 HBM 流式读取权重所需时间的 2.9 倍。SGLang-TorchTPU 把一次解码或验证步的全部 62 层写成一个 Pallas 程序,让权重、KV 与跨设备传输都排在计算之前发出。单请求下每输出 token 从 3.78 ms 降到 1.95 ms,两个并发请求时为 1.85 倍,并发继续增大时收益收窄。

  4. NVIDIA Technical Blog

    英伟达把智能体推理的内存账算到每个字节:Vera Rubin NVL72 每兆瓦吞吐最高达 GB300 NVL72 的 30 倍

    英伟达把 AI 工厂的内存问题从“GPU 有多少容量”改成“每个字节产出多少有用 token”,用 NVFP4 压缩权重与 KV 缓存、宽专家并行分散 MoE 权重、Dynamo 复用 KV 缓存、Vera CPU 暂存工具调用期间的上下文、CMX 在机架级共享上下文存储。在回放真实编码智能体会话的 SemiAnalysis AgentX 上,每 GPU 同为 288 GB 的 Vera Rubin NVL72 在每用户 160 token/s 下,每兆瓦吞吐最高达到 GB300 NVL72 的 30 倍。

  5. arXiv

    智能体推理服务不再重启换相:Evolving Infra 让节点原地切换,切换耗时从754秒降到6.2秒

    面向编码、数学与计算机操作类智能体负载,Evolving Infra 把预填充与解码的算力分配同 KV 缓存管理解耦:节点不再重启即可在两种阶段间切换,KV 留在所有节点可读的共享池中。在最多 256 块 GB300 GPU 上,其平均端到端时延与 P95 首字时延相对 NVIDIA Dynamo 最多降低 4.1 倍和 14 倍,平均一次阶段切换耗时 6.2 秒,而 Dynamo 重启需 754 秒。

  6. arXiv

    JSSA把token级稀疏解码做成免gather:128K上下文下吞吐最高达到全量KV注意力

    长上下文解码的瓶颈在反复读取不断增长的KV缓存,稀疏注意力只取其中一部分位置,但token级选择一直难以同时保住精度和延迟。JSSA用共享的查询—键低维子空间给候选token打分,并配一个免gather的索引注意力内核,让每个KV头保留各自选中的token集合。在GQA、混合滑窗/全局注意力和MLA模型上,它离全量KV精度最近;在B200上128K上下文时解码吞吐最高达到全量KV注意力的水平。

  7. LMSYS Org

    SGLang把KV缓存压到4位:长上下文解码吞吐提升26%到30%,智能体高并发下FP8先撑不住

    SGLang 为分页 KV 缓存加入 NVFP4 存储,把每个 token 的键值数据从 FP8 再压到约 56% 的字节量。在 Qwen3.8-27B 上,32K、160K、1M 三种输入长度下保持相同解码并发,峰值批解码吞吐提升约 26% 到 30%;智能体负载并发超过 12 后,FP8 吞吐骤降而 NVFP4 继续上升。精度上两个模型的差距随任务不同,最大为 SWE-bench Verified 上的 1.60 个百分点。

  8. LMSYS Org

    XM-Sparse把稀疏注意力的KV缓存搬出HBM:16K上下文同批下每token时间降49.25%

    Netpreme把X-Mem™内存层接入SGLang HiSparse,让解码GPU从高带宽外部内存取回未命中的KV条目,而不是走PCIe访问主机DRAM。在16K上下文、每GPU批192、20% top-k未命中率下,平均每输出token时间从167.48 ms降到84.99 ms,降幅49.25%;40%未命中率下降幅为63.58%。在20%未命中率下,16K至1M上下文的峰值解码吞吐是主机DRAM的2.09–3.04倍。

  9. KV选择不再等目标层查询:EarlySelectKV用代理查询提前算索引,长输出吞吐最高提升12.4%

    查询条件稀疏KV选择每次解码都要先拿到目标层查询,才能给候选打分并生成索引,这段路由因此卡在注意力之前。EarlySelectKV把路由查询换成由更早隐藏状态构造的代理查询,提前算好下一层要访问的KV索引,最终注意力仍用真实查询。在RocketKV上,LongBench相差+0.018分、RULER约−0.01分、代表性NIAH/Passkey设置+0.25个百分点;TensorRT-LLM部署中路由卸载到CPU后,端到端输出吞吐最高提升12.4%,GPU常驻内存减少KV与K-summary池的11.1%。

  10. Preferred Networks

    PLaMo 3.1 Prime 把推理与非推理装进同一模型,部署算力不用再翻倍

    PFN 发布基座模型 PLaMo 3.1 Prime,把推理与非推理两种模式并入同一个模型,同时新增 Web 检索与 Deep Research 功能。此前 PLaMo 3.0 Prime 分别训练、分别部署两种模式;按发布方给出的当时配置,同时提供两种模式所需计算资源是只部署单一模式模型(PLaMo 2.2 Prime 或 PLaMo 3.0 Prime Beta)的两倍。新模型分两阶段指令微调,第二阶段混入删掉推理过程的样本,让同一模型按请求切换;相对 PLaMo 3.0 Prime,推理模式下 Web 检索问答平均提高 2.4 分、检索报告平均提高 11.1 分。