Бюджет FPS многопоточного узла 

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

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

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

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

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

паспортная

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

синтетическая

результат прогона утилиты производителя на заранее подготовленном буфере в памяти. Ближе к реальности, чем паспортная, но входные данные лежат готовыми, а конкурентов за шину нет.

пиковая сквозная

то, что показывает демонстрационный ролик: холодный узел, одна камера, минута работы. Самое частое число в коммерческих предложениях и самое бесполезное в проектировании.

устойчивая сквозная

то же самое после теплового выхода на режим, на сцене с реальной сложностью и с полным конвейером. Ниже пиковой на десятки процентов, и именно она должна попадать в договор.

частота источника

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

детекционная

сколько раз в секунду по каждому потоку реально вызывается детектор. При децимации в два раза она вдвое ниже частоты источника, и на качество слежения это влияет куда меньше, чем принято думать.

полезная (goodput)

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

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

Узел, о котором идет речь, — Raspberry Pi 5 с модулем ускорителя на Hailo-8L, подключенным по единственной линии PCIe. Это та же связка, на которой собран детектор малоразмерных целей направления Falcon Eye, и та же, которую мы предлагаем заказчикам как нижнюю ступень линейки. Ее паспортные свойства опубликованы и проверяемы, поэтому начинать надо с них.

Из этой таблицы сразу следуют три вещи, которые дальше будут работать как ограничения модели. Первое: ускоритель один. Сколько бы потоков ни пришло, они выстроятся в общую очередь к одному устройству, и это очередь с последовательным обслуживанием — глава 11 показывает, чем такая очередь отличается от четырех независимых. Второе: линия PCIe одна, и через нее в обе стороны едут граничные тензоры каждого кадра — глава 9 считает, сколько это в мегабайтах в секунду и когда упирается. Третье: тепловой контур общий. Ядра, ускоритель и накопитель греют один и тот же объем воздуха внутри корпуса, а порог снижения частоты назначен производителем и понижается пользователем, но не повышается ^[40].

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

На живом железе мы этот узел уже мерили. Сборка детектора БПЛА под Hailo-8L дала 80–90 кадров в секунду при целевом профиле 60 — то есть профиль был перекрыт с запасом. Замер стендовый: одна камера, узел на столе. Эта цифра опубликована на странице направления Falcon Eye и используется в коммерческих разговорах как ориентир.

Теперь неприятная часть, с которой и начинается настоящая работа. В журнале направления зафиксирована сама цифра и профиль сборки, но не полный набор условий: сколько длилось окно измерения, какая была температура кристалла к его концу, входило ли в измеряемый интервал декодирование, считался ли постпроцессинг, какой был режим линии PCIe. Для ответа на вопрос «перекрыли ли мы шестьдесят» этого достаточно. Для ответа на вопрос «сколько камер поместится на объекте» — нет: неизвестно, какую именно из семи величин главы 2 мы измерили.

Второй источник собственных данных — отчет компилятора Hailo по нашей сборке. Он устроен подробнее, чем принято думать: для сети YOLO11n в разрешении 640×640 под Hailo-8L он дает разложение на пять контекстов, время каждого, объемы граничных и межконтекстных тензоров, коэффициенты использования вычислительных блоков и распределение весов по уровням памяти. Из него считается верхняя граница производительности ускорителя — 315 кадров в секунду, и он же показывает, что загрузка умножителей в среднем по контекстам держится около 0,11 от пиковой. Разбору этого отчета посвящена глава 12: разрыв между 315 и 90 — самая содержательная величина во всей работе, потому что он весь состоит из вещей, за которые платит заказчик.

Работа дальше устроена так. Часть II разбирает конвейер по стадиям и показывает, где именно расходуется время и какой ресурс каждая стадия занимает. Часть III дает аппарат: закон Литтла, универсальный закон масштабируемости, формулу Кингмана и тепловую RC-модель — этого хватает, чтобы предсказать поведение узла на N потоках. Часть IV собирает из этого модель бюджета и считает предсказания для одного, двух, четырех и восьми потоков. Часть V — протокол суточного замера с кодом стенда, который эти предсказания проверит или опровергнет. Часть VI переводит результат в смету. Часть VII перечисляет границы и то, что мы обязуемся опубликовать после прогона, включая случай, когда модель окажется неверной.

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

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

