n8n и Ollama можно запускать на одной машине, в соседних контейнерах или на разных серверах, а подключение сводится к адресу сервера Ollama в учётных данных и узлу модели в сценарии. Главные трудности лежат в сети между ними и в том, какие данные уходят в модель. Локальная модель оправдана, когда сведения нельзя отдавать внешнему сервису, а для задач, где качество важнее приватности, нужен запасной путь.
Зачем локальная модель
В n8n есть узлы для чата и эмбеддингов Ollama, которые работают с учётными данными по адресу сервера. Адрес по умолчанию — localhost с портом Ollama, а при запуске в разных контейнерах его заменяют на адрес, доступный соседнему контейнеру.
Отдел поддержки хочет автоматически определять тему обращения и готовить черновик ответа, но тексты содержат данные клиентов. Сценарий n8n забирает обращение, отправляет текст локальной модели, получает тему и черновик и кладёт результат в таблицу для оператора. Облачные сервисы в этой цепочке отсутствуют, и вопрос передачи данных наружу снимается.
Причины ставить локальную модель в автоматизацию обычно три: данные нельзя отправлять наружу, нужно много запросов без лимитов вендора, важна независимость от внешних сервисов. Платой становятся задержка на вашем оборудовании и более скромное качество по сравнению с облачными флагманами.
Общую схему подключения нейросети к сценариям мы разбирали в статье как настроить n8n с нейросетью для бизнеса, а запуск самой Ollama — в материале Ollama для компании. Эта статья про стык двух систем: сеть, ограничения данных, проверка и резерв.
Состав узлов и параметров смотрите в описании учётных данных Ollama: документация обновляется, и поведение узлов от версии к версии меняется.
Сеть и адрес
Самая частая причина неудачи — неверный адрес. Слово localhost в разных контейнерах означает разные машины, поэтому схема размещения определяет, что вписывать в учётные данные.
| Где запущены n8n и Ollama | Какой адрес указать | Что проверить |
|---|---|---|
| На одной машине, без контейнеров | localhost или 127.0.0.1 с портом Ollama | При сбое localhost пробуйте 127.0.0.1 |
| n8n в контейнере, Ollama на хосте | Адрес хоста, доступный из контейнера | Слушает ли Ollama на этом интерфейсе (переменная OLLAMA_HOST) |
| Оба в контейнерах | Имя сервиса Ollama в общей сети Docker | Общая сеть и разрешённые источники (OLLAMA_ORIGINS) |
| Разные серверы | Внутренний адрес сервера с Ollama | Доступ только из внутренней сети, защита шлюзом с ключом |
Разные серверы дают гибкость, но добавляют сетевой путь, который тоже ломается. Проверяйте время ответа на самом сервере модели и со стороны n8n: разница показывает задержку сети. Если запросы идут через защищённый шлюз, добавьте его в мониторинг, иначе сбой шлюза будет выглядеть как неисправность модели.
Если Ollama открыта по сети, защищайте её: у самой Ollama нет проверки доступа, поэтому перед сервером ставят шлюз, а в учётных данных n8n указывают ключ, который уходит в заголовке авторизации. Контейнерную часть разбирает статья про Ollama в Docker, а обращения к серверу из своих сервисов описаны в материале про подключение Ollama через API.
Что уходит в модель
Локальная модель снимает вопрос внешней передачи данных, но остаются вопросы внутренние: кто видит запросы, где хранятся журналы запусков, что попадает в запись выполнения n8n. Журнал выполнений содержит входные данные узлов, и в нём окажутся тексты запросов к модели.
- Минимум данных: отправляйте в модель только поля, нужные для задачи, без остальной карточки клиента.
- Маскирование: телефоны, номера документов и суммы заменяйте метками до запроса и возвращайте после ответа, если задача это допускает.
- Срок хранения запусков: настройте очистку журнала выполнений, чтобы тексты запросов хранились ограниченное время.
- Права на сценарий: кто может открыть запуск, тот видит данные внутри него, поэтому ограничьте число людей с таким доступом.
- Размер контекста: длинные документы режьте на части, иначе модель потеряет начало или ответит очень медленно.
Отдельная оговорка про узлы-подузлы: в документации n8n сказано, что выражения в них считаются по первому элементу входа, и перебор всех элементов подузлам самостоятельно недоступен. Для пакетной обработки списка заявок вокруг узла модели строят цикл или вызывают модель через обычный запрос по HTTP.
Проверка связки
Проверку делают в три слоя: сервер Ollama, соединение из n8n, поведение сценария. Каждый слой проверяется отдельно, чтобы причину сбоя находить быстро.
- Убедитесь, что Ollama отвечает на машине, где она запущена, и что нужная модель загружена и значится в списке.
- Из контейнера или сервера с n8n отправьте запрос на адрес Ollama, чтобы проверить сеть до того, как открывать учётные данные.
- Создайте учётные данные Ollama с найденным адресом и ключом и запустите минимальный сценарий: ручной триггер, узел модели, короткий вопрос.
- Прогоните три реальных запроса: короткий, длинный и с необычными символами, и запишите время ответа как точку отсчёта.
- Остановите Ollama и посмотрите, что делает сценарий: он должен перейти в обработку ошибки и ответить хоть чем-то.
Сравните и несколько размеров модели на реальных запросах. Меньшая модель отвечает быстрее и занимает меньше памяти, а для классификации обращений или извлечения полей её хватает, тогда как крупная нужна для связного текста. Выбор размера по тестовой нагрузке мы разбираем в статье про Qwen через Ollama.
Записанное время ответа пригодится позже: когда сценарий начнёт тормозить, у вас будет с чем сравнивать, и вы быстро отличите перегрузку модели от проблем сети.
Какую задачу вы хотите отдать локальной модели?
Запасной путь
Сервер с моделью может перегрузиться, перезагрузиться или остаться без видеокарты. Сценарий, который зависит от одной локальной модели, остановится вместе с ней, поэтому резерв закладывают сразу.
- Повтор с паузой: короткий сбой часто проходит сам, и сценарий пробует ещё раз через настройку узла Retry On Fail.
- Очередь вместо потери: при недоступной модели заявки складываются в таблицу и обрабатываются позже.
- Запасная модель: меньшая локальная или облачная, если задача допускает отправку данных наружу, с отметкой в журнале, какой путь сработал.
- Передача человеку: для критичных заявок сбой модели означает уведомление сотруднику, ожидание автоматической обработки теряет смысл.
- Оповещение: отдельный сценарий на сбой выполнения сообщает ответственному, что модель недоступна.
Следите за ресурсами сервера моделей: память, загрузка видеокарты, число одновременных запросов. Простая панель с тремя показателями и порогом оповещения избавляет от сюрпризов, когда сценарий днём начинает работать заметно медленнее из-за соседней задачи, запущенной на той же машине без вашего ведома.
Остановите тестовую Ollama и посмотрите, что произойдёт со сценарием. Если ответа нет ни у клиента, ни у сотрудника, резерв отсутствует, и это нужно исправить до запуска в работу.
Локальную модель легко принять за калькулятор, который работает всегда, а это сервер с памятью, температурой и обновлениями, и мониторить его нужно как любой другой. Как вписать такой сервер в рабочие процессы и контроль, мы показываем в разделе про внедрение ИИ в компанию.