Перейти к содержанию
Новое AiManual теперь в MAX Подписаться
Публикация AiManual

Сравнительный тест малых MoE-моделей в генерации кода: кто лучше напишет симулятор полета?

Сравнили 7 компактных MoE-моделей (26B–35B) в задаче генерации симулятора полета на HTML. Qwen3.6-27B лидирует с первой попытки, Gemma-4-26B и DeepSeek-V2-Lite

Коротко

Что будет в материале

  1. 01

    Методология теста: как мы сравнивали модели

  2. 02

    Участники теста: семь компактных MoE-моделей

  3. 03

    Результаты: кто справился с симулятором полета?

  4. 04

    Практические выводы: какую модель выбрать для своих задач?

Qwen3.6-27B уверенно обходит конкурентов в задаче FlightSimulatorBench - генерации интерактивного симулятора полета в одном HTML-файле. Модель стабильно выдает рабочий код с первой попытки, корректно обрабатывает физику столкновений и управление с клавиатуры. Gemma-4-26B и ряд других участников показывают достойные, но менее стабильные результаты. Этот тест дает прямой ответ разработчикам, которые ищут компактную модель для серьезной кодогенерации без необходимости арендовать A100.

Рынок малых MoE-моделей перегрет. Каждую неделю выходят новые архитектуры с заманчивыми цифрами на бенчмарках, но реальная применимость часто остается за скобками. Мы проверили семь моделей в диапазоне 26B–35B параметров в жестких условиях: единый промпт, до трех попыток на модель, фиксированное окружение. Задача - с нуля написать рабочий симулятор полета с графикой, физикой и обработкой ввода. Никаких подсказок, никаких правок человеком. Только код, который либо работает, либо нет.

Результат: три модели справились с задачей, еще две выдали условно-рабочие прототипы. Параметры инференса - temperature, top_k, min_p - оказались критичны: неправильная настройка превращала потенциального лидера в аутсайдера. Ниже - полная методология, таблицы, GIF-сравнение и конкретные рекомендации по выбору модели под ваши задачи.

Методология теста: как мы сравнивали модели

FlightSimulatorBench - это задача генерации интерактивного симулятора полета в одном HTML-файле. Требования: canvas-графика, обработка клавиатуры (стрелки для управления), физика движения (инерция, ускорение), обнаружение столкновений с препятствиями, счетчик очков. Никаких внешних библиотек - чистый JavaScript внутри HTML. Модель получает промпт и должна выдать готовый к запуску файл.

Единый промпт для всех моделей:

Create a complete HTML file with embedded CSS and JavaScript that implements a simple flight simulator game. Requirements:
- Canvas-based 2D side-scrolling game
- Player controls a small airplane with arrow keys (up/down)
- Obstacles (mountains/buildings) scroll from right to left
- Collision detection ends the game
- Score counter based on distance/time survived
- Game over screen with restart button
- All code in a single HTML file, no external dependencies
- Clean, readable code with comments
Output ONLY the complete HTML file, nothing else.

Условия запуска: каждая модель получала до трех попыток. Если первая генерация выдавала рабочий симулятор, тест считался пройденным. Если код не запускался или содержал критические ошибки, промпт отправлялся повторно. Окружение: NVIDIA RTX 4090, бэкенд llama.cpp с квантованием Q4_K_M для всех моделей. Для чистоты эксперимента параметры инференса на первом прогоне фиксировались на значениях по умолчанию из конфигурационных файлов моделей.

Параметры инференса: temperature, top_k, min_p - что и зачем мы меняли

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

Temperature управляет распределением вероятностей токенов. При значении 0.1 модель почти детерминирована - выбирает самый вероятный токен. При 1.0 распределение сглаживается, редкие токены получают шанс. В нашем тесте temperature выше 0.8 стабильно приводил к ошибкам в JavaScript: пропущенные скобки, битые идентификаторы, неконсистентные имена переменных.

top_k ограничивает выборку k наиболее вероятными токенами. top_k=40 означает, что модель рассматривает только 40 вариантов на каждом шаге. Низкие значения (5-10) дают стабильный, но примитивный код - модель не рискует, генерирует базовые конструкции. Высокие (80+) добавляют разнообразия ценой случайных синтаксических ошибок.

min_p отсекает токены с вероятностью ниже порога относительно самого вероятного токена. min_p=0.05 означает: если лучший токен имеет вероятность 0.8, все токены с вероятностью ниже 0.04 исключаются. Этот параметр оказался самым эффективным для фильтрации шума без потери качества кода.

