Что именно тестировали и зачем это вам
Разработчик с 20-летним опытом прогнал две локальные open-weight модели, Gemma4-31B и Qwen3.8-27B, в одинаковой квантизации Q4 от Unsloth на двух задачах разработки: разбор незнакомого репозитория и создание нового проекта на C# с WPF-фронтендом. Для контрольной точки тот же промпт на создание проекта отдали фронтирной модели GPT 6.1-Sol.
Результат в двух строках. В анализе кода обе модели дали сопоставимо качественные ответы, но Gemma4 уложилась примерно в 10 обращений к серверу против 20-30 у Qwen. На создании проекта Gemma4 быстро выдала результат уровня B-, Qwen3.8 наделала больше мелких ошибок, зато после одной итерации правок довела код до B+, а GPT 6.1-Sol с первого прохода выдал A+.
Практический вывод: локальные модели на потребительском железе уже дают рабочий код, но в одну лигу с фронтиром не встают. Оценки B-, B+ и A+ субъективны, их выставил автор теста на основе своего опыта, а не автоматический бенчмарк.
Условия теста: модели, квантизация, инструменты
Обе модели запускались в одной и той же квантизации Q4, вариант Unsloth, поэтому сравнение не сводится к спору «одну сжали сильнее другой». Gemma4-31B содержит 31 млрд параметров, Qwen3.8-27B - 27 млрд. Разница в 4 млрд на бумаге выглядит небольшой, но при одинаковой схеме квантования она прямо отражается на весе файла и на требованиях к видеопамяти.
Запуск шёл через harness'ы Codex CLI и OpenCode CLI. Автор теста признал различия между ними незначительными и в итоговых оценках их не учитывал. Тестирование проводилось на потребительском оборудовании, а не на серверных ускорителях, что заранее ограничивает перенос выводов на промышленные конфигурации.
Это не лабораторный бенчмарк с фиксированными сидами и прогонами на десятках задач. Практический прогон на двух типах работ, где оценивалась пригодность кода к реальному использованию. Оценки выставлял человек, и они отражают его рабочие привычки. Подробности автор описал в наблюдениях в сообществе r/LocalLLaMA.
Сколько VRAM понадобится: арифметическая прикидка
Q4 означает примерно 4-5 бит на вес. По этой арифметике веса 31B-модели занимают около 17-19 ГБ, веса 27B-модели - около 15-17 ГБ, к ним добавляется KV-кеш, который растёт вместе с длиной контекста. Отсюда практический ориентир: карта на 24 ГБ под 31B и 16 ГБ плюс запас под 27B, если контекст небольшой. Это расчёт по битам на вес, а не измерение конкретной сборки, фактический расход зависит от контекста, типа KV-кеша и оверхеда рантайма.
Как выбор провайдера и формата квантизации меняет качество на коде и диалоге, разобрано в отдельном материале про сравнение сборок Qwen и Gemma для кодинга и общения. Реальный расход VRAM на слабой карте виден в тесте Qwen3.8 27B IQ3_XXS против Bonsai Ternary PQ2, где обе модели влезли в 16 ГБ.
Анализ незнакомого репозитория: обе хороши, но Gemma4 эффективнее
Промпт был намеренно узким, чтобы модели не расползались в сторону: разобрать конкретную библиотеку, её ключевые абстракции и связи между ними, уложившись в лимит объёма.
Read-only pass, tell me about such-and-such library, its core abstractions... Keep it under 900 words.
Обе модели дали одинаково качественные разборы. Разница обнаружилась в процессе, а не в тексте ответа. Gemma4 решала задачу заметно экономнее: около 10 обращений к серверу против 20-30 у Qwen, разброс зависит от harness. Меньше обращений означает меньше времени на ответ и меньше нагрузки на железо при том же результате.
Обратная сторона нашлась у Qwen. Модель проявила больше любопытства и инициативы, чем требовал запрос, копнула глубже и собрала чуть более полную картину происходящего в коде. Если стоит цель понять чужой проект целиком, а не получить выжимку по конкретному вопросу, такая инициативность полезна.
Итог по этой задаче простой. Обе модели пригодны для чтения незнакомого кода. Gemma4-31B выигрывает, когда важны скорость и минимум накладных расходов, Qwen3.8-27B - когда нужна глубина и дополнительные детали за пределами явного запроса.
Создание нового проекта на C# с WPF: скорость против настойчивости
Вторая задача сложнее. Промпт на восемь абзацев описывал приложение на C# с переиспользуемым бэкендом и WPF-фронтендом. Автор оценил объём работы вручную в один-два дня.
Gemma4-31B быстро спланировала структуру и так же быстро выполнила задачу. Итоговый результат автор оценил в B-: код рабочий, но сырой и требует доработки перед реальным использованием.
Qwen3.8-27B шла по проекту с большим числом мелких ошибок, среди них пропущенные using и другие дефекты сборки. При этом первый вариант продукта у неё оказался на шаг лучше, чем у Gemma4, и хватило одной итерации правок, чтобы получить код, который можно использовать. Оценка после правки - B+.
Разница в характере моделей здесь проявляется ярче, чем в анализе кода. Gemma4 берёт эффективностью на первом проходе, Qwen - настойчивостью и способностью довести задачу до рабочего состояния после замечаний. Для нового проекта одного быстрого прохода мало: важнее, дойдёт ли модель до состояния «можно запускать». По этому критерию Qwen3.8 оказалась полезнее.
GPT 6.1-Sol: другой уровень, другой бюджет
Тот же промпт на создание приложения передали GPT 6.1-Sol через десктопное приложение ChatGPT. Результат - A+ с первого прохода, одним запросом, без итераций правок. Автор теста описал это как совершенно другой уровень функциональности и полировки.
Разрыв объясняется масштабом и характером обучения фронтирной модели, а не тем, что локальные модели бесполезны. Проприетарная модель недоступна для self-hosted запуска, её нельзя поставить на домашний сервер и держать под своим контролем. Плата за качество - внешний API, зависимость от провайдера и передача кода наружу.
Похожая картина уже встречалась в сравнениях локальных моделей с облачными: локальный Qwen3.8-Flash-Next «Coder» набрал 92,7 балла и сравнялся с Claude Opus 4.6 на трёх задачах по Python, при этом чистоту и поддерживаемость кода облачная модель держала лучше. Подробности с методикой и скрытыми тестами собраны в разборе локальных Qwen против Claude Opus 4.6.
Что это значит на практике: кому и какую модель выбрать
Сводка результатов по обеим задачам:
| Модель | Анализ репозитория | Новый проект C# + WPF | Обращений к серверу | Сильная сторона |
|---|---|---|---|---|
| Gemma4-31B | Качественно, около 10 обращений | B- с первого прохода | ~10 | Скорость и экономия ресурсов |
| Qwen3.8-27B | Качественно, копнула глубже запроса | B+ после одной итерации правок | ~20-30 | Настойчивость и глубина разбора |
| GPT 6.1-Sol | В тесте не участвовала | A+ с первого прохода | Не указано | Качество и полировка кода |
Из таблицы следуют вполне прикладные сценарии:
- Разбор чужого кода и быстрые ответы по репозиторию. Gemma4-31B, если считать обращения и время. На 31B-модель в Q4 нужна карта на 24 ГБ, либо агрессивнее давить контекст на 16 ГБ.
- Незнакомый проект, который надо понять целиком. Qwen3.8-27B охотнее выходит за рамки вопроса и приносит лишний контекст. Цена - больше обращений и времени.
- Новый проект с нуля. Qwen3.8-27B плюс одна итерация правок. Gemma4 быстрее на старте, но первый результат сырее.
- Критичная задача сжатыми сроками. Если есть доступ к API и бюджет, GPT 6.1-Sol экономит итерации. Локального аналога такого качества в этом тесте не нашлось.
Планировать железо стоит с запасом. Один и тот же промпт на веб-разработку через девять моделей на RTX 3060 12 ГБ показал, что даже на слабой карте можно получить рабочий результат, но выбор квантизации меняет и качество, и скорость в разы. Цифры по времени и tok/s собраны в тесте девяти LLM на одном промпте.
Ограничения теста и что будет дальше
Результаты стоит воспринимать с поправкой на методологию, и автор теста говорит об этом прямо:
- Проверялись только две задачи: анализ репозитория и создание проекта. Ни рефакторинг, ни отладка, ни работа с тестами не затрагивались.
- Оценки B-, B+ и A+ субъективны. Их выставил один разработчик по своему опыту, без чек-листа и подсчёта баллов.
- Различия между Codex CLI и OpenCode CLI признаны незначительными и не учитывались, хотя разброс в числе обращений (20-30 у Qwen) как раз зависел от harness.
- Легаси-код не тестировался. Автор планирует отдельно проверить модели на задачах с унаследованной кодовой базой и внешними зависимостями.
- Работа шла на потребительском оборудовании, что влияет на скорость и на длину контекста, который реально доступен.
Общий вывод автора: локальные open-weight модели на потребительском железе дают совершенно рабочие результаты, но пока не в той же лиге, что фронтирные решения.
Практическое следствие для читателя: не строить выбор модели на одном чужом тесте. Возьмите два-три своих типовых промпта, прогоните через Gemma4-31B и Qwen3.8-27B в одной квантизации на своём железе и сравните три вещи: сколько итераций правок нужно до рабочего кода, сколько обращений уходит на одну задачу и насколько результат совпадает с вашим стилем. Эти три метрики скажут о вашем рабочем процессе больше, чем любая чужая оценка в баллах.