Как я выбирал локальную модель для кодинга на 16 ГБ VRAM — и трижды менял победителя

Сначала я выбрал модель, которая отлично писала код. Подключил её к OpenCode и выяснил, что создавать файлы на диске она просто не умеет. Взял другую — та уверенно работала с файлами, но полностью поплыла на русском языке.

​В итоге победила модель, которую я поначалу оставил «для экспериментов»: слишком большая, на грани по квантованию и, казалось, сплошной компромисс.

​Ниже — о том, как я подбирал рабочую лошадку под WordPress и фронтенд на видеокарте с 16 ГБ памяти. Со скоростями, квантами и неожиданным экзаменом по русскому языку.

Для каких задач я её искал

Я занимаюсь WordPress‑разработкой. Мой повседневный набор — PHP, HTML, CSS, JavaScript, интеграция вёрстки и работа с блоками Gutenberg.

От локальной модели мне нужны были вполне конкретные вещи: прочитать существующий код, внести правки, создать нужные файлы и соблюдать правила проекта. В том числе писать по‑русски названия полей, которые потом увидит человек в админке.

Работать я собирался через OpenCode, поэтому одного умения хорошо писать код было недостаточно: нужны были ещё вызовы инструментов, нормальный русский и скорость, при которой не забываешь, о чём спрашивал. И всё это должно было помещаться в 16 ГБ вместе с контекстом.

В контексте ещё должны жить инструкции, исходники, переписка и результаты вызова инструментов. Если модель загрузилась в видеопамять, это ещё не значит, что там осталось место для её полноценной работы.

Качество я оценивал по своим рабочим задачам, а скорость и память замерял на таком компьютере:

Гонять модель на абстрактных задачах вроде «напиши функцию сортировки» не имело смысла — синтетические тесты ничего не говорят о реальной работе.

Задача стояла вполне прикладная: превращать готовую HTML‑вёрстку в блоки Gutenberg через Carbon Fields, в рамках моего базового плагина для блоков. Модель должна была разобраться в структуре, разложить PHP по нужным файлам, подключить блок и задать осмысленные подписи к полям в админке на русском языке.

Первый этап: скачать всё, что посоветовали нейросети

Список кандидатов я собирал через ChatGPT, Claude и DeepSeek: спрашивал, что из кодинг‑моделей реально влезет в 16 ГБ, и скачивал варианты. Получилась небольшая коллекция:

Модели на 3–8 миллиардов параметров я не стал подробно сравнивать как кандидатов на основную роль. Но одну 7B оставил для мелких задач: иногда нужно поправить небольшой фрагмент, и для этого необязательно запускать самого тяжёлого участника.

Для тех, кто пока не запомнил все эти индексы: квантование уменьшает точность хранения весов модели и позволяет экономить память. Q4, Q5 и Q8 — обозначения разных вариантов такого сжатия. Обычно меньший размер означает больший компромисс по качеству, но сравнивать модели только по цифре после Q нельзя.

У Qwen3-Coder есть ещё обозначение A3B. Это MoE‑модель: всего у неё около 30 миллиардов параметров, а при обработке токена активируется примерно 3 миллиарда. Это снижает объём вычислений, но не превращает её в трёхмиллиардную модель по требованиям к хранению весов. Точные характеристики есть в карточке Qwen3-Coder.

REAP — отдельная история. Это версия исходной модели, уменьшенная за счёт удаления части экспертов. То есть здесь меняется состав модели, а квантование уже применяется поверх неё. Метод описан в карточке Cerebras

Вместо «вроде быстро» — скрипт с замерами

На коротких вопросах модель отвечает быстро, но стоит скормить ей побольше кода — начинает заметно тормозить. По таким впечатлениям выбирать было сложно.

С помощью ChatGPT я написал PowerShell‑скрипт для тестирования через llama-server.exe. Он последовательно прогонял несколько размеров контекста, снимал использование видеопамяти через nvidia-smi и сохранял результаты.

Поэтому задачу я поставил предельно конкретно: нужны реальные цифры — сколько токенов вошло, сколько памяти занято после загрузки, сколько на пике и с какой скоростью всё работает. Общее понимание у меня уже сложилось, а единой таблицы для сравнения ещё не было.

Скорость смотрел отдельно на чтении входного текста (prefill) и на генерации ответа (generation). Заодно следил, сколько свободной VRAM остаётся на пике нагрузки.

