Frigate на слабом железе упирается в ускоритель раньше, чем в камеры

MAATRIX

Quick-start гайд Frigate обещает результат за 15 минут: docker compose, конфиг с парой камер по RTSP — и в интерфейсе уже бегают рамки вокруг человека или машины. На деле это работает ровно до того момента, пока камер не становится больше одной-двух или пока детекция объектов не съедает процессор целиком, не оставляя запаса на запись и веб-интерфейс. Дальше разговор идёт не про камеры и не про диск, а про то, на чём именно Frigate считает нейросеть — CPU, Coral TPU или GPU, — и это решение определяет, во сколько реально обойдётся рабочая система.

Быстрый старт: что вы получаете за 15 минут и где заканчивается халява

Минимальный запуск Frigate выглядит примерно так — docker compose с одним сервисом и конфигом на пару камер:

services:
  frigate:
    image: ghcr.io/blakeblackshear/frigate:stable
    restart: unless-stopped
    shm_size: "256mb"
    devices:
      - /dev/dri/renderD128:/dev/dri/renderD128
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./config:/config
      - ./storage:/media/frigate
    ports:
      - "8971:8971"
      - "8554:8554"
    environment:
      FRIGATE_RTSP_PASSWORD: "changeme"

И базовый config.yml:

mqtt:
  enabled: false

detectors:
  cpu1:
    type: cpu

cameras:
  vhod:
    ffmpeg:
      inputs:
        - path: rtsp://user:pass@192.168.1.50:554/stream1
          roles:
            - detect
            - record
    detect:
      width: 640
      height: 480
      fps: 5

На одной камере с низким fps детекции такая связка честно отработает демо: рамки появятся, события запишутся, интерфейс откликается быстро. Именно эту картину и показывают quick-start гайды — и именно поэтому впечатление обманчиво. Как только вы добавляете вторую-третью камеру или поднимаете fps детекции до значений, при которых система не пропускает быстро движущиеся объекты, CPU-детектор упирается в потолок раньше, чем диск, сеть или сам docker-хост. Официальная документация Frigate прямо предупреждает, что детектор типа cpu не рассчитан на промышленную нагрузку и годится максимум для теста одной камеры — но в quick-старт гайдах это предупреждение обычно теряется среди инструкций по запуску контейнера.

Detect-поток и почему CPU упирается в потолок быстрее декодирования

У Frigate для каждой камеры можно развести потоки по ролям: detect — поток, который анализирует нейросеть (его специально держат в низком разрешении, обычно порядка 300–640 пикселей по стороне, чтобы не тратить вычисления впустую), и record — поток в полном разрешении, который просто пишется на диск без анализа. Это разделение снимает часть нагрузки: декодирование и запись сами по себе не так прожорливы, как считает большинство новичков, судящих по quick-start гайдам, где ffmpeg вообще не мелькает в логах с ошибками.

Узкое место — именно инференс: прогон каждого кадра detect-потока через модель детекции объектов. CPU-детектор в Frigate использует TensorFlow Lite без аппаратного ускорения, и время инференса на слабом или средненагруженном процессоре легко достигает сотен миллисекунд на кадр. При нескольких камерах эти запросы к детектору выстраиваются в очередь — Frigate не научился магическим образом распараллеливать инференс на слабом CPU так же эффективно, как на выделенном ускорителе. В логах и в веб-интерфейсе (вкладка System → детекторы) это видно по растущему inference speed и по задержке между реальным событием и появлением рамки в интерфейсе. Проверить узкое место просто: если при добавлении новой камеры процессор во время анализа уходит в постоянные 90–100%, а inference speed детектора ползёт вверх — это не про диск и не про сеть, это чистая нехватка вычислений под детекцию.

Отдельная ловушка — decode. Если камеры отдают поток в высоком разрешении и вы не настроили отдельный низкоразрешённый substream для detect, ffmpeg декодирует полный кадр только ради того, чтобы Frigate потом ужал его до 640×480 для нейросети. На слабом CPU это удваивает нагрузку зря — большинство камер с прошивкой ONVIF умеют отдавать второй, младший поток именно для такой задачи, и его стоит сразу прописать в detect.inputs отдельно от record.

Coral TPU: недорогой выход из тупика

Google Coral — специализированный ускоритель инференса (Edge TPU), который Frigate поддерживает "из коробки" через тип детектора edgetpu. Он существует в двух форм-факторах: USB-модуль, который подключается как обычное USB-устройство, и M.2/mini-PCIe плата для установки внутрь сервера. Для домашнего или тестового стенда USB-вариант удобнее — не нужно вскрывать корпус, а для боевого сервера, который работает круглосуточно, M.2-вариант надёжнее с точки зрения физического подключения.

