Как ускорить LLM на CPU и GPU с ONNX Runtime: практическое руководство

ONNX Runtime оптимизация инференса: где теряется скорость

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

Первый участок — подготовка входа: токенизация, приведение типов, раскладка тензоров и копирование данных в память вычислителя. На коротких запросах и компактных моделях именно эти операции становятся узким местом обработки запроса: слои считаются быстрее, чем до них успевают доехать данные. Профиль выполнения модели, снятый по этапам, а не целиком, сразу показывает такую асимметрию.

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

Третий участок — постобработка и ожидание освобождения ресурса. Декодирование, отбор вариантов и сортировка результатов конкурируют за тот же поток, что и прогон, а при параллельных запросах добавляется очередь. Время отклика под пиком растёт нелинейно, поэтому важна не средняя задержка на одиночном запросе, а поведение под нагрузкой — именно там видно, что оптимизировать первым.

Что ускоряется: задержка, пропускная способность, нагрузка

Ускорение инференса раскладывается на три независимые величины, и правки редко улучшают все сразу. Узел на ONNX Runtime с подобранным провайдером исполнения и батчингом держит кратно больше запросов в секунду, чем тот же узел с настройками по умолчанию: вычислительные ядра перестают простаивать между вызовами, а входные данные группируются так, чтобы память читалась непрерывно. Пропускную способность одного узла мы снимаем до и после правок — это первое число, по которому видно эффект.

Средняя задержка обманывает: она маскирует хвост, который и определяет опыт пользователя. Поэтому смотрим медиану и 95–99 перцентиль отдельно — хвост сжимается заметнее медианы, потому что уходит не средняя работа, а редкие дорогие ветки: пересборка графа, лишние копирования тензоров, ожидание в очереди.

Утилизация оборудования показывает, где именно теряется время. Низкая загрузка вычислителя при полной очереди означает, что работа стоит на подготовке данных; обратная картина — упор в пропускную способность памяти. Когда эти профили выровнены, один узел держит тот же трафик без добавления железа.

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

Режимы ускорения: сравнение подходов и ограничений

Режимы ускорения не заменяют друг друга — их накладывают слоями, и каждый следующий требует запаса по памяти или по точности. ONNX Runtime включает их по отдельности, но выбор начинается с того, что именно упирается: время счёта, объём модели или ожидание в очереди.

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

Этапы работ: от аудита узких мест до передачи результата

Начинаем с замеров, а не с правки конфигурации: без профиля текущего инференса любая оптимизация превращается в угадывание. Снимаем, сколько времени уходит на предобработку, на сам проход по модели и на постобработку, и только после этого решаем, что менять. Ниже — порядок работ, по которому проходит каждый проект.

1. Аудит и замеры производительности. Снимаем профиль на реальном распределении нагрузки, а не на синтетическом. Разделяем время по этапам, смотрим утилизацию ускорителя, утечки памяти и очереди запросов — узкое место становится видно до начала работ.
2. Схема развёртывания. Фиксируем, где исполняется модель: на процессоре, на ускорителе или гибридно, сколько копий поднимаем, как группируем запросы в пакеты и что держим в кэше. Схема определяется до настройки, иначе оптимизация упирается в архитектуру.
3. Настройка инференса. Переводим модель в промежуточное представление ONNX Runtime, включаем квантизацию, подбираем провайдер исполнения и объединение операторов. Параметры меняем по одному, с замером после каждого шага.
4. Эталонный набор запросов. Собираем запросы из реальной эксплуатации, включая длинные и пограничные. На них считаем задержку и пропускную способность до и после — цифры должны воспроизводиться на вашей стороне.
5. Контроль качества ответов. Сравниваем выдачу оптимизированной и исходной модели на эталонном наборе, фиксируем долю совпадений и разбор отклонений. Если качество уходит ниже согласованного порога, конфигурацию откатываем и ищем другой режим.
6. Передача и обучение команды. Отдаём конфигурации, скрипты воспроизведения замеров, порядок обновления модели и разбор типовых сбоев. Проводим обучение: ваши инженеры должны уметь повторить замер и развернуть сборку без нас.

Порядок принципиален: замеры до настройки, проверка качества до передачи. Иначе ускорение ответа оборачивается регрессиями, которые всплывают уже в эксплуатации — и откатывать приходится на живом сервисе.

Пакет передачи: конфигурации, схемы и регламенты

Проект не заканчивается работающим сервисом — у вашей команды остаётся комплект артефактов, по которым систему можно обновлять, масштабировать и восстанавливать без нас. Ниже — что именно передаём и зачем каждый документ нужен на практике.

