Зачем сравнивать LLM на реальных задачах, а не на бенчмарках
Nemotron 3.5 Bolt выиграл первую задачу и проиграл вторую. Дата-инженер дал ему два реальных задания из своего ETL-проекта, которые до этого выполнил Qwen Flash Next в квантизации UD-IQ4_XS на llama.cpp. Судьёй выступил Gemini: он получил spec-sheet с критериями приёмки, исходные файлы и результаты обеих моделей. В рефакторинге run.sh сильнее оказался Bolt, в создании orchestrator.py победил Qwen Flash Next.
Первая задача - привести run.sh к паттерну run-new.sh: управление флагами, структурированное логирование, обработка ошибок AWS SNS при сохранении логики разрешения venv. Вторая - написать orchestrator.py, который генерирует последовательность временных окон (ежедневных или ежемесячных в зависимости от аргументов запуска) и последовательно вызывает run.sh для каждого окна. Обе задачи взяты из рабочего конвейера дата-инженера, а не из синтетического набора.
Короткий вывод для тех, кто выбирает модель прямо сейчас: Nemotron 3.5 Bolt подходит для лёгких и средних задач и работает быстро, но заменой Qwen Flash Next на сложных repo-level задачах он не становится. Ниже - методика, технические причины побед каждой модели и ограничения такого сравнения.
Модель, которая уверенно проходит синтетический тест, может сломаться на первом же рабочем скрипте. Бенчмарк чаще проверяет генерацию кода с нуля, а работа дата-инженера устроена иначе: нужно встроиться в существующий конвейер, сохранить чужие паттерны, не потерять порядок проверок и не сломать пути. Рефакторинг shell-скрипта под чужой дизайн-паттерн такие тесты почти не проверяют.
Метод, который применил автор кейса, ставит во главу угла готовый эталон. Он даёт новой модели те же задачи, которые уже выполнила доверенная модель, и сравнивает результат с реализацией, принятой в работу. Здесь доверенной моделью был Qwen Flash Next, проверяемой - Nemotron 3.5 Bolt. Исходный разбор опубликован на Reddit.
Оценку проводил Gemini. Задачи ставились через markdown spec-sheet в свежей сессии pi.dev: сначала планирование и критерии приёмки, потом работа модели, потом разбор результатов. Такой формат даёт конкретику, потому что сравнение идёт не по общему впечатлению, а по пунктам спецификации, где проверяема каждая строка. Дальше - что именно решило исход в каждой задаче.
Методика: spec-sheet, pi.dev и Gemini как судья
Пайплайн автора укладывается в четыре шага. Сначала задачи планируются в Gemini, там же формулируются требования. Затем оформляется markdown spec-sheet с критериями приёмки. Готовый документ вставляется в свежую сессию pi.dev, и модель работает по нему без дополнительных подсказок. После завершения автор загружает в Gemini тот же spec-sheet, релевантные файлы (оригинальный run.sh и run-new.sh) и результаты обеих моделей, после чего просит оценить работу и выбрать победителя. Полный текст с оценкой доступен на Reddit.
Spec-sheet составляется до того, как модель напишет первую строку кода. Критерии нельзя подогнать под готовый результат, а значит, сравнение двух моделей идёт по одинаковым правилам.
Почему сравнение с доверенной моделью работает лучше слепого теста
Эталон уже прошёл проверку практикой. Результат Qwen Flash Next на том же ETL-рефакторинге был принят в работу, а не просто выглядел убедительно в редакторе. Новая модель получает идентичные задачи и идентичные критерии приёмки, поэтому сравнивается с рабочей реализацией, а не с абстрактным «хорошо» или «плохо».
Риск красивого, но нерабочего решения снижается. Модель может выдать аккуратный код, который разваливается при запуске из другого каталога, и на синтетическом тесте это останется незамеченным. Рядом с готовым эталоном такие провалы видны сразу: достаточно сравнить поведение двух скриптов в одинаковых условиях.
Ограничения методики: одна модель-судья и малая выборка
Победителя в каждой задаче определял Gemini по spec-sheet и предоставленным файлам. Один судья - это один взгляд, независимых экспертов в процессе нет. Модель-судья может тяготеть к определённому стилю кода и оценивать формальные признаки строже, чем практическую ценность решения.
Выборка - две задачи, и сам автор не считает их сверхсложными. Это практический кейс, а не статистика: переносить результаты на все repo-level задачи нельзя. Для устойчивых выводов нужны серии однотипных заданий и, желательно, несколько независимых судей.
Детали разбора второй задачи в исходном посте раскрыты короче, чем первой, поэтому по orchestrator.py меньше воспроизводимых цитат и больше общих формулировок. Подход с прогоном локальных и облачных моделей на большом наборе заданий по кодингу, анализу данных и RAG разобран в отдельном материале AI-Manual.
Задача №1: рефакторинг run.sh - почему выиграл Nemotron 3.5 Bolt
Формулировка задачи звучит так: привести run.sh к паттерну из run-new.sh, то есть перенести управление флагами, структурированное логирование и обработку ошибок AWS SNS, сохранив при этом существующую логику разрешения venv.
Базу обе модели сделали одинаково хорошо. Парсер аргументов у них совпал: цикл while/case корректно разбирает флаги -o, -x, -s, -e, -i, -b, -h, -d вместе с длинными формами, и ни одна модель не экспортировала CLI-аргументы в переменные окружения. Исход решили три детали.
SCRIPT_DIR и LOG_DIR: где на самом деле создаются логи
Nemotron определяет в начале скрипта SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" и берёт для логов путь $SCRIPT_DIR/logs. Логи привязаны к каталогу скрипта, откуда бы его ни вызвали.
Qwen Flash Next задал LOG_DIR="$(pwd)/logs" и отложил определение SCRIPT_DIR на потом. Если запустить /path/to/run.sh из /tmp, логи уедут в /tmp/logs вместо каталога приложения. В cron, CI или при ручном запуске из другого каталога это ломает предсказуемость: лог есть, но лежит не там, где его ищут при разборе инцидента.
Порядок проверок зависимостей: tee и aws
Nemotron проверяет наличие tee и aws до перенаправления вывода. Qwen Flash Next сначала подключает process substitution >(tee -a ...), и только потом проверяет, существует ли tee.
Разница проявляется на сломанном окружении. Без tee у Qwen пайп падает в момент запуска с ошибкой оболочки, а у Nemotron пользователь получает понятное сообщение о нехватке бинарника до старта логирования. Для скрипта, который запускается по расписанию на чужой машине, порядок проверок экономит часы диагностики.
exec против дочернего процесса: почему trap не срабатывал у Qwen
run-old.sh завершался вызовом exec "$VENV/bin/python" .... Qwen Flash Next сохранил exec. Механика такая: exec заменяет текущий процесс оболочки процессом Python, поэтому trap ... EXIT, объявленный в скрипте, обходится при завершении Python. Nemotron убрал exec и вызывает Python дочерним процессом. Оболочка продолжает жить и корректно выполняет трапы при выходе: очистка ресурсов, финальная запись в лог, предсказуемый код возврата.
Вывод Gemini по первой задаче: реализация Nemotron признана превосходным рефакторингом. Все критерии приёмки соблюдены, каталоги логов привязаны к SCRIPT_DIR, а не к pwd, задачи настройки выстроены логично - проверка tee выполняется до использования process substitution. Формулировка оценки приведена в исходном разборе.
Задача №2: orchestrator.py - почему выиграл Qwen Flash Next
Вторая задача: написать orchestrator.py, который генерирует последовательность временных окон (ежедневных или ежемесячных в зависимости от аргументов запуска) и последовательно вызывает run.sh для каждого окна. Здесь победил Qwen Flash Next. Причин три.
Строгое следование спецификации: subprocess.run с check=True
В spec-sheet было прямо указано использование subprocess.run с check=True, и Qwen выполнил это буквально. С check=True ненулевой код возврата run.sh выбрасывает исключение и останавливает оркестратор. Без него ошибка одного окна тихо проходит дальше, и на выходе получается частично загруженный набор данных без единой строчки о сбое.
Nemotron в этом месте от спецификации отступил, и оценка снизилась. Когда пайплайн крутится по расписанию, формальное соблюдение spec важнее творческих улучшений: каждое отклонение потом приходится отлаживать в проде.
Безопасное разрешение путей через Path(__file__)
Qwen определил расположение run.sh от Path(__file__), то есть от файла самого оркестратора. Скрипт работает из любого рабочего каталога: при запуске из домашней папки, из systemd и из крона.
Это тот же класс ошибки, что и с LOG_DIR в первой задаче, только здесь Qwen его избежал. Симметрия показательна: модели не забывают правило навсегда, оно просто не переносится автоматически из одного файла в другой.
Информативное логирование хода выполнения
Логи Qwen подробнее. Видно, какие временные окна сгенерированы, какой вызов run.sh стартовал, что вернулось. Для ETL-оркестрации это инструмент разбора инцидентов: когда окно за январь не догрузилось, по логу сразу понятно, дошёл ли оркестратор до этого окна. Nemotron логировал беднее.
Оговорка по этой задаче: детали её разбора в исходном посте короче, чем по первой, поэтому три перечисленные причины - основной наблюдаемый слой различий, а не полный перечень.
Скорость Nemotron 3.5 Bolt: 130 токенов/с даже в 2-битной квантизации
На сервере автора Bolt выдаёт около 130 токенов/с даже в 2-битной квантизации. Эта цифра приведена в исходном разборе. Для модели с сильным сжатием весов это высокая скорость, и она делает Bolt пригодным для лёгких и средних задач, где важен отклик: подсказки по коду, шаблонный рефакторинг, генерация обвязки.
Значение измерено в одной конфигурации на конкретном сервере. Модель GPU и параметры запуска автор не приводит, поэтому ориентироваться стоит на порядок величины, а не на точное число: на другом железе результат будет другим.
2-битная квантизация - компромисс по качеству, и он проявляется именно на сложных repo-level задачах, где нужно удержать в контексте несколько файлов, спецификацию и историю правок. Как кванты одного семейства ведут себя на задачах разной сложности, разобрано в материале про три кванта Qwen 3.8 на 16 ГБ VRAM.
Когда брать Bolt, когда Qwen Flash Next, а когда - обоих
Разделение следует напрямую из двух задач. Nemotron 3.5 Bolt - быстрая модель для лёгких и средних задач: привести файл к шаблону, дописать обвязку, объяснить незнакомый код. Qwen Flash Next в конфигурации UD-IQ4_XS на llama.cpp надёжнее там, где нужно точно держать спецификацию, аккуратно обходиться с путями и писать оркестрацию с предсказуемым поведением при ошибках.
Третий вариант - комбинировать. Автор планирует использовать Bolt как суб-агента в связке с более сильной моделью на будущем M5 Mac Studio. Логика схемы простая: быстрая модель закрывает рутинные шаги, сильная берёт на себя решения уровня репозитория. Данных о производительности M5 в разборе нет, это план, а не измеренный результат.
Сценарий «суб-агент + сильная модель»
Разделение ролей выглядит так: Bolt генерирует черновики и типовые фрагменты, сильная модель проверяет их на соответствие спецификации, дописывает сложные места и берёт на себя сквозные изменения по репозиторию. Выгода в скорости отклика на массовых шагах, цена - необходимость ревью между этапами. Как похожие схемы работают в coding и agentic-сценариях, включая требования к VRAM, разобрано в сравнении DeepSeek V4 Flash и Qwen 3.6 27B.
Как повторить такое сравнение на своём проекте
- Выберите две или три реальные задачи, которые доверенная модель уже решила и результат которых принят в работу. Идеально, если задачи разные по типу: рефакторинг существующего файла и написание нового.
- Оформите spec-sheet в markdown: что нужно сделать, какие критерии приёмки, какие ограничения соблюсти. Критерии пишутся до запуска модели.
- Дайте задачи новой модели в чистой сессии pi.dev, без подсказок и правок по ходу.
- Сохраните артефакты: оригинальные файлы, spec-sheet, результат доверенной модели и результат новой модели. Без эталона сравнение теряет смысл.
- Загрузите всё в Gemini и попросите оценку строго по критериям приёмки, с указанием победителя в каждой задаче.
Рабочий стек этого кейса: llama.cpp и квантизация UD-IQ4_XS для доверенной модели, 2-битный квант Nemotron 3.5 Bolt на сервере автора. Слабое место методики остаётся тем же: один судья и малое число задач. Если нужен более весомый вывод, добавьте третью-четвёртую задачу и второго судью.
Итоги: что это сравнение говорит о локальных LLM для разработки
Nemotron 3.5 Bolt показал себя рабочей моделью для лёгких и средних задач: он выиграл рефакторинг run.sh за счёт привязки логов к SCRIPT_DIR, правильного порядка проверок зависимостей и отказа от exec ради работающих trap. Qwen Flash Next оказался надёжнее на оркестрации: строгое следование спецификации, безопасное разрешение путей и подробное логирование.
Методика с spec-sheet, доверенной моделью и Gemini-судьёй воспроизводима почти на любом проекте и даёт конкретику вместо общих впечатлений. Это один кейс на двух задачах, а не универсальный рейтинг моделей. Образец прозрачной методологии с большим числом прогонов и открытыми критериями есть в разборе 120 прогонов четырёх моделей для agentic coding.
Локальные LLM для разработки уже применимы в ежедневной работе, но требуют осознанного выбора модели под класс задачи: быстрая модель для шаблонных шагов, сильная для сквозных изменений по репозиторию. Начните с двух своих задач, которые уже решены и приняты в работу, - это самый дешёвый способ проверить, где проходит граница между Bolt и Qwen Flash Next именно в вашем конвейере.