Что определяет стоимость встроенной модели: 61 977 рабочих вызовов

С 29 мая по 27 августа 2026 года наша система сделала 61 977 обращений к языковым моделям в рабочем режиме — не в тесте, а на живых пользовательских запросах. Каждое обращение логируется: поверхность, провайдер, язык, число токенов на входе и выходе, время ответа, попал ли запрос в кэш.

Чего здесь нет: денег. Поле стоимости у двух основных провайдеров не заполняется — 31 796 вызовов записаны с нулём. Это пробел в нашем учёте, а не бесплатная услуга, и выдавать эти нули за расходы мы не станем. Поэтому дальше речь о токенах и о доле кэша — величинах, которые измерены достоверно.

Это, впрочем, не потеря. Главный рычаг стоимости — не цена за токен, а доля запросов, которые до провайдера вообще не доходят. Её мы измерили точно.

Из 61 977 обращений 30 119 (48,6%) отданы из кэша и до провайдера не дошли. Помесячно:

Доля выросла с 23% до 52% за три месяца, и механизм здесь простой: кэш работает тем лучше, чем больше запросов уже прошло. Ключ строится по содержимому запроса, поэтому каждый новый пользователь, спрашивающий про уже проверенный объект, получает ответ бесплатно.

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

В токенах это примерно 37 миллионов, которые не были отправлены и не были оплачены — оценка по среднему размеру обращения в нашей выборке.

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

Разница объясняется повторяемостью входа. У статей вход — сам текст статьи, он один и тот же для всех читателей, отсюда 82%. У проверки заголовков вход — полный набор заголовков конкретного сайта в конкретный момент; он не повторяется почти никогда, отсюда 1%.

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

Три наблюдения.

Вход втрое больше выхода. На один токен ответа приходится примерно три с половиной токена запроса. Поскольку у большинства провайдеров вход дешевле выхода, но не в три с половиной раза, сокращение промпта обычно выгоднее сокращения ответа — а оптимизируют чаще второе.

Ответ занимает секунды, а не миллисекунды. 3,9 и 5,4 секунды в среднем — это на два порядка дольше, чем отвечают наши обычные инструменты, где медиана 95 мс. Встраивая модель в интерфейс, надо исходить из того, что ответ придёт через секунды, и показывать это пользователю.

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

Русских обращений 60 545, английских 1 432 — соотношение 42 к 1. Это отражает состав аудитории, а не качество моделей, но имеет прямое следствие для расходов: основная нагрузка приходится на провайдера, обслуживающего русский язык, и его тарифы определяют счёт почти целиком.

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

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

Оговорка о применимости: это данные одного продукта с конкретным набором задач. Доля кэша в 48,6% — наша, а не отраслевая; у продукта с уникальным входом на каждом запросе она будет околонулевой.