Linux Foundation запустила новое направление — Tokenomics Foundation, которое выпустило проект описания «Big-T Notation». Автор фреймворка — Ден Нефф, старший архитектор облачных решений в Adobe. Нотация предлагает способ классифицировать рабочие нагрузки по росту потребления токенов в LLM- и агентных системах, по аналогии с Big-O в теории алгоритмов. Проблема, которую решает Big-T, — не в дороговизне токенов самих по себе, а в том, что рост расходов сложно структурно предсказать и управленчески трудно контролировать. Токены в бюджетировании обычно относят к категории «разберёмся потом», как когда-то веб-разработчики относились к SQL-запросам.
Каждое поколение вычислительной техники имеет свой дефицитный ресурс. Для больших языковых моделей таким ресурсом является токен. Методы анализа сложности ранее применялись к ИИ в контексте обучения — стоимости обучения модели. Но сколько токенов модель потребляет при каждом ответе на запрос заданной рабочей нагрузки — для этого не существовало собственной терминологии. Big-T призвана её создать. Фреймворк основан на исследованиях Flexpa и лаборатории MIT CSAIL, которые изучали, как LLM ищут и извлекают информацию, а также на опыте использования маршрутизации моделей, кеширования и сериализации входных данных.
| Рычаг | Суть | Ключевой результат |
|---|---|---|
| 1. Сокращайте вводные данные | Отправляйте модели только то, что ей действительно нужно | Компактные промпты, ниже стоимость |
| 2. Выбирайте правильную модель | Правильный размер, правильный момент (асинхронные запросы), не переплачивайте за избыточный «интеллект» и быстрые ответы | Достаточное качество по минимальной цене |
| 3. Контролируйте системную сложность | Управляйте числом вызовов (k) и глубиной агентских цепочек/деревьев (a) | Отсутствие мультипликатора роста потребления токенов |
| 4. Максимизируйте переиспользование | Кешируйте, предвычисляйте, не платите дважды за одни и те же токены | Чем чаще система находит готовый результат в кеше, тем меньше ей приходится заново обращаться к дорогим ресурсам |
| 5. Оптимизируйте вывод | Ограничивайте, суммируйте и структурируйте ответы | Короткие ответы быстрее и дешевле (а пользоваться ими проще) Выходные токены стоят в несколько раз дороже входных у всех крупных провайдеров |
Big-T нотация использует переменные: n — количество запросов или размер каждого запроса, k — число обращений к модели за один запрос, a — глубина дерева (цепочки) агентов. Классы сложности представлены в виде «лестницы»: T(1) — константа, когда модель не вызывается на каждый запрос (кеш, статический ответ); T(log n) — сублинейный рост, достигаемый, например, через правильно построенный RAG с SQL-фильтрацией; T(n) — линейный рост, базовое допущение большинства бюджетных моделей. Автор честно оговаривается, что нотация не является формальной математической системой — в ней нет теорем и доказательств, а вводные значения не имеют чёткого определения.
Проверим фреймворк на живых цифрах — прайс-листе Yandex Cloud ИИ Studio. Реальные тарифы показывают, что «невидимые множители», о которых пишет автор, — это конкретные строки в биллинге. Например, стоимость зависит не только от числа токенов, но и от типа модели, объёма контекста, а также скрытых надбавок за инструменты агента, загружаемые в контекст при каждом вызове. Это иллюстрирует, почему линейная оценка T(n) часто оказывается недостаточной: на практике расходы могут расти быстрее из-за неучтённых факторов.
Для организаций, внедряющих LLM-решения, Big-T нотация может стать инструментом планирования бюджета. Она помогает выявлять классы сложности, которые обычно упускают, например сублинейный рост через RAG. Однако, как и любая новая методология, она требует адаптации и проверки на реальных данных. Пока Big-T — это скорее концептуальная рамка для обсуждения, чем готовое решение, но она задаёт важное направление: сделать расходы на токены предсказуемыми и управляемыми.
