Tensormesh запускает платформу для снижения затрат на инференс LLM за счёт повторного использования KV-кэша

Каждый раз, когда ИИ-ассистент получает объёмный документ, ему необходимо обработать его, прежде чем он сможет начать отвечать. Если те же документы, инструкции или история диалога появляются снова, значительную часть обработки, возможно, приходится выполнять повторно. В масштабах предприятия такие повторы могут расходовать дорогостоящие ресурсы GPU, не добавляя полезной работы.

Tensormesh намерена решить эту проблему с помощью Tensormesh Platform, о запуске которой компания объявила 14 октября 2026 года. Компания, чья команда создала проект с открытым исходным кодом LMCache, предлагает организациям, обслуживающим большие языковые модели на собственной инфраструктуре, уровень управления кешированием пар ключ-значение, или KV-кешированием.

Платформа управляет состоянием инференса, пригодным для повторного использования, в памяти GPU, оперативной памяти и хранилищах. Её цель проста: сократить объём обработки промптов, которую парку GPU приходится выполнять повторно, и предоставить операторам средства контроля за хранением, совместным использованием и мониторингом кешированного состояния.

Почему важен KV-кеш

Инференс LLM состоит из двух важных этапов. На этапе предварительного заполнения (prefill) модель обрабатывает входной промпт. На этапе декодирования (decode) она генерирует ответ токен за токеном. В KV-кеше хранится промежуточное состояние, связанное с механизмом внимания: благодаря ему модель может обращаться к уже обработанным токенам, не пересчитывая всё с нуля.

Повторное использование этого состояния в разных запросах позволяет сократить объём работы на этапе предварительного заполнения, если контекст входных данных повторяется. Например, ассистент службы поддержки может обращаться к одному и тому же руководству по продукту, отвечая на сотни разных вопросов. Агент может снова и снова добавлять одни и те же инструкции или инструменты к меняющимся задачам.

Это не то же самое, что кеширование готового ответа. Система может повторно использовать вычисления, связанные с общим контекстом, и при этом генерировать новый ответ на новый вопрос.

В документации vLLM по автоматическому кешированию префиксов описаны преимущества этого подхода при повторных запросах к документам и многоэтапных диалогах. В ней также обозначено важное ограничение: кеширование префиксов ускоряет обработку промпта, но не генерацию новых выходных токенов. В рабочих нагрузках, где преобладают длинные ответы или почти всегда используются уникальные входные данные, эффект может быть меньше.

Для корпоративных заказчиков важен вопрос о том, какая доля их реальной рабочей нагрузки содержит контекст, пригодный для повторного использования, и можно ли извлечь этот контекст быстрее и дешевле, чем вычислять его заново.

От кеша к управляемой инфраструктуре

В описании выпуска Tensormesh выделяет пять приоритетных направлений эксплуатации: безопасность, наблюдаемость, отказоустойчивость, управление политиками и мультитенантность. Они охватывают практические задачи по защите кешированных данных, отслеживанию производительности, восстановлению после сбоев, контролю сроков хранения и вытеснения данных, а также разделению команд или клиентов в общей инфраструктуре.

Компания также описывает API контроллера для закрепления, поиска, перемещения, сжатия и очистки записей кеша. Это делает управление жизненным циклом кеша отдельной эксплуатационной задачей, а не оставляет его целиком на усмотрение отдельных процессов инференса.

Проект LMCache, лежащий в основе платформы, отделяет управление кешем от обслуживающего движка и поддерживает выгрузку и извлечение данных из нескольких уровней хранения. В документации описано повторное использование данных между запросами, сеансами и экземплярами движка, а также возможность подключать различные серверные компоненты для хранения и передачи данных.

Корпоративная платформа развивает эту основу. Согласно её руководству по установке, оператор Kubernetes управляет компонентами кеширующего движка: серверы кеша размещаются на узлах GPU, а координатор обеспечивает координацию на уровне всего парка. Для развёртывания используется Helm, а для эксплуатации предусмотрены веб-интерфейс и инструменты командной строки.

Такая архитектура важна, поскольку память GPU — ограниченный ресурс. Хранение в ней каждого промпта, который потенциально можно использовать повторно, конкурировало бы с другими потребностями инференса. Перемещение состояния, которое не требуется немедленно, в оперативную память хоста или хранилище позволяет увеличить объём сохраняемых данных, хотя их извлечение сопряжено с дополнительными затратами на пропускную способность и задержками.

Не только идентичные префиксы промптов

Кеширование префиксов хорошо работает, когда два промпта начинаются с одних и тех же токенов. С генерацией с дополнением на основе поиска (RAG) всё сложнее: приложение извлекает релевантные документы, но они могут располагаться в разном порядке или следовать за разным текстом.

Рассмотрим два гипотетических запроса, использующих одни и те же документы. В одном документ A идёт перед документом B, а в другом — документ B перед документом A. Оба запроса содержат данные, пригодные для повторного использования, но их общий префикс может быть коротким.

