Модель на 30B в квантовании Q8 с контекстом 256K и нежатым KVCache не помещается в 32 ГБ VRAM, и разрыв измеряется сотнями гигабайт: только кэш ключей и значений в FP16 занимает около 515 ГБ. Это прямая арифметика. Объём KVCache растёт линейно с длиной контекста, и при длинном окне главным потребителем видеопамяти становится кэш, а не веса.
Обсуждение темы строится вокруг гипотезы: будущие механизмы вроде Engram сожмут KVCache и переиспользуют состояния модели настолько, что средние модели в Q8 с контекстом 256K поместятся в потребительскую видеокарту. Разбираем, откуда берутся такие числа, какие допущения должны сработать и что здесь подтверждено, а что остаётся предположением.
Сразу о статусе данных: ни один из доступных материалов не описывает Engram, квантизацию Q8 и Q4, контекст 256K или модели около 30B и 54B. Все конкретные цифры и названия будущих моделей - предположения авторов обсуждения, а не характеристики релизов. Ниже разбор логики расчётов, а не прогноз по железу.
Что такое KVCache и Engram и при чём тут VRAM
Трансформер при генерации токенов не пересчитывает весь контекст заново. На каждом шаге он сохраняет для каждого слоя матрицы ключей (K) и значений (V) всех предыдущих токенов и переиспользует их. Этот кэш и называется KVCache. Без него генерация была бы квадратичной по длине последовательности и на длинном контексте превращалась бы в бесконечное ожидание.
Плата за ускорение - видеопамять. Веса модели занимают фиксированный объём, а KVCache прибавляет байты с каждым новым токеном контекста. На коротком диалоге это десятки мегабайт, на длинном документе - десятки гигабайт. Второй фигурант темы, Engram, в доступных источниках не описан вовсе, поэтому дальше речь пойдёт о нём как о гипотетической оптимизации.
Как KVCache расходует видеопамять при длинном контексте
Формула простая: KV-байты ≈ 2 × layers × heads × head_dim × seq_len × bytes_per_element. Множитель 2 отвечает за две матрицы, K и V, а последний параметр задаёт тип хранения.
Возьмём гипотетическую модель на 30B с 60 слоями, 64 головами внимания и head_dim 128. Размерности выбраны для примера и не описывают конкретный релиз. При контексте 256K токенов (262 144) получаем:
- FP16, 2 байта на элемент: около 515 ГБ;
- Q8, 1 байт: около 257 ГБ;
- Q4, 0.5 байта: около 128 ГБ.
Сжатие кэша в четыре раза оставляет 128 ГБ. На потребительской карте с 32 ГБ места под такой кэш нет ни в одном формате. Этот разрыв и подпитывает разговоры о принципиально других механизмах: сжать кэш ещё в 4-8 раз без потери качества, а затем переиспользовать состояния между слоями так, чтобы полный кэш вообще не хранился.
На практике длинный контекст сегодня держится другими средствами: PagedAttention борется с фрагментацией памяти, скользящее окно и разреженное внимание ограничивают число учитываемых токенов. Эти методы работают, но меняют архитектуру или поведение модели: часть контекста становится недоступной для внимания.
Engram как гипотетический механизм: что о нём известно и чего нет
Честная позиция: в доступных источниках нет описания Engram, его архитектуры, замеров или кода. В обсуждении он фигурирует как гипотетическая оптимизация, которая, по предположениям, занимает 1/3-1/2 размера модели и заметно сокращает расход видеопамяти. Отталкиваться здесь можно только от общей логики таких механизмов.
Что могло бы стоять за идеей: сильнее сжимать KVCache и хранить его не в FP16, а в малоразрядных форматах с эпизодическим пересчётом; переиспользовать устойчивые паттерны активаций между слоями и между проходами, не сохраняя полный кэш для каждого токена; выносить часть состояний во внешнюю память на SSD или в RAM. Любой из вариантов требует компромисса: экономия памяти почти всегда оплачивается скоростью генерации или качеством ответов.
Цифру "1/3-1/2 размера модели" тоже стоит воспринимать осторожно. Для модели на 30B это 10-15 ГБ. Применительно к KVCache такая оценка подразумевает сжатие в десятки раз относительно FP16 на контексте 256K. Публичных подтверждений такого сжатия на длинном контексте нет.
Из чего складывается расход VRAM при запуске локальной LLM
Планируя конфигурацию, полезно считать не "размер модели", а сумму пяти компонентов. Ошибка в любом из них ломает весь расчёт.
- Веса модели. Зависят от числа параметров и квантизации: FP16 - 2 байта на параметр, Q8 - примерно 1 байт, Q4 - около 0.5 байта.
- KVCache. Растёт с длиной контекста и числом одновременных запросов.
- Промежуточные активации и буферы. Зависят от размера батча и длины последовательности.
- Дополнительные компоненты модели: головы MTP (multi-token prediction) и vision-энкодер у мультимодальных версий.
- Оверхед библиотеки инференса: контекст CUDA, драйверы, фрагментация памяти, вспомогательные буферы.
Веса модели, квантизация и базовый минимум VRAM
Ориентиры по весам без учёта кэша: 30B в FP16 - около 60 ГБ, в Q8 - около 30 ГБ, в Q4 - около 15 ГБ. Модель на 54B в Q4 - примерно 27 ГБ, на 70B в Q4 - около 35 ГБ. Реальный расход выше на 10-20% из-за оверхеда, и этот запас нужно закладывать сразу.
Квантизация Q8 почти не теряет в качестве относительно FP16, но требует вдвое больше памяти, чем Q4. Отсюда и возникает сценарий из обсуждения: если будущие механизмы действительно сократят KVCache, то первыми в потребительские карты попадут не самые компактные Q4-модели, а именно Q8-модели среднего размера, у которых освободившийся бюджет памяти уйдёт под кэш. Компромиссы ультранизкой квантизации, где экономия памяти максимальна, а потери качества заметнее, разобраны в материале Qwen 3.8 Next UD IQ1_S против Qwen 3.8 27B UD Q4: есть ли смысл в ультранизкой квантизации.
MTP, Vision и другие накладные расходы
MTP добавляет модели дополнительные головы предсказания, которые угадывают несколько следующих токенов за проход. Это ускоряет декодирование, но увеличивает и вычисления, и занимаемую память. Выигрыш не гарантирован: на некоторых конфигурациях MTP замедляет генерацию вместо ускорения, о чём стоит помнить при выборе сборки. Vision-энкодер у мультимодальной модели занимает отдельный блок видеопамяти, и его аппетит зависит от разрешения входных изображений.
В обсуждаемой таблице эти компоненты учтены, но их вклад в разных моделях различается в разы. Перенос vision-энкодера на CPU вместе с частью вычислений меняет и требования к памяти, и скорость, а иногда даёт эффект, обратный ожидаемому; разбор такого компромисса есть в статье Qwen3.8-Flash-next на RTX 3090: как запустить модель с 12 ГБ VRAM и что придется пожертвовать.
Логика расчёта: хватит ли 32 ГБ VRAM для модели 30B в Q8 с контекстом 256K
Пройдём по шагам так, как это сделано в обсуждении.
Шаг первый: веса. Модель на 30B в Q8 - около 30 ГБ. На карте с 32 ГБ остаётся 2 ГБ, и это уже проблема.
Шаг второй: KVCache при контексте 256K. В FP16 - около 515 ГБ, в Q8 - около 257 ГБ, в Q4 - около 128 ГБ. Любая из этих цифр перекрывает бюджет в разы.
Шаг третий: MTP и Vision. Ещё несколько гигабайт сверху, если модель мультимодальная или использует дополнительные головы предсказания.
Без радикального сжатия кэша 32 ГБ не хватает. Дальше начинается гипотеза: если Engram или похожий механизм сократит KVCache до 1/3-1/2 от размера модели, то есть до 10-15 ГБ для 30B, суммарно получится 30 + 10-15 + оверхед, примерно 45-50 ГБ. Это всё ещё больше 32 ГБ.
Значит, в исходном предположении должны работать дополнительные допущения: либо кэш сжимается сильнее, чем в 4 раза, либо веса занимают меньше 30 ГБ, либо часть вычислений выносится из GPU. Точных цифр нет, и это упражнение в логике, а не прогноз. Полезный вывод простой: 32 ГБ становятся достаточными только при совпадении нескольких прорывов одновременно, а не при одной удачной оптимизации.
Какие допущения должны сработать, чтобы 32 ГБ оказалось достаточно
Список допущений, на которых держится оптимистичный сценарий:
- KVCache сжимается в 4-8 раз без заметной потери качества.
- Engram переиспользует состояния и не хранит полный кэш для всех токенов.
- Веса в Q8 занимают ровно 30 ГБ без оверхеда библиотеки инференса.
- MTP и Vision не добавляют ни байта видеопамяти.
- Библиотека не тратит память на промежуточные буферы.
Каждое из этих условий либо не подтверждено, либо расходится с текущей практикой. Публичных замеров, где KVCache сжимается в 4-8 раз без потери качества на длинном контексте, нет. Оверхед библиотеки никуда не исчезает. MTP и vision-энкодер память занимают. Совпадение всех пяти пунктов разом маловероятно.
Почему Q4-модели около 54B - более реалистичный сценарий
У Q4 вдвое ниже требования к весам, и это высвобождает бюджет под кэш. Для модели на 54B в Q4 веса занимают около 27 ГБ. При умеренном сжатии KVCache в 2-4 раза кэш добавит 9-13 ГБ, итого 36-40 ГБ. Это тоже выше 32 ГБ, но заметно ближе, и на карте с 48 ГБ такой сценарий уже выглядит рабочим.
Второй аргумент в пользу Q4: качество таких моделей растёт, и для многих практических задач они сопоставимы с Q8. Здесь тоже остаётся оговорка: расчёт построен на арифметике, а не на измеренном результате. Работающей модели на 54B в Q4 с контекстом 256K на потребительской карте пока никто публично не показывал.
Что уже работает сегодня, а что остаётся гипотезой
Текущие методы снижения VRAM: квантизация, PagedAttention, выгрузка на CPU
Инструменты, доступные прямо сейчас, дают предсказуемый результат.
- Квантизация весов (GPTQ, AWQ, GGUF) сокращает память под веса в 2-4 раза.
- Квантизация KVCache в Q8 или Q4 срезает объём кэша ещё вдвое или вчетверо.
- PagedAttention борется с фрагментацией и позволяет плотнее упаковывать кэш.
- FlashAttention снижает пиковое потребление памяти на промежуточных тензорах внимания.
- Выгрузка части слоёв на CPU позволяет запустить модель, которая не влезает в GPU, ценой скорости.
Комбинация этих методов уже позволяет держать модель на 30B в Q4 с контекстом 32K на 24 ГБ VRAM. Для 256K такого набора не хватает. Практика показывает, где начинаются компромиссы: при переносе части вычислений на CPU или при нестандартном размещении таблиц скорость генерации может падать нелинейно, и на длинном контексте выигрыш от освобождённой памяти легко съедается просадкой токенов в секунду. Подробный разбор таких режимов есть в статье Qwen3.8-Flash-Next в llama.cpp: как VRAM, PLE и контекст меняют скорость на практике.
Гипотетический слой оптимизации перед инференсом: что предлагают исследователи
Одна из концепций, которая встречается в обсуждениях, описывает отдельный слой оптимизации между входящими данными и дорогим инференсом. Его задача - свести к минимуму вычисления и перемещение данных при заданном качестве результата. Внутри такого слоя: фильтрация нерелевантного, дедупликация, retrieval из структурированных баз, сжатие, предвычисления, а также маршрутизация задач между моделями разного размера.
Пример из описания концепции: нагрузка содержит 100 ГБ информации, но релевантна для задачи лишь малая доля. Слой сначала выделяет нужное, сжимает и извлекает, а дорогой модели передаёт только необходимое. Метрика в такой схеме смещается с "сэкономленных токенов" на полезный результат на единицу потреблённых вычислений. Обсуждается и аппаратный вариант: специализированный ускоритель, который работает до основного AI-ускорителя.
Оговорка по статусу: это концептуальное предложение в формате обсуждения, а не подтверждённое исследование или замер. KVCache и Engram в нём напрямую не описаны. Слой оптимизации снижает нагрузку на модель, но не отменяет необходимости хранить кэш для длинного контекста: если на вход подаётся 200K токенов, внимание всё равно должно их учесть. Связать эту идею с Engram можно только на уровне догадки: вероятно, подобные механизмы станут частью такого слоя, но подтверждений этому нет.
Стоит ли ждать этих оптимизаций при выборе GPU
Ждать гипотетических оптимизаций рискованно: у них нет ни сроков, ни публичных замеров. Если модель нужна сейчас, ориентируйтесь на текущие требования. Оптимизации будущего скорее продлят жизнь уже купленным картам, чем превратят 32 ГБ в универсальное решение для 256K контекста.
Практические ориентиры по VRAM для популярных размеров моделей
Приблизительные ориентиры по видеопамяти под веса, без длинного контекста:
| Размер модели | Квантизация | VRAM под веса |
|---|---|---|
| 7-8B | Q4 | 6-8 ГБ |
| 13B | Q4 | 10-12 ГБ |
| 30B | Q4 | 18-22 ГБ |
| 30B | Q8 | 32-36 ГБ |
| 54B | Q4 | 28-32 ГБ |
| 70B | Q4 | 40-48 ГБ |
Для контекста 128K и выше добавляйте 10-20 ГБ в зависимости от архитектуры модели. Цифры приблизительные: конкретная сборка, число голов внимания и тип кэша меняют итог заметно. Практический пример выбора квантизации под конкретный объём памяти разобран в статье Qwen 3.8 Flash Next на 6 ГБ VRAM: какую квантизацию выбрать для баланса скорости и качества.
Как следить за развитием технологий без иллюзий
Стоит отслеживать релизы llama.cpp, vLLM и TensorRT-LLM, изменения в поддержке типов KV-кэша и публикации по сжатию KVCache и attention для длинного контекста. Простое правило проверки: если в обсуждении нет ссылки на код, бенчмарк или рецензируемую статью, перед вами гипотеза.
Свои цифры тоже стоит проверять: запустить модель, замерить фактическое потребление памяти через nvidia-smi при разной длине контекста и сравнить с расчётом по формуле. Расхождение в 10-20% нормально, расхождение в разы означает, что считали не то. Таблица из исходного обсуждения - пример логики, а не руководство к покупке. Схемы запуска с распределением нагрузки между VRAM, RAM и NVMe разобраны в материале Как собрать локальный стек для Qwen3.8 27B на двух RTX 3090 с DFlash2 и LMCache.
Итог: что реально может измениться, а что остаётся предположением
KVCache - реальный и хорошо изученный механизм, который сильнее всего влияет на расход VRAM при длинном контексте. Engram - гипотетическая оптимизация без подтверждённых данных: ни архитектуры, ни замеров, ни кода. Расчёты из обсуждения показывают логику, но не доказывают, что 32 ГБ хватит для модели на 30B в Q8 с контекстом 256K: даже при сжатии кэша до 10-15 ГБ суммарный расход выходит за 40 ГБ.
Наиболее реалистичный сценарий - Q4-модели около 54B на 32-48 ГБ VRAM при условии, что сжатие KVCache продолжится. Практический вывод: сегодня ориентируйтесь на работающие методы (квантизация весов и кэша, PagedAttention, FlashAttention, разумное распределение нагрузки между GPU и CPU), закладывайте запас VRAM 10-20% и считайте требования по формуле под свой сценарий. Будущие оптимизации рассматривайте как потенциальный бонус, который может продлить жизнь текущей карте, а не как основание откладывать покупку.
Если выбираете железо прямо сейчас, берите объём, который закрывает вашу задачу без гипотез: для 30B в Q4 с контекстом 32-64K достаточно 24 ГБ, для 70B в Q4 - 48 ГБ. Гнаться за 256K на потребительской карте пока не стоит: даже если память позволит, скорость генерации может оказаться неприемлемой для интерактивной работы.