Отсюда же — рабочий метод поиска узкого места, известный как USE: для каждого ресурса смотреть загрузку, насыщение и ошибки, а не искать «медленный код» ^[72]. На нашем узле ресурсов ровно четыре: ядра, аппаратный декодер, линия PCIe и ускоритель. Пятым ограничением работает тепловой контур, который не является ресурсом в обычном смысле, но ведет себя как ресурс с медленной обратной связью, — ему посвящена глава 15.

Видеопоток приходит по RTSP поверх RTP ^{[32, 33, 34]}. На уровне протокола кадр — это несколько пакетов, собираемых в единицу доступа; на уровне сети между камерой и узлом стоят коммутатор, иногда радиомост, иногда чужой канал с чужим трафиком. Даже если камера отдает строго по таймеру, до узла кадры доезжают с джиттером, а на загруженном канале — группами.

Отсюда два практических следствия. Первое: приемный буфер обязан быть, и его глубина — проектный параметр, а не значение по умолчанию из библиотеки. Второе: буфер не может быть большим. Раздутые буферы дают ровно тот эффект, который в сетях описан как bufferbloat ^[25]: очередь перестает терять пакеты, но начинает копить задержку, и система, формально не потерявшая ни кадра, выдает события с секундным опозданием. Для видеоаналитики это хуже потери: пропущенный кадр незаметен, а событие, пришедшее через полторы секунды после того, как человек прошел через зону, обесценивает систему.

Третье следствие — про измерения. Счетчик кадров на входе конвейера меряет камеру, а не узел. Если камера отдает 25 к/с, а узел успевает 12, вход все равно покажет 25: разница уйдет в потери на следующей стадии. Поэтому в протоколе части V точка съема частоты стоит на выходе конвейера, а на входе считается только приход и потери.

В BCM2712 остался единственный аппаратный декодер — HEVC до 4Kp60. Блоков для H.264 на кристалле нет ^[41]. Логика производителя понятна и в целом верна: четыре ядра A76 разбирают H.264 быстрее, чем это делал старый аппаратный блок предыдущего поколения. Для настольного применения это улучшение. Для узла видеоаналитики с восемью камерами — смена статьи расходов: работа, которая раньше выполнялась бесплатно с точки зрения процессора, теперь конкурирует за те же ядра, на которых живут препроцессинг, трекер и бизнес-логика.

Цена декодирования зависит от кодека, разрешения, битрейта и структуры группы кадров. Ключевая асимметрия: опорный кадр стоит в несколько раз дороже предсказанного, поскольку декодируется целиком, без опоры на предыдущий ^{[35, 38]}. При типовой структуре с опорным кадром раз в две секунды это означает регулярный всплеск нагрузки на всех камерах сразу — и всплески эти не синхронизированы между потоками, что дает именно тот рваный профиль, который разбирается в главе 13.

Отдельная ловушка — «просто включить аппаратное ускорение». На узле без аппаратного декодера H.264 попытка запросить его через стандартный интерфейс ядра приводит либо к ошибке, либо к молчаливому откату на программный путь. Второй вариант опаснее: система работает, ядра загружены, а инженер уверен, что декодирование ничего не стоит. Протокол в части V проверяет это явно — сравнением загрузки ядер при пустом конвейере и при конвейере без инференса.

Между декодером и ускорителем кадр меняет форму. Декодер отдает изображение в планарном формате с субдискретизацией цвета, детектор ждет тензор фиксированного размера в своем порядке каналов и своем диапазоне значений. Между этими двумя состояниями стоят: приведение цветового пространства, масштабирование с сохранением пропорций и дополнением полями, нормализация и укладка в непрерывный буфер, пригодный для передачи по шине.

Каждая операция сама по себе дешевая, но их три, и каждая — это проход по памяти объемом в мегабайты. Кадр 1080p в планарном формате занимает около 3 МБ, целевой тензор 640×640×3 — 1,23 МБ. Наивная реализация делает три полные копии на кадр; при восьми потоках по 25 к/с это порядка гигабайта в секунду трафика к памяти на одном только препроцессинге. Ядра при этом заняты не вычислениями, а ожиданием памяти — ситуация, которую хорошо описывает крышевая модель ^[23]: операционная интенсивность у таких стадий низкая, и упираются они в полосу, а не в арифметику.

Ускоритель подключен одной линией PCIe. По ней в каждую сторону едут граничные тензоры: на вход — подготовленное изображение, на выход — карты признаков головы детектора. Для нашей сборки отчет компилятора дает точные числа: 1 228 800 байт входа (это ровно 640×640×3) и 1 092 000 байт выхода. В сумме 2,32 МБ на каждую детекцию.

