> ## Content Index
> Fetch the complete content index at: https://eclibra.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# DeepSeek Engram: условная память, которая разгружает LLM и усиливает рассуждения
- URL: https://eclibra.com/deepseek-engram-conditional-memory-llm/
- Published: 2026-01-19T10:30:04.000Z
- Updated: 2026-01-19T10:30:04.000Z
- Description: DeepSeek предлагает Engram — модуль условной памяти для LLM, который выносит факты в отдельный O(1) слой, разгружает трансформер и улучшает качество на задачах знания, рассуждения и кода без увеличения FLOPs.
- Author: ByteMaster
- Tags: ИИ-инфраструктура и энергия

🎯

****Engram: новый тип памяти для больших языковых моделей**  
  
  
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\]

[Открыть репозиторий](https://github.com/deepseek-ai/Engram?ref=eclibra.com) 

## Практические идеи

Если вы уже используете или планируете 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 года.