Запуск 70B+ моделей на домашнем ПК: слоевый стриминг против ограничений VRAM

Почему 70B модель на 24 ГБ VRAM — это не безумие

Открою секрет: большинство инженеров смотрят на требования памяти для 70B моделей и опускают руки. 140 ГБ в FP16. 35 ГБ в Q4. А у вас RTX 4090 с 24 ГБ или новая RTX 5060 Ti с теми же 24 ГБ. Цифры не сходятся.

Но математика лжёт. Вернее, она считает худший случай — когда вся модель должна быть в VRAM одновременно. А что если загружать её по частям? Слоевый стриминг (layer streaming) меняет правила игры. Вместо «всё или ничего» мы говорим «дай то, что нужно сейчас».

Почему это работает? LLM обрабатывает токены последовательно. Слой 1 заканчивает работу — его можно выгрузить, загрузить слой 2. Пока GPU занят вычислениями, CPU или NVMe готовит следующий слой. Это как конвейер на заводе: деталь движется, а станки меняются.

Железо 2026: что реально работает

Прежде чем перейти к технике, посмотрим на железо. Цены упали, но не так сильно, как хотелось бы.

Видите RTX 5060 Ti? Та же 24 ГБ VRAM, что и у 4090, но архитектура Blackwell даёт +40% эффективности для слоевого стриминга. NVIDIA специально оптимизировала драйверы для этой нагрузки.

Слоевый стриминг: три подхода, которые реально работают

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

1 CPU Offloading: классика, которая не стареет

Самый простой метод. Храним всю модель в оперативке, загружаем слои в VRAM по очереди. llama.cpp делает это из коробки с флагом --ngl (число слоёв на GPU).

# Запуск Llama 3.1 70B на RTX 4090 с 24 ГБ VRAM
./main -m llama-3.1-70b.Q4_K_M.gguf \
  --ngl 35 \
  -t 12 \
  -c 4096 \
  -p "Расскажи про квантовую физику"

Что здесь происходит? --ngl 35 говорит: «Держи 35 слоёв в VRAM, остальные в RAM». Всего слоёв в Llama 70B — около 80. Значит, половина в видеопамяти, половина в оперативке.

Как рассчитать число слоёв? Грубо: размер одного слоя в Q4 ≈ (70B / 80 слоёв) × 0.5 байта = ~440 МБ. 24 ГБ VRAM / 440 МБ ≈ 54 слоя. Но нужен запас для KV-кэша и активаций. Оставляйте 20-30% свободными.

2 NVMe Offloading: когда RAM тоже мало

У вас 64 ГБ оперативки, а модель в Q4 занимает 35 ГБ. Вроде бы помещается. Но вместе с системой, браузером и самим llama.cpp остаётся 15-20 ГБ. Мало.

Решение — хранить модель на SSD, подгружать в RAM, а оттуда в VRAM. Двухуровневый кэш. В llama.cpp с 2025 года есть экспериментальная поддержка через --mmap и --mlock.

# Модель на NVMe, слои в RAM, часть в VRAM
./main -m /nvme/models/llama-3.1-70b.Q4_K_M.gguf \
  --ngl 25 \
  --mmap \
  -t 16 \
  -c 2048

Скорость? Да, медленнее. Загрузка слоя с NVMe (7000 МБ/с) вместо RAM (60000 МБ/с). Но если у вас PCIe 5.0 SSD — разница 2-3x, а не 10x. Токенов в секунду будет меньше, но модель запустится.

Этот подход я подробно разбирал в статье «Когда RAM не хватает: заставляем llama.cpp работать с контекстом 1M+ через SSD Offload» — принципы те же.

3 Асинхронный стриминг в vLLM: для production

llama.cpp хорош для демо. vLLM — для реальной работы. С версии 0.4.0 там есть Tensor Parallelism с автоматическим слоевым стримингом.

# vLLM с автоматическим распределением слоёв
from vllm import LLM, SamplingParams

# Указываем, сколько слоёв максимум на GPU
llm = LLM(
    model="meta-llama/Llama-3.1-70B",
    quantization="awq",  # или "gptq"
    tensor_parallel_size=1,  # одна карта
    max_num_seqs=4,
    gpu_memory_utilization=0.85,  # 85% VRAM
    enable_layer_streaming=True  # ключевой флаг!
)

vLLM сам решает, сколько слоёв держать в VRAM. Умнее, чем ручной --ngl. Но требует больше памяти на overhead — около 2 ГБ против 500 МБ у llama.cpp.

Квантование 2026: Q3 vs Q4 vs Q5

