n8n + Ollama: автоматизация без облачных ИИ-подписок

MAATRIX

Половина нод OpenAI в типичном workflow n8n делает вещи, которые не требуют мощи GPT-4o: разложить письмо по трём категориям, вытащить из заявки email и сумму, определить язык обращения. Платите вы при этом по тому же прайсу, что и за сложные рассуждения. Если таких вызовов тысячи в день, а задача рутинная и повторяемая, есть смысл вынести именно эти ноды на локальную Ollama — без месячного счёта за токены и без риска, что провайдер модели однажды откажет региону.

Когда есть смысл менять облачный API на Ollama

Разница не в том, «облако или свой сервер» вообще, а в том, какую конкретно ноду вы меняете. Узел AI Agent с цепочкой инструментов и памятью — отдельный разговор, там локальная модель на CPU обычно слишком медленная для интерактива: это разбирали в статье про n8n с AI-агентами на своём сервере. Здесь речь о другом сценарии — одиночный вызов «вход-ответ» без диалога и без выбора инструментов: классификация, извлечение полей, разметка тегами, короткое резюме.

У такой задачи три признака, по которым стоит переносить её на Ollama:

• Объём выше, чем разовые тесты. Сотни-тысячи вызовов в день — там, где счёт за облачный API начинает быть заметной строкой расходов.
• Задача узкая и повторяемая. Фиксированный набор категорий или полей, а не открытый вопрос произвольной сложности.
• Задержка в несколько секунд приемлема. Фоновая обработка почты или тикетов, а не чат с живым человеком на линии.

Если хотя бы один признак не выполняется — объём маленький, задача требует тонкого понимания контекста или нужен ответ за доли секунды, — дешевле и надёжнее остаться на облачном API. Честно: заменять GPT-4o-mini на 7B-модель ради экономии $3 в месяц не имеет смысла, ниже разберём, где проходит реальная граница выгоды.

HTTP Request вместо ноды OpenAI: как это устроено

В n8n есть отдельный узел для LangChain-цепочек — Ollama Chat Model, но он рассчитан на AI Agent и Basic LLM Chain, тянет за собой их накладные расходы и подходит не для всех сценариев. Для простой замены OpenAI-ноды в обычном линейном workflow проще и прозрачнее обычный HTTP Request: он обращается к Ollama напрямую, без прослойки LangChain, и одинаково хорошо работает что в потоке классификации писем, что в любом другом месте графа.

