Локальные большие языковые модели (LLM) перестали быть просто игрушкой для энтузиастов. Они становятся полноценными инструментами в арсенале разработчика, способными генерировать код, планировать архитектуру и отлаживать проекты. Но какой именно моделью пользоваться, когда на кону стоит не абстрактный бенчмарк, а реальный рабочий процесс? В этом материале мы разберем практическое сравнение двух флагманских моделей — Qwen 3.6 и Gemma 4 — в условиях, максимально приближенных к реальной разработке.
Автор теста, практикующий разработчик, решил не проводить сухие тесты на синтетических датасетах. Вместо этого он поставил перед моделями конкретную прикладную задачу: создать кроссплатформенное десктопное приложение для просмотра и редактирования Markdown-файлов. Выбор пал на фреймворк Tauri, который позволяет создавать легкие и быстрые приложения, объединяя веб-технологии (HTML/CSS/JS) с нативным бэкендом на Rust. Это сложный проект, требующий от модели понимания взаимодействия фронтенда и бэкенда, работы с файловой системой и управления состоянием приложения.
В ходе сравнения рассматриваются ключевые метрики: время генерации полного кода, количество ошибок, требующих ручной правки, качество планирования задач, а также влияние нагрузки на железо. Мы подробно разберем, как модели справляются с архитектурными решениями, почему плотные модели (dense models) часто выигрывают у MoE-архитектур в задачах код-генерации, и как правильно настроить окружение для запуска LLM на собственном ПК. Это руководство поможет вам понять, какая модель лучше подходит для ваших конкретных задач и конфигурации железа.
01Выбор архитектуры: почему плотные модели (Dense)?
Один из первых вопросов, который возникает при выборе модели для локального запуска — это архитектура. Современные LLM делятся на два основных типа: Dense (плотные) и MoE (Mixture of Experts — смешанные модели). В данном тесте автор сознательно выбрал плотные модели: Qwen 3.6 с 27 миллиардами параметров и Gemma 4 с 31 миллиардом параметров. Это не случайность, а осознанный выбор для задач программирования.
Плотные модели обрабатывают каждый токен через все свои параметры. Это обеспечивает более глубокую «концентрацию» знаний в каждом нейроне, что часто приводит к более стабильному и логичному результату в сложных логических задачах, таких как написание кода. В то же время модели архитектуры MoE активируют только часть параметров для каждого токена, что делает их быстрее, но иногда менее точными в деталях или склонными к галлюцинациям в специфических контекстах.
Для задач генерации кода, где важна строгость синтаксиса и логическая связность, плотные модели часто показывают лучшие результаты. Они лучше удерживают контекст длинных файлов и реже допускают фундаментальные ошибки в архитектуре. Именно поэтому автор предпочел 27B Qwen и 31B Gemma, несмотря на то, что существуют более крупные или более быстрые альтернативы. Важно понимать: для локального запуска критическим фактором является объем видеопамяти (VRAM). Плотные модели требуют равномерного распределения весов, и если модель не помещается в VRAM, придется использовать CPU-инференс, что резко снизит скорость генерации.
02Тестовый стенд и окружение
Для проведения сравнительного теста был использован настольный компьютер, с которого модели запускались локально, и MacBook, с которого осуществлялось управление через локальную сеть. Это симулирует типичную сценарий работы разработчика: мощный сервер/ПК с видеокартой выполняет вычисления, а интерфейс взаимодействия находится на ноутбуке.
Ключевым требованием к железу, как подчеркивает автор, является наличие видеокарты с большим объемом памяти. Именно VRAM, а не только вычислительная мощность GPU, является узким местом при запуске LLM. Если модель не влезает в видеопамять, система начинает использовать системную оперативную память (RAM), что замедляет генерацию токенов с нескольких десятков токенов в секунду до единиц. В данном тесте обе модели (27B и 31B) успешно помещались в VRAM, что обеспечило стабильную скорость работы.
Для взаимодействия с моделями использовался инструмент OpenCode. Это AI-агент, который умеет не просто генерировать текст, но и взаимодействовать с файловой системой проекта: читать файлы, создавать новые, запускать команды терминала. Автор заранее подготовил две папки, в каждой из которых лежал одинаковый файл с описанием задачи. Это обеспечило честность сравнения: модели получали идентичный входной контекст.
03Этап планирования: Qwen 3.6 против Gemma 4
Первым этапом работы стало создание детального плана реализации. Автор попросил каждую модель проанализировать описание приложения и разбить его на фазы и конкретные задачи. Это важный этап, так как качество плана напрямую влияет на успех всей генерации кода.
Qwen 3.6 справилась с планированием за 4 минуты. Результат оказался очень подробным: модель разделила проект на множество фаз, каждая из которых содержала детализированные задачи с указанием нюансов. Автор отметил, что план выглядит логичным и полным. Однако, более детальное сравнение показало, что Qwen разбила проект почти на две фазы больше, чем Gemma, и сформулировала больше отдельных задач. Это может быть как плюсом (больше контроля), так и минусом (больше шагов для выполнения).
Gemma 4 продемонстрировала более высокую скорость на этапе планирования — всего 2,5 минуты. Ее план также был структурирован по фазам и содержал четкие описания задач. Визуальное сравнение планов показало, что они очень похожи по структуре, но Gemma предложила более компактный путь к результату. Интересно, что Gemma, даже не получая такой инструкции явно, самостоятельно переместила файлы описания и плана в отдельную папку «documentation», что сделало структуру репозитория чище. Это говорит о хорошем понимании принципов организации кода.
04Генерация кода: Стресс-тест на полную реализацию
Самым интересным и сложным этапом стала генерация всего кода приложения за один проход. Автор намеренно выбрал такой сценарий (stress test), чтобы проверить, насколько хорошо модели могут удерживать контекст и последовательно выполнять сложные задачи, не теряя нить повествования. В реальной разработке обычно рекомендуется реализовывать проект поэтапно, но здесь цель была проверить предел возможностей моделей.
Qwen 3.6 начала активное рассуждение и генерацию кода. Процесс был долгим. Модель демонстрировала способность к саморефлексии: она выявляла собственные ошибки в процессе генерации и пыталась их исправить. Однако, общий объем работы оказался значительным. На реализацию всего проекта Qwen ушло 46 минут. Это приемлемое время для локальной модели, работающей с таким объемом кода, но оно требует терпения.
Gemma 4 справилась с той же задачей в два раза быстрее — за 20 минут. Это впечатляющий результат, который делает Gemma более привлекательной для итеративной разработки, где скорость ответа критична. Кроме того, в конце своего ответа Gemma вывела список всех задач, которые она выполнила. Это удобная функция для отладки и понимания того, что именно было сгенерировано. Быстрая генерация Gemma не означала низкого качества: модель также активно рассуждала и принимала решения.
05Энергопотребление и стоимость владения
Запуск локальных LLM — это не только вопрос скорости, но и затрат на электроэнергию. Автор обратил внимание на этот аспект, показав потребление настольного компьютера под активной нагрузкой. Это важный момент, который часто упускают из виду. Если модель работает постоянно, генерируя код, счет за электричество может заметно вырасти.
Поскольку Gemma 4 выполнила задачу за 20 минут, а Qwen 3.6 — за 46 минут, разница в потребленной энергии будет существенной. При одинаковой мощности системы (которая определяется в основном видеокартой и процессором, работающими на 100%), Gemma сэкономила более 26 минут работы под полной нагрузкой. Для разработчиков, которые часто запускают AI-ассистентов, это может означать экономию нескольких киловатт-часов в месяц, что в масштабах года превращается в ощутимую сумму. Кроме того, меньшее время работы снижает тепловыделение и шум системы охлаждения.
06Результат: Запуск и отладка приложений
После генерации кода началась самая болезненная часть для любого разработчика — запуск и отладка. Идеальный сценарий, когда код работает с первого раза, встречается редко. Оба приложения столкнулись с ошибками, но характер этих ошибок differed.
Qwen 3.6: Приложение не запустилось сразу. Первая ошибка была связана с фронтендом: модель, вероятно, неправильно указала порт или не сгенерировала блок запуска сервера. Автору пришлось добавить несколько строк кода вручную. Вторая ошибка возникла в коде на Rust: Qwen использовала метод из первой версии Tauri, который был изменен во второй версии. Это классическая проблема «устаревших» примеров в обучающих данных. После исправления этих двух незначительных ошибок приложение запустилось.
Gemma 4: Также не запустилась с первого раза. Ошибка была на стороне Rust, связанной с доступом к файловой системе. Проблема заключалась в том, что в конфигурации Tauri не были подключены плагины для работы с файловой системой, хотя сам код их использовал. Автору нужно было добавить эти плагины в конфиг. После этого компиляция прошла успешно, и приложение запустилось.
Обе модели допустили ошибки, но они были исправимы и не требовали глобальной переписки кода. Это говорит о том, что базовая архитектура была построена правильно.
07Функциональность и UX готовых приложений
После успешного запуска автор протестировал функциональность обоих приложений. Оба создали двухпанельный интерфейс: слева редактор текста, справа — предпросмотр Markdown. Это стандартное и удобное решение.
Qwen 3.6: Редактор корректно реагировал на ввод текста, предпросмотр обновлялся в реальном времени. Удалось открыть файл плана разработки внутри самого редактора, и Markdown отобразился без ошибок. Однако, кнопки на панели инструментов вели себя странно: некоторые не реагировали на нажатия. Это указывает на то, что модель не до конца проработала обработчики событий для UI-элементов.
Gemma 4: Интерфейс также работал корректно. Кнопки переключения между режимами редактирования и просмотра функционировали правильно. Функция открытия файла с диска также работала без сбоев. Но здесь обнаружился странный провал: Gemma полностью проигнорировала создание кнопок для форматирования текста, хотя в своем плане она явно включила задачи по их разработке. Это пример «галлюцинации» или потери контекста при переходе от планирования к реализации.
08Сравнительный анализ: Плюсы и минусы
Подводя итоги, можно выделить четкие преимущества каждой модели.
Qwen 3.6 (27B):
- Плюсы: Более детализированное планирование, способность к саморефлексии в процессе генерации, создание более полной структуры проекта (больше фаз и задач). Хорошая работа с логикой.
- Минусы: Медленнее (46 минут против 20), больше ошибок в первых версиях кода (устаревшие API, пропущенные блоки), необходимость ручной доработки UI-кнопок.
Gemma 4 (31B):
- Плюсы: В два раза быстрее, чище структура репозитория (авто-организация файлов), меньше ошибок при компиляции, хорошая работа с базовым функционалом.
- Минусы: Игнорирование части задач из собственного плана (кнопки форматирования), менее детальное разбиение на фазы.
09Выводы: кому что подойдёт
Обе модели успешно справились с задачей создания полноценного приложения, что говорит о высоком уровне их развития. Выбор между ними зависит от ваших приоритетов.
Если вам важна скорость итераций и вы хотите быстро получить рабочий прототип, который можно дорабатывать, Gemma 4 будет лучшим выбором. Она быстрее, чище в организации файлов и дает стабильный результат с меньшим количеством критических ошибок. Однако, будьте готовы проверить, не пропустила ли модель какие-то задачи из плана.
Если же вам нужно максимально детальное планирование и вы готовы потратить больше времени на отладку, Qwen 3.6 может оказаться полезнее. Её способность разбивать проект на множество мелких задач помогает лучше контролировать процесс, а саморефлексия позволяет исправлять ошибки на лету. Но будьте готовы к тому, что код может требовать больше ручной правки, особенно в части интеграции с актуальными версиями библиотек.
Автор теста решил использовать обе модели вместе, комбинируя их сильные стороны. Это разумный подход: использовать Gemma для быстрой генерации базовой структуры и Qwen для детализации сложных логических блоков. Для практиков в РФ это означает, что при наличии достаточного объема VRAM (24 ГБ+) можно эффективно использовать обе модели, не ограничиваясь одной. Доступ к ним осуществляется через локальные серверы (Ollama, LM Studio), что гарантирует конфиденциальность данных и независимость от внешних API.
В конечном счете, локальные AI-ассистенты — это не замена разработчику, а мощный инструмент, расширяющий его возможности. Понимание сильных и слабых сторон каждой модели позволяет выстроить эффективный рабочий процесс, где AI берет на себя рутину, а человек контролирует качество и архитектуру.
Источник: видео-разбор (YouTube) ↗