Tensormesh запускає платформу для зниження витрат на інференс LLM завдяки повторному використанню KV-кешу

Щоразу, коли ШІ-асистент отримує великий документ, він має опрацювати його, перш ніж почати відповідати. Якщо ті самі документи, інструкції або історія розмови з’являються знову, значну частину цієї роботи, можливо, доводиться повторювати. У масштабах підприємства такі повтори можуть споживати значні ресурси GPU, не додаючи корисної роботи.

Tensormesh прагне розв’язати цю проблему за допомогою Tensormesh Platform, про запуск якої оголосили 14 жовтня 2026 року. Компанія, команда якої створила проєкт LMCache з відкритим вихідним кодом, пропонує рівень управління кешуванням пар «ключ—значення», або KV-кешуванням, для організацій, які обслуговують великі мовні моделі на власній інфраструктурі.

Платформа керує станом інференсу, який можна повторно використовувати, у пам’яті GPU, пам’яті CPU та сховищах. Її мета проста: зменшити обсяг обробки промптів, яку парку GPU доводиться повторювати, і водночас надати операторам засоби керування тим, як цей стан у кеші зберігається, спільно використовується та відстежується.

Чому KV-кеш має значення

Інференс LLM складається з двох важливих етапів. Під час попереднього опрацювання модель обробляє вхідний промпт. Під час декодування вона генерує відповідь токен за токеном. У 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-даних між вузлами, завдяки якому один вузол може отримати кешований стан з іншого, а в матеріалах компанії йдеться про розділення етапів prefill і decode. Таке розділення відокремлює обробку запиту від генерації відповіді, тож ці етапи можуть виконуватися на різних робочих вузлах.

Це взаємодоповнювальні способи організації інференсу. Спільне використання сумісного стану допомагає уникнути повторних обчислень на іншому вузлі, а розділення етапів дає змогу командам з інфраструктури по-різному розподіляти ресурси відповідно до потреб обробки.

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

У тій самій матриці розрізняють функції, перевірені під час тестування Tensormesh, і ті, що підтримуються в основних проєктах, але потребують додаткового тестування перед використанням у виробничому середовищі. Як перевірені рушії для обслуговування моделей указано vLLM і NVIDIA Dynamo, а SGLang і TensorRT-LLM — у планах розвитку.

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

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

Де це може бути економічно вигідно

Найперспективніші сценарії — це застосунки, які регулярно обробляють значний спільний контекст: внутрішні помічники для роботи зі знаннями, сервіси аналізу документів і агенти, які знову й знову звертаються до сталого набору інструкцій або довідкових матеріалів.

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

Самої частки влучань у кеш недостатньо. Висока частка влучань корисна лише тоді, коли заощаджені обчислення дають чистий виграш з урахуванням витрат на передавання даних і керування. Так само швидша поява першого токена не обов’язково означає, що вся відповідь генерується пропорційно швидше.

Якість відповідей потрібно перевіряти окремо, особливо коли кешовані фрагменти поєднуються в зміненому контексті. Вибіркове повторне обчислення в CacheBlend покликане розв’язати цю проблему, однак під час тестування у виробничому середовищі слід перевірити власні документи організації, формати запитів і конфігурації моделей.

У міру того як кеш виходить за межі одного процесу, дедалі важливішими стають строк зберігання даних та ізоляція клієнтів. Серед важливих операційних питань — хто може повторно використовувати запис, як довго він залишається доступним і як зміни політик або запити на видалення впливають на збережений стан. Анонсовані Tensormesh функції керування покликані зробити ці рішення контрольованими.

Практичний крок до скорочення повторних обчислень

За повідомленням компанії, Tensormesh Platform доступна від моменту запуску. Її важливість полягає в тому, що стан інференсу розглядається як ресурс, яким можна керувати в усьому парку систем, зберігаючи обчислення для повторного використання довше, ніж триває окремий запит.

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