Engram отделяет хранение знаний от вычислений и превращает память в отдельный O(1) слой условной памяти для LLM.[86][87]
На тех же FLOPs Engram-27B заметно обгоняет MoE-27B по знанию, рассуждению и задачам кода и математики.[87]
Для архитекторов ИИ это сигнал: следующая волна оптимизации пройдёт по оси памяти, а не только по оси вычислений.[86][87]
Почему Engram вообще важен
Типичные большие языковые модели сегодня решают две разные задачи одной и той же архитектурой: им нужно и рассуждать по контексту, и вспоминать устойчивые факты вроде названий компаний или формул. В трансформерах без специальной памяти модель вынуждена «восстанавливать» эти факты через много слоёв внимания и MLP, тратя вычисления на то, что можно было бы просто считать из таблицы.
Команда DeepSeek предлагает вернуть в современный стек идею n-грамм, но в радикально обновлённом виде: Engram хранит огромную таблицу статических шаблонов, к которой модель обращается за O(1) за счёт хешированной адресации. В результате трансформер может освободить ранние слои от рутинного «сборки сущностей» и направить глубину на более сложные шаги рассуждения.
На уровне парадигмы это вводит третий столп рядом с плотными моделями и MoE: помимо условных вычислений, появляется условная память как самостоятельная ось разреженности.
MoE научили выбирать, какие вычисления запускать. Engram добавляет возможность выбирать, какие знания доставать из памяти без дополнительных FLOPs.[86][87]
Это не просто ускорение: архитектура начинает по-другому распределять роль между слоями — память переезжает в отдельный модуль, а «спинной мозг» модели занимается логикой.[87]
Как устроен Engram под капотом
На входе Engram берёт локальный контекст токенов и сжимает его через проекцию словаря: разные варианты написания и форматирования приводятся к канонической форме, что уменьшает эффективный словарь примерно на четверть. Затем несколько независимых хеш-функций проецируют получившиеся n-граммы в индексы огромной embedding-таблицы, из которой за O(1) извлекаются векторы памяти.
Извлечённые векторы сами по себе «немые»: они не знают, к какому контексту относятся. Поэтому поверх них навешивается контекстно-зависимое управление: скрытое состояние модели на текущем слое играет роль запроса, а память — ключа и значения, и через скалярный гейт определяется, насколько сильно конкретный фрагмент памяти надо подмешать в представление токена.
Важно, что Engram подключается к трансформеру не везде, а в нескольких стратегических слоях. В работе это слои 2 и 15: достаточно рано, чтобы разгрузить низкоуровневую реконструкцию шаблонов, но не настолько глубоко, чтобы мешать высокоуровневым рассуждениям.
Сравнение скрытых представлений показывает: ранние слои модели с Engram по своей «зрелости» ближе к более глубоким слоям обычной MoE-модели.[87]
Иначе говоря, Engram ведёт себя так, как будто вы добавили модели полезную глубину, не увеличивая бюджет FLOPs.[87]
Глубокий анализ: что показывают цифры
Авторы тренируют четыре модели на 262 миллиардах токенов: плотную Dense-4B, MoE-27B, Engram-27B с тем же общим числом параметров и Engram-40B с ещё более крупной памятью, но тем же числом активных параметров.
При фиксированном числе активных параметров (3.8 млрд, одинаковый FLOPs на токен) Engram-27B систематически превосходит MoE-27B на широком наборе бенчмарков — от MMLU до HumanEval и MATH, а Engram-40B добавляет ещё несколько пунктов качества.
| Модель | Всего параметров | MMLU (5-shot) | BBH (3-shot) | HumanEval (Pass@1) |
|---|---|---|---|---|
| MoE-27B | 26.7B | 57.4 | 50.9 | 37.8 |
| Engram-27B | 26.7B | 60.4 | 55.9 | 40.8 |
| Engram-40B | 39.5B | 60.6 | 57.5 | 38.4 |
Особенно показателен блок долгого контекста: при окне 32 тысячи токенов Engram-27B достигает точности 97 процентов в задаче многократного поиска «иглы в стоге сена» по множеству запросов против 84.2 процента у MoE-27B, а отслеживание переменных в длинных цепочках растёт с 77 до 89 процентов.
Отдельная ось анализа — как распределять разреженную ёмкость между экспертами и памятью. При фиксированном бюджете FLOPs авторы варьируют долю параметров, отведённых под MoE и Engram, и находят U-образный закон: чистый MoE оказывается субоптимален, а оптимум лежит примерно при 75–80 процентах sparse-бюджета в экспертных слоях и 20–25 процентах в памяти.
Если вы уже используете MoE, часть «спящих» параметров имеет смысл перенести в отдельный слой памяти вместо дальнейшего раздувания числа экспертов.[87]
Это улучшает как знание, так и рассуждение при том же бюджете вычислений.[87]
Что это значит для архитекторов и платформ
Для команд, которые строят собственные модели или кастомные форки открытых LLM, Engram даёт несколько практических ориентиров.
Во-первых, становится ясно, что «память» не обязана жить внутри attention-слоёв или в виде классического retrieval-augmentation с внешним векторным поиском. Статическая, таблицеобразная память может быть дешёвой с точки зрения FLOPs и при этом крупной по числу параметров, если вынести её в отдельный слой с хешированием и предусмотреть инфраструктурную поддержку предвыборки.
Во-вторых, архитектура Engram подчёркивает, что MoE в одиночку не решает задачу разреженности: экспертные слои отлично масштабируют вычислительную глубину, но плохо захватывают устойчивые локальные паттерны. С точки зрения дизайна это аргумент в пользу гибридных конфигураций, в которых разреженные вычисления и разреженная память дополняют друг друга.
В-третьих, бумага демонстрирует, что грамотный offload памяти на хост почти не стоит пропускной способности: таблица на 100 миллиардов параметров, вынесенная в оперативную память, добавляет менее трёх процентов накладных расходов за счёт детерминированного адреса и overlap коммуникации с вычислением. Для hyperscaler-инфраструктур это означает возможность наращивать параметрическую ёмкость без линейного роста количества GPU.
Перспективы и риски подхода
Технически Engram выглядит очень привлекательно: чёткая ось скейлинга, хорошая совместимость с существующими трансформерными бэкендами и небольшой штраф к latency при грамотном размещении слоёв. Но в практическом внедрении есть несколько вопросов, которые инженерам придётся решать самостоятельно.
Во-первых, организационная сложность. Engram предполагает, что команда умеет управлять не только тренингом модели, но и отдельным жизненным циклом памяти: как обновлять таблицу, как отслеживать деградацию в редких паттернах, как тестировать влияние изменений памяти на безопасность и качество вывода.
Во-вторых, вопросы приватности. Поскольку память может встраивать очень детальные n-граммовые шаблоны, особенно в корпоративных доменах, становится критично контролировать, какие данные попадают в таблицу и как её можно «очищать» без полного переобучения. По сути, Engram делает проблему забывания более сложной: забыть единичный факт в статической памяти может быть проще, но нужно уметь корректно переиндексировать связанные шаблоны.
В-третьих, риск избыточной специализации. Если слишком большая часть sparse-бюджета уйдёт в память, модель может начать недорабатывать на задачах, где требуется именно динамическое рассуждение, а не извлечение шаблонов. Наблюдаемая U-образная кривая качества показывает, что баланс между Engram и MoE нужно подбирать осторожно.
Engram показывает жизнеспособность ещё одной оси разреженности. Следующим шагом логично ожидать появление стандартных «слоёв памяти» в популярных фреймворках и рост числа гибридных архитектур, где память, эксперты и retrieval-системы работают вместе.[86][87]
Для компаний это означает, что дизайн моделей всё сильнее будет напоминать дизайн баз данных и кеширующих подсистем, а не только чисто нейросетевую оптимизацию.[87]
Узнать больше
DeepSeek Engram: код и документация
Репозиторий Engram с реализацией условной памяти, примерами интеграции и конфигурациями моделей, описанных в статье Conditional Memory via Scalable Lookup.[87]
Практические идеи
Если вы уже используете или планируете MoE-архитектуры, имеет смысл рассматривать часть sparse-параметров как кандидат на перенос в отдельный слой памяти по типу Engram. Даже простые эксперименты с n-граммовой таблицей и детерминированной адресацией дадут интуицию, сколько качества можно вернуть без увеличения FLOPs.
Источники информации
На чём основан этот разбор
Материал подготовлен на основе оригинальной статьи Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models и её приложения с полными таблицами результатов,[86][87] а также обсуждений исследователей и инженеров в профессиональных блогах и сообществах, анализирующих архитектуру Engram и её практические последствия.[88][89][91] Данные и выводы актуальны на январь 2026 года.
