NVIDIA добавила в TensorRT 11.1 функцию Global Performance Tuner — автоматическую настройку производительности, которая перебирает варианты сборки движка под конкретную модель и условия эксплуатации. Об этом рассказали инженер NVIDIA Jian Hu и старший продакт-менеджер Lin Chai в первой части цикла о новом инструменте. Суть новости проста: вместо одной универсальной стратегии планировщика TensorRT получает набор настраиваемых маршрутов сборки, из которых выбирается самый быстрый движок, укладывающийся в допуск по точности.
Почему одной стратегии сборки мало
Сборка движка TensorRT — это не перевод каждого оператора в GPU-ядро, а задача компиляции со множеством допустимых ответов. При построении движка TensorRT принимает взаимозависимые решения о преобразованиях графа, слиянии операций, выборе реализаций, размещении памяти и квантовании. Этот процесс называется планированием (scheduling). Разные решения сохраняют семантику модели, но дают очень разную скорость инференса.
Единой лучшей стратегии не существует. Преобразование, ускоряющее одну сеть, может замедлить другую. Ядро, быстрое само по себе, может плохо взаимодействовать со слиянием, раскладкой тензоров или трафиком памяти в другом месте графа. Агрессивное планирование ускоряет работу, но нарушает требования приложения к точности. Все эти эффекты обычно видны только после полной сборки движка и замера.
Раньше оптимизация TensorRT опиралась на внутренние KPI-модели: инженеры изучали нагрузки и зашивали находки в эвристики стандартной стратегии. С расширением парка моделей и платформ такой подход упирается в три проблемы:
- разрастание эвристик — каждая новая модель добавляет правило, взаимодействие которого с прежними нужно понимать и поддерживать, а улучшение для одного семейства моделей незаметно бьёт по другому;
- сцепка производительности и точности — ядра пониженной точности ускоряют работу, но вносят численные расхождения выше допустимого порога, а более точные варианты жертвуют скоростью;
- сложность кастомизации — удачный выбор для одной модели или GPU может не подойти для другой, а зашить все удачные решения в одну универсальную стратегию невозможно.
Тюнинг предлагается как масштабируемое дополнение к эвристикам.
Три принципа Global Performance Tuner
NVIDIA описывает компиляцию как пару алгоритмов: builder algorithm (планировщик производительности) порождает множество кандидатов, а searching algorithm (решатель) выбирает среди них. Builder отображает пространство моделей в множество решений, удовлетворяющих допуску точности ε, а решатель берёт решение с минимальным временем выполнения.
Проблема в том, что идеальный решатель не спасёт, если builder не породил нужного кандидата. Поэтому вместо попытки построить идеальный builder сразу NVIDIA предлагает постепенно расширять доступные маршруты сборки. Отсюда три принципа, на которых держится Global Performance Tuner:
- Тюнинг с учётом точности — сквозная точность служит ограничением, которое направляет оптимизацию производительности.
- Настраиваемый маршрут сборки — планирование адаптируется под каждую модель и среду развёртывания.
- Большое пространство решений — строится богатое множество допустимых решений, из которого выбирается самый быстрый кандидат, чьё численное расхождение остаётся в заданном допуске.
Формально инструмент описывается так: есть семейство маршрутов сборки B = {B₁, B₂, …, Bₙ}, и итоговое решение выбирается как s* = A(B₁(m) ∪ B₂(m) ∪ ⋯ ∪ Bₙ(m)). Для каждого кандидата проверяются выходы по критерию точности и замеряется сквозная производительность инференса.
Аналогия с шеф-поваром и специями
Авторы объясняют мотивацию через кулинарную метафору. У шеф-повара есть блюдо, которое годами устраивало трёх постоянных клиентов: один любит острое, второй — кисло-сладкое, третий — посолонее. Повар смешивает перец чили, сироп, лимон и соль в одном стандартном рецепте. Приходит четвёртый клиент, не переносящий острое: оставить чили — расстроить новичка, убрать — рискнуть первым клиентом.
Корень проблемы в том, что способ добавления приправ не масштабируется: число взаимодействующих исключений растёт вместе с клиентской базой. Масштабируемый подход сохраняет базовое блюдо, но делает приправы настраиваемыми: повар записывает подходящую комбинацию для каждого постоянного клиента, а новому предлагает пробы разных вариантов, отбрасывает неподходящие и оставляет лучший.
В этой аналогии TensorRT — повар, общий конвейер — базовый рецепт, настраиваемые конфигурации компилятора — приправы, собранный движок — готовое блюдо, каждая ONNX-модель — клиент, а сквозная производительность — удовлетворённость клиента.
Что это даёт на практике
Важно понимать границы модели: в реальном TensorRT генерация кандидатов, отсев, профилирование и выбор тесно связаны, и граница между builder и решателем в архитектуре компилятора может быть неявной. Кроме того, решатель в реальности может выбрать субоптимальное решение — как минимум по двум причинам. Эвристика может отбросить кандидата до того, как его оценят в составе полного движка: например, builder отфильтрует тактики свёртки по порогу размерности канала в определённом слое, и если отфильтрованная тактика участвовала бы в самом быстром сквозном решении, найти его уже не получится.
Вторая причина — расхождение между локальным профилированием и сквозным исполнением. При сборке ядра-кандидаты могут профилироваться по отдельности, а при инференсе производительность измеряется по всему движку. Ядро в изоляции и оно же в составе большого графа работают не в идентичной среде — авторы приводят в пример адаптивный подбор размера сетки в GPU NVIDIA Blackwell. Поэтому сумма времён отдельных ядер не обязательно равна сквозному времени выполнения.
Для администратора, который держит инференс на TensorRT, это означает сдвиг в сторону замеров на своей модели: документация Global Performance Tuner описывает саму функцию и её параметры конфигурации, а алгоритм, архитектура и лучшие практики разобраны во второй части цикла. Смежные материалы по инференсу на GPU есть в разборе TensorRT multi-device в Dynamo-Triton, а про оркестрацию GPU в кластере — в статье об открытой платформе NVIDIA Run:ai.
Частые вопросы
Что именно появилось в TensorRT 11.1?
Функция Global Performance Tuner — автоматическая настройка производительности, которая перебирает настраиваемые маршруты сборки и выбирает самый быстрый движок, укладывающийся в допуск по точности.
Чем это отличается от прежней оптимизации TensorRT?
Раньше улучшения зашивались в эвристики стандартной стратегии на основе внутренних KPI-моделей. Теперь маршруты сборки можно настраивать под конкретную модель и среду развёртывания, а не полагаться на одну универсальную стратегию.
Как учитывается точность модели?
Сквозная точность выступает ограничением: каждый кандидат проверяется по критерию точности ε, и среди прошедших выбирается решение с минимальным временем выполнения.
Что такое маршрут сборки?
Это последовательность проходов компилятора, преобразующих модель в решение; формально builder algorithm описывается как композиция функций f₀…fₖ₋₁. Настраиваемый маршрут позволяет менять решения планировщика под модель.
Почему быстрый движок не гарантирован?
Решатель может выбрать субоптимальный вариант: эвристика способна отбросить кандидата до полной оценки, а сумма времён отдельных ядер не равна сквозному времени из-за различий в среде исполнения.
Где искать инструкции по настройке?
В документации Global Performance Tuner описаны функция и её параметры конфигурации; алгоритм, архитектура и лучшие практики разобраны во второй части серии.
Нужно ли пересобирать движки после обновления?
В статье об этом не говорится. Авторы лишь отмечают, что без замера полного движка эффект от планирования предсказать трудно, поэтому проверять результат стоит на своей модели.
Кого касается новость?
Тех, кто собирает и эксплуатирует инференс-движки на TensorRT: инженеров по производительности и администраторов, обслуживающих GPU-инференс.
Источник: developer.nvidia.com