Запуск MoE моделей на SSD: как GLM-5 работает с 1/3 весов на диске благодаря кэшированию

Сто миллиардов параметров и скрипящий жесткий диск

Вот вам классическая дилемма 2026 года. Хотите запустить GLM-5 MoE - одну из самых умных моделей от Zhipu AI. Параметров там под 400 миллиардов. А у вас на сервере - 96 ГБ оперативки. Или, что еще хуже, на домашнем ПК - 64 ГБ.

Обычная плотная модель такого размера даже не задумываясь сожрет всю вашу память и попросит еще. Но GLM-5 - не обычная. Это Mixture of Experts, или MoE. И эта архитектура дает вам единственный шанс заставить ее работать на ограниченном железе. Правда, с одной оговоркой: вам понадобится быстрый SSD.

Зачем хранить в памяти то, что вам не нужно?

Секрет MoE в том, что модель состоит из множества "экспертов" - маленьких нейросетей. Для каждого токена входящего текста активируется лишь несколько из них, обычно 2-4. Остальные 100+ экспертов в этот момент просто спят.

Вот и возникает очевидная мысль: а зачем держать в дорогой оперативной памяти все веса всех экспертов, если в каждый момент времени работает лишь малая часть? Именно эту мысль и реализовали в GLM-5. Алгоритм прост до гениальности: держим в RAM только те эксперты, которые работают прямо сейчас, плюс кэш наиболее популярных. Все остальные - на SSD. Когда понадобится новый эксперт, грузим его с диска в RAM, вытесняя того, кто дольше всех не использовался.

Под капотом: как работает кэширование экспертов

Технически это реализовано в библиотеке transformers от Hugging Face (версия 4.45.0 на момент написания) с помощью специального загрузчика моделей от Zhipu AI. Когда вы инициализируете модель с флагом offload_folder, происходит следующее:

• Ядро модели (токенайзер, эмбеддинги, выходные слои) загружается в оперативную память полностью. Это обязательная часть.
• Все эксперты MoE-слоев загружаются... на SSD. В виде отдельного файла кэша.
• Создается LRU-кэш (Least Recently Used) в оперативной памяти. Его размер вы задаете вручную.
• Во время инференса, когда для токена требуется конкретный эксперт, система сначала проверяет, есть ли он в RAM-кэше. Если нет - загружает его с SSD, вытесняя из кэша самого "старое" ядро.

Самое интересное - паттерн доступа. В отличие от игр, где подгрузка текстур может вызывать лаги, в MoE-моделях активация экспертов следует довольно предсказуемым шаблонам. Часть экспертов (например, те, что отвечают за общие понятия) используются постоянно и остаются в кэше всегда. Другие (узкоспециализированные) подгружаются редко. После нескольких минут работы кэш "прогревается", и количество обращений к SSD падает в разы.

Пошагово: заставляем GLM-5 жить на SSD

1 Подготовка SSD и установка ПО

Первое - проверьте свободное место на SSD. Для GLM-5-400B вам понадобится около 300-400 ГБ. Не для весов модели (они занимают меньше), а для комфортной работы системы и самого кэша.

# Проверяем свободное место
df -h /path/to/your/ssd
# Устанавливаем необходимое ПО (актуально на 11.04.2026)
pip install torch==2.3.0 transformers==4.45.0 accelerate
# Плюс специальная библиотека от Zhipu для работы с их MoE
pip install glm-utils==1.2.0

2 Загрузка модели с правильными флагами

Вот тут большинство ошибается впервые. Нельзя просто загрузить модель через from_pretrained. Нужно явно указать, что мы хотим использовать оффлоад.

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

# Указываем путь на SSD, куда будут сброшены веса
ssd_path = "/mnt/nvme_ssd/glm5_cache"

model_name = "THUDM/glm-5-400b-moe"

tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)

# Ключевой момент: используем device_map="auto" и offload_folder
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    trust_remote_code=True,
    device_map="auto",
    offload_folder=ssd_path,  # Вот этот флаг включает механизм
    max_memory={0: "90GiB", "cpu": "200GiB"},  # Распределяем память
    torch_dtype=torch.bfloat16  # Bfloat16 экономит память и работает на современных GPU
)

Система автоматически определит, какие слои поместить в GPU (если он есть), какие в RAM, а какие отправить на SSD. Но автоматика не идеальна.

3 Тонкая настройка кэша

По умолчанию размер LRU-кэша в оперативной памяти задан консервативно. Но его можно и нужно увеличить, если у вас есть свободная RAM. Делается это через переменные окружения или прямо в коде.

import os

