Хочу рассказать об интересном подходе к построению ML-моделей. Как известно, практически любая нейросеть - это, грубо говоря, некая архитектура + некий набор весов. Веса здесь, опять же если говорить грубо, циферки в матрице. Очень много циферок в очень большой матрице. Обычно соблюдается правило, что чем сложнее и “умнее” модель, тем больший размер имеют ее “матрицы с циферками”. Особенно в этом плане выделяются LLM: у Kimi-K3, например, 2,8 триллиона параметров. Обычно, чтобы использовать модель, нужно

а) иметь ее веса на диске, откуда их будешь грузить

б) загрузить нужные для расчётов веса в память. Обычно это видеопамять; все веса сразу или только текущий блок — зависит от реализации

Эти два условия во многом определяют требования к хранению и памяти. Например, у открытой Qwen2.5-7B-Instruct 7,61 млрд параметров, а файлы весов в BF16 занимают около 15,2 GB. И это одна из небольших LLM-моделей, у пресловутой Kimi-K3 - уже что-то около уже 1,4 ТБ, если отвести по четыре бита на каждый из 2,8 триллиона параметров.

На этом хватит про общеизвестные вещи. Эта статья писалась затем, чтобы рассказать про необычный вариант построения и сжатия ML-моделей, хоть и рассчитана на любительский уровень понимания. Некоторые из рассмотренных подходов известны давно, некоторые - едва появились в виде препринтов на arxiv. Я постарался включить в обзор все более-менее релевантное теме.

Итак, вопрос: а что, если можно использовать модель, не сохраняя ее веса? Ответ кажется очевидным, нельзя использовать то, чего у тебя нет - а модель многие отождествляют в первую очередь именно с ее весами. Но если разобраться, окажется, что иногда достаточно и “рисунка ключа”. Хотя будет более правильным назвать его рецептом - неким правилом, позволяющим “на ходу” собрать веса модели, не требуя их сохранения. Внимательный читатель может заметить, что рецепт в таком случае и будет “весами модели”, но, я надеюсь, вы простите мне это мелкое допущение и позволите для удобства изложения разграничить эти понятия.

Сразу оговорюсь, что эта статья не про какое-то мое сверхизобретение, это просто обзор нескольких опубликованных исследований со ссылками на первоисточники. И мы просто разберём, какие варианты составления рецептов пробовали авторы, что у них получилось и насколько это приближает большие языковые модели к участи первого “Doom” - быть запущенными на каждом чайнике.

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

Индексы указывают, какой элемент нужен, а небольшой набор параметров описывает генератор. Тогда вместо всей матрицы весов можно сохранить правило и параметры . Для вычисления слоя всё ещё нужно получить

Нам придется учитывать, что генерация весов и применение слоя — разные операции, имеющие свой вклад в потребление ресурсов.

Таким рецептом — — может быть маленькая нейросеть, кодовая книга или динамическая система; некоторые архитектуры даже используют настоящие фрактальные функции.

Начнём с обучаемых генераторов и постепенно перейдём к генераторы случайных чисел с фиксированным seed, локальным кодам и простым преобразованиям вместо матриц. По пути затронем смежные идеи: сжатие KV-кэша и самоподобные архитектуры, а завершим обзором общих блоков и повторных проходов. Методы и бюджеты сначала разберём по результатам их авторов; часть работ — свежие препринты 2026 года. А в конце посмотрим, что получилось в нашей выборочной проверке на CPU и MacBook.

Оглавление

• Три разных бюджета

• Обучаемый генератор: от гиперсети до координат

• Seed и латент: от килобайтной сети до блоков LLM и адаптеров

• Кодовая книга, траектория и вычисление блоков

• Формула вместо матрицы: спектр и простые множители

• Фрактал на связи и фрактал в топологии

• Рекурсия по глубине: один блок, много проходов

• Выборочное воспроизведение

• Насколько близка LLM на слабом устройстве

Три разных бюджета

Как уже было сказано, мы должны рассмотреть несколько свойств модели, которые меняются от замены ее весов рецептом. Мы рассмотрим три параметра, за изменением которых будем следить. Назовем их “бюджетами”.

Размер на диске - объем памяти, занимаемый моделью “на хранении”. Он состоит в основном из рецепта - генератора и всех данных, необходимых для восстановления весов модели: латентов, индексов, масштабов, оставленных обычных весов, если архитектура предполагает замену только части весов модели на генератор. Нужно учитывать, что мы не можем приравнять сокращение числа обучаемых параметров и эквивалентное сокращение файла “модели” на диске. Этот бюджет, впрочем, как и последующие, зависит от архитектуры конкретной модели.

Рабочая память - объем памяти (оперативной, видеопамяти), необходимый для модели во время работы. Состав зависит от реализации: можно сначала восстановить всю матрицу, а можно по частям генерировать её блоки: получить блок, умножить на соответствующую часть входа, добавить результат к выходу и освободить блок. Во втором случае нам не обязательно держать всю матрицу в памяти одновременно, но все равно нужны сам генератор, текущий блок, входы и выходы слоя, промежуточные активации. У LLM добавляется KV-cache — сохранённые ключи и значения attention для предыдущих токенов.

Цена вычисления - время, которое модель тратит на подготовку к работе и на сами вычисления. Восстановление весов иногда можно выполнить один раз при загрузке, а иногда оно входит в каждый проход. Поэтому время подготовки и время работы будем указывать отдельно. Если авторы измеряют пропускную способность — сколько запросов или токенов обрабатывается за секунду, — укажем и условия такого замера. Восстановление весов тоже требует вычислений; удастся ли спрятать их цену за другими операциями, зависит от реализации.

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

Наконец, перейдем к самому интересному и рассмотрим конкретные архитектуры генераторов

Обучаемый генератор: от гиперсети до координат

Наверное, самый очевидный вариант решения задачи “генерировать какую-то не имеющую закономерностей на первый взгляд фигню” - использовать нейросеть. Этот подход называется гиперсеть: сеть, которая генерирует веса другой сети. В HyperNetworks её входом служит обучаемое описание слоя, а выходом — нужные фильтры. В статическом варианте гиперсеть восстанавливает плотные ядра свёрток. Развернуть их все заранее и дальше пользоваться обычной сетью можно. Послойное восстановление позволило бы не держать их все одновременно — это один из вариантов реализации.

Для Wide ResNet 40-2 — свёрточной сети с обходными связями между слоями и увеличенным числом каналов — на CIFAR-10, наборе маленьких цветных картинок десяти классов, число параметров уменьшается с 2,236 млн до 0,148 млн, но ошибка классификации растёт с 5,66% до 7,23%. В этом опыте экономия вышла с потерей качества: параметров стало меньше, но ошибка выросла.

бюджеты

Диск — вместо независимых фильтров хранятся гиперсеть, описания слоёв и оставшиеся обычные параметры. Размер файлов не указан; расчёт по числу параметров в FP32 даёт примерно 8,94 → 0,59 MB.

Память — пик не указан; для работы восстанавливаются плотные ядра 36 свёрточных слоёв. Полная развёртка вернёт соответствующий объём весов в память.

Время — задержка этого сравнения не указана; генерация добавляет вычисления, но статические веса можно восстановить один раз перед обработкой входов. §3.1, §4.2, Table 2

Стоит упомянуть существование динамических гиперсетей - их особенность в том, что они меняют генерируемые веса основной сети в зависимости от входа и состояния. Но их задача, как правило, немного иная - большая выразительность за счёт подстройки весов под вход и состояние; такие сети не обязаны быть меньше исходной сети. В той же работе этот вариант проверяют на RNN и LSTM для последовательностей. Например, на текстах Penn Treebank сеть предсказывает следующий символ. У обычной LSTM ошибка составляет 1,312 бита на символ, а у HyperLSTM — 1,265; здесь меньше значит лучше.