Все говорят про Q4. Но на 2026 год появились гибридные подходы. Например, Q3_K_L для внимания и Q4_K_M для FFN слоёв. llama.cpp поддерживает это с конца 2025.

IQ4_XS — новый формат от Intel (да, они ещё в игре). Использует 4 бита, но с умным распределением точности. Для слоевого стриминга идеален: меньше размер — больше слоёв в VRAM.

# Конвертация в IQ4_XS через llama.cpp
./quantize \
  models/llama-3.1-70b/ggml-model-f16.gguf \
  models/llama-3.1-70b/ggml-model-IQ4_XS.gguf \
  IQ4_XS

Практика: запускаем Command R+ 72B на RTX 5060 Ti

Теория — это хорошо. Давайте реальный пример. Command R+ от Cohere — 72B параметров, отличная для RAG. На февраль 2026 есть GGUF версии от TheBloke.

1 Скачиваем и проверяем

# Скачиваем модель (IQ4_XS для экономии)
wget https://huggingface.co/TheBloke/command-r-plus-GGUF/resolve/main/command-r-plus.IQ4_XS.gguf

# Размер?
ls -lh command-r-plus.IQ4_XS.gguf
# ~22 ГБ — отлично, влезает в RAM

2 Запускаем со слоевым стримингом

# Оптимальные параметры для RTX 5060 Ti 24 ГБ
./main -m command-r-plus.IQ4_XS.gguf \
  --ngl 45 \           # 45 слоёв в VRAM (~10 ГБ)
  --threads 14 \       # 6P+8E ядер
  --ctx-size 8192 \    # RAG требует контекст
  --batch-size 512 \   # Для параллелизма
  --gpu-layers-split 24:21 \  # Новый флаг: 24 слоя сразу, 21 по мере необходимости
  --mlock \            # Держим в RAM
  -p "Проанализируй документ:"

Новый флаг --gpu-layers-split появился в январе 2026. Позволяет указать: «Столько слоёв загрузи сразу, остальные подгружай лениво». Снижает задержки при генерации первого токена.

3 Мониторим использование памяти

# Смотрим, что происходит
nvtop  # или nvidia-smi -l 1

# Ожидаемые показатели:
# VRAM: 18-20 ГБ из 24 ГБ
# RAM: 30-35 ГБ из 64 ГБ
# Скорость: 9-14 токенов/с

Ошибки, которые взрывают память (и как их избежать)

Я видел десятки падений OOM. Большинство — из-за трёх типовых ошибок.

Ошибка 1: Жадный KV-кэш

Вы ставите контекст 32k, забывая, что KV-кэш для 70B модели съедает 5-7 ГБ VRAM. Решение:

# НЕ ТАК (съест всю память)
./main -m 70b-model.gguf --ctx-size 32768 --ngl 40

# ТАК (ограничиваем кэш)
./main -m 70b-model.gguf --ctx-size 8192 --ngl 45 --kv-cache-max 4096

--kv-cache-max лимитирует память под кэш. Если контекст превысит — старые токены вытеснятся.

Ошибка 2: Слепое доверие автоматике

vLLM с gpu_memory_utilization=0.95 на 24 ГБ карте — это 22.8 ГБ. Без учёта памяти системы и драйверов. На практике ставьте 0.8-0.85.

Ошибка 3: Игнорирование температуры VRAM

Слоевый стриминг — это постоянная загрузка/выгрузка. VRAM греется. На RTX 5060 Ti с пассивным охлаждением может быть троттлинг через 20 минут. Мониторьте:

watch -n 2 "nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader"
# Если выше 85°C — делайте паузы или улучшайте охлаждение

Будущее: что ждёт нас в 2027?

Слоевый стриминг — промежуточное решение. На горизонте три технологии:

1. HBM4 видеокарты — 64-128 ГБ на потребительских картах. Цена? Первое время заоблачная.
2. Оптическая связь CPU-GPU — загрузка слоёв со скоростью RAM (50+ ГБ/с). В прототипах у AMD и Intel.
3. Специализированные AI-ускорители с архитектурой «память-на-чипе». Cerebras уже показывает 72B модели на одном чипе.

Но пока этого нет — слоевый стриминг остаётся вашим лучшим другом. Это не идеально, но работает. 70B модель на домашнем ПК — не фантастика, а инженерная задача. Решаемая.

Кстати, если хотите глубже погрузиться в оптимизацию конкретных моделей, посмотрите мою статью про KimiLinear-48B и MLA KV Cache — там похожие техники, но для другой архитектуры.

А теперь идите и запускайте свои 70B модели. Только не забудьте про мониторинг температуры.