Сама Ollama после установки уже поднимает HTTP API на порту 11434 — детали установки и выбора модели под железо разбирали в статье про локальный запуск LLM через Ollama. Здесь важно одно: если n8n и Ollama работают в разных контейнерах Docker, localhost внутри контейнера n8n ведёт в сам контейнер, а не на хост с моделью. Либо поднимайте Ollama в том же compose-файле под именем сервиса (http://ollama:11434), либо добавляйте host.docker.internal с extra_hosts: ["host.docker.internal:host-gateway"] и переменной OLLAMA_HOST=0.0.0.0 на хосте — иначе получите connect ECONNREFUSED при первом же запуске ноды.

Настройка HTTP Request ноды на локальный Ollama-эндпоинт

Параметры ноды для запроса к /api/generate:

• Method — POST
• URL — http://ollama:11434/api/generate (или http://host.docker.internal:11434/api/generate)
• Body Content Type — JSON
• Specify Body — Using JSON

Тело запроса — с format: "json", чтобы модель вернула строго структурированный ответ, а не вольный текст:

{
  "model": "qwen2.5:7b-instruct-q4_K_M",
  "prompt": "Категории: billing, technical, other. Определи категорию письма и верни JSON {\"category\": \"...\"}. Тема: {{ $json.subject }}. Текст: {{ $json.body }}",
  "stream": false,
  "format": "json",
  "options": { "temperature": 0 }
}

stream: false обязателен — иначе Ollama отдаёт ответ построчными JSON-чанками, и HTTP Request нода получит на выходе не одну структуру, а поток, который придётся собирать вручную. temperature: 0 убирает разброс в формулировках между одинаковыми письмами — для классификации это не творческая задача, а детерминированная.

Второй нюанс, который ломает половину первых попыток: поле response в ответе Ollama — это строка, даже когда внутри лежит JSON. Модель вернула {"category": "billing"}, но само это значение приезжает в n8n как текст внутри поля response, а не как объект. Нужен ещё один разбор в Code-ноде:

const raw = $input.item.json.response;
let parsed;
try {
  parsed = JSON.parse(raw);
} catch (e) {
  parsed = { category: "review", error: raw };
}
return { json: parsed };

Модели поменьше иногда добавляют markdown-обёртку вокруг JSON (``json ... `) даже с параметром format: "json" — try/catch с запасным значением review` спасает от падения всего workflow на одном кривом ответе.

Отдельно про таймаут: по умолчанию у HTTP Request ноды 300 секунд — для одиночной классификации на CPU этого хватает с запасом, но если модель не в памяти и Ollama её только что выгрузила (OLLAMA_KEEP_ALIVE по умолчанию 5 минут), первый запрос после паузы уйдёт на подгрузку весов и будет заметно медленнее следующих.

Пример flow: автоматическая категоризация входящих заявок

Рабочая цепочка на четыре ноды, которую можно собрать за полчаса:

1. IMAP Email Trigger (или Webhook, если заявки приходят с формы на сайте) — ловит новое сообщение, отдаёт тему и тело.
2. HTTP Request к Ollama — промпт с закрытым списком категорий и просьбой вернуть JSON, как описано выше. Список категорий держите коротким: три-пять пунктов работают заметно надёжнее восьми-десяти — модель реже путает соседние по смыслу категории.
3. Code — парсит response, проверяет, что категория входит в разрешённый список (["billing", "technical", "other"]), иначе принудительно ставит review. Это дешёвая страховка от галлюцинации: модель иногда придумывает категорию payment_issue, которой не было в промпте.
4. Switch — по значению category раскладывает заявку: billing → тег в CRM и уведомление в бухгалтерию, technical → тикет в трекер, other и review → общая очередь на ручной разбор.

Ветка review — не лишняя деталь, а страховочная сетка всего flow: любой малый локальный модели время от времени промахивается или отдаёт кривой JSON, и такие письма должны попадать к человеку, а не потеряться и не улететь в случайную категорию. На практике доля писем, уходящих в review, — хороший индикатор качества промпта: если она растёт, чаще всего дело в неоднозначных формулировках категорий, а не в самой модели.

Экономия на токенах при большом объёме

Разовая классификация письма — короткий вызов: пара сотен токенов на вход (промпт с примерами плюс текст письма) и пара десятков на выход. По отдельности это копейки в облаке. Разница проявляется на объёме.

Возьмём условный ориентир по ценам лета 2026 года (перед реальным расчётом свежие тарифы стоит проверить — они меняются чаще, чем стоимость аренды сервера): у gpt-4o-mini — около $0,15 за миллион входных токенов и $0,60 за миллион выходных, у Claude Haiku 4.5 — около

Настройка HTTP Request ноды на локальный Ollama-эндпоинт

Параметры ноды для запроса к /api/generate:

• Method — POST
• URL — http://ollama:11434/api/generate (или http://host.docker.internal:11434/api/generate)
• Body Content Type — JSON
• Specify Body — Using JSON

Тело запроса — с format: "json", чтобы модель вернула строго структурированный ответ, а не вольный текст:

{
  "model": "qwen2.5:7b-instruct-q4_K_M",
  "prompt": "Категории: billing, technical, other. Определи категорию письма и верни JSON {\"category\": \"...\"}. Тема: {{ $json.subject }}. Текст: {{ $json.body }}",
  "stream": false,
  "format": "json",
  "options": { "temperature": 0 }
}

stream: false обязателен — иначе Ollama отдаёт ответ построчными JSON-чанками, и HTTP Request нода получит на выходе не одну структуру, а поток, который придётся собирать вручную. temperature: 0 убирает разброс в формулировках между одинаковыми письмами — для классификации это не творческая задача, а детерминированная.

Второй нюанс, который ломает половину первых попыток: поле response в ответе Ollama — это строка, даже когда внутри лежит JSON. Модель вернула {"category": "billing"}, но само это значение приезжает в n8n как текст внутри поля response, а не как объект. Нужен ещё один разбор в Code-ноде:

const raw = $input.item.json.response;
let parsed;
try {
  parsed = JSON.parse(raw);
} catch (e) {
  parsed = { category: "review", error: raw };
}
return { json: parsed };

Модели поменьше иногда добавляют markdown-обёртку вокруг JSON (``json ... `) даже с параметром format: "json" — try/catch с запасным значением review` спасает от падения всего workflow на одном кривом ответе.

Отдельно про таймаут: по умолчанию у HTTP Request ноды 300 секунд — для одиночной классификации на CPU этого хватает с запасом, но если модель не в памяти и Ollama её только что выгрузила (OLLAMA_KEEP_ALIVE по умолчанию 5 минут), первый запрос после паузы уйдёт на подгрузку весов и будет заметно медленнее следующих.

Пример flow: автоматическая категоризация входящих заявок

Рабочая цепочка на четыре ноды, которую можно собрать за полчаса:

1. IMAP Email Trigger (или Webhook, если заявки приходят с формы на сайте) — ловит новое сообщение, отдаёт тему и тело.
2. HTTP Request к Ollama — промпт с закрытым списком категорий и просьбой вернуть JSON, как описано выше. Список категорий держите коротким: три-пять пунктов работают заметно надёжнее восьми-десяти — модель реже путает соседние по смыслу категории.
3. Code — парсит response, проверяет, что категория входит в разрешённый список (["billing", "technical", "other"]), иначе принудительно ставит review. Это дешёвая страховка от галлюцинации: модель иногда придумывает категорию payment_issue, которой не было в промпте.
4. Switch — по значению category раскладывает заявку: billing → тег в CRM и уведомление в бухгалтерию, technical → тикет в трекер, other и review → общая очередь на ручной разбор.

Ветка review — не лишняя деталь, а страховочная сетка всего flow: любой малый локальный модели время от времени промахивается или отдаёт кривой JSON, и такие письма должны попадать к человеку, а не потеряться и не улететь в случайную категорию. На практике доля писем, уходящих в review, — хороший индикатор качества промпта: если она растёт, чаще всего дело в неоднозначных формулировках категорий, а не в самой модели.

Экономия на токенах при большом объёме

Разовая классификация письма — короткий вызов: пара сотен токенов на вход (промпт с примерами плюс текст письма) и пара десятков на выход. По отдельности это копейки в облаке. Разница проявляется на объёме.

Возьмём условный ориентир по ценам лета 2026 года (перед реальным расчётом свежие тарифы стоит проверить — они меняются чаще, чем стоимость аренды сервера): у gpt-4o-mini — около $0,15 за миллион входных токенов и $0,60 за миллион выходных, у Claude Haiku 4.5 — около $1 и $5 за миллион соответственно. При 250 входных и 50 выходных токенах на классификацию:

Локальный сервер под Ollama с моделью на 7B стоит фиксированную сумму независимо от того, разобрали вы за месяц пятьсот писем или пятьдесят тысяч, — подробный разбор, из чего складывается эта сумма и когда она окупает себя против облака, в статье сколько стоит держать локальную LLM в месяц. Вывод из таблицы честный: при низком объёме и дешёвой модели вроде gpt-4o-mini переход на свой сервер экономит доллары, а не сотни долларов, и связываться с ним ради самой экономии не стоит — выгода появляется на реальном потоке заявок и особенно заметна, если в проекте уже используется более дорогая модель для той же рутинной задачи.

Честный минус: качество классификации слабее топовых моделей

Здесь важно не обманывать себя. 7–8B модель на классификации трёх понятных категорий («счёт», «техническая проблема», «остальное») работает почти на уровне GPT-4o-mini — задача действительно простая. Но на многозначных формулировках, сарказме, смешанных запросах («и вопрос по оплате, и не работает функция») и на редких языках она заметно чаще ошибается, чем топовые облачные модели, и куда чаще нарушает запрошенный формат JSON — отсюда обязательный try/catch из раздела выше.

Что реально помогает поднять качество без смены модели:

• Короткий и однозначный список категорий — три-пять, не десять.
• Пара примеров прямо в промпте (few-shot) — для мелких моделей это даёт больше, чем для крупных.
• temperature: 0 и отдельная нода-валидатор, а не доверие к тому, что модель сама во всём разберётся.
• Гибридная схема — если категория review набирает заметный процент, стоит не менять всю схему, а прогонять только эту долю через облачный API как второй, более точный проход. Так вы платите за облако лишь на действительно спорных случаях, а не на каждом письме.

Если качества всё равно не хватает, следующий шаг — не менять архитектуру, а взять модель покрупнее: 13–14B точнее держит границы между близкими категориями, но требует больше RAM и генерирует медленнее — подбор конкретной модели под доступное железо разбирали в статье какую модель Ollama поставить на 4 ГБ RAM (принцип масштабируется и на бо́льшие объёмы памяти).

{
  "model": "qwen2.5:7b-instruct-q4_K_M",
  "prompt": "Категории: billing, technical, other. Определи категорию письма и верни JSON {\"category\": \"...\"}. Тема: {{ $json.subject }}. Текст: {{ $json.body }}",
  "stream": false,
  "format": "json",
  "options": { "temperature": 0 }
}

const raw = $input.item.json.response;
let parsed;
try {
  parsed = JSON.parse(raw);
} catch (e) {
  parsed = { category: "review", error: raw };
}
return { json: parsed };

{
  "model": "qwen2.5:7b-instruct-q4_K_M",
  "prompt": "Категории: billing, technical, other. Определи категорию письма и верни JSON {\"category\": \"...\"}. Тема: {{ $json.subject }}. Текст: {{ $json.body }}",
  "stream": false,
  "format": "json",
  "options": { "temperature": 0 }
}

const raw = $input.item.json.response;
let parsed;
try {
  parsed = JSON.parse(raw);
} catch (e) {
  parsed = { category: "review", error: raw };
}
return { json: parsed };

Локальный сервер под Ollama с моделью на 7B стоит фиксированную сумму независимо от того, разобрали вы за месяц пятьсот писем или пятьдесят тысяч, — подробный разбор, из чего складывается эта сумма и когда она окупает себя против облака, в статье сколько стоит держать локальную LLM в месяц. Вывод из таблицы честный: при низком объёме и дешёвой модели вроде gpt-4o-mini переход на свой сервер экономит доллары, а не сотни долларов, и связываться с ним ради самой экономии не стоит — выгода появляется на реальном потоке заявок и особенно заметна, если в проекте уже используется более дорогая модель для той же рутинной задачи.

Честный минус: качество классификации слабее топовых моделей

Здесь важно не обманывать себя. 7–8B модель на классификации трёх понятных категорий («счёт», «техническая проблема», «остальное») работает почти на уровне GPT-4o-mini — задача действительно простая. Но на многозначных формулировках, сарказме, смешанных запросах («и вопрос по оплате, и не работает функция») и на редких языках она заметно чаще ошибается, чем топовые облачные модели, и куда чаще нарушает запрошенный формат JSON — отсюда обязательный try/catch из раздела выше.

Что реально помогает поднять качество без смены модели:

• Короткий и однозначный список категорий — три-пять, не десять.
• Пара примеров прямо в промпте (few-shot) — для мелких моделей это даёт больше, чем для крупных.
• temperature: 0 и отдельная нода-валидатор, а не доверие к тому, что модель сама во всём разберётся.
• Гибридная схема — если категория review набирает заметный процент, стоит не менять всю схему, а прогонять только эту долю через облачный API как второй, более точный проход. Так вы платите за облако лишь на действительно спорных случаях, а не на каждом письме.

Если качества всё равно не хватает, следующий шаг — не менять архитектуру, а взять модель покрупнее: 13–14B точнее держит границы между близкими категориями, но требует больше RAM и генерирует медленнее — подбор конкретной модели под доступное железо разбирали в статье какую модель Ollama поставить на 4 ГБ RAM (принцип масштабируется и на бо́льшие объёмы памяти).

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