Почему у разных LLM при одинаковых параметрах разная память для контекста: Mamba, KV-кэш и архитектура

Введение

Если запустить Llama 3.1 8B и Granite 4.1 8B на одном GPU с контекстом в 128 000 токенов, вы заметите неожиданную вещь: при практически одинаковом количестве параметров требования к видеопамяти будут существенно различаться. Более того, если заменить Transformer на Mamba-модель того же размера, разница станет ещё более впечатляющей.

Почему так происходит? Ответ кроется не в количестве параметров, а в фундаментальных различиях архитектур: как модель хранит информацию о прошлом, как вычисляет внимание и как растёт потребление памяти с увеличением контекста.

В этой статье мы разберём технические причины — от KV-кэша и механизма self-attention до State Space Models и гибридных архитектур — и покажем, как это влияет на реальное развёртывание.

Три вида памяти при инференсе LLM

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

1. Веса модели (постоянная память)

Веса — это обученные параметры модели. Их размер фиксирован и не зависит от длины контекста:

• FP16/BF16: 2 байта на параметр → 8B модель ≈ 16 ГБ

• INT8: 1 байт на параметр → 8B модель ≈ 8 ГБ

• INT4: 0,5 байта на параметр → 8B модель ≈ 4 ГБ

Этот компонент одинаков для всех архитектур при одинаковом количестве параметров и одинаковой квантизации.

2. Активации (временная память)

Активации — промежуточные результаты вычислений, необходимые для прямого прохода (forward pass) и, при fine-tuning, обратного (backward pass). При чистом инференсе (без обучения) активации можно минимизировать с помощью техники activation checkpointing.

3. KV-кэш / состояние (растущая память)

Именно этот компонент объясняет разницу между архитектурами. Это память, которая хранит информацию о всех токенах контекста и растёт с каждым новым токеном. Здесь кроется ключевое различие между Transformer, Mamba и RWKV.

💡 Практический вывод: при выборе модели для продакшн-развёртывания важно смотреть не только на количество параметров, но и на то, как растёт память с увеличением контекста. Модель с меньшим количеством параметров может потребовать больше VRAM при длинном контексте, чем модель с большим количеством параметров, но более эффективной архитектурой.

Transformer и KV-кэш: почему память растёт линейно

Как работает self-attention

В основе Transformer лежит механизм self-attention: каждый токен сравнивается со всеми предыдущими токенами. Для каждого токена вычисляются три вектора:

• Query (Q) — «что я ищу?»

• Key (K) — «что я предлагаю?»

• Value (V) — «что я храню?»

Attention вычисляется как взвешенная сумма всех Value, где веса определяются сходством Query с каждым Key.

Проблема O(n²)

Вычисление attention для последовательности длины n требует сравнения каждого токена с каждым — это O(n²) операций. Для контекста в 128K токенов это 16 миллиардов сравнений.

KV-кэш как решение

Чтобы не пересчитывать Key и Value для каждого нового токена, их кэшируют — это и есть KV-кэш. При генерации каждого нового токена модель:

1. Вычисляет Query для нового токена

2. Сравнивает его со всеми закэшированными Key

3. Вычисляет взвешенную сумму закэшированных Value

4. Добавляет новые Key и Value в кэш

Это снижает вычислительную сложность с O(n³) до O(n²), но память KV-кэша растёт линейно с длиной контекста.

Формула памяти KV-кэша

Размер KV-кэша на один токен рассчитывается по формуле:

байт_на_токен = 2 × слои × KV_головы × размер_головы × байт_на_тип

Множитель 2 — это Key и Value. Давайте посчитаем для реальных моделей:

Llama 3.1 8B (BF16):

• 32 слоя, 4 KV-головы (GQA), 128 размер головы, 2 байта

• 2 × 32 × 4 × 128 × 2 = 65 536 байт ≈ 64 КБ на токен

Llama 3.1 70B (BF16):

• 80 слоев, 8 KV-голов, 128 размер головы, 2 байта

• 2 × 80 × 8 × 128 × 2 = 327 680 байт ≈ 320 КБ на токен

Реальные цифры

Обратите внимание: при контексте в 128K токенов KV-кэш 70B-модели (40 ГБ) превышает размер весов модели в BF16 (140 ГБ / 2 = 70 ГБ при BF16). При контексте в 1M токенов KV-кэш (320 ГБ) становится доминирующим компонентом.

⚠️ Типичная ошибка при планировании инфраструктуры: многие оценивают VRAM только по весам модели, игнорируя KV-кэш. Для Llama 3.1 70B с контекстом 128K нужно не 140 ГБ (веса), а 180 ГБ (веса + KV-кэш). Это может означать разницу между одним и двумя GPU.

Grouped-Query Attention (GQA) и Multi-Query Attention (MQA)

Для снижения размера KV-кэша разработчики используют техники, при которых несколько Query-голов делят одну Key/Value-голову:

• MHA (Multi-Head Attention): каждая Query-голова имеет свою Key/Value — максимальное качество, максимальная память

