Оптимизация инференса LLM: скорость ответа, нагрузка и загрузка видеокарт

Очередь, чтение запроса, выдача ответа

Запрос сначала ждёт в очереди, потом модель читает его целиком (чем длиннее запрос с вложенными документами, тем дольше), и только затем начинает выдавать ответ по частям, слово за словом. Пользователь чувствует два интервала: время до первого слова и скорость, с которой текст появляется дальше. Чтение запроса упирается главным образом в вычислительную мощность карты, выдача ответа — в скорость обращения к памяти и в размер весов.

Почему важен профиль нагрузки

Ассистент по документам присылает длинные запросы с найденными фрагментами и получает короткие ответы: узким местом оказывается чтение. Классификатор обращений получает короткие запросы и отдаёт несколько слов, и всё решает число запросов в секунду. Чат с агентом ведёт длинные диалоги, где контекст растёт, а память под него занята. Один и тот же сервер для этих трёх задач настраивается по-разному.

Что происходит с памятью

Кроме самих весов, видеопамять занимает кэш уже прочитанного контекста, и он растёт с длиной запроса и числом одновременных диалогов. Когда память кончается, сервер начинает ограничивать число запросов в обработке, и очередь растёт даже при незагруженных вычислениях. Расчёт этой части описан в статье «Сколько видеопамяти нужно для своей языковой модели».

На открытых серверах инференса, таких как vLLM, llama.cpp и Text Generation Inference, и на решениях производителей карт у каждого свои сильные стороны: одни хорошо собирают запросы в общую обработку, другие удобно работают на процессоре и на небольших картах, третьи требуют конкретного оборудования. Формат весов и поддержка именно вашей модели часто решают больше, чем заявленная скорость.

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

Что входит в вопрос выбора

• Оборудование. Какие карты есть и что поддерживает программа на них; для отечественных ускорителей и редких карт поддержку проверяем отдельно.
• Формат весов и лицензия. Какие форматы читает сервер и разрешает ли лицензия модели ваше использование.
• Интерфейс. Совместим ли сервер с общепринятым интерфейсом запросов, чтобы приложения не пришлось переписывать.
• Эксплуатация. Как обновляется, какие даёт метрики для мониторинга, что делает при нехватке памяти.

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

Версии моделей, оценка качества при обновлениях и мониторинг дрейфа относятся к MLOps и развёртыванию моделей. Когда вопрос в том, подойдёт ли вообще своя модель или хватит внешнего программного интерфейса, сравнение лежит в статье «Своя LLM или ChatGPT API». Внешний интерфейс снимает заботу о железе, но для данных ограниченного доступа чаще не подходит по требованиям заказчика.