К локальному агенту приходят почти всегда по одной из двух причин: либо данные нельзя выпускать наружу, либо хочется перестать платить за каждый запрос.
Обе причины разумные, но приводят к разным выводам. Разберём честно: что даёт локальное развёртывание, чего оно стоит и где облако выигрывает даже у тех, кто очень хочет обойтись своим сервером.
Сначала о путанице: модель и агент — разные вещи
Половина статей по этому запросу описывает установку модели и на этом заканчивается. Но запустить модель у себя — это не то же самое, что получить агента.
| Что это | Что нужно | Сколько занимает | |
|---|---|---|---|
| Локальная модель | «Мозг», который отвечает на вопросы | Железо и программа для запуска | Час-два |
| Локальный агент | Модель + инструменты + память + логика | То же плюс разработка | Недели |
Модель отвечает текстом. Агент делает: смотрит в вашу базу, читает документ, создаёт задачу, пишет ответ. Подробный разбор понятия — что такое ИИ-агент. Разница подробно разобрана в статье про то, чем ИИ-агент отличается от чат-бота — и она не зависит от того, где крутится модель.
Практический вывод: инструкция «поставьте Ollama и получите агента» не работает. Вы получите чат с моделью на своём компьютере. Полезно, но это не автоматизация процесса.
Единственная причина, ради которой это делают всерьёз
Причин называют три: приватность, экономия, независимость. Честно выдерживает проверку только первая.
Данные не покидают контур. Это настоящая причина, и её нельзя обойти никакими настройками облака. Если по вашим требованиям содержимое документов не может уходить стороннему обработчику, локальное развёртывание — единственный вариант.
Экономия. Работает только при постоянной серьёзной нагрузке. Видеокарта, способная тянуть приличную модель, стоит как несколько лет облачных запросов при среднем потоке. Если у вас пятьсот диалогов в месяц, облако дешевле в разы — расчёт по токенам разобран в статье про то, сколько стоит ИИ-агент.
Независимость от поставщика. Отчасти справедливо: локальная модель не отключится и не подорожает. Но взамен вы получаете зависимость от своего железа и от человека, который его обслуживает.
- Содержимое не покидает контур
- Нет счёта за токены
- Разовые вложения в железо
- Модели слабее облачных
- Обслуживание на вас
- Старшие модели без вложений
- Запуск за день
- Оплата по факту использования
- Данные уходят обработчику
- Зависимость от доступности сервиса
Что реально требуется от железа
Главный вопрос, на который в обзорах отвечают расплывчато.
Определяющий параметр — объём видеопамяти. Именно от него зависит, какая модель поместится и с какой скоростью будет отвечать. Процессор и обычная оперативная память важны, но вторичны: модель можно запустить и на них, только отвечать она будет медленно — иногда мучительно медленно.
| Задача | Что примерно нужно | Чего ожидать |
|---|---|---|
| Попробовать, поиграть | Обычный компьютер, без видеокарты | Ответ по несколько секунд на слово |
| Классификация, извлечение данных | Небольшая модель, скромная видеокарта | Приемлемо для фоновых задач |
| Диалог с клиентом в реальном времени | Серьёзная видеокарта | Задержка становится терпимой |
| Сложные рассуждения, длинный контекст | Несколько видеокарт или очень дорогая одна | Уже сравнимо со стоимостью команды |
Почему нельзя дать точные цифры в статье. Требования зависят от размера модели, степени её сжатия, длины контекста и того, сколько запросов идёт одновременно. Одна и та же модель может занимать вдвое меньше памяти в сжатом виде — с потерей качества, которую надо проверять на своих задачах.
Что из этого следует практически: прежде чем закупать железо, соберите прототип на арендованной машине с видеокартой. День аренды стоит копейки по сравнению с покупкой не той карты.
Чем запускают модели
Два инструмента, которые встречаются чаще всего, и оба доступны из России.
Ollama — запуск моделей одной командой. Ставится на сервер, поднимает локальный интерфейс, к которому обращаются другие программы. Это тот вариант, который используют, когда агент должен работать как служба.
LM Studio — приложение с окном: модели ставятся в пару кликов, есть чат для проверки. Удобно, чтобы попробовать и понять, какая модель справляется с вашей задачей.
Обе ссылки проверены с российского адреса 24 августа 2026 года.
Порядок, который экономит время: сначала LM Studio на своём компьютере — прогнать десяток реальных задач на нескольких моделях и понять, какая справляется. Потом уже Ollama на сервере и разработка агента вокруг неё.
Какие модели ставят
Здесь важно понимать одну вещь: «локальная модель» — это не отдельный сорт нейросетей. Это открытые модели, веса которых выложены и которые можно скачать.
Их отличает от облачных не природа, а размер. В облаке работают модели, для которых нужны десятки видеокарт. Локально запускают уменьшенные версии — и качество отличается ровно настолько, насколько отличается размер.
Что локальные модели делают хорошо:
- классификация обращений по темам;
- извлечение данных из текста: имя, сумма, дата, артикул;
- ответы по вашим документам, если поиск нашёл нужные куски;
- переформулирование и сокращение текста;
- простые диалоги по сценарию.
Что делают хуже облачных:
- длинные цепочки рассуждений;
- редкие формулировки и профессиональный жаргон;
- работа с очень длинным контекстом;
- аккуратное следование сложным инструкциям.
Для агента это означает: локальная модель хороша как исполнитель понятных шагов и слабее как «принимающий решения».
Как из модели получается агент
Схема, которая объясняет, почему это отдельный проект.
Ключевое наблюдение: переход на локальную модель не отменяет ни базу знаний, ни настройку инструментов, ни описание границ. Он меняет только нижний слой. Поэтому обещание «локально — значит дешевле» верно лишь в части оплаты запросов.
Как устроен слой базы знаний, разобрано отдельно — что такое RAG.
Гибрид: то, что в итоге делают чаще всего
Выбор «всё локально или всё в облаке» на практике встречается редко. Работает третий вариант, и он же обычно оказывается дешевле обоих.
Идея простая: маршрут запроса определяется не сложностью задачи, а чувствительностью данных.
Типичное разделение на практике. Локально: разбор документов клиентов, работа с персональными данными, внутренние регламенты. В облаке: формулирование текста, общие вопросы, задачи, где содержание не критично.
Что это даёт. Требование по данным выполняется, при этом на сложных задачах работает сильная модель. И железо нужно скромнее: локальная часть обрабатывает меньший поток.
Что усложняется. Две системы вместо одной, две точки отказа, разное поведение моделей. Это реальная плата, и её надо учитывать.
Сколько это стоит на самом деле
Разложим по статьям, чтобы «бесплатные открытые модели» перестали выглядеть бесплатными.
| Статья | Локально | В облаке |
|---|---|---|
| Железо | разово, основная сумма | не нужно |
| Модель | бесплатно (открытые веса) | по токенам |
| Электричество и размещение | ежемесячно | входит в тариф |
| Обслуживание | ваш админ или подрядчик | на стороне поставщика |
| Разработка агента | одинаково | одинаково |
| Обновление моделей | ваша задача | происходит само |
Где обычно ошибаются в расчёте. Сравнивают стоимость видеокарты со стоимостью токенов и на этом останавливаются. Забывают про две вещи: обслуживание (человек, который следит, обновляет и чинит) и простой (если сервер лёг, агент не работает, и запасного нет).
Когда локальное действительно дешевле: большой постоянный поток запросов, где облачный счёт исчисляется десятками тысяч в месяц. Тогда железо окупается за обозримый срок.
Когда локальное дороже, но всё равно нужно: требования к данным не оставляют выбора. Тогда это не вопрос экономики, а вопрос допустимости.
Что ломается в локальных развёртываниях
Пять проблем, которые не встречаются в облаке.
Модель занимает больше памяти, чем ожидали. Заявленный размер модели и реальное потребление при работе — разные числа: к весам добавляется контекст, а он растёт вместе с длиной диалога.
Скорость падает при нескольких пользователях. Одна видеокарта обслуживает запросы по очереди. Пока один пользователь получает длинный ответ, остальные ждут.
Некому обновлять. Открытые модели выходят постоянно, и через полгода ваша заметно отстанет. В облаке обновление происходит без вашего участия, локально это отдельная работа с перепроверкой качества.
Нет запасного варианта. Облачный сервис при сбое можно временно заменить другим. Ваш сервер лёг — агент не работает, пока его не поднимут.
Качество проверяют на демонстрации, а не на потоке. Модель отлично отвечает на пять показательных вопросов и путается на реальном разнообразии обращений. Проверять нужно на архиве настоящих запросов.
Когда локальный агент точно не нужен
Ниже случаи, в которых деньги уйдут зря.
Данные и так публичные. Если агент отвечает по вашему же сайту и прайсу, скрывать нечего — облако проще и лучше.
Поток небольшой. Несколько сотен запросов в месяц никогда не окупят железо.
Нет админа. Сервер с видеокартой требует ухода. Если обслуживать некому, система тихо деградирует.
Нужно максимальное качество ответов. Здесь облачные старшие модели пока впереди, и разрыв заметен на сложных задачах.
Задача — быстро проверить идею. Прототип собирают в облаке за дни, а не за недели закупки железа.
Порядок, если решили делать
- 1Определить, что именно нельзя отдаватьНе «все данные», а конкретные поля и документы
- 2Собрать архив реальных задачПолсотни настоящих запросов, а не придуманных
- 3Прогнать их на нескольких моделяхНа арендованной машине, до закупки железа
- 4Выбрать модель по результатуНе по размеру и не по рейтингу
- 5Посчитать железо под выбраннуюС запасом на одновременные запросы
- 6Заложить обслуживаниеКто обновляет, кто чинит, что делать при простое
Главный вывод, если убрать детали. Локальный агент — это не «то же самое, только у себя». Это другой набор компромиссов: приватность и предсказуемость счёта в обмен на качество моделей, скорость запуска и вашу же ответственность за работоспособность. Выбирать стоит по требованиям к данным, а не по желанию сэкономить.
Безопасность: «локально» не значит «безопасно»
Ловушка, в которую попадают чаще всего. Решение поставить модель у себя принимают ради защиты данных — и на этом успокаиваются.
Между тем перенос модели в свой контур закрывает ровно одну угрозу: содержимое запросов не уходит стороннему обработчику. Все остальные остаются, и часть из них появляется заново.
Что нужно закрыть отдельно:
| Угроза | Что с ней делать |
|---|---|
| Доступ к серверу извне | Сервер с моделью не должен смотреть в интернет напрямую |
| Кто может отправлять запросы | Аутентификация на уровне сервиса, а не «кто знает адрес» |
| Логи запросов | Содержимое диалогов оседает в логах — решить, сколько хранить |
| Доступ администраторов | У того, кто обслуживает сервер, есть доступ ко всему, что через него проходит |
| Обновления | Незакрытая уязвимость на своём сервере — ваша проблема, а не поставщика |
По деньгам выходит так: локальное развёртывание переносит ответственность за безопасность на вас. Для компании с отделом ИТ это нормально. Для небольшой компании без администратора это часто означает, что данные в итоге защищены хуже, чем были бы в облаке у крупного поставщика.
Как выглядит внедрение по шагам
Порядок работ на реальном проекте, чтобы было понятно, из чего складывается срок.
- 1Разбор требований к даннымЧто именно нельзя отдавать и почему
- 2Сбор архива задачРеальные запросы, на которых будем проверять
- 3Тест моделей на арендеНесколько кандидатов, одинаковые задачи
- 4Выбор модели и расчёт железаПо результату теста, а не по рейтингам
- 5РазвёртываниеСервер, запуск модели, доступы, мониторинг
- 6Разработка агентаБаза знаний, инструменты, границы
- 7Проверка на потокеЧасть реальных запросов, параллельно с людьми
Где обычно сдвигаются сроки: не в разработке, а в закупке и настройке железа. Видеокарты бывают в дефиците, а сервер надо где-то разместить.
Что спросить у подрядчика
Пять вопросов, которые отделяют тех, кто делал такое, от тех, кто читал про это.
На каком архиве проверялась модель. Правильный ответ — на ваших реальных запросах, а не на демонстрационных примерах.
Что происходит при простое сервера. Должен быть ответ: очередь, переключение на облако для нечувствительных задач или честное «агент не работает, вот как об этом узнаем».
Сколько одновременных запросов держит конфигурация. Если ответа нет, значит нагрузку не считали.
Кто и как обновляет модель. Через полгода выйдут новые версии, и должен быть понятный порядок с перепроверкой качества.
Что остаётся у вас при расставании. Модель, база знаний, код агента и доступы должны быть вашими — это касается любого проекта, но в локальном особенно: инфраструктура уже стоит у вас.
Короткий вывод
Если убрать детали, решение сводится к трём утверждениям.
Первое. Локальный агент нужен там, где данные нельзя отдавать наружу. Это единственная причина, которая выдерживает проверку в любом случае; экономия работает только на большом потоке.
Второе. Запустить модель — час. Получить работающего агента — недели, и эти недели одинаковы для локального и облачного варианта: база знаний, инструменты и границы нужны в обоих.
Третье. Локальность переносит на вас ответственность за железо, обновления и безопасность. Это нормальная цена за контроль над данными, но она не нулевая, и считать её надо до закупки, а не после.
Ошибка, которая дороже всех остальных: закупить железо до того, как проверили модели на своих задачах. Видеокарта, купленная под модель, которая в итоге не справилась, превращается в дорогой урок — а проверка на арендованной машине стоит несколько сотен рублей и занимает один рабочий день.
Что делаю я
Всё упирается в один вопрос, и его я задаю первым: что конкретно нельзя выпускать из вашего контура. Обычно чувствительна не вся переписка, а два поля в ней, — и тогда задача решается облаком с правильной подготовкой данных, без закупки железа.
Если локальное развёртывание действительно нужно, делаю ИИ-агентов на своём сервере целиком: подбор модели под ваши задачи на реальном архиве, разворачивание, база знаний, инструменты и границы. Если вижу, что задача закрывается чат-ботом или облачным агентом, говорю об этом прямо: локальный сервер без необходимости — это расходы, которые потом никто не хочет обслуживать.