Tensormesh использует CacheBlend, чтобы расширить повторное использование данных за пределы начала промпта. В документации LMCache объясняется, что система выборочно пересчитывает часть токенов, одновременно используя повторно кешированные фрагменты. Пересчёт необходим, поскольку окружающий контекст фрагмента может влиять на внутреннее состояние модели.

В исследовательской статье CacheBlend, представленной на EuroSys 2025, сообщается, что в исследованных сценариях время до первого токена было в 2,2–3,3 раза меньше, а пропускная способность — в 2,8–5 раз выше по сравнению с полным пересчётом KV-кэша. Авторы провели оценку на трёх моделях с открытым исходным кодом и четырёх наборах данных для тестирования.

Это результаты исследований, полученные в конкретных условиях, а не гарантия экономии при любом развертывании Tensormesh. Тем не менее они показывают, почему повторное использование данных за пределами общего префикса представляет технический интерес: оно позволяет избежать части вычислений, которые обычное сопоставление префиксов не учитывает.

Повторное использование данных между узлами и важность поддержки конкретных версий

В анонсе запуска говорится о прямой передаче данных KV между узлами, благодаря которой один узел может получать кэшированное состояние с другого. В материалах компании также описано разделение этапов предварительной обработки и генерации. При таком разделении обработка запроса отделяется от генерации ответа, и эти этапы могут выполняться на разных рабочих узлах.

Это взаимодополняющие способы организации инференса. Совместное использование совместимого состояния позволяет избежать повторных вычислений на другом узле, а разделение этапов дает командам, отвечающим за инфраструктуру, возможность распределять ресурсы с учетом потребностей каждого этапа обработки.

Однако в открытых материалах нет полного согласия относительно статуса выпуска. Во вводной информации о запуске описаны совместное использование данных между узлами и разделение этапов, тогда как в матрице совместимости с указанием версий от 17 сентября передача данных между узлами и разделение этапов обозначены как планы на будущее. В документации по функциям также есть страницы с предварительными версиями.

В той же матрице различаются функции, проверенные в ходе тестирования Tensormesh, и функции, поддерживаемые в вышестоящих проектах, но требующие дополнительных испытаний перед использованием в промышленной среде. В качестве проверенных движков обслуживания указаны vLLM и NVIDIA Dynamo, а SGLang и TensorRT-LLM включены в планы на будущее.

Таким образом, широкие заявления о совместимости описывают направление развития, а не подтверждают, что проверено каждое сочетание моделей и инфраструктуры. Командам следует уточнить конкретную версию, движок обслуживания, модель и режим кэширования, которые они собираются использовать.

Во вводной информации о запуске конкретно описана работа vLLM в Kubernetes с графическими процессорами NVIDIA или поддерживаемыми графическими процессорами AMD Instinct через ROCm, а также с хранилищем на основе файловой системы. Кэширование не только префиксов для плотных моделей и поддержка SGLang представлены как функции, появление которых ожидается в будущем. Там также уточняется, что кэш работает вместе с моделями, размещенными на собственной инфраструктуре; это не дополнение, которое можно подключить к произвольному API размещенной модели.

В каких случаях это может быть экономически выгодно

Наиболее перспективны приложения, которые многократно обрабатывают значительный объем общего контекста: внутренние помощники для работы со знаниями, сервисы анализа документов и агенты, вновь обращающиеся к неизменному набору инструкций или справочных материалов.

Для полезной оценки следует сравнить работу с пустым и заполненным кэшем на репрезентативном потоке запросов. Операторам стоит измерять время до первого токена, пропускную способность, время извлечения данных из кэша, загрузку графических процессоров, а также затраты памяти, хранилища и сети на сохранение состояния.

Одного показателя частоты попаданий в кэш недостаточно. Высокая частота попаданий полезна лишь в том случае, если повторное использование уже выполненных вычислений дает чистый выигрыш с учетом затрат на передачу данных и управление. Точно так же ускорение появления первого токена не обязательно означает пропорциональное сокращение времени подготовки всего ответа.

Качество ответов следует проверять отдельно, особенно если кэшированные фрагменты объединяются в изменившемся контексте. Выборочное повторное вычисление в CacheBlend призвано решить эту проблему, однако при тестировании в производственной среде необходимо учитывать собственные документы организации, форматы запросов и конфигурации моделей.

По мере того как кэш выходит за пределы одного процесса, все важнее становятся срок хранения данных и изоляция арендаторов. К важным эксплуатационным вопросам относятся право повторно использовать запись, срок ее доступности, а также влияние изменений политики или запросов на удаление на сохраненное состояние. Объявленные Tensormesh функции управления призваны сделать эти решения контролируемыми.

Практичная ставка на сокращение повторных вычислений

Согласно анонсу компании, платформа Tensormesh доступна с момента запуска. Ее значение в том, что состояние инференса рассматривается как ресурс, которым можно управлять в масштабах всего парка серверов, сохраняя вычисления для повторного использования и после завершения отдельного запроса.

Для компаний, использующих собственную инфраструктуру LLM, это конкретный способ повысить эффективность: повторно использовать больше уже выполненной работы по обработке запросов. Результат будет зависеть от частоты повторения запросов, совместимости кэша и стоимости передачи данных, однако все это можно измерить и проверить на собственном потоке запросов.