Сначала я выбрал модель, которая отлично писала код. Подключил её к OpenCode и выяснил, что создавать файлы на диске она просто не умеет. Взял другую — та уверенно работала с файлами, но полностью поплыла на русском языке.
В итоге победила модель, которую я поначалу оставил «для экспериментов»: слишком большая, на грани по квантованию и, казалось, сплошной компромисс.
Ниже — о том, как я подбирал рабочую лошадку под WordPress и фронтенд на видеокарте с 16 ГБ памяти. Со скоростями, квантами и неожиданным экзаменом по русскому языку.
Для каких задач я её искал
Я занимаюсь WordPress‑разработкой. Мой повседневный набор — PHP, HTML, CSS, JavaScript, интеграция вёрстки и работа с блоками Gutenberg.
От локальной модели мне нужны были вполне конкретные вещи: прочитать существующий код, внести правки, создать нужные файлы и соблюдать правила проекта. В том числе писать по‑русски названия полей, которые потом увидит человек в админке.
Работать я собирался через OpenCode, поэтому одного умения хорошо писать код было недостаточно: нужны были ещё вызовы инструментов, нормальный русский и скорость, при которой не забываешь, о чём спрашивал. И всё это должно было помещаться в 16 ГБ вместе с контекстом.
В контексте ещё должны жить инструкции, исходники, переписка и результаты вызова инструментов. Если модель загрузилась в видеопамять, это ещё не значит, что там осталось место для её полноценной работы.
Качество я оценивал по своим рабочим задачам, а скорость и память замерял на таком компьютере:
Компонент | Моя конфигурация |
|---|---|
Видеокарта | GIGABYTE GeForce RTX 5060 Ti WINDFORCE MAX OC, 16 ГБ |
Память GPU в диагностике |
|
Процессор | AMD Ryzen 5 5600 |
Оперативная память | 32 ГБ |
Среда | Windows, |
Пакет CUDA runtime |
|
Агент для работы с проектом | OpenCode |
Гонять модель на абстрактных задачах вроде «напиши функцию сортировки» не имело смысла — синтетические тесты ничего не говорят о реальной работе.
Задача стояла вполне прикладная: превращать готовую HTML‑вёрстку в блоки Gutenberg через Carbon Fields, в рамках моего базового плагина для блоков. Модель должна была разобраться в структуре, разложить PHP по нужным файлам, подключить блок и задать осмысленные подписи к полям в админке на русском языке.
Первый этап: скачать всё, что посоветовали нейросети
Список кандидатов я собирал через ChatGPT, Claude и DeepSeek: спрашивал, что из кодинг‑моделей реально влезет в 16 ГБ, и скачивал варианты. Получилась небольшая коллекция:
Модель | Какие варианты пробовал | Первое впечатление |
|---|---|---|
Qwen Coder 7B семейства 2.5 | Q4, Q8 | Подходит для небольших задач, в Q8 хорошо помещается |
Qwen2.5-Coder-14B‑Instruct | Q4, Q5 | Хороший баланс размера и качества |
Qwen3-Coder-30B‑A3B‑Instruct | Q4, Q3 | Q4 не помещался целиком в VRAM; Q3 оказался интереснее, чем я ожидал |
Qwen3-Coder‑REAP-25B‑A3B | Q4 | Помещается с контекстом до 32K в моей конфигурации |
DeepSeek‑Coder‑V2-Lite‑Instruct | Q4, Q5 | Аномально медленная работа в моих запусках |
Phi-4 | — | Отдельной роли в коллекции не нашлось |
Модели на 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:
Настроенный контекст | Генерация |
|---|---|
16K | 63,8 токена/с |
32K | 1,57 токена/с |
На 32K скорость упала примерно в сорок раз. При полутора токенах в секунду работать я уже не хотел — пришлось искать другой вариант.
Тогда я попробовал ещё два варианта квантования от Unsloth:
Вариант Qwen3-Coder-30B‑A3B‑Instruct | Размер файла, примерно |
|---|---|
| 14,7 ГБ |
| 13,8 ГБ |
| 12,8 ГБ |
Размеры указаны для файлов в репозитории Unsloth. Это гигабайты файла на диске, а не замеры занятой видеопамяти.
Сначала я больше склонялся к UD-Q3_K_XL: он экономил память относительно Q3_K_M, при этом выглядел менее радикальным компромиссом, чем вариант с названием IQ3_XXS.
Но после прошлых тестов полагаться только на буквы в названии файла я уже не стал.
Финальный замер: почти одинаковая скорость, разный запас памяти
Вот результаты двух запусков с настроенным контекстом 32 768 токенов и входом 29 491 токен:
Метрика | UD‑IQ3_XXS | UD‑Q3_K_XL |
|---|---|---|
VRAM после загрузки, MiB* | 14 717 | 15 605 |
Пиковая VRAM, MiB* | 14 794 | 15 666 |
Прирост от загрузки до пика, MiB* | 77 | 61 |
Свободно на пике, MiB* | 1 517 | 645 |
Обработка входа, токенов/с | 1 863,13 | 1 718,98 |
Генерация, токенов/с | 42,32 | 42,04 |
77 MiB — это просто прирост от загрузки до пика, но эта разница не показывает полный расход на контекст: LoadedMB я замерял уже после запуска сервера с выбранными настройками. В таблице показана занятая память карты, включая всё, что разместилось там помимо весов.
По скорости генерации для меня это ничья: 42,32 и 42,04 токена в секунду.
А вот запас памяти различался существенно: у UD-IQ3_XXS оставалось на 872 MiB больше — 1 517 против 645. Более чем вдвое больше свободного места при практически одинаковой скорости генерации.
Разницы в качестве кода на своих задачах я тоже не заметил. Отдавать за UD-Q3_K_XL почти ещё гигабайт памяти не имело никакого смысла.
А если всё‑таки попробовать 48K?
Конечно, на этом всё не закончилось: когда на карте пустуют полтора гигабайта, сразу хочется выжать из них максимум.
Вот что получилось на 48K:
Метрика | Прогон на 48K |
|---|---|
Настроенный контекст | 49 152 токена |
Фактический вход | 44 236 токенов |
VRAM после загрузки | 15 878 MiB |
Пиковая VRAM | 15 937 MiB |
Прирост от загрузки до пика | 59 MiB |
Свободно на пике | 374 MiB |
Обработка входа | 1 419,72 токена/с |
Генерация | 22,68 токена/с |
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 ГБ видеопамяти.
