К содержимому
myvram.ru

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 (зеркало) — гайд «Скачать файл модели в России».

Рядом