Эффективная пропускная способность заметно ниже номинальной: на нее влияют кодирование физического уровня, размер полезной нагрузки транзакции и поведение конкретного контроллера — измерения на реальных системах показывают потери порядка десятков процентов от теоретического потолка ^[48]. Для оценок берем консервативные значения: около 400 МБ/с для режима Gen 2 и около 800 МБ/с для Gen 3 ^[47]. При наших размерах тензоров это дает потолок примерно 170 детекций в секунду на Gen 2 и около 345 на Gen 3 — независимо от того, сколько камер их создают.

После ускорителя работа не заканчивается. Выходы головы детектора надо превратить в рамки, отсеять перекрывающиеся, связать с существующими треками, применить правила (зона, направление, длительность), при срабатывании записать клип и отправить событие. Все это исполняют те же четыре ядра.

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

Трекер — вторая по значимости статья. Классическая связка «фильтр Калмана плюс венгерский алгоритм» ^{[56, 59]} стоит доли миллисекунды на кадр при десятке целей и растет квадратично по числу объектов в кадре; варианты с ассоциацией по внешнему виду ^[57] дороже на порядок, потому что тянут собственную сеть. Для наших задач существенно другое: именно трекер позволяет вызывать детектор не на каждом кадре, и поэтому он не расход, а рычаг экономии — количественно это разобрано в главе 17.

• Запись клипов на карту памяти: пиковые задержки записи блокируют поток, если запись идет синхронно в том же потоке исполнения.
• Отправка событий по сети: таймаут недоступного сервера обязан быть коротким, иначе конвейер встает из-за чужой инфраструктуры.
• Журналирование: подробный лог на каждый кадр — это не только диск, но и блокировки; на восьми потоках он становится заметной статьей.
• Служебные процессы: обновления, мониторинг, сторожевой таймер — фон, который в пятиминутном замере не виден, а в суточном виден.

Закон Литтла связывает три величины в любой системе, которая работает в установившемся режиме: среднее число заявок внутри, интенсивность их прихода и среднее время пребывания ^{[1, 2]}. Он не требует никаких предположений о распределениях, дисциплине очереди и внутреннем устройстве — только стационарности.

Второе соотношение — закон загрузки: загрузка ресурса равна произведению пропускной способности системы на требование к этому ресурсу на одну заявку ^{[13, 14]}. Третье — закон узкого места: пропускная способность системы не может превысить обратную величину наибольшего требования.

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

Hailo-8L устроен иначе, чем графический ускоритель. Это не универсальный процессор с внешней памятью, а массив вычислительных блоков с распределенной памятью на кристалле; внешней DRAM у него нет вовсе ^{[44, 45]}. Компилятор раскладывает сеть по этому массиву статически: каждый слой получает свои умножители и свои куски памяти под веса и промежуточные данные. Если сеть целиком не помещается, она режется на контексты, которые проходят через чип последовательно.

Разрыв в три с половиной раза — самая содержательная величина в этой работе. Он складывается из вещей, которых нет в отчете компилятора, и каждая из них проверяема на стенде.

• Хост-часть кадра: декодирование, приведение формата, укладка тензора, разбор выходов. Это процессорное время, которое в отчете компилятора не учитывается вовсе.
• Передача по шине: 2,32 МБ на кадр в обе стороны, плюс накладные расходы протокола и задержки на инициацию транзакций ^[48].
• Переключение контекстов: сборка на пять контекстов проходит через чип пятью фазами, и на каждой границе есть служебная работа. Ее величина нам неизвестна — это гипотеза H2.
• Синхронный режим работы: при глубине очереди в один кадр ускоритель простаивает, пока хост готовит следующий тензор, а хост ждет, пока ускоритель досчитает текущий. Классическая потеря на конвейеризации, лечится асинхронной подачей.
• Условия замера: неизвестно, что именно входило в измеряемый интервал и в каком тепловом состоянии находился узел (глава 4).

Отчет компилятора добавляет к этому еще один факт, важный для интуиции. Средняя загрузка умножителей по контекстам в нашей сборке — около 0,11 от пиковой, при том что «активная» загрузка внутри работающих блоков держится на уровне 0,75. Это означает, что паспортные тринадцать триллионов операций в секунду для этой сети недостижимы принципиально: сеть с малым числом каналов на ранних слоях не заполняет массив целиком. То же самое на других архитектурах ускорителей описано в разборах матричных блоков: пиковая производительность достигается только на задачах с высокой операционной интенсивностью, а детекторы малых объектов к ним не относятся ^{[23, 54]}.

