Это очень интересный длиннопост о том, что именно показывают 5-ти часовые и недельные лимиты в Claude / GPT / Gemini и что происходит под капотом

Это третья большая статья из моей серии «Как работают LLM»
Вот первые две
-
Просто и подробно о том, как работают ChatGPT и другие GPT подобные модели. С картинками. Кстати, эта статья стала одной из победителей Космотекста
-
От написания промптов к проектированию контекста. Или один очень обширный материал по Context Engineering. Эта статья сложнее, чем первая
Некоторые главы могут показаться лишними или слишком техническими — но нет. Так как эта статья для тех, кто хочет лучше понимать, что скрывается под капотом моделей, то я постарался учесть все ньюансы и возможные вопросы, которые могут возникнуть у читателя.
Оглавление статьи
-
Про открытые модели и почему мы используем их как пример
-
Из чего складывается цена токена
-
Про Dense и MoE архитектуры
-
Как считается attention и активные параметры
-
Total ≠ active: тренд на MoE архитектуру
-
Почему output-токены дороже input
-
Reasoning-токены как невидимый output, за который тоже приходится платить
-
Context Window и KV-cache — почему длинный контекст дорогой
-
В чем разница между KV-cache и prompt caching
-
За счет чего фронтир модели стоят в разы дороже
-
Почему дорогая модель чаще всего реально «умнее»
-
Как всё это итого собирается в 5-часовой лимит
-
И как бонус — сортировка open-weight моделей по active и total
Ну, поехали..
Каждый раз, открывая дропдаун с выбором модели, ты видишь несколько на выбор. Чаще всего это маленькая и быстрая, средняя и флагманская, которая дороже, медленнее, но и умнее всех