бюджеты

Диск — размер файла не указан; в этом сравнении число параметров растёт с 4,25 до 4,91 млн, поскольку к основной сети добавляется гиперсеть.

Память — отдельный пик не указан; нужны также состояния гиперсети.

Время — численного сравнения задержки здесь нет; генерация вызывается на каждом шаге. §3.2, Table 3

В статической гиперсети выше входом было описание слоя. Можно пойти дальше и подавать генератору координаты двух нейронов — а на выходе получать вес связи между ними. Подобный подход опробован ещё в 2009 году в работе HyperNEAT. Здесь небольшая сеть задаёт рисунок связей через геометрию расположения нейронов. Так можно описывать симметрии и повторяющиеся мотивы, а поиск вести по параметрам этого описания. Но задача здесь — эволюционно построить подходящую сеть, а не упаковать веса уже обученной.

Проверяли это, например, на простой зрительной задаче: найти центр большого квадрата рядом с маленьким. Качество оценивали по расстоянию до правильного центра. Найденный на поле 11×11 генератор затем использовали для 55×55 без нового эволюционного поиска. Получились сети в среднем с 8,3 млн связей; статистически значимого падения качества при таком увеличении разрешения авторы не обнаружили. §4–5, Figure 10

бюджеты

Диск — можно хранить генератор и описание геометрии вместо списка всех связей; размер файла не указан.

Память — пик не указан; в опытах сначала строят сеть со сгенерированными связями, затем исполняют её.

Время — задержка генерации и исполнения не приведена; сеть строят перед оценкой каждого кандидата в эволюционном поиске. §3, §5.1–5.3

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

NeRN, Figure 1. Слева координаты превращаются в веса, справа восстановленная сеть сравнивается с исходной по весам, ответам и промежуточным признакам. p. 3

Но одной близости отдельных циферок оказалось недостаточно: небольшая ошибка в весе может заметно изменить ответ сети. Поэтому предиктор учат воспроизводить и веса, и выходы, и промежуточные признаки исходной модели. Ещё авторы переставляют ядра так, чтобы соседние координаты описывали более похожие значения; обратный порядок тоже нужно сохранить. §3

На ResNet20 и CIFAR-10 предиктор размером 0,65 MB восстанавливает сеть с точностью 91,68 ± 0,06% против исходных 91,69%. Если уменьшить его до 0,36 MB, точность становится 90,39 ± 0,05%. Компактность здесь регулируется размером самого генератора, и в какой-то момент это становится заметно по качеству. Table 1

бюджеты

Диск — 0,65 MB предиктора сравнивают с 1,03 MB свёрточных весов, а не с полным комплектом: для этой перестановки нужны ещё 0,04 MB карт перестановок и другие обычные параметры.

Память — для исполнения нужно восстановить веса; пик потокового варианта не измерен.

Время — скорость всей сети с генерацией в этом сравнении не приведена. Пока это результат для CNN, а не для языковой модели. §3.1, Appendix C–D

В Neural Metamorphosis координатный генератор используют уже для разных размеров сети - авторы генерируют веса и согласованно переставляют нейроны, облегчая обучение координатной функции. Перед исполнением восстанавливаются веса выбранной ширины. Авторы сравнивают сети с одинаковой шириной и стоимостью основного прохода.

На CIFAR-10 её ResNet20 — 20-слойная свёрточная сеть с теми же обходными связями — получает 91,76% при полной ширине и 89,56% при четверти каналов. Авторы пишут про сжатие на 75% - однако, если кто-то решит заглянуть в оригинал, прошу обратить внимание, что в статье «75% compression» означает удаление трёх четвертей каналов в сети, а не уменьшение файла генератора на 75%.

бюджеты

Диск — размер файла не указан; для NeuMeta в таблице приведены 0,20 млн хранимых параметров против 0,67 млн у набора отдельно обученных сетей разной ширины. Это примерно в 3,35 раза меньше параметров для всего набора.

Память — пик не указан; нужны восстановленные веса выбранной ширины и активации.

Время — задержка с учётом генератора не указана; более узкая сеть требует меньше операций, но сама координатная запись не делает свёртки дешевле. §4.1, Table 2

Ещё один вариант сжатия уже обученной модели описан в работе Big2Small: подобрать координатную сеть, приближающую её веса. Генераторы восстанавливают веса, затем те загружаются в исходную архитектуру для обычного прохода. Помимо ResNet, метод проверен на визуальном трансформере Swin и свёрточной U-Net для сегментации изображений.

На ImageNet — большом наборе изображений, здесь в задаче классификации на тысячу классов — точность ResNet18, 18-слойной свёрточной сети, меняется с 71,47% до 71,24%.

бюджеты

Диск — 44,6 → 7,6 MB для ResNet18, то есть 5,9×. Здесь работают сразу два источника экономии: генератор и шестибитная квантизация. Без квантизации, в FP32, рецепт занимает 30,4 MB и даёт 1,5× сжатия. В таблице режим 6/6 означает шесть бит и для весов, и для активаций.

Память — пик RAM/VRAM не указан; сжатый пакет на диске не заменяет восстановленные веса в рабочей памяти.

Время — в отдельном тесте на ImageNet и NVIDIA RTX PRO 6000 задержка с восстановлением весов выросла примерно на 30%. Figure 3, Table II, Inference Time

Seed и латент: от килобайтной сети до блоков LLM и адаптеров

До сих пор нашим рецептом была ещё одна нейросеть, которую тоже приходилось хранить. А можно ли сделать его ещё короче? В Kilobyte Models авторы оставляют seed — число, по которому генератор псевдослучайных чисел воспроизводит одну и ту же последовательность, — и небольшой обучаемый вектор. Этот вектор называют латентом: его значения задают положение модели в заранее выбранном семействе. Генератор здесь фиксирован: случайный базис и начальные веса восстанавливаются по seed, а дальше применяется заранее заданная нелинейная формула. Отдельную обученную сеть для этого хранить не требуется.

Здесь легко представить себе волшебный архиватор: скормили ему любую модель, получили пару килобайт. Но компактность закладывается ещё при обучении — авторы учат модель внутри ограниченного семейства, которое способен воспроизводить генератор. Сам seed знаний о задаче не содержит; они должны поместиться в латент. В приведённом ниже режиме рецепт состоит из seed, масштаба и 4 096 четырёхбитных значений латента; столь короткая запись получается при обучении с учётом квантизации.

Проверяют идею на небольших свёрточных сетях, полносвязных сетях для табличных данных и рекуррентной LSTM. Например, CNN с 105 866 параметрами на MNIST, наборе рукописных цифр, получает 98,60% точности против 98,99% у полной FP32-модели. На Fashion-MNIST, где вместо цифр нужно различать предметы одежды, результат уже 89,11% против 91,06%. Всё ещё неплохо, но ограниченная ёмкость рецепта становится заметнее.

бюджеты

Диск — компактное описание выбранной CNN занимает 2 060 байт.

Память — полный пик с генерацией не указан; после восстановления сеть работает с обычными плотными весами.

Время — замера вместе с восстановлением нет; вычисления самого прохода не сокращаются. Авторы прямо пишут: «do not compress inference compute». Limitations

Случайный базис можно использовать и без нелинейного генератора. В PRANC веса — линейная комбинация фиксированных случайных сетей:

.

Seed воспроизводит базис, а обучаются коэффициенты . Это тоже обучение внутри выбранного семейства, а не способ без потерь сохранить любую готовую сеть.

