Вступление (и сразу оговорки)

Привет, Хабр.

Меня зовут Лазутин Алексей, я не профессиональный разработчик. SEO, аудиты сайтов, куча рутины с CSV, curl, отчётами для программистов — вот мой цех. Код для себя пишу «как умею»: скрипты, Docker, копипаста с LLM. Если в архитектуре что-то покажется странным — вы, скорее всего, правы. Это не учебник по Python, а честный отчёт эксперимента, который мне самому было интересно повторить.

Недавно на Хабре вышла статья «Qwen3.6 27B MTP… с 60 t/s до 130 t/s» — про Multi-Token Prediction, спекулятивное декодирование и то, что на чистой генерации кода MoE-модель с MTP может ускориться примерно в полтора–два раза без потери качества (lossless, если верить разбору sampling.cpp в llama.cpp).

Я подумал: у меня как раз Qwen3.6-35B-A3B в LM Studio, плюс домашний агент Hermes в Docker — тот же стек, о котором пишут в духе «выжать больше из локальных LLM», только у меня не «один промпт в чат», а многоходовый агент с терминалом и файлами.

Вопрос был простой: если включить MTP-вариант модели, станет ли быстрее и лучше то, чем я реально пользуюсь каждый день?

Спойлер: в сырых t/s я не мерил. Я собрал свой бенчмарк агентских задач и дважды прогнал его — и цифры получились не такие, как в брошюре про MTP.

Откуда вообще Hermes и зачем бенчмарк

Hermes у меня — это обёртка: Hermes Agent в Docker ходит в LM Studio на Mac (host.docker.internal:1234). Профили под SEO-аудиты, handoff для разработчиков, legal-проверки — отдельная история.

Для сравнения моделей я не хотел «на глаз» спрашивать «напиши скрипт» и радоваться красивому ответу. Нужно было:

1. Одинаковая среда — тот же Docker, те же toolsets, те же промпты.

2. Объективный score — не «мне понравилось», а «файл есть, в SQLite ≥20 https-строк, в JSON есть ключи».

3. Время в контексте агента — не только токены/сек, а wall-time (сколько я реально ждал) и сумма API latency из логов Hermes.

Так появился каталог hermes-data/benchmarks/ и команда:

./benchmark-qwen-models.sh

Это 7 задач × 2 модели = 14 прогонов через docker compose run … hermes chat. Каждый прогон — отдельная папка workspace/benchmarks/run-<дата-время>/ с артефактами, логами, REPORT.md и summary.csv.

Я не претендую на MMLU, HumanEval или SWE-bench. Это мой рабочий срез: файлы, терминал, немного сети, чуть SQL — то, что агент делает у меня в SEO/аналитике.

Что за тесты и почему именно такие

Список задач лежит в tasks.yaml (suite qwen-hermes-agent-v1). Идея: не болтовня, а tool calling — Python, CSV, curl, SQLite, regex, JSON, короткое резюме.

Фикстуры синтетические — вымышленные домены, учебный лог, статья. Юнит-тесты пакета гоняются без Docker и без интернета; сеть нужна только task3.

Score считает scoring.py: веса задач, чекеры (files_exist, python_syntax, sqlite_https_count, json_keys, …). Итог — процент пройденных проверок. Пересчитать без Hermes:

./benchmark-qwen-models.sh --score-only RUN_DIR SLUG

Метрики времени:

• wall Σ — сколько ждал шаг целиком (Docker + Hermes + tools + LM Studio);

• API Σ — сумма latency= из agent.log по сессии;

• api_calls / tool_calls — сколько раз модель «ходила в круг» (каждый tool ≈ новый chat completion в LM Studio — кто видел лог LM Studio, тот поймёт, почему там сотня строк «Prompt processing progress»).

Сравниваю две модели в LM Studio:

• Базовая: qwen/qwen3.6-35b-a3b

• MTP: qwen3.6-35b-a3b-mtp

Два прогона: «уставший вечер» и «свежее утро»

Я специально оставил два полных прогона — не усреднял в один красивый отчёт.

Прогон 1 — run-20260522-235929 (конец дня)

LM Studio и модели уже целый день крутились — агентские задачи, аудиты, не один чат.

Быстрее по API — базовая (~23 с экономии).

По задачам:

• Базовая провалила SQLite (файлов .db и .txt нет) и JSON-агрегацию (нет task6_summary-….json).

• MTP закрыла все 7 задач на 100%.

На этом месте можно было бы написать: «MTP умнее, берите MTP». Но смотрим на время: MTP медленнее по wall и по API, при том что tool calls совпали. То есть ускорение «в 2 раза» из статьи про MTP сюда не перенеслось — зато выросло число API-вызовов (36 против 30).

