Tensormesh 推出平台，借助 KV 缓存复用降低大语言模型推理成本

每当 AI 助手收到一份长文档，都必须先处理其中的内容，才能开始作答。如果相同的文档、指令或对话历史再次出现，其中许多内容可能需要重复处理。在企业级应用规模下，这种重复处理会消耗昂贵的 GPU 算力，却没有带来有用的工作成果。

Tensormesh正通过 Tensormesh Platform 应对这一问题。该平台于 2026 年 10 月 14 日发布。Tensormesh 团队曾创建开源 LMCache 项目，如今正为在自有基础设施上运行大语言模型的组织提供企业级管理层，用于管理键值缓存（KV 缓存）。

该平台可管理 GPU 内存、CPU 内存和存储中的可复用推理状态。它的预期作用很直接：减少 GPU 集群需要重复处理的提示词内容，同时让运营人员能够控制缓存状态的保留、共享和监控方式。

KV 缓存为何重要

大语言模型推理分为两个重要阶段。在预填充阶段，模型处理输入提示词；在解码阶段，模型逐个生成响应词元。KV 缓存保存与注意力机制相关的中间状态，使模型能够回看已处理的词元，而不必从头重新计算所有内容。

如果不同请求中的输入上下文重复，复用这些状态就能减少预填充阶段的工作量。例如，客服助手可能会针对数百个不同问题查阅同一本产品手册。智能体也可能在处理不断变化的任务时，反复附上相同的指令或工具。

这与缓存已经生成的答案不同。系统可以复用与共享上下文相关的计算，同时仍针对新问题生成新的响应。

vLLM 自动前缀缓存文档介绍了这项功能在重复查询文档和多轮对话中的优势。文档也指出了一个重要限制：前缀缓存能加快提示词处理，却不能加快新输出词元的生成。若工作负载主要由长篇回答构成，或输入大多各不相同，所获得的收益可能较小。

对企业采购方而言，关键在于弄清实际工作负载中有多少包含可复用的上下文，以及能否以更快、更低成本的方式重新获取这些上下文，而不是重新计算。

将缓存打造为托管基础设施

Tensormesh 在发布公告中列出了五项运营重点：安全性、可观测性、韧性、策略管理和多租户支持。这些重点对应着实际运营工作，包括保护缓存数据、跟踪性能、从故障中恢复、控制保留和淘汰策略，以及在共享基础设施上隔离不同团队或客户。

该公司还介绍了控制器 API，可用于固定、定位、移动、压缩和清除缓存条目。这意味着缓存生命周期管理被明确纳入运营工作，而不再完全由各个推理进程自行处理。

底层的LMCache 项目将缓存管理与服务引擎分离，并支持在多个存储层之间卸载和检索缓存。其文档介绍了跨请求、会话和引擎实例复用缓存的方式，并支持可插拔的存储和传输后端。

企业平台以此为基础构建。根据其安装指南，Kubernetes 运算符负责管理缓存引擎组件；缓存服务器部署在 GPU 节点上，另设协调器负责整个集群的协调。Helm 用于部署，网页界面和命令行工具则支持日常运维。

这种架构之所以重要，是因为 GPU 内存资源有限。将所有可能复用的提示词都保留在 GPU 内存中，会与其他推理需求争夺资源。把暂时不那么有用的状态移至主机内存或存储，可以增加可保留的数据量，但检索也会带来额外的带宽和延迟成本。

超越完全相同的提示词前缀

当两个提示词以相同词元开头时，前缀缓存效果良好。检索增强生成（RAG）则更棘手：应用会检索相关文档，但这些文档的顺序可能不同，前面出现的文本也可能不同。

设想两个使用相同文档的请求：一个先包含文档 A，再包含文档 B；另一个则先包含 B，再包含 A。两者都有可复用的内容，但开头相同的部分可能很短。

Tensormesh 使用 CacheBlend，将复用范围扩展到提示词开头之外。LMCache 文档说明，该方法会在复用缓存块的同时，有选择地重新计算一部分词元。之所以需要重新计算，是因为块周围的上下文会影响模型的内部状态。

