Чтобы понять, во сколько обходится один запрос и сколько ждать ответа, нужно сделать два независимых замера на своём сценарии. Сначала измерьте время от отправки запроса до получения последнего токена ответа на нескольких повторах и возьмите медиану. Затем возьмите из ответа API число входных и выходных токенов, умножьте каждое на цену из прайс-листа провайдера и сложите. Сравнивайте варианты по паре этих чисел, а не по одному показателю.
Какие метрики задержки и стоимости нужно фиксировать
Задержка и стоимость — это не одно число, а набор измеримых величин. Если упустить хотя бы одну, сравнение провайдеров получится однобоким.
Для задержки важны четыре показателя. Time to first token (TTFT) — время от отправки запроса до прихода первого токена ответа. Оно определяет, как быстро пользователь увидит начало ответа. Общее время ответа — от отправки до последнего токена. Скорость генерации (tokens per second) показывает, насколько быстро модель выдаёт текст после первого токена. И наконец, перцентили: p50 (медиана), p95 и p99. Среднее арифметическое здесь плохой помощник: один медленный запрос из двадцати может сильно исказить картину, а p95 покажет, что чувствует каждый двадцатый пользователь.
Стоимость складывается из цены за входные (prompt) и выходные (completion) токены. Входные токены — это ваш запрос плюс системный промпт и история диалога. Выходные — сгенерированный ответ. Провайдеры обычно берут за выходные токены в несколько раз больше, чем за входные. Считайте не только цену одного запроса, но и цену 1000 запросов или месячного объёма — так проще сопоставлять с бюджетом. Не забудьте про скрытые расходы: повторные попытки при ошибках, кэширование промптов (иногда дешевле), стриминг (влияет на восприятие, но не на цену токенов).
Отделяйте сетевую задержку от времени работы модели. Пинг до сервера провайдера может добавлять десятки миллисекунд, а очередь на стороне сервиса — секунды в часы пик. Чтобы понять, где узкое место, замеряйте время до первого байта ответа и сравнивайте с TTFT из документации, если провайдер его публикует.
Как корректно провести замер: методика и инструменты
Чтобы цифры были сравнимыми, замеряйте на одном и том же наборе запросов с одинаковыми параметрами генерации. Вот пошаговый процесс.
- Подготовьте фиксированный набор промптов. Возьмите 5–10 запросов разной длины: короткий вопрос, средний запрос с контекстом, длинный с историей. Зафиксируйте параметры: temperature, max_tokens, top_p. Для всех провайдеров они должны совпадать.
- Сделайте прогрев. Первый запрос к новому API часто медленнее из-за установки соединения и холодного старта. Отправьте 2–3 пробных запроса и не учитывайте их в результатах.
- Повторите каждый замер 10–20 раз. Записывайте время до первого токена и общее время ответа. Используйте
time.perf_counter()в Python или аналогичный высокоточный таймер. Не полагайтесь на время, которое возвращает сам API, — оно может не включать сетевую задержку. - Отбросьте выбросы. Если один замер оказался в 5 раз дольше остальных, проверьте, не было ли сетевого сбоя или rate limit. Такие точки лучше исключить или зафиксировать отдельно.
- Посчитайте перцентили. Отсортируйте значения и возьмите 50-й, 95-й и 99-й процентили. Медиана покажет типичный опыт, p95 — хвостовые задержки.
Инструменты могут быть разными. Простейший вариант — собственный скрипт на Python с библиотекой requests или httpx и замером времени вокруг вызова. Для нагрузочного тестирования подойдут locust или k6, но они требуют аккуратности: не создавайте лишнюю нагрузку на API, если провайдер ограничивает частоту запросов. Если сервис поддерживает стриминг, TTFT можно замерить по приходу первого чанка в потоке. Сверьтесь с официальной документацией провайдера насчёт лимитов (rate limits) и правил тестирования, чтобы не заблокировать ключ.
Учитывайте, что стриминг меняет воспринимаемую скорость: пользователь видит первые слова почти сразу, даже если полный ответ генерируется дольше. Поэтому для интерактивных сценариев TTFT важнее общего времени, а для пакетной обработки — наоборот.
Формулы расчёта стоимости и пример на конкретных цифрах
Стоимость одного запроса считайте по формуле:
Стоимость = (входные токены × цена входа + выходные токены × цена выхода) / 1 000 000
Цены берите из прайс-листа провайдера на дату замера. Например, если провайдер указывает 3 доллара за миллион входных токенов и 15 долларов за миллион выходных, а ваш запрос содержит 500 входных и 300 выходных токенов, то:
500 / 1 000 000 × 3 + 300 / 1 000 000 × 15 = 0,0015 + 0,0045 = 0,006 доллара за запрос.
Тысяча таких запросов обойдётся примерно в 6 долларов. Если ответ вырастет до 1000 выходных токенов, стоимость станет 0,0015 + 0,015 = 0,0165 доллара, а задержка обычно увеличится — оба числа придётся перемерить.
Не забывайте про повторные попытки. Если 5% запросов завершаются ошибкой и вы отправляете их заново, фактическая стоимость вырастает на эти 5% (при условии, что неудачные попытки тоже тарифицируются — уточняйте в документации). Кэширование промптов может снизить цену входных токенов, если провайдер его поддерживает.
Сведите задержку и стоимость в одну таблицу, чтобы сравнивать варианты наглядно. Пример для двух гипотетических провайдеров:
| Параметр | Провайдер A | Провайдер B |
|---|---|---|
| Цена за 1 млн входных токенов | 3 доллара | 5 долларов |
| Цена за 1 млн выходных токенов | 15 долларов | 10 долларов |
| Стоимость запроса (500 вход / 300 выход) | 0,006 доллара | 0,0055 доллара |
| Медиана TTFT | 0,8 с | 1,2 с |
| Медиана общего времени | 2,4 с | 3,1 с |
| p95 общего времени | 4,0 с | 5,5 с |
В этом примере провайдер B чуть дешевле, но заметно медленнее. Выбор зависит от сценария: для чат-бота важнее TTFT и p95, для ночной пакетной обработки — стоимость.
Где брать актуальные тарифы и данные о задержке
Единственный надёжный источник — официальные страницы провайдера: pricing, документация по API и status-страница с информацией о доступности и SLA. Сторонние обзоры и новости технологий могут отставать на недели, а тарифы меняются часто. Всегда фиксируйте дату, на которую вы сверили цифры. Например, для этой статьи тарифы проверены 12 ноября 2026 года, но перед использованием в расчётах откройте прайс-лист заново.
Если провайдер публикует исторические данные о задержке (например, в статус-панели), используйте их как ориентир, но не как замену собственному замеру: ваш сетевой путь и нагрузка могут отличаться. Для сравнения нескольких провайдеров удобно завести таблицу с датой проверки и ссылкой на источник.
Типичные ошибки при измерении и как их избежать
- Сравнение на разных промптах. Если вы замерили задержку у провайдера A на коротком вопросе, а у B — на длинном, сравнение недействительно. Используйте одинаковый набор запросов.
- Игнорирование p95. Средняя задержка может выглядеть прилично, но если каждый двадцатый ответ приходит в три раза дольше, пользователи это заметят. Всегда смотрите на хвостовые перцентили.
- Замер на одном запросе. Один замер ничего не говорит о стабильности. Нужна серия из 10–20 повторов с прогревом.
- Забытые ретраи. Повторные попытки увеличивают и время, и стоимость. Учитывайте их в расчётах, если ваш код делает повторы.
- Смешение сетевой задержки и времени модели. Если вы находитесь далеко от сервера, сетевая задержка может составлять значительную долю TTFT. Замеряйте время до первого байта отдельно, чтобы понять вклад сети.
Вопрос: Можно ли использовать среднее время ответа вместо медианы?
Среднее сильно искажается редкими долгими запросами. Медиана устойчивее и лучше описывает типичный опыт. Для оценки хвостовых задержек добавляйте p95.
Вопрос: Как учесть стоимость, если провайдер тарифицирует по запросам, а не по токенам?
Тогда формула упрощается: цена запроса = тариф за запрос. Но проверьте, нет ли ограничений по длине контекста или скрытых доплат за длинные ответы.
Вопрос: Что делать, если API не возвращает число токенов?
Многие провайдеры возвращают usage в ответе. Если нет, оцените количество токенов с помощью библиотеки-токенизатора, подходящей для модели, или приблизительно: для английского текста один токен ≈ 4 символа, для русского соотношение иное. Точный расчёт возможен только через токенизатор.
Вопрос: Влияет ли стриминг на стоимость?
Нет, стриминг меняет только способ доставки. Тарификация идёт по количеству токенов, если провайдер не указал иное. Однако стриминг может снизить воспринимаемую задержку, поэтому для интерактивных сценариев его стоит включить.