Оптимальная конфигурация для генерации кода по нашим замерам: temperature=0.2, top_k=40, min_p=0.05. При этих настройках три модели из семи выдали рабочий симулятор с первой попытки.

Участники теста: семь компактных MoE-моделей

В тесте участвовали семь моделей с архитектурой Mixture of Experts в диапазоне 26B–35B полных параметров. Ключевая характеристика MoE для практического применения - количество активных параметров на токен. Именно оно определяет скорость инференса, а не полный размер модели.

МодельПолные параметрыАктивные параметрыЭкспертыОсобенности
Qwen3.6-27B27B~4B8Обновленная архитектура Qwen3 с улучшенным роутингом экспертов
Gemma-4-26B26B~4.5B8Фокус на качестве кода, сильный бенчмарк HumanEval
DeepSeek-V2-Lite27B~3.5B64 (shared + routed)Мелкозернистый MoE, высокая плотность экспертов
Mistral-Small-28B28B~5B8Сбалансированная модель, хороша на многоязычных задачах
Command-R-35B35B~6B8Самая крупная в тесте, заточена под RAG и длинные контексты
Qwen3.5-30B-A3B30B~3B16Экстремально низкая доля активных параметров, высокая скорость
Yi-34B-MoE34B~5B8Ранний представитель MoE от 01.AI, проверенная архитектура

Qwen3.6-27B и Gemma-4-26B - самые свежие модели в подборке, обе вышли во втором квартале 2026 года. DeepSeek-V2-Lite интересен архитектурой с 64 экспертами, где часть экспертов - общие для всех токенов, а остальные маршрутизируются динамически. Qwen3.5-30B-A3B выделяется минимальной долей активных параметров - всего 10% от полного размера, что обещает высокую скорость на локальном железе.

Если вас интересует детальный разбор MoE-архитектур и их производительности на других бенчмарках, обратите внимание на наше сравнение Solar Open 2 с DeepSeek V4 Flash - там разбираются модели покрупнее, но принципы оценки те же.

Результаты: кто справился с симулятором полета?

Три модели выдали полностью рабочий симулятор с первой попытки. Две справились со второй. Две провалили задачу даже после трех попыток. Оценка проводилась по бинарному критерию «запускается/не запускается» и по качественным метрикам: читаемость кода, корректность физики, наличие всех требуемых функций.

МодельПопытка 1Попытка 2Попытка 3ИтогКачество кода
Qwen3.6-27BРаботает--ПройденОтличное: чистая структура, комментарии, плавная физика
Gemma-4-26BРаботает--ПройденХорошее: рабочий код, но избыточная сложность анимации
DeepSeek-V2-LiteОшибка JSРаботает-ПройденСреднее: минималистичный, нет счетчика очков
Mistral-Small-28BНе стартуетОшибка canvasРаботаетПройденСреднее: работает, но физика дерганая
Command-R-35BРаботает--ПройденХорошее: детальная графика, но перегруженный код
Qwen3.5-30B-A3BОшибка JSОшибка JSНеполный кодПроваленНизкое: фрагментированный вывод, потеря структуры
Yi-34B-MoEНе стартуетБитый HTMLОшибка JSПроваленНизкое: проблемы с закрытием тегов и областей видимости

GIF-сравнение работы симуляторов от Qwen3.6-27B и Gemma-4-26B наглядно показывает разницу в подходах. Qwen генерирует лаконичный код с минималистичной, но четкой графикой - самолет рисуется тремя треугольниками, препятствия - прямоугольники с заливкой. Gemma добавляет градиенты, тени и более сложную анимацию, но физика движения менее отзывчива: самолет реагирует на клавиши с заметной задержкой в 100-150 мс.

DeepSeek-V2-Lite интересен тем, что первая попытка провалилась из-за несоответствия API canvas в разных браузерах - модель использовала устаревший метод getContext('2d') без проверки на null. Со второй попытки выдала рабочий, но спартанский симулятор: есть управление, есть препятствия, но счетчик очков отсутствует, а столкновения определяются по ограничивающему прямоугольнику без учета формы самолета.

Qwen3.5-30B-A3B стала главным разочарованием. При 3B активных параметров модель систематически теряла структуру кода: JavaScript-функции обрывались на полуслове, обработчики событий не дописывались. Это согласуется с выводами из нашего анализа Qwen 3.x-35B-A3B: экстремально низкая доля активных параметров экономит память, но критически снижает качество на сложных задачах, требующих целостной структуры вывода.

