Локальный ИИ-агент: свои модели и self-hosted стек

Локальный агент - это не «то же самое, но бесплатно». Это другой набор компромиссов: вы получаете контроль над данными и предсказуемую стоимость, а платите качеством на сложных задачах и своим временем на эксплуатацию.

Зачем запускать локально

Три причины, каждая из которых достаточна сама по себе.

Данные нельзя отдавать наружу. Персональные данные, медицина, банковская тайна, договор с клиентом, прямо запрещающий передачу третьим лицам. Это самая частая и самая честная причина: тут вопрос не в цене.

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

Независимость. Провайдер может изменить цену, ограничить доступ или снять модель с поддержки. Локальная модель никуда не денется - вместе со всеми своими недостатками.

Чего в этом списке нет: «локально быстрее» и «локально проще». Обычно наоборот.

Что нужно из железа

Главный ресурс - видеопамять, и именно она определяет, какая модель вообще запустится.

• Потребительская видеокарта. Небольшие модели, приемлемая скорость. Годится для узких задач: классификация, извлечение полей, короткие ответы по шаблону.
• Профессиональная карта. Модели среднего размера. Это уровень, на котором агентный цикл начинает работать осмысленно.
• Несколько карт или сервер. Крупные модели. Здесь встаёт вопрос, не дешевле ли платить провайдеру.
• Процессор без ускорителя. Формально работает, практически непригодно для агента: цикл из двадцати шагов растягивается на часы.

Второй по важности ресурс - скорость генерации. У агента каждый шаг требует ответа модели, и медленная модель превращает минутную задачу в получасовую. На одном ответе разница незаметна, на цикле она умножается.

Ограничения локальных моделей

Честно про потолок: на агентных задачах разрыв больше, чем на генерации текста.

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

Что проявляется на практике:

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

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

Гибридная схема

Обычно лучшее решение - не крайность, а разделение.

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

В облако отправляют то, где нужна глубина и где данные можно обезличить: сложные рассуждения, разбор нестандартных случаев, планирование.

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

Это даёт и приватность там, где она нужна, и качество там, где оно нужно. Цена - чуть более сложная система, но обычно проще, чем попытка вытянуть всё на локальной модели.

Инфраструктура вокруг

Локальная модель - только половина. Остальное такое же, как в облачном варианте: база для состояния, очередь, логи по шагам, мониторинг. Если стек поднимается на своём сервере, полезен разбор про self-hosted в Docker - принципы те же: бэкапы, обновления, ключи.

И главное: локальный запуск не отменяет ни одного требования к агенту. Лимит шагов, верификация, идемпотентность нужны точно так же - см. внедрение агентов.

Общая картина - гид по ИИ-агентам.