Под крылом Linux Foundation появилось новое направление — Tokenomics Foundation. Фонд выпустил проект описания «Big‑T Notation» (автор — Ден Нефф, старший архитектор облачных решений в Adobe), в котором предлагается фреймворк для оценки и управления расходами на токены в LLM‑ и агентных системах — по аналогии с Big‑O в теории алгоритмов. Токены в бюджетировании обычно относят к категории «разберёмся потом» — примерно как когда‑то на заре Интернета веб‑разработчики относились к SQL‑запросам.

Проблема не в дороговизне токенов самих по себе, а в том, что этот рост сложно структурно предсказать и управленчески трудно контролировать. В статье разберём основные идеи Big‑T, а заодно проверим их на живых цифрах — прайс‑листе Yandex Cloud AI Studio. Реальные тарифы хорошо показывают, что «невидимые множители», о которых пишет автор фреймворка, — это не абстракция, а конкретные строки в биллинге.

Зачем потребовалась новая нотация

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

Методы анализа сложности и ранее применялись к ИИ, но почти всегда в контексте обучения: к стоимости обучения модели. Сколько токенов модель потребляет при каждом ответе на запрос в рамках заданной рабочей нагрузки — это уже другой вопрос, и до сих пор для него не существовало собственной терминологии. Нотация Big‑T призвана её создать. 

На чем основан подход и насколько стоит ему доверять

Фреймворк основан на исследованиях Flexpa и лаборатории MIT CSAIL. Они изучали, как LLM ищут и извлекают информацию, а также опыт использования маршрутизации моделей, кеширования и сериализации входных данных.

Короткое отступление для тех, кому (как и мне) нужно освежить в памяти, что такое Big‑O нотация

Big‑O — это способ описать, как растёт время работы (или память) алгоритма, когда становится больше входных данных. Не точное время в секундах, а именно характер роста. Например, нотация поможет ответить на вопрос: во сколько раз больше займет выполнение функции, если элементов будет не 10, а 1 000 000. 

На рисунке мы видим категории поведения алгоритмов при увеличении n. Визуализация помогает пониманию, как влияют усилия по оптимизации на результат.

Big‑T нотация

n — либо количество запросов, либо размер каждого запроса, либо и то и другое одновременно

k — число обращений к модели за один запрос

a — глубина дерева (цепочки) агентов

Big‑T нотация, аналогично Big‑O, помогает классифицировать рабочие нагрузки по тому, как растёт потребление токенов при увеличении объёма использования, усложнении задач или расширении автономности агентов.

Автор честно оговаривается, что нотацию, которую они предлагают, это не формальная математическая система, в ней нет теорем и доказательств. Вводные значения не имеют четкого определения — это и число запросов, и объем.

Рассмотрим классы сложности, которые автор представил в виде лестницы. Для упрощения понимания я добавила на каждый класс пример, как если бы речь шла не про ИИ агентов, а про сотрудников.

Лестница классов сложности

Ключевая метафора Big‑T — “лестница” классов, упорядоченных по скорости роста потребления токенов:

• T(1) — константа. Модель вообще не вызывается на каждый запрос (кеш, статический ответ) — аналог O(1).

  Пример: 

  Чтобы все новые гости и сотрудники не спрашивали «пароль от Wifi», ответ давно висит стикером на двери. Никто не отвлекает сотрудника, вопрос вообще не доходит до него. Сколько бы человек ни задали вопрос — расход времени сотрудника не растёт.

• T(log n) — сублинейный рост. Класс, который организации чаще всего упускают: правильно построенный RAG, где детерминированная фильтрация (например, с помощью SQL, эмбеддинг‑поиска) отсекает избыточные данные до передачи в модель. Автор приводят пример: сжатие объема данных с ~240 000 до ~19 000 токенов через SQL‑фильтрацию и переход от миллионного корпуса до пары сотен релевантных токенов при поиске.

  Пример: 

  Помощнику приходит запрос «найди договор с клиентом Х» — сотрудник не перебирает все папки в архиве, а идёт сразу в нужный шкаф, нужную полку, нужную папку. Архив может разрастись с 1000 до 100 000 документов, а сотрудник всё равно найдёт нужное за пару шагов, потому что искал не перебором, а по системе.

