Какую LLM выбрать под задачи компании в 2026, если считать цену за токен, а не только качество ответов?

Собрали и сравнили варианты по критериям, чтобы вы не тратили время. Методология — ниже.

Цена за токен в прайс-листе не равна стоимости задачи: одна и та же операция на разных моделях требует разного числа токенов из-за длины reasoning-цепочек, повторов и ретраев. Плюс к этому — кэширование промптов, батчи, курс валюты и тарифы на выходные токены, которые обычно дороже входных в 3–5 раз. Без замера токенов на своём трафике сравнение моделей по цене превращается в угадывание.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Почему цена за токен не равна стоимости задачи

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

Линейную арифметику «цена × объём» ломают три вещи.

• Длина reasoning-цепочек. Модели с рассуждениями выдают в 5–20 раз больше выходных токенов на ту же задачу. Платите за размышления, а не за ответ.
• Выходные токены дороже входных. Ориентир: у большинства провайдеров выход дороже входа в 3–5 раз. Прайс меняется, сверяйтесь с актуальным.
• Ретраи. Ответ не прошёл валидацию по формату, JSON сломался, модель ушла в отказ. Каждый повтор — полный прогон, и он в счёте.

Рабочая единица измерения — стоимость одной успешной задачи. Не тысяча токенов, не «цена за миллион». Суммарные расходы на все попытки, делённые на число принятых результатов. Остальное — маркетинг провайдера.

Дальше — как собрать замер, что логировать и как выбрать модель под свой трафик. Без магии, но с ручной работой на один-два вечера.

Как собрать эталонный набор запросов для замера

Набор из 50–200 запросов даёт устойчивую картину по стоимости задачи без больших затрат. Меньше — шум. Больше — уже мониторинг, для выбора не нужно.

Откуда брать запросы:

• Логи прототипа за последнюю неделю-две. Живые формулировки, а не придуманные в Notion.
• Тикеты поддержки, если задача — разбор обращений.
• Выгрузка из CRM или очереди, если LLM работает в операционном контуре.

Дальше фиксируете эталонные ответы. Вручную или с тем, кто эту задачу принимает в проде. Важна не красота, а критерий приёмки: что считаем годным ответом, что нет. Без этого порога не посчитаете долю неуспешных прогонов, а без неё стоимость задачи врёт.

И третье — распределение типов задач. Если 80% трафика — короткая классификация, а 20% — сложный разбор, средняя цена по набору будет нерелевантна, если вы набрали одних сложных. Набирайте пропорционально реальному трафику. Иначе выберете модель под задачу, которой у вас почти нет.

Набор запросов — это не тест на сообразительность модели, а слепок вашей нагрузки. Ошибка на этом шаге обнуляет весь дальнейший расчёт.

Что логировать при прогоне моделей-кандидатов

Прогоняете набор через 3–4 модели. Не через десять — утонете в разборе. Три-четыре кандидата закрывают вопрос выбора.

По каждому запросу и каждой модели пишете:

1. Input-токены и output-токены отдельно. Не общее число, а раздельно — выход дороже.
2. Число ретраев и причину отбраковки. «Не прошёл валидацию», «не тот формат», «отказ».
3. Латентность. Она не про деньги, но если ответ идёт 20 секунд, а UX требует 3, модель не подходит независимо от цены.
4. Стоимость одной успешной задачи. Считаете по формуле ниже.

Формула стоимости успешной задачи:

(средние входные токены × тариф входа + средние выходные токены × тариф выхода) × коэффициент ретраев

Коэффициент ретраев — единица плюс доля неуспешных прогонов. Если каждая пятая попытка уходит в повтор, коэффициент 1,2. Арифметика простая, но именно её никто не делает, когда сравнивает модели по прайсу.

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

Если нужен инструмент для прогона и логирования, посмотрите набор для оценки LLM — там про замер на своём трафике, а не про бенчмарки.

Кэш промптов и батчинг: где реальная экономия

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

Что проверить на своём профиле:

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

Батчинг — второй рычаг, но с оговоркой. Он уместен там, где ответ не нужен в реальном времени: ночная обработка выгрузок, массовая классификация, обогащение базы. Если пользователь ждёт ответ в интерфейсе, батч ломает UX. Не гонитесь за скидкой в ущерб продукту.

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

Роутинг между моделями: дешёвая на простое, дорогая на сложное

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

Критерии отнесения запроса к простым задаёте сами, но обычно это:

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

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

И обязательный пункт — мониторинг доли ошибок после роутинга. Роутер сам может ошибаться: отправит сложный запрос на дешёвую модель, та выдаст мусор, вы получите ретрай и потеряете и деньги, и время. Считайте долю отбраковок по каждой ветке отдельно.

Роутинг окупается на объёме. На малых нагрузках сложность инфраструктуры съест экономию — см. раздел ниже.

Российские провайдеры и валютный фактор

Для SMB в РФ экономика считается в рублях, а прайс у части провайдеров привязан к валюте. Это добавляет в бюджет статью, которую никто не закладывает.

• Тарифы в рублях и ассортимент. Не все модели доступны у российских провайдеров. Иногда выбор сужается до двух-трёх вариантов, и это нормально — считайте по ним.
• Курсовые колебания. Закладывайте запас в бюджет. Если тариф в валюте, рост курса на 10% — это рост вашей себестоимости на 10%, и он не спросит разрешения.
• Лимиты контекста и скорости. У разных провайдеров они отличаются. Длинный контекст может быть недоступен или стоить иначе. Проверяйте на своём наборе, а не по описанию.

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

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

