Поиск локальной модели для кодинга на 16 ГБ VRAM: три провала и один неожиданный выбор
Автор статьи Владислав Лебедкин делится опытом подбора локальной нейросети для задач разработки на WordPress и фронтенде. Работая с видеокартой RTX 5060 Ti 16 ГБ, он прошел путь от популярной 14-параметровой модели до мощной 30-параметровой версии Qwen, научившись балансировать между качеством кода, пониманием русского языка и утилитарными возможностями агентов.
# Как выбрать локальную модель для кодинга на 16 ГБ VRAM: опыт подбора рабочей лошадки
Работа с локальными Large Language Models (LLM) часто сводится к постоянному поиску баланса между мощностью модели, скоростью обработки и доступной памятью видеокарты. Для разработчика, использующего связку OpenCode и локальный сервер, этот баланс критически важен. На примере конфигурации на базе видеокарты NVIDIA GeForce RTX 5060 Ti (16 ГБ VRAM) и процессора AMD Ryzen 5 5600 мы рассмотрим процесс выбора модели, способной не только писать код, но и корректно работать с файловыми инструментами и русским языком.
Почему стандартные тесты вводят в заблуждение
Оценка способности модели писать код на абстрактных задачах вроде «напиши функцию сортировки» является бесполезным упражнением. Синтетические тесты не отражают реальную рабочую нагрузку, которой занимается разработчик. В случае с веб-разработкой и работой с CMS (в данном примере — WordPress), ключевыми задачами становятся: * Чтение существующих файлов и внесение правок. * Создание новых файлов проекта. * Работа с инструментами агентов (например, вызов API для создания блоков Gutenberg). * Написание понятных русскоязычных подписей к полям админки.
Все эти операции должны выполняться в контексте, который включает исходный код, инструкции проекта и логи переписки, не выходя за пределы физических ограничений видеопамяти.
Квантование: краткое объяснение
Для экономии видеопамяти веса моделей сжимают методом квантования. Цифры после буквенного обозначения (Q4, Q5, Q8) указывают на точность хранения весов: чем меньше цифра, тем меньше памяти требуется, но тем выше вероятность потери качества. * MoE (Mixture of Experts): Некоторые модели, такие как Qwen3-Coder, используют архитектурные уловки. Например, модель размером 30 миллиардов параметров (30B) может активировать лишь часть экспертов (например, 3 миллиарда параметров, A3B) при генерации одного токена. Это снижает вычислительную нагрузку, но требует полного объема памяти для хранения весов всей модели.
Эволюция выбора: от 14B до 30B параметров
Автор статьи последовательно менял лидеров, проходя три стадии отсева неэффективных решений.
Этап 1: Первая неудача — Qwen2.5-Coder-14B
На начальном этапе был выбран вариант Qwen2.5-Coder-14B в квантовании Q5. Модель показалась отличным балансом размера и качества кода, уверенно помещаясь в 16 ГБ памяти. Однако при подключении к агентскому пайплайну OpenCode обнаружилась критическая проблема: модель генерировала JSON-структуры для работы с файлами, но фактически не могла создать или отредактировать файлы на диске. Она просто выдавала результат в чат, игнорируя вызовы инструментов. Это сделало модель непригодной для автоматизированной разработки.
Этап 2: Второе поражение — Qwen3-Coder-REAP-25B-A3B
В качестве альтернативы была рассматривана модель Qwen3-Coder-REAP-25B-A3B. Версия REAP (Reduced Experts And Pruned) создана путем удаления части экспертов для оптимизации. В квантовании Q4 эта модель помещалась в память с запасом до 32K контекста и отлично справлялась с вызовами агентов OpenCode.
Однако при тестировании на реальных задачах WordPress возникла языковая проблема. Несмотря на то, что код писался корректно, модель не могла генерировать русскоязычные подписи для полей административной панели. Попытки уточнить инструкции и добавить запреты не привели к стабильному результату. Для интерфейса, ориентированного на человека, отсутствие качественного русского языка стало фатальным недостатком.
Этап 3: Победитель — Qwen3-Coder-30B-A3B в квантовании UD-IQ3_XXS
Вернувшись к базовой версии модели Qwen3-Coder-30B-A3B-Instruct, авторы столкнулись с проблемой объема. Полная модель в стандартном квантовании Q3 (Q3_K_M) потребляла много памяти, позволяя использовать всего 24K контекста со скоростью генерации 1,57 токена/с (при настройке на 32K), что было неприемлемо медленно.
Решением стало использование специализированных квантований от проекта Unsloth. Сравнивались три варианта: * Q3_K_M: 14,7 ГБ на диске, низкая эффективность памяти. * UD-Q3_K_XL: 13,8 ГБ, умеренный компромисс. * UD-IQ3_XXS: 12,8 ГБ, наиболее радикальное сжатие.
Финальный тест на 32K контексте показал, что UD-IQ3_XXS оставал больше всего свободной видеопамяти (около 1,5 ГБ) при генерации со скоростью 42 токена/с. Это обеспечивало необходимый запас для обработки длинных контекстов и вызовов инструментов. Хотя модель на 32K работала на скорости 42 токена/с, попытка растянуть контекст до 48K снижала скорость почти вдвое (до 22,68 токена/с) и оставляла всего 374 МБ свободного места, что было признано рискованным для стабильной работы.
Итоговые рекомендации по настройке
В качестве окончательного решения для задачи разработки на WordPress и фронтенде с использованием агентов была выбрана связка: * Модель: Qwen3-Coder-30B-A3B-Instruct * Формат: DD-IQ3_XXS (квантование Unsloth) * Контекстное окно: 32 768 токенов * Остаток памяти: ~1,5 ГБ при пиковой нагрузке
Этот выбор позволил решить все три критерия одновременно: качественная генерация кода, корректная работа с файлами через OpenCode и поддержка русского языка для интерфейса.
С чего начать выбор модели в будущем?
Опыт показывает, что ориентироваться сначала на качество ответов в чате — ошибка. При выборе модели стоит сразу тестировать ее на законченной рабочей задаче: прочитать файл, внести изменение через инструмент, создать новый код и написать русские подписи. Лишь после прохождения этого практического экзамена имеет смысл измерять скорость генерации и доступность контекста. В идеале, рабочий промпт для сложных задач может вырасти до 400 строк, что требует от модели не только интеллекта, но и внимательности к инструкциям.