• GQA (Grouped-Query): группы Query-голов делят Key/Value — баланс качества и памяти

• MQA (Multi-Query): все Query-головы делят одну Key/Value — минимальная память

Llama 3.1 70B использует GQA с 8 KV-головами вместо 64 — это сокращает KV-кэш в 8 раз по сравнению с MHA.

Mamba: линейная память вместо KV-кэша

State Space Models (SSM)

Mamba — это реализация State Space Model, которая обрабатывает последовательности принципиально иначе. Вместо хранения всех Key и Value, Mamba поддерживает фиксированное скрытое состояние, которое обновляется с каждым новым токеном.

Математически это описывается рекуррентным уравнением:

h_t = Ā · h_{t-1} + B̄ · x_t
y_t = C · h_t

где h — скрытое состояние фиксированного размера, не зависящее от длины контекста.

Ключевое отличие: O(1) память при инференсе

Вместо KV-кэша, который растёт с каждым токеном, Mamba хранит состояние постоянного размера. Это означает:

• Память при инференсе: O(1) — не зависит от длины контекста

• Вычисления: O(n) — линейная сложность (против O(n²) у Transformer)

• Теоретически бесконечный контекст — ограничен только аппаратными ресурсами

Реальное сравнение

Mamba-2 (~790M параметров) способна обрабатывать контекст до 220K токенов в пределах 24 ГБ VRAM — результат, недостижимый для Transformer-модели сопоставимого размера.

💡 Практический совет: если ваша задача требует обработки очень длинных контекстов (миллионы токенов), Mamba-модели могут быть единственным вариантом, который помещается в доступный VRAM.

Mamba-2: селективность

Первая версия Mamba (Mamba-1) имела ограничение: параметры SSM были фиксированными и не зависели от входных данных. Mamba-2 ввела селективность — модель может адаптировать свои параметры в зависимости от входящего токена, что позволило:

• Лучше «запоминать» важную информацию и «забывать» неважную

• Значительно улучшить качество по бенчмаркам

• Сопоставиться с Transformer-моделями того же размера

Гибридные архитектуры: лучшее из обоих миров

Проблема чистых SSM

Чистые Mamba-модели имеют недостаток: они хуже справляются с задачами, требующими точного извлечения информации из длинного контекста (needle-in-a-haystack). Это связано с тем, что SSM сжимает информацию в фиксированное состояние, тогда как Transformer хранит её явно в KV-кэше.

Решение: гибриды

Идея проста: чередовать слои Mamba и Transformer. Mamba-слои обеспечивают эффективную обработку длинных последовательностей, а Transformer-слои — точное извлечение информации.

Jamba (AI21 Labs, 2024):

• Соотношение Mamba:Transformer = 7:1

• MoE (Mixture of Experts) каждые 2 блока

• Контекст до 256K токенов

• 52B параметров (12B активных)

Granite 4.0 H Small (IBM, 2025):

• Гибридная Mamba-2/Transformer архитектура

• 32B параметров (9B активных)

• 70% меньше памяти, чем сопоставимые Transformer-модели

• 2× быстрее инференс

Бенчмарки гибридов

RWKV: ещё один подход к линейной памяти

RWKV (Receptance Weighted Key Value) — архитектура, которая переосмысливает attention через рекуррентную форму. Вместо хранения всех Key/Value, RWKV вычисляет взвешенную сумму с экспоненциальным затуханием:

wkv_t = Σ exp(k_i + w(t-i)) · v_i
y_t = sigmoid(r_t) · wkv_t

Ключевые особенности:

• Рекуррентный инференс — O(1) память, как у Mamba

• Параллельное обучение — O(n²) при обучении, как у Transformer

• Бесконечный контекст — теоретически не ограничен

RWKV7-G1 2.9B работает на RTX 4090 со скоростью 115 токенов/сек при квантизации nf4, используя всего 2,4 ГБ VRAM.

Почему при одинаковых параметрах — разная память: сводная таблица

Теперь ответим на главный вопрос статьи. Вот почему модели с одинаковым количеством параметров потребляют разное количество памяти:

Конкретный пример: 8B моделей

Разница между 4K и 1M контекстом для Transformer — 63 ГБ. Для Mamba и гибридов — ноль.

Оптимизация KV-кэша: как снизить память без смены архитектуры

Если вы не можете заменить Transformer на Mamba (например, из-за требований к качеству), есть техники оптимизации:

1. Квантизация KV-кэша

KVQuant и аналогичные методы квантизируют Key и Value до INT8 или INT4:

• FP16 → INT8: 2× экономия памяти KV-кэша

• FP16 → INT4: 4× экономия памяти KV-кэша

• Пер-токенная квантизация Value + пер-канальная квантизация Key — оптимальный баланс качества и экономии

2. Sliding Window Attention (SWA)

Вместо хранения KV-кэша для всех токенов, храните только последние N токенов:

• Llama 3.1 8B: SWA 4K для большинства слоёв + глобальный attention каждые 8 слоёв

