Как выбрать нейросеть по чеку и секундомеру: мануал теста «цена и скорость
Почему самая умная модель разоряет на трафике и как за 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 токенов, процент ответов без галлюцинаций.
Четвёртое: выберите победителя не по самому высокому качеству, а по лучшему соотношению «процент корректных ответов делить на цену». Установите его моделью по умолчанию в боевую среду на следующую неделю. Через семь дней сравните счёта от провайдеров и жалобы пользователей в поддержку. Этот единственный цикл даст вам больше понимания реальной экономики продукта, чем чтение десятка статей о новых архитектурных прорывах.