В мире современных рекомендательных систем происходит фундаментальный сдвиг: от традиционных пайплайнов извлечения и ранжирования к генеративным моделям, которые рассматривают персонализацию как задачу моделирования последовательностей. Однако внедрение таких мощных архитектур, как Hierarchical Sequential Transduction Unit (HSTU), сталкивается с серьезными вызовами в плане задержек (latency) и использования ресурсов. NVIDIA предлагает комплексное решение, объединяющее PyTorch AOTI, кэширование KV-состояния через FlexKV и сервер инференса Dynamo-Triton, чтобы сделать эти модели доступными для высоконагруженных продакшен-сред.
Эта статья подробно разбирает архитектуру развертывания HSTU-рекоммендатора. Мы рассмотрим, как компиляция моделей «время от времени» (Ahead-of-Time) снижает накладные расходы Python, как кэширование ключей и значений (KV-cache) устраняет избыточные вычисления для длинных историй пользователей, и какие практические результаты производительности можно ожидать на оборудовании NVIDIA RTX PRO 6000 Blackwell Workstation Edition GPU. Это руководство для инженеров ML, стремящихся оптимизировать инференс сложных последовательных моделей.
01Почему HSTU для генеративных рекомендаций?
Генеративные рекомендательные системы (GR) переосмысливают задачу персонализации. Вместо того чтобы обрабатывать извлечение, ранжирование и предсказание как изолированные этапы, GR формируют рекомендацию как задачу моделирования последовательностей. Взаимодействия пользователя, контекст, кандидаты и действия становятся токенами в высокоразнообразном потоке событий. Модель учится генерировать или оценивать следующие релевантные элементы на основе этой последовательности.
Этот подход особенно привлекателен для современных рабочих нагрузок, где истории пользователей могут быть очень длинными, каталоги товаров постоянно меняются, а качество персонализации зависит от моделирования богатого последовательного поведения. В примере NVIDIA HSTU входные данные строятся из категориальных токенов: контекстуальные токены представляют информацию о пользователе, токены предметов — сами товары, а опциональные токены действий — взаимодействия пользователя с этими товарами.
Путь предварительной обработки HSTU извлекает эмбеддинги, чередует эмбеддинги предметов и действий (если присутствуют токены действий), добавляет контекстуальную информацию и применяет позиционное кодирование. Блоки HSTU затем обрабатывают последовательность, а голова предсказания выдает многозадачные результаты ранжирования. Эта структура идеально подходит для систем, где важны свежесть, порядок и повторяющиеся паттерны взаимодействия. Однако это также означает, что инференс может стать дорогим, если каждый запрос повторно обрабатывает длинные исторические последовательности.
02Почему обслуживание больших последовательных рекомендательных систем сложно?
Обслуживание больших последовательных рекомендательных систем кардинально отличается от обслуживания небольших плотных моделей ранжирования. Стек обслуживания должен обрабатывать «рваные» (jagged) входные последовательности, большие состояния категориальных эмбеддингов, длинные истории и паттерны запросов, при которых один и тот же пользователь возвращается повторно с небольшим количеством новой информации.
Пересчет полного ключ-значение (KV) состояния для истории пользователя при каждом запросе — это пустая трата вычислительных ресурсов и источник высоких задержек. Здесь на сцену выходит кэширование KV. Кэш KV хранит повторно используемые данные ключей и значений из предыдущих вычислений последовательности, позволяя модели избегать пересчета закэшированных частей истории пользователя. Для рекомендательного инференса это особенно полезно, когда долгосрочная история пользователя остается стабильной, а появляются новые кандидаты или недавние действия.
В рабочем процессе инференса NVIDIA HSTU используется KVCacheManager, который использует память GPU и хранилище хоста для кэшей KV-данных. Кэш GPU организован как таблица данных KV с страницами и поддерживает операции поиска, выделения, добавления и вытеснения. Когда пространство кэша GPU ограничено, старые пользователи могут быть вытеснены в соответствии с политикой, похожей на LRU (Least Recently Used). Хост-сторона предоставляет еще один уровень для кэшированных KV-данных, и рабочий процесс включает бэкенд, поддерживаемый FlexKV, для времени выполнения кэша KV.
03PyTorch AOTI для нативного инференса
Рабочий процесс PyTorch AOTI (Ahead-of-Time Inductor) начинается с модели PyTorch и экспортирует ее с помощью torch.export и PyTorch AOTI. AOTI компилирует модель заранее в пакет, который может быть загружен нативным C++ рантаймом. Это снижает накладные расходы рантайма Python и предоставляет артефакт, удобный для развертывания, для бэкенда Dynamo-Triton PyTorch AOTI.
Экспортированный пакет модели содержит архив модели AOTI, а также метаданные и файлы таблиц эмбеддингов. В примере NVIDIA реализация эмбеддингов сочетает таблицы инференса DynamicEmb и NV Embedding Cache, который снижает использование памяти GPU, храня только популярные эмбеддинги в памяти GPU, в то время как вся таблица остается в памяти CPU. Путь экспорта записывает метаданные слоев и данные таблиц эмбеддингов вместе с скомпилированным архивом .pt2, чтобы модель можно было загрузить без ненужных дублирующихся копий таблиц эмбеддингов.
Рабочий процесс проверяет одни и те же экспортированные артефакты нескольки
Источник: NVIDIA Developer ↗