На примере Claude это серия из трех моделей — Opus, Sonnet и Haiku
Как мы видим, и OpenAI пошел по этому же пути и вместо циферных обозначений переходит на такие же серию из трех моделей: Sol, Terra и Luna
А ещё практически у всех есть переключатель Thinking
Так чем же они отличаются и почему вообще дорогая модель стоит дороже. А дешевая — дешевле?
TL;DR
Короткий ответ: потому что каждый ответ модели использует больше вычислительных мощностей датацентра. А 5-часовой лимит, который ты видишь у себя на экране, — это удобная, понятная и простая визуализация этих вычислений, за которой скрывается вся сложность
Стоимость запроса ≈ ( 2N × токены + attention(контекст) + KV-cache ) × нагрузка
Длинным ответом же является эта статья
Чтобы понять, что такое лимиты, давайте сначала посмотрим, из чего вообще состоит стоимость ответа модели. И в течении статьи мы будем возвращаться к этим пунктам
Стоимость каждого ответа от LLM считается примерно так
-
input-токены — те токены, что ты отправил модели. Складываются из system prompt + tools + MCP + Skills + Memory + наше новое сообщение
-
+ output-токены — состоят из того ответа модели, который мы видим + скрытых reasoning-токенов, если они включены
-
+ VRAM, которая вычисляет и затем хранит ваш KV cashe
-
+ serving overhead — расходы на прогонку KV cashe в GPU для расчёта и затем в места для хранения. И так туда сюда
Если коротко по слагаемым:
-
Токен — это часть текста, которым оперирует модель. Один токен это часть слова или, иногда слово целиком. Считается и тарифицируется всё именно в токенах
-
Input токены — те токены, что ты отправил модели, output — те токены, что модель написала в ответ
-
Reasoning-токены — её внутреннее размышление до видимого ответа
-
Serving overhead — накладные расходы провайдера на то, чтобы держать модель запущенной и готовой отвечать: очереди, маршрутизация и простаивающие между запросами GPU
Каждая переменная — это отдельный кусок GPU-времени и GPU-памяти, за который кто-то платит. Дальше поговорим про все это подробнее
Добавлю, что читать такую математику было бы удобнее всего на примере ChatGPT / Claude моделей. Но есть проблема — ни OpenAI, ни Anthropic не раскрывают ни архитектуру, ни размер своих моделей. Проверить на них наши формулы будет нельзя.
Поэтому мы пойдем по другому пути и будем разбирать все на open-weight моделях — Llama и чуть DeepSeek.
У них опубликованы и размер, и архитектура, а цену выставляет понятный рынок провайдеров. На них математика сходится в числах, которые можно перепроверить руками.
А уже потом перенесём логику на закрытые флагманы 🥵
Let’s go deeper
Для начала давайте расскажу, что такое Open-weight модели — это модель, у которой веса выложены в открытый доступ. Llama от Meta как раз одна из таких. Любой из вас может изучить файлы с весами и сам провести те же рассчеты, что и я
Основное отличие любой модели — количество параметров, которое измеряют в миллиардах параметров. Это те самые 8B, 70B, 405B (от англ. billion)
Trade off вполне очевидный. Чем больше параметров, тем «умнее» модель, но тем мощнее железо нужно, чтобы ее запустить и рассчитать ответ
Для примера покажу эту взаимсвязь на открытых Llama моделях при quantization FP16
-
Llama 3.1 8B — заводится на хорошем ноутбуке, нужно ~16GB видеопамяти
-
Llama 3.1 70B — нужен сервер с парой видеокарт или флагманский ноут, нужно ~140 GB видеопамяти
-
Llama 3.1 405B — потребуется кластер примерно из 16 штук H100 (датацентровая GPU NVIDIA с 80 ГБ VRAM на карту), сотни тысяч долларов железа, ~1280GB видеопамяти
Размер модели задаёт класс железа: число параметров умножается на 2 байта и превращается в конкретный объём видеопамяти — от ноутбука до кластера из 16 H100.
Для самых любопытных. Почему именно VRAM и что такое квантизация
Как работает наша арифметика памяти. Причём «память» здесь имеет ровно один референт — VRAM, быстрая память видеокарты. Не оперативка и не SSD/HDD.
Эти уровни отличаются по скорости на порядки. SSD ≈ 5 ГБ/с, RAM ≈ 50 ГБ/с, VRAM у H100 ≈ 3000 ГБ/с — то есть VRAM в ~600 раз быстрее SSD. Модель обязана жить в VRAM целиком, потому что на каждый токен GPU перечитывает все её веса заново, и любая подкачка с диска убила бы скорость в тысячи раз. Поэтому когда говорят «нужно 140 ГБ памяти» — это всегда про VRAM.
Дальше просто перемножаем: каждый параметр в исходном виде занимает 2 байта — 16-битный формат, в котором веса выкладывают чаще всего. 8B — это ~16 ГБ VRAM, столько даёт хороший игровой ноутбук с дискретной видеокартой. 70B — уже ~140 ГБ, столько VRAM в ноутбук не влезает, нужен сервер с несколькими видеокартами. 405B — ~810 ГБ, масштаб целого кластера.
Числа можно ужать. Если хранить каждый параметр в 1 байте вместо 2 (формат FP8 вместо BF16), VRAM нужно вдвое меньше.
Это называют квантизацией, и крупные модели почти всегда запускают именно так. Поэтому раскладка для 405B такая: без квантизации, в формате BF16 — это ~810 ГБ и реально требует ~16 H100. А сжатая до FP8 — уже ~405 ГБ, и помещается ровно в один узел из 8 H100
В домашних условиях и даже на уровне компаний 405B модели поднять могут меньшинство, потому что узел из 8 H100 стоит около 200+ тысяч долларов. Большинство просто берёт inference-провайдера — компанию, которая держит модель запущенной и продаёт доступ к ней. Inference — это и есть работа модели на ответах, в отличие от обучения. Таких провайдеров много: Together AI, Fireworks, DeepInfra, Groq, Cerebras. Каждый поднимает у себя те же открытые веса и продаёт доступ к модели по токенам.
Веса у всех провайдеров одинаковые, поэтому конкурируют они между собой за одного и того же клиента. Монополии нет. А значит, цена на Llama не может улететь в космос — она прижата к реальной физике обслуживания плюс некоторая маржа провайдера
У закрытых моделей же всё иначе. Веса GPT, Claude и Gemini знают только OpenAI, Anthropic и Google — и только они хостят эти модели. В их ценник зашито сразу всё
-
compute — собственно вычисления и работа GPU
-
их маржа как монополистов на свою модель
-
окупаемость многолетнего R&D и стоимость обучения каждой новой модели
Поэтому стоимость использования закрытого флагмана — это compute плюс всё остальное. А то, что мы посчитаем дальше на примерах Llama — это практически чистая физика и нижняя граница. От которой затем уже можно интерпретировать рассчеты на флагманские модели
Большая модель дороже на каждый сгенерированный токен
Когда модель генерирует следующий токен, то она прогоняет контекст через всю нейросеть и считает вероятности — какой токен идёт дальше.
Размер каждой нейросети измеряют в параметрах — это настроенные при обучении числа-коэффициенты, и их в модели миллиарды. Это все те же наши Llama 8B, 70B, 405B
И чем больше активных параметров у модели, тем больше операций уходит на генерацию одного токена
Подробнее про токены и механизм работы я писал в статье «Просто и подробно о том, как работают GPT-модели»
Теперь про Dense и MoE модели
Это важно для понимания современных моделей
Dense модели — это классический трансформер, где на расчёт каждого следующего токена задействуются все параметры
MoE (Mixture of Experts) — модель, где параметры разделены на «экспертов»
И при расчте каждого следующего токена активируется только часть параметров.
Например, Llama 3.1 — dense, DeepSeek V3.1 — MoE
Разница между Dense и MoE моделями принципиальна для расчет compute, что мы подробно и разберём в следующей главе.
А пока для примера возьмём dense — там compute считается проще всего
Для dense-трансформера compute на один токен считается примерно так
FLOPs/token ≈ 2 × количество параметров
Для самых любопытных про то, что такое FLOPs и откуда в формуле двойка
FLOPs — floating-point operations, операции с дробными числами. Это объём вычислений на один токен. Не путайте с FLOPS через большую S — floating-point operations per second: это уже скорость железа, и одна H100 выдаёт порядка квадриллиона таких операций в секунду. Объем вычислений, делённый на скорость железа, даёт нам время ответа
Теперь о том, откуда в формуле двойка.
Каждый параметр — это вес, число, на которое что-то умножается. Прогон токена через сеть — это перемножение матриц, и каждый вес участвует в одной операции «умножить и прибавить»: входное число умножается на вес, а результат прибавляется к накопленной сумме. Умножение плюс сложение — две операции на каждый вес. N весов — значит, 2N операций на токен. Двойка — это буквально «умножить и сложить».
То есть условные 20B параметров — это примерно 40 миллиардов операций на токен. 200B — уже около 400 миллиардов. Чем больше активных параметров у модели, тем дороже нам обходится каждый сгенерированный токен.
Кроме количества активных параметров, на скорость ответа влияет ещё глубина модели — количество слоёв, которые токен проходит последовательно. Llama 3.1 70B имеет 80 слоёв, Llama 3.1 405B — 126. Слои нельзя параллелить — каждый следующий ждёт результата предыдущего. Поэтому крупные модели не просто дороже на токен, но и физически медленнее за счёт этой sequential chain.
Несколько оговорок к формуле
-
MoE-модели. Для них формула считается по активным параметрам, а не по всем. Что это значит — разберём в следующей секции.
-
Attention. Формула его не учитывает — а это механизм, которым модель на каждом токене сверяется со всеми остальными токенами контекста. Из-за этого «каждый с каждым» вычислений на attention тем больше, чем длиннее контекст, и растут они быстрее самой длины: удвоил контекст — затраты на вычисление attention увеличились в ~4 раза. На коротком промпте этим можно пренебречь. Но на контексте в 100k+ токенов уже нет
Attention сверяет каждый токен с каждым: удвоил контекст — связей стало вчетверо больше. Рост квадратичный, а не линейный.
Конечно, есть разные способы обойти сложность O (n2) через различные подходы к Attention, но суть квадрата остается примерно такой же
Теперь давайте проверим нашу формулу на реальных числах
Llama 3.1 — вся dense, размеры опубликованы, цены берём у Together AI. Это снапшот конца 2024 — последний период, когда вся тройка 8B / 70B / 405B продавалась у одного провайдера на одной площадке. Llama 3.1 используем как чистую иллюстрацию формулы 2N: одна архитектура, одна линейка, один прайс-лист и одна дата
Получилось, что модель в 50 раз больше — а токен только в 19 раз дороже
Параметры выросли в 50 раз — с 8B до 405B. А цена всего лишь в 19 раз.
У нас получилася не строго линейный рост между ценой и кол-вом параметров — и скорее всего это происходит из-за батчинга: это когда провайдер складывает запросы многих пользователей в одну пачку и прогоняет через GPU разом. Крупные модели батчатся выгоднее, и стоимость их дорогого железа размазывается по большему числу запросов.
Но направление получается ровно то, что мы получили в нашей формуле — чем больше модель, тем дороже токен
Для самых любопытных — что такое батчинг и почему он дает экономию именно на крупных моделях
В фазе decode GPU тратит бóльшую часть времени не на сами вычисления, а на чтение весов модели из VRAM — у крупной модели весов больше, соответственно и чтение дольше. А когда провайдер собирает в один батч сто запросов от разных пользователей, то эти веса читаются один раз и обслуживают все сто параллельно: вычисления у каждого запроса свои, но они почти бесплатны по сравнению с уже сделанной «дорогой» работой чтения. Чем тяжелее модель — тем сильнее экономия на запрос.
На длинном контексте у каждого запроса появляется свой большой KV-cache (об этом дальше в главе про контекст), и вот уже он не шарится между пользователями, так как у каждого контекст диалога свой.
Тогда батчинг постепенно теряет преимущество. Поэтому у некоторых вендоров на 200k+ токенов появляется премиум-ставка — она компенсирует падение эффективности батча.
И ещё одно преимущество моделей с меньшим количеством параметров, помимо собственно цены. Маленькая модель выдает результат быстрее, потому что происходит меньше операций на токен. А значит между вопросом и ответом задержка будет меньше.
Флагман на тот же вопрос ответит и дороже, и медленнее. В агентных сценариях — когда модель работает в цикле «шаг → результат → следующий шаг» или в Speech to Speech communication, скорость ответа является очень важным параметром
Total ≠ active: как работают модели на триллионы параметров
Все современные флагманы, да и наша Llama 4 версии, строятся на MoE архитектуре
Если Llama 3.1 вся была Dense, то вот Llama 4 уже вся MoE
Напомню в dense-модели на каждый токен задействована вся сеть, а в MoE — только часть, через выбранных «экспертов». Из этого следует ключевое свойство: у MoE-модели два разных числа параметров — total, сколько их всего, и active, сколько реально считается на один токен.
Давайте разбираться, что же это такое
В прошлой главе формула FLOPs ≈ 2N работала для dense, где N — все параметры модели. У MoE (Mixture of Experts) она остаётся той же, но N в ней — только active: те параметры, через которые реально проходит каждый токен. Остальные параметры на этом токене просто не считаются
Active определяет цену и скорость на один токен. На каждом токене провайдер считает ровно столько FLOPs, сколько занимает active-часть: 37B у V3.1, 17B у Maverick. Скорость генерации тоже привязана к active — чем больше параметров надо прогнать на один токен, тем медленнее ответ на том же железе. Total на эти две вещи не влияет
Total определяет, сколько модель занимает в памяти. Все веса должны лежать в VRAM, даже если на каждом отдельном токене работает только active часть — ведь роутер заранее не знает, кого выберет на следующем. Поэтому хостить MoE-гиганта дороже, чем dense-модель того же active-размера. Приходится держать в памяти весь массив экспертов, даже если считать только часть
Итого для закрепления
Total — это где живут знания, а active — где происходит размышление. Каждый факт, который модель «помнит» (год смерти Пушкина, формула инсулина, идиома на португальском) статистически распределён между весами. Чем больше total, тем больше различимых паттернов влезает — рост сублинейный, но он есть: Llama 70B на factual-бенчмарках обходит Llama 8B примерно вдвое, при том что параметров в неё в 9 раз больше.
А то, как модель манипулирует этими знаниями в моменте — крутится в active compute на токен. Поэтому frontier-класс моделей уже давно ушёл за 1 триллион по количеству параметров + MoE, чтобы взять все преимущества — знания в триллионах параметров при сильно меньшей стоимостью работы
Для самых любопытных. Как устроено MoE и как 671B превращается в 37B на токен
Перед “экспертами” в каждом MoE-слое стоит роутер — крошечная сеть. Она смотрит на токен и выбирает, через каких экспертов его пропустить. Например, у DeepSeek V3.1 максимальное кол-во экспертов на токен — 8 из 256, остальные 248 для этого токена выключены. На следующем слое выбор повторяется заново. Сложить всех экспертов на всех слоях — это total, 671B; сложить только выбранных — active, 37B.
Почему экспертов именно 256, а не 228 или 4000. Число экспертов берут степенью двойки — так они ровно раскладываются по видеокартам, на которых крутится модель; 228 на 8 или 16 GPU ровно не ляжет (228 ÷ 8 = 28 с остатком 4).
Чем больше экспертов, тем тоньше специализация — но роутеру тяжелее выбирать, а каждый эксперт за обучение видит меньше токенов и учится хуже. 256 — подобранный под модель и железо компромисс; у других MoE число своё: 8 у Mixtral, 128 у Llama 4 Maverick
Давайте сравним на двух открытых представителях — DeepSeek V3.1 и Llama 4 Maverick
Total в сотни миллиардов звучит как флагман — но, как мы уже знаем, в MoE на каждый токен считаются всего лишь десятки миллиардов параметров.
V3.1 и Maverick — два примера одного паттерна