Отдельно про межконтекстный трафик. Отчет дает 2 944 800 байт на кадр между контекстами при нулевом числе портов внешней памяти. То есть эти данные остаются внутри чипа и шину не занимают — важное уточнение, потому что интуитивно кажется наоборот. Наружу едут только граничные тензоры, и именно они входят в расчет потолка по шине в главе 9.

Наконец, про несколько потоков на одном ускорителе. Среда исполнения производителя умеет обслуживать несколько моделей и несколько процессов на одном устройстве, распределяя время планировщиком с круговой дисциплиной и настраиваемыми приоритетами и размерами пакета ^[46]. Это удобно и это же означает, что при N потоках устройство остается единственным сервером: заявки выстраиваются в очередь, а не выполняются параллельно. Все следствия этого разбираются в двух следующих главах.

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

Когда потоков много и их фазы независимы, суммарный поток заявок к общему ускорителю перестает быть равномерным. Классический результат теории потоков — теорема Пальма — Хинчина: суперпозиция большого числа независимых редких потоков сходится к пуассоновскому ^{[4, 5]}. Пуассоновский поток — это поток с пачками: интервалы распределены экспоненциально, коэффициент вариации равен единице, и заявки регулярно приходят группами.

Количественно переход описывается приближением для коэффициента вариации объединенного потока: он линейно интерполирует между вариацией отдельного источника и единицей по мере роста числа источников ^{[7, 8]}.

Вопрос «в какой момент начинают теряться кадры» имеет неприятный ответ: обычно заметно раньше, чем спрос сравняется с пропускной способностью, и не в виде потерь, а в виде задержки. Универсальное приближение для системы общего вида — формула Кингмана ^[3].

Для частного случая с детерминированным обслуживанием и пуассоновским входом есть точный результат Полячека — Хинчина, и он же дает нижнюю границу того, что вообще достижимо при ровном сервере ^{[4, 6]}.

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

Отдельно о дисперсии времени обслуживания. Сам по себе инференс на ускорителе — операция с очень стабильным временем, и это большая удача. Но реальное обслуживание включает подготовку тензора и разбор выходов на процессоре, а они конкурируют с декодированием. При загрузке 0,97 рост коэффициента вариации обслуживания с нуля до 0,35 поднимает расчетную p99 с 49 до 121 мс — то есть дисперсия, наведенная процессорной частью, портит показатель сильнее, чем сам ускоритель.

Процессорная часть конвейера параллелится по четырем ядрам, но не линейно. Классика вопроса — закон Амдала: доля последовательной работы ограничивает ускорение сверху независимо от числа исполнителей ^[9]. Возражение Густафсона тоже уместно: при росте объема задачи доля последовательной части падает, и практический выигрыш выше пессимистичной оценки ^[10]. Для нашей задачи обе модели неполны, потому что не учитывают главного — издержек на согласование.

Кремний греется, корпус мешает теплу уходить, прошивка снижает частоту при достижении порога. На Raspberry Pi 5 пороги названы прямо: с 80 °C ядра начинают прогрессивно замедляться, с 85 °C ограничение становится жестким и распространяется на графику ^[40]. Ускоритель при этом продолжает работать в своем режиме, но данные ему готовит уже замедленный процессор — и весь конвейер едет вниз.

Тепловое поведение узла описывается одноемкостной моделью — тем же аппаратом, что используется в тепловом моделировании процессоров, только на уровне всего изделия ^{[49, 50]}. Мощность создает превышение температуры над средой, пропорциональное тепловому сопротивлению; теплоемкость определяет, за какое время это превышение устанавливается.

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

Каждый ресурс узла разрешает какое-то число камер. Разрешения независимы, считаются по отдельности и выражаются в одних и тех же единицах. Итоговое число камер равно минимальному из них — это прямое следствие закона узкого места (6).

Параметров в формуле семь, и это хорошая новость. Три берутся из документации (B_eff, C, пороги), два — из отчета компилятора (S_in, S_out), один — из живого замера прошлого года с оговорками главы 4 (t_npu), и ровно один неизвестен совсем — процессорная стоимость стадий t_dec, t_pre, t_post. Именно поэтому протокол части V начинается не с многопоточного прогона, а с раздельного измерения стадий на одном потоке: без этого модель имеет свободный параметр, а с ним — ни одного.

