On-prem AI стек: Frigate + n8n + локальные LLM + MCP для автоматизации предприятия | AiManual
AiManual Logo Ai / Manual.
09 Янв 2026 Гайд

Архитектура on-prem AI стека: Frigate + n8n + локальные LLM + MCP серверы для автоматизации предприятия

Полное руководство по сборке локального AI стека для автоматизации производства. Frigate для компьютерного зрения, n8n для оркестрации, локальные LLM и MCP серв

Зачем вам эта головная боль?

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

Бюджет в $10,000 - не прихоть. Это минимальная сумма для системы, которая реально работает, а не имитирует деятельность. Дешевле - получите игрушку, дороже - золотую игрушку.

Вот что происходит на 90% предприятий. Видеонаблюдение есть, но оно слепое. Отчеты составляются вручную. Инциденты обнаруживаются через дни. Автоматизация - это слово из презентаций, а не из реальности.

Стек, который не просит разрешения

Главная фишка on-prem подхода - независимость. Никаких API лимитов, никаких внезапных изменений тарифов, никаких отключений из-за проблем у провайдера. Ваши данные остаются вашими. Ваша логика работает, даже когда интернет отключают.

Компонент Что делает Альтернативы (хуже)
Frigate NVR Детектирование объектов в реальном времени Blue Iris, ZoneMinder
n8n Оркестрация рабочих процессов Zapier, Make
Локальные LLM Анализ и генерация текста OpenAI API, Anthropic
MCP серверы Унифицированный доступ к данным REST API хаос

Почему именно эта комбинация? Frigate - единственный open-source NVR с нормальной интеграцией детекторов объектов. n8n - единственная оркестровка, которая не сломается от 1000 одновременных событий. Локальные LLM - потому что GPT-4 стоит $0.06 за запрос, а у вас их будут тысячи в день.

💡
Если вы только начинаете строить локальную LLM инфраструктуру, посмотрите этот гайд по запуску на домашнем железе. Принципы те же, масштаб другой.

Frigate: глаза системы

Frigate - это не просто видеорегистратор. Это детектор объектов с поддержкой Coral TPU и GPU ускорения. Видео с камер поступает в реальном времени, система выделяет объекты (человек, автомобиль, грузовик), отслеживает их перемещение, генерирует события.

1 Настройка зон и правил

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

  • Зона А: только люди (оборудование под напряжением)
  • Зона Б: люди и погрузчики (склад)
  • Зона В: только автомобили (въезд)

Настройте фильтры по размеру объекта. Маленький человек вдалеке - не событие. Крупный объект в запретной зоне - событие. Frigate позволяет задавать маски, минимальные/максимальные размеры, пороги уверенности.

Не экономьте на Coral TPU. Детектирование на CPU съест все ресурсы. Одна Coral USB Accelerator обрабатывает 100 FPS. На предприятии с 20 камерами нужно минимум 2-3 ускорителя.

2 Интеграция с MQTT

Frigate публикует события в MQTT брокер. Каждое событие - JSON с координатами объекта, типом, уверенностью, камерой, временем. Это входная точка для всей автоматизации.

Пример топика: frigate/events. В payload - вся информация о событии. n8n подписывается на этот топик, получает события в реальном времени.

n8n: мозг системы

n8n - это оркестратор. Он берет события из Frigate, обогащает данными из других систем, принимает решения, запускает действия. Если Frigate - глаза, то n8n - мозг.

3 Рабочий процесс обработки инцидента

  1. MQTT триггер получает событие "человек в опасной зоне"
  2. Проверка по графику: рабочий час или нет?
  3. Если нерабочий час - запрос к LLM для анализа ситуации
  4. LLM получает скриншот, описание, контекст
  5. LLM решает: ложное срабатывание или реальная угроза
  6. Если угроза - уведомление охране, запись в базу инцидентов
  7. Если ложное - обучение модели (помечаем как false positive)

Весь этот процесс занимает секунды. Охранник получает уведомление с фотографией и описанием: "Неизвестный в зоне высокого напряжения, 3-я смена не работает".

💡
Для сложных сценариев с множеством агентов посмотрите Beads: как превратить хаос AI-агентов в слаженный оркестр. Принципы те же, но масштабируется лучше.

Локальные LLM: анализ без облаков

Зачем локальные модели, если есть GPT-4? Посчитаем. 1000 событий в день. Каждое событие - запрос к LLM для анализа. GPT-4 Turbo: $0.01 за 1K токенов. Средний запрос с контекстом - 500 токенов. Итого: 1000 * 500 / 1000 * $0.01 = $5 в день. $150 в месяц. $1800 в год.

Локальная модель на RTX 6000: стоимость электричества - $50 в месяц. Разница в 36 раз. И это только для одного завода.

4 Выбор модели для production

Не берите самые большие модели. Они медленные. Не берите самые маленькие. Они глупые. Золотая середина - модели 7-14B параметров с квантованием до 4-бит.

  • Qwen2.5-7B-Instruct-AWQ - отлично для классификации
  • Llama-3.2-3B-Instruct - для простых задач
  • DeepSeek-Coder-7B - если нужен анализ логов

Запускайте через vLLM или Ollama. vLLM дает лучшую производительность, но сложнее в настройке. Ollama проще, но медленнее. Для production - только vLLM.

Не запускайте LLM на той же машине, что и Frigate. Видеоаналитика жрет CPU/GPU. LLM тоже жрет GPU. Разделяйте. Frigate + n8n на одном сервере, LLM на другом с GPU.

