Сравнивать модели честно можно только при трёх условиях: одна и та же задача, один и тот же харнесс и одинаковый уровень усилий. Всё остальное — сравнение обвязок, а не моделей. Ниже — метод, собранный по разбору шестистороннего бенчмарка Qwen3.8-Flash-Next против Opus 5.5 на реальной фиче из роадмапа LlamaStash.
Почему обычные сравнения моделей врут
Большинство сравнений моделей измеряют не модель, а разницу в инструментах и настройках. Автор бенчмарка прямо пишет: в прошлом посте ему указали, что сравнивать Flash-Next и Opus с разными харнессами и разными уровнями усилий нечестно. Это типичная ошибка — модель, запущенная в Claude Code с максимальным reasoning, и та же модель в простом чате дают несопоставимые результаты.
Что ломает чистоту эксперимента:
- Разный харнесс. Агентный инструмент сам читает файлы, правит код и запускает тесты — половину работы делает обвязка.
- Разный уровень усилий. Больше шагов рассуждения = другие результаты на той же модели.
- Разное железо и квантование. Локальная модель в Q4 и облачная в полной точности — не один и тот же испытуемый.
- Один прогон. Одна удачная или неудачная попытка ничего не говорит о стабильности.
Метод: как поставить честный бенчмарк на реальной задаче
Честный бенчмарк — это фиксированная задача из реального роадмапа, одинаковые условия для всех участников и минимум два прогона на каждую комбинацию. В разборе взяли настоящую фичу из роадмапа LlamaStash: сохранять KV-кэш llama-server перед выгрузкой модели и восстанавливать его, когда модель возвращается. Это не синтетическая задачка, а работа, которую кто-то действительно собирался делать.
Шаги:
- Выберите задачу из реального роадмапа. Не «напиши функцию сортировки», а фича, которую вы бы иначе делали руками. Так вы заодно получаете рабочий код.
- Зафиксируйте постановку. Один и тот же текст задачи для всех прогонов, без подсказок под конкретную модель.
- Уравняйте харнесс. Все модели гоняются в одном инструменте — в разборе это Claude Code, чтобы обвязка не давала форы.
- Уравняйте усилия. Одинаковый уровень reasoning и одинаковый лимит шагов.
- Зафиксируйте окружение. Локальная модель — на одном железе и одном кванте (в примере — Flow Z13 на Strix Halo, запуск через Halogen, примерно Q4).
- Гоняйте каждую комбинацию дважды. Один прогон — это шум, два — уже сигнал о стабильности.
- Сравнивайте PR, а не впечатления. Смотрите на диффы, прохождение тестов и объём ручных правок.
Пример с числами: шесть комбинаций, двенадцать PR
В разборе получилось шесть комбинаций «модель × условия», каждая прогнана дважды — итого 12 пул-реквестов на одну и ту же фичу. Участники: Qwen3.8-Flash-Next локально на ноутбуке Flow Z13 (Strix Halo) через Halogen в примерно Q4-квантовании и Opus 5.5. Задача одна для всех: сохранение и восстановление KV-кэша llama-server при выгрузке и возврате модели.
Что это даёт на практике: вместо спора «какая модель умнее» вы получаете 12 диффов на одну задачу и видите, где локальная модель в Q4 дотягивает до облачной, а где разваливается. Это и есть ответ на вопрос, стоит ли платить за облако или хватит своего железа — подробнее про порог входа по памяти в материале Сколько VRAM нужно для локальной LLM.
Что может пойти не так
Бенчмарк разваливается по трём причинам: разъехались условия, мало прогонов или задача не из реальной жизни. Даже аккуратный разбор на шесть комбинаций остаётся единичным замером — он показывает поведение на одной фиче, а не рейтинг моделей.
Типичные грабли:
- Модель в другом инструменте ведёт себя иначе. Один и тот же код в разных харнессах отличается — об этом отдельный разбор Почему одна и та же модель кодит по-разному в разных инструментах.
- Квантование съедает качество. Локальный Q4 и облачный оригинал — разные модели по факту.
- Задача слишком лёгкая. Если фича делается за один шаг, разница между моделями не проявится.
- Нет критерия приёмки. Без тестов и чёткого «готово» вы будете сравнивать красоту диффов, а не результат.
Как перенести метод на свою работу
Начните с одной задачи из своего бэклога и двух моделей — этого достаточно, чтобы получить полезный сигнал. Не гонитесь за десятком участников: важнее одинаковые условия и повторные прогоны.
Минимальный набор: реальная фича, один харнесс, одинаковые усилия, два прогона на модель, тесты как критерий приёмки. Дальше — по желанию расширять. Если работаете с агентами, пригодятся правила постановки из Как делегировать задачу ИИ-агенту по схеме «цель → шаги → проверка».
Частые вопросы
Сколько прогонов нужно для честного сравнения? Минимум два на каждую комбинацию — один прогон не отличает случайную неудачу от стабильного поведения. В разборе на шесть комбинаций ушло 12 PR.
Можно ли сравнивать локальную модель с облачной? Да, но фиксируйте квантование и железо. Локальный запуск в примерно Q4 и облачный оригинал — не идентичные испытуемые, и это надо держать в голове при выводах.
Почему нельзя брать разные харнессы? Потому что тогда вы измеряете разницу инструментов, а не моделей. Один харнесс для всех участников — базовое условие эксперимента.
Больше разборов по ИИ и автоматизации — в канале: @il_chum