Подставим наши числа. Время инференса 11,1 мс — это обратная величина к верхней границе живого замера (90 к/с). Граничные тензоры 1,23 и 1,09 МБ. Ядер четыре, коэффициенты масштабирования взяты умеренными (α = 0,08, β = 0,008). Источники — 1080p при 25 к/с. Стоимость декодирования принята в 6 мс на кадр для программного H.264 и 1,2 мс для аппаратного H.265; обе цифры — оценки, подлежащие замеру.

Второй расчет — динамический: что произойдет с задержкой и потерями при разном числе потоков. Здесь работает дискретно-событийная модель из главы 14, в которую заложены независимые фазы источников и джиттер 12 % периода.

Третий расчет — под договорный порог задержки. Он отвечает на вопрос, который заказчик задает вторым: не «сколько камер», а «сколько камер при условии, что событие приходит не позже, чем через столько-то».

И последнее в этой главе — цена прогрева. Возьмем узел, спроектированный на шесть потоков с загрузкой 0,83, и дадим ему двадцатипроцентное замедление процессорной части, соответствующее уходу в мягкий троттлинг.

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

децимация

детектор вызывается на каждом k-м кадре, промежутки закрывает трекер. Эффект линейный по k и действует одновременно на ускоритель, шину, ядра (частично) и тепло. Стоимость — ноль рублей и несколько дней на подбор k. Ограничение обсуждается ниже.

смена кодека на камерах

перевод источников на H.265 переносит декодирование с ядер в аппаратный блок ^[41]. Эффект — только по процессорному потолку, зато большой. Стоимость нулевая, если решается до закупки камер, и высокая, если после.

суб-поток пониженного разрешения

детектору отдается второй поток камеры 1280×720 вместо 4K. Уменьшает и декодирование, и препроцессинг. Ограничение физическое: пикселей на цели должно остаться достаточно, и это проверяется метрикой, а не на глаз.

режим линии PCIe

перевод в Gen 3 удваивает потолок по шине ^{[43, 47]}. Стоит ничего, но помогает только тогда, когда шина действительно узкое место; по нашим расчетам это не наш случай, пока не выросло разрешение.

охлаждение

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

смена сборки детектора

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

Теперь про ограничение децимации, потому что бесплатных обедов не бывает. Пропуск кадров допустим ровно до тех пор, пока трекер способен связать положения цели между детекциями. Условие формулируется через смещение цели за интервал между вызовами детектора: оно должно оставаться меньше характерного размера цели, иначе ассоциация по перекрытию рамок разваливается ^{[56, 58]}.

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

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

goodput

число кадров, дошедших до логики решения, деленное на длительность окна. Снимается на выходе конвейера, отдельно по каждому потоку. Это и есть тот FPS, который идет в договор.

потери

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

задержка

распределение времени от метки источника до готового события. Фиксируются p50, p95, p99 и максимум. Среднее не фиксируется вовсе — оно скрывает ровно то, ради чего замер делается.

разложение по стадиям

время декодирования, препроцессинга, инференса и постобработки по отдельности. Это параметры D_r формулы (6), без них модель не замкнута.

температура и частоты

температура кристалла, текущая частота ядер, слово состояния троттлинга. Снимаются раз в секунду весь прогон, включая прогрев.

мощность

потребление узла под нагрузкой. Снимается по данным контроллера питания и сверяется с внешним измерителем хотя бы один раз — данные PMIC годятся для динамики, но не для абсолютной точности.

глубины очередей

мгновенная и максимальная длина каждой очереди. Показывает, где копится задержка, до того как начнутся потери.

загрузка ядер

по каждому ядру отдельно, вместе с временем ожидания ввода-вывода. Суммарная загрузка на четырех ядрах маскирует ситуацию «одно ядро в потолке, три простаивают», а она встречается чаще всего.

Матрица строится вокруг ряда 1, 2, 4, 8 потоков — из главы 15 понятно, зачем именно он: две точки задают конкуренцию, третья — издержки согласованности, четвертая проверяет модель. К ряду добавляются три бинарных фактора и один трехуровневый.

Длительность окна определяется двумя требованиями: тепловым и статистическим. Тепловое — прогон должен идти дольше трех постоянных времени, иначе измеряется не производительность, а теплоемкость корпуса (глава 16). При τ порядка пяти минут это минимум двадцать минут прогрева до начала окна.

• Холодный старт, узел в штатном корпусе, крышка закрыта, температура среды записана.
• Прогрев 20 минут под целевой нагрузкой; телеметрия пишется с первой секунды, она же дает кривую для оценки R_th и τ.
• Окно измерения 20 минут; в это время никаких действий по SSH, никаких сборок, никаких сторонних процессов.
• Три повтора каждой конфигурации, между повторами узел остывает до температуры среды плюс пять градусов.
• Контрольный прогон базовой конфигурации в конце дня: если он разошелся с утренним больше чем на 5 %, день признается недостоверным и повторяется.

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

