Тест локальных LLM на длинные промпты: Qwen3 vs GLM на 48GB VRAM | 2026 | AiManual
AiManual Logo Ai / Manual.
20 Янв 2026 • Гайд

Когда 48GB VRAM не хватает: какие локальные модели реально работают с промптами как у Claude Code

Эмпирическое исследование: какие модели на 48GB VRAM справляются с системными промптами в 20k токенов. Тесты Qwen3, GLM 4.6v, реальные показатели памяти.

Почему ваша 48GB видеокарта плачет от 20k токенов

Вы купили RTX 6000 Ada с 48GB VRAM. Потратили кучу денег. Загрузили Qwen3-Next-80B, запустили инференс и... получили CUDA out of memory на промпте в 15 тысяч токенов. Знакомо?

Проблема не в железе. Проблема в том, как работают современные локальные модели с длинными контекстами. Особенно когда речь о системных промптах, которые используют в Claude Code - те самые, где подробнейшие инструкции на 20k+ токенов.

Важный момент: 48GB VRAM - это не волшебная палочка. Это всего 48 гигабайт. Llama 3.2 405B в FP16 занимает 810GB. Даже самый оптимизированный квантованный вариант требует больше вашей видеопамяти.

Что на самом деле происходит с памятью при длинных промптах

Давайте разберемся, куда уходят ваши 48 гигабайт. Возьмем Qwen3-Next-80B в формате GGUF Q4_K_M:

  • Базовый размер модели: ~45GB (уже почти все VRAM)
  • Кэш ключей-значений для 20k контекста: ~8-12GB
  • Буферы для вычислений: 2-4GB
  • Операционная система и драйверы: 1-2GB

Итого: 45 + 12 + 4 + 2 = 63GB. Вылетаем за пределы даже при идеальных условиях.

💡
Самый частый миф: "У меня 48GB VRAM, значит, я могу запустить любую 80B модель". Нет. Можно запустить только с сильным квантованием и маленьким контекстом. Для длинных промптов нужны либо меньшие модели, либо другие архитектуры.

Методика тестирования: как мы мучили видеокарты

Я взял систему с RTX 6000 Ada (48GB), 128GB RAM, Core i9-14900K. Тестировал через llama.cpp версии 0.15.0 - самый стабильный вариант на январь 2026 года.

Тестовый промпт: реалистичный системный промпт для кодогенерации в стиле Claude Code. 18,743 токена инструкций по архитектуре, стилю кода, тестам, документации. Плюс 2k токенов пользовательского запроса.

# Команда для теста
./llama-cli -m qwen3-next-80b-q4_k_m.gguf \
  -p "[SYSTEM: 18k токенов инструкций...]\n[USER: Напиши микросервис на Go...]" \
  -n 1024 -c 20000 --mlock --no-mmap

Результаты: кто выжил, а кто сдался

Модель Версия Квантование Загрузка Память (пик) Статус
Qwen3-Next-80B Qwen/Qwen3-Next-80B Q4_K_M 45.2GB 51.3GB OOM
GLM 4.6v THUDM/glm-4-6v-80b Q4_K_M 43.8GB 48.1GB Еле-еле
Qwen3-Coder-32B Qwen/Qwen3-Coder-32B Q5_K_M 19.2GB 28.4GB Работает
DeepSeek-Coder-V3 deepseek-ai/DeepSeek-Coder-V3-32B Q4_K_M 17.8GB 26.7GB Работает
GPT-OSS-70B openai/gpt-oss-70b Q3_K_L 29.4GB 39.2GB Работает

Вот вам и сюрприз. Qwen3-Next-80B - новейшая модель на январь 2026, но она не влезает даже в 48GB с квантованием Q4. GLM 4.6v висит на грани - работает, но с переполнением в оперативку и скоростью 0.8 токенов в секунду.

Почему Qwen3-Next не влез - технические подробности

Qwen3-Next использует архитектуру с расширенным контекстом до 128k токенов. Для этого нужны специальные механизмы кэширования, которые жрут память как не в себя. Даже с Q4 квантованием:

  • Базовые веса: 45.2GB
  • Rotary embeddings для 20k контекста: 2.1GB
  • KV cache в формате paged attention: 4.3GB
  • Временные буферы для flash attention: до 3GB

Итого 54.6GB при пиковой нагрузке. Начинается swapping в RAM, скорость падает до неприемлемых значений.

Важная деталь: llama.cpp с флагом --no-mmap пытается загрузить всю модель в VRAM. Без этого флага он использует memory mapping и частично грузит из RAM, но тогда скорость еще ниже.

GLM 4.6v: работает, но стоит ли оно того?

GLM 4.6v от THUDM - обновленная версия на январь 2026 с поддержкой мультимодальности и 80B параметров. Удивительно, но она влезает. Почти.

Пиковое потребление: 48.1GB. То есть все 48GB VRAM заполнены, плюс 100MB утекают в shared memory или систему. Темп генерации: 0.8-1.2 токенов в секунду. На ответ в 500 токенов ждем 7-10 минут.

Качество ответов? Приемлемое. Но когда ждешь 10 минут на один промпт, начинаешь задумываться - может, лучше взять 32B модель, которая ответит за 30 секунд?

Победители: 32B модели, которые реально работают

1 Qwen3-Coder-32B в Q5_K_M

Вот это неожиданность. Qwen3-Coder-32B в квантовании Q5_K_M показывает лучшее качество кода из всех протестированных. Потребление памяти: 19.2GB загрузка, 28.4GB пик. Скорость: 12-15 токенов в секунду.

Почему Q5, а не Q4? Потому что для кодогенерации точность важнее. Разница в 3GB памяти дает заметный прирост качества. Особенно в сложных архитектурных решениях.

2 DeepSeek-Coder-V3 32B

Новейшая версия DeepSeek-Coder на январь 2026. Поддержка контекста 256k токенов, но нам важно другое - эффективное использование памяти. Даже с 20k промптом потребляет всего 26.7GB.

Качество кода? Немного уступает Qwen3-Coder в сложных архитектурных задачах, но выигрывает в простом бойлерплейте. Скорость: 14-18 токенов в секунду.

GPT-OSS-70B: темная лошадка

OpenAI выложили GPT-OSS-70B в декабре 2025. Это не полноценный GPT-4.5, а специально обученная open-source версия. Но что важно - она оптимизирована для эффективной работы с памятью.

С квантованием Q3_K_L модель занимает 29.4GB. Добавляем KV cache - получаем 39.2GB. Остается запас для вычислений. Скорость: 6-8 токенов в секунду.

Качество? Лучше, чем у 32B моделей в понимании сложных инструкций. Хуже в конкретном синтаксисе. Если ваш промпт - это в основном требования к архитектуре, а не синтаксические детали, GPT-OSS-70B ваш выбор.

💡
Совет из практики: если у вас 48GB VRAM и нужны длинные промпты, берите 32B модель в Q5 квантовании, а не 80B в Q4. Вы получите в 10-15 раз выше скорость и почти такое же качество для большинства задач.

Оптимальные настройки для 48GB VRAM

После недели тестов я вывел золотые правила:

# Для Qwen3-Coder-32B
./llama-cli -m qwen3-coder-32b-q5_k_m.gguf \
  -c 32768 \  # Контекст 32k, не меньше
  --rope-freq-base 1000000 \  # Важно для длинного контекста
  --rope-freq-scale 0.5 \
  --mlock \  # Фиксируем в RAM
  --no-mmap \  # Не используем memory mapping
  -t 12 \  # 12 потоков CPU
  -b 512 \  # Размер батча
  --memory-f32  # Используем float32 для KV cache

Ключевые моменты:

  • --memory-f32: KV cache в float32 вместо float16. Занимает в 2 раза больше памяти, но стабильнее работает с длинными контекстами
  • --rope-freq-base 1000000: настройка rotary embeddings для контекста больше 8k
  • -c 32768: всегда ставьте контекст с запасом. Даже если промпт 20k, модель может нуждаться в буфере

Чего делать нельзя: типичные ошибки

Ошибка 1: Пытаться засунуть 80B модель любой ценой. Результат - swapping в RAM, скорость 0.5 токенов в секунду и бесполезная видеокарта.

Ошибка 2: Использовать Q2 или Q3 квантование для кодогенерации. Модель начнет галлюцинировать синтаксис, пропускать скобки, создавать нерабочий код.

Ошибка 3: Забывать про KV cache. При 20k контексте кэш ключей-значений съедает 8-12GB. Не учитываете - получаете OOM в середине генерации.

А что насчет vLLM и других инференс-серверов?

Пробовал. vLLM 0.6.0 (последняя на январь 2026) с paged attention должен экономить память. На практике для локального запуска с одной картой - те же проблемы.

Paged attention помогает, когда у вас много параллельных запросов с коротким контекстом. У нас один запрос с длинным контекстом - выгоды почти нет.

Text Generation Inference от Hugging Face? Тяжеловесный, требует много CPU памяти. Для одной карты неоптимален.

Выводы, которые вас удивят

1. 48GB VRAM недостаточно для 80B моделей с длинными промптами. Даже с Q4 квантованием. Забудьте.

2. 32B модели в Q5 - золотая середина. Qwen3-Coder-32B-Q5_K_M - лучший выбор на январь 2026 для кодогенерации с длинными промптами.

3. Скорость важнее размера. 32B модель на 15 токенов в секунду продуктивнее, чем 80B на 1 токен в секунду. Вы больше не будете бояться отправлять длинные промпты.

4. KV cache - главный пожиратель памяти. При 20k контексте выделяйте минимум 8GB под кэш. И используйте --memory-f32 для стабильности.

Мой прогноз: к середине 2026 года появятся 40-50B модели, которые по качеству будут как сегодняшние 80B, но с вдвое меньшими требованиями к памяти. А пока - выбирайте умно, а не жадно. Иногда меньше - действительно больше.

P.S. Если у вас все же есть доступ к 2x48GB или больше, посмотрите мою статью про стратегии масштабирования локальных LLM. Там разбираем, как объединить несколько карт для действительно больших моделей.

←
На главную