CPU-offload и гибрид GPU+RAM: когда и сколько теряешь
«Модель не влезает в VRAM — можно ли запустить с offload?» Да, и это честное спасение, если модель лишь чуть больше бюджета карты: часть весов (и KV-кэша) живёт в системной RAM, GPU считает свою часть, CPU — свою, а за один токен они по очереди обмениваются слоями. Цена — скорость: GPU-часть идёт со скоростью GPU-памяти (сотни–тысячи ГБ/с), CPU-часть — со скоростью DDR (десятки ГБ/с), и общая скорость упирается в медленную. Ток/с падает в разы или на порядок.
Как решается «влезает / offload»
Три числа берутся из формул (src/lib/formulas.ts) и данных files-слоя:
total = weights_GB + KV_GB(ctx) + overhead (1.5 ГБ)
weights_GB — точный размер файла (files.json: байты манифеста/HF, не «0.6 × параметры»)
KV_GB(ctx) = 2 × layers × kv_heads × head_dim × b_kv × ctx / 1e9 (b_kv: fp16 = 2, q8_0 = 1)
budget = VRAM × 0.9 (dedicated GPU; unified-память Mac — ×0.70–0.85)
overflow = total − budget → если > 0, эта часть уходит в RAM (CPU-offload) Оценка tok/s для гибрида (пометка: оценка, не бентчмарк): GPU-часть — по bandwidth карты (ГБ/с ÷ общий размер × 0.5), CPU-часть — по bandwidth RAM: DDR4 dual ≈ 25.6 ГБ/с, DDR5-4800 dual ≈ 76.8 ГБ/с (ориентиры из гайда «LLM без видеокарты»); итог — взвешенная по долям величина. Чистый CPU-offload формула даёт 1–5 tok/s для dense-моделей (константы CPU-offload в методике).
Примеры (файлы из каталога, числа из формул)
| Модель · квант (файл) | Карта / ctx | KV @ctx | Итого (веса+KV+1.5) | Бюджет (90%) | Вердикт | tok/s (оценка) |
|---|---|---|---|---|---|---|
| Qwen3 8B · Q4_K_M 5.03 ГБ (GGUF, Qwen) | 8 ГБ (320 ГБ/с) / 16K | 2.4 ГБ | 8.9 ГБ | 7.2 ГБ | не влезает: 1.7 ГБ в RAM | ≈5.3–11 (DDR4–DDR5) 12 ГБ-карта: влезает, ≈22.4 tok/s |
| Gemma 3 12B · Q4_K_M 7.3 ГБ (GGUF, ggml-org) | 8 ГБ (320 ГБ/с) / 32K | 12.9 ГБ | 21.7 ГБ | 7.2 ГБ | не влезает: 14.5 ГБ в RAM | ≈0.8–2.3 — непригодно |
| GPT-OSS 120B · MXFP4 (нативный) 63.39 ГБ (GGUF, ggml-org) | 24 ГБ (1008 ГБ/с) / 16K | 0.6 ГБ | 65.5 ГБ | 21.6 ГБ | частичный offload: ~70% в RAM |
≈0.3–0.8 (оценка) 2×24 ГБ: ≈1.7; M4 Max 128 ГБ (unified): влезает, ≈4.2 |
| Nemotron 3.5 Lightning 30B-A3B · Q4_0 18.9 ГБ (GGUF, ggml-org) | 24 ГБ (1008 ГБ/с) / 16K | 0.1 ГБ | 20.5 ГБ | 21.6 ГБ | влезает (MoE: память — по total 30B) | ≈100.8 (скорость MoE — по active ~3B) Ollama-сборка Q4_K_M (24.27 ГБ): лёгкий offload, ≈5.7 |
Размеры — точные байты из манифестов/HF API от 19.10.2026. Gemma 3: у модели скользящее окно 1024 у большинства слоёв — KV-столбец считается по всем 48 слоям (консервативная верхняя оценка; реальный KV при длинном контексте меньше). GPT-OSS 120B: KV — только 18 full-attention-слоёв (гибрид с sliding-слоями, окно 128). MoE-скорость — оценка по активным параметрам (K=0.18), dense — K=0.5; всё — модельные оценки, не бентчмарки.
Когда offload — честное спасение, а когда нет
Правило по overflow (total − бюджет) — из той же формулы, что выше:
- overflow ≤ ~25% нагрузки (например, Qwen3 8B Q4_K_M на 8 ГБ: 8.9 против 7.2 ГБ — 1.7 ГБ в RAM): лёгкий offload, ≈5–15 tok/s по оценке — для чата/скриптов допустимо. Это и есть «честное спасение».
- overflow ~25–60%: 2–5 tok/s (формула dense-offload: 1–5 tok/s). «Модель работает» — да, но отвечать будет секунд по десять на строку. Для интерактива — нет, для ночного батча — может, да.
- overflow > 60% (например, Gemma-3 12B на 8 ГБ с 32K: 14.5 из 21.7 ГБ в RAM): ≈1–2 tok/s — фактически непригодно. Правильный ответ не «как ускорить offload», а «как не offload» (ниже).
- MoE-модели (GPT-OSS 120B, Nemotron 30B-A3B): память — по total, скорость — по active. Частичный offload для них менее катастрофичен, чем для dense того же размера, но «влезает целиком» — только когда total + KV в бюджете (см. строку Nemotron: Q4_0 влезает на 24 ГБ, Ollama-сборка Q4_K_M — уже лёгкий offload).
Как уменьшить, чтобы offload не понадобился
- Меньший квант: Q8_0 → Q4_K_M → Q3/IQ. Реальные размеры по моделям — сравнение квантов Qwen3 8B, Gemma 3 12B, Nemotron 3.5 30B-A3B (все модели × кванты — каталог GGUF; простыми словами — гид по квантам).
- Меньший контекст: KV растёт линейно — 32K → 16K режет KV-столбец вдвое (например, у Gemma-3 12B с 32K на 8 ГБ: 21.7 → 12 ГБ при 8K). Сколько контекста стоит в ГБ — гайд «Сколько VRAM ест контекст».
- KV q8_0 вместо fp16: в оценке режет KV-столбец примерно вдвое («halves» —
оценка; точный коэффициент верифицируется замером — llama.cpp
--cache-type-k q8_0/ Ollama KV-квантизация; замер не публиковали). Риск: качество на длинном контексте может просесть. - Модель поменьше: если задача не требует 12B+ — 8B-класс влезает без offload. Что погонит на вашей памяти: 8 ГБ / 16 ГБ / 24 ГБ / 64 ГБ.
- MLX / unified-память (Mac): на Apple Silicon «оффлоад» не нужен — модели живут в едином пуле памяти (бюджет 70–85% unified). Файлы MLX (4/8-bit) — в блоке MLX на страницах файлов; скорости unified-памяти — гайд «LLM без видеокарты».
- Если offload всё же нужен — управляйте долей на GPU: llama.cpp
-ngl N(число слоёв на GPU), Ollama — параметрnum_gpu(Modelfile), LM Studio — ползунок «GPU offload» в настройках модели, vLLM —--cpu-offload-gb. Правило: KV и как можно больше слоёв — в VRAM, в RAM — хвост.
Где взять файлы (включая РФ)
Конкретные файлы (GGUF/Ollama/MLX с точными размерами) — на страницах «Файлы» по моделям (на примере Qwen3 8B) и в каталоге GGUF. HuggingFace в РФ заблокирован — рабочие пути: ollama pull (реестр) и hf-mirror.com (зеркало) — гайд «Скачать файл модели в России».
Рядом