DuoLM ускоряет LLM-рекомендации в 60 раз: 26 400 оценок в секунду на одном H100

Рекомендательные системы на больших языковых моделях упираются в арифметику. Чтобы оценить сотни кандидатов для одного пользователя, приходится гонять через модель полные тексты описаний вместе с историей, и пропускная способность серверов быстро заканчивается. Авторы DuoLM — Jiang Wu, Yutong Song, Hongbo Wang, Guanghe Cao и Jeff Lei Liang — предлагают убрать повторную работу целиком. На одной видеокарте H100 их система считает около 26 400 оценок кандидатов в секунду. Это примерно в 60 раз быстрее учителя, развёрнутого на vLLM с automatic prefix caching, при сопоставимом качестве рекомендаций.

Две модели вместо одной длинной подсказки

Обычный LLM-ранкер получает на вход всё сразу: текст объекта, историю пользователя, его реакции. Для каждой пары «пользователь — кандидат» текст приходится обрабатывать заново, хотя описание товара или ролика от пользователя не зависит.

DuoLM делит задачу на две части. Первая — энкодер на базе LLM. Он читает описание объекта и сжимает его в компактное представление. Это делается офлайн, результат кэшируется и годится для любого количества пользователей. Вторая — персонализированный ранкер, тоже LLM. Он получает готовые представления кандидатов, историю пользователя и обратную связь и выдаёт рекомендацию.

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

Рантайм: виртуальные токены и CUDA Graphs

Модель, которая в теории экономит вычисления, на практике легко теряет выигрыш на накладных расходах. Поэтому авторы описывают не только архитектуру, но и серверную часть. Она устроена так:

• представления объектов хранятся прямо на GPU и подаются в модель через виртуальные token ID — ранкер обращается к эмбеддингам так же, как к обычным токенам, без лишних копирований;
• несколько кандидатов внутри одного запроса делят вычисление истории пользователя: её префикс считается один раз, а не для каждого кандидата;
• CUDA Graph replay снижает накладные расходы на запуск ядер, что важно, когда сами вычисления короткие.

Вместе модель и рантайм сокращают повторную работу на каждом этапе рекомендательного конвейера.

Что дают 26 400 оценок в секунду

Главные параметры работы:

• архитектура: энкодер LLM для компактных представлений объектов и персонализированный ранкер LLM;
• обучение: end to end, рекомендательная разметка и дистилляция из full-text учителя;
• инференс: виртуальные token ID, общий расчёт истории, CUDA Graph replay;
• железо: один GPU H100;
• пропускная способность: около 26 400 оценок кандидатов в секунду;
• ускорение: примерно в 60 раз относительно учителя на vLLM с automatic prefix caching;
• качество: сопоставимо с экспертной моделью-учителем.

Сравнение интересно тем, что базой выбран не наивный запуск, а vLLM с prefix caching — то есть уже оптимизированный стек. Даже он проигрывает на порядок, потому что кэширует префиксы, но не заменяет длинные тексты объектов короткими векторами.

Для команд, которые строят рекомендации на LLM, вывод практический. Если каталог меняется медленнее, чем растёт трафик (товары, статьи, видео, объявления), описания разумно переводить в кэшируемые представления заранее. Тогда онлайн-часть сводится к работе с историей пользователя, а стоимость ранжирования одного кандидата падает кратно. Параллельно это снижает нагрузку на GPU-парк: те же запросы обслуживаются меньшим числом карт.

Ограничения тоже понятны. Выигрыш зависит от доли повторно используемых объектов и от того, насколько сжатое представление сохраняет детали. Заявленное качество измерено на бенчмарках относительно учителя, а не в живом A/B-тесте на продакшен-трафике. Но сама схема «офлайн-энкодер, онлайн-ранкер и серверный рантайм под неё» выглядит воспроизводимой: код проекта опубликован на GitHub, и проверить 60-кратный разрыв на собственных данных можно без переписывания всей инфраструктуры.