Не существует модели, которая одновременно самая точная, самая быстрая, держит самый большой контекст и стоит дешевле всех. Любая конкретная модель — компромисс между этими параметрами. Значит, искать нужно не «лучшую модель вообще», а ту, чей компромисс совпадает с вашей задачей. Разберём пять параметров, по которым модели расходятся, и соберём матрицу приоритетов для пяти типичных сценариев: поддержки, анализа документов, генерации текстов, программирования и извлечения сущностей.
Почему рейтинги не отвечают на вопрос «какую LLM выбрать»
Бенчмарк измеряет не вашу задачу
Публичные бенчмарки давно не сводятся к математике и экзаменационным вопросам. SWE-bench собран из реальных задач в GitHub-репозиториях, τ-bench проверяет диалог с вызовом инструментов, GAIA и OSWorld — работу с браузером и операционной системой. Задачные бенчмарки есть, и они полезны. Проблема в другом. Ни один из них не собран из ваших тикетов, ваших договоров и ваших счетов. Модель, лучшая на SWE-bench, не обязательно точнее классифицирует обращения в вашу поддержку. Бенчмарк отвечает на вопрос «какая модель сильнее в среднем». Вам нужен ответ на вопрос «какая модель справится вот с этим».
Рейтинг поддаётся накрутке
Самый цитируемый публичный рейтинг — Chatbot Arena. Пользователь задаёт вопрос, получает ответы двух анонимных моделей и голосует за лучший. Из этих голосов складывается таблица лидеров. Работа The Leaderboard Illusion (NeurIPS 2025) показала, что условия у участников неравные. Модели Google и OpenAI участвовали примерно в 20% всех сравнений каждая, а 83 модели с открытыми весами — в 29,7% на всех. Каждое сравнение даёт вендору обратную связь: видно, какие ответы нравятся голосующим. Дальше модель подстраивают под этот вкус, и её результат на арене растёт — по оценке авторов, до 112%. Работает и второй механизм. Вендор тайно прогоняет десятки черновых версий модели, а публикует результат только лучшей. В таблицу попадает не типичный уровень модели, а её самая удачная попытка. Рейтинг от этого не бесполезен: заведомо слабые модели он отсекает. Но разрыв в несколько позиций говорит скорее о ресурсах вендора, чем о том, какая модель лучше разберёт ваши тикеты.
Пять критериев, которые определяют выбор
Качество ответа
Качество — это не абстрактная «мудрость» модели. Это точность на вашей задаче: правильно ли она классифицирует тикет, не путает ли суммы в договоре, не выдумывает ли факты там, где нужно опираться на документ. Требования бывают двух разных типов. Одним задачам нужна глубокая способность к рассуждению. Другим — аккуратное следование инструкции без творческой самодеятельности. Модель, сильная в первом, не обязательно хороша во втором.
Скорость ответа
Для интерфейса, где пользователь ждёт ответ вживую, важнее всего время до первого токена (time to first token, TTFT). Именно оно ощущается как зависание сервиса. Потоковый вывод (streaming) саму модель не ускоряет. Он показывает текст по мере генерации, и ожидание смещается с полного ответа на первое слово. Общая скорость генерации важна отдельно: она определяет, сколько документов пройдёт через модель за час.
Размер контекстного окна (context window)
Контекстное окно — это объём текста, который модель обрабатывает за один запрос. Договор целиком, длинная переписка, база инструкций. Большое окно не означает, что модель одинаково работает по всей его длине. Это измерено, а не выведено из опыта отдельных команд. Классическая работа Lost in the Middle (TACL) показала: модели лучше находят информацию в начале и в конце длинного текста и заметно хуже — в середине. Исследование Context Length Alone Hurts LLM Performance Despite Perfect Retrieval (Findings of EMNLP 2025) идёт дальше. Качество падает от одной только длины входа, даже когда нужный фрагмент найден идеально и посторонних данных нет. Диапазон деградации в замерах — от 13,9% до 85%. В контрольном опыте длину входа набивали простыми пробелами, и падение всё равно доходило до 48%. Вывод простой. Заявленный размер окна — верхняя граница, а не рабочий диапазон. Большой документ надёжнее нарезать и подавать нужные фрагменты, чем закидывать целиком в расчёте на объём окна.
Цена
Стоимость считается по токенам, причём входные и выходные тарифицируются отдельно. Выходные дороже: на прайсах Anthropic и OpenAI разрыв составляет 5–6 раз. Второй множитель — разница между флагманом и облегчённой моделью одного вендора. Она доходит до 25 раз по обоим типам токенов. Избыточная модель обходится дороже, чем кажется при взгляде на один прайс. Третий фактор виден не сразу. Reasoning-модели тратят токены на внутренние рассуждения. В документации OpenAI сказано: рассуждения не видны через API, но занимают место в контекстном окне и тарифицируются как выходные токены. Самые дорогие токены при этом не показываются в ответе. Четвёртый фактор — кеширование промптов (prompt caching). Его часто считают безусловной экономией, но это не так. Чтение из кеша действительно дешевле в 10 раз, а вот запись стоит дороже обычного входного токена, и кеш живёт минуты. Экономия появляется только на плотном потоке однотипных запросов с общим началом. Поэтому одна модель нагружает бюджет по-разному в разных сценариях: длинный вход с коротким ответом (анализ документа) и короткий вход с длинным ответом (генерация текста) дают разные счета.
Доступность и комплаенс
Пятый параметр специфичен для российских компаний, и в зарубежных обзорах его нет. Доступ к иностранным API из России нестабилен. Меняются условия оплаты, региональные ограничения и юридическая рамка. Строить процесс на прямом договоре с зарубежным вендором рискованно. Второе ограничение — 152-ФЗ. Если в промпт попадают персональные данные, важно, где они обрабатываются и хранятся. Для части сценариев это закрывает вопрос выбора сразу: модель должна работать в российском контуре, либо данные нужно маскировать до отправки.
Матрица выбора: что важнее для каждой задачи
| Задача | Качество | Скорость | Контекст | Цена | Доступность и комплаенс |
|---|---|---|---|---|---|
| Поддержка (чат-бот, тикеты) | средне | критично | средне | важно: самый плотный поток запросов | важно: в диалог попадают ПДн |
| Анализ документов | критично | некритично | критично | важно: длинный вход на каждом документе | критично: договоры и отчёты — коммерческая тайна |
| Генерация текстов | важно | средне | средне | средне | некритично: публичные тексты без ПДн |
| Программирование | критично | важно | важно | важно: растёт вместе с внедрением | важно: код — интеллектуальная собственность |
| Извлечение сущностей (NER) | важно | важно | некритично | критично: тысячи документов в день | критично: паспортные данные и реквизиты |
Уровни в таблице: критично — параметр определяет выбор, важно — влияет заметно, средне — учитывается, некритично — почти не влияет.
Поддержка: скорость и объём важнее глубины рассуждений
В чат-боте поддержки и в маршрутизации тикетов ответ нужен здесь и сейчас. Задержка в несколько секунд читается как сбой сервиса. Сами задачи чаще всего несложные: ответить по FAQ, определить тему обращения, предложить следующий шаг. Максимальная способность к рассуждению здесь не нужна. Зато поддержка — один из самых нагруженных сценариев по числу обращений к API, поэтому цена за запрос заметно влияет на счёт. И в диалог регулярно попадают персональные данные, поэтому вопрос контура обработки возникает сразу.
Анализ документов: качество и контекст на первом месте
Когда модель работает с договором, финансовым отчётом или протоколом совещания, ошибка в выводе обходится дороже лишней секунды ожидания. Критичны два параметра. Качество: не потерять и не исказить условие договора. Контекст: документ должен помещаться в окно либо быть корректно нарезан на фрагменты. Скорость отходит на второй план в интерактивном сценарии. Но если документы идут пакетом по несколько сотен, пропускная способность снова становится значимой. Цена выше, чем кажется: длинный вход на потоке — основная статья расходов.
Генерация текстов: качество и соответствие стилю
Для черновиков писем, коммерческих предложений, статей и постов ключевое — связность, соответствие тону бренда и отсутствие фактических ошибок в деталях. Скорость влияет умеренно: черновик всё равно правит человек. Контекст нужен, если модель должна учитывать примеры прошлых текстов компании или объёмное техническое задание. Это единственный сценарий из пяти, где комплаенс обычно не ограничивает выбор. Публичные тексты редко содержат персональные данные.
Программирование: качество и контекст решают
Ошибка модели в коде проявляется не в моменте, а позже, при отладке или в проде. Поэтому качество здесь на первом месте. Контекст критичен по своей причине. Модель должна видеть код вокруг задачи: соседние файлы, зависимости, стиль проекта. На изолированном фрагменте она выдаёт формально верное, но чужое для проекта решение. Скорость влияет на комфорт разработчика при интерактивной работе, но уступает точности. Цену здесь обычно оценивают по первому пилоту, и оценка выходит заниженной: код — это длинный выход, а выходные токены дороже. Счёт растёт быстрее, чем число подключённых разработчиков. Исходный код — интеллектуальная собственность компании. Вопрос, куда он уходит при каждом запросе, не менее важен, чем качество подсказок.
Извлечение сущностей: цена и скорость на потоке
Распознавание дат, сумм и реквизитов из счетов, накладных и анкет (named entity recognition, NER) даёт понятный и проверяемый результат. Широкие творческие способности модели здесь не нужны. Такие задачи почти всегда идут потоком: сотни или тысячи документов в день. Поэтому цена за токен и скорость обработки определяют выбор. Контекст, наоборот, почти не ограничивает. Один счёт или накладная укладываются в короткое окно. Качество нужно ровно настолько, чтобы стабильно доставать конкретные поля. А вот комплаенс критичен: в счетах и анкетах лежат паспортные данные и банковские реквизиты.
Как проверить выбор на своих данных
Матрица задаёт приоритеты. Итоговое решение подтверждается замером. Перед сменой модели проверьте, что дело в ней: качество ответа часто определяется промптом и поданными данными. Уточнить инструкцию или подключить поиск по базе знаний (RAG) дешевле, чем переходить на флагман.
Соберите 20–50 реальных примеров
Не синтетических, а из своего потока: настоящие тикеты, настоящие счета, настоящие фрагменты кода. Для каждого примера зафиксируйте правильный ответ руками. Это самая трудоёмкая часть, и пропустить её нельзя.
Замерьте три величины, а не одну
На каждой модели-кандидате измерьте долю правильных ответов по вашей разметке, время до первого токена и стоимость обработки ста задач. Одна метрика без двух других вводит в заблуждение. Дешёвая модель с точностью 60% требует ручной доработки и в сумме обходится дороже.
Считайте стоимость задачи, а не цену токена
Правильная единица сравнения — стоимость одной успешно решённой задачи. Она учитывает и повторные попытки, и долю брака. Модель вдвое дороже по прайсу выигрывает по результату, если ей хватает одной попытки вместо трёх. Приоритеты внутри одной категории тоже расходятся. Юридический анализ договоров требует более высокого качества, чем сверка типовых актов.
Одна модель на все задачи не нужна
Из матрицы следует практический вывод: разным задачам нужны разные модели. Поддержке нужна быстрая и недорогая модель. Анализу договоров — более сильная и с большим контекстом. Извлечению данных из счетов — оптимизированная под структурированный вывод (structured output).
Держать несколько прямых интеграций ради этого дорого. Каждая смена модели или подключение нового провайдера превращается в отдельный проект для разработки. Дополнительно возникает привязка к вендору (vendor lock-in): чем глубже конкретный API вшит в код, тем сложнее с него уйти.
Удобнее один шлюз, через который доступны разные модели, российские и зарубежные, с переключением под задачу без переписывания интеграции. Такой шлюз даёт платформа AIaaS от ITGLOBAL.COM. Это единый API к 100+ языковым моделям, квоты и бюджеты по подразделениям и пользователям, универсальные ИИ-кредиты как одна валюта для всех моделей и полное логирование запросов. Данные обрабатываются в России, работа идёт в соответствии с требованиями 152-ФЗ.
Для сценариев, где нужен изолированный контур и дообучение на своих данных, подойдёт Private AI Cloud на инфраструктуре ITGLOBAL. Если модель разворачивается своими силами, посмотрите инференс нейросетей в облаке и наш гид по открытым моделям для одного сервера NVIDIA HGX.
Единая точка доступа снимает главное препятствие для замера из предыдущего раздела. Прогнать пять моделей на своих примерах становится вопросом смены одного параметра, а не пяти интеграций.
Предыдущая статья