Размер файла модели на диске при этом не равен расходу VRAM. Помимо весов, память нужна под рабочие буферы и KV‑кеш — данные, которые используются при обработке контекста.

В выводе скрипта были отдельные колонки Context и PromptTokens. Первая — настроенный размер окна, вторая — фактическое число входных токенов. В финальном тесте на 32K вход занимал 29 491 из 32 768 токенов, а в следующем прогоне на 48K — 44 236 из 49 152. В обоих случаях это примерно 90% окна: проверялась работа с реально длинным запросом, а не короткое «привет» при большом значении в настройках.

Просто скачать подходящий по весу GGUF и загрузить его в память — лишь половина дела. Реальный стресс‑тест начинается при забитом под завязку окне.

Первый победитель: Qwen2.5-Coder-14B Q5

7B в Q8 осталась для быстрых небольших задач. Полная Qwen3-Coder-30B в Q3 — для экспериментов. REAP 25B в Q4 — как перспективный кандидат.

Основной моделью я выбрал Qwen2.5-Coder-14B в Q5. Она устраивала меня по размеру и качеству кода. Казалось бы, идеальный баланс найден — на этом можно было ставить точку.

Заодно почистил коллекцию.

DeepSeek‑Coder‑V2-Lite у меня работала аномально медленно. Почему — так и не разобрался. Другие кандидаты уже работали лучше, поэтому её удалил.

Phi-4 тоже убрал. Это универсальная 14B‑модель с заявленным контекстом 16K, а я искал помощника под конкретный процесс разработки. Её характеристики можно посмотреть в карточке Microsoft. Среди уже отобранных вариантов я не нашёл задачи, ради которой стоило держать ещё и её.

Забить диск гигабайтами GGUF под любые кванты легко. Гораздо труднее получить инструмент, которому не страшно доверить реальный проект.

Подключаю OpenCode — и меняю победителя

Подключил выбранную Qwen2.5-Coder-14B к OpenCode. И довольно быстро пожалел, что не сделал этого раньше.

На просьбу создать или отредактировать файл модель могла вывести JSON в чат и остановиться. Текст есть. Изменений в проекте нет.

До подключения агента я оценивал, какой код она предлагает. Теперь критерий стал предельно простым: создан запрошенный файл в проекте или нет?

В агентском сценарии модель должна корректно запросить вызов инструмента, получить результат и продолжить работу. Просто написать похожий на вызов JSON недостаточно.

С вызовами инструментов должны сойтись модель, шаблон чата, сервер и клиент — у llama.cpp про это есть отдельная документация. В моей связке надёжно это не заработало.

А вот Qwen3-Coder‑REAP-25B‑A3B подхватила задачи OpenCode заметно лучше. Она выполняла команды, работала с файлами и хорошо справлялась с кодом. При этом в Q4 оставалось место для контекста до 32K.

Казалось, идеальный кандидат наконец найден: код пишет, команды агента выполняет, по памяти запас есть. Поиски окончены — теперь уже наверняка.

Второй фаворит засыпался на русском языке

В моих блоках Gutenberg нужны русские названия полей. Это часть интерфейса: пользователь должен видеть понятные подписи в админке.

Я не просил модель писать художественную прозу. Мне нужны были подписи к полям Carbon Fields. Казалось бы, если модель осилила бэкенд на PHP, с обычным русским текстом проблем быть не должно.

И именно здесь у REAP начались проблемы. Добиться стабильно чистого русского в заголовках не получалось. Я уточнял инструкции, добавлял правила и запреты, но результат всё равно меня не устраивал.

Код модель писала. Инструменты вызывала. А на подписях полей мы застряли.

Переписывать подписи после каждого запуска мне не хотелось.

Я вернулся к полной Qwen3-Coder-30B‑A3B‑Instruct в Q3. Она сразу отработала промпт и выдала нормальные русские заголовки.

Осталось договориться с видеопамятью.

Q3 бывает очень разным

У полной 30B‑модели в моей первоначальной конфигурации получалось работать примерно с 24K контекста. Хотелось больше.

Особенно наглядным оказался тест обычного Q3_K_M:

На 32K скорость упала примерно в сорок раз. При полутора токенах в секунду работать я уже не хотел — пришлось искать другой вариант.

Тогда я попробовал ещё два варианта квантования от Unsloth:

Размеры указаны для файлов в репозитории Unsloth. Это гигабайты файла на диске, а не замеры занятой видеопамяти.

