Когда «полная выгрузка на GPU» оказывается не такой уж полной
Вы настраиваете LM Studio. У вас RTX 3090 с 24 ГБ VRAM. Оперативки – 32 ГБ. Выбираете GPT-OSS 20B GGUF, ставите галочку "Full GPU Offload" и с чистой совестью жмёте "Загрузить".
Через 30 секунд получаете Out of Memory. Диспетчер задач показывает, что VRAM заполнена на 80%, а оперативная память – на 95%. Вы чешете затылок. Зачем тогда эта кнопка, если она не работает?
Проблема не в вашем железе. Проблема в том, как LM Studio (а точнее, llama.cpp под капотом) взаимодействует с Windows и драйверами NVIDIA на 25 января 2026 года.
Важно: Если вы думаете, что Full GPU Offload означает "вся модель целиком уходит в видеопамять", вы ошибаетесь. Это распространённое заблуждение, которое сломало график работы тысяч энтузиастов локального ИИ.
Что на самом деле делает Full GPU Offload в LM Studio
Давайте разберём по косточкам. Когда вы загружаете GGUF-модель в LM Studio, происходит следующее:
- Файл модели читается с диска
- Определяется количество слоёв (layers) и их размер
- Считается, сколько слоёв поместится в доступную VRAM
- Оставшиеся слои... остаются в оперативной памяти
Вот тут собака зарыта. "Full GPU Offload" в контексте LM Studio означает "выгрузить на GPU столько слоёв, сколько физически поместится". Не все. Столько, сколько поместится.
Для моделей типа GPT-OSS 20B в формате Q4_K_M (самом популярном на 2026 год) это примерно 18-20 ГБ VRAM при полной загрузке. Казалось бы, на RTX 3090 должно влезть. Но нет.
Три неочевидных пожирателя оперативки
Почему же RAM заполняется, когда модель должна быть в VRAM? Причин несколько, и каждая по-своему коварна.
1. Контекстный буфер – тихий убийца
Когда вы работаете с длинным контекстом (4096 токенов и более), LM Studio создаёт буфер в оперативной памяти. Этот буфер содержит:
- Текущий контекст диалога
- Ключи и значения внимания (KV-cache)
- Временные данные для генерации
Для контекста в 8192 токенов (стандарт для моделей 2025-2026 годов) этот буфер может занимать 4-6 ГБ RAM. И он всегда находится в оперативной памяти, даже при Full GPU Offload.
2. Драйверы NVIDIA и их аппетиты
Драйверы NVIDIA под Windows (версии 560.xx на начало 2026) резервируют системную память для своих нужд. Это называется "Shared GPU Memory" или "Shared System Memory".
Когда вы запускаете LM Studio, драйвер видит: "О, большая модель! Надо подготовиться к свопу!". И резервирует 8-12 ГБ оперативки под потенциальные нужды видеопамяти.
| Компонент | Примерный объём | Где находится |
|---|---|---|
| Модель (20B Q4_K_M) | ~12 ГБ | VRAM + часть в RAM |
| Контекстный буфер (8192) | ~5 ГБ | Только RAM |
| Резерв драйвера NVIDIA | ~8 ГБ | Только RAM |
| Системные процессы | ~3 ГБ | RAM |
| Итого | ~28 ГБ | Из 32 ГБ доступных |
3. Проклятие слоёв llama.cpp
Llama.cpp (движок LM Studio) загружает модель послойно. Каждый слой – это отдельный тензор. Когда слой не помещается в VRAM, он остаётся в RAM, но llama.cpp всё равно пытается его использовать.
Результат? Медленные вычисления на CPU и двойное использование памяти: слой лежит в RAM, но драйвер пытается его скопировать в VRAM для вычислений.
Пошаговый план: как заставить Full GPU Offload работать правильно
Теория – это хорошо, но давайте перейдём к практике. Вот что нужно сделать, чтобы 20B модель летала на RTX 3090 с 32 ГБ RAM.
1 Проверяем базовые настройки LM Studio
Откройте LM Studio и перейдите в Settings → Model. Убедитесь, что у вас установлены следующие параметры:
- GPU Offload Layers: Установите вручную, а не "Auto"
- Context Length: Начните с 4096, а не 8192
- Batch Size: 512 (не больше)
Для RTX 3090 с 24 ГБ VRAM и моделью 20B Q4_K_M установите GPU Offload Layers на 35-38 (из примерно 40 общих слоёв). Оставьте 2-3 слоя для запаса.
2 Настройка драйверов NVIDIA
Откройте Панель управления NVIDIA → Управление параметрами 3D → Глобальные параметры:
# Это не команда, а визуализация настроек:
1. Максимальное количество заранее подготовленных кадров: 1
2. Режим управления электропитанием: Макс. производительность
3. Потоковая оптимизация: Авто
4. Вертикальный синхроимпульс: Выкл.
Но самая важная настройка – «Ограничение размера памяти CUDA» в разделе «Параметры CUDA». Установите значение на 22000 МБ (из 24576 доступных). Оставьте 2 ГБ для системы.
Совет: Если вы работаете с разными моделями, создавайте отдельные профили в Панели управления NVIDIA для каждой конфигурации. Для 20B моделей – один профиль, для 7B – другой, для 70B (если используете) – третий.
3 Оптимизация Windows 11 (2025 обновление)
Windows 11 с обновлением 2025 года получила улучшенное управление памятью для AI-задач, но по умолчанию оно отключено.
Откройте PowerShell от имени администратора и выполните:
# Включаем оптимизацию памяти для CUDA-приложений
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" -Name "LargePageMinimum" -Value 0xFFFFFFFF
# Отключаем ненужные службы, которые жрут память
Stop-Service -Name "SysMain" -Force
Set-Service -Name "SysMain" -StartupType Disabled
# Настраиваем файл подкачки (если у вас SSD)
$pagefile = Get-WmiObject -Query "SELECT * FROM Win32_PageFileSetting WHERE Name='C:\\pagefile.sys'"
$pagefile.InitialSize = 16384
$pagefile.MaximumSize = 32768
$pagefile.Put()
4 Продвинутая настройка llama.cpp через аргументы
LM Studio позволяет передавать аргументы напрямую в llama.cpp. В настройках модели добавьте:
-ngl 38 --no-mmap --mlock
Что это даёт:
-ngl 38: Ровно 38 слоёв на GPU (точное число, а не "сколько влезет")--no-mmap: Загружать модель целиком в память, а не через memory-mapped файлы--mlock: Блокировать модель в RAM, предотвращая свопинг
Если у вас проблемы с запуском больших LLM на другом железе, например на AMD Strix Halo, принципы те же – точное распределение ресурсов. Подробнее в нашем руководстве по AMD Strix Halo.
Чего НЕ делать: самые частые ошибки
За годы работы с LM Studio я видел одни и те же ошибки снова и снова. Избегайте этих ловушек:
Ошибка 1: Ставить GPU Offload Layers на максимум. Если укажете 40 слоёв для модели, у которой 40 слоёв, системе не останется памяти для контекстного буфера. Всегда оставляйте запас 2-3 слоя.
Ошибка 2: Использовать контекст 8192 для 20B модели на 32 ГБ RAM. Это убийственно для памяти. Начните с 4096, проверьте стабильность, только потом увеличивайте.
Ошибка 3: Запускать LM Studio вместе с браузером (50+ вкладок), Docker и Android-эмулятором. Каждый из этих процессов резервирует гигабайты памяти. Чистая система – быстрая модель.
Если вы хотите глубже понять стратегии распределения ресурсов между CPU и GPU, рекомендую наше руководство по масштабированию локальных LLM – там разбираем кейсы от одной карты до кластеров.
Проверка результата: как понять, что всё работает правильно
После всех настроек откройте Диспетчер задач Windows (Ctrl+Shift+Esc) и перейдите на вкладку «Производительность» → «GPU». Вы должны увидеть:
- Использование видеопамяти: 21-22 ГБ из 24 ГБ
- Использование общей памяти (Shared GPU Memory): менее 1 ГБ
- Загрузка GPU (3D): 80-95% во время генерации
В LM Studio скорость генерации для 20B модели на RTX 3090 должна быть:
- Первая генерация (холодный старт): 10-15 секунд
- Последующие генерации: 15-25 токенов в секунду
- Полный ответ на 500 токенов: 20-30 секунд
Если цифры сильно отличаются – что-то пошло не так. Вернитесь к шагу 1.
А если ничего не помогает?
Бывает. Железо капризничает, драйверы глючат, звёзды не сошлись. В таком случае:
- Попробуйте более новую версию LM Studio. На 25 января 2026 актуальна версия 0.3.5+. В ней исправлены многие баги с распределением памяти.
- Скачайте другую квантованную версию модели. Вместо Q4_K_M попробуйте Q3_K_M. Она занимает на 25% меньше места при минимальной потере качества.
- Рассмотрите переход на Linux. Серьёзно. Под Linux управление памятью для CUDA-приложений работает на 30% эффективнее. Если это рабочая станция – Ubuntu 24.04 LTS с NVIDIA драйверами 560+ творит чудеса.
Для тех, кто работает с ещё более серьёзными моделями (30B+, MoE-архитектуры), у нас есть отдельный гайд по запуску 30B MoE-моделей на ограниченном железе.
Будущее Full GPU Offload: что нас ждёт
Проблема с распределением памяти в LM Studio – не уникальна. Все локальные LLM-клиенты сталкиваются с похожими сложностями. Но тенденции 2025-2026 годов обнадёживают:
- Windows DirectML Backend: Microsoft активно развивает DirectML как альтернативу CUDA под Windows. В LM Studio 0.4.0+ обещают нативную поддержку.
- Умное распределение слоёв: Новые версии llama.cpp учатся динамически перемещать слои между RAM и VRAM в зависимости от нагрузки.
- Сжатие контекста: Техники like "rolling context" позволяют работать с длинным контекстом, не загружая его целиком в память.
Мой прогноз: к концу 2026 года проблема OOM при Full GPU Offload станет экзотикой. Но пока – вооружайтесь знаниями из этой статьи и настраивайте вручную.
P.S. Если после всех манипуляций модель всё равно падает с OOM – проверьте, не стоит ли у вас в фоне майнер. Шутка. Но не совсем.