Локальные LLM для агентов: когда свой сервер выгоднее API

За 2024 год открытые модели догнали закрытые настолько, что запуск LLM на собственном сервере перестал быть уделом энтузиастов. Meta (компания Meta признана в России экстремистской и запрещена) выпустила Llama 3.3 70B, Alibaba — линейку Qwen 2.5 вплоть до 72B, а DeepSeek — MoE-модель DeepSeek-V3 на 671B параметров с активными 37B на токен. Всё это можно скачать и поднять локально. Вопрос уже не «можно ли», а «стоит ли» — особенно если модель работает не в чате, а внутри агента, который сам вызывает инструменты, ходит по API и принимает решения в цикле.

Почему для агентов вопрос стоит острее, чем для чата

Обычный чат-бот делает один вызов на реплику. Агент¹ — десятки. Один пользовательский запрос разворачивается в цепочку: спланировать шаги, вызвать поиск, прочитать результат, вызвать ещё один инструмент, свести ответ. Каждый шаг — это входной и выходной токены, и они множатся.

Отсюда две вещи, которые для агентов важнее, чем для диалога:

• Стоимость на объёме. Если агент обрабатывает тысячи задач в сутки, разница между 0,5 и 5 долларами за миллион токенов превращается в разницу между парой тысяч и десятками тысяч рублей в месяц.
• Латентность в цикле. Пять последовательных вызовов по секунде — это пять секунд ожидания. Локальная модель на быстром GPU иногда отвечает предсказуемее облачного API, который делит мощности между всеми клиентами.

При этом агенту нужна не столько «эрудиция», сколько дисциплина: чёткое следование формату вызова инструмента (обычно JSON), устойчивость к длинному контексту и предсказуемость. Тут открытые модели среднего размера часто закрывают потребность без топовой закрытой модели.

Плюсы локального запуска

• Данные не уходят наружу. Для медицины, юридических документов, внутренней переписки это не удобство, а требование. Ничего не отправляется на чужой сервер.
• Фиксированная стоимость. Вы платите за железо и электричество, а не за токены. При высокой и стабильной нагрузке это дешевле подписки за вызовы.
• Нет лимитов и внезапных изменений. Провайдер не поднимет цену, не выключит модель и не введёт rate limit посреди пиковой нагрузки.
• Дообучение² под свою задачу. Открытую модель можно адаптировать на своих данных — под конкретный формат вызовов, домен, стиль ответов.
• Работа офлайн. Агент запускается там, где нет доступа к внешним API или он запрещён политикой безопасности.

Минусы, о которых узнают на второй неделе

• Железо стоит денег вперёд. Чтобы крутить модель уровня 70B без сильного квантования, нужны десятки гигабайт видеопамяти. Это либо серверный GPU за сумму от нескольких сотен тысяч рублей, либо аренда, которая съедает часть экономии.
• Инфраструктура — это работа. Обновления, мониторинг, откаты, отказоустойчивость. У облачного API всё это входит в цену; у себя — ложится на команду.
• Качество вызова инструментов ниже, чем у топовых закрытых моделей. Открытые модели чаще ломают JSON или галлюцинируют аргументы функции. Лечится промптами и валидацией, но требует времени.
• Контекстное окно³ на практике меньше заявленного. Модель может формально держать 128K токенов, но качество на длинном контексте у открытых моделей проседает раньше, чем у лидеров рынка.
• Отставание по возможностям. Мультимодальность, встроенный веб-поиск, свежие знания — здесь закрытые API часто впереди.

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

Как это выглядит в сравнении

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

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

Кому это пригодится и кому нет

Локальная LLM оправдана, если

• Вы обрабатываете чувствительные данные и не имеете права выпускать их за периметр — медкарты, персональные данные клиентов, коммерческая тайна.
• Нагрузка высокая и стабильная: агент работает круглосуточно, а не отвечает паре пользователей в день. На объёме фиксированная стоимость железа обходит поштучную оплату токенов.
• Задача узкая и повторяемая, и модель под неё можно дообучить — тогда небольшая открытая модель обгоняет универсальный API по точности и цене.
• У вас есть инженеры, готовые держать инфраструктуру, а не только писать промпты.

Лучше остаться на облачном API, если

• Нагрузка низкая или рваная: несколько сотен запросов в день дешевле оплатить по факту, чем содержать GPU 24/7.
• Вы на этапе прототипа и проверяете гипотезу — тратить недели на инфраструктуру рано.
• Агенту нужны мультимодальность, встроенный поиск или максимально надёжный вызовов инструментов из коробки.
• В команде нет никого, кто возьмёт на себя дежурство по серверу и обновления.

Промежуточный вариант

Между «всё своё» и «всё в облаке» есть третий путь — открытые модели через хостинг-провайдеров, которые дают их как API с поштучной оплатой. Вы получаете открытую модель и относительную независимость от одного вендора, но без покупки железа. Это разумный компромисс, когда данные не настолько чувствительны, чтобы держать всё у себя, но экономика поштучных вызовов топовых закрытых моделей уже кусается.

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

¹ Агент — программа на основе LLM, которая не просто отвечает текстом, а в цикле планирует действия, вызывает внешние инструменты (поиск, код, API) и использует их результаты для следующего шага.

² Дообучение (fine-tuning) — донастройка готовой модели на своих данных, чтобы она лучше решала конкретную задачу или следовала нужному формату.

³ Контекстное окно — максимальный объём текста (в токенах), который модель удерживает за один вызов: и входной запрос, и её ответ.