• T(n) — линейный рост. Базовое допущение большинства бюджетных моделей: токены растут пропорционально числу запросов. Отдельно отмечается скрытая фиксированная надбавка — например, полный каталог инструментов агента, загружаемый в контекст при каждом вызове, даже если ни один инструмент не используется. Однако нужно следить, чтобы постоянные издержки не стали в какой‑то момент выше полезной нагрузки.

  Пример: 

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

• T(n·k) — мультипликативный рост. k — невидимый множитель: «усиленно думающие» модели могут съедать сотни тысяч токенов ради пары сотен токенов видимого ответа. Ещё один драйвер — совместимость инструментов: если результат одного шага нельзя напрямую передать в другой, агент на каждом шаге переигрывает весь накопленный контекст, и пятишаговая цепочка обходится в 10–20 раз дороже, чем тот же результат через единый обобщенный вызов.

  Пример:

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

• T(n·k·a) — агенты как мультипликатор роста. Добавляется глубина дерева агентов (a). Разработчик, который работает с несколькими окнами агентов, в каждом из которых субагенты выполняют список задач, расходует n×k×a токенов, где a — глубина дерева агентов.

  Пример:

  У старшего оператора службы поддержки есть три помощника, и каждый вопрос клиента он передаёт всем троим «на всякий случай». Каждый уровень иерархии повторяет модель работы из T(n·k). Задача та же самая, но теперь она умножена на глубину этого дерева согласований, хотя со стороны клиент думает, что он задал один простой вопрос.

• T(∞) — неограниченный рост. Продакшен‑системы без прерывания циклов, где расход токенов теоретически не ограничен.

  Пример:

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

Тарификация Яндекс AI Studio через призму Big‑T нотации

Давайте посмотрим на примере, как происходит обработка запроса пользователя в Яндекс AI Studio, скриншот из вебинара про то, как работает тарификация токенов. 

Слева мы видим вопрос пользователя («Когда в Санкт‑Петербурге разводят мосты в 2026») и один ответ. Со стороны это выглядит как единичное обращение к модели. Так работает скрытие класса сложности, о котором говорит автор Big‑T: форма взаимодействия не выдаёт, сколько всего реально происходит внутри.

Цветами, кстати, размечены разные SKU запросов (ценовых позиций), которые соотносятся с прайс‑листом: 

• фиолетовый — входящие токены запроса и частично кешированные токены;

• зеленый — исходящие токены ответа модели;

• оранжевый — токены инструментов, переданные в модель в результате вызова какого‑либо инструмента.

  Шаг 1 — базовый T(n): запрос + полный каталог инструментов. Вы платите за токены ввода и кешированные токены

  Responses API отправляет в LLM не только сообщение пользователя, но и весь список доступных инструментов — websearch, filesearch, mcp_tool1 — со схемами, даже если в итоге понадобятся не все. Это ровно та «скрытая фиксированная надбавка» внутри T(n): каждый вызов тащит за собой каталог инструментов целиком, независимо от того, что реально будет использовано.

  Шаг 2 — LLM решает, какие инструменты использовать. Вы платите за вызов инструментов и их потребление

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

  Шаг 3 — Второе обращение к модели: перечитывание обновленного контекста. Вы платите за токены инструментов

  Это точка, где n=1 (один вопрос пользователя) умножается на k=2 результат работы инструментов возвращается в модель вместе с контекстом.

  Три результата (текст из web search, список файлов, «ОК» от mcp) не идут напрямую пользователю — их нужно снова отправить в LLM, вместе с исходным контекстом (сообщение, инструкции, ответ инструментов), чтобы модель сгенерировала связный ответ на естественном языке. Это второй полный проход через модель ради одного вопроса пользователя — то самое «на каждом промежуточном шаге агент возвращается, интерпретирует результат и делает новый вызов, заново подгружая контекст», о котором пишет автор Big‑T. Только тут это происходит один раз, поэтому множитель умеренный, но он есть. Представьте ситуацию, когда инструменты выполняют работу последовательно, передают информацию между собой, и их не 3, а значительно больше.

  Потенциальный переход к T(n·k·a)

  В подписи под диаграммой сказано: «вызов инструментов происходит в цикле по решению LLM». Это важная деталь — если бы результатов первого раунда не хватило (например, file search не нашёл нужный файл), LLM могла бы инициировать ещё один цикл вызовов инструментов, а не остановиться на одном раунде. Тогда n=1 запрос пользователя превратился бы уже не в фиксированный k=2, а в переменную глубину циклов — то есть потенциально в T(n·k·a), где a — глубина этих итераций «вызов → результат → снова вызов».

  Шаг 4 — LLM выдает решение в заданном формате. Вы платите за токены вывода 

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

  Далее для иллюстрации порядков, которые достигают разницы между ценами на модели и типы токенов, сравним цены на токены моделей Yandex. В таблицах представлены коэффициенты сравнения (не абсолютные величины). За основу я взяла цены на самую недорогую модель Alice AI LLM Flash.

