Зачем нужен многоуровневый offload в MoE-моделях
Архитектура Mixture of Experts решает проблему масштабирования нейросетей через разделение модели на множество независимых подсетей-экспертов. На каждом токене активируется лишь часть из них, обычно 1-4 эксперта из 8, 16 или 64. Полный набор весов при этом остаётся в памяти, и здесь возникает узкое место: суммарный размер всех экспертов многократно превышает доступную VRAM потребительских GPU.
Модель DeepSeek V2 Lite с 16 экспертами и 2.4B активных параметров весит около 16 ГБ в FP16. Mixtral 8x7B занимает порядка 47 ГБ. Запустить их на карте с 8-12 ГБ VRAM без компромиссов невозможно. Существующие флаги --cpu-moe и --n-cpu-moe в llama.cpp частично решают проблему: неактивные эксперты выгружаются в оперативную память и подгружаются в GPU по требованию роутера. Но что делать, когда и RAM не хватает?
Ответом может стать трехуровневая иерархия offload: GPU (быстрый инференс) → CPU (средняя задержка) → диск (максимальная экономия памяти). Предлагаемые флаги --disk-moe и --n-disk-moe расширяют логику выгрузки на SSD или HDD. Цель - запуск моделей, чей полный размер превышает совокупный объём VRAM и RAM. Плата за это - радикальное падение скорости. Насколько именно - разберём на цифрах.
Как работают существующие флаги --cpu-moe и --n-cpu-moe
В llama.cpp и ряде форков реализован механизм выборочной выгрузки экспертов MoE в системную память. Флаг --cpu-moe указывает движку хранить указанное количество экспертов в RAM, а не в VRAM. --n-cpu-moe задаёт конкретное число экспертов для оффлоада. Роутер модели по-прежнему работает на GPU; когда он выбирает эксперта, находящегося в CPU, веса подгружаются через PCIe-шину.
Пропускная способность PCIe 4.0 x16 составляет около 32 ГБ/с, что на порядок ниже пропускной способности VRAM (у RTX 4090 - 1 ТБ/с). Каждая подгрузка эксперта размером 1.5 ГБ добавляет примерно 47 мс задержки только на передачу данных. Для сравнения: тот же эксперт из VRAM загружается за 1.5 мс. Разница в 30 раз ощутима при генерации каждого токена, если эксперты меняются часто.
Пример конфигурации с --cpu-moe
Рассмотрим запуск Mixtral 8x7B на системе с 12 ГБ VRAM и 32 ГБ RAM. Каждый эксперт весит около 5.9 ГБ в FP16. Конфигурация:
./llama-cli \
-m mixtral-8x7b.Q4_K_M.gguf \
-ngl 12 \
--cpu-moe 6 \
--n-cpu-moe 6Два эксперта остаются на GPU, шесть выгружены в RAM. При активации двух экспертов на токен вероятность обращения к CPU-эксперту составляет 75%. Средняя задержка на токен вырастает с ~20 мс до ~55 мс, скорость генерации падает с 18-22 t/s до 6-8 t/s. Для пакетной обработки это приемлемо, для чата - на грани комфорта.
Детальный разбор стратегий offload и тесты на реальном железе мы публиковали в статье про запуск MoE-модели весом 204 ГБ на одной видеокарте. Там же описана комбинация unified memory и regex-фильтров для экспертов.
Предлагаемые флаги --disk-moe и --n-disk-moe: техническая реализуемость
Идея дисковой выгрузки не утопична. Она продолжает ту же логику, что и CPU offload: веса экспертов лежат на медленном носителе, подгружаются в GPU при активации. Техническая реализация может идти двумя путями. Первый - через CPU как промежуточное звено: диск → RAM → GPU, с двойной буферизацией. Второй - GPU Direct Storage (GDS) от NVIDIA, позволяющий GPU читать данные с NVMe-диска напрямую, минуя CPU и системную память.
GDS сокращает накладные расходы на копирование и снижает загрузку CPU, но доступен только на профессиональных картах (A100, H100) под Linux. Для потребительских GPU реализация почти наверняка пойдёт через CPU-буфер. Это означает двойную пересылку: диск → RAM, затем RAM → VRAM.
Оценка задержек при дисковой выгрузке
Ключевой вопрос - насколько медленно. Сравним задержки доступа к весам эксперта размером 1.5 ГБ с разных уровней хранения:
| Уровень хранения | Пропускная способность | Задержка загрузки 1.5 ГБ |
|---|---|---|
| VRAM (RTX 4090) | ~1 ТБ/с | ~1.5 мс |
| RAM DDR5-5600 (через PCIe 4.0 x16) | ~32 ГБ/с | ~47 мс |
| NVMe SSD PCIe 4.0 (Samsung 990 Pro) | ~7 ГБ/с чтение | ~214 мс |
| SATA SSD | ~550 МБ/с | ~2 727 мс (2.7 с) |
| HDD 7200 RPM | ~160 МБ/с | ~9 375 мс (9.4 с) |
Цифры отрезвляют. Даже быстрый NVMe добавляет 214 мс на загрузку одного эксперта. Если модель активирует двух экспертов на токен и оба лежат на диске, задержка первого токена вырастает на 400+ мс. При генерации каждого следующего токена роутер может выбрать других экспертов - и каждый такой переход обходится в сотни миллисекунд.
Дисковая выгрузка имеет смысл только при редкой смене экспертов. Например, в моделях с крупными экспертами и стабильным роутингом, где один и тот же эксперт активируется на протяжении десятков токенов подряд. Исследование, которое мы разбирали в статье про предсказание загрузки экспертов MoE, показывает: точность предсказания следующего эксперта достигает 78%, что открывает путь к предзагрузке и маскировке задержек.
Износ дисков: мифы и реальность
Распространённое опасение: инференс с дисковой выгрузкой убьёт SSD за считанные недели. Проверим на цифрах. Современный NVMe-накопитель объёмом 1 ТБ имеет TBW (Total Bytes Written) около 600 ТБ. При инференсе мы преимущественно читаем данные, запись минимальна - только кеш и логи. Чтение не расходует ресурс TBW.
Возьмём сценарий: модель с 8 экспертами по 5 ГБ, 4 эксперта на диске. 1000 запросов в день, на каждый запрос - 500 токенов генерации, смена эксперта каждые 10 токенов. Это 50 подгрузок эксперта на запрос, 50 000 подгрузок в день. Объём чтения: 50 000 × 5 ГБ = 250 ТБ в день. Такой поток данных находится в пределах спецификаций NVMe-дисков на чтение (обычно 0.3-1 DWPD - Drive Writes Per Day, что для 1 ТБ диска означает 300-1000 ТБ операций в день суммарно).
HDD в этом сценарии неприемлем не столько из-за износа, сколько из-за latency в 9+ секунд на загрузку эксперта. Единственный реалистичный вариант - NVMe-диск с прямым доступом или быстрым буфером в RAM.
Практические сценарии: когда --disk-moe оправдан
Дисковая выгрузка не для интерактивных чат-ботов. Её ниша - офлайн-обработка, исследования и пакетный инференс, где задержка некритична.
Сценарий 1: аналитика документов. Запуск модели 16x7B на машине с 8 ГБ VRAM и 16 ГБ RAM для анализа корпуса текстов. Задача выполняется раз в час, время ответа до 30 секунд приемлемо. Два эксперта на GPU, два в CPU, двенадцать на NVMe-диске. Полный размер модели ~112 ГБ эффективно умещается в конфигурацию с 24 ГБ быстрой памяти.
Сценарий 2: исследовательские эксперименты. Тестирование новых архитектур MoE с десятками экспертов без покупки дорогого железа. Дисковая выгрузка позволяет быстро прототипировать, пусть и с низкой скоростью.
Сценарий 3: пакетный инференс. Генерация эмбеддингов или суммаризация тысяч документов. Запустили батч, оставили на ночь - задержка не важна.
Конфигурация для домашнего сервера с GPU 8 ГБ
Практический пример запуска Mixtral 8x7B (Q4_K_M, ~26 ГБ) на системе с RTX 3070 8 ГБ, 32 ГБ RAM и NVMe SSD:
# Гипотетическая конфигурация с --disk-moe
./llama-cli \
-m mixtral-8x7b.Q4_K_M.gguf \
-ngl 12 \
--cpu-moe 2 \
--disk-moe 4 \
--n-disk-moe 4Два эксперта на GPU, два в RAM, четыре на диске. Ожидаемая скорость генерации: 1-3 токена в секунду при частой смене экспертов, до 8-10 t/s при стабильном роутинге. Задержка первого токена: 3-8 секунд. Для периодических задач - рабочий вариант.
Подробный разбор запуска больших MoE-моделей на оборудовании с ограниченной памятью мы делали в статье про стриминг-инференс для MoE. Там же рассмотрены альтернативные подходы через TensorRT-LLM и DeepSpeed.
Альтернативы трехуровневому offload: сравнение подходов
Дисковая выгрузка - крайняя мера. Перед её применением стоит исчерпать другие методы экономии памяти:
- Квантизация. Снижение точности весов до 4-bit (Q4_K_M) уменьшает размер модели в 3-4 раза. Mixtral 8x7B с 47 ГБ в FP16 сжимается до ~14 ГБ. Потери качества минимальны, скорость инференса на GPU растёт. Квантизация совместима с CPU offload и даёт больший выигрыш, чем дисковая выгрузка.
- Дистилляция. Обучение компактной модели на выходе большой MoE. DeepSeek R1 Distill - примеры дистилляции 671B MoE в плотные модели 7B-70B. Радикально снижает требования к памяти ценой ресурсов на обучение.
- Sparse inference. Пропуск неактивных экспертов без загрузки их весов. FlashInfer и vLLM реализуют разреженные вычисления для MoE, сокращая пиковое потребление VRAM.
- Совместное использование экспертов. Архитектурные трюки с общими слоями между экспертами, как в DeepSeek V3 с shared experts. Уменьшают общий размер модели без потери качества.
Сравнение по ключевым критериям:
| Метод | Экономия памяти | Потери качества | Сложность | Скорость |
|---|---|---|---|---|
| Квантизация 4-bit | 70-75% | 1-3% | Низкая | Высокая |
| Дистилляция | 80-95% | 5-15% | Высокая | Высокая |
| CPU offload | Зависит от RAM | 0% | Низкая | Средняя |
| Дисковый offload | Максимальная | 0% | Средняя | Низкая |
Дисковая выгрузка выигрывает только по критерию сохранения точности - веса не модифицируются. Во всём остальном квантизация и дистилляция предпочтительнее для практических задач.
Перспективы реализации в популярных фреймворках
На август 2026 года флаги --disk-moe и --n-disk-moe не реализованы в мейнстримных инференс-движках. В репозитории llama.cpp нет открытых pull request с такой функциональностью, но обсуждения на GitHub и в сообществе r/LocalLLaMA указывают на растущий интерес.
Технически интеграция в llama.cpp наиболее вероятна, поскольку архитектура движка уже поддерживает многоуровневый offload через бэкенды GPU, CPU и гипотетический disk. Добавление нового бэкенда с mmap-доступом к файлам весов на диске - задача средней сложности. Основной вызов - эффективное управление буфером и асинхронная предзагрузка.
В vLLM ситуация сложнее: движок заточен под high-throughput инференс на серверном железе, и дисковая выгрузка противоречит его философии. Однако плагин vLLM-Moet, который мы разбирали в статье про запуск DeepSeek V4 Flash на двух RTX 4090, демонстрирует, что сообщество активно экспериментирует с нестандартными конфигурациями памяти.
Прогноз: пилотные реализации появятся в форках llama.cpp в течение 6-12 месяцев. В мейнстрим функция войдёт при условии, что разработчики увидят достаточное количество успешных кейсов и решат проблему асинхронной предзагрузки, аналогичную описанной в исследовании про предсказание загрузки экспертов.
Выводы: стоит ли ждать --disk-moe?
Дисковая выгрузка экспертов технически реализуема и способна радикально снизить требования к памяти для запуска больших MoE-моделей. Трехуровневая иерархия GPU → CPU → диск позволяет запустить модель, чей полный размер превышает совокупный объём VRAM и RAM, без потери точности весов.
Плата высока: задержка загрузки эксперта с NVMe-диска в 100+ раз превышает доступ к VRAM. Для интерактивных сценариев это неприемлемо. Для пакетной обработки, исследований и периодических задач - оправданный компромисс. Износ SSD при типичных нагрузках инференса остаётся в пределах спецификаций производителей.
Практическая рекомендация: в 2026 году для продакшена используйте квантизацию и CPU offload. Держите в GPU столько экспертов, сколько позволяет VRAM, остальное - в RAM. Если памяти всё равно не хватает, экспериментируйте с самописными решениями на базе llama.cpp с mmap-доступом к весам на диске. Следите за форками и обсуждениями - спрос на запуск больших моделей на обычном железе только растёт, и появление --disk-moe в мейнстриме - вопрос времени.