MoLE: Когда эксперты живут не в памяти, а в lookup-таблицах

Представь: запускаешь 120B MoE-модель на ноутбуке с 32 ГБ RAM. В теории это возможно с offload'ом весов на диск. На практике — мучительные паузы по 300-500 мс каждый раз, когда роутер выбирает нового эксперта. Веса читаются с SSD, GPU простаивает, пользователь нервно стучит пальцами по столу.

Проблема гибридного инференса (RAM + Disk) — не в объёме памяти. Современные NVMe справляются с терабайтами. Проблема в латентности. Каждый переход к новому эксперту — это физическое чтение с диска, которое убивает перцептивную скорость генерации.

MoLE (Mixture of Lookup Experts) решает это кардинально. Не загружает экспертов по требованию. Не кэширует их в RAM. Вместо этого — предварительно вычисляет и хранит готовые ответы экспертов для всех возможных входов.

Что не так с классическим MoE на диске

Сначала разберёмся, почему существующие решения работают медленно. Возьмём классическую схему, которую используют в CPU-only MoE или гибридных запусках:

Даже с NVMe Gen5 задержка чтения 100-200 МБ весов составляет 30-80 мс. Умножь на 2-3 активных эксперта на токен, на 20-30 токенов в секунду — получаешь постоянные микрозадержки, которые складываются в секунды ожидания.

Как работает MoLE: предсказание вместо вычисления

Основная идея MoLE проста до гениальности. Если эксперты — это чёрные ящики, которые преобразуют входные эмбеддинги в выходные, почему бы не предвычислить все возможные выходы заранее?

Звучит безумно. Для 1024-мерного эмбеддинга количество возможных входов астрономическое. Но на практике эмбеддинги живут в ограниченном подпространстве. И даже если не все — можно использовать квантование.

Вот техническая схема:

1. Фаза прекомпиляции: прогоняем экспертов через репрезентативный датасет, собираем пары (эмбеддинг → выход эксперта)
2. Кластеризация: используем product quantization или подобные методы для группировки похожих эмбеддингов
3. Построение таблиц: для каждого кластера вычисляем усреднённый выход каждого эксперта
4. Инференс: определяем кластер входного эмбеддинга, берём готовые значения из таблицы

Задержка? Фактически нулевая. Вместо чтения миллионов параметров с диска и их умножения на матрицы — одна операция поиска в памяти.

Сравнение с Deepseek Engram: два подхода к одной проблеме

Deepseek Engram, о котором мы писали в контексте SEDAC v5, решает проблему иначе. Это не новая архитектура, а система кэширования.

Engram запоминает, какие эксперты использовались для похожих контекстов, и предзагружает их в RAM. Умно? Да. Но есть нюансы:

• Engram требует обучения кэша на реальных данных
• Эффективность зависит от повторяемости паттернов
• При cache miss задержки те же, что и в классической схеме
• Требует дополнительной RAM для хранения кэша

MoLE идёт дальше. Он вообще не хранит веса экспертов в оперативке. Только lookup-таблицы, которые на порядок компактнее.

Цена скорости: где MoLE проигрывает

Ни одна технология не идеальна. Особенно революционная. У MoLE есть свои trade-offs, о которых молчат в анонсах:

Точность против скорости

Lookup-таблицы — это аппроксимация. Усреднённый выход для кластера никогда не будет точным, как вычисление на полных весах. Разработчики MoLE заявляют о 98-99% точности на большинстве задач, но для математических рассуждений или кодирования падение может быть заметнее.

Размер таблиц растёт экспоненциально

Хотите увеличить разрешение квантования для большей точности? Каждый дополнительный бит удваивает размер таблиц. 2^24 кластеров при 8 экспертах и 4096-мерном выходе — это уже десятки гигабайт.

Статичность экспертов

MoLE плохо сочетается с адаптивными методами вроде Adaptive-K Routing. Если эксперт динамически меняет своё поведение на основе контекста, его нельзя предвычислить раз и навсегда.

Практическое применение: для кого MoLE станет спасением

Представь себя в трёх сценариях:

1. Ноутбук с ограниченной RAM

У тебя 16 ГБ RAM и быстрый NVMe. Классические 30B MoE-модели тормозят из-за постоянного своппинга. MoLE позволяет запускать их с перцептивной скоростью, сравнимой с нативной загрузкой в память.

2. Мобильные и edge-устройства

Смартфоны, IoT-устройства, встроенные системы. Здесь каждый милливатт на счету. MoLE заменяет энергоёмкие матричные умножения на поиск в таблице, что снижает энергопотребление в 3-5 раз.