На ResNet18 и ImageNet-100 точность меняется с 82,1% до 61,08%. Сильное сокращение здесь хорошо видно вместе с его ценой. Table 4

бюджеты

Диск — вместо 11,23 млн параметров исходной модели хранят 100 000 коэффициентов, seed и 19 200 параметров BatchNorm; размер готового файла не указан.

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

Время — замера задержки с пофильтровым восстановлением здесь нет. p. 4, Table 4

А вот SeedLM применяет похожую идею к уже обученной LLM. Только рецепт здесь относится не ко всей сети сразу, а к небольшому блоку весов. Для каждого блока подбирают seed и коэффициенты смеси. Простой генератор псевдослучайной последовательности — LFSR, регистр сдвига с обратной связью, — по seed строит матрицу , а коэффициенты дают приближение нужного блока: .

SeedLM, Figure 2. Матрицу U(s) хранить не требуется, но seed и коэффициенты нужны для каждого блока. p. 3

Здесь важно не потерять слово «каждого»: миллиарды весов не помещаются в одно число. Экономия получается потому, что локальное описание блока короче списка его элементов. Авторы сжимают модель без калибровочных данных и дообучения. На Llama 2-7B, WikiText-2 и контексте 2048 perplexity — метрика предсказания токенов, где меньше значит лучше, — меняется с 5,5 у FP16 до 5,7 при четырёхбитном представлении и 6,6 при трёхбитном. Но у Llama 3-70B даже четырёхбитный вариант даёт 3,8 вместо 2,9: одинаковый рецепт не означает одинаковой потери качества. Table 2

бюджеты

Диск — 3–4 бита на вес в описанном формате, включая локальные seed, коэффициенты и масштабы; полного файла эта цифра не описывает.

Память — аппаратная реализация восстанавливает веса для матрично-векторного оператора; общего пика LLM с KV-cache здесь нет.

Время — оператор на FPGA ускоряется в 3,67–3,98 раза. При этом сжатый вариант использует 128 DSP-блоков против 32 у сравниваемого FP16: меньше чтений из памяти позволяет загрузить больше вычислителей. Это полезный аппаратный результат, но пока не скорость генерации текста всей LLM на обычном ноутбуке. pp. 9–10

У Seed-Q сохраняется тот же общий принцип, но более чувствительные участки весов получают больше битов. Сколько бит приходится на каждый блок, декодер определяет по общему правилу. Отдельный список для всех блоков хранить не нужно, хотя небольшие общие таблицы и часть весов в FP16 всё же остаются.

На Llama 2-7B и WikiText-2 при контексте 2048 выбранный вариант получает perplexity 5,85 — такую же, как четырёхбитный SeedLM в реализации этих авторов. Table 1

бюджеты

Диск — 3,77 бита на вес относятся к основному коду; служебные данные, общие таблицы и оставшиеся веса в FP16 учитывают дополнительно. Размер полного файла не указан.

Память — общий пик LLM не приведён; аппаратные расходы авторы оценивают синтезом схемы.

Время — замера скорости всей LLM на изготовленном ASIC здесь нет. §4.2, Appendix A.7

С тем же инструментом можно чинить уже сжатые веса. В Activation-Weighted Seeded Residual Coding, или AWSRC, seed-базис описывает ошибку между исходной матрицей и её квантованной версией. При выборе поправки учитывают, как ошибка влияет на выход слоя.

В одном из опытов с Qwen2.5-3B-Instruct perplexity WikiText-2 при контексте 2048 меняется с 9,834 после исходного сжатия до 7,075 с поправкой, при 6,704 у BF16. Качество оценивают после восстановления весов в BF16. Авторы также проверяют загрузку самостоятельного комплекта без плотного исходника. §4.2–4.3

бюджеты

Диск — самостоятельный комплект занимает 2,60 GB; сама поправка добавляет 0,162 бита на вес заменяемых MLP-матриц, а не всех параметров модели. Маленькая поправка сама не заменяет модель: нужны и сжатая основа, и остальные веса.

Память — в этом опыте веса восстанавливают в BF16; общий пик не приведён.

Время — скорость исполнения с упакованным кодом этим опытом не установлена. §4.2–4.3

Наконец, рецепт может описывать только дообученную поправку. У LoRA эта поправка задаётся произведением двух небольших матриц. В NOLA сами эти матрицы записывают как смеси случайных базисов: хранят seed и обученные коэффициенты. Поправку можно заранее слить с основой и получить обычные плотные веса без добавочных операций при исполнении.

Для восьмибитной Llama 2-70B точность MMLU с пятью примерами в запросе — 69,4% у NOLA против 69,5% у LoRA ранга 1. Table 5

бюджеты

Диск — адаптер NOLA содержит 0,57 млн параметров против 12,94 млн у LoRA; размер файлов не указан. Основная 70B-модель в это сравнение размеров адаптеров не входит.

Память — в отдельном опыте обучения GPT-2 L на RTX 6000 Ada она остаётся около 33,4 GB у обоих подходов, то есть не сокращается в той же пропорции. Это память обучения, а не пик инференса.

Время — после слияния поправки с основой добавочных операций нет; отдельного замера задержки в этом сравнении не приведено. Table 2, Table 5, §3.1

В GenLoRA вместо фиксированной случайной смеси используют лёгкие нелинейные генераторы с радиальными базисными функциями — RBF. Они по латентам создают те же небольшие матрицы поправки. Как и у NOLA, поправку можно слить с плотной основой.

На Llama 3-8B после обучения на Math10K средняя точность шести математических задач — 70,17% против 67,28% у LoRA. Table 1

бюджеты

Диск — адаптер в этом сравнении содержит 0,98 млн параметров против 4,72 млн у LoRA; размер полного комплекта с основной моделью не указан.

Память — в отдельном опыте обучения на задачах кода на RTX A6000 пик GPU-памяти уменьшается лишь с 31 724 до 30 460 MB. Это память обучения всей системы, а не размер адаптера и не пик инференса.

Время — в том же опыте обучение занимает примерно столько же: 11,6 → 11,7 часа. Замера задержки инференса здесь нет; после слияния поправки работает плотная основа. Table 1, Appendix G.4, Table 9

Кодовая книга, траектория и вычисление блоков

Теперь посмотрим на другой способ приблизить уже обученную большую модель. Один короткий латент для неё может оказаться тесноват, зато никто не запрещает хранить множество маленьких кодов и общий способ их расшифровки. Примерно как заменить повторяющиеся слова в тексте номерами из словаря — только здесь восстанавливаемые кусочки весов могут немного отличаться от оригинала.

В PocketLLM такой словарь называется кодовой книгой. Это таблица латентных векторов: индекс выбирает строку, а небольшой нейронный декодер превращает её в группу весов. Весь рецепт включает индексы, кодовую книгу и декодер. После загрузки декодированные группы собираются обратно в матрицы слоёв.

Метод проверяют на языковых трансформерах Llama2-7B и Qwen3-14B. Для Llama2-7B при 2,98 бита на сжимаемый вес средняя точность пяти задач после дообучения составляет 64,07% против исходных 64,29%. Без дообучения получается 59,53%; при 1,60 бита даже с ним — 55,45%. То есть маленький файл здесь покупается не только выбором кода, но и дополнительным обучением.

бюджеты

Диск — 2,98 бита на сжимаемый вес в приведённом режиме; размер полного файла не указан. Заявленные «около 10×» считаются относительно FP32 и учитываемых сжатых весов; это не коэффициент уменьшения всего файла и тем более не обещание ещё раз вдесятеро сжать уже четырёхбитную модель.