Прогон 2 — run-20260523-131304 (после перезапуска и обновления LM Studio)

Утром: перезагрузил LM Studio, подтянул обновление, снова ./benchmark-qwen-models.sh.

Снова быстрее API у базовой (~40 с).

Что изменилось по сравнению с вечером:

• Базовая — тот же 76.5%, но быстрее (меньше нагрузка на GPU/кэш?).

• MTP — score упал с 100% до 88.2%: снова нет SQLite у обеих моделей; у базовой дополнительно отвалилась regex-задача (файл не прошёл проверки), у MTP regex уже ок.

• У MTP ещё больше API-вызовов (42) и tool calls (32) — агент «крутится» дольше, хотя MTP как раз должен ускорять генерацию токенов, а не число ходов.

Стабильный провал обоих прогонов — task4 (SQLite). Значит, это не «MTP плохой», а сложное место для агента: много шагов, execute_code, пути только под /opt/data/, легко не дописать файлы до конца лимита ходов.

Чем мой бенчмарк отличается от t/s на Habr

В статье про MTP замеры — один длинный промпт, llama-server, --spec-type draft-mtp, задачи «код / перевод / сочинение». Там MTP на Dense даёт до ~2× на коде, на MoE — скромнее, иногда деградация на «творчестве».

У меня другой слой:

Промпт → Hermes → tool (terminal / file / code) → снова модель → … → артефакты на диске → автопроверка

Здесь скорость = f(число ходов, размер контекста, тормоза Docker, LM Studio verbose, усталость GPU). MTP ускоряет один forward pass, но если агент на MTP делает на 40% больше API calls (42 vs 27 во втором прогоне), итоговый wall-time может стать хуже, даже при lossless-токенах.

Это ближе к духу «генератор тестов на LLM» — инструмент под свою рутину, а не универсальный ML-бенчмарк — только у меня рутина не Postman, а SEO-агент с файлами.

Как устроен pipeline (для тех, кто захочет повторить)

Кратко, без лекции по FastAPI:

• benchmark-qwen-models.sh → Python pipeline.py (preflight: Docker, образ, LM Studio).

• Промпты: hermes-data/prompts/benchmark-qwen/*.txt, плейсхолдеры {{RUN_DIR}}, {{MODEL_SLUG}}.

• Каждый шаг — docker compose run + парсинг agent.log (log_parse.py, metrics_io.py).

• На выходе: REPORT.md, metrics.json, summary.csv, SCORES-<slug>.json.

Тесты обвязки без железа:

./test-benchmark.sh

Полный suite — примерно час–два терпения (в README честно: один шаг Hermes ≈ 2–15 минут). LM Studio держит одну модель в GPU — параллельно две не гонял.

Переменные, если модели называются иначе:

HERMES_BENCH_MODEL_BASE='qwen/qwen3.6-35b-a3b' \

HERMES_BENCH_MODEL_MTP='qwen3.6-35b-a3b-mtp' \

./benchmark-qwen-models.sh

Выводы (личные, не научные)

1. MTP в llama.cpp и MTP в «агент + LM Studio + tools» — разные истории. У меня MTP не стал быстрее по wall/API; во втором прогоне был медленнее и более болтлив по числу вызовов.

2. Качество по score плавает между прогонами (100% → 88.2% у MTP), при этом базовая стабильно 76.5% — оба раза те же дыры, плюс утром ещё regex у базовой. Это напоминание: одного прогона мало, особенно после «целый день гоняли нейросеть».

3. Самый показательный провал — SQLite (task4) у обеих моделей во втором прогоне и у базовой в первом. Наблюдение: если оцениваете агентов для автоматизации — именно многошаговые «сделай БД и положи файл» ломаются чаще, чем «напиши hello world».

4. Статья про MTP остаётся правдой в своём измерении (t/s, lossless, llama-server). Я не опровергаю Shannon — я добавляю слой: «а у вас это в агенте?»

5. Я не разработчик, но собрать воспроизводимый suite оказалось реальнее, чем читать реддит, вручную сравнивать и делать вывод «вчера вроде быстрее». LLM помогали писать Python для scoring и тестов — как в истории про TGS, только проект мой и заточен под Hermes.

P.S. для редакторов и комментаторов

• Железо в статью не включал — у меня Mac Studio Apple M4 Max 128 гб + LM Studio.

• Репо — код suite, промпты и оба прогона (логи, REPORT.md, summary.csv): https://github.com/exelens/hermes-qwen-benchmark