Сначала я больше склонялся к UD-Q3_K_XL: он экономил память относительно Q3_K_M, при этом выглядел менее радикальным компромиссом, чем вариант с названием IQ3_XXS.

Но после прошлых тестов полагаться только на буквы в названии файла я уже не стал.

Финальный замер: почти одинаковая скорость, разный запас памяти

Вот результаты двух запусков с настроенным контекстом 32 768 токенов и входом 29 491 токен:

77 MiB — это просто прирост от загрузки до пика, но эта разница не показывает полный расход на контекст: LoadedMB я замерял уже после запуска сервера с выбранными настройками. В таблице показана занятая память карты, включая всё, что разместилось там помимо весов.

По скорости генерации для меня это ничья: 42,32 и 42,04 токена в секунду.

А вот запас памяти различался существенно: у UD-IQ3_XXS оставалось на 872 MiB больше — 1 517 против 645. Более чем вдвое больше свободного места при практически одинаковой скорости генерации.

Разницы в качестве кода на своих задачах я тоже не заметил. Отдавать за UD-Q3_K_XL почти ещё гигабайт памяти не имело никакого смысла.

А если всё‑таки попробовать 48K?

Конечно, на этом всё не закончилось: когда на карте пустуют полтора гигабайта, сразу хочется выжать из них максимум.

Вот что получилось на 48K:

48K прошёл, но свободными остались всего 374 MiB. Генерация — 22,68 токена/с, почти вдвое медленнее, чем 42,32 у UD-IQ3_XXS на 32K.

Попытка замахнуться на контекст в 65K закономерно упала с ошибкой. Так что идея выжать честные 64K так и осталась слишком оптимистичным сценарием.

Для повседневной работы я остановился на 32K: около 42 токенов в секунду и заметный запас памяти. До 48K добраться удалось, но оставлять всего 374 MiB свободной VRAM для постоянной работы я не стал.

Основным инструментом в итоге стала:

Qwen3-Coder-30B-A3B-Instruct-UD-IQ3_XXS.gguf

Название размером с терминальную команду. Зато она работает с инструментами OpenCode, справляется с моими задачами по WordPress и фронтенду и пишет русские подписи, с которыми мы застряли на REAP. Это полная версия модели, без удаления экспертов, хотя и с сильным квантованием. На 32K после всего этого остаётся 1 517 MiB — около 1,48 GiB видеопамяти.

С чего я начинал бы тесты сеодня

Поначалу я ориентировался на качество кода в ответах чата, а проверять надо было реальную работу с агентом.

Теперь я бы сразу давал кандидату маленькую, но законченную рабочую задачу: прочитать файл, внести изменение через инструмент, создать нужный код и написать русские подписи. А уже прошедшим этот этап измерял скорость и доступный контекст.

Qwen2.5-Coder-14B устраивала по коду, но не заработала как нужно в моей агентской связке. REAP хорошо работала через OpenCode, но не устроила меня по русским подписям. Полная Qwen3-Coder устроила и по качеству генерации, и по интеграции в агентский пайплайн, однако потребовала перебора квантований.

Именно поэтому итоговый выбор оказался менее очевидным, чем «возьми модель побольше в Q4».

Параллельно с выбором модели я дорабатывал инструкции: объяснял, как устроен плагин и каким должен получиться блок. Правил постепенно набралось прилично.

В итоге рабочий промпт для блока разросся больше чем до 400 строк. Блок встал без ошибок, но тут же возник вопрос: где заканчиваются полезные правила проекта и начинается скрипт, который я почему‑то написал словами? С моделью определился, теперь разбираюсь с этим.

Теперь под Qwen3-Coder-30B я планирую и дальнейший апгрейд: рассматриваю вторую видеокарту с 16 ГБ, чтобы попробовать Q4–Q5 и более широкий контекст. Насколько удачным получится такой запуск на двух GPU — но это уже совсем другая история и отдельный объём тестов.

Дальше хочу так же разобрать модели общего назначения и vision‑модели, которые работают с изображениями. Но это следующие истории.

Изначально план был простой: выбрать модель под имеющуюся видеокарту. В итоге выбрал модель и начал присматривать ей вторую.

О таких экспериментах, разработке на WordPress и жизни между задачами пишу в канале «Вла'д Лебедкин | Stack & Life». Заглядывайте, если интересно, как локальные сетки уживаются с разработчиком и 16 ГБ видеопамяти.