Память — пик не указан; нужны восстановленные веса, активации и KV-cache.

Время — задержка с декодированием не указана; восстановление добавляет операции, но результатов замера их влияния на время запуска авторы не приводят. Algorithm 1, Compression Ratio Analysis

Такое описание весов можно сочетать с обычной низкоранговой частью. В ReALLM матрицу представляют как сумму этой части и сжатого остатка. Для остатка предусмотрены и векторное квантование, и нейронный декодер HNeRV. Поэтому результат конкретной таблицы нельзя автоматически приписать только нейронному варианту.

На Llama 2-7B проверяют двухбитный вариант при контексте 2048. Ранг низкоранговой части — 64, размерность векторного квантования — : числа латентного представления объединяют по четыре. Без дообучения perplexity WikiText-2 составляет 40,85, после полного цикла дообучения — 6,69; у FP16 — 5,47. Небольшой код здесь работает вместе с дополнительным обучением. Tables 1–2

бюджеты

Диск — кроме сжатого остатка нужны низкоранговые компоненты, данные декодера, масштабы и остальные веса; размер полного файла для этого сравнения не указан.

Память — полный пик инференса не приведён.

Время — подготовка Llama 2-7B вместе со сжатием и дообучением занимает около 90 часов на A40; это время подготовки, не генерации ответа. Скорость исполнения всей модели в этом сравнении не указана. §4

В Neural Weight Compression авторы идут ещё дальше: учат общий кодек на наборе весов, а потом применяют его к другим моделям. Вместе с декодером обучается вероятностная модель для энтропийного кодирования — частые значения получают более короткое описание.

Кодек, обученный на Llama 3-8B, проверяют в том числе на Qwen. У Qwen3-8B в выбранном режиме средний результат четырёх reasoning-тестов — 69,0% против 70,0% у 16-битной основы. Этот результат получен с дополнительным дообучением при сжатии: ещё несжатые слои внутри каждого блока подстраивают под ошибки уже сжатых. Table 1

бюджеты

Диск — 3,94 бита на вес в приведённом режиме; размер полного комплекта с общим декодером не указан.

Память — реализация исследуется на уровне отдельных тензоров и восстанавливает их целиком; полный пик модели не приведён.

Время — совмещённое декодирование по плиткам авторы оставляют дальнейшей работе; ускорение ответа этим сравнением не установлено. Table 1, Limitations

Общий декодер, впрочем, необязательно должен быть нейросетью. В Hyper-Compression авторы используют траекторию динамической системы — иррациональную намотку тора. Если убрать геометрическое название, рецепт выглядит довольно просто. Для каждой группы весов подбирают числовой код. Умножив его на заданные коэффициенты и взяв дробные части результатов, можно приблизительно восстановить эту группу. Для разных групп сохраняются свои коды ограниченной длины, масштабы и служебные параметры.

В математической модели траектория может подходить сколь угодно близко к нужным точкам. Но номер подходящего места на ней тоже придётся записать, и для более точного приближения короткого кода может не хватить. Фрактальной функции в этом механизме нет. Чтобы не ждать распаковки всей модели, авторы предлагают восстанавливать следующие слои параллельно с работой предыдущих. Цена декодирования остаётся, но часть её можно скрыть за вычислениями.

Оригинальная Figure 1 из Hyper-Compression: параметры заменяются описанием, затем восстанавливаются. Практический алгоритм хранит множество локальных кодов. p. 2

Метод проверяют и на свёрточных моделях для изображений, и на LLM семейств LLaMA и Qwen. Для LLaMA2-7B средняя точность восьми задач меняется с 65,88% до 64,89%: потеря 0,99 процентного пункта. Perplexity на WikiText-2 растёт с 5,47 до 5,82. В той же таблице GPTQ int4 даёт perplexity 5,69. В этом сравнении GPTQ и компактнее, и даёт меньшую perplexity на WikiText-2. Tables 5–6 Средние оценки PocketLLM и Hyper-Compression напрямую сравнивать нельзя: наборы задач у них разные.

бюджеты

Диск — LLaMA2-7B: 12,50 → 4,80 GB, то есть 2,60×; для GPTQ int4 в той же таблице — 3,46×.

Память — пик для этого сравнения LLaMA2 не указан; нужны рецепт и развёрнутые слои, которые уже используются или подготовлены.

Время — задержка LLaMA2 не приведена. У U-Net при batch=1 получается 4,35 → 4,43 секунды на RTX 4060 и 1,50 → 2,06 секунды на A40. Это замеры другой модели; задержку LLM по ним вычислить не получится. §4, Table 15

Следующий логичный вопрос: а зачем вообще сначала создавать полную матрицу слоя, если мы собирались сразу умножить её на вход? В Birkhoff / HyperLinear декодирование блока весов совмещено с матричным умножением. Блок восстановили, использовали, перешли к следующему. Это уже практический пример того варианта, который мы обсуждали в разделе о рабочей памяти.

Реализация использует CUDA/Triton; перенос такого оператора на слабый CPU — отдельная инженерная задача. Метод проверен на GPU и моделях семейства SAM для сегментации — выделения объектов на изображении. Например, у SAM-B на COCO с подсказками в виде рамок качество сегментации mAP меняется с 37,0% до 36,8% — потеря 0,2 процентного пункта. Результатов для LLM эта работа не даёт. Table VI

бюджеты

Диск — для SAM-B из Table VI сжатие составляет 4,31×; в аннотации авторы сообщают 5,17× для SAM2-B. При сохранении индексы плотно упаковываются: под каждый отводится нужное число бит. По коэффициенту сжатия метод пока не превосходит INT6.

Память — общий пик VRAM не указан; полная матрица заменённого линейного слоя не создаётся, но остаются рецепт, рабочие блоки, активации и остальные веса. В HyperLinearV1 один uint16-индекс приходится на пару весов: около восьми бит на исходный вес ещё до вспомогательных данных. Это рабочая индексная матрица, а не её упаковка на диске.

Время — в Table V все шесть проверенных сжатых SAM работают медленнее исходных; совмещение декодирования с умножением сокращает расходы относительно раздельного выполнения этих операций. Table V, упаковка индексов, реализация HyperLinearV1

Но есть и работа, где компактный код уже проверили по скорости целой LLM. В QTIP вместо независимого выбора строки кодовой книги используют код с решёткой состояний — trellis. Его состояние сдвигается по мере чтения битов, а последовательность состояний задаёт восстановленные веса. Здесь кодируют сразу длинную последовательность: это позволяет учитывать её устройство, не заводя огромную таблицу всех возможных комбинаций.

QTIP, левая панель Figure 1. Блок весов кодируется путём по решётке состояний; значение веса задаётся декодером выбранного состояния. p. 2

Значение, соответствующее состоянию, необязательно хранить в таблице. У QTIP есть варианты, где оно вычисляется несколькими простыми инструкциями, и гибридный вариант, где формула выбирает строку небольшой таблицы. Перед кодированием авторы ещё меняют базис весов рандомизированным преобразованием Адамара. Сам по себе псевдослучайный декодер не узнаёт веса: нужную последовательность состояний подбирают при сжатии. §3

Чисто вычисляемый вариант 3INST на Llama 2-7B, WikiText-2 и контексте 4096 даёт perplexity 5,17 при четырёхбитном представлении против 5,12 у FP16. При двухбитном — уже 6,82. В этом опыте дообучения нет. Скорость измеряют отдельно для гибридного декодера. Это два варианта рецепта; склеивать качество первого со скоростью второго было бы неправильно. Table 3

бюджеты