#!/usr/bin/env bash
# Поднимаем N независимых RTSP-источников из одного клипа.
# Клип берем реальный, со сценой заказчика: синтетические градиенты
# сжимаются в разы лучше и занижают цену декодирования.
set -euo pipefail

N=${1:-8}                 # число потоков
CODEC=${2:-h264}          # h264 | hevc
CLIP=${3:-scene_1080p25.mp4}
GOP=50                    # опорный кадр раз в две секунды при 25 к/с
BITRATE=4M

# mediamtx слушает 8554 и раздает то, что мы в него публикуем
mediamtx &
sleep 2

for i in $(seq 1 "$N"); do
  # -re держит реальное время, -stream_loop -1 крутит клип бесконечно
  ffmpeg -hide_banner -loglevel error \
    -re -stream_loop -1 -i "$CLIP" \
    -c:v "$( [ "$CODEC" = hevc ] && echo libx265 || echo libx264 )" \
    -preset veryfast -tune zerolatency \
    -b:v "$BITRATE" -g "$GOP" -keyint_min "$GOP" -sc_threshold 0 \
    -an -f rtsp "rtsp://0.0.0.0:8554/cam$i" &
  sleep 0.37   # разводим фазы источников: см. главу 13
done
wait

#!/usr/bin/env bash
# Пишем состояние узла раз в секунду весь прогон, включая прогрев.
# Формат — CSV, потому что его читают и глазами, и скриптом.
set -euo pipefail
OUT=${1:-telemetry.csv}

echo "ts,temp_c,arm_hz,throttled,cpu_busy,mem_used_mb" > "$OUT"
while true; do
  TS=$(date +%s.%N)
  TEMP=$(vcgencmd measure_temp | tr -dc '0-9.')
  ARM=$(vcgencmd measure_clock arm | cut -d= -f2)
  # биты 0-3 — текущее состояние, 16-19 — было с момента загрузки
  THR=$(vcgencmd get_throttled | cut -d= -f2)
  CPU=$(awk '/^cpu /{u=$2+$4; t=$2+$4+$5; if (t>0) printf "%.3f", u/t}' /proc/stat)
  MEM=$(awk '/MemAvailable/{printf "%.0f", ($2)/1024}' /proc/meminfo)
  echo "$TS,$TEMP,$ARM,$THR,$CPU,$MEM" >> "$OUT"
  sleep 1
done

"""Замер сквозного конвейера: N потоков, общий ускоритель, честные метки времени.

Каждая стадия таймируется отдельно, каждая очередь имеет предел и счетчик потерь.
Результат — построчный CSV, по которому потом считаются квантили и разложение.
"""
import csv, queue, threading, time
from dataclasses import dataclass, field

QUEUE_DEPTH = 4          # кадров на поток; см. главу 14

@dataclass
class Counters:
    arrived: int = 0
    dropped_decode: int = 0
    dropped_infer: int = 0
    done: int = 0
    stage_ms: dict = field(default_factory=lambda: {"dec": [], "pre": [], "npu": [], "post": []})

def stream_worker(src, infer_q, counters, stop):
    """Один поток: приемка, декодирование, препроцессинг. Ядра тратятся здесь."""
    for frame in src:                     # источник отдает кадр с меткой t_src
        if stop.is_set():
            return
        counters.arrived += 1
        t0 = time.perf_counter()
        img = decode(frame)               # аппаратный блок или ядра — см. главу 7
        t1 = time.perf_counter()
        tensor = preprocess(img)          # масштаб, letterbox, укладка
        t2 = time.perf_counter()
        counters.stage_ms["dec"].append((t1 - t0) * 1e3)
        counters.stage_ms["pre"].append((t2 - t1) * 1e3)
        try:
            infer_q.put_nowait((frame.t_src, frame.stream_id, tensor))
        except queue.Full:
            counters.dropped_infer += 1   # очередь к ускорителю переполнена

def infer_worker(infer_q, counters, stop):
    """Единственный обслуживающий прибор: один ускоритель на все потоки."""
    while not stop.is_set():
        try:
            t_src, sid, tensor = infer_q.get(timeout=0.5)
        except queue.Empty:
            continue
        t2 = time.perf_counter()
        raw = infer(tensor)               # синхронный вызов среды исполнения
        t3 = time.perf_counter()
        events = postprocess(raw, sid)    # разбор выходов, трекер, правила
        t4 = time.perf_counter()
        counters.stage_ms["npu"].append((t3 - t2) * 1e3)
        counters.stage_ms["post"].append((t4 - t3) * 1e3)
        counters.done += 1
        writer.writerow([sid, t_src, t4, (t4 - t_src) * 1e3, len(events)])

