Как выбрать между облачным и локальным ИИ-агентом

MAATRIX

Вы собираете агента — не просто чат-бота, а систему, которая сама читает документы, дёргает API, пишет код и перепроверяет результат по цепочке шагов. И на первом же архитектурном решении упираетесь в развилку: гнать всё через облачный API OpenAI или Anthropic, или поднять открытую модель у себя и не зависеть от внешнего провайдера. Разница ощущается не в демо на один запрос, а через неделю эксплуатации, когда агент раз за разом падает на пятом шаге цепочки или счёт за токены удивляет вас в конце месяца. Ниже — честное сравнение по критериям, которые реально решают, а не по маркетинговым лозунгам.

Что вообще считать «агентом»

Разница между моделью и агентом принципиальна, и путать их — источник половины разочарований. Модель отвечает на один запрос текстом. Агент — это модель, обёрнутая в цикл: получить задачу → решить, какой инструмент вызвать → сформировать корректный JSON вызова → дождаться результата → решить следующий шаг → повторять, пока задача не решена или не исчерпан лимит шагов. Каждая стрелка в этой цепочке — точка, где агент может сорваться: неправильно сформированный аргумент функции, галлюцинация несуществующего инструмента, зацикливание на одном и том же вызове, потеря контекста после десятого шага. О механике самого вызова — как модель вообще генерирует эти JSON-структуры и кто их исполняет — подробно разобрано в статье про tool calling в LLM. Здесь важно другое: чем длиннее и разветвлённее цепочка, тем сильнее разница между провайдерами модели становится заметна — и именно на длинных цепочках чаще всего решается, годится ли открытая модель для продакшена.

Качество рассуждений и надёжность вызовов инструментов

Это главный и самый неудобный пункт сравнения. На конец лета 2026 года флагманские облачные модели (GPT последних версий, Claude) на сложных многошаговых задачах с вызовом инструментов ошибаются заметно реже открытых моделей сопоставимого класса — это касается как формата вызова (валидный JSON с нужными полями), так и логики: когда остановиться, когда переспросить, когда не выдумывать параметр. Открытые модели (Llama, Qwen, Mistral, DeepSeek и их дообученные форки) за последние пару лет очень сильно подтянулись именно в tool calling — по отдельным вызовам разница с топовыми облачными моделями уже небольшая. Но на длинных цепочках (5+ последовательных вызовов с ветвлением по результатам) у открытых моделей чаще накапливается ошибка: агент теряет исходную цель, повторяет один и тот же вызов, или уверенно вызывает функцию с придуманными параметрами вместо того, чтобы попросить уточнение.

Практический вывод: если ваш агент делает 1-2 вызова инструмента на запрос (классификация, извлечение данных, простой RAG-ответ), разница между облачной и открытой моделью может быть не критична. Если агент — автономный воркфлоу на 10+ шагов с реальными побочными эффектами (правки в базе, отправка писем, изменения в инфраструктуре), закладывайте на открытой модели больше валидации на каждом шаге и жёсткие таймауты — либо ведите такие цепочки через облако. Точные цифры по проценту успешных завершений цепочек сильно зависят от конкретной модели и вашего промпта — не берите чужие бенчмарки за истину, проверяйте на своих сценариях.

Доступность из России: там, где обрывается облако

Это второй по значимости фактор, и он не про качество модели, а про инфраструктуру. Прямой доступ к API OpenAI и Anthropic из российских IP заблокирован или нестабилен, российская карта для оплаты не подходит. Рабочая схема — сервер за рубежом (США, Великобритания) как точка выхода: либо прокси к API, либо полноценный шлюз вроде LiteLLM, который принимает запросы от вашего приложения и уже сам обращается к OpenAI/Anthropic с зарубежного IP. Мы писали отдельно, как поднять API-прокси к Claude через сервер в США — это рабочий, но дополнительный слой инфраструктуры, который нужно администрировать, мониторить на предмет даунтайма и оплачивать отдельно от токенов.

Локальный агент на открытой модели этой проблемы не имеет — модель крутится на вашем сервере (в России или где угодно), внешняя сеть ей не нужна, если только сам агент не должен ходить в интернет по задаче. Для команд, где стабильность канала до Anthropic/OpenAI — постоянная головная боль, это весомый довод в пользу локального варианта или гибрида, где критичный по времени цикл не зависит от внешнего соединения.

Стоимость: токены против железа

