←Все статьи блога
бенчмарк·16 сентября 2026 г.·7 мин чтения·6 просмотров

Как выбрать нейросеть по чеку и секундомеру: мануал теста «цена и скорость

Почему самая умная модель разоряет на трафике и как за 15 минут найти ту, что отвечает быстро, дёшево и без галлюцинаций.

Как выбрать нейросеть по чеку и секундомеру: мануал теста «цена и скорость

Балл качества в пресс-релизе — это только половина картины. Модель может блестеть бенчмарками (тестами сравнения производительности) на красивых графиках, но разорять вас на каждом запросе. Представьте два такси до аэропорта. Одно приезжает за 20 минут и стоит 1500 рублей. Второе — за 40 минут, зато за 500. Если вам ехать каждый день, второй вариант выгоднее втрое, даже если салон чуть скромнее.

Шаг 1. Что именно мы меряем под капотом вашего запроса

Тест «цена и скорость» фиксирует две цифры для одного типичного обращения к модели. Первая цифра — задержка (latency, время ожидания). Это сколько миллисекунд проходит от нажатия кнопки Enter до появления первого символа ответа. Важно понимать разницу: Time to First Token (первый токен — минимальная единица текста, например часть слова или знак препинания) показывает ощущение скорости для пользователя, а среднее время генерации всей страницы влияет на пропускную способность сервера. Вторая цифра — стоимость. Провайдеры считают её не за весь ответ, а за токены. Вам выставляют счёт за миллион входных токенов (то, что вы отправили модели) и за миллион выходных (то, что она сгенерировала в ответ).

Возьмём реальный пример из свежих тарифов одной крупной китайской модели: отправка миллиона токенов обходится в 0,27 доллара, а генерация такого же объёма в ответ — в 1,1 доллара. Кажется копейками, пока эти копейки не умножаются на ваш трафик. На тысячу запросов в сутки лишние 2 рубля превращаются в 60 тысяч в месяц. Скорость тоже обманчива: разница между 300 и 800 миллисекундами незаметна при ручном вводе, но когда у вас пиковая очередь из ста одновременных обращений, вторая модель просто захлебнётся, выстроив ваших пользователей в цифровую пробку.

Шаг 2. Как читать цифру: считаем реальную экономику проекта

Смотрите не на абсолютное число, а на соотношение с качеством ответов. Если баллы двух моделей на вашем наборе данных отличаются всего на 3–5%, а разница в цене — в три раза, выбор очевиден. Но чтобы увидеть эту картину, нужно перевести абстрактные доллары за миллион токенов в понятный кэш.

Формула предельно проста. Берёте средний размер вашего промпта (запроса), допустим, 150 слов (около 200 токенов), и средний размер ответа — ещё 300 токенов. Считаете цену одного полного цикла диалога по тарифам провайдера. Затем берёте свой реальный объём: дневной пик, суточный объём и месячный прогноз. Умножаете.

Теперь добавляем математику задержки. Если ваша система делает сто параллельных запросов, а модель отвечает за 800 мс, последний клиент в очереди будет ждать десятки секунд. Если модель отвечает за 200 мс, вся пачка улетит меньше чем за секунду. В ИТ-инфраструктуре часто важнее не абсолютная скорость, а соотношение скорости к ресурсам — точно так же, как в вычислительной технике для космоса критично соотношение скорости к ваттам энергии из-за их жёсткой ограниченности.

Чего этот тест НЕ показывает, потому что он измеряет только таксометр и спидометр. Он молчит о галлюцинациях (когда ИИ уверенно придумывает несуществующие факты). Быстрая и дешёвая модель так же уверенно изобретёт несуществующий метод API, как и дорогая. Он не проверяет умение держать контекст длинного диалога на пять страниц и соблюдение ваших строгих правил формата вроде обязательного JSON-ответа. Дешевизна не гарантирует адекватность.

Шаг 3. Собираем стенд: замеряем свои логи и ставим потолок

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

Теперь ставим жёсткий потолок бизнеса. Например: не дороже 1,5 рубля за полный цикл запроса и не дольше 400 миллисекунд до первого токена при средней нагрузке. Эти числа зависят от вашей экономики. Если вы продаёте подписку, у вас есть вилка маржи. Если крутите бесплатный чат-бот для лидогенерации, каждая лишняя секунда ожидания режет конверсию.

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

Шаг 4. Прогоняем сотню кейсов и ловим невидимые баги

Запускаем наш пул из ста реальных запросов через собранный стенд. Обязательно включаем режим потоковой передачи (streaming) — когда слова печатаются на экране по мере готовности, пользователь воспринимает такой ответ в два раза быстрее, даже если общее время генерации то же самое.

Фиксируем метрики. Время отклика смотрим не в вакууме, а под нагрузкой вашей пиковой очереди — имитируем хотя бы десять одновременных потоков. По стоимости сверяемся с данными маршрутизатора и биллингом провайдера — иногда они расходятся на комиссиях облачного посредника. А дальше начинается самое важное: руками размечаем ответы. Не смотрите на общие бенчмарки индустрии, оценивайте применимость к своей задаче. Сколько ответов пришли в нужном формате? Сколько содержали фактические ошибки? Насколько сильно модель ушла от роли?

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

Что сделать завтра утром

Вам не нужно писать код целый спринт. Откройте терминал и выполните четыре действия.

Первое: вытащите из базы 50 последних диалогов с пользователями вместе с их реальным ценником и временем ответа. Рассчитайте среднюю стоимость одного полезного ответа (если из десяти попыток бот дал один нормальный результат, реальная цена — ценник всех десяти попыток).

Второе: зарегистрируйте бесплатный аккаунт в сервисе-посреднике вроде LiteLLM. Подключите туда ключи от двух-трёх самых обсуждаемых бюджетных моделей этого месяца и двух дорогих лидеров рынка.

Третье: напишите простейший скрипт на 20 строк, который возьмёт ваши 50 диалогов и прогонит их через все подключенные модели. Зафиксируйте таблицу: название модели, средняя задержка, цена за 1000 токенов, процент ответов без галлюцинаций.

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