Если vLLM падает на вашей конфигурации (а он будет падать), изучите полное расследование сбоев vLLM на RTX 6000. Там все распространенные ошибки и их решения.

MCP серверы: единый язык данных

Model Context Protocol - это стандарт от Anthropic для доступа к данным. Вместо того чтобы писать кучи интеграций для каждой системы (ERP, CRM, базы данных), вы пишете MCP сервер.

MCP сервер предоставляет инструменты (tools). LLM вызывает эти инструменты через стандартный интерфейс. Хотите проверить график работника? Есть инструмент get_employee_schedule. Хотите посмотреть историю инцидентов? get_incident_history.

5 Архитектура MCP для предприятия

Один MCP сервер на каждую систему:

  • MCP для 1С (учет рабочего времени)
  • MCP для системы контроля доступа
  • MCP для базы инцидентов
  • MCP для метеостанции (да, это важно для наружных работ)

n8n содержит LLM агента с доступом ко всем MCP серверам. Когда приходит событие, агент запрашивает нужную информацию, анализирует, принимает решение.

💡
Подробнее про MCP и автоматизацию RAG систем в практическом руководстве по MCP Tool Registry.

Сборка пазла: от событий к действиям

Теперь соберем все вместе. Конвейерная линия. Камера над конвейером. Frigate детектирует объект "неисправное изделие".

  1. Frigate публикует событие в MQTT
  2. n8n получает событие, запускает workflow
  3. Workflow делает запрос к LLM с фотографией дефекта
  4. LLM через MCP сервер получает техкарту изделия
  5. LLM анализирует: "Трещина в зоне сварного шва, критический дефект"
  6. n8n останавливает конвейер через PLC шлюз
  7. Создает заявку в системе обслуживания
  8. Уведомляет мастера смены в Telegram
  9. Записывает инцидент в базу с фотографией и анализом LLM

Весь процесс - 15 секунд. Раньше дефект обнаруживался на следующем этапе контроля. Теперь - сразу. Экономия материалов, времени, нервов.

Распределение $10,000 бюджета

Где деньги уйдут на самом деле:

Компонент Бюджет Примечания
Сервер для Frigate + n8n $2,500 Intel i5, 64GB RAM, 4TB SSD, 2x Coral TPU
Сервер для LLM $4,000 RTX 6000 Ada, 128GB RAM, 2TB NVMe
Камеры и инфраструктура $2,000 8-12 камер POE, коммутатор, кабели
Лицензии и ПО $500 Почти все open-source
Настройка и интеграция $1,000 Ваше время или подрядчик

Можно сэкономить на железе, взяв б/у. Но Coral TPU лучше новые - поддержка в Frigate обновляется постоянно. GPU можно взять предыдущего поколения (RTX 4090 вместо RTX 6000), но тогда память меньше.

Типичные ошибки (как не надо делать)

Я видел десятки попыток внедрения. Вот как проваливаются:

  • Слишком много камер сразу. Начните с 2-3 критических зон. Отладите workflow. Потом добавляйте.
  • Сложные LLM промпты. Промпт должен быть простым: "Проанализируй изображение. Есть ли нарушения техники безопасности? Ответ: ДА/НЕТ. Если ДА, опиши что именно."
  • Отсутствие обратной связи. Система должна учиться. Каждый false positive - метка для дообучения детектора.
  • Попытка автоматизировать всё. Начните с одного сценария. "Человек в опасной зоне вне рабочего времени". Доведите до 99% точности. Потом следующий.
💡
Если ваши AI ассистенты ломаются в бизнес-среде, проблема часто в контексте. Читайте анализ проблемы контекста и инженерные решения.

Что дальше? Масштабирование

Система работает на одном заводе. Пора масштабировать на филиалы. Тут начинается настоящее веселье.

Каждый филиал - свой Frigate + n8n. Центральный сервер LLM обслуживает все филиалы. MCP серверы реплицируют данные в центральную базу. События агрегируются, анализируются, строятся отчеты.

n8n на каждом филиале обрабатывает локальные события быстро. Сложный анализ уходит на центральный LLM. Баланс между скоростью и мощностью.

Не пытайтесь централизовать всё. Видеопотоки с 50 камер по WAN не пустить. Локальная обработка на филиале, только результаты - в центр.

Следующий шаг - предиктивная аналитика. Система замечает: "Каждую среду в 14:30 кто-то оставляет тележку в проходе". Предлагает: "Поставить барьер в этом месте" или "Назначить ответственного на это время".

Секрет успеха: начинайте с бумаги

Прежде чем покупать железо, возьмите лист бумаги. Нарисуйте схему: камеры -> события -> проверки -> действия. Пропишите бизнес-логику: "Если событие X и условие Y, то действие Z".

Потом реализуйте это в n8n. Без камер. С тестовыми событиями. Убедитесь, что логика работает. Потом подключайте Frigate. Потом LLM. Постепенно.

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

И последнее: эта система не заменит людей. Она даст им информацию. Охранник получает не "движение в кадре", а "неизвестный в опасной зоне, 3-я смена не работает, похож на сотрудника из цеха 5". Мастер получает не "дефект", а "трещина в зоне сварки, вероятная причина - неправильная температура, рекомендуемая проверка - ультразвуковой контроль".

Информация вместо данных. Решения вместо отчетов. Вот что дает этот стек.