Экономика ИИ: стоимость запросов, задержки, кэширование, архитектура под нагрузку

Коротко по статье:

• «Дешево за токен» ≠ «дешево за лид»: деньги уходят на частоту вызовов, объем токенов и хвосты задержек, которые бьют по конверсии.
• «Цена за 1M токенов» скрывает структуру: паразитные повторы системных правил и «чистые» запросы при одинаковых токенах стоят по-разному.
• Платите за input/output и тяжелый prefill длинного входа; оптимизация начинается с сокращения системной части и ограничения контекста.
• Длинная история диалога — анти-экономика: состояние лучше хранить вне модели (JSON/поля, резюме, 1–2 факта).
• Латентность складывается из сети, очередей, prefill, генерации, постобработки и ретраев; важнее P95/P99 и деградация без каскада повторов.
• Кэширование промпта дает сильный эффект при «стабильном префиксе»: правила/формат сначала, переменные данные в конце; под нагрузкой помогают слои маршрутизации, дедлайны, идемпотентность и приоритеты.

Определение

Экономика LLM-продукта для media buying в 2026 — это управление стоимостью и задержками не через «самую умную модель», а через структуру вызовов, длину input/output и повторяемость префикса для кэша. На практике строят дешевый слой (классификация/валидация/маршрутизация) → компактный промпт со стабильными правилами → кэш → эскалация на дорогую модель только при необходимости, с дедлайнами, ограниченными ретраями и внешним хранением состояния.

Содержание

• Экономика LLM-запросов в 2026: почему «дешево за токен» не равно «дешево за лид»
• Сколько на самом деле стоит один запрос и почему метрика «цена за 1M токенов» обманывает?
  • Что именно вы оплачиваете: input, output и «префилл»
  • Почему «длинная история диалога» почти всегда анти-экономика
• Задержки: где теряются миллисекунды и как это бьет по открутке
  • Почему «один длинный запрос» иногда быстрее «трех коротких»
  • Где рождаются «хвосты» и почему среднее время вас обманывает
• Кэширование промптов: когда это дает x10 по бюджету
  • Как провайдеры кэшируют и почему важен «стабильный префикс»
  • Какой контент нужно «замораживать» в начале промпта
• Как спроектировать архитектуру под нагрузку, если у вас 10–100 RPS и пики по событиям?
  • Нужен ли вам один провайдер или минимум два?
  • Где хранить состояние, чтобы не платить токенами за память?
• Рейт-лимиты, очереди, ретраи: безопасная деградация без слома воронки
  • Идемпотентность и дедлайны как защита бюджета
  • Очереди и приоритизация: что должно проходить первым
• Таблица сравнения прайсов 2026 и что из этого следует
• Таблица расчетов: бюджет на 1 млн запросов и эффект кэша
• Под капотом: KV-кэш, chunked prefill и почему длинный контекст — это налог
  • Малоочевидный факт №1: эффективность KV-кэша решает, сколько одновременных запросов выдержит одна GPU
  • Малоочевидный факт №2: FlashAttention ускоряет attention именно за счет памяти, а не «магии»
  • Малоочевидный факт №3: chunked prefill и непрерывный batching — это причина, почему «много мелких запросов» иногда выгоднее группировать
• Практическая схема для media buying-команды: от идеи до продакшна

В 2026 году «экономика ИИ» для media buying-команд перестала быть разговором про «сколько стоит модель». Реальные деньги сгорают на стыке трех вещей: как часто вы дергаете модель, сколько токенов вы гоните в каждом запросе, и какой хвост задержек вы сами себе создаете архитектурой. Для арбитража трафика это особенно чувствительно: лишние 300–600 мс в критическом месте превращаются не в «медленнее», а в «падает конверсия и растет цена показа/клика при том же бюджете».

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

Экономика LLM-запросов в 2026: почему «дешево за токен» не равно «дешево за лид»

Цена токенов — это только нижняя часть айсберга. Над ней всегда лежат «скрытые статьи»: повторная обработка одинаковых инструкций, прогрев контекста на каждом шаге, каскадные ретраи, очереди, распухшие логи, вызовы инструментов/поиска, а иногда и лишние модели «на всякий случай».

В прикладных задачах маркетинга (генерация связок, анализ креативов, нормализация фидов, саппорт-боты, модерация, антифрод-объяснения) стоимость чаще всего определяется не одним большим ответом, а большим количеством коротких и средних запросов. Поэтому выигрывает не тот, кто «взял самую умную модель», а тот, кто построил дешевую траекторию: быстрый фильтр → компактный промпт → кэш → эскалация на более дорогую модель только при необходимости.