Диск — битовый поток, вспомогательные параметры и таблица размером 2 KiB у гибрида; 2 или 4 бита в названии режима не описывают весь файл.

Память — декодирование совмещено с умножением, но из этого не следует величина общего пика с KV-cache.

Время — двухбитная Llama 2-7B с гибридным декодером выдаёт 188 токенов/с против 55,9 у FP16 на RTX 6000 Ada, batch 1. Здесь уже есть генерация текста всей моделью, а не только скорость одного оператора. Такой же эффект на слабом CPU или Metal ещё надо проверить. Table 4, §4.2

Свежий XOR-Trellis продолжает эту линию: значение веса восстанавливается простыми XOR-операциями и небольшой палитрой, а преобразование Адамара во время исполнения не требуется. При подборе кода учитывают влияние ошибки на слой.

На Llama 3.1-8B, WikiText-2 и контексте 4096 авторы получают perplexity 8,00 против 5,84 у BF16, без дообучения, но с калибровкой. Table 1

бюджеты

Диск — около 2,25 эффективных битов на вес вместе с масштабами; размер полного файла модели не указан.

Память — общий пик LLM не приведён; есть оценка площади аппаратного декодера, но это другая величина.

Время — скорости генерации всей LLM на таком устройстве эта оценка пока не даёт. §5

Другой вариант — хранить координаты квантованных весов и упаковывать их энтропийным кодированием: частые значения получают короткие коды. В EntroPack поток делят на небольшие блоки — плитки. Каждую можно распаковать отдельно, не читая предыдущие. GPU-оператор читает код и сразу восстанавливает численные веса, а следующее умножение остаётся отдельной операцией.

На генераторе изображений Z-Image-Turbo ошибка самих весов ниже, чем у сравниваемого NF4: 7,18% против 9,41%. Ошибка весов, впрочем, не равна качеству изображений. Table 1

бюджеты

Диск — 4,02 бита на вес выбранных линейных слоёв вместе с метаданными против 4,50 у NF4. Это сжатые слои, а не весь комплект с текстовым энкодером.

Память — общий пик модели для этого сравнения не приведён; веса восстанавливают плитками, а умножение выполняют отдельно.

Время — один шаг удаления шума на NVIDIA H20 занимает 544,7 ms против 505,7 ms у BF16. Из этого времени исключены первый шаг, обработка запроса и финальное получение изображения. Для длинной обработки входного текста цена распаковки легче скрывается за вычислениями, а обычный быстрый decode LLM из этого результата не следует. Table 1, Appendix A.1/A.5

Формула вместо матрицы: спектр и простые множители

В предыдущих рецептах мы восстанавливали веса, иногда прямо во время умножения. Но можно задать само умножение через несколько простых преобразований. В ACDC вместо одной большой матрицы используют цепочку действий: по отдельности масштабируют элементы вектора, переходят к косинусным коэффициентам, ещё раз масштабируют и возвращаются обратно. Масштабы обучаются, а косинусное преобразование фиксировано. Если записать входной вектор строкой, получится

,

где и — обучаемые диагональные матрицы, — косинусное преобразование, а — размер входного вектора. Одному такому модулю нужны параметров и операций; несколько модулей можно поставить последовательно. Плотную матрицу для исполнения строить не требуется.

В CaffeNet на ImageNet авторы заменяют два полносвязных слоя. Ошибка top-1 вырастает на 0,67 процентного пункта. Table 1

бюджеты

Диск — число параметров всей модели меняется с 58,7 до 9,7 млн; размер полного файла не указан. Это сокращение числа параметров CNN.

Память — плотную матрицу заменённого слоя строить не требуется, но общий пик модели не приведён.

Время — скорость одного слоя авторы измеряют на Titan X, для прямого и обратного прохода. Это отдельный операторный тест, из которого нельзя получить время ответа всей модели или обещать шестикратное ускорение по сокращению параметров. §5, Figure 2

В ACDC косинусное преобразование участвует в самом вычислении слоя. А в Evolving neural networks in compressed weight space, работе 2010 года, спектральные коэффициенты служат компактной записью весов: эволюционный поиск ведут по коэффициентам Фурье, из которых затем восстанавливают матрицы. Высокие частоты отбрасывают, чтобы уменьшить пространство поиска. Авторы рассматривают задачи управления, включая балансировку шеста и управление рукой осьминога. Здесь ищут подходящую сеть в компактном представлении, а не сжимают готовую сеть.

В симуляции руки осьминога рецепт из 40 коэффициентов задаёт сеть с 728 весами. Средняя оценка лучших найденных контроллеров — 0,38 против 0,17 у прямого поиска по всем весам, по 20 прогонам. Эта оценка учитывает время движения и расстояние до цели; здесь больше значит лучше. §3.3, Table 3

бюджеты

Диск — в этом опыте достаточно 40 DCT-коэффициентов и описания архитектуры вместо 728 весов; размер файла не приведён.

Память — пик не указан; перед оценкой кандидата из коэффициентов восстанавливают матрицы сети.

Время — замера задержки готовой сети нет; число оценок кандидатов в работе характеризует эффективность эволюционного поиска. §2.1–2.2, Tables 1–3

В препринте Training Transformers in Cosine Coefficient Space эту идею проверяют уже при обучении маленького языкового трансформера. Матрицы attention и FFN задаются выбранными DCT-коэффициентами — коэффициентами косинусного преобразования. Перед каждым проходом веса восстанавливаются обратным преобразованием.

У четырёхслойной символьной модели на tinyShakespeare validation loss меняется с 1,580 до 1,604. Это один seed и небольшой опыт, из которого нельзя вывести равенство качества больших LLM. Table 1

бюджеты

Диск — число обучаемых параметров уменьшается с 818 048 до 424 832; размер готового файла не указан.

Память — плотная матрица в основном опыте всё ещё создаётся, общий пик не приведён.

Время — авторы обсуждают прототип на Metal, но замер совмещённого восстановления и умножения внутри обучения оставляют дальнейшей работе. Скорость всей модели с таким исполнением здесь не установлена. Table 1, p. 5

У готовой LLM, впрочем, не обязана сразу обнаружиться удобная структура весов. В ProcrustesGPT авторы сначала переписывают веса в другом базисе. Для этого подбирают согласованные ортогональные преобразования, которые сохраняют поведение исходной модели. Затем веса приближают структурированными матрицами. Один из вариантов — сумма произведений Кронекера, где большую матрицу собирают из небольших множителей.

На Llama 2-7B perplexity WikiText-2 растёт с 5,47 до 8,19. Данные для калибровки используют, дообучение для восстановления качества — нет. Сохранение поведения при смене базиса не делает последующее приближение без потерь. Table 3

бюджеты

Диск — этот вариант сокращает число параметров всей модели на 25,09%; в рецепт входят и сами преобразования. Размер полного файла не приведён.

Память — общий пик для этого сравнения не указан.

Время — замера скорости генерации здесь нет; уменьшение числа параметров само его не заменяет. Table 3, §5.4, §6

Теперь ненадолго сделаем перерыв и перейдём от весов к KV-cache. Это соседняя задача: здесь компактно записывают промежуточные данные, а не параметры модели. Она полезна для нашего вопроса про гипотетический чайник — память ему потребуется и для весов, и для контекста. В EinSort перестановка индексов помогает найти структуру, удобную для тензорного разложения. Но порядок тоже надо сохранить, и полная карта перестановки может съесть всю экономию; авторы используют общие перестановки для групп элементов.

