Модель, що досягає найсучаснішої точності на тестовому наборі, автоматично не кваліфікується для польового розгортання. Дослідницькі моделі навчаються та оцінюються на GPU-кластерах з рясною пам'яттю та обчислювальними ресурсами. Розгорнуті моделі повинні працювати на периферійному обладнанні зі суворими бюджетами потужності, обмеженою пам'яттю та вимогами до затримки в реальному часі. ONNX та TensorRT — дві ключові технології в конвеєрі оптимізації моделей для розгортання на Jetson.

Розрив між навчанням та інференсом

Типова дослідницька модель існує як PyTorch state dict або TensorFlow SavedModel — колекція навчених ваг та визначення графу обчислень. Запуск дослідницької моделі в PyTorch на NVIDIA Jetson Orin NX без оптимізації забезпечує інференс приблизно 8–15 кадрів/с для моделі середньої складності — значно нижче цільових 30 кадрів/с для відеоаналізу в реальному часі. Три джерела цього розриву: надмірні витрати пам'яті (стан оптимізатора, буфери градієнтів), витрати обчислень (динамічні графи) та невідповідність точності (FP32 проти INT8).

ONNX як universal interchange: експорт з PyTorch

ONNX визначає стандартне графове представлення архітектур нейронних мереж, незалежне від будь-якого конкретного фреймворку навчання. Функція `torch.onnx.export` трасує граф обчислень моделі, запускаючи її з прикладними вхідними тензорами. Ключові параметри: opset_version (версія набору операторів ONNX — використовуйте opset 16 або 17 для максимального покриття з поточним TensorRT); dynamic_axes (вимір пакету повинен бути динамічним для підтримки як одноінференсного, так і пакетного виконання).

Поширені підводні камені. Не всі операції PyTorch мають прямі еквіваленти ONNX. Голівка NMS для виявлення YOLOv8 є найбільш поширеною проблемною зоною — Ultralytics надає прапорці конфігурації експорту для використання ONNX-сумісних реалізацій NMS. Завжди перевіряйте експортовану модель ONNX на репрезентативному тестовому наборі перед тим, як переходити до компіляції TensorRT.

Компіляція TensorRT: INT8 калібрування, злиття шарів, автоналаштування ядра

TensorRT приймає модель ONNX як вхід і виробляє файл движка TensorRT, оптимізований для конкретної цільової GPU-архітектури. Процес компіляції має три етапи: (1) Парсинг мережі та валідація; (2) Оптимізаційні прогони — TensorRT застосовує злиття шарів, оптимізацію розташування тензорів та заміну операторів; (3) Калібрування точності та компіляція движка — для компіляції INT8 TensorRT запускає процедуру калібрування на 500–1 000 зображень.

Затримка проти пропускної здатності: розмір пакету 1 для інференсу в реальному часі

При розмірі пакету 1 YOLOv8-medium, скомпільований до INT8 на Jetson AGX Orin, працює при приблизно 1,8 мс затримки (555 кадрів/с теоретичний максимум). Для чотирикамерної системи з кожною при 30 кадрах/с, розмір пакету 4 дозволяє одночасну обробку одного кадру з кожного потоку камери приблизно за 5 мс.

Ключовий висновок: Файли рушія TensorRT не є портативними між GPU-архітектурами. Будуйте конвеєр оптимізації для компіляції рушіїв на цільовому класі пристроїв (або ідентичному пристрої). Спроба запустити рушій на пристрої, відмінному від компіляційного, може спричинити помилки або тихе зниження точності.

Версіонування моделей та конвеєр оновлень для польових пристроїв

Оновлення конвеєру для моделей, розгорнутих з TensorRT: нова модель навчається в центральному об'єкті → експортується до ONNX → ONNX-модель надсилається на пристрій через захищений канал → компіляція TensorRT виконується на пристрої → скомпільований рушій активується → старий рушій архівується для відкату. Кожна версія моделі ONNX повинна містити семантичний ідентифікатор версії, хеш SHA-256 та криптографічний підпис.