Совет эксперта от npprteam.shop, маркетинговый аналитик: "Если вы не можете внятно назвать, какой процент запросов у вас можно сделать на «дешевом слое» без потери качества, значит вы платите за интеллект там, где нужен контроль процесса и нормальная инженерия."

Сколько на самом деле стоит один запрос и почему метрика «цена за 1M токенов» обманывает?

«Цена за 1M токенов» полезна только как линейка, но она скрывает структуру запроса. Два вызова с одинаковым количеством токенов могут стоить одинаково по прайсу, но один будет «паразитным» (повторяете один и тот же системный текст и длинные правила каждый раз), а другой — «чистым» (передаете только меняющиеся данные и получаете короткий ответ). В реальности вы покупаете не токены, а повторяемые вычисления.

Что именно вы оплачиваете: input, output и «префилл»

У провайдеров вы почти всегда платите отдельно за входные и выходные токены. Важная деталь: длинный вход — это не просто «длиннее текст», это тяжелый этап прогона префикса (prefill), который и по времени, и по железу чувствуется сильнее, чем кажется по счетчику токенов. Поэтому оптимизация начинается с входа: сокращение системной части, перенос «редко меняющегося» в кэш, и жесткое ограничение на то, что вы отправляете в контекст.

Почему «длинная история диалога» почти всегда анти-экономика

Многие команды по привычке тащат целиком историю сообщений, потому что «так надежнее». На практике это самый дорогой способ «помнить». Экономичнее хранить состояние вне модели: структурированные поля (JSON в базе), короткое резюме, и только 1–2 последних факта, которые реально влияют на ответ.

Задержки: где теряются миллисекунды и как это бьет по открутке

Почти любая задержка в ИИ-цепочке — это сумма нескольких хвостов: сеть до провайдера, очередь на стороне провайдера, префилл длинного входа, генерация токенов, постобработка, и ваши же повторные вызовы из-за таймаутов. В 2026 это выглядит особенно контрастно: модели стали быстрее, но приложения стали «агентнее», то есть начали делать больше шагов на одно действие пользователя.

Почему «один длинный запрос» иногда быстрее «трех коротких»

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

Где рождаются «хвосты» и почему среднее время вас обманывает

В продакшне важнее P95/P99, чем среднее. Для маркетинга это выглядит так: среднее «норм», но редкие пики превращают часть сессий в «подвисло», а вы потом лечите это ретраями — и получаете двойную оплату за один и тот же результат. Архитектура должна уметь деградировать: если ответ не успел, вы отдаете упрощенный результат или задерживаете не критичную часть, а не запускаете каскад повторов.

Кэширование промптов: когда это дает x10 по бюджету

В 2026 кэширование промптов у крупных провайдеров — не экзотика, а базовый инструмент. Смысл простой: если первые N токенов запроса повторяются (стабильный префикс), провайдер может переиспользовать вычисления и дать скидку по цене входа плюс ускорение по времени.

Как провайдеры кэшируют и почему важен «стабильный префикс»

У OpenAI промпт-кэширование применяется автоматически для длинных промптов и работает как переиспользование вычислений по повторяющемуся префиксу; в статистике ответа это отражается как cached tokens, а эффект заявляется как существенное снижение стоимости входа и ускорение (в документации упоминаются большие проценты ускорения/экономии при корректном повторе префикса).

У Anthropic кэширование включается через cache_control и поддерживает TTL (например, короткий и более длинный срок), при этом в прайсе отдельно видны «cache writes» и «cache hits/refreshes», то есть вы можете управлять тем, за что платите: запись в кэш дороже, чтение (попадание) дешевле.

Какой контент нужно «замораживать» в начале промпта

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

Совет эксперта от npprteam.shop, маркетинговый аналитик: "Считайте кэш не как «опцию провайдера», а как архитектурный контракт: стабильное сначала, переменное в конце. Если вы не можете гарантировать стабильность первых 1–2 тысяч токенов, кэш почти не сработает."

Как спроектировать архитектуру под нагрузку, если у вас 10–100 RPS и пики по событиям?

Архитектура под нагрузку в ИИ — это не «больше серверов», а правильное разделение траекторий. Вы должны заранее решить, какие запросы идут в быстрый слой, какие можно поставить в очередь, какие требуют строгого дедлайна, и какие можно заменить приближенным ответом.

Нужен ли вам один провайдер или минимум два?