Разница в инференсе ощутимая: разработчики Frigate и сообщество вокруг проекта сходятся в том, что на Coral один кадр обрабатывается на порядок быстрее, чем на CPU без ускорения — там, где CPU-детектор тратит сотни миллисекунд, Coral обычно укладывается в единицы-десятки миллисекунд. Точные цифры зависят от модели камеры, разрешения detect-потока и конкретной ревизии ускорителя, поэтому не берите эти значения как гарантию для своей конфигурации — но порядок разницы достаточен, чтобы один недорогой Coral USB закрыл детекцию для нескольких камер там, где CPU не тянул стабильно и одну.

Конфиг детектора выглядит так:

detectors:
  coral:
    type: edgetpu
    device: usb

Ограничение Coral — он один физический ускоритель, и все камеры, назначенные на него, делят его пропускную способность по очереди. По опыту сообщества один USB-ускоритель обычно закрывает от нескольких до десятка камер, если detect-поток держат в низком разрешении и невысоком fps (для большинства сценариев охраны периметра достаточно 5 fps детекции — событие всё равно ловится по последовательности кадров, а не по единственному кадру). Если камер значительно больше или нужен более тяжёлый детектор объектов, одного Coral может не хватить, и тогда встаёт вопрос либо о нескольких ускорителях, либо о переходе на GPU.

GPU-ускорение как альтернатива Coral

Frigate умеет использовать GPU двумя разными способами, и их стоит не путать. Первый — детекция объектов через TensorRT-детектор на NVIDIA GPU или через OpenVINO-детектор на встроенной графике Intel. Это прямой аналог Coral, только на другом железе: модель детекции гоняется на GPU вместо TPU. Второй — аппаратное декодирование видеопотоков (NVDEC у NVIDIA, QuickSync у Intel, VAAPI на Linux в целом), которое разгружает CPU от декодирования RTSP-потоков, но не от самой детекции объектов — это разные задачи, и одно не заменяет другое.

GPU оправдан, если у вас уже много камер, вы хотите более тяжёлую и точную модель детекции (не облегчённую MobileNet-подобную, а что-то вроде YOLO с бОльшим числом классов и лучшей точностью на мелких объектах), или вы одновременно гоняете на том же сервере другие нагрузки с GPU. Если задача — просто "видеть человека или машину и не терять кадры" на десятке камер, Coral почти всегда обходится дешевле и проще в эксплуатации: не нужно возиться с драйверами NVIDIA внутри контейнера, версиями CUDA и совместимостью образов.

Если у вас уже есть сервер с GPU под другие задачи — например, инференс LLM — соблазн повесить туда же и Frigate понятен, но учтите: детекция объектов конкурирующим процессом на боевом инференс-сервере может увеличивать задержку основной нагрузки рывками, когда одновременно срабатывает несколько камер. Разделение ролей и подбор конфигурации GPU-сервера под смешанную нагрузку — отдельная тема, чуть шире вопроса именно про Frigate: базовые принципы проброса и настройки GPU в сервере разобраны в статье про проброс GPU в виртуальную машину.

Проброс ускорителя в виртуализацию — где обычный VPS не подходит

Тут начинается вопрос, который в quick-start гайдах вообще не поднимается: как ускоритель физически попадает внутрь вашего сервера или контейнера. Coral USB — это USB-устройство, и чтобы Frigate внутри Docker его увидел, устройство должно быть проброшено в контейнер (--device=/dev/bus/usb), а сам хост должен физически иметь этот USB-порт и видеть на нём Coral. На типичном VPS с виртуализацией KVM или OpenVZ у вас нет доступа к физическим USB-портам гипервизора — устройство просто неоткуда взять внутри виртуальной машины. То же самое с GPU: чтобы TensorRT-детектор увидел видеокарту, нужен полноценный проброс GPU через IOMMU/vfio-pci на уровне хоста, что физически возможно только на выделенном сервере с поддерживающей проброс материнской платой и BIOS — базовые принципы этого разобраны в статье про GPU passthrough.

Практический вывод: если вы планируете Frigate с аппаратным ускорением детекции, стандартный VPS для этого не подойдёт независимо от того, сколько у него ядер и памяти — вам нужен выделенный сервер, к которому физически подключается Coral USB, либо сервер с GPU, доступным контейнеру напрямую. VPS остаётся разумным вариантом только для сценария "1-2 камеры, CPU-детектор, невысокий fps" — то есть ровно того демо-режима, который показывают в quick-start гайдах.

Сколько камер потянет разное железо — практический ориентир

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

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

Если система уже стоит и упирается не в старте, а спустя месяцы работы — растёт число событий, разрастается база SQLite/Postgres под метаданные, а веб-интерфейс начинает подвисать при просмотре истории, — это отдельный набор проблем, не связанный напрямую с детектором, и по духу похож на то, что разбирается в статье про частые ошибки Home Assistant на сервере — Frigate нередко живёт в связке с Home Assistant именно на одном сервере, и оба сервиса упираются в похожие по природе ресурсные пороги.

Частые вопросы