Когда RAM не хватает: заставляем llama.cpp работать с контекстом 1M+ через SSD Offload

Проблема: ваш контекст не помещается в RAM, а покупать 512 ГБ оперативки - глупо

Вы пытаетесь запустить модель с контекстом 128k. Или 256k. Или, что там у вас, 512k. llama.cpp загружается, начинает обработку первого токена... и вылетает с OOM. Знакомо?

Проблема в KV-кэше. Эта штука растет линейно с размером контекста. Для 70B модели и контекста 128k нужно примерно 8-12 ГБ только под кэш. Для 256k - уже 16-24 ГБ. Для 512k - забудьте про обычные серверы.

Решение: выгружаем горячий хлам на холодный SSD

Идея проста как молоток: не все части KV-кэша одинаково полезны в каждый момент времени. Текущий блок внимания работает с последними N токенами, а старые... лежат мертвым грузом. Зачем держать их в дорогой RAM?

В конце эпохи квадратичной сложности я уже писал, как модели научились жульничать. Теперь научимся мы.

llama.cpp с версии b3234 (релиз от января 2026) поддерживает экспериментальный SSD offload. Не через костыли, а нативно. Работает так:

1. Загружаем модель как обычно (частично в VRAM, частично в RAM)
2. Выделяем буфер KV-кэша в RAM + swap-файл на SSD
3. Алгоритм сам решает, что оставить в памяти, а что сбросить на диск
4. При необходимости - подгружает обратно

Что нужно для работы: железо, софт и нервные клетки

Без этого не получится:

• llama.cpp версии НЕ РАНЬШЕ b3234 (январь 2026)
• SSD с прямой записью (не QLC, лучше TLC или MLC)
• Минимум 64 ГБ свободного места на диске
• Linux (на Windows работает, но глючит с правами доступа)
• Компилятор с поддержкой C++20

Шаг 1: собираем llama.cpp с поддержкой SSD offload

Первая ловушка: не все сборки поддерживают эту фичу. Особенно если вы качаете бинарники с GitHub Releases.

1 Собираем из исходников (обязательно!)

# Клонируем репу (обязательно main ветку на 10.02.2026)
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

# Собираем с поддержкой CUDA и SSD offload
make LLAMA_CUDA=1 LLAMA_SSD=1 -j$(nproc)

# Проверяем, что собралось
./main --help | grep -i ssd
# Должна быть строчка про --ssd-cache

Если не видите --ssd-cache в help - что-то пошло не так. Возможно, у вас старая версия.

Шаг 2: готовим SSD - не любой диск сгодится

Здесь большинство обламывается. Берут старый SATA SSD 2018 года и удивляются, почему скорость 2 токена в секунду.

Что нужно:

• NVMe PCIe 4.0 или 5.0 - минимум. Идеально - два диска в RAID 0
• DRAM кэш на диске - обязательно. Без него производительность рухнет
• Свободное место - для контекста 1M токенов нужно ~60-80 ГБ
• Файловая система - ext4 с noatime или XFS. NTFS на Windows

Проверяем диск:

# Для Linux
fio --name=random-write --ioengine=libaio --iodepth=32 \
--rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=4 \
--runtime=60 --group_reporting

# Должно быть > 200k IOPS для random write
# И > 3 GB/s для sequential

Если у вас меньше - либо покупайте новый диск, либо готовьтесь к тормозам. Это не шутка.

Шаг 3: конфигурируем запуск - здесь все тонкости

Самый важный этап. Неправильные параметры сведут на нет все преимущества.

2 Базовый запуск с SSD offload

./main -m models/llama3.1-70b-q4_k_m.gguf \
-p "Расскажи историю про кота" \
-c 200000 \  # Контекст 200k токенов
--ssd-cache \  # Включаем SSD кэш
--ssd-cache-path /mnt/nvme0/llama_cache \  # Путь к кэшу
--ssd-cache-size 40G \  # Размер кэша на диске
--keep-in-ram 8192 \  # Сколько токенов держать в RAM
--batch-size 512 \  # Важно для производительности
--ctx-size 2048 \  # Размер окна внимания
--parallel 4  # Количество потоков для IO

Разберем ключевые параметры:

Шаг 4: оптимизация под ваше железо

Здесь нет универсальных рецептов. Нужно тестировать.

3 Профилируем и настраиваем

# Запускаем с профилированием
./main -m model.gguf -c 100000 --ssd-cache --ssd-cache-path /cache \
--prompt-cache /tmp/prompt.cache \
--prompt-cache-all \
--log-disable \
--simple-io 2>&1 | grep -E "(tokens/s|ssd|ram)"

Что смотреть:

• ssd read/write ops - если много операций ввода-вывода, увеличивайте --keep-in-ram
• RAM usage - не должно быть близко к максимуму
• Tokens per second - сравнивайте с режимом без SSD

Типичная ошибка: слишком маленький --keep-in-ram. Модель постоянно дергает диск, скорость падает в 10 раз.

Шаг 5: ловушки и как их обходить

Я потратил неделю на отладку. Сохраните себе эти проблемы.

Проблема 1: SSD перегревается и троттлит

NVMe диски при постоянной нагрузке греются. Температура >70°C - начинается троттлинг, скорость падает.

Решение:

# Устанавливаем heatsink на SSD
# Или ставим вентилятор
# Или ограничиваем скорость через --parallel 2

Проблема 2: fragmentation кэша

После нескольких запусков кэш фрагментируется. Чтение замедляется.

# Очищаем кэш раз в неделю
rm -rf /mnt/nvme0/llama_cache/*

# Или используем отдельный раздел только для кэша

Проблема 3: внезапная смерть процесса

Если llama.cpp падает, кэш-файлы остаются заблокированными.

# Проверяем перед запуском
lsof | grep llama_cache
# Убиваем зависшие процессы
# Или используем --ssd-cache-cleanup при запуске

Реальные цифры: что получится на разном железе

Я тестировал три конфигурации (все тесты на 10.02.2026):

Без SSD offload все эти конфигурации либо не запускались, либо работали с 0.5-1 t/s из-за свопа ОС.

Когда это НЕ нужно использовать

SSD offload - не панацея. Есть случаи, когда лучше выбрать другой подход:

• Короткий контекст (< 32k) - обычный режим быстрее
• Модели < 7B - проще докупить RAM
• HHD вместо SSD - забудьте. Скорость будет 0.1 t/s
• Многопользовательский режим - используйте кластерные решения

Для действительно огромных контекстов (1M+) лучше смотреть в сторону радикальных оптимизаций KV-cache или специализированных систем вроде Tailor.

Что будет дальше: прогноз на 2026-2027

SSD offload в llama.cpp - временное решение. Уже вижу тренды:

1. Аппаратное ускорение - Intel и AMD добавляют в процессоры специальные блоки для KV-cache
2. CXL memory - можно будет подключать DDR5 как сетевой ресурс
3. Квантовые SSD (шутка, но кто знает)
4. Полный отказ от полного контекста - модели научатся работать с 4k окном без потерь

Пока этого нет - SSD offload ваш лучший друг для длинных контекстов. Не идеально, но работает.

P.S. Если у вас есть старый NVMe диск от ноутбука - купите корпус за 1000 рублей и используйте как внешний кэш. Дешевле, чем 64 ГБ RAM.