• Экономия: до 75% KV-кэша при сохранении качества

3. PagedAttention (vLLM)

Аналог виртуальной памяти: KV-кэш разбивается на блоки, которые могут быть не непрерывными в памяти. Это решает проблему фрагментации и позволяет:

• Динамически выделять память под каждый запрос

• Уменьшать внутреннюю фрагментацию (когда выделено 4K, а использовано 100 токенов)

• Увеличивать эффективный batch size

4. KV-кэш свопинг

Для длинных сессий KV-кэш можно выгружать на системную RAM или SSD:

• PCIe 4.0 x16: 32 ГБ/с — загрузка 10K токенов за 0,03 сек

• DDR5 RAM: 81 ГБ/с — ещё быстрее

• SSD: 7,4 ГБ/с — загрузка 10K токенов за 0,12 сек

Это в ~100 раз быстрее, чем пересчёт промпта с нуля.

⚠️ Важно: выбор техники оптимизации — это не просто техническая деталь. Неправильная квантизация KV-кэша может привести к деградации качества на 5-15% на задачах с длинным контекстом. Для продакшн-решений рекомендуется тестирование на реальных данных с привлечением специалистов.

Практические сценарии выбора архитектуры

Сценарий 1: RAG-система с длинными документами

Задача: обработка юридических документов до 500K токенов.

Рекомендация: Granite 4.0 H Small (Hybrid MoE) или Mamba-2.

• Контекст 128K+ без экспоненциального роста памяти

• Granite 4.0 H Small: 70% меньше памяти, чем Transformer того же размера

• Гибридная архитектура сохраняет точность извлечения информации

Сценарий 2: Чат-бот с коротким контекстом

Задача: клиентская поддержка, контекст до 4K токенов.

Рекомендация: Любой Transformer (Llama, Granite 4.1, Qwen).

• При коротком контексте KV-кэш не является проблемой

• Transformer показывает лучшее качество на задачах с точным извлечением

• Зрелая экосистема инструментов

Сценарий 3: Анализ кодовой базы

Задача: обработка всей кодовой базы (1M+ токенов) для рефакторинга.

Рекомендация: Mamba-2 или Codestral Mamba.

• Теоретически бесконечный контекст

• Codestral Mamba: 256K контекст, 7.3B параметров

• Линейная память — можно обрабатывать файлы любого размера

💡 Практический совет: команды, которые доверяют выбор архитектуры и оптимизацию инференса опытным специалистам, экономят значительные ресурсы. Поверхностное копирование решений из интернета может привести к скрытым проблемам с производительностью и качеством — особенно при работе с длинными контекстами, где неправильная настройка KV-кэша или квантизации может деградировать качество на 10-20%.

Риски самостоятельного развёртывания

При развёртывании LLM в продакшене типичные ошибки включают:

1. Неучтённый KV-кэш: расчёт VRAM только по весам модели → нехватка памяти при длинном контексте

2. Неправильная квантизация: INT4 для KV-кэша без тестирования → деградация качества на критичных задачах

3. Отсутствие оптимизации инференса: отсутствие PagedAttention → фрагментация памяти и низкий batch size

4. Архитектурные ошибки: выбор Transformer для задач с миллионным контекстом → невозможность развёртывания на доступном железе

Команды, которые привлекают специалистов для проектирования AI-инфраструктуры, избегают этих ошибок на этапе проектирования — что значительно дешевле, чем исправление в продакшене.

Заключение

Разница в потреблении памяти между моделями с одинаковым количеством параметров объясняется тремя ключевыми факторами:

1. Архитектура хранения контекста: KV-кэш (Transformer) vs. фиксированное состояние (Mamba/RWKV)

2. Механизм внимания: self-attention O(n²) vs. рекуррентное обновление O(n)

3. Оптимизации: GQA/MQA, квантизация KV-кэша, SWA, PagedAttention

Для коротких контекстов (до 4K) разница минимальна — любой Transformer справится. Но при контексте в 128K+ токенов выбор архитектуры становится критичным: Mamba и гибридные модели могут потребовать в 5-10 раз меньше памяти, чем Transformer того же размера.

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

Источники

• Characterizing State Space Model and Hybrid Language Model Performance with Long Context — arXiv

• How Much VRAM to Run an LLM? KV-Cache & Context Math

• GPU Memory Requirements for LLMs: VRAM Calculator

• What Is a Mamba Model? Complete Guide to SSM Architecture

• Post-Transformer Architectures — Mamba and Hybrid Models

• Attention was never enough: Tracing the rise of hybrid LLMs — AI21

• What Is A Mamba Model? — IBM

• KV Cache Memory Calculation for LLMs — Lyceum Technology

• Hybrid Attention Models 2026: Mamba, Jamba, RWKV — Presenc AI

• Mamba, RWKV, and the Race to Replace Transformers — Algorithmine

• A Survey of Mamba — arXiv

• Techniques for KV Cache Optimization in Large Language Models

• KVQuant: Towards 10 Million Context Length LLM Inference

• IBM Granite 4.0 — Official