Архитектура MoE и проблема памяти

Запуск больших языковых моделей (LLM) на локальном железе часто упирается в ограничения памяти. Ситуация меняется с появлением архитектуры Mixture-of-Experts (MoE), как в модели Kimi K3 от Moonshot. У этой модели 2,8 триллиона параметров, но благодаря структуре «смеси экспертов» при вычислении каждого токена активируются лишь 16 блоков из 896 на слое. Фактически в расчетах участвует около 104 миллиардов параметров, что значительно снижает вычислительную нагрузку, но не решает проблему объема весов, которые необходимо где-то хранить.

Веса Kimi K3 занимают около 1,56 ТБ. Модель разделена на две части: «спина» (spine) — общие слои, работающие на каждом токене (около 114 ГБ в bf16), и маршрутизируемые эксперты, которые составляют основную массу данных (1,45 ТБ). Проблема локального запуска заключается не в нехватке вычислительной мощности, а в организации иерархии хранения и доставки нужных экспертов в память.

Методы локального запуска

Существует три основных подхода к запуску тяжелых моделей на ограниченном железе. Первый — сжатие (квантование). Команда Unsloth представила калиброванные динамические кванты для K3: однобитная сборка весит 594 ГБ и сохраняет около 78,9% качества восьмибитного эталона. Второй метод — оффлоад экспертов, когда часть весов остается в системной памяти (RAM), а часть обрабатывается на видеокарте (VRAM). Это реализуется через флаги в llama.cpp, позволяющие переопределять размещение тензоров.

Третий, самый радикальный метод — стриминг. Проект Deltafin демонстрирует возможность запуска Kimi K3 на MacBook с M1 Max и 64 ГБ памяти. В этом сценарии «спина» модели загружается в память, а 82 432 экспертов подтягиваются с NVMe-накопителя или по сети по мере необходимости через range-запросы.

Оптимизация стриминга в Deltafin

Для достижения скорости в один токен в минуту разработчик Deltafin применил ряд инженерных решений. Для ускорения чтения используется склейка тензоров (один запрос на эксперта), кэширование сырых байт через mmap и двойная буферизация загрузки слоев. Также применяется префетч: так как соседние токены используют около 40% тех же экспертов, система заранее подгружает нужные данные.

Дополнительно используется оптимизация на уровне вычислений: распаковка формата MXFP4 и умножение происходят в один проход через табличный поиск (fused gemv на NEON). Это позволяет избежать медленной связки этапов распаковки и умножения, сохраняя при этом точность вычислений.