Яндекс раскрыл LLM-оптимизации больших моделей: 50+ патчей для продакшена

Андрей, разработчик сервисов машинного обучения для Yandex AI Studio, опубликовал разбор того, с чем столкнулась команда Яндекса, когда запустила флагманские модели в реальную эксплуатацию. Проблемы оказались не в самих моделях, а в планировщике, аллокаторе GPU-памяти, очереди стримингового вывода и сети. Статья ценна тем, что показывает боли продакшена изнутри, а не с позиции вендорских бенчмарков.

Пять метрик, между которыми приходится выбирать

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

• TTFT (Time to First Token, время до первого токена (token, единица текста: часть слова, знак препинания или фрагмент кода)) от получения запроса до появления первого слова в ответе.
• TBT (Time Between Tokens, время между токенами) насколько равномерно модель выдаёт текст.
• U2E (User to End, время полного ответа) от запроса до последнего токена, критично там, где нужен готовый результат целиком.
• Пропускная способность на GPU измеряется в токенах в секунду на одну видеокарту.
• Стоимость инференса цена обработки тысячи или миллиона токенов.

Оптимизировать все пять одновременно невозможно. Выбор зависит от сценария: голосовому роботу нужен быстрый TTFT, кодовому ассистенту важен U2E, а аналитике на миллион обращений в день важна минимальная стоимость.

Почему длинный контекст ломает всё?

Главная боль, которую описывает команда Яндекса: для классического механизма внимания (attention) вычислительная сложность растёт очень быстро при увеличении длины входа. KV-кеш (промежуточные данные, которые модель хранит, чтобы не пересчитывать уже обработанный текст) раздувается до десятков и сотен гигабайт.

Если контекст вырос с 4 000 до 32 000 токенов, нагрузка на обработку входа увеличивается кратно. А в облаке трафик произвольный: у одного клиента кодовый ассистент, у другого голосовой робот, у третьего пакетная аналитика. Длинные и короткие запросы, обрабатываемые параллельно на одном GPU, начинают мешать друг другу. Именно на таких смешанных нагрузках всплывает то, чего не видно на референсных замерах вендора.

Что понадобится

• Доступ к GPU-кластеру (или облачному GPU-инстансу, например в Yandex Cloud).
• Инференс-движок с открытым кодом (команда Яндекса работала с открытыми репозиториями и вносила правки в них).
• Мониторинг метрик TTFT, TBT, U2E на реальном трафике, а не на синтетических бенчмарках.
• Готовность копаться в чужом коде: по словам автора, суммарно команда сделала больше 50 контрибьютов (правок и дополнений) в разные открытые репозитории.
• Время: речь не о настройке за вечер, а о системной работе над каждым слоем инференс-стека.

Пошаговая инструкция

1. Замерьте метрики на реальном трафике, не на тестах. Синтетический бенчмарк покажет идеальную картину. Проблемы появляются, когда на один кластер приходят запросы с контекстом в 4 000 и 32 000 токенов одновременно. Фиксируйте TTFT, TBT и U2E именно на боевом потоке.

2. Разделите prefill и decode. Prefill (обработка входного запроса) требует вычислительной мощности и чувствителен к длине контекста. Decode (генерация ответа по одному токену) чувствителен к памяти и стабильности TBT. На GPU у этих операций нет приоритетов, поэтому если всё работает на одном сервере, длинные запросы «забивают» короткие. Команда Яндекса управляет этими стадиями отдельно, выделяя под каждую свои ресурсы.

3. Изолируйте нагрузки разных сценариев. Раньше в Yandex Cloud разделяли инференс на пользователей с короткими и длинными запросами, чтобы короткие не зависали. Определите, какие сценарии конкурируют за ресурсы в вашем случае, и разнесите их.

4. Проверьте планировщик, аллокатор памяти и сеть. По опыту команды, причина деградации TTFT почти никогда не в модели. Она прячется в планировщике (компонент, который решает, какой запрос обработать следующим), аллокаторе GPU-памяти (компонент, который распределяет память видеокарты между задачами) или в сетевом слое.

5. Будьте готовы править открытый код. Если вы используете открытый инференс-движок, готовые настройки могут не учитывать вашу конфигурацию. Команда Яндекса переписывала куски рантайма (исполняемого кода) под свои конфигурации и возвращала исправления в открытые репозитории.

Что делать с этим прямо сейчас, по ролям

Автору на Дзене или копирайтеру. Если вы используете ИИ-ассистента для генерации текстов и замечаете, что ответы приходят рывками или с задержкой, причина может быть не в «глупости» модели, а в перегруженном инференсе на стороне сервиса. Это полезно понимать хотя бы для того, чтобы не менять инструмент, когда достаточно сменить время суток или длину промпта (prompt, текстовый запрос к модели).

Маркетологу. Стоимость инференса напрямую влияет на экономику ИИ-продуктов. Если вы закладываете бюджет на ИИ-аналитику или чат-бот для клиентов, спрашивайте поставщика не только про «точность модели», но и про то, как устроен инференс и как считается цена за токен.

Предпринимателю в РФ. Яндекс через AI Studio предлагает инференс своих моделей в облаке. Это один из немногих вариантов запуска больших моделей в продакшене без выстраивания собственной GPU-инфраструктуры. Опыт с яндекс LLM оптимизации больших моделей, описанный командой, показывает, что платформа проходит через реальные нагрузки, а не только лабораторные тесты.

Разбор команды Яндекса показывает простую вещь: модель может быть сколь угодно хорошей, но если инференс-стек не настроен под реальный трафик, пользователь увидит тормоза и уйдёт. Для тех, кто строит ИИ-продукты в России, опыт с разделением prefill и decode и работой над открытым кодом это не абстрактная инженерия, а практическое руководство к тому, куда смотреть, когда TTFT вырос в три раза, а модель ни при чём.