По compute V3.1 и Maverick — оба между Llama 3.1 8B и Llama 3.1 70B
Компании-провайдеры, у которых вы арендуете модели, выставляют счёт за active, а не за total
Итого как вывод
total параметры — это маркетинг и то место, которое занимают веса на железе, а счёт выставляется по active. Когда в заголовке пишут «N триллионов параметров» — это почти всегда total. Реальный compute на токен на порядок меньше.
GPT-4, по некоторым утечкам, был MoE уже тогда — около 1,8 триллиона параметров total и ~280 миллиардов active на токен. То есть флагман уже давно мерится в триллионах, а не миллиардах, но active у него всё равно «всего» 280B — в шесть раз меньше total.
По GPT-5+ и Claude Opus вендоры архитектуру не раскрывают вовсе. Мы просто предположим, что флагманы устроены похоже. А вот Gemini Google прямо называют что это MoE архитектура
Точных цифр Total/Active правда никто из них не раскрывает
Пошли дальше
Почему Output токены дороже Input токенов
До сих пор мы считали токен как токен. Но многие современные провайдеры делят их на два класса: input-токены — те, что ты отправил, — и output-токены, которые модель написала в ответ. И output всегда дороже.
Почему так?
Представим, что вы отправили запрос в модель. Это называется Input–токены. Их модель обрабатывает пачкой. Это стадия prefill: ей дали весь промпт целиком, она прогнала его за один проход и построила внутреннее состояние. Prefill хорошо параллелится и упирается в объём вычислений, а считать много и сразу GPU как раз умеет.
Output же генерируется строго последовательно
1-й токен → 2-й → 3-й → … → 2000-й
Нельзя получить 2000-й токен, пока не появился 1999-й — каждый следующий зависит от всех предыдущих. Эта фаза, генерация ответа, называется decode, и ведёт себя иначе, чем prefill. На каждый новый токен модель заново «перечитывает» из памяти GPU всё, что уже накопила, — и узкое место тут не скорость вычислений, а скорость доступа к памяти. Еще это называют memory-bandwidth-bound.
Поэтому, если совсем просто — output держит GPU занятым дольше, хуже параллелится и потому стоит дороже
На закрытых флагманах output обычно в 3–5 раз дороже input. У open-weight бывает иначе: некоторые провайдеры могут брать за input и output одну и ту же ставку
Для самых любопытных. Почему output-токены стоят дороже
Ведь FLOPs у них одинаковые: 1000 input-токенов и 1000 output-токенов на Llama 3.1 8B прокатываются через те же ~16 терафлопс вычислений.
Но по времени всё иначе. Prefill 1k input на H100 видеокарте занимает ~16 миллисекунд, а decode 1k output — ~4,78 секунды. То же количество токенов, тот же compute, но в 300 раз дольше. Один output-токен на H100 по времени стоит как ~295 input-токенов.
Это число — прямое отражение архитектуры GPU: 989 TFLOPS compute против 3,35 ТБ/с памяти. Output не помещается в эту арифметику и упирается в bandwidth, а input помещается.
Эту физику провайдеры частично сглаживают через батчинг — копят запросы нескольких пользователей в один decode-шаг и читают веса раз на всех. Поэтому в прайсе разница не в 300, а в 3–5 раз. Но output остаётся дороже именно по этой причине.
Reasoning-токены как невидимый output

