TensorCast — програмований шар керування станом великих ШІ-моделей

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

Ідея важлива не лише як чергова оптимізація інференсу. TensorCast має стати спільним рівнем керування для ваг моделей, блоків KV Cache та інших проміжних станів, які сьогодні часто обслуговуються різними компонентами інфраструктури.

Яку проблему вирішує TensorCast

Системи для запуску великих мовних моделей (LLM) працюють не тільки з незмінними вагами. Їм також потрібно швидко обробляти динамічні блоки KV Cache — кеш ключів і значень, у якому зберігається контекст попередніх токенів, — а також проміжні тензорні стани.

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

TensorCast пропонує винести керування життєвим циклом тензорів в окремий системний шар. Застосунок описує, що потрібно зробити зі станом, а середовище виконання саме організовує його пошук, розміщення, передачу, перетворення та підготовку до використання на доступних ресурсах кластера. 1

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

Як побудована система

• Тензори як об’єкти першого класу. Кожен тензор має власний ідентифікатор, інформацію про власника, розміщення та правила життєвого циклу. Тому рушій може посилатися на ваги, блок KV Cache або проміжний стан, не зашиваючи в логіку відомості про конкретний вузол, GPU чи тип сховища. 1
• Комбіновані примітиви життєвого циклу. Розробники можуть поєднувати операції переміщення, перетворення, попереднього завантаження, реплікації та матеріалізації у власні політики під конкретне навантаження. Це зменшує потребу щоразу переписувати низькорівневу інфраструктуру. 1
• Розділення політики й механізму. Політика задається через API TensorCast, тоді як середовище виконання бере на себе розподілене виконання та передачу даних. Базовий рушій не обов’язково потрібно змінювати для кожної нової оптимізації. 1
• Поділ площини керування і площини даних. Global Store (GS) зберігає метадані — стан вузлів і Worker-процесів, розташування тензорів, права власності та інформацію для планування. Самі дані передають Workers. Отже, GS координує операції, але не стає каналом для всього трафіку тензорів. 1
• Різні стратегії для різних метаданих. Відносно статичні об’єкти з невеликою кількістю записів, наприклад ваги моделі, можуть централізовано відстежуватися в GS. Натомість численні й динамічні об’єкти, як-от блоки KV Cache, розподіляються між Workers. Worker, призначений «домом» для певного сегмента, підтримує його власність і узгодженість за допомогою лізингів та fencing-токенів. 1
• Швидка матеріалізація. Локальні копії можуть відкривати GPU-пам’ять через CUDA IPC, а CPU-пам’ять — через локальні дескриптори memfd. Для віддалених джерел передбачено прямий запис через RDMA, що дає змогу уникати зайвих копіювань і використовувати обмін GPU-GPU або локальні шляхи, коли вони доступні. 6

Чому міграція KV Cache стає простішою

У звичайній системі обслуговування LLM перенесення багатокрокового діалогу з одного інстансу на інший може вимагати одночасних змін у маршрутизаторі запитів, реалізації KV Cache всередині рушія та мережевому або кеш-бекенді.

У TensorCast політика може просто визначити тензорні об’єкти, що належать сесії, попросити розмістити або матеріалізувати їх на цільовому Worker і спрямувати туди наступні запити. Пошук, передача та прив’язка даних до пам’яті виконуються середовищем керування життєвим циклом. 1

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

Що показали випробування

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

За заявленими результатами, продуктивність роботи з KV Cache була співставною з Mooncake — спеціалізованою системою для кешу, — водночас TensorCast зберігав можливість реалізовувати політики, що охоплюють кілька компонентів інфраструктури. 1

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

У сценаріях із високою конкуренцією та багатокроковими агентними взаємодіями програмована політика TensorCast, за повідомленням авторів, зменшила медіанний time-to-first-token (TTFT) — час до появи першого токена відповіді — до 93,2%. 1

Чому це може бути важливо

TensorCast показує напрям, у якому інфраструктура ШІ може перейти від набору вертикальних оптимізацій до єдиного програмованого шару для роботи зі станом моделей. Швидкий запуск інстансів, маршрутизація з урахуванням локальності кешу, міграція сесій і повторне використання вже завантажених тензорів можуть задаватися як системні політики, а не як окремі функції конкретного рушія чи сховища.

Водночас наведені показники є експериментальними результатами авторів дослідницького препринта. Для оцінки готовності TensorCast до промислового використання потрібні незалежне відтворення результатів і перевірка на production-навантаженнях. 1