Если у вас performance-контур (автогенерация текстов для открутки, ответы в интерфейсе, автоанализ), один провайдер — это единая точка риска по лимитам и деградации. Практичный компромисс: основной провайдер + резервный для «план Б» на уровне критичных функций. Важно не плодить зоопарк: достаточно двух траекторий с одинаковым форматом входа/выхода.

Где хранить состояние, чтобы не платить токенами за память?

Ключевой прием — вынести память из модели. Храните состояние задачи как набор полей: гипотеза, ограничения, черновик, статус проверки, причины отказа. Модель получает только то, что нужно для следующего шага, а не роман на 20 тысяч токенов.

Рейт-лимиты, очереди, ретраи: безопасная деградация без слома воронки

В 2026 почти все провайдеры и платформы имеют лимиты по запросам и токенам, а также периодические очереди на пиках. Ошибка — лечить это «ретраями до победы». Правильнее строить защитные механики: дедлайны, джиттер, идемпотентность, контроль повторов, и приоритеты.

Идемпотентность и дедлайны как защита бюджета

Если один и тот же запрос может быть отправлен повторно из-за таймаута, он должен быть идемпотентным: повтор не должен запускать новую дорогую работу без необходимости. Дедлайн нужен жесткий: если ответ не успел, вы возвращаете безопасный упрощенный вариант и продолжаете работу асинхронно, а не сжигаете бюджет в хвосте.

Очереди и приоритизация: что должно проходить первым

Приоритизация в маркетинге обычно проста: пользовательский интерфейс и критичные операции идут первыми; аналитика, переоценка кампаний и «полировка текста» — вторыми. Самое дорогое — когда второстепенная задача забивает очередь и начинает вытеснять критичную.

Таблица сравнения прайсов 2026 и что из этого следует

Ниже — ориентиры по публичным прайсам на 2026 (в пересчете на 1M токенов). Эти цифры полезны не для выбора «самого дешевого», а для проектирования слоев: где использовать кэш, где держать короткий ответ, где ограничивать контекст, где переносить работу в пакетный режим.

Таблица расчетов: бюджет на 1 млн запросов и эффект кэша

Чтобы оценивать бюджет честно, полезно считать не «токены вообще», а типовой профиль запроса. Возьмем распространенный сценарий: на один запрос вы отправляете 800 входных токенов и получаете 200 выходных. Это похоже на задачу «дать структурированный ответ с проверкой формата». Для кэша допустим, что 600 из 800 входных — стабильный префикс (правила/формат), а 200 — переменные данные.

Практический вывод для media buying-команды: если вы можете стандартизировать формат ответа и «заморозить» правила в начале промпта, кэширование превращается в прямую экономию на частотных сценариях. Если вы еще и ограничиваете длину ответа (например, требуете строго JSON/табличный формат и запрет на лишний текст), то стоимость становится предсказуемой и масштабируется без сюрпризов.

Под капотом: KV-кэш, chunked prefill и почему длинный контекст — это налог

Большая часть затрат по времени и памяти в генерации связана с attention и хранением ключей/значений (KV cache) для уже прочитанного контекста. Поэтому инфраструктурные идеи вроде PagedAttention (vLLM) появились не «для красоты», а чтобы обслуживать больше запросов на той же памяти, уменьшая потери KV-кэша и повышая пропускную способность. В продакшне это означает простую вещь: ваша привычка тащить длинный контекст буквально превращается в налог на каждую следующую генерацию.

Малоочевидный факт №1: эффективность KV-кэша решает, сколько одновременных запросов выдержит одна GPU

Сервинг-системы оптимизируют размещение KV-кэша, потому что именно он часто ограничивает параллелизм. Когда KV-кэш расходуется неэффективно, вы платите не только за токены, но и за «пустое место» в памяти, которое не приносит результатов.

Малоочевидный факт №2: FlashAttention ускоряет attention именно за счет памяти, а не «магии»

Ускорение внимания достигается снижением дорогих операций чтения/записи между GPU-памятью и on-chip памятью. Для вас это прикладно: оптимизация контекста и батчинга может дать такой же эффект, как «переехать на более дорогую модель», только дешевле.

Малоочевидный факт №3: chunked prefill и непрерывный batching — это причина, почему «много мелких запросов» иногда выгоднее группировать

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

Практическая схема для media buying-команды: от идеи до продакшна

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

Внутри приложения вы храните состояние задач отдельно: что уже сделано, какие ограничения, какие варианты отброшены и почему. Тогда модель работает как вычислитель, а не как «память и менеджер проекта». Это снижает стоимость, уменьшает задержки и делает качество стабильнее.

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