Что такое product-key memory и почему таблица может заменить параметры
Модель на 21M параметров с внешней таблицей на 16,8M строк показала качество, сопоставимое с плотной моделью на 114M. Обе учились на одинаковых 500M токенов Wikipedia. В таблице лежат 6,4 млрд параметров, но на один токен из неё читается только 33M.
Так работает product-key memory: сеть получает огромное хранилище выученных векторов и достаёт из него несколько сотен записей на токен. Вычисления на токен остаются на уровне маленькой модели, а объём доступной информации вырастает до миллиардов векторов. Хранить это хозяйство в VRAM не обязательно.
Чем разреженная память отличается от плотных параметров
Плотная модель на 114M прогоняет через вычисления все свои веса на каждом токене. Схема с внешней таблицей устроена иначе: 6,4 млрд параметров лежат в таблице, но активируется из них лишь 33M. Разрыв в пять раз по числу плотных параметров возникает потому, что большая часть знаний не участвует в расчёте конкретного токена.
Таблица обучается вместе с моделью. Это не статическая база фактов, подсунутая сети сбоку, а часть параметров, обновляемая на том же шаге обратного распространения, что и обычные слои.
Интуиция простая. Обычная модель похожа на читателя, который перечитывает весь том перед каждой фразой. Модель с внешней памятью открывает справочник на нужной странице: страниц миллионы, но за раз нужна пара штук.
Откуда взялась идея: Lample et al. 2019 и Memory Layers at Scale
Автор не претендует на новизну концепции. Он прямо ссылается на product-key memory (Lample et al. 2019) и работу Meta «Memory Layers at Scale»: идея дать сети большую таблицу выученных векторов с чтением нескольких сотен записей на токен появилась задолго до его проекта.
Вклад здесь в другом: практическая проверка на маленьком масштабе, ориентация на локальный запуск и переносимые между платформами ядра. Репозиторий, модель и просмотрщик таблицы автор выложил публично, о них ниже.
Эксперимент: 21M + таблица против 114M плотной модели
Сравнение шло в одинаковых условиях: те же 500M токенов Wikipedia, та же процедура оценки, различие только в архитектуре. Модель на 21M параметров с таблицей на 16,8M строк вышла примерно на уровень плотной модели на 114M (исходный пост автора).
Что именно сравнивалось и на каких данных
| Параметр | 21M + внешняя таблица | 114M плотная |
|---|---|---|
| Параметры модели | 21M | 114M |
| Параметры в таблице | 6,4 млрд, 16,8M строк | нет |
| Активно на токен | 33M из таблицы | все 114M |
| Обучающие данные | 500M токенов Wikipedia | те же 500M токенов |
| Качество на валидации | примерно как у 114M | базовый уровень |
Это не сравнение с продакшн-моделями на миллиарды параметров. Автор сам называет масштаб крошечным, и оценка честная: 21M и 114M далеки от того, что запускают в рабочем контуре.
Бюджет эксперимента скромный: большинство прогонов шли на игровом ПК автора, крупные прогоны обошлись примерно в 70 долларов на Runpod. Проект собирался вместе с Claude Code, но идеи, решения и деньги автор оставил за собой.
Почему это не значит, что таблица всегда лучше
Результат получен при одном seed для крупных прогонов, на маленьком масштабе и на узком домене Wikipedia. Он не доказывает превосходство над плотными моделями в общем случае и не переносится автоматически на другие данные.
Есть и прямой отрицательный результат: попытка прикрутить таблицу к уже обученной Qwen3.5-0.8B выигрыша не дала. Разбираю её отдельно ниже, потому что экономит время тем, кто рассматривал такой сценарий.
Как таблица на 6,4 млрд параметров помещается на SSD и не занимает VRAM
Таблицу не обязательно держать в видеопамяти. Автор квантует её до 4 бит и подключает через memory-mapping с NVMe SSD: модель выдаёт около 140 токенов/с на RX 9070, занимая всего 0,4 ГБ VRAM (данные автора).
Memory-mapping и 4-битное квантование: как это работает на практике
4-битное квантование сокращает размер таблицы в разы. Точных цифр объёма файла на диске автор не приводит, поэтому считаем по арифметике: 6,4 млрд параметров по 0,5 байта дают примерно 3,2 ГБ, и это оценка без служебных данных.
Memory-mapping меняет способ доступа. Операционная система подгружает с диска только те страницы таблицы, которые нужны прямо сейчас, а не весь массив целиком. Для ядра таблица выглядит как файл, из которого читаются нужные строки.
Почему длинные промпты читаются медленно
Узкое место в чтении с диска, и проявляется оно на prefill, а не на генерации. Каждый промах по строке таблицы стоит целой страницы в 4 КБ, о чём автор предупреждает отдельно.
На коротком промпте обращений к таблице мало, и латентность NVMe почти незаметна. С длинным контекстом число промахов растёт, и чтение страниц начинает тормозить обработку входа. Скорость 140 токенов/с к этой проблеме отношения не имеет: генерация идёт по уже прочитанным данным.
Практический вывод: экономия VRAM обменивается на латентность чтения. Если нужен длинный контекст, стоит смотреть на модели, которые целиком помещаются в память: разбор запуска MoE-моделей 35B, 120B и 176B на 11 ГБ VRAM показывает, где проходит реальная граница по памяти.
Мысль выносить статическую память на SSD уже обсуждалась в экспериментах вокруг Engram/N-gram-памяти: там речь шла о RAM- и SSD-тирах вместо размещения всех знаний в VRAM.
Triton-ядра: один код для Radeon, MI350X и H100/H200
Ядра для работы с таблицей написаны на Triton и без изменений запускаются на Radeon, MI350X и H100/H200. Один и тот же код идёт на GPU от AMD и NVIDIA.
Что даёт переносимость ядер на практике
Triton компилируется под разные бэкенды, поэтому горячий участок не приходится переписывать под каждую платформу. Для экспериментов это экономит время: собрал одну версию и проверяешь её на всём, что есть под рукой, от игровой карты до серверного ускорителя.
Речь именно о ядрах для чтения таблицы, а не обо всей инфраструктуре обучения. Автор не называет свой способ единственно возможным, но переносимость заметно снижает порог входа для тех, кто хочет пробовать на разном железе.
Отрицательный результат: таблица не помогла Qwen3.5-0.8B
Автор попробовал прикрутить таблицу к уже обученной Qwen3.5-0.8B. Выигрыша не вышло: результат не лучше небольшого плотного довеска при том же объёме вычислений.
Почему это важно для тех, кто хочет улучшить готовую модель
Отрицательный результат экономит время не хуже положительного. Если у вас есть обученная модель и вы рассматривали внешнюю память как способ прокачать её без переобучения, эксперимент говорит: при том же compute прироста ждать не стоит.
Гипотеза, которую обозначает автор: таблица должна обучаться вместе с моделью. У готовой сети знания уже распределены по плотным параметрам, и внешняя память не даёт преимущества, если её не встраивать с самого начала. Категоричным этот вывод называть рано, но направление поиска он задаёт.
Ограничения, о которых говорит сам автор
Автор перечисляет слабые места без попытки их замаскировать: крошечный масштаб, один seed для крупных прогонов и галлюцинирующий, хоть и беглый английский текст. Он также просит сообщество помочь с запуском на масштабе 1B (список ограничений и запрос к сообществу).
Что значит «один seed» и почему это важно
Один seed не показывает разброс результатов. Если при другом seed картина изменится, вывод о сопоставимости с 114M-моделью ослабнет. Для устойчивых утверждений нужны множественные прогоны, и автор это признаёт сам.
Галлюцинации при беглом тексте: что это говорит о модели
Модель пишет беглый английский в стиле Wikipedia, но с выдуманными фактами. Беглость речи и фактическая точность расходятся, и здесь это видно особенно наглядно.
Для маленьких моделей такая картина типична, и она не отменяет архитектурный результат. На практике ограничение критично: текст, который звучит правдоподобно, но содержит выдумки, в работу без проверки не годится. К громким заявлениям о возможностях железа вообще стоит подходить с одной меркой: сначала методика и метрики, потом цифра.
Что это значит для локального запуска LLM и стоит ли пробовать
Подход меняет баланс требований к железу. VRAM нужна минимальная, в конфигурации автора это 0,4 ГБ, зато появляется зависимость от скорости NVMe SSD и латентности чтения страниц. Для владельцев домашних AI-серверов с быстрым накопителем это интересный эксперимент, для продакшна решение пока не готово.
Где посмотреть код, модель и просмотрщик таблицы
Автор выложил репозиторий sparse-memory-lm на GitHub, модель sparse-memory-lm-B-16M на Hugging Face и интерактивный просмотрщик таблицы. В просмотрщике можно кликнуть по слову и увидеть, какие записи таблицы читает модель на этом шаге. Ссылки лежат в исходном посте, здесь я их не дублирую.
Кому это интересно, а кому пока рано
Интересно разработчикам, которые экспериментируют с архитектурами, владельцам быстрых NVMe и GPU для локальных прогонов, а также тем, кто следит за эффективными методами обучения. Рано тем, кто ищет готовый инструмент под рабочую нагрузку, и тем, кто надеется улучшить уже обученную модель добавленной таблицей.
Пока это исследовательский проект, а не продукт: масштаб 1B ещё не проверен. Если считаете бюджет под VRAM заранее, полезен разбор выбора между Qwen3.8-27B IQ3_XXS и Qwen3.6-35B-A3B Q4_K_M: там показано, как битность квантования и архитектура меняют требования к памяти.
Практический шаг, если тема зацепила: откройте просмотрщик таблицы, посмотрите, какие записи читаются на конкретные слова, и прикиньте, хватит ли пропускной способности вашего NVMe под длинные промпты. Пока не появятся прогоны на 1B и несколько seed, воспринимайте результат как рабочую гипотезу, а не как готовый рецепт экономии VRAM.