Локальный ИИ-агент: сколько правда стоит своё железо и когда оно окупается

15 сентября 2026 · 9 мин чтения

Многие считают: если данные нельзя выпускать за периметр компании, выбор простой. Поднять свой сервер, поставить открытую модель, вопрос закрыт. На практике это не выбор, а начало второго вопроса. Сервер надо арендовать или купить. Модель — обновлять. А систему кто-то должен держать в рабочем состоянии постоянно, не по остаточному принципу. Дальше я раскладываю, из чего на самом деле состоит локальный ИИ-агент. Сколько стоит его содержать, если считать честно. И в какой момент он перестаёт быть дороже платного API.

Кому локальный агент нужен не для галочки

Я вижу на практике одну из двух причин, и обе конкретные, не абстрактный страх «утечки».

Первая — персональные данные граждан РФ. По 152-ФЗ имя, телефон, адрес клиента обязаны храниться на серверах в России. Их нельзя передавать в модель, которая физически считает запрос за рубежом, если их не обезличили заранее. Если такую базу всё же хранят за границей, с 1 июля 2025 года за это штрафуют на сумму до 18 млн ₽ на юрлицо.

Вторая — коммерческая тайна, которая дороже штрафа. Чертежи. Рецептура. Условия с поставщиками. Финансовая модель. Формального закона здесь нет. Зато есть репутационный и договорной риск, если такой текст однажды окажется в логах чужого API.

Если ни того, ни другого в процессе нет, локальный агент решает задачу, которой не существует. Экономии на токенах он почти никогда не даёт, я разбираю это дальше. Сравнение моделей по доступу и цене без привязки к данным я делал в статье Нейросети для бизнеса, там же схема с тремя вариантами, где физически живут данные.

Из чего собран локальный агент

Локальный агент — это не «модель на своём сервере» одним куском. Я вижу в нём четыре слоя, и каждый требует отдельного решения.

Модель с открытыми весами. Это открытая версия DeepSeek, а также Llama, Mistral, Qwen и другие. Она не ходит во внешний API вообще. Весь расчёт идёт на вашем железе.

Сервер или облачный GPU под эту модель. Модели с открытыми весами не работают на обычном офисном сервере. Нужна видеокарта с достаточным объёмом памяти. Чем крупнее модель, тем дороже конфигурация.

Агентный слой поверх модели. Это код, который решает, когда вызвать инструмент, обратиться к базе или переспросить. Модель сама по себе только отвечает на вопрос. Агентность добавляет отдельный код, и его тоже кто-то пишет и чинит.

Интеграции с вашими системами: CRM, 1С, канал, откуда приходят обращения. Без них агент отвечает в пустоту. Ни один процесс до конца он так не завершает.

Сколько стоит железо и инженер, если не прятать статьи расходов

Здесь обычно и происходит разрыв между ожиданием и счётом. Лицензия открытой модели правда ничего не стоит. Всё, что вокруг неё, стоит почти всегда.

Арендовать сервер с видеокартой под модель среднего размера стоит десятки тысяч рублей в месяц (оценка по рынку облачных GPU-провайдеров). Крупная модель или несколько параллельных диалогов поднимают счёт в разы. Купить своё железо вместо того, чтобы его арендовать, дороже на старте. Зато без ежемесячного счёта дальше. Но GPU дешевеет и устаревает. Через два-три года конфигурацию обычно меняют заново.

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

Третья статья расходов не видна на старте. Это простой. Внешний API почти всегда возвращает ответ. Свой сервер иногда падает, и чинить его в выходной день тоже приходится вам, а не провайдеру с дежурной поддержкой.

Где проходит точка, после которой свой контур дешевле API

Платный API устроен просто: чем больше диалогов, тем больше счёт, и рост почти линейный. Свой сервер устроен иначе: основные деньги уходят один раз, на железо и настройку, а дальше цена почти не растёт вместе с потоком, пока сервер справляется с нагрузкой.

Из этого следует практичное правило. На маленьком и нестабильном потоке обращений платный API почти всегда дешевле: вы платите за то, что реально использовали, а не за простаивающий сервер по ночам. На большом и стабильном потоке кривые расходов меняются местами, и свой контур начинает выигрывать за счёт объёма, а не за счёт того, что он якобы бесплатный.

Где именно проходит эта точка, зависит от объёма диалогов, размера модели и цены токена у конкретного провайдера на момент расчёта. Универсальной цифры я сознательно не привожу: посчитайте её на своём реальном потоке за месяц, а не на паре тестовых диалогов, иначе точка пересечения сдвинется в любую сторону.

Что теряете, уходя от внешнего API в свой контур

Свой контур снимает вопрос 152-ФЗ и утечки коммерческой тайны одним решением, и это настоящий выигрыш. Но рядом с ним три вещи, о которых молчат, продавая идею self-host как чистую экономию.

Качество. Топовые модели, доступные только через внешний API, на сложных многошаговых задачах и на коде пока обгоняют открытые версии сопоставимого размера. На типовых диалогах разница почти не видна, на сложной аналитике или юридическом тексте видна сразу.

Поддержка. Если платный API сбоит, есть провайдер, которому можно позвонить. Открытую модель на своём сервере никто так не поддерживает. Есть комьюнити, документация и ваш инженер, который разбирается сам.

Скорость обновлений. Внешний провайдер выкатывает новую версию модели, и она становится лучше сама, без вашего участия. На своём сервере модель приходится обновлять руками: сначала проверить совместимость, потом прогнать сценарии заново и только после этого переключать прод.

Гибридный вариант: не весь агент, а только чувствительная часть

Полный self-host — не единственный способ закрыть требование по данным. Часто дешевле и быстрее устроить гибрид: обезличить данные перед тем как отправить их в модель, а не разворачивать модель у себя целиком.

Имя, телефон, адрес и другие идентификаторы клиента заменяют метками до того, как текст уходит в языковую модель, работающую через внешний API. Модель обрабатывает обезличенный текст и возвращает результат. Метки с реальными данными сопоставляете только вы, и делаете это вне модели. Формально персональные данные за периметр не выходят вообще, и при этом не приходится тянуть свой GPU-сервер.

Пример из практики (без названия компании по NDA): оптовый поставщик разбирал заявки дилеров с ценами по договору и остатками на складе, часть данных требовала соответствия 152-ФЗ. Вместо своего сервера контур развернули на РФ-облаке, а персональные данные контрагентов обезличивали перед отправкой в модель. Требование по хранению данных в России это закрыло без покупки собственного GPU.

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

Чек-лист: когда своя инфраструктура оправдана, а когда нет

Я советую считать свой сервер всерьёз, если совпадает большинство пунктов из списка.

• В диалогах или документах есть персональные данные или коммерческая тайна, которую нельзя обезличить.
• Поток обращений большой и стабильный, а не редкий и всплесками.
• В штате уже есть инженер, способный держать систему, а не нанятый специально под этот проект.
• Сложные многошаговые задачи не преобладают, открытой модели хватает по качеству.

Если данные обезличиваются без потери смысла задачи, поток небольшой или нестабильный, а своего инженера в штате нет, я почти всегда советую гибрид или обычный API. Он обходится дешевле и быстрее. Требование по 152-ФЗ при этом закрывает то же обезличивание или выбор модели с обработкой в РФ.

Читайте также: Бесплатные ИИ-агенты: что реально бесплатно и Нейросети для бизнеса: как выбрать под задачу

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