Как пересчитывать экономику при росте объёмов

Выбор модели — не разовое решение. То, что было выгодно на старте, перестаёт работать при росте.

• Скидки за объём и батчи. На больших нагрузках появляются тарифы, которых не было на малых. Пересматривайте прайс раз в месяц-два.
• Рост доли дорогих выходных токенов. Чем сложнее становятся задачи, тем длиннее ответы и рассуждения. Средняя стоимость задачи ползёт вверх.
• Периодический пересмотр. Раз в 4 недели прогоняйте эталонный набор заново. Модели обновляются, цены меняются, ваш трафик тоже.

Держите замер как регулярную процедуру, а не как разовый проект. Один вечер раз в месяц дешевле, чем год переплаты на каждом запросе.

Вердикт: если X — бери Y

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

Если трафик смешанный и есть объём — берите роутинг: дешёвая на простое, дорогая на сложное, с мониторингом отбраковок.

Если качество ни одной доступной модели не проходит порог — цена вторична. Сначала решаете задачу качества, потом считаете деньги.

Когда это не сработает

Подход не сработает, если у вас меньше сотни запросов в месяц. Накладные расходы на замер, логирование и роутинг превысят экономию. На таких объёмах берите одну модель, которая проходит приёмку, и не тратьте время на оптимизацию.

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

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

Что сделать через 10 минут

1. Откройте логи прототипа или продакшена. Выгрузите 50 запросов, пропорционально типам задач.
2. Зафиксируйте критерий приёмки: что считаете годным ответом. Одной строкой.
3. Прогоните набор через 3 модели-кандидата, логируя input/output-токены, ретраи и латентность.
4. Посчитайте стоимость успешной задачи по формуле выше. Сравните не цены, а результат.

Это один вечер работы. Дальше вы принимаете решение по своим данным, а не по чужому бенчмарку.

FAQ

Почему нельзя сравнивать модели просто по цене за миллион токенов?

Потому что модели тратят разное число токенов на одну и ту же задачу. Reasoning-модели генерируют длинные цепочки рассуждений, и выходных токенов может быть в 5–20 раз больше. Плюс ретраи. Цена за миллион — это вход в расчёт, а не ответ.

Что такое стоимость успешной задачи и как её считать?

Это суммарные расходы на все попытки получить приемлемый ответ, делённые на число принятых результатов. Включает входные и выходные токены, ретраи, повторные вызовы. Считается по логам, а не по прайс-листу.

Насколько кэширование промптов меняет экономику?

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

Стоит ли брать самую дешёвую модель и не усложнять?

Иногда да — если задача простая (классификация, извлечение полей, короткие ответы) и качество дешёвой модели проходит ваш порог. На сложных сценариях экономия на модели оборачивается временем сотрудников на правки ответов. Считайте не только токены, но и часы.

Как часто пересчитывать выбор модели?

Раз в 4 недели прогоняйте эталонный набор заново. Модели обновляются, цены меняются, ваш трафик растёт. Разовая оптимизация устаревает за месяц-два.

Сводная таблица

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

Риски и как их снять заранее

• Запуск без baseline и недельной аналитики — самый дорогой вариант, потому что непонятно, что лечить.
• Смешивание многих задач одновременно — обычно увеличивает календарные сроки и бюджет сверх суммы задач по отдельности.
• Слабая интеграция с точками истины данных (CRM, биллинг, тикет-системы) даёт красивый интерфейс и плохой бизнес-эффект.

Что сделать дальше

Короткая диагностика под ваш процесс: обычно 3 дня для малого бизнеса и до 5 дней для проектов со сложной воронкой и несколькими стейджами.

Быстрый расчет эффекта: (количество заявок × текущая стоимость обработки заявки) − (то же после внедрения целевой модели) + (дополнительные продажи × средняя маржа). Число получится грубым и полезным: оно задаёт экономику решения даже без идеальных данных.

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

• Запросить диагностику процесса: Открыть форму контактов PrimeCoder
• Получить план внедрения на 30 дней: Подключить AI Boost Team как внешний AI-офис с KPI

FAQ по теме статьи

Почему нельзя сравнивать модели просто по цене за миллион токенов?

Потому что модели тратят разное число токенов на одну и ту же задачу. Reasoning-модели генерируют длинные цепочки рассуждений, и выходных токенов может быть в 5–20 раз больше, чем у обычной модели. Итоговая стоимость задачи отличается сильнее, чем прайс за токен.

Что такое стоимость успешной задачи и как её считать?

Это суммарные расходы на все попытки получить приемлемый ответ, делённые на число принятых результатов. Включает входные и выходные токены, ретраи, повторные вызовы после ошибок валидации и расходы на препроцессинг. Считайте по логам, а не по прайс-листу.

Насколько кэширование промптов меняет экономику?

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

Стоит ли брать самую дешёвую модель и не усложнять?

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

Как учитывать курс валюты и тарифы российских провайдеров?

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

Что делать, если объём вырастет в 10 раз?

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

Дальше по теме платформы: смежные материалы (ROI / деньги)

Статью лучше читать в связке — так быстрее собирается картина, как ответ складывается в работающую воронку, а не в изолированный совет.

• Сколько стоит AI Boost Team в 2026
• ROI AI Boost Team: как считать
• AI-отдел на аутсорсе vs штат