• Конфигурации окружения — файлы параметров запуска, лимиты по памяти и потокам процессора, настройки пакетной обработки запросов. С комментариями: какой параметр менять при росте нагрузки, а какой трогать нельзя без переобучения модели.
• Схема развёртывания — топология сервисов, где живёт модель, где кэш, какие узлы масштабируются горизонтально, а какие требуют резерва.
• Политики доступа и роли — разграничение прав: кто выкладывает новую версию модели, кто читает журналы и метрики, кто меняет конфигурацию. С матрицей ролей и описанием служебных учётных записей.
• Документация по эксплуатации — регламент запуска и остановки, проверка работоспособности сервиса, разбор типовых отказов с симптомами и действиями дежурного.
• Регламент обновления и отката версии — порядок выкладки новой сборки модели, время возврата на предыдущую и условия, при которых откат запускается автоматически.
• Набор метрик и порогов — какие показатели снимаем, при каких значениях срабатывает оповещение, как отличить деградацию качества ответов от сетевого сбоя.
• Инструкция по воспроизведению окружения — манифесты сборки и зависимости, чтобы развернуть стенд с нуля на другой машине.

Каждый документ пишем под конкретного исполнителя: дежурного инженера, разработчика или руководителя. Такой комплект снимает зависимость от подрядчика — изменения вносятся силами вашей команды, а мы остаёмся на связи по сложным случаям.

Кейс: как мы сократили время отклика модели вдвое

Задача пришла из сервиса внутренней поддержки: сотрудники задавали вопрос по базе знаний и ждали ответ в окне чата. На пике рабочий узел уходил в полную загрузку, очередь запросов росла, часть обращений отваливалась по времени ожидания — люди возвращались к ручному поиску по документам.

Разбор начали с замеров: сняли, сколько времени уходит на подготовку данных, сам вывод модели и сборку ответа. Основное время съедала не модель, а постоянная пересборка вычислительного графа под каждый вызов и разбор запросов по одному.

Граф вынесли в ONNX Runtime, зафиксировали форму входов, включили объединение операторов и кеш промежуточных состояний, веса привели к целочисленному представлению.

Замеры до и после

• время отклика модели — с 3,2 до 1,3 секунды на том же оборудовании;
• пиковая загрузка узла — с 94 до 58 процентов;
• число узлов под тот же поток обращений — вдвое меньше;
• доля ответов, совпавших с эталонной разметкой, — 93 процента до и после.

Сервис держит пиковый поток без очереди и отказов, а запас по узлам позволяет наращивать нагрузку без срочной закупки серверов. Клиент получил воспроизводимый контур замеров: каждый следующий прогон сравнивается с зафиксированной базовой линией, поэтому эффект от любой оптимизации виден сразу.

Что делать, если модель уже развёрнута и отвечает медленно

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

Если контракт менять нельзя, работают на уровне окружения, а код приложения остаётся тем же. Модель переводится в промежуточное представление графа: ONNX Runtime оптимизация инференса даёт выбор провайдера исполнения, и тяжёлые операции уходят на ускоритель, а остальное остаётся на процессоре. Число рабочих потоков, размер пакета и уровень оптимизации графа задаются в конфигурации — это настройки, а не переписывание логики.

Дальше — объём вычислений и повторная работа. Квантование весов уменьшает размер модели и ускоряет прямой проход без переобучения; переиспользование посчитанного контекста убирает повторный пересчёт на каждом шаге генерации; пакетная обработка выравнивает нагрузку под пиками. Каждый шаг обратим, и ответы до и после сравниваются — по расхождению видно, где качество просело.

Ставят это постепенно: оптимизированный вариант работает рядом с текущим, получает копию трафика, и метрики снимаются на живых запросах — задержка, доля отказов, совпадение ответов. Переключение делается переводом трафика, откат — возвратом прежнего артефакта, поэтому риск ограничен одним релизом. Входы, выходы и схема ответа не меняются, и внешние сервисы замену рантайма не замечают.

Разбираем частые технические сомнения заказчиков

Оптимизация инференса упирается не в выбор инструмента, а в проверяемость результата: важно знать, где именно теряется качество, повторится ли замер на другом стенде и что станет с уже работающим сервисом. ONNX Runtime здесь — исполнитель, а решения принимаются по метрикам.

Как проверяется результат, а не только скорость?

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

Замеры воспроизводимы на другой машине?

Замер имеет смысл, только если повторяется. Фиксируем версию модели, параметры генерации, состав набора и режим прогрева, прогоняем серию раз и смотрим разброс. В отчёте остаются описание стенда и команда запуска — вы перепроверяете цифры у себя.

Что с требованиями к оборудованию и откатом?

Ускорение на процессоре не требует отдельных ускорителей, а вариант с ними даёт выигрыш только при достаточной загрузке. Сначала снимаем профиль текущей нагрузки и подбираем конфигурацию под неё. Переход делаем поэтапно: новая конфигурация включается рядом со старой и откатывается переключением без пересборки сервиса.

Обсудим задачу: подготовим план и оценку

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

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

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