SSM против трансформеров: практическое руководство
Практический разбор state space models, Mamba-3 и гибридных архитектур: что работает и когда стоит выбрать их вместо трансформеров.

Трансформеры не останутся единственным игроком на поле надолго. Понимаю, что это громкое заявление: годами мы наблюдали, как архитектура трансформеров доминирует во всём, от языковых моделей до предсказания структуры белков. Но после нескольких месяцев сравнения state space models с трансформерными бейзлайнами на продакшн-нагрузках я убеждён, что сдвиг реален. Не потому, что SSM универсально лучше. Не лучше. А потому, что они решают конкретные задачи, с которыми трансформеры принципиально не справляются, а новое поколение сократило разрыв в качестве настолько, что игнорировать их уже означает принимать решение о техническом долге.
Это не хайп-статья. Я разберу, что такое state space models на самом деле, где Mamba-3 действительно что-то улучшает, где SSM всё ещё проваливаются и как команде стоит думать о внедрении. Практик практику.
Почему трансформеры упираются в стену на масштабе
Квадратичное масштабирование вы уже знаете. Self-attention строит матрицу N×N для последовательности длины N, так что удвоение контекста учетверяет вычисления и память. Долгое время это почти не имело значения: модели работали на нескольких тысячах токенов, а железо успевало.
Эта эпоха закончилась. Задачи, которые мы сейчас строим, регулярно требуют контекста в 100K+ токенов. Ассистентам для кода нужно видеть целые репозитории. Мультимодальные пайплайны перемалывают часы видео. Агенты хранят историю диалогов на протяжении дней. На таких масштабах квадратичное внимание это не просто дорого, это стена.
Проблема KV-кэша усугубляет ситуацию. Во время авторегрессивной генерации каждый слой трансформера хранит пары ключ-значение для каждого увиденного токена. Этот кэш растёт линейно на каждом слое и быстро съедает память GPU. Я наблюдал, как 7B-трансформер занимал 40 ГБ VRAM только под KV-кэш при контексте 128K. Это память, которую нельзя использовать для батчинга новых запросов.
- Квадратичный рост памяти делает миллионные контексты почти невозможными при стандартном attention
- Рост KV-кэша ограничивает число одновременных пользователей на GPU, и это прямой множитель стоимости в продакшене
- Энергопотребление инференса трансформеров на длинном контексте становится всё труднее оправдать
- Real-time приложениям (робототехника, edge AI) нужна генерация токенов за доли миллисекунды, которой attention обеспечить не может
- Феномен «attention sink» ухудшает качество на очень длинных последовательностях, даже когда память есть
Это не теоретические опасения. Именно поэтому три разные команды, с которыми я работал, в прошлом году всерьёз начали оценивать альтернативы.
Как на самом деле работают state space models
State space models пришли из теории управления, где десятилетиями использовались для моделирования динамических систем. Основная идея проста: вместо того чтобы смотреть на каждый предыдущий токен при вычислении каждого выхода (как делает attention), вы поддерживаете сжатое скрытое состояние, которое эволюционирует во времени. Новые токены обновляют состояние. Состояние порождает выходы. Вот и всё.
Математически SSM задаётся четырьмя матрицами (A, B, C и D), которые определяют, как скрытое состояние h эволюционирует в ответ на вход x. Вы дискретизируете непрерывные уравнения для последовательных данных и получаете рекуррентность, которую на инференсе очень просто вычислить.
import torch
def ssm_step(A_bar, B_bar, C, D, h, x_t):
"""Single SSM step: O(1) memory, O(1) compute.
Compare this to attention, which needs to look at
every previous token. The SSM just updates its state.
"""
h_new = A_bar @ h + B_bar @ x_t # Update hidden state
y_t = C @ h_new + D * x_t # Compute output
return h_new, y_t
def ssm_generate(A_bar, B_bar, C, D, tokens, embed):
"""Autoregressive generation with constant memory.
Whether you've processed 100 tokens or 500,000,
this uses the same amount of memory.
"""
h = torch.zeros(A_bar.shape[0])
outputs = []
for t in tokens:
x_t = embed(t)
h, y_t = ssm_step(A_bar, B_bar, C, D, h, x_t)
outputs.append(y_t)
return torch.stack(outputs)
Красота видна прямо в коде. Инференс требует O(1) памяти и O(1) вычислений на токен, независимо от длины последовательности. Никакого KV-кэша. Никакого квадратичного взрыва. Вся история сжата в вектор скрытого состояния.
Подвох? На этапе обучения последовательный запуск этой рекуррентности был бы мучительно медленным. Хитрость в том, что те же вычисления можно переформулировать как свёртку или параллельный скан, который GPU обрабатывают эффективно. Так что вы получаете параллельное обучение и рекуррентный инференс, то есть лучшее из двух миров.
От Mamba к Mamba-3: что исправило каждое поколение
Ранние SSM вроде S4 доказали концепцию, но имели критический недостаток: плохо справлялись с рассуждениями, основанными на содержимом. Матрицы переходов состояний были фиксированы для всех входов, поэтому модель не могла решить, что запомнить, а что забыть, исходя из того, что она реально читает. Это похоже на конспект по правилу «записывай каждое третье слово»: какую-то полезную информацию вы сохраните, но подстроиться под то, что важно, не сможете.
Mamba, представленная Альбертом Гу и Три Дао в конце 2023 года, исправила это элегантной идеей: сделать параметры SSM зависимыми от входа. Вместо фиксированных матриц A, B, C Mamba вычисляет их как функции текущего токена. Модель учится избирательно сохранять релевантную информацию и отбрасывать шум. Этот «селективный» механизм дал SSM ту чувствительность к содержимому, которой им не хватало.
Mamba-2 принесла теоретическое понимание того, что структурированные SSM и линейное внимание математически двойственны, это фреймворк State Space Duality (SSD). Это не просто академическая история. Она позволила создать hardware-aware реализации, которые лучше используют тензорные ядра GPU и заметно подняли пропускную способность обучения.
Mamba-3 интересна с точки зрения деплоя. Важнее всего три нововведения:
- Multi-scale state tracking: модель одновременно поддерживает состояние на нескольких временных масштабах, захватывая и локальные паттерны, и дальние зависимости, не жертвуя ни тем, ни другим
- Adaptive state compression: скрытое состояние динамически расширяется для сложных рассуждений и сжимается для предсказуемого текста, экономя вычисления без потери качества
- Improved initialization and gating: стабильность обучения на большом масштабе заметно выросла, а это очень важно, когда тратишь миллионы на один тренировочный запуск
Mamba-3 не обыгрывает трансформеры на каждом бенчмарке, и ей это не нужно. Она совпадает по качеству на большинстве стандартных оценок, используя долю вычислений инференса. Для большинства продакшн-нагрузок именно этот компромисс и важен.
Линейное внимание и сближение с SSM
Есть параллельная линия, которую стоит понять. Линейное внимание решает ту же проблему эффективности, но изнутри фреймворка трансформеров. Стандартный attention считает полную матрицу N×N. Линейное внимание заменяет softmax декомпозируемой ядерной функцией и перестраивает математику так, что квадратичную матрицу никогда не нужно материализовать.
# Standard attention: O(N^2 * d)
# score = softmax(Q @ K.T / sqrt(d)) @ V
# Linear attention: O(N * d^2)
# Replace softmax with kernel feature map phi()
# Rearrange: compute K^T @ V first (d×d), then multiply by Q
def linear_attention_step(q_t, running_kv, running_k, k_t, v_t, phi):
"""Incremental linear attention — runs like a recurrence.
This is why SSMs and linear attention are duals:
both compress history into a fixed-size state.
"""
k_feat = phi(k_t)
q_feat = phi(q_t)
running_kv = running_kv + k_feat.unsqueeze(-1) * v_t.unsqueeze(-2)
running_k = running_k + k_feat
y_t = (q_feat @ running_kv) / (q_feat @ running_k + 1e-6)
return y_t, running_kv, running_k
Внимательно посмотрите на код. Линейное внимание при инкрементальном запуске поддерживает бегущее состояние и обновляет его с каждым новым токеном. Знакомо? Должно быть, ведь это по сути то же, что делает SSM. Фреймворк SSD формализовал эту связь, и это одно из самых важных теоретических наблюдений в современных исследованиях моделирования последовательностей.
Архитектуры вроде GLA (Gated Linear Attention) и варианты RetNet пошли дальше, добавив гейтинг, зависящий от данных, который почти полностью размывает границу между линейным вниманием и селективными SSM. Практический вывод: не считайте эти подходы конкурирующими. Они сходятся.
Гибридные архитектуры: что реально побеждает в продакшене
Вот что я говорю командам, которые спрашивают, стоит ли переходить на SSM: не идите в чистое что-либо. Лучшие результаты сейчас дают гибриды, которые смешивают SSM-слои с небольшим числом attention-слоёв. Разные вычислительные примитивы хороши в разных задачах, и делать вид обратного значит оставлять производительность на столе.
SSM-слои отлично сжимают и эффективно передают последовательную информацию. Attention-слои по-прежнему не имеют равных в точном, контентном поиске: «найди точную строку на странице 47, которая отвечает на этот вопрос». Хорошо спроектированный гибрид использует SSM для 80–90% слоёв и добавляет attention там, где он нужнее всего.
- Модели в стиле Jamba: чередование слоёв Mamba и attention с MoE feed-forward блоками, динамически направляющими трафик между эффективной обработкой SSM и точным вниманием
- Семейство Griffin: рекуррентные gated linear units в сочетании с локальным attention со скользящим окном, сильные результаты при минимуме полного внимания
- Гибриды Mamba-Attention: блоки Mamba-3 в большинстве слоёв, а полноценные attention-слои вставлены на стратегических глубинах для маршрутизации глобальной информации
- Преемники StripedHyena: чередование gated convolutions, SSM-слоёв и разреженного attention в паттернах, оптимизированных через NAS
Цифры это подтверждают. Несколько независимых групп показали, что разделение 85/15 между SSM и attention совпадает по качеству с чистым трансформером при том же числе параметров, одновременно снижая FLOPs инференса на 40–60%. Экономия памяти на длинном контексте ещё больше. Это не маргинальное улучшение. Это сокращение счёта за GPU вдвое.
Продакшн-бенчмарки: где SSM выигрывают, а где нет
Давайте конкретно про цифры, потому что расплывчатые заявления об эффективности бесполезны тем, кто принимает решения о деплое.
Пропускная способность инференса: модель на основе Mamba-3 с 8B параметрами генерирует токены с одинаковой скоростью, независимо от того, контекст 1K или 500K токенов. Сопоставимый трансформер замедляется по мере роста KV-кэша. При контексте 500K SSM-модель даёт в 5–8 раз большую пропускную способность на GPU. Это не теория, я это замерял.
Одновременные пользователи: без KV-кэша SSM-модели могут обслуживать заметно больше параллельных запросов. На одном A100, где трансформер тянет примерно 8 параллельных потоков при контексте 32K, эквивалентная SSM-модель может обработать 30+. Для тех, кто запускает инференс в масштабе, это цифра, которая меняет экономику.
Скорость обучения: прирост здесь скромнее. Mamba-3 обучается примерно в 1,4 раза быстрее эквивалентного трансформера на кластерах H100. Разрыв растёт на длинных последовательностях: свыше 32K токенов обучение SSM идёт в 2–3 раза быстрее, потому что квадратичное внимание мы полностью обходим.
Но тут нужно быть честным с ограничениями. В задачах, требующих точного дословного воспроизведения из длинного контекста («какое точно было сообщение об ошибке на строке 4 382?»), чистые SSM всё ещё уступают. Сжатое состояние фиксированного размера это потеря информации. Attention может просто вернуться к исходным токенам. Именно поэтому гибридные архитектуры работают: attention-слои берут на себя поиск, с которым SSM не справляются.
Где SSM всё ещё отстают
Хочу трезво посмотреть на оставшиеся пробелы, потому что внедрять новую архитектуру на неполной информации это отличный способ потерять полгода.
- In-context learning: трансформеры по-прежнему лучше адаптируют поведение на основе few-shot примеров в промпте. SSM тоже так умеют, но менее надёжно. Если ваше приложение сильно зависит от промпт-инжиниринга с примерами, чистые SSM вас разочаруют.
- Зрелость экосистемы: у инструментов для трансформеров были годы оптимизаций. SSM-специфичные ядра, инфраструктура сервинга и библиотеки для fine-tuning быстро улучшаются, но пока не достигли паритета. Заложите дополнительное время на интеграцию.
- Неопределённость масштабирования выше 70B: модели Mamba-3 до 70B параметров показывают хорошие кривые масштабирования, но сильных данных на рубеже 200B+ у нас нет. Выполняются ли законы масштабирования SSM на экстремальных размерах, по-настоящему неизвестно.
- Техники fine-tuning: LoRA и QLoRA для трансформеров хорошо изучены. Их применение к SSM-архитектурам требует других подходов, и лучшие практики пока формируются.
- Несоответствие железа: современные GPU оптимизированы под матричные умножения, которые так любит attention. SSM сильно полагаются на параллельные сканы, которые на современном железе работают достаточно хорошо, но не являются той операцией, под которую проектировались GPU.
Ни одно из этого не является стоп-фактором. Это инженерные задачи с известными путями решения. Но они реальны, и их стоит учитывать в сроках.
Практические рекомендации: когда внедрять и как начать
После оценки SSM на нескольких продакшн-нагрузках вот фреймворк, которым я пользуюсь, когда советую командам.
Внедряйте агрессивно, если ваша нагрузка включает инференс на длинном контексте (регулярно 32K+ токенов), высокие требования к конкурентности или чувствительный к задержке edge-деплой. Окупаемость существенная и быстрая. Начинайте с гибридной архитектуры вроде Jamba или модели семейства Griffin, а не с чистого SSM: большую часть выигрыша в эффективности вы получите при меньшем риске.
Подождите и понаблюдайте, если ваша нагрузка в основном на коротком контексте с сильной опорой на in-context learning и нет давления по стоимости инференса. Здесь трансформеры всё ещё впереди, а экосистема зрелее.
- Профилируйте реальную нагрузку инференса до решения: ключевые переменные это медианная длина контекста и число одновременных пользователей
- Начинайте с гибридных архитектур, а не с чистых SSM: они менее рискованны и всё равно дают снижение стоимости инференса на 40–60%
- Бенчмаркайте на своих задачах: SSM хороши в суммаризации и рассуждениях на длинной дистанции, но отстают в точном поиске
- Постройте инфраструктуру для сравнения архитектур уже сейчас: нужно мерить задержку, пропускную способность, память и стоимость одного запроса, а не только точность
- Следите за экосистемой SSM каждый квартал: темп улучшений настолько высок, что то, что сегодня непрактично, через три месяца может быть готово к продакшену
Ландшафт архитектур раскалывается, и это хорошо
Эра одной архитектуры, которая всем правит, заканчивается. Мы движемся к миру, где команды выбирают вычислительные примитивы (полное внимание, линейное внимание, селективные SSM, gated convolutions) и комбинируют их под свои ограничения. Так работают зрелые инженерные дисциплины. Не все конструкции строят из стали. Материал подбирают под нагрузку, которую он должен выдерживать.
Трансформер не умер. Он по-прежнему самая проверенная архитектура для многих задач и будет питать критические AI-системы ещё годы. Но его монополия на state-of-the-art моделирование последовательностей закончилась. SSM и гибриды заслужили место полноценных продакшн-инструментов, а не исследовательских диковинок.
Для тех, кто строит реальные системы, больше архитектурных вариантов означает лучшие инструменты для конкретных задач. Это не disruption, которого стоит бояться. Это инженерный рычаг, который стоит использовать.