# Запуск: по потоку на камеру плюс один обслуживающий поток на ускоритель.
# Второй обслуживающий поток тут не нужен и вреден: устройство одно, а лишний
# поток добавит только конкуренцию за очередь — это тот самый коэффициент beta
# из формулы (10).

"""Из сырых CSV — в параметры модели: alpha, beta, R_th, tau и таблица отчета."""
import numpy as np, pandas as pd

def quantiles(df):
    lat = df["latency_ms"].to_numpy()
    return dict(n=len(lat), p50=np.percentile(lat, 50),
                p95=np.percentile(lat, 95), p99=np.percentile(lat, 99),
                pmax=lat.max())

def fit_usl(n_workers, throughput):
    """USL (10) в линейной форме: (N/C - 1)/(N-1) = alpha + beta*N."""
    n = np.asarray(n_workers, float)
    c = np.asarray(throughput, float) / throughput[0]
    mask = n > 1
    y = (n[mask] / c[mask] - 1) / (n[mask] - 1)
    beta, alpha = np.polyfit(n[mask], y, 1)
    return alpha, beta, np.sqrt((1 - alpha) / beta) if beta > 0 else np.inf

def fit_thermal(t_s, temp_c, power_w, t_amb):
    """R_th и tau по кривой разогрева: dT = P*R*(1-exp(-t/tau))."""
    dt = temp_c - t_amb
    r_th = dt[-1] / power_w                       # установившееся превышение
    target = 0.632 * dt[-1]                       # уровень одной постоянной времени
    tau = t_s[np.argmax(dt >= target)]
    return r_th, tau

def verdict(row, p99_limit_ms, loss_limit=0.01):
    """Критерий отказа из главы 14: нарушен любой из двух — точка не засчитана."""
    return "ok" if row.p99 <= p99_limit_ms and row.loss <= loss_limit else "fail"

• Мерить холодным. Пять минут прогона попадают в левую часть тепловой кривой, где еще ничего не произошло. Смета живет в правой части (глава 16).
• Считать FPS на входе. Счетчик до очередей меряет камеру. Узел при этом может выбрасывать половину кадров, и цифра не изменится.
• Показывать среднюю задержку. Среднее прячет хвост, а событие опаздывает именно в хвосте ^[16].
• Мерить одну камеру и умножать на N. Из главы 13 следует, что суперпозиция потоков ведет себя хуже, чем масштабированный одиночный поток при той же средней нагрузке.
• Гонять синтетический клип. Градиенты и статичная картинка сжимаются в разы лучше реальной сцены, и декодирование выходит дешевле, чем будет на объекте.
• Забыть про структуру группы кадров. Разные прогоны с автоматическим выбором опорных кадров несравнимы между собой.
• Держать открытый корпус. Крышка меняет тепловое сопротивление, а с ним и устойчивую производительность — это разные изделия (глава 16).
• Работать по SSH во время окна. Компиляция, копирование или даже активная сессия занимают ядро, которого не хватит конвейеру.
• Не фиксировать режим линии PCIe. Половина потолка по шине зависит от одной строки конфигурации ^[43].
• Считать успехом отсутствие потерь. Нулевые потери при p99 в полторы секунды означают, что буфер слишком большой, а система уже неработоспособна ^[25].
• Сравнивать прогоны разной длины. Квантиль по тысяче кадров и по шестидесяти тысячам — величины разной надежности (17).
• Публиковать один прогон. Без повторов и без контрольной точки в конце дня результат неотличим от дрейфа стенда ^{[18, 20]}.

Отдельно про то, чего протокол сознательно не делает. Он не измеряет качество детекции: precision, recall и метрики трекинга ^{[60, 61]} снимаются на других данных и другой методикой, и смешивать эти два эксперимента нельзя. Он не сравнивает платформы между собой — это отдельная работа с отдельным бюджетом. И он не претендует на воспроизводимость чужими руками в чужом корпусе: тепловая часть результата привязана к конкретной механике, и это прямо сказано в границах.