# Увеличиваем размер кэша экспертов в оперативке (по умолчанию часто 20% от весов модели)
os.environ["GLM_MOE_RAM_CACHE_SIZE"] = "80GiB"  # Например, 80 гигабайт

# Перезагружаем модель после установки переменной
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    trust_remote_code=True,
    device_map="auto",
    offload_folder=ssd_path,
    max_memory={0: "90GiB", "cpu": "200GiB"},
    torch_dtype=torch.bfloat16
)

Чем больше RAM-кэш, тем реже обращение к SSD и тем выше итоговая скорость генерации. Но есть предел - если сделать кэш размером со все веса модели, вы просто загрузите всю модель в память, и смысл технологии теряется. Ищите баланс.

4 Первый запуск и бенчмарк

Первый запуск будет долгим. Система должна скачать модель (если ее нет локально) и создать кэш на SSD. Не пугайтесь.

prompt = "Объясни, как работает кэширование в MoE-моделях, в трех предложениях."
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)

# Первые несколько токенов будут генерироваться медленно - идет прогрев кэша
with torch.no_grad():
    outputs = model.generate(
        **inputs,
        max_new_tokens=200,
        do_sample=True,
        temperature=0.7
    )

print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Замерьте скорость генерации первых 50 токенов и последующих 150. Разница покажет, насколько эффективно работает кэш. В идеале после прогрева скорость должна вырасти в 3-5 раз.

Типичные грабли, на которые наступают все

• Медленный SATA SSD вместо NVMe. Пропускная способность SATA III - 600 МБ/с. NVMe Gen4 - 7000 МБ/с. Разница в 10+ раз. На SATA SSD инференс будет ползти как улитка. Если у вас только SATA, лучше рассмотрите другие методы, например, агрессивное квантование.
• Забыли про trust_remote_code=True. GLM-5 использует кастомные слои. Без этого флага ничего не загрузится.
• Пытаются запустить на Windows без WSL2. Прямая работа с файловой системой и управление памятью в Windows часто приводят к ошибкам. Используйте Linux или WSL2. Если очень надо Windows - готовьтесь к долгой отладке.
• Не хватает места на SSD во время работы. Система создает временные файлы при подгрузке экспертов. Убедитесь, что свободно минимум 20% от объема SSD.
• Смешивают эту технику с другими методами экономии памяти. Например, пытаются одновременно использовать 8-битное квантование (load_in_8bit) и оффлоад на SSD. Библиотеки на это не рассчитаны, получите странные ошибки или падение производительности. Выберите что-то одно. Для сравнения методов смотрите наш гайд по homelab-оптимизации.

А что там с другими моделями?

Технология не уникальна для GLM-5. Аналогичный подход с разной степенью зрелости реализован в:

• Qwen3.5 MoE - есть экспериментальная поддержка в ветке dev репозитория. Работает похоже, но документация скудная.
• Mixtral 8x22B - через библиотеку llama.cpp с флагом --flash-attn и указанием путей для оффлоада. Детали в нашей статье про llama.cpp и SSD.
• DeepSeek MoE - официально не поддерживается, но энтузиасты патчили transformers для работы. Готовых решений нет, придется копать код.

Будет ли это работать на моем железе? Цифры

Привожу реальные цифры с тестового стенда на 11.04.2026:

Видна разница между NVMe и SATA? На SATA SSD после прогрева скорость в 3 раза ниже, чем на NVMe. Это и есть цена экономии.

Что дальше? PCIe 6.0 и RAM-диски

Технология не стоит на месте. К концу 2026 года ожидается массовый переход на PCIe 6.0, что удвоит пропускную способность NVMe SSD. А это значит, что latency при подгрузке экспертов сократится еще сильнее, приблизив SSD-оффлоад по скорости к работе целиком из RAM.

Но есть и более экзотический путь. Если у вас много оперативной памяти (допустим, 512 ГБ), но не хватает для полной загрузки модели (800+ ГБ), создайте RAM-диск размером 400 ГБ и укажите путь к нему в offload_folder. Эксперты будут подгружаться с RAM-диска, что в 100-1000 раз быстрее SSD. Звучит как извращение, но на практике для инференса с непредсказуемым паттерном запросов это может дать прирост скорости в 2-3 раза по сравнению с NVMe. Правда, после перезагрузки сервера кэш придется строить заново.

Главный вывод прост: MoE-архитектура - это не просто способ создать модель больше. Это фундаментально другой подход к управлению ресурсами. Он позволяет вам выбирать между скоростью и объемом памяти. Хотите быстрее - купите больше RAM. Хотите дешевле - купите быстрый SSD. GLM-5 с ее кэшированием просто сделала этот выбор очевидным и доступным для любого, у кого есть терпение настроить пару десятков строчек кода.

Подписаться на канал