На демонстрации нейросеть мгновенно находит царапину на детали. На производственной линии та же модель начинает пропускать изделия: изображение ещё обрабатывается, а объект уже прошёл точку, где его можно отделить. Причина может быть не в точности распознавания. Камера, декодирование, очередь запросов и передача результата вместе создают задержку, которую красивый ролик не показывает.
Это касается не только промышленности. Робот, сортировщик или система подсчёта посетителей получает пользу от модели, когда результат приходит вовремя. Разберём условный проект с четырьмя камерами и уже обученной нейросетью. Числа ниже — пример расчёта и испытаний, а не характеристики конкретного сервера или готового продукта.
Обучение модели и её применение — разные нагрузки
При обучении система подбирает параметры по набору примеров. При инференсе использует готовые параметры для обработки нового изображения. Поэтому требование «нужен сервер для искусственного интеллекта» слишком неопределённо: нужно указать модель, разрешение входа, число потоков и допустимую задержку. Инфраструктура для периодического обучения и для непрерывного распознавания может различаться.
Если проект предполагает собственный вычислительный узел, варианты HPE ProLiant можно сравнить в каталоге: https://servermall.ru/sets/servery-hp-proliant/. Поддержку ускорителей проверяют по конкретной модели и сборке. Например, QuickSpecs HPE ProLiant DL380 Gen11 содержат отдельные требования к GPU, вентиляторам и кабелям питания. Свободный слот PCIe сам по себе не означает готовность сервера принять любую видеокарту.
Считать нужно время всей цепочки
Условный бюджет одного кадра: получение и декодирование — 12 мс, изменение размера и подготовка — 8 мс, работа модели — 25 мс, обработка ответа — 5 мс, передача результата — 10 мс. Суммарно получается 60 мс без ожидания в очереди. Если измерить только нейросеть, отчёт покажет 25 мс и существенно недооценит реальную задержку.
Для движущегося объекта это имеет физический смысл. При скорости ленты 0,8 м/с за 60 мс изделие переместится на 4,8 см. Если очередь добавит 100 мс, суммарное перемещение составит уже 12,8 см. Допустимый интервал определяют по расположению камеры и исполнительного устройства, а не по абстрактному требованию «работать в реальном времени».
Метки времени должны позволять связать кадр с результатом. Для измерения внутри одного процесса используют подходящий монотонный таймер. При сравнении событий разных устройств учитывают синхронизацию часов. Нельзя вычесть два несогласованных времени и принять разницу за задержку системы.
Кадры в секунду не гарантируют быстрый ответ
Пусть четыре камеры передают на анализ по десять кадров в секунду. Входящая нагрузка равна 40 кадрам в секунду. Если стенд устойчиво обрабатывает только 32, очередь будет расти примерно на восемь кадров каждую секунду. За минуту накопится около 480 необработанных кадров, если система ничего не отбрасывает и нагрузка постоянна.
В такой ситуации недостаточно увеличить размер очереди. Память позволит хранить больше кадров, но результат будет приходить всё позже. Для задачи подсчёта можно выбрать обработку свежего кадра с пропуском промежуточных. Для контроля каждого изделия такой подход может быть неприемлем: необходимо изменить производительность или способ съёмки.
Групповая обработка изображений иногда увеличивает пропускную способность, но требует времени на накопление группы. В пилоте измеряют отдельно число обработанных кадров в секунду и задержку каждого ответа. Оптимизация одного показателя может ухудшить другой, поэтому нужны оба критерия.
Проверить, где действительно выполняются вычисления
Настройка приложения «использовать GPU» ещё не доказывает, что весь расчёт идёт на ускорителе. Часть операций может выполняться на процессоре, а передача данных — занимать заметное время. Проверяют выбранный вычислительный backend, поддерживаемые операции и профиль выполнения конкретной модели.
Документация ONNX Runtime описывает настройку потоков и особенности многопроцессорных NUMA-систем. Большое число потоков не всегда даёт лучший результат: совместная работа через разные узлы памяти может увеличить накладные расходы. Полезно сравнить несколько настроек на одном наборе кадров, не меняя одновременно модель и входное разрешение.
В журнал испытания включают версию модели, движка, драйверов и параметры обработки. Без этого «стало быстрее» трудно воспроизвести. После обновления библиотек тест повторяют: скорость и распределение операций между устройствами могут измениться, даже если файл модели остался прежним.
Память и сеть тоже участвуют в распознавании
Один несжатый RGB-кадр 1920 × 1080 при трёх байтах на пиксель занимает 6 220 800 байт, около 6,22 МБ. Для 40 кадров в секунду это примерно 249 МБ/с данных в таком представлении. Это не оценка сетевого трафика камеры: сжатый видеопоток может быть значительно меньше, но после декодирования в памяти появляются большие изображения.
У приложения могут одновременно существовать исходный кадр, уменьшенная копия и тензор модели. Если тензор хранит три канала в float32, объём отличается от трёхбайтового RGB. Поэтому память оценивают по фактическому процессу с очередями и параллельными запросами, а не только по размеру файла нейросети.
На сервере дополнительно могут работать запись видео, интерфейс оператора и база событий. Их проверяют вместе с распознаванием. Отдельный удачный запуск модели не показывает, что система сохранит скорость при одновременной записи архива и просмотре результатов.
Точность проверяют на условиях, а не на красивых примерах
В тестовый набор включают разные смены освещения, блики, загрязнение объектива, положение объекта и редкие дефекты. Материалы для приёмки отделяют от обучающих примеров. Иначе система может выглядеть убедительно именно потому, что уже видела эти изображения при подготовке.
Для условной выборки из 1 000 изделий, среди которых 50 дефектных, модель обнаружила 45 дефектов и ошибочно отклонила 20 исправных. Полнота обнаружения дефектов равна 45 / 50 = 90%, а точность положительных срабатываний — 45 / 65 ≈ 69,2%. Одна общая доля верных ответов скрыла бы разницу между пропущенным браком и лишней отбраковкой.
Порог срабатывания выбирают с учётом последствий обеих ошибок. Для дорогой проверки ложные тревоги увеличивают ручную работу, а пропущенный дефект может иметь другую цену. Выбранный порог фиксируют вместе с условиями испытаний. Его нельзя незаметно менять только ради улучшения одного показателя в отчёте.
Испытание должно охватывать пики и отказные сценарии
Сначала запускают один поток, затем плановое число камер и только после этого добавляют согласованный запас нагрузки. Тест должен включать длительную работу и реальные фоновые задачи. Первые секунды после запуска и прогретый режим измеряют отдельно: средняя цифра за короткий фрагмент может не описывать начало смены.
- Фиксируют медиану задержки и высокий перцентиль, например p95.
- Считают потерянные кадры, тайм-ауты и рост очереди.
- Проверяют восстановление соединения после краткого отключения камеры.
- Убеждаются, что устаревший ответ не относится к следующему изделию.
Перцентиль p95 показывает границу, ниже которой лежат примерно 95% измеренных задержек. Но оставшиеся 5% тоже могут быть важны. Для ответственного процесса дополнительно определяют предельный срок и допустимое число опозданий. Серверная система распознавания не должна самостоятельно подменять предусмотренные средства безопасного управления оборудованием.
Практический итог пилота — согласованные показатели точности, скорости и поведения при сбое, а также протокол на конечной конфигурации. Он отвечает на вопрос, успевает ли система решать задачу. Только после этого имеет смысл выбирать сервер, ускоритель и запас ресурсов: по проверенному процессу, а не по слову «ИИ» на презентации.