Как видно из таблицы разница цен за 1000 токенов между моделями может достигать 48 раз.

Сравним цены по типам токенов по отношению к входящим токенам.

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

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

Пять рычагов экономии

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

Вопросы, которые помогут найти возможности для оптимизации:

К какому классу сложности относится эта рабочая нагрузка? 

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

Насколько дёшево она выполняется в рамках своего класса? 

Обратите внимание, качество — это вводное требование, а не параметр сравнения. Т.е. модели, между которыми вы выбираете, должны справляться с задачей.

Решения про сжатие данных, маршрутизацию между моделями, кеширование и сериализацию — это работа с коэффициентом, а не с классом Big‑T: они делают то же самое действие дешевле, но не меняют то, как расход токенов масштабируется с ростом нагрузки. В этом смысле Big‑T ведёт себя так же, как Big‑O, который тоже игнорирует константы.

Но есть важное отличие. У Big‑O разброс констант обычно небольшой — асимптотика интересна именно потому, что при росте n он перестаёт что‑либо решать. В токеномике всё иначе: разброс цены за токен между версиями моделей одного поколения может достигать 5–20 раз, поэтому «просто» оптимизация коэффициента способна сэкономить бюджет на порядок величины — без единой архитектурной правки.

Референсная архитектура: конвейер токен‑эффективности

Пять рычагов складываются в конвейер, где каждый слой снижает нагрузку для следующего, и эффективная сложность по Big‑T падает по мере прохождения запроса по стеку:

1. Детерминированная предобработка — SQL‑фильтры, regex, структурные преобразования. Поможет снизить сложность до T(log n).

2. Проверка кеша — семантический кеш и кеш префикса промпта. При попадании ответ возвращается за T(1), минуя нижестоящие слои.

3. Маршрутизатор моделей — классифицирует сложность задачи и направляет её к подходящему уровню модели.

4. Архитектура промпта — оптимизация сериализации, дедупликация системных промптов, ограничения формата вывода.

5. Инференс (запрос к модели) — до модели доходит только необходимый минимум токенов.

6. Выбор режима вывода — прямой ответ для простых задач; генерация кода для пакетных операций. Это снижает мультипликативный фактор, перенося основную работу с дорогого инференса LLM на выполнение сгенерированного кода.

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

Чек‑лист самооценки

Big‑T предлагает самооценку по семи областям:

1. Видимость. Знаете ли вы расход токенов в разбивке по моделям, нагрузкам и стоимости?

2. Маршрутизатор моделей. Направляете ли вы каждую задачу к самой дешёвой модели из способных её решить?

3. Гигиена промптов. Каждый ли отправляемый токен выполняет полезную работу?

4. Стратегия кеширования. Свели ли вы стоимость часто повторяющихся нагрузок к константе с помощью кеша?

5. Распределение затрат. Можете ли вы связать стоимость токенов с конкретными командами и проектами?

6. Аудит абстракций. Не скрывают ли контракты на основе кредитов (баллов, поинтов) или числа мест стоимость отдельных нагрузок?

7. Модель управления. Есть ли у вас автоматические ограничители и бюджетные пороги?

Так стоит ли Big‑T внимания

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

Минусы. Аналогия с Big‑O красивая, но хромает: у Big‑O есть строгая математика, у Big‑T “n” — намеренно нестрогая переменная, и автор сам это признает. Большая часть содержания — то, что практикующие ML/платформенные инженеры и так знают интуитивно: кешировать стабильные промпты, роутить по моделям, следить за скрытыми токенами «на размышление». Это позиционный и в некоторой степени маркетинговый документ, а не научная работа, и у него есть рыночная цель — застолбить терминологию. 

Итог

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