Насколько хорошо новая модель ИИ справляется с задачами — первый вопрос, который обычно задают при ее обсуждении. В техническом сообществе разговор обычно идет о бенчмарках, количестве параметров и гонке рейтингов.
Вот только для пользователя это чаще косвенные показатели. Главное — скорость работы, нет ли зависаний под нагрузкой и сколько стоит тариф. Если модель отлично решает задачи, но тормозит, или токены стоят как чугунный мост, ее популярность резко падает в пользу чуть менее эффективной.
Поэтому на этапе инференса модель оптимизируют насколько возможно. Об этом ведущий эксперт в области инфраструктуры ИИ Филипп Кили написал целую книгу под названием «Инженерия инференса»: как разместить модель на нужном оборудовании, ускорить ответы, выдержать текущую и пиковую нагрузку и при этом не потратить больше, чем продукт сможет принести.
Сегодня коротко разберем основные мысли оттуда.
Два этапа работы модели
Чтобы понять способы ускорения, которые предлагает Кили, разделим работу языковой модели на два этапа: чтение (prefill) и написание (decode).
Модель получает запрос и читает его. Неважно, короткий это вопрос или объемный промпт с десятками страниц. Такие большие запросы модель обрабатывает целиком за один проход, если хватает вычислительной мощности. Тут становится понятно, сколько времени пройдет до получения пользователем первых символов на экране.
Потом нейросеть переходит на этап написания и выдает ответ. Он строится последовательно, фрагмент за фрагментом. Каждый новый кусок опирается на все предыдущее: переписку, контекстное окно и уже сгенерированный текст.
На втором этапе проблема уже не в вычислительной мощности, а в пропускной способности памяти. Оборудованию приходится снова и снова обращаться к огромному набору параметров ради нового фрагмента текста.
У каждого этапа свое узкое место. Проанализировав книгу, я выделил несколько советов, которые помогают это преодолеть.
Совет первый: модель поменьше
Когда речь идет об ускорении, в первую очередь в голову приходят видеокарты, кэш и программные движки. Но Кили считает, что практичнее сначала понять, верную ли модель выбрали при развертывании инфраструктуры.
Для этого важно сформулировать требования к продукту:
что должна делать модель;
какое качество ответа считается достаточным;
какое время ожидания приемлемо для пользователя;
сколько компания может потратить на один запрос;
нагрузка будет постоянной или люди пойдут резкими волнами.
С такими вводными уже можно примерно прикидывать адекватную производительность.
Автор предлагает использовать самую маленькую и токеномичную модель, которая уверенно справляется с вашими задачами. Большинству компаний, особенно средним и небольшим, не нужны самые прокачанные LLM из топа рейтингов: вариант попроще может отлично справляться с задачами в своей области. Крутая модель не гарантирует, что она будет лучшей в отдельных типах задач, а стоить будет ощутимо дороже — и по цене работы, и по стоимости оборудования.
Проверять модель нужно на реальных задачах, а не на общих тестах. Если нейросеть работает в техподдержке, ей нужно общаться с тестовыми клиентами (о чем я недавно писал). Если она работает с определенным типом документов, эти документы ей и нужно скармливать.
Размещать собственную модель вместо API провайдера имеет смысл только тогда, когда компания уверенно понимает, какую проблему это решит.
Совет второй: объединяй и обрабатывай
Когда определитесь с выбором модели, нужно разобраться, как она будет обслуживать пользователей. Для этого есть базовый прием оптимизации — бэтчинг (batching), то есть объединение разных запросов в одну группу.
В чем соль. При генерации ответа модель постоянно читает свои параметры из памяти видеокарты. Ради одного запроса приходится перемещать огромный объем данных, хотя вычислительных мощностей для его обработки нужно сравнительно мало. Если считать несколько ответов одновременно, одни и те же загруженные параметры можно использовать сразу для целой группы запросов. Видеокарты в таком случае потребляют больше ресурсов, но успевают обслужить намного больше пользователей, и средняя стоимость одного ответа падает.
Но есть и проблема. Если собирать запросы в группы, появляется задержка: нужно дождаться, пока наберется достаточно пассажиров, как в маршрутке. У одних пользователей запросы могут быть объемные, у других — маленький вопрос в полпредложения. А когда группа уже обрабатывается, мелкий запрос не может закончиться раньше остальных: сервер ждет, пока завершится самый длинный запрос в группе. Причем дважды: сначала в очереди перед чтением, потом при написании.
Поэтому к бэтчингу прикручивают опцию непрерывного формирования групп. На языке маршруток: кто-то может выйти раньше, если по пути появится новый относительно эквивалентный пассажир.
В итоге общая пропускная способность модели растет.
Совет третий: вам нужен кэш
И одними финансами тут не обойтись. Вам потребуется освоить кэширование префикса.
Представим, что модель много раз отвечает на вопросы по огромному документу на 45 страниц. Без оптимизации она будет обрабатывать документ целиком в ответ на каждый запрос, даже если в нем ничего не изменилось.
И вот тут в дело вступает кэширование префикса — общей начальной части запроса. Система один раз обрабатывает ее и сохраняет результат. Когда приходит следующий запрос с тем же началом, модель сразу переходит к новой части — скажем, к очередному вопросу о документе.
Чем больше общая часть запросов и чем чаще они повторяются, тем ощутимее экономия времени и затрат. Это отлично работает с длинными системными инструкциями и техдокументацией.
Но тут важно отправлять готовые запросы на серверы, где данные уже сохранены. Иначе готовый кэш останется обособленным, и на других машинах вычисления пойдут классическим путем. Есть и ограничение: кэш занимает память видеокарты, а она не бесконечная. Так что хранить стоит только то, что запрашивают часто.
Совет четвертый: используйте кванты
Точнее, квантизацию. Это способ упрощения чисел внутри модели. Любая нейросеть хранит в параметрах миллиарды цифр, и они занимают память видеокарты. Чем точнее каждое число, тем больше места оно требует. А для работы максимальная точность нужна далеко не всегда.
Грубо говоря, если у отдельного значения много знаков после запятой, его можно округлить. Если число хорошо обрезать, получится ощутимое высвобождение памяти и буст по скорости, потому что модели проще работать с числами покороче.
Квантизация позволяет разместить модель на меньшем количестве ускорителей.
Но помните: чем серьезнее сжатие числовых параметров, тем выше риск галлюцинаций. Кили считает FP8 и MXFP8 (хранение числа в 8 двоичных разрядах) оптимальным компромиссом между качеством работы и ресурсозатратами модели. И при такой оптимизации нужно повторно тестировать решение рабочих задач.
Совет пятый: матрешка моделей
Языковая модель обычно создает по одному фрагменту за раз. Ускорить ее можно, подключив более мелкую модель.
Мини-модель подкидывает несколько фрагментов текста, а основная проверяет их за один заход, и если предположение большой модели совпадает с предложением мелкой, она его принимает.
Принцип похож на подготовку черновика: основная модель не генерирует каждое слово, а берет на себя роль проверяющего, который не обязан соглашаться с предложенным текстом и может его отклонить. Маленькие модели тратят меньше мощностей и токенов.
Но оптимизация такого рода хороша только на предсказуемых задачах и в программировании. Когда у ответа много возможных трактовок, возникают проблемы.
А почему бы просто не добавить видеокарт?
Казалось бы, зачем все это? Проще расширить вычислительные мощности и настроить их, чем занимать сложной оптимизацией целую команду инженеров. Тем более что инженеры тоже стоят денег и входят в затраты на инфраструктуру.
Проблема в том, что между ускорителями идет постоянный обмен данными. Чем их больше, тем интенсивнее обмен, который в свою очередь порождает задержки.
Две видеокарты никогда не будут работать вдвое быстрее одной. Важно, сколько у них памяти, насколько быстро читаются данные и с какой скоростью они общаются между собой. Поэтому самая новая и дорогая модель видеокарты далеко не всегда будет выгодным выбором для конкретной задачи.
Решает не количество GPU, а их правильная конфигурация. Можно настроить серверы так, чтобы часть ускорителей работала со входящими запросами (чтение), а часть — с исходящими (написание). Но такое разделение оправдано только при высокой нагрузке, иначе не окупится.
Всю эту рутину берут на себя движки инференса: vLLM, SGLang, TensorRT-LLM. Они определяют, какие запросы объединить, что сохранить в кэше, как распределить модель между устройствами и когда освободить занятую память. Автор книги разбирает примеры в основном на этом ПО.
Еще один совет: мониторинг скачков активности
Самый сладкий сон сисадмина — равномерно распределенная нагрузка. Но в реальности всегда есть пиковые часы, к которым нужно быть готовым. Условно, в обычном состоянии модель получает 20 запросов в секунду, а в пике уже целых 100.
Каждую секунду очередь пополняется на 80 запросов, а за полминуты вырастает до 2400. Даже когда всплеск закончится, системе потребуется время, чтобы разобрать накопленное. Тем временем пользователи ждут и недовольны.
Казалось бы, можно посчитать нагрузку, как для обычного сайта, и исходить из этой цифры. Но языковые модели коварны: никогда не знаешь заранее, сколько ресурсов уйдет на конкретный запрос. Значит, нужен механизм, который подстраивается под нагрузку. Для этого как раз можно использовать автоматическое масштабирование: система замечает растущую очередь и добавляет мощности.
Но у автомасштабирования есть лаг. Пока новые ресурсы запустятся, очередь успевает вырасти до тех самых 2400 запросов за полминуты. Чтобы эту проблему перекрыть, Кили предлагает смотреть на две вещи: сколько запросов приходит и насколько загружены видеокарты. По числу обращений видно заранее, что нагрузки прибавится. А загрузка видеокарт показывает, когда ресурсы уже на пределе. Первое — сигнал на будущее, второе — на сейчас.
Помимо этого, для важных сервисов часть серверов держат заранее запущенными, чтобы сразу принять всплеск. Обращения распределяют по приоритету, а при перегрузке удерживают в очереди, пока не добавятся мощности. А очередь, время ожидания и размеры запросов помогают понять, что происходит.
А что с медиа?
Большая часть книги посвящена LLM, но инженерия инференса выходит за пределы текста и затрагивает также обработку изображений и голоса.
Чтобы оптимизировать обработку картинок, в первую очередь можно урезать качество входного изображения. В большинстве случаев это не критично. Модель уменьшает разрешение, а в случае с видео может снизить частоту FPS или брать только ключевые кадры.
В распознавании речи длинную запись дробят по паузам между репликами. Полученные фрагменты можно обрабатывать параллельно, а затем собирать в единый текст. В живом разговоре модель получает звук небольшими порциями, не дожидаясь конца фразы или всей записи. Неудачно распознанные участки — например, куски с подозрительным количеством повторов — отправляют на повторную обработку с другими настройками.
Кили предлагает разрабатывать голосовой помощник как цепочку из трех моделей: первая переводит речь в текст, вторая формирует ответ, третья озвучивает его. Чтобы собеседник не ждал завершения всей цепочки, каждый компонент начинает сразу передавать результат дальше небольшими частями. Языковая модель может отвечать еще до конца расшифровки, а синтезатор начинать воспроизведение до завершения всего текста.
В итоге
Inference Engineering показывает, что хорошая модель — всего лишь исходный материал. Чтобы превратить ее в продукт, нужно найти баланс между качеством, скоростью, стоимостью и надежностью. Универсального рецепта нет: сначала определяются требования, затем выбирается минимально достаточная модель, находится узкое место и только после этого применяется конкретная оптимизация.
Книгу можно получить бесплатно по этой ссылке — достаточно указать имя, email и компанию (в поле можно вписать что угодно, хоть Google). На почту моментально придет PDF-файл и бонусом ePUB.
А если вам в целом интересно, как устроена экономика ИИ, то можете почитать другие статьи на эту тему: