128 ГБ ОЗУ на Strix Halo: какие модели для кодирования реально работают, а какие — маркетинг

128 ГБ ОЗУ — это не про комфорт, это про возможность

Когда вы видите ноутбук с 128 ГБ ОЗУ на AMD Strix Halo, первая мысль — "наконец-то можно запустить что-то серьезное". Вторая мысль — "а что именно?".

Потому что оперативка есть, но вот архитектура Strix Halo — это не 128 ГБ видеопамяти на RTX 6000. Разница колоссальная. Пропускная способность памяти, латентность, скорость матричных операций — все это влияет на то, какие модели будут летать, а какие будут еле ползать.

Почему 30B-100B параметров — золотая середина для кодирования

Модели до 8B параметров — это для чата и простых задач. Модели от 200B — это для кластеров. А вот диапазон 30B-100B — именно то, что нужно для серьезного кодирования на локальной машине.

Почему? Потому что эти модели:

• Достаточно умны для сложных архитектурных решений
• Помнят контекст в 128K+ токенов (важно для больших проектов)
• Умеют работать с несколькими файлами одновременно
• Их можно тонко настроить под ваш стек технологий
• Они влезают в 128 ГБ ОЗУ (после правильного квантования)

Топ-5 моделей для Strix Halo: не верить бенчмаркам, верить практике

Все бенчмарки в интернете делаются на идеальном железе. На практике на Strix Halo с 128 ГБ ОЗУ все работает иначе. Вот что реально летает:

1. DeepSeek-Coder-V3-70B-Instruct (Q4_K_M GGUF)

На январь 2026 года — это король локального кодирования. Не путать с DeepSeek-Coder-V2 — третья версия получила серьезные улучшения в понимании контекста и работе с длинными файлами.

Почему GGUF, а не AWQ? Потому что на чистой оперативке (без быстрой видеопамяти) GGUF с llama.cpp работает стабильнее. AWQ оптимизирован под NVIDIA GPU с tensor cores, а у Strix Halo их нет.

2. Qwen2.5-Coder-32B-Instruct (Q6_K GGUF)

Если DeepSeek слишком медленный для ваших задач — берите Qwen2.5. На январь 2026 это самая быстрая 32B-модель для кодирования. Особенно хороша для Python и веб-разработки.

Q6_K квантование — это компромисс между качеством и скоростью. На Strix Halo разница между Q4_K_M и Q6_K в скорости всего 15-20%, но качество кода заметно лучше.

3. CodeLlama-70B-Python (IQ3_XS GGUF)

Да, модель 2023 года, но до сих пор одна из лучших для Python. IQ3_XS — это новый формат квантования 2025 года, который дает почти такое же качество как Q4_K_M, но на 25% меньше размер.

На Strix Halo это важно — меньше размер модели = меньше операций с памятью = выше скорость. CodeLlama-70B в IQ3_XS занимает всего ~38 ГБ вместо ~45 ГБ у DeepSeek в Q4_K_M.

4. Magicoder2-30B-SC-Instruct (Q5_K_M GGUF)

Специально обучена на синтетических данных для кодирования. На январь 2026 — лучшая 30B-модель для multi-language проектов (Python, JavaScript, Go, Rust в одном проекте).

На Strix Halo дает 20-25 токенов/сек — это уже комфортная скорость для работы в реальном времени. Потребляет всего ~22 ГБ ОЗУ в Q5_K_M.

5. StarCoder2-30B-Instruct (Q4_K_M GGUF)

Если работаете с GitHub-проектами — эта модель понимает контекст лучше других. Обучена на лицензионных данных, можно использовать в коммерческих проектах без страха нарушить лицензии.

Квантование — это не "какой коэффициент выбрать", а "какой формат не сломает модель"

Все говорят про Q4_K_M, Q6_K, но мало кто понимает, как квантование влияет на способность модели писать код. А влияет сильно.

Вот простая таблица, которая сэкономит вам недели экспериментов:

Золотое правило для Strix Halo: для 70B моделей — только Q4_K_M или IQ3_XS. Для 30B-32B моделей можно Q5_K_M, если готовы ждать.

Тонкая настройка на Strix Halo: можно, но нужно ли?

У вас 128 ГБ ОЗУ, значит теоретически можно делать тонкую настройку (fine-tuning) прямо на ноутбуке. Практически — это боль и страдания.

Почему? Потому что Strix Halo — мобильный чип. Да, у него много ядер, но:

• Нет tensor cores для ускорения обучения
• Тепловыделение ограничено (ноутбук же)
• Оперативка быстрая, но не настолько быстрая как HBM на профессиональных GPU

Что МОЖНО делать на Strix Halo:

1. LoRA для 7B-13B моделей — быстро, не греется, влезает в память
2. QLoRA для 30B моделей — медленно (сутки на небольшом датасете), но возможно
3. Дообучение на код-ревью — маленькие датасеты, быстрый результат

Что НЕЛЬЗЯ делать на Strix Halo:

1. Full fine-tuning 70B моделей — технически возможно, но займет недели
2. Обучение с нуля — даже не думайте
3. Обучение на больших датасетах (100K+ примеров) — ноутбук превратится в грелку

Если серьезно хотите заниматься тонкой настройкой — посмотрите сравнение Strix Halo и RTX 5080. Для обучения все же лучше отдельная видеокарта.

Оптимизация под 128 ГБ: как выжать максимум без магии

Шаг 1: Настройка llama.cpp для Strix Halo

# Компиляция с оптимизациями под Zen 5 (ядро Strix Halo)
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make LLAMA_CPU_AVX512=1 LLAMA_BLAS=1 LLAMA_BLAS_VENDOR=OpenBLAS -j32

Ключевые флаги:

• LLAMA_CPU_AVX512=1 — использует AVX-512 инструкции Zen 5
• LLAMA_BLAS=1 — ускоряет матричные операции
• -j32 — использует все 32 потока Strix Halo

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

./main -m ./models/deepseek-coder-v3-70b-q4_k_m.gguf \
  -t 30 \  # 30 потоков, 2 оставляем для системы
  -c 131072 \  # полный контекст 128K
  -b 512 \  # размер batch для ускорения
  -ngl 0 \  # все в оперативку, видеопамяти нет
  --mlock \  # фиксируем модель в RAM
  --no-mmap \  # не используем mmap для стабильности
  -p "[INST] Напиши функцию на Python для..."

Шаг 3: Мониторинг и настройка

Установите htop и следите за:

• Использование оперативки (не должно быть свопа)
• Температура CPU (должна быть стабильной)
• Загрузка потоков (все ядра должны работать)

Распространенные ошибки (и как их избежать)

Ошибка 1: Брать самую большую модель

"У меня 128 ГБ, значит возьму 100B модель!" — звучит логично, но работает плохо. 100B модель в Q4_K_M займет ~60 ГБ, но скорость будет 2-3 токена в секунду. Бесполезно для работы.

Ошибка 2: Использовать AWQ вместо GGUF

AWQ форматы оптимизированы под NVIDIA GPU. На чистом CPU (даже таком мощном как Strix Halo) GGUF работает быстрее и стабильнее. Не ведитесь на маркетинг.

Ошибка 3: Не настраивать количество потоков

По умолчанию llama.cpp использует все ядра. На Strix Halo это 32 потока. Но системе тоже нужны ресурсы. Ставьте -t 28 или -t 30, оставляйте 2-4 потока для ОС.

Ошибка 4: Работать без мониторинга температуры

Strix Halo под нагрузкой греется. Если температура превышает 95°C — система начнет троттлить. Установите sensors и следите. Или используйте ограничение частоты через Ryzen Adj.

Что будет через год? (прогноз на 2027)

На январь 2026 Strix Halo с 128 ГБ ОЗУ — это топ для локального кодирования. Но технологии не стоят на месте.

Что изменится к 2027:

• Модели станут эффективнее — те же 70B параметров, но лучше качество
• Появятся специализированные кодеры 50B — золотая середина между скоростью и качеством
• Квантование IQ4_XS станет стандартом — качество Q4_K_M при размере Q3_K_S
• Интеграция с IDE станет нативной — не через плагины, а прямо в ядро редакторов

Но главное — появятся гибридные схемы, где тяжелые вычисления делаются на eGPU, а инференс — на Strix Halo. Это изменит правила игры.

Вопросы, которые задают чаще всего

Можно ли запустить две модели одновременно?

Технически — да. Практически — нет. 70B модель занимает 45 ГБ, вторая 70B — еще 45 ГБ, итого 90 ГБ. Остается 38 ГБ на систему, кэш, IDE. Будет работать, но с оговорками:

• Скорость каждой упадет в 2 раза
• Возможны перегревы
• Система будет менее отзывчивой

Лучше запускать одну модель, но использовать ее для всех задач.

Стоит ли обновлять биос/драйверы для работы с LLM?

Обязательно. На январь 2026 уже вышли оптимизации под AI-нагрузки:

• Биос с улучшенным управлением питанием
• Драйверы чипсета с оптимизациями для матричных операций
• Обновления микрокода процессора

Без обновлений можете терять 15-20% производительности.

Какой IDE плагин лучше для локальных моделей?

На январь 2026 лидер — Continue.dev с поддержкой локальных моделей через llama.cpp. Из бесплатных — Cursor с ручной настройкой эндпоинта. Не используйте плагины, которые требуют GPU — они не заработают на Strix Halo.

Что делать, если модель "забывает" синтаксис?

Это проблема квантования. Решения:

1. Перейти на менее агрессивное квантование (с Q4_K_M на Q5_K_M)
2. Использовать промпты с примерами синтаксиса
3. Взять другую модель (не все одинаково устойчивы к квантованию)
4. Попробовать новый формат IQ3_XS — он лучше сохраняет знания

Если интересны детали оптимизации памяти под разные модели — посмотрите отдельный гайд по оптимизации ОЗУ.