Смета видеоаналитики складывается из вещей, которые растут по-разному. Часть пропорциональна числу камер (сама камера, монтаж, кабель), часть — числу узлов (вычислитель, ускоритель, корпус, питание, место в шкафу), часть постоянна (сервер событий, интеграция, обучение персонала). Число камер на узел определяет, как средняя часть размазывается по первой.

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

Второй вопрос экономики — запас. Проектировать узел в потолок нельзя: из главы 14 видно, что при загрузке выше 0,85 задержка растет быстрее линейного, а из главы 18 — что прогрев съедает пятую часть темпа. Разумная проектная точка — 0,7 по самому загруженному ресурсу в установившемся тепловом режиме.

Ответ «поставим второй узел» верен чаще, чем кажется, но не всегда. Ниже — четыре варианта с честным перечислением того, что каждый ломает.

больше узлов

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

ускоритель мощнее

вдвое более производительный модуль в том же форм-факторе снимает потолок ускорителя, но упирает систему в следующий по очереди — обычно в процессорный. Прирост числа камер получается меньше, чем прирост TOPS, и это надо считать заранее по формуле (15), а не после закупки.

каскад детекторов

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

агрегация на сервере

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

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

Последнее — формулировка обязательства. В договор идет не «система обрабатывает восемь камер», а конструкция из четырех величин: число потоков, частота детекции на поток, порог задержки p99 и допустимая доля потерь, — плюс условия, при которых это верно: разрешение, кодек, температура среды и тип корпуса. Такое обязательство проверяется приемочным прогоном по протоколу части V и защищает обе стороны: заказчик знает, что покупает, а подрядчик знает, за что отвечает.

• Один ускоритель. Вся часть III построена на том, что обслуживающий прибор один. Для узла с двумя ускорителями меняется структура очереди, и формулы (8), (9) надо переписывать под многоканальную систему ^[8].
• Постоянная стоимость кадра. Модель считает время инференса неизменным. Для каскадных схем и сетей с ранним выходом это неверно: время начинает зависеть от сцены, и вместо константы нужно распределение.
• Отсутствие конкуренции за память. При росте числа потоков конкуренция за полосу памяти растет нелинейно, и коэффициент β формулы (10) перестает быть константой. Ряд 1, 2, 4, 8 это поймает, а экстраполяция на 32 потока — нет.
• Одноемкостная тепловая модель. Реальный узел имеет как минимум три тепловые массы с разными постоянными времени. Для оценки времени до троттлинга и устойчивой мощности этого хватает, для точного предсказания температуры конкретной точки платы — нет ^[50].
• Стационарность нагрузки. Модель описывает установившийся режим. Проходная в час пик, ночная смена и пустой цех — три разные нагрузки, и проектировать надо по худшей, а не по средней.
• Качество детекции. Ни одна формула в работе ничего не говорит о том, найдет ли детектор цель. Бюджет FPS и метрики качества — независимые оси, и хороший результат по одной ничего не обещает по другой.

H1 · узкое место

На профиле 1080p25 с детекцией каждого кадра первым в потолок упирается ускоритель, а не ядра, шина или тепло. Закрывается положительно, если при N = 4 загрузка ускорителя выше 0,95, а остальные три ресурса ниже 0,8. Закрывается отрицательно, если хоть один другой ресурс достигает потолка раньше, — тогда переписывается глава 18 и меняются рекомендации по железу.

H2 · цена переключения контекстов

Разрыв между оценкой компилятора (315 к/с) и живым замером (80–90 к/с) более чем наполовину объясняется хост-частью и передачей по шине, а не служебной работой на границах контекстов. Закрывается положительно, если чистое время инференса, снятое утилитой производителя, окажется не более чем в 1,6 раза выше суммы времен контекстов. Если разрыв внутри самого ускорителя больше — значит, сборку надо перекомпилировать в меньшее число контекстов, и это отдельная работа с понятной ценой.

H3 · выравнивание фаз

Планировщик, выдающий заявки на ускоритель по собственному таймеру вместо факта прихода кадра, снижает p99 задержки при N = 8 не менее чем на 25 % при неизменной пропускной способности. Основание — глава 13 и формула (7). Закрывается отрицательно, если выигрыш меньше 10 %: тогда суперпозиция потоков на нашем масштабе не является значимым фактором.

H4 · цена крышки

Закрытый корпус без обдува уменьшает устойчивое число камер не менее чем на 20 % относительно открытого стенда при той же температуре среды. Закрывается положительно, если разница в устойчивом goodput между двумя прогонами превышает 20 %, и отрицательно, если она меньше 10 %, — во втором случае тепловая часть модели для нашего конструктива избыточна.

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

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