В основном опыте исполнения для Qwen3-0.6B сначала обрабатывают 64 токена, сжимают кеш, затем генерируют до 64 новых. В режиме, который авторы обозначают как «Compression 90%», вариант tensor train — цепочка небольших тензоров — даёт perplexity 27,04 против 47,38 у SVD-варианта в том же опыте. Эти числа сравнивают два варианта сжатого кеша; сколько качества потеряли относительно исходного кеша, по ним не определить. Tables 2–3

бюджеты

Диск — уменьшение файла весов в этом опыте не рассматривается: здесь сжимают кеш.

Память — «90%» здесь обозначает режим разложения кеша. Полный расход с учётом перестановки и битов знака не приведён; общий пик модели тоже.

Время — скорость на A40 составляет лишь 61,9% от модели без разложения кеша. Лучшее представление кеша здесь покупается дополнительной работой; ускорения всей модели этот опыт не показывает. §3, Tables 2–3

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

Для проверки исполнения авторы отдельно сжимают только расширяющие проекции up и gate у Llama 3-8B. В режиме с 40% сокращением их представления средняя точность восьми задач меняется с 70,4% до 61,9%. Сравниваемый SVD-вариант быстрее, но хуже по качеству. Table 6

бюджеты

Диск — 40% сокращения относятся к представлению выбранных проекций, в которое входят словарь, значения коэффициентов и маски; размер полного файла модели не указан.

Память — общий пик с KV-cache не приведён; слой исполняют через словарь и разреженные коэффициенты.

Время — средняя скорость синхронной генерации на RTX 3090 — 48 токенов/с против 44 у плотной модели, по запросам длиной от 1 до 256 токенов. Это измерение целой LLM с выбранными заменами, а не ускорение любого слоя или любого режима сжатия. Table 6, Appendix A.11/A.15

В CoSpaDi столбцы матрицы задаются через общий словарь и разреженные коэффициенты. Другой вариант — разложить само действие слоя на несколько небольших преобразований входа. Так работает Tensor Mixture, или MixT: вместо одного большого умножения выполняют несколько небольших и складывают результаты. Для этого вход представляют многомерным массивом. Каждая часть работает с несколькими его осями, оставляя остальные без изменения; разные части могут работать с одними и теми же осями. Такие части называют локальными тензорными операторами. Так слой можно исполнить без сборки плотной матрицы. Можно менять число локальных частей и число заменённых блоков трансформера; после замены их дообучают.

В одном варианте Llama 2-7B заменяют 17 блоков. При четырёх локальных частях точность MMLU после дообучения — 43,56% против 46,38%. При дальнейших заменах качество резко падает. §IV, Table I

бюджеты

Диск — число параметров всей модели меняется с 6,74 до 3,58 млрд; расходы хранения в работе — оценки, а не замер готового файла.

Память — измеренный пик инференса меняется с 12,61 до 6,79 GiB. Полные условия замера вынесены в отдельное приложение, которого в доступном тексте нет.

Время — приведены оценки FLOPs, а не замер скорости токенов; слой можно исполнить без сборки плотной матрицы. §IV, Table I

У MixT результаты небольших преобразований складываются. Ещё один вариант — приблизить матрицу произведением простых множителей. В Double Binary Factorization, или DBF, таких множителя два: знаковые матрицы с вещественными масштабами. В знаковых матрицах только −1 и +1. Промежуточный размер регулирует компактность и точность, а умножение на знаки позволяет заменить часть обычных умножений сложениями.

На Llama 3-8B при среднем бюджете 2,3 бита на исходный вес вариант с дополнительным дообучением масштабов и знаков матриц (PV) даёт perplexity WikiText-2 6,86 против 5,54 у плотной модели. Дообучение требуется уже при подготовке базового DBF, а PV добавляет ещё один этап. Table 2, §3.4, §4.1

бюджеты

Диск — средний бюджет DBF в этих опытах — 2,3 бита на исходный вес; размер готового файла со всеми параметрами не приведён.

Память — общий пик модели не указан.

Время — в отдельном замере генерации целая Llama 3-8B выдаёт 121 токен/с против 60 у FP16 на RTX 4090. Условия — batch 1, 128 токенов из пустого запроса, скомпилированный граф; бюджет DBF — те же 2,3 бита. Это уже реальное ускорение полного decode на GPU. Table 5, §4.4

В DiBA два множителя содержат только нули и единицы. Между ними и по краям стоят обучаемые масштабы — три диагональные матрицы. Формула выглядит так:

,

где и — бинарные матрицы. Вариант DiBARD фиксирует бинарные части и дообучает только диагонали.

Так заменяют, например, 48 attention-проекций Audio Spectrogram Transformer, который классифицирует звуковые команды. Точность после замены — 76,84%, после дообучения диагоналей — 97,81%, у исходной модели — 98,37%. Остальные веса модели при этом оставляют обычными. Table 3

бюджеты

Диск — размер считают по теоретической битовой упаковке, а не по готовому файлу.

Память — расход при исполнении не измерен; реализация с обычными плотными операциями может хранить бинарные множители как числа с плавающей точкой и занимать больше расчётного объёма.

Время — в отличие от DBF, скорость инференса здесь не измеряют. §6, Appendix C

Фрактал на связи и фрактал в топологии

А вот в FI-KAN появляется фрактал: он участвует в самом преобразовании входа. В обычном KAN на связях между узлами находятся обучаемые функции, а здесь их строят с помощью фрактальной интерполяции — повторяющихся сжимающих преобразований. В чистом варианте она заменяет сплайны, то есть функции из состыкованных полиномиальных кусочков. В гибридном сплайны остаются, а к ним добавляется фрактальная поправка.

Исследуют такие сети на аппроксимации функций: модель должна по входному числу или координатам приблизить нужное значение. В сопоставимом сравнении гибрид выигрывает по ошибке на трёх из четырёх функций. Это любопытный результат о том, какие функции удобнее приближать с помощью такого базиса, но не способ упаковать готовую LLM. Table 3

Фрактальная функция сама требует последовательных шагов. В тесте на функции Вейерштрасса лучший результат даёт глубина , то есть две итерации вычисления базиса. В этом тесте увеличение глубины не помогло: ошибка выросла, а обучение заняло больше времени.

бюджеты

Диск — размер файла не указан; у сопоставимого KAN 864 параметра, у гибридного FI-KAN — 840.

Память — пик не указан; нужны параметры функций и промежуточные значения их вычисления.

Время — задержка готовой модели не указана; приведённое сравнение глубины относится ко времени обучения. Table 8

Теперь посмотрим на два соседних фрактальных подхода. Они помогают разграничить генерацию весов и самоподобное устройство самой сети. В FractalNet самоподобным делают граф соединений обычных свёрточных слоёв. Приём drop-path отключает отдельные пути во время обучения, чтобы сеть не полагалась только на одну их комбинацию. Здесь рецепт рисует архитектуру, а численные веса свёрток всё равно надо сохранить.

Эти сети классифицируют изображения на CIFAR, SVHN и ImageNet. Например, на ImageNet у FractalNet-34 ошибка top-1 — 24,12% против 24,19% у сравниваемого ResNet-34 C. Это доля изображений, для которых первый выбранный класс оказался неверным; сравнение выполнено на validation с десятью фрагментами каждого изображения — 10-crop. Table 2 Работают и более короткие подсети, которые можно извлечь из полного графа.

бюджеты

Диск — размер файла не указан; для отдельной 20-слойной версии из Table 1 приведены 38,6 млн обычных весов.

Память — пик не указан; нужны веса и активации выбранных путей.

Время — зависит от выбранного пути: авторы показывают компромисс скорости и точности между короткими и длинными подсетями. Это исполнение меньшей части графа; все веса из одной фрактальной формулы здесь не восстанавливаются. §3, §4