Экономика считается принципиально по-разному, и здесь легко обмануть себя, сравнивая не то с тем.

• Облачный API — вы платите за фактически использованные токены, входные и выходные, обычно раздельно по цене. У агентных цепочек расход токенов растёт нелинейно: каждый шаг цикла — это, как правило, весь контекст заново (история диалога, системный промпт, описания инструментов, результаты предыдущих вызовов). Агент на 10 шагов с контекстом в 8000 токенов на шаг — это не 8000, а ближе к 40 000-60 000 токенов суммарно за одну задачу, потому что контекст на каждом шаге растёт. При росте объёма (сотни задач в день) счёт увеличивается прямо пропорционально нагрузке, без потолка.
• Локальный агент — вы платите фиксированную стоимость сервера (аренда GPU или мощного CPU-инстанса) независимо от того, сколько задач агент обработал за месяц. При низкой нагрузке это может быть дороже разового облачного счёта, но при постоянной высокой нагрузке (агент работает 24/7, десятки тысяч вызовов в день) фиксированная стоимость железа быстро окупается против растущего облачного счёта.

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

Контроль данных и приватность

Здесь у локального агента преимущество почти без оговорок. Все данные, которые агент читает и генерирует — внутренние документы, переписка, код, персональные данные клиентов — не покидают ваш периметр. Это снимает вопросы о том, что провайдер облачного API делает с промптами и ответами (даже при формальном отказе от обучения на данных клиентов, сам факт передачи данных на сторонний сервер за пределами вашей юрисдикции для многих отраслей — юридический стоп-фактор: медицина, финансы, госсектор, работа с персональными данными по 152-ФЗ).

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

Сравнение по критериям

Честный вывод из таблицы: нет универсально «лучшего» варианта — есть вариант, подходящий под конкретную задачу, объём и требования к данным. Если у вас единичные сложные цепочки с реальными последствиями ошибок — берите облако. Если у вас массовый простой поток задач с жёсткими требованиями к приватности — локальная модель окупится. Большинству реальных продуктов нужно и то, и другое одновременно, для разных частей одного агента.

Гибрид через LiteLLM: сложное в облако, рутину — локально

Практичный компромисс, к которому приходит большинство команд после пары месяцев эксплуатации агента — не выбирать один вариант навсегда, а маршрутизировать запросы по сложности. LiteLLM здесь удобен тем, что даёт единый OpenAI-совместимый эндпоинт поверх и облачных провайдеров, и локально развёрнутых моделей (через Ollama или vLLM с их же OpenAI-совместимым API) — ваш агент обращается в один и тот же интерфейс, не зная, куда конкретно ушёл запрос.

Базовая конфигурация config.yaml с двумя маршрутами — «умным» на облако и «быстрым» на локальный сервер:

model_list:
  - model_name: agent-smart
    litellm_params:
      model: anthropic/claude-sonnet-4-5
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: agent-routine
    litellm_params:
      model: openai/qwen2.5-32b-instruct
      api_base: http://127.0.0.1:8000/v1
      api_key: "sk-local-placeholder"

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

Дальше маршрутизация — на стороне логики агента, не самого LiteLLM: он не умеет сам оценивать «сложность» задачи, это решаете вы. Рабочие эвристики, которые применяют на практике:

• Первый проход по задаче — на локальной модели (agent-routine); если агент три раза подряд не смог сформировать валидный вызов инструмента или зациклился на одном шаге — эскалация оставшейся части цепочки на agent-smart.
• Классификация типа задачи заранее: рутинные операции (извлечение данных по фиксированному шаблону, простой RAG над внутренней базой) — сразу на локальную модель; задачи с открытым планированием (агент сам решает порядок и состав шагов) — сразу на облако.
• По чувствительности данных: если во входных данных есть персональные данные или коммерческая тайна — маршрут принудительно на локальную модель, независимо от сложности, и уже на выходе (после того, как чувствительные поля замаскированы или удалены) при необходимости передавать обобщённый запрос в облако.

Это не готовый рецепт под любую задачу — граница «где сложно, а где рутина» у каждого продукта своя, и её придётся откалибровать на реальных логах отказов, а не угадать заранее. Подробный пошаговый деплой самого LiteLLM на VPS с Docker Compose, Postgres для учёта трат и виртуальными ключами описан в статье как установить и настроить LiteLLM на VPS, а более широкий обзор экономики выбора между своим железом и внешним API — в статье локальная модель против облачного API.

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