TensorCast объединяет управление весами моделей и KV Cache в одном слое

TensorCast — это предлагаемая распределённая прослойка Tensor-as-a-Service (TaaS) для управления жизненным циклом тензоров. Она отвечает за идентификацию, размещение, перемещение, преобразование, совместное использование и материализацию тензорных данных независимо от вычислений, которые эти данные создают или используют. 1

Главная идея проекта — заменить набор разрозненных механизмов для загрузки весов, работы с KV Cache, сетевой передачи и хранения общим программируемым интерфейсом. Такой подход особенно важен для динамической инфраструктуры больших языковых моделей, где состояние постоянно перемещается между узлами, GPU и уровнями хранения. 1

Зачем понадобился TensorCast

Современные системы обслуживания LLM работают не только с неизменяемыми весами модели. Им также приходится управлять постоянно меняющимися блоками KV Cache — промежуточным состоянием внимания, которое позволяет продолжать многошаговый диалог без повторного вычисления всей истории, — а также различными промежуточными тензорами.

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

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

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

Как устроена система

• Тензоры становятся объектами первого класса. Каждый тензор получает собственный идентификатор, владельца, сведения о размещении и правила жизненного цикла. Благодаря этому движок может обращаться к весам, блоку KV Cache или промежуточному состоянию, не «зашивая» в код информацию о конкретном узле, GPU или формате хранения. 1
• Операции жизненного цикла можно комбинировать. Разработчик собирает прикладную политику из примитивов перемещения, преобразования, предварительной загрузки, репликации и материализации, вместо того чтобы каждый раз менять низкоуровневую инфраструктуру. 1
• Политика отделена от механизма исполнения. Правила управления описываются через API TensorCast, тогда как распределённое выполнение и передача данных остаются задачей среды выполнения. Это позволяет внедрять новые стратегии без обязательной переделки самого движка инференса. 1
• Разделены плоскости управления и данных. Глобальное хранилище (Global Store, GS) содержит метаданные: состояние узлов и Worker-процессов, местоположение тензоров, сведения о владении и планировании. Сами полезные данные передают Worker-процессы. Поэтому GS координирует операции, но не становится узким местом для переноса больших тензорных массивов. 1
• Для разных типов состояния используются разные стратегии метаданных. Относительно статичные объекты с небольшим числом экземпляров, например веса модели, могут отслеживаться централизованно. Динамичный KV Cache с большим числом объектов распределяется по шардам: Worker, назначенный «домом» шарда, управляет владением и согласованностью с помощью аренд и fencing-токенов. 1
• Материализация рассчитана на минимальное число копирований. Реплики на Worker могут предоставлять доступ к памяти GPU через CUDA IPC, а к памяти CPU — через локальные дескрипторы memfd. Для удалённых источников TensorCast поддерживает прямую запись по RDMA, что позволяет использовать пути передачи GPU-to-GPU или локального совместного доступа, если они доступны. 6

Почему миграция KV Cache становится проще

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

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

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

Какие результаты получили авторы

Авторы интегрировали TensorCast с двумя популярными движками инференса — vLLM и SGLang — и проверили материализацию и синхронизацию весов, управление KV Cache, а также программируемую маршрутизацию запросов. 1

По заявлению исследователей, производительность работы с KV Cache сопоставима с Mooncake — специализированной системой для KV Cache. При этом TensorCast сохраняет возможность задавать политики, охватывающие сразу несколько компонентов инфраструктуры. 1

Для запуска экземпляра Qwen3-235B-A22B, модели со 235 млрд параметров, из которых активируются 22 млрд, в статье заявлено ускорение до 228,6 раза по сравнению с распространёнными распределёнными файловыми системами. 12

В сценариях с высокой конкуренцией и многошаговыми агентными диалогами программируемая политика TensorCast, согласно результатам авторов, снизила медианное время до первого токена (TTFT, time-to-first-token) до 93,2%. 1

Что это значит для инфраструктуры ИИ

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

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