В Fractal Generative Models самоподобным делают уже устройство генеративной модели: модули вызываются рекурсивно, деля изображение на всё меньшие части вплоть до значений RGB. Здесь «генеративная» означает, что сеть генерирует данные, а не веса другой сети. У уровней модели различаются ширина и глубина; всю сеть одним общим набором параметров этот пример не описывает.

На ImageNet 256×256 модель FractalMAR-H получает FID 6,15 — метрику близости распределений полученных и настоящих изображений, где меньше значит лучше. Table 4

бюджеты

Диск — у FractalMAR-H 848 млн параметров; размер файла не указан.

Память — общий пик для этого сравнения не приведён.

Время — при batch 1024 на H100 PCIe авторы получают в среднем 1,29 секунды на изображение. Это не задержка одного изображения при batch 1. Table 4, §4.2, §5.2

Рекурсия по глубине: один блок, много проходов

А что, если много раз выполнять один и тот же блок с общими весами? Тогда его веса можно хранить один раз, а пользоваться ими много раз. Формально это выглядит так:

где — промежуточное состояние. На каждом проходе состояние меняется, параметры остаются общими. Получается ещё один способ экономии, хотя произвольную матрицу во фрактальную формулу мы по-прежнему не превратили.

Huginn — уже языковая модель: 3,5 млрд параметров, обучение на 800 млрд токенов. Повторения общего блока не добавляют независимых наборов весов, но для разных проходов нужны промежуточные состояния и KV-cache. Авторы отдельно исследуют ограниченный кеш с перезаписью старых шагов.

Дополнительные проходы общего блока улучшают ряд задач рассуждения, пока эффект не выходит на плато.

Оригинальная Figure 1 из Recurrent Depth: эффект повторений зависит от задачи и выходит на плато. Верхняя шкала materialized parameters характеризует развёрнутые вычисления, а не размер хранимой модели. p. 1

бюджеты

Диск — размер файла не указан; GB — только расчёт объёма параметров в 16-битном представлении.

Память — общий пик VRAM не указан; ограниченный кеш уменьшает часть расхода, связанную с KV.

Время — вычислить общий блок несколько раз дороже, чем один; численного сравнения задержки здесь нет. §6.2

В Mixture-of-Recursions авторы идут дальше: пусть модель сама решает, сколько проходов требуется отдельному токену. Маршрутизатор выбирает глубину, а система управления KV-cache не держит одинаковый набор записей для всех возможных шагов. Общие слои сокращают число независимых весов; выбранная стратегия кеширования позволяет одновременно обслуживать больше запросов.

Проверяют подход на языковых трансформерах, построенных на конфигурациях от 135 млн до 1,7 млрд параметров. В дополнительном сравнении масштаба 1,7B при одинаковом бюджете вычислений на обучение обычная модель получает среднюю точность шести задач 48,9%, а MoR с двумя проходами — 48,4%. Задачи решали в режиме few-shot — с несколькими примерами в запросе. При этом MoR обучали на 26 млрд токенов против 20 млрд у обычной модели. Это отдельное сравнение качества; ниже приведён замер скорости меньшей конфигурации. Table 7

бюджеты

Диск — размер файла не указан; независимых весов меньше благодаря общим слоям.

Память — полный пик не указан; допустимый batch рассчитан по весам и KV-cache без текущих скрытых состояний.

Время — на конфигурации масштаба 360M вариант MoR-4 достигает до 2,06× по пропускной способности — числу токенов в секунду — на H100 при batch 51 против 32 у соответствующей обычной модели с 34 слоями. Из замера исключены сохранение и обновление KV. По этим числам нельзя обещать вдвое более быстрый ответ одному пользователю. §3.3, Appendix E

Наконец, Ouroboros пробует сделать рекурсивной уже обученную LLM. Часть слоёв удаляют, а общему блоку добавляют LoRA-поправки — изменения весов, заданные произведением небольших матриц. Контроллер меняет их коэффициенты в зависимости от состояния и номера прохода. Сами базисные матрицы фиксированы: их получают SVD-разложением усреднённых различий между удалёнными слоями и общим блоком.

В основном опыте с Qwen2.5-3B оставляют 17 из 36 слоёв. С качеством пока не всё сложилось. Тренировочный loss, то есть значение функции ошибки, снижается на 43,4% относительно сокращённой модели. Но на 12 отложенных текстах, которых не было в обучении, loss хуже того же 17-слойного baseline: 5,961 против 5,690. Авторы объясняют это замороженными выходными слоями, не привыкшими к изменённым состояниям общего блока. Это их гипотеза, а не установленная причина. И тем более тренировочное улучшение нельзя объявить восстановленным качеством исходной Qwen.

бюджеты

Диск — полный размер файла не указан. Только не спешите считать размер рецепта по 9,2 млн добавленных обучаемых параметров: по Table 2 нужны также около 1,8 млрд параметров замороженной основы и 7,3 млн параметров SVD-базисов.

Память — пик RAM/VRAM не указан.

Время — задержка инференса не указана; повторения блока и контроллер добавляют вычисления. §3–4, Table 2

Выборочное воспроизведение: что проверяли и что получили

До сих пор мы разбирали рецепты и результаты их авторов. А что получится, если взять доступный код и самим посмотреть на три бюджета? Для нескольких работ такую проверку провели на CPU: Xeon Gold 6230, 12 логических ядер и примерно 45 GiB RAM, без GPU. В расчётах использовали восемь потоков и FP32. FI-KAN обучали заново, Hyper-Compression проверяли на готовых весах авторов, а у MoR и Huginn измеряли исполнение готовых моделей. Обучение больших LLM и их качество на бенчмарках в этих CPU-опытах не воспроизводили.

В каждом опыте сравниваются два варианта; сравнивать скорость разных опытов смысла нет. В размер комплекта включали веса, настройки, нужный токенизатор, код опыта и файл с фиксированными версиями зависимостей — lock, но не установленные библиотеки и данные. Пик RAM — наибольшая RSS процесса, то есть занятая им физическая память, включая библиотеки и загрузку. Для файлов KB, MB и GB означают тысячи, миллионы и миллиарды байт; для RAM используем GiB — байт.

Время исполнения после прогрева и скорость — медианы повторных замеров; для FI-KAN взята медиана пяти seed-медиан. Batch 10 — десять изображений за проход. Decode здесь означает генерацию следующих токенов с готовым KV-cache, без начальной обработки входного текста. Время подготовки модели укажем отдельно, где оно измерено; это отдельные замеры, а не медианы прогретых проходов.

FI-KAN. Повторили небольшой опыт: KAN и гибридный FI-KAN, четыре функции, пять начальных значений генератора случайных чисел — seeds, по 500 эпох. Три строки получились близкими к Table 3. На пилообразной функции sawtooth гибрид по-прежнему выигрывает, но средняя ошибка — 0,00127 вместо опубликованных 0,00181. Поэтому воспроизведение частичное. Здесь есть и особенность авторского протокола: лучшую эпоху выбирали по test MSE, среднеквадратичной ошибке на тестовых точках. Отдельной валидацией это не является. Бюджеты относятся к сохранённым весам последней эпохи, которая не обязательно была лучшей.

бюджеты

Диск — для опыта polynomial комплект KAN → Hybrid FI-KAN занимает примерно 66,4 → 66,2 KB.

Память — пик RAM примерно 0,22 → 0,22 GiB.

Время — один вход после прогрева: 1,88 → 6,99 ms.

Hyper-Compression. Здесь сначала полностью восстановили веса, а дальше работал обычный MobileNetV3. На всех 10 000 тестовых изображениях CIFAR-10 исходная модель дала 74,42% точности, после сжатия — 73,91%. Это близко к авторским 74,41% и 73,93%. Опубликованные 3,61× сжатия точно повторить не удалось; причина расхождения пока не установлена.