3. Масштабирование на кластерах

Вместо распределения экспертов по разным узлам (со всеми проблемами сетевой задержки) можно хранить компактные таблицы на каждом узле. Это меняет экономику inference-as-a-service.

Техническая реализация: как это выглядит в коде

Хотя полные реализации MoLE ещё не появились в открытом доступе (ожидаем релиз в Q1 2026), архитектура понятна:

# Псевдокод MoLE слоя
class MoLELayer:
    def __init__(self, num_experts, hidden_dim, num_clusters=2**20):
        self.num_experts = num_experts
        self.hidden_dim = hidden_dim
        self.num_clusters = num_clusters
        
        # Lookup-таблицы: [num_clusters, num_experts, hidden_dim]
        self.lookup_tables = nn.Parameter(
            torch.zeros(num_clusters, num_experts, hidden_dim)
        )
        
        # Квантователь для входных эмбеддингов
        self.quantizer = ProductQuantizer(
            num_subvectors=8,
            num_clusters_per_subvector=2**8  # 256
        )
        
        # Роутер (такой же как в классическом MoE)
        self.router = nn.Linear(hidden_dim, num_experts)
    
    def forward(self, x):
        # 1. Роутинг: выбираем топ-k экспертов
        router_logits = self.router(x)
        weights, expert_indices = torch.topk(router_logits, k=2)
        weights = torch.softmax(weights, dim=-1)
        
        # 2. Квантование входного эмбеддинга
        cluster_ids = self.quantizer.encode(x)  # [batch_size]
        
        # 3. Lookup вместо вычисления
        expert_outputs = self.lookup_tables[cluster_ids]  # [batch_size, num_experts, hidden_dim]
        
        # 4. Собираем выход только для выбранных экспертов
        selected_outputs = expert_outputs[
            torch.arange(x.size(0)).unsqueeze(1),
            expert_indices
        ]  # [batch_size, k, hidden_dim]
        
        # 5. Взвешенная сумма
        output = torch.sum(selected_outputs * weights.unsqueeze(-1), dim=1)
        
        return output

Ключевой момент — self.lookup_tables. Это не веса экспертов, а уже вычисленные выходы. Обучение такой системы происходит в два этапа: сначала классический MoE, затем дистилляция в lookup-таблицы.

Интеграция с существующими системами

MoLE — не замена всей архитектуре. Это drop-in замена MoE слоёв. Теоретически можно взять любую существующую MoE-модель (Mixtral, Qwen, OLMoE) и конвертировать её в MoLE-версию.

Процесс выглядит так:

1. Загружаем предобученную MoE-модель
2. Прокачиваем эксперты на разнообразном датасете, собирая пары (эмбеддинг → выход)
3. Обучаем квантоватор на собранных эмбеддингах
4. Заполняем lookup-таблицы усреднёнными выходами для каждого кластера
5. Заменяем оригинальные MoE слои на MoLE версии

Для существующих проектов вроде llama.cpp с поддержкой EXAONE MoE потребуются модификации, но они минимальны. Основная логика инференса остаётся прежней.

Ограничения и будущее развитие

MoLE — не серебряная пуля. Есть задачи, где он не подойдёт:

• Динамическая маршрутизация: если эксперт должен адаптироваться к конкретному контексту (как в Multiplex Thinking), lookup-таблицы не помогут
• Очень большие модели: для 1T+ параметров размер таблиц может превысить размер оригинальных весов
• Частое обновление: если эксперты постоянно дообучаются, перестраивать таблицы дорого

Но развитие идёт в интересных направлениях:

Уже есть наработки по сжатию таблиц через tensor train decomposition и обучению квантоватора совместно с экспертами. Это может снизить размер таблиц в 4-8 раз без потери точности.

Что это значит для тебя прямо сейчас

Если ты работаешь с локальным инференсом больших моделей, запомни три вещи:

1. MoLE появится в llama.cpp и других популярных инференс-движках к середине 2026
2. Готовь датасеты для прекомпиляции — разнообразные, репрезентативные
3. Не спеши выбрасывать старые GPU — MoLE отлично работает на CPU с быстрым SSD

Особенно интересно это для энтузиастов, которые экспериментируют с нестандартными GPU-конфигурациями или бюджетным железом.

Мой прогноз: к концу 2026 каждая вторая локально запускаемая MoE-модель будет использовать MoLE или подобную технологию. Потому что когда выбор между «медленно, но точно» и «быстро, но с погрешностью 1%», большинство выберет скорость.

Особенно если эта скорость позволяет запускать на ноутбуке то, что раньше требовало сервер с четырьмя RTX 4090.