Как выбрать LLM под конкретного агента: разбор по задачам

Агент, который читает почту и назначает встречи, и агент, который переписывает legacy-код на 40 файлов, — это две разные задачи, и одна и та же модель почти никогда не подходит обеим одинаково хорошо. Ошибка выбора видна не сразу: демо работает, а на проде агент зацикливается на вызове инструмента, теряет контекст на длинном диалоге или сжигает бюджет, потому что за каждый шаг платится за весь разросшийся промпт. Выбор LLM под агента* — это про совпадение сильных сторон модели с профилем нагрузки, а не про строчку «SOTA» в пресс-релизе.

С чего начинается выбор: профиль задачи, а не рейтинг

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

• Вызов инструментов (tool/function calling). Агент дёргает API, ищет в базе, запускает код. Здесь важна не «эрудиция», а надёжность структурированного вывода: модель должна стабильно возвращать корректный JSON и не путать имена функций.
• Длинные цепочки рассуждений. Планирование в несколько шагов, декомпозиция задачи. Тут выигрывают модели с усиленным reasoning — они дольше «думают» и дороже, но реже сбиваются на многошаговых сценариях.
• Работа с большим контекстом. Анализ документов, кодовой базы, длинной переписки. Смотрите на размер контекстного окна** и на то, как модель держит внимание в его конце, а не только в начале.
• Массовые однотипные операции. Классификация обращений, извлечение сущностей, разметка. Здесь чаще всего переплачивают: тяжёлая модель на простой задаче — деньги на ветер.

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

Что реально сравнивать

Четыре параметра, которые определяют пригодность модели для агента, и которые стоит свести в таблицу до того, как писать код.

1. Надёжность function calling. Ключевое для агентов свойство. Проверяется только на ваших инструментах: возьмите 20–30 типичных запросов и посчитайте долю корректных вызовов.
2. Размер контекстного окна. У ведущих моделей сегодня это диапазон от 128 тыс. до 1 млн+ токенов. Но платите вы за все токены на входе каждого шага, поэтому большое окно — это одновременно и возможность, и риск для бюджета.
3. Латентность. Для интерактивного агента, с которым человек общается вживую, задержка важнее пары процентов точности. Для фонового агента — почти неважна.
4. Цена за миллион токенов. Считайте отдельно вход и выход: у reasoning-моделей выход дороже, и он же раздувается за счёт «размышлений».

Ориентировочное сравнение классов моделей

Ниже — не рейтинг конкретных версий (они устаревают за месяцы), а сравнение по типам моделей. Актуальные цены и лимиты сверяйте на официальных страницах провайдеров.

Частая ошибка: одна модель на всё

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

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

Кому что подойдёт

Флагманская модель — берите, если

• агент выполняет разнородные задачи и ошибка стоит дорого (юридический ассистент, финансовый помощник);
• function calling должен работать почти без сбоев с первого раза;
• объём запросов умеренный и цена за токен не решающий фактор.

Reasoning-модель — берите, если

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

Лёгкая модель — берите, если

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

Открытая модель на своих серверах — берите, если

• данные нельзя отправлять во внешний API по требованиям безопасности;
• объём настолько велик, что своя GPU-инфраструктура окупается против поштучной оплаты;
• у команды есть силы на эксплуатацию и обновления моделей.

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

Как проверить перед внедрением

1. Соберите 30–50 реальных запросов, покрывающих типичные и краевые случаи.
2. Прогоните на кандидатах и замерьте три числа: долю корректных вызовов инструментов, среднюю латентность, стоимость одного полного прохода агента.
3. Отдельно проверьте поведение на длинном контексте — специально нагрузите модель в конце окна и посмотрите, не теряет ли она инструкцию из начала.
4. Заложите смену модели в архитектуру: держите обращение к LLM за абстракцией, чтобы поменять провайдера без переписывания агента. Модели обновляются каждые несколько месяцев.

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

** Контекстное окно — максимальный объём текста (в токенах), который модель обрабатывает за один вызов: сюда входят и системный промпт, и история, и данные. Один токен — примерно 3–4 символа для латиницы, для кириллицы обычно меньше.