бюджеты

Диск — файлы весов и настроек: 6,247 → 1,303 MB, примерно в 4,79 раза меньше; полный комплект с кодом и lock: 6,335 → 1,392 MB, в 4,55 раза меньше.

Память — пик RAM: 0,349 → 0,437 GiB.

Время — восстановление заняло 1,27 секунды. От старта скрипта до первого batch, включая импорты и подготовку данных: 2,94 → 7,06 секунды. Прогретый batch 10: 22,93 → 22,61 ms; диапазоны перекрываются, ускорения здесь не видно.

MoR. Проверили готовую пару: 32 слоя у обычной модели и 34 развёрнутых у MoR. Она отличается от авторской пары для теста скорости. Здесь использовали один запрос со 128 входными и 16 выходными токенами; качество на бенчмарках не проверяли. Авторский загрузчик при создании общих слоёв делает временные копии. Поэтому уменьшение памяти после загрузки ещё не гарантирует меньшего общего пика.

бюджеты

Диск — комплект обычной модели → MoR-4: 728,235 → 295,586 MB.

Память — стабильная RSS: 1,835 → 1,141 GiB, а общий пик RAM: 2,315 → 3,324 GiB. Рост пика связан с проверенной реализацией загрузки.

Время — прогретый decode: 12,06 → 11,07 токена/с.

Huginn. Сравнили 4 и 16 проходов общего блока с полным кешем. Вся модель при исполнении находилась в RAM. При 16 проходах отдельно проверили ограниченный KV-cache. Проверка короткая — один запрос, 16 входных и четыре выходных токена; о качестве рассуждений или длинном контексте по ней судить нельзя.

бюджеты

Диск — при 4 → 16 проходах комплект остаётся тем же: 15,648 GB.

Память — общий пик RAM с полным кешем примерно 18,03 GiB в обоих вариантах. При 16 проходах ограниченный KV-cache сократился со 136,4 до 40,1 MB, но общий пик загрузки остался около 18 GiB.

Время — прогретый decode при 4 → 16 проходах: 1,66 → 0,42 токена/с.

Сведём эти CPU-замеры в одну таблицу. В её колонке времени показано исполнение после прогрева; подготовка модели описана отдельно выше.

Опыт	Размер комплекта	Пик RAM, GiB	Исполнение на CPU после прогрева
KAN → Hybrid FI-KAN, polynomial	≈66,4 → 66,2 KB	≈0,22 → 0,22	Один вход: 1,88 → 6,99 ms
MobileNetV3 → Hyper-Compression	6,335 → 1,392 MB	0,349 → 0,437	Batch 10: 22,93 → 22,61 ms
Обычная модель → MoR-4	728,235 → 295,586 MB	2,315 → 3,324	Decode: 12,06 → 11,07 токена/с
Huginn: 4 → 16 проходов, полный кеш	15,648 → 15,648 GB	≈18,03 → 18,03	Decode: 1,66 → 0,42 токена/с

PocketLLM — наша адаптация подхода. А этот рецепт попробовали собрать на MacBook. Здесь мы проверяли сам принцип, а не воспроизводили авторскую реализацию и её результаты. Вместо Llama или Qwen взяли предобученную GPT-2 с 124,4 млн параметров; вычисления шли на Metal, Apple M2 Pro с 32 GiB общей памяти. Все 48 линейных матриц attention и FFN — 68,3% параметров модели — заменили индексами, кодовой книгой и обученным нейронным декодером. Остальные веса оставили в FP16 и тоже включили в размер комплекта. Перед исполнением все матрицы восстановили.

После сжатия качество предсказаний просело. Попробовали восстановить его коротким LoRA-дообучением: 64 шага на отдельном обучающем срезе, выбор сохранённой версии по validation. Чтобы не приписать сжатию обычный эффект дообучения, ту же процедуру провели для плотной модели. Обеим дали одинаковый бюджет шагов; лучшие версии выбирали по одной и той же валидации.

Вариант GPT-2	Полный комплект, MB	Perplexity на тестовом срезе ↓
Исходная FP16	253,8	39,90
После сжатия	127,0	49,83
Сжатие + короткое дообучение	131,7	37,40
Плотная модель + такое же дообучение	258,5	38,21

На нашем тесте сжатая модель после дообучения даже дала меньшую perplexity. Но это один seed и 8 192 токена из тестовой части WikiText-2, а не полный бенчмарк; общего улучшения качества от сжатия такой опыт не доказывает. Отдельная загрузка подтвердила, что исходные плотные веса комплекту больше не нужны. Получился рабочий рецепт хранения небольшой LLM, которому для исполнения по-прежнему нужно место под все восстановленные веса.

В следующих замерах сравниваем исходную GPT-2 в FP16 без дообучения и сжатую модель после короткого LoRA-дообучения. Матрицы LoRA хранятся в комплекте отдельно, но при загрузке поправка один раз сливается с восстановленными FP16-весами; дополнительных LoRA-операций во время decode нет.

бюджеты

Диск — исходная FP16 → сжатая после дообучения: 253,8 → 131,7 MB, почти вдвое меньше исходного FP16.

Память — тензоры Metal занимают около 261,5 MB в обоих вариантах; стабильная RSS процесса выросла примерно с 0,51 до 0,79 GiB. Это пересекающиеся счётчики, складывать их нельзя.

Время — загрузка до готовности модели: 0,67 → 4,35 секунды, без импорта библиотек и первого прохода. Медиана 32 шагов decode: 0,351 → 0,436 секунды; диапазоны семи повторов — 0,340–0,393 и 0,349–0,477 секунды соответственно. Повторная независимая загрузка того же сжатого комплекта дала 0,407 секунды. Decode измеряли с начальным контекстом 128 токенов: два повтора для прогрева и ещё семь для замера, с синхронизацией Metal. В наших замерах медиана времени decode у сжатой модели была выше; диапазоны отдельных повторов перекрываются.

Вот зачем нам понадобились три бюджета: меньший рецепт ещё не означает меньший расход памяти или более быстрый ответ. Числа CPU-опытов относятся к конкретным реализациям на одном сервере, с неочищенным файловым кешем и без контроля чужой нагрузки. Для остальных работ достаточного опыта пока нет; отсутствие замера не означает плохого результата.

Насколько близка LLM на слабом устройстве

Итак, рисунок ключа в некоторых случаях действительно работает. Веса умеют хранить как рецепт, блоки — восстанавливать прямо внутри вычисления, а одним набором параметров — пользоваться несколько раз. Но, как вы уже заметили, за похожими словами скрываются довольно разные достижения: килобайты на небольших сетях, фрактальные функции для аппроксимации, множество локальных кодов для LLM, спектральные коэффициенты и простые множители, общие слои для повторных проходов.

Но, как мы видим из рассмотренных подходов, до “чайника” пока еще очень далеко. В рассмотренных работах пока нет технологии, которая позволила бы гонять сложные нейронки в целом и LLM в частности слабом устройстве. Оптимизировать размер “холодной” модели мало - нужно еще что-то решить с памятью и вычислительной сложностью. Даже если ждать результата вычислений мы согласны долго, промежуточные данные придётся где-то хранить или заново вычислять, что накладывает, на мой взгляд, наболее серьезные на данный момент ограничения.

Мне кажется, направление от несколько печальной оценки, приведенной выше, не становится менее интересным. Существует множество направлений, приближающих желанный результат “карманного ИИ”, и рано или поздно эта цель будет достигнута.