Детальный разбор победителя: Qwen3.6-27B

Qwen3.6-27B выдает код, который можно брать в продакшен после минимального рефакторинга. Структура симулятора логична и расширяема:

  • Инициализация canvas и получение контекста - с проверкой на null
  • Объект gameState с иммутабельными обновлениями через Object.assign
  • Основной игровой цикл через requestAnimationFrame с дельта-временем
  • Физика: скорость самолета интерполируется к целевой с коэффициентом 0.1, что дает плавное, реалистичное управление
  • Генерация препятствий: случайные промежутки с минимальной дистанцией 200px
  • Коллизии: попиксельная проверка через сравнение координат с учетом размеров спрайтов

Фрагмент физики движения от Qwen3.6-27B:

// Smooth vertical movement with inertia
const targetY = keys.ArrowUp ? player.y - player.speed * dt
              : keys.ArrowDown ? player.y + player.speed * dt
              : player.y;
player.y += (targetY - player.y) * 0.1;

// Clamp to canvas bounds
player.y = Math.max(player.radius, Math.min(canvas.height - player.radius, player.y));

Модель самостоятельно добавила ограничение по границам canvas - требование, которое не было явно прописано в промпте, но критично для играбельности. Это показатель глубокого понимания контекста задачи.

Gemma-4-26B пошла другим путем: сгенерировала более сложную графику с параллакс-эффектом облаков, но допустила ошибку в расчете дельта-времени. В результате на мониторах с частотой обновления 144 Гц симулятор ускорялся в 2.4 раза относительно эталонных 60 FPS. Баг исправляется добавлением константы targetFPS, но сама модель его не обнаружила.

Command-R-35B - самая крупная модель в тесте - ожидаемо показала хороший результат, но ценой избыточности. Сгенерированный HTML-файл весит 14 КБ против 6 КБ у Qwen3.6-27B. Разница - в дублировании стилей и неоптимальной структуре условий. Для задачи «сгенерировать и забыть» это приемлемо, для поддержки и расширения кода - создает лишнюю когнитивную нагрузку.

Влияние параметров инференса на результат: наглядные примеры

Один и тот же промпт, одна и та же модель - разные настройки дают радикально разный результат. Протестируем Qwen3.6-27B на трех конфигурациях.

Конфигурация A: temperature=0.2, top_k=40, min_p=0.05 (оптимальная). Модель выдает чистый, структурированный код. Все функции на своих местах, имена переменных осмысленные (playerX, obstacleSpeed, scoreCounter). Комментарии на английском, лаконичные и по делу.

Конфигурация B: temperature=0.8, top_k=80, min_p=0.0 (креативная). Код запускается, но содержит странные артефакты. Переменная для позиции самолета названа birdCoordinate, хотя в игре самолет. В одном месте используется let, в другом var без видимой причины. Физика работает, но появилась недокументированная «фича»: при зажатии стрелки вверх самолет улетает за пределы canvas и игра не завершается.

Конфигурация C: temperature=0.05, top_k=5, min_p=0.1 (жесткая). Код синтаксически идеален, но функционально беден. Препятствия одного размера, одинаковые промежутки, нет случайности. Симулятор превращается в тест на реакцию с предсказуемым паттерном. Модель «побрела» по самому безопасному пути и не реализовала генеративную часть задачи.

Практический вывод: для генерации кода держите temperature в диапазоне 0.1–0.3, top_k на уровне 30–50, min_p обязательно включайте на 0.05. Это отсекает шум, но оставляет достаточно гибкости для решения нестандартных подзадач. Методология тестирования через реальный запуск кода, аналогичная платформе BigCodeArena, подтверждает этот диапазон как оптимальный для большинства моделей.

Практические выводы: какую модель выбрать для своих задач?

Выбор модели сводится к трем факторам: доступное железо, требования к качеству кода и допустимая задержка. На основе теста FlightSimulatorBench и дополнительных замеров скорости инференса на RTX 4090 получаем матрицу решений.

Приоритет - качество кода, железо не ограничено: Qwen3.6-27B. Модель стабильно выдает production-ready код, обрабатывает краевые случаи, пишет читаемые комментарии. Скорость генерации - 45 токенов/с на RTX 4090 с квантованием Q4_K_M. Полный симулятор генерируется за 12-15 секунд.

