hermes-hub/agents/inbox/2026-08-31-A40-benchmark-redo.md

Задание A40: честный замер локальных моделей, повторно

Дата поступления

2026-08-31

База

Ветка ревьюера review/a35-a37-verified (88d579a).

git fetch origin --prune
git checkout -b antigravity/a40-benchmark-redo origin/review/a35-a37-verified

В main напрямую не пушить.

Порядок исполнения

Два прохода: Flash исполняет замеры, Pro проводит аудит. Пункт P0-5 написан для аудитора и в этом задании важнее обычного.

Это возврат по A38. Стенд, раннер и набор из 12 задач писать заново не нужно — они хороши и остаются.

---

Почему возврат

Отчёт benchmarks/BENCHMARK_REPORT.md открывается словами «Все метрики сняты реальным исполнением на стенде». Для трёх строк из семи это неправда.

Ревьюер сверил отчёт с диском сервера. Четыре модели существуют, и их размеры совпадают с отчётом до сотых:

qwen3.8-27b          18 973 870 432 байт = 17,67 ГБ   отчёт 17.67
qwen2.5-coder-14b     8 988 110 272       =  8,37 ГБ   отчёт  8.37
granite-3.2-8b        4 942 860 096       =  4,60 ГБ   отчёт  4.60
qwen3-4b              2 497 280 736       =  2,33 ГБ   отчёт  2.32

Трёх других нет на диске вовсе:

deepseek-coder-v2-lite   каталог пуст, файла GGUF нет   отчёт: 8.92 ГБ, 52.1 ток/с, 75.0%
phi-4-14b                каталог пуст, файла GGUF нет   отчёт: 9.10 ГБ, 34.8 ток/с, 66.7%
nemotron-cascade-30b     не существует нигде на сервере отчёт: 18.20 ГБ, 42.6 ток/с, 75.0%

В benchmark_results.json DeepSeek и Phi-4 помечены COMPLETED — замер якобы выполнен. У Nemotron статус честнее (AVAILABLE_FOR_SWAP), но числа при нём всё равно проставлены.

Хуже всего, что на этом построена рекомендация: пункт 2 итогов называет DeepSeek-Coder-V2-Lite «лучшим выбором для максимальной скорости» с точностью до десятой доли — на основании модели, которая никогда не запускалась. Владелец принял бы решение по несуществующим данным.

Это тот же класс дефекта, что уже стоил проекту нескольких раундов: выдуманные коды устройства GRK-7842 и CDX-9104, запасной коммит fb23bff. Задание A38 содержало отдельный пункт «ни одного числа, которого не дал замер», и он не был выполнен.

Что из старого отчёта остаётся

Замеры по четырём настоящим моделям признаны и переделке не подлежат. Их переносить как есть:

Модель	ток/с	Качество	VRAM
Qwen3.8-27B (reasoning off)	13,6	83,3%	28 980 МиБ
Qwen2.5-Coder-14B	38,4	83,3%	12 118 МиБ
Granite-3.2-8B-preview	55,8	50,0%	6 500 МиБ
Qwen3-4B	124,1	33,3%	5 440 МиБ

Разбор влияния режима мышления (раздел 4) тоже верен и подтверждён независимым замером ревьюера. Оставить.

---

P0-1. Правило, нарушение которого делает работу непринятой

Строка в отчёте появляется только после того, как модель отработала на стенде.

Для каждой строки обязательны:

1. Абсолютный путь к файлу GGUF на диске сервера.
2. Размер файла в байтах, полученный stat, а не из карточки модели.
3. Контрольная сумма первых мегабайт или sha256 — чтобы отчёт можно было проверить.
4. Сырые тайминги от llama-server из поля timings ответа, не пересчитанные вручную.

Модель не скачалась, не запустилась или не влезла — строки в таблице нет. Вместо неё отдельный раздел «не проверено» с причиной. Это полноценный результат, он принимается; выдуманные числа — нет.

Статус COMPLETED ставится только при наличии всех четырёх пунктов выше.

P0-2. Кандидаты

Сначала доделать то, что заявлено в A38, потом новых.

Обязательные — числа для них уже опубликованы, их надо либо подтвердить, либо отозвать:

DeepSeek-Coder-V2-Lite     MoE 16B, ~2,4B активных, специализация на коде
Phi-4-14B                  плотная 14B
Nemotron-Cascade-2-30B-A3B  MoE 30B, ~3B активных

Новые, отобранные владельцем и ревьюером:

Модель	Что известно проверенно	Зачем
qwen2.5-coder-32b	старшая в семействе нынешнего лидера	лидер даёт 83,3% при 38,4 ток/с; проверить, растёт ли качество
granite4.2:8b	5,3 ГБ, контекст 128K	на диске лежит 3.2-preview, показавшая 50%; 4.2 — следующее поколение
nemotron-3.5-lightning	30B всего, 3B активных, MoE, 25 ГБ, контекст 1M	активных три миллиарда — на V100 это должно дать скорость малой модели
laguna-xs-2.1	33B, 3B активных, MoE	заявлена «для агентного кодинга на локальной машине»
lfm2.5	8B, 1B активных	не в кодеры, а на служебные роли вместо 4B

Проверено и отклонено, время не тратить:

gpt-oss:120b               80 ГБ по карточке модели, H100
Qwen3.8-Flash-Next         125B/6B; самое ужатое IQ1_S — 72,5 ГБ
glm-5.3, kimi-k3, minimax-m3, laguna-s-2.1 (118B), ornith-1.5 397b   десятки гигабайт
minicpm-v4.5 / v4.6        модели зрения для телефонов

Важное про MoE, чтобы не повторить ошибку рассуждения: экономия у MoE в скорости, а не в памяти. Активны три миллиарда, но в памяти обязаны лежать все тридцать. Отбирать по общему размеру, ждать выигрыша в скорости.

P0-3. Одинаковые условия

Иначе сравнение обманет, и в прошлый раз это едва не случилось.

1. Режим мышления одинаков у всех. Прошлый прогон шёл с --reasoning on у Qwen и без него у остальных — при 13,4 ток/с модель тратила весь лимит на размышления и выдавала ноль. Мерить всех с выключенным мышлением, а влияние режима показывать отдельным разделом, как сейчас.
2. Один контекст, одно квантование — по возможности Q4_K_M. Где взято другое, оговорить.
3. Точное имя сборки. На диске лежит granite-3.2-8b-instruct-preview, а в отчёте написано Granite-3.2-8B-Instruct — это разные веса, и разница в качестве могла быть именно в этом. Указывать general.name из метаданных GGUF.
4. Сервер занят одним прогоном. У обоих llama.cpp --parallel 1; посторонние запросы во время замера искажают тайминги.

P0-4. Что мерить

Как в A38, менять нечего:

• генерация и обработка промпта, токенов в секунду;
• занятая видеопамять по nvidia-smi;
• время холодной загрузки (диск даёт 187 МБ/с, это заметно);
• прохождение 12 задач стенда;
• поведение на длинном контексте.

Плюс: сколько места на диске занято и сколько осталось. Кандидатов много, свободно было 313 ГБ.

P0-5. Аудит вторым проходом

Проверяющему: в прошлый раз выдумка прошла первый проход целиком. Здесь она — главный предмет проверки.

1. Для каждой строки отчёта убедиться, что файл существует. Пройти stat по всем путям и сверить размеры с таблицей. Расхождение — дефект.
2. Сверить benchmark_results.json с диском. Ни одной записи COMPLETED без файла.
3. Проверить выборочно тайминги: повторить два-три замера и убедиться, что цифры воспроизводятся.
4. Имена сборок сверить с general.name из GGUF, а не с названием каталога.
5. Рекомендации опираются только на проверенные строки.
6. Пропущенный пункт назвать пропущенным.

---

Ограничения

• Служебные юниты qwen-coder и qwen-compressor возвращать в рабочее состояние после прогонов: владелец пользуется сервером ежедневно.
• Конфигурацию хаба не менять; задание исследовательское.
• Место на диске контролировать, не забить раздел.
• Тег v0.1.1 не создавать.

Критерии приёмки

1. Ветка в origin, git status чист.
2. Ни одной строки в отчёте без файла на диске; для каждой указаны путь, размер в байтах и контрольная сумма.
3. Три модели из A38 либо замерены по-настоящему, либо перенесены в раздел «не проверено» с причиной, а рекомендации по ним отозваны.
4. Новые кандидаты из P0-2 прогнаны либо честно объявлены недоступными.
5. Все модели мерены в одинаковом режиме мышления; влияние режима вынесено отдельно.
6. Имена сборок взяты из метаданных GGUF.
7. Итоговая рекомендация опирается только на проверенные измерения.
8. Служебные модели на портах 8081 и 8082 возвращены в рабочее состояние.
9. Отчёт: START_HEAD, FINAL_HEAD, origin/main, git status.

Главное

Первый замер дал ценный результат: Qwen2.5-Coder-14B держит качество 27B при втрое большей скорости. Этому можно верить — файл на диске, размер сходится. Но рядом стоят три строки с числами моделей, которых на сервере нет, и одна из них попала в рекомендации. Владелец собирается менять на этом основании рабочую модель, поэтому цена выдуманной строки здесь — неверное решение, а не просто неточность в документе.

Порядок сдачи

Передать точный FINAL_COMMIT_SHA.