在 EuroSys 2025 上发表的CacheBlend 研究论文报告称，在其评估的工作负载中，与完整重新计算 KV 缓存相比，该方法将首词元生成时间缩短至原来的 1/2.2–1/3.3，吞吐量提高至原来的 2.8–5 倍。作者评估了三种开源模型和四个基准数据集。

这些是在特定条件下得出的研究结果，并不保证每次部署 Tensormesh 都能节省成本。不过，这些结果确实说明了为何共享前缀之外的复用在技术上颇具价值：它能够挽回传统前缀匹配会遗漏的有效计算。

跨节点复用与版本特定支持的重要性

发布公告介绍了点对点 KV 传输功能，使一个节点能够从另一个节点获取缓存状态；公司的产品资料则介绍了预填充/解码分离。分离处理将提示词处理与输出生成拆开，让这两个阶段能够在不同的工作节点上运行。

这些都是组织推理流程的互补方式。共享兼容状态可以避免在另一节点上重复计算；分离不同阶段则能让基础设施团队根据各阶段的处理需求，以不同方式分配资源。

不过，公开资料对功能发布状态的描述并不完全一致。发布介绍描述了跨节点共享和分离处理，而带版本信息的兼容性矩阵（日期为 9 月 17 日）则将点对点传输和分离处理列入路线图。功能文档中也包含预览页面。

同一份矩阵还区分了在 Tensormesh 测试中已验证的功能，以及上游已支持、但在投入生产前仍需进一步测试的功能。矩阵将 vLLM 和 NVIDIA Dynamo 列为已验证的服务引擎，而 SGLang 和 TensorRT-LLM 则列入路线图。

因此，发布公告中宽泛的兼容性表述代表的是设计方向，并不能证明每一种模型与基础设施组合都已通过验证。团队应确认自己计划部署的具体版本、服务引擎、模型和缓存模式。

发布介绍具体说明了通过 ROCm 在 Kubernetes 上使用 vLLM，并搭配 NVIDIA 或受支持的 AMD Instinct GPU，以及由文件系统提供支持的存储。介绍还称，针对稠密模型的非前缀缓存和对 SGLang 的支持即将推出。它还明确指出，该缓存与自托管模型搭配运行；它并非能够附加到任意托管模型 API 上的附加组件。

哪些场景可能具备经济效益

最适合的场景，是需要反复处理大量共享上下文的应用：内部知识助手、文档分析服务，以及会反复查阅稳定指令集或参考资料的智能体。

一种有效的评估方法，是使用具有代表性的流量，对比冷缓存和热缓存时的表现。运营人员应测量首 token 时间、吞吐量、缓存检索时间、GPU 利用率，以及保留状态所需的内存、存储和网络成本。

仅看缓存命中率并不足够。只有当节省下来的计算在扣除传输和管理开销后仍能带来净收益时，高命中率才有价值。同样，首 token 生成更快，也不一定意味着整个响应的完成时间会按相同比例缩短。

还应单独检查回答质量，尤其是在缓存块被组合到变化后的上下文中时。CacheBlend 通过选择性重新计算来解决这一问题，但生产环境测试仍应涵盖组织自己的文档、提示词格式和模型配置。

随着缓存超出单个进程的范围，保留期限和租户隔离也变得更加重要。需要考虑的运维问题包括：谁可以复用某个条目、该条目可以保留多久，以及策略变更或删除请求会如何影响已保存的状态。Tensormesh 宣布的管理功能旨在让这些决策变得可控。

减少重复工作的务实之选

据公司公告，Tensormesh Platform 已随此次发布推出。它的重要意义在于将推理状态视为一种可在整个计算集群中管理的资源，并将可复用的计算结果保留到当前请求结束之后。

对于运行自有 LLM 基础设施的企业而言，这提供了一种切实可行的效率提升手段：复用更多已经完成的提示词处理工作。最终效果取决于工作负载的重复程度、缓存兼容性和数据传输成本；不过，这些都是可以量化的工程问题，团队可以用自己的流量进行测试。