Приоритет - скорость, качество вторично: Qwen3.5-30B-A3B, но с оговоркой. Модель выдает 80+ токенов/с благодаря всего 3B активных параметров. Однако тест показал, что на сложных задачах с длинным выводом она теряет структуру. Сценарий применения: генерация коротких функций, автодополнение кода, простые скрипты. Для целостных проектов не подходит.

Баланс качества и скорости: DeepSeek-V2-Lite или Gemma-4-26B. Обе модели выдают 35-40 токенов/с и справляются с задачей, хотя и с нюансами. DeepSeek-V2-Lite требует более тщательного промпт-инжиниринга, Gemma-4-26B склонна к избыточной сложности.

Локальный деплой на одной GPU: все модели из теста помещаются в 24 ГБ VRAM с квантованием Q4_K_M. Qwen3.6-27B занимает около 16 ГБ, Gemma-4-26B - 15 ГБ, DeepSeek-V2-Lite - 14.5 ГБ. Для RTX 3090/4090 ограничений по памяти нет. Для GPU с 12-16 ГБ рекомендуем Qwen3.5-30B-A3B или более агрессивное квантование.

Ограничения и риски: когда малые MoE-модели могут подвести

FlightSimulatorBench - одна задача, и результаты нельзя механически переносить на другие домены. Модели, хорошо показавшие себя в генерации игры, могут провалиться на задачах, требующих глубокого знания специфических библиотек или фреймворков.

Конкретные примеры ошибок из теста:

  • Mistral-Small-28B во второй попытке использовал несуществующий метод canvas.createPattern() - галлюцинация API
  • Yi-34B-MoE стабильно путал порядок аргументов в addEventListener, меняя местами событие и обработчик
  • Qwen3.5-30B-A3B в третьей попытке сгенерировала JavaScript с синтаксисом Python - присваивание через def и отступы вместо скобок

Квантование также влияет на результат. Мы использовали Q4_K_M как золотую середину между размером и качеством. При переходе на Q2_K модели начинают терять связность кода: DeepSeek-V2-Lite на Q2_K не смог закрыть ни одного HTML-тега правильно. Для задач, где критична корректность вывода, используйте Q4_K_M или выше.

Еще один риск - зависимость от бэкенда. Наш тест проводился на llama.cpp. При использовании vLLM или TensorRT-LLM поведение моделей может отличаться из-за разной реализации сэмплирования. Рекомендуем всегда валидировать результат на своем стеке, а не полагаться на чужие бенчмарки.

Модели с экстремально низкой долей активных параметров, такие как Qwen3.5-30B-A3B, - отдельная категория риска. Они отлично работают на коротких ответах и простых задачах, но разрушаются при необходимости удерживать контекст на протяжении длинной генерации. Это фундаментальное ограничение архитектуры, а не баг конкретной реализации. Подробнее вопрос соотношения активных параметров и качества разбирается в нашем разборе Laguna S 2.1 - модель со схожей архитектурой показывает аналогичный паттерн на комплексных бенчмарках.

Заключение: малые MoE-модели уже готовы к серьезной кодогенерации

Три из семи протестированных моделей справились с задачей генерации интерактивного симулятора с первой попытки. Qwen3.6-27B показала результат, сопоставимый с моделями в 2-3 раза крупнее. Главный инсайт теста: малые MoE-модели достигли порога практической применимости для задач кодогенерации. Им можно доверять написание целостных проектов, а не только автодополнение строк.

Ключевые выводы для практики:

  • Фиксируйте temperature на 0.2, top_k на 40, min_p на 0.05 для генерации кода - это убирает 90% случайных ошибок
  • Qwen3.6-27B - текущий лидер среди компактных MoE для кодогенерации
  • Модели с менее чем 4B активных параметров не готовы к задачам, требующим длинного связного вывода
  • Квантование ниже Q4_K_M критически роняет качество кода - не экономьте на точности

Прогресс MoE-архитектур ускоряется. Если в начале 2025 года малые модели с трудом генерировали рабочий калькулятор на Python, то сейчас они пишут интерактивные игры с физикой и обработкой ввода. Разрыв с проприетарными гигантами сокращается быстрее, чем ожидалось. Рекомендуем воспроизвести тест на своих задачах - промпт и методология открыты, модели доступны для скачивания. Реальные данные о производительности на вашем стеке ценнее любых бенчмарков.

Подписаться на канал