Практически все фронтир модели имеют функцию Reasonig
Когда он включен у модели, то она не пишет ответ сразу. Сначала она тратит токены на размышление: проверяет гипотезы, планирует, разбивает задачу на шаги. И только потом формулирует то, что ты увидишь. У Claude этот режим называют thinking, а настройка reasoning effort задаёт, сколько его.
Эти токены размышления в финальном тексте не видны. Но GPU их всё равно посчитал — а значит, они тоже влияют на трату лимитов или косты в API.
Как это выглядит на одном запросе:
-
видимый ответ — 2 000 токенов
-
внутреннее рассуждение — 10 000 токенов
-
фактическая output-нагрузка — 12 000 токенов
Поэтому связка «дорогая модель + высокий effort» утяжеляет счёт не на 20%, а в разы
При включеном Reasoning мы платим не только за текст, который видим. Но и за те вычисления внутренних рассуждений, которые помогли модели дойти до этого текста
И это одна из причин, почему на Фронтир моделях нет смысла использовать настолько распиаренный Caveman style. Я писал про это отдельную статью
Оговорка для нашего бенчмарка: у Llama полноценного reasoning-режима по-прежнему нет — это свойство frontier-флагманов
Среди open-weight такой режим умеют немногие — DeepSeek (R1 и V4), Qwen 3.5/3.6 с togglable thinking mode, — но Llama 4 (Scout, Maverick) в их число не входит. Так что это слагаемое формулы мы переносим на закрытые модели по аналогии, а не считаем напрямую
Если вам нравится эта статья, то можете и в Telegram мой заглянуть.
Там я посты чаще выкладываю
Context Window — еще один параметр, который влияет на расход наших лимитов
С большим контекстом есть два разных «дорого»
-
В прайсе у провайдера ставка за токен обычно не зависит от длины контекстного окна — но не всегда: у Gemini Pro (и 2.5, и 3 Pro) запрос длиннее 200k токенов уходит на премиум-ставку, где input вдвое дороже, а output — в полтора раза. У Flash-моделей этого порога нет — у них одинаковая ставка при любой длине контекста. Claude от похожей наценки вроде как отказался, хотя раньше было
-
Инфраструктурно на уровне железа длинный контекст тяжелее всегда — даже там, где цена за токен формально не меняется
А почему оно так работает?
Контекст — это не просто текст, лежащий рядом с моделью. Во время генерации модель держит KV-cache — рабочую память по уже обработанному контексту: чтобы на каждый новый токен не прогонять весь контекст заново, модель хранит промежуточный результат.
Чем длиннее контекст, тем больше нужно этой памяти — и тем:
-
больше VRAM (видеопамяти GPU) занято под KV-cache
-
меньше запросов влезает на одну GPU — хуже батчинг
-
выше латентность, и дороже обслуживать много пользователей разом
-
сильнее вклад attention — того самого, что растёт быстрее длины контекста
Запрос на 5k токенов и запрос на 150k — инфраструктурно разные вещи, даже если цена input-токена одинаковая. Второй забивает больше GPU-памяти, хуже батчится и может попадать под отдельные лимиты или внутреннюю маршрутизацию — у провайдеров длинные контексты иногда идут через отдельную инфраструктуру со своими rate limits. «Засунуть весь проект в контекст» — это не бесплатная магия, а аренда большего куска GPU-памяти и времени.
Еще одна врезка для самых любознательных. Сколько весит KV Cache и как считается
Посчитаем на Llama 3.1 70B. Каждый токен контекста лежит в видеопамяти как пара векторов key/value со всех 80 слоёв модели — это и есть KV-cache, чтобы не прогонять контекст заново на каждом шаге. Выходит ровно 320 КБ на токен.
KV на токен = 2 × слои × KV-головы × размерность головы × байты от квантизации
Для Llama 3.1 70B = 2 × 80 × 8 × 128 × 2 байта = 327 680 байт
2 в начале формуле — это нашиK + V. Attention на каждом токене хранит два вектора: key (по нему ищут) и value (его достают).
Запрос на 5 000 токенов держит около 1,5 ГБ VRAM, а контекст в 150 000 токенов — уже почти 46 ГБ, в 30 раз больше. Это больше половины целой H100 на 80 ГБ, занятой только «памятью о разговоре». Растёт линейно: вдвое длиннее контекст — вдвое больше занятой видеопамяти.
В продакшн-моделях вроде ChatGPT и Claude KV-cache последнего запроса живёт в среднем около часа — провайдер держит его в VRAM, чтобы при продолжении чата не пересчитывать контекст заново.
Получается, что чем сильнее у людей забит Context Window и чем больше открытых сессий одновременно по миру, тем больше GPU или памяти рядом с GPU занято просто «спящими диалогами». Это одна из тех фиксированных затрат, которые провайдер размазывает на цену за токен.
Четыре открытых чата с забитым контекстом в 200 000 токенов — это около 250 ГБ VRAM, что равно 3–4 занятым H100 видеокартам. И в этот момент эта доля пула не может обслужить никого больше
Сколько места занимает KV Cache при разном Context Window
KV-cache зависит от количества токенов и от веса каждого токена. А вес токена зависит от глубины модели (число слоёв) и числа KV-голов. А от количества параметров почти не зависит
Поэтому вес одного токена в Llama 405B тяжелее одного токена Llama 70B всего в 1,6 раза, хотя по параметрам разница между моделями в 5,8 раза
Итого вот из каких параметров состоит вес одного токена
А теперь про KV-cache и кеширование
KV-cache был придуман для того, чтобы на стадии Decoding не приходилось пересчитывать весь Attention заново для каждого нового токена. Когда модель генерирует ответ токен за токеном, attention на каждом новом токене должен свериться со всеми предыдущими — ему нужны их Key и Value векторы. Модель считает их один раз и складывает в VRAM
А уже поверх KV-cache механизма многие AI провайдеры надстроили новый — prompt caching
|
KV-cache |
Prompt caching |
|
|---|---|---|
|
Что кэширует |
K/V всех токенов |
K/V общего префикса |
|
Область |
внутри одного запроса |
между запросами |
|
Сколько живет |
эфемерный, гибнет после ответа |
сохраняется на время (60 минут в Claude Code) |
|
Важность |
обязателен (иначе decode нереален) |
опциональная оптимизация |
|
Эффект на затраты |
Каждый новый закешированный токен ест VRAM => затраты выше |
Кеширование между запросами позволяет пропустить Prefill стадию, следовательно экономит ресурсы и деньги |
Подробнее про Context и кеширование я расписывал в статье, которую уже упомянул в начале
Подробный лонгрид про context engineering
Я в своем статус лайне даже вывел кеширование отдельно. Чтобы смотреть, инвалидируется ли кеш в процессе работы и сколько времени осталось до его протухания
Мы уже почти на финишной прямой
Выше мы считали расходы на открытых моделях — там каждое число проверяемо. У закрытых флагманов механика та же, но ценник выше в несколько раз
Повторю еще раз, что ни OpenAI, ни Anthropic, ни Googl не раскрывают число параметров своих флагманов. Всё, что где-то «известно» про их размер, — это утечки, оценки аналитиков и слухи с разбросом в разы
Итого вот почему фронтиры могут стоить в разы дороже
-
Больше active-параметров на токен
-
Выше я уже писал о том, что цену токена определяет количество active а не total параметров. У топовых открытых MoE active — это 17-49B (Llama 4 Maverick — 17B, Kimi K2 — 32B, DeepSeek V4-Pro — 49B)
У закрытых флагманов active официально неизвестен, но была одна утечка насчет того, что в GPT-4 ~280B active параметров. Получается, что даже год назад у GPT количество active параметров на MoE архитектуре было в 3-16 раз больше сегодняшних открытых моделей. А раз больше active → то и больше операций 2N на токен → значит дороже.
А вот насчет количества total параметров у фронтиров я особо ничего и не нарыл. Слухи называют разброс от 1 до 10 трлн параметров
-
-
Больше reasoning budget → больше невидимого output. Флагманы обычно гоняют с бо́льшим reasoning budget — и генерируют больше того самого невидимого output, на который компании тоже тратят много compute
-
Монопольная маржа. У Llama цену прижимает конкуренция десятков провайдеров, крутящих одни и те же веса. У закрытого флагмана конкурента нет — модель есть только у владельца, и стоимость никто кроме него задать не может
-
Меньше агрессивного батчинга — ради скорости ответа богатый провайдер может выделять больше GPU или более мощный GPU. Так как они могут позволить себе скупать все GPU мира
-
Могут выделять приоритетные latency lane — твой запрос не стоит в общей очереди; та самая задержка из главы про цену токена, только здесь её снимают деньгами.
Например, режим /fast внутри Claude Code скорее всего работает как комбинация последних двух, поэтому и стоит дороже
Почему дорогая модель чаще всего реально «умнее»
«Умнее» в мире LLM я бы обозначил такими кластерами — что модель умеет, за счёт чего и как её разворачивают
Что модель умеет
-
Знает больше. Знания живут в total-параметрах — во всех экспертах модели, — даже если active на токен скромный. Большая модель «помнит» больше фактов и связей, а платишь ты по-прежнему за active (см. главу total ≠ active).
-
Лучше держит цель на длинной цепочке шагов. В агентных сценариях это особенно важно — модель не должна забывать свою цель
-
Не теряет задачу в сложном context window. Когда в одном запросе десять требований и ни в коем случае нельзя забыть восьмое требование
-
Реже уверенно ошибается и лучше калибрована, а значит меньше галлюцинаций и чаще говорит «не знаю, надо проверить»
За счёт чего — что в неё вложено
-
Больше compute на обучение и дообучение (training и post-training). Это не измерение ума, а его причина: в один флагман топовые лаборатории вкладывают сотни миллионов долларов обучения и тяжёлый post-training
Как и чем её обвязывают — harness вокруг модели
-
Harness и работа с инструментами (tool use). Голую модель в вакууме уже почти никто не рассматривает — фронтир затачивают под агентные циклы, вызов инструментов и длинный контекст. Одна и та же модель с хорошим harness и без него — почти два разных по «умности» продукта
-
Больше inference-time compute. Больше внутренних «попыток» перед ответом — reasoning-токены, перебор вариантов. Модель буквально думает дольше на трудной задаче.
Но на простой задаче флагман часто может быть не умнее дешёвой модели. А только дороже и медленнее. «Умнее» окупается на сложных задачах
Как итог
Между «отправил запрос в LLM» и «увидел цифру usage» лежит вот такой конвейер

А дорогая модель стоит дороже, потому что она тратит больше GPU-времени и GPU-памяти сразу в нескольких местах:
-
Дороже каждый токен — больше active compute, видно на Llama 8B → 70B → 405B
-
Total ≠ active — заголовки про «N триллионов параметров» обычно про total, а биллинг определяет active. Видно на DeepSeek V4 Pro: 1.6T total, а биллинг по 49B active
-
Дороже output — он генерируется последовательно, следовательно долго занимает большие объемы VRAM
-
Больше reasoning‘a — есть невидимые токены размышления
-
Дороже большой контекст — больше веса токенов, быстрее забивается KV-cache, который забивает дорогую VRAM. Да еще и attention надо считать
-
Дороже serving у закрытых frontier-моделей — меньше батчинга, приоритетная очередь, дефицит мощных кластеров, плюс монопольная маржа
И, наконец-то, отвечая на вопрос из начала статьи
Что же показывают недельное и 5-часовое окно
Этот индикатор считает не количество сообщений или токенов, а compute, потраченный нашими запросами.
Формула выглядит примерно так
Стоимость запроса ≈ ( 2N × токены + attention(контекст) + KV-cache ) × нагрузка
Где
-
2N — объем вычислений на один токен. N = active-параметры выбранной модели.
Если на примере Claude моделей, то У Haiku N маленькое, тогда как у Opus N будет в разы больше. По аналогии с нашими Llama 405B (~800 миллиардов вычислений на токен) и 8B (~16 миллиардов вычислений на токен) -
× число токенов — все токены запроса. Input (промпт + контекст) + output (видимый ответ) + скрытые reasoning-токены (невидимый output). Выше reasoning budget → больше токенов в этом множителе.
-
+ attention(контекст) — надбавка за длину контекста. Каждый токен сверяется со всем контекстом; растёт быстрее числа токенов и на длинном контексте обгоняет 2N. Это GPU-время.
-
+ KV-cache — память под контекст. Контекст физически лежит в VRAM (≈320 КБ/токен у Llama 70B). Это GPU-память, отдельная ось от времени. Плюс был ли использован Prompt Cashing. Если да, то часть Compute нам делать не придется, а значит лимитов потратим меньше
-
× коэффициент нагрузки — множитель провайдера. Например, раньше у Anthropic были 2х затраты в некоторые пиковые часы, когда сервера не справлялись с нагрузкой.
Сортировка Open Weight моделей по Active параметрам
Напомню, что active определяет
-
Цену токена у провайдера: он считает по формуле FLOPs ≈ 2N · active и выставляет ценник по этой работе
-
Скорость генерации: чем больше active, тем медленнее ответ на том же железе. Total на эти две вещи не влияет.
-
Если разворачиваешь локально, то active показывает compute-нагрузку на GPU при каждом проходе, то есть latency на токен
Сортировка Open Weight моделей по Total параметрам
Напомню, что total определяет
-
Размер файла модели и требуемый объём VRAM: всю модель нужно держать в памяти GPU. Стоимость серверной инфраструктуры у провайдера тоже растёт с total. Active на это не влияет.
Если разворачиваешь локально, то total — это первый вопрос: «влезет ли модель в мой GPU?». Одна H100 80GB в BF16 квантизации держит модель до ~35B. Например, dense-Llama 3.1 8B. 70B-модель влезает уже только в FP8 (~70 ГБ под веса) или 4-bit квантизации (~35 ГБ). Kimi K2 (1T) дома даже в 4-bit требует ~500 ГБ — это уже multi-GPU кластер минимум на 7 карт.
Какие выводы можно сделать из этих двух графиков
Open-weight frontier переехал в класс «1T+ MoE»
Четыре модели имеют 1 триллион и больше total. У всех active в диапазоне 32–49B — то есть на каждом токене реально работает 2–5% от общего размера модели. Это «3% активации» — новая норма frontier-класса 2026 года; ещё полгода назад единственным представителем был Kimi K2
MoE архитектура и экономия
Например, Kimi K2 Instruct ($0,50 / $2,00) стоит как dense-модель класса 30B, при том что под капотом 1 триллион параметров. Так как платим мы только за active
Еще один пример в виде открытой модельки от OpenAI — gpt-oss-120B: при 117B total и всего 5,1B active цена $0,15 / $0,60 ниже, чем у dense Llama 3.3 70B по output. Обратный пример — Kimi K2.6 ($0,95 / $4,00): та же 1T/32B-архитектура, что и у K2, но надбавка за reasoning почти удваивает цену
P.S. про числа в статье
-
Все цены в статье — снапшот на 2026 год; рынок inference двигается быстро, и через полгода ставки могут быть другими
-
Раскладка факторов frontier-класса — обоснованная интерпретация, а не опубликованные данные провайдеров
P.P.S. для тех, кто дочитал и кому понравилось
Раз в месяц я набираю небольшие группы по 7-10 человек, которых в течении месяца за ручку провожу от
«Я слышал что есть Claude Code / Codex и агенты, но не знаю с чего начать»
и до
«Я знаю больше, чем 95% людей в моем окружении. А от момента появления любой идеи и до её реализацией меня отделяют несколько часов»
Будет 8 живых уроков со мной, в которых мы пройдем темы от основ работы с Claude Code/Codex, Git, GitHub, VPS, и вплоть до готового личного персонального агента под ваш бизнес/жизнь
Если вы чувствуете, что не успеваете за всеми AI-трендами, то здесь вы уберёте FOMO и научитесь использовать современные LLM на совершенно другом уровне 😻
Программа и ближайший поток на сайте ⬅️
До 5 июня можно еще успеть на 6 поток
Можно как для себя взять, так и для команды

Автор: Raicon


