Это исходный отчёт фазы как есть — со всеми таблицами и методикой. Живая версия: 💬 Языковые модели.

Фаза 5: LLM — typed output, вызов инструментов и качество на русском

Прогон: 19–20 октября 2026
Хост: UGREEN DXP4800 Pro, i3-1315U, 32 GB, iGPU Intel RPL-U (Xe-LP, 64 EU)
Что меряли: насколько надёжно локальные LLM возвращают JSON заданной структуры, вызывают команды Home Assistant и справляются с русским текстом. Отдельно проверено, дают ли модели Вихря выигрыш против своих базовых моделей.

Коротко

• Ответ в заданной структуре JSON стабильно получается у всех моделей, если делать две вещи: передавать схему через response_format: json_schema и писать в pattern [0-9] вместо \d.
  • В таком режиме все 14 моделей дали 100% ответов, проходящих JSON Schema.
  • Без замены \d грамматика llama.cpp молча не проверяет форматы. Маленькие модели тогда пишут «89641508629» вместо «+79641508629» и «08.02.2026» вместо «2026-02-08», валидно только 71–75% ответов.
• По точности извлечения лидеры почти идеальны: 98.5–99.3% полей, 92–96% документов без единой ошибки.
  • Лучше всех Gemma 4: 96% документов без ошибок (см. ниже про флаги).
  • Затем Qwen3.6-35B-A3B, gpt-oss-20b, Qwen3-8B и Mistral-Small 24B: 99.3% полей, 92% документов.
  • На документ они тратят 18–22 с, Mistral 49 с.
  • Быстрее при чуть меньшей точности: Ling 3.0 Tiny (98.1%, 6 с) и Qwen3.5-4B (97.8%, 14 с).
  • Выдумывают значения вместо null редко: 0–4 из 11 полей.
• Команды Home Assistant лучше всех выполняет Qwen3.5-4B: 40 из 40 верно, медиана ответа 6.6 с, 4.7 GiB.
  • Qwen3-4B, Qwen3-8B и QVikhr-3-8B ошиблись в одной команде из 40.
  • Ling 3.0 Tiny отвечает быстрее всех (2.6 с), но понял «Погаси свет» как «включи».
  • gpt-oss в двойных командах выполняет только первую половину.
  • Mistral-Small переспрашивает там, где можно действовать.
• Лучшее качество на русском у Qwen3.6-35B-A3B: Belebele 94%, MMLU 89%, MGSM 90%, 8.7 tok/s, 17.8 GiB.
  • Рядом Gemma 4 (94 / 85 / 85) и gpt-oss-20b (88 / 84 / 85).
  • Mistral-Small и Vistral (24B, dense) дают 92 / 80–81 / 82–88, но генерируют всего 2.5 tok/s.
• Вихрь не даёт выигрыша против своих базовых моделей.
  • QVikhr-3 1.7B, 4B и 8B на извлечении JSON на 1.5–3.3 п.п. хуже Qwen3. На командах HA на 0–10 п.п. хуже, на MGSM на 2–5 п.п.
  • Заметный плюс только на MMLU у маленьких моделей: +11 у 1.7B и +7 у 4B. У 8B уже −2.
  • Vistral-24B по знаниям равен Mistral-Small-3.2 (MMLU +1, MGSM +5, то есть две задачи из 40), но не вызывает инструменты вообще: 10% против 85% у базовой модели. На команды он отвечает текстом «Включаю свет на кухне», а вызова нет.
• Gemma 4 26B-A4B точнее всех разбирает документы, но на этой сборке llama.cpp и этом iGPU работает только с обходными флагами.
  • 96% документов без единой ошибки, 100% валидного JSON на JSONSchemaBench, 39 из 40 команд HA, Belebele 94%, MMLU 85%.
  • Без --swa-full она выдаёт мусор, а запросы с грамматикой вешают iGPU.
  • С --swa-full ломается переиспользование кэша промпта, и приходится отключать его совсем. Тогда каждая команда HA заново обрабатывает 2K токенов и занимает ~30 с.

Как мерили

• Модели: 14 GGUF-файлов.
  • 6 из прошлого llm-bench.
  • 4 модели Вихря и их базовые модели в той же квантизации Q4_K_M:
    • QVikhr-3 1.7B / 4B / 8B против Qwen3 1.7B / 4B / 8B;
    • Vistral-24B против Mistral-Small-3.2-24B.
• Сервер: llama.cpp server-vulkan, build 11718 (sha256:7f8b8664…).
  • Параметры как в llm-bench: -c 8192 -np 1 -ngl 99 -fa off -t 2 --jinja.
  • Плюс --cache-ram 0 (см. «Заметки для фреймворка»).
  • Рассуждение выключено (--reasoning off) там, где модель это позволяет:
    • gpt-oss выключить рассуждение не даёт, поэтому reasoning_effort: low и запас 1024 токена;
    • у LFM2.5 стоит --reasoning-budget 0;
    • у Gemma 4 добавлен --swa-full, без него запросы с грамматикой вешают iGPU.
• Запросы: temperature 0, seed 42, по одному.

• Typed output. 24 синтетических документа (make_extract.py) с известным правильным JSON и JSON Schema. Ловушки:

  • «1 250,50 ₽» и «8,5 млн руб.»;
  • «1 ч 15 мин» → 75;
  • «18 октября 2026 г.» → 2026-10-18;
  • телефоны → +7XXXXXXXXXX;
  • русские описания → английские enum («течёт смеситель» → plumbing);
  • 11 полей, которых в тексте нет и где нужен null.

  Два режима: - A — схема только в промпте; - B — response_format: json_schema, грамматика llama.cpp. - Вызов инструментов. 40 русских голосовых команд (make_ha.py) и 13 инструментов в формате HA LLM API. Среди команд: - двойные («выключи свет на кухне и в коридоре»); - с параметрами (яркость, температура, громкость, таймер); - 4 фразы, где вызывать ничего не нужно, включая несуществующий «свет в ванной».

  Проверяется только первый ответ модели, сами инструменты не выполняются. - JSONSchemaBench. 12 реальных схем из JSONSchemaBench (MIT), задача — сгенерировать валидный пример. - Качество на русском: - Belebele rus_Cyrl — 100 вопросов на понимание прочитанного; - Global-MMLU ru — 100 вопросов по 11 предметам; - MGSM ru — 40 задач. - Воспроизведение: - данные: make_extract.py, make_ha.py, prepare_public.py; - на NAS: run_llm.sh <модель> [наборы] [N], run_matrix.sh; - клиент llm_client.py, оценка score_llm.py; - сырые ответы лежат в raw/, таблицы генерирует python3 make_report.py.

Typed output: извлечение в JSON

24 синтетических русских документа (счета, заявки, письма о встречах, рецепты, объявления, отзывы) с известным правильным JSON. A — схема только в промпте, B — response_format: json_schema (грамматика llama.cpp), C — то же, но в pattern вместо \d написано [0-9] (грамматика llama.cpp \d молча пропускает). «Валидно» — ответ разобран и проходит JSON Schema; «поля» — доля верных полей (числа ±0.01, даты, enum и телефоны точно, имена нечётко); «документ» — доля документов без единой ошибки; «выдумано» — сколько из 11 полей, которых в тексте нет, модель заполнила вместо null (режим C).

Вызов инструментов: команды Home Assistant

40 русских команд, 13 инструментов в формате HA LLM API (HassTurnOn, HassLightSet, HassClimateSetTemperature, ...). «Верно» — набор вызовов совпал с ожидаемым (инструмент, устройство или комната, параметры); «инструмент» — хотя бы выбран нужный инструмент; «лишние вызовы» — сколько из 4 фраз без команды (спасибо, как дела, несуществующий свет в ванной...) модель всё равно что-то вызвала. «Ответ» — медиана времени ответа на команду (обработка промпта ~2K токенов с описанием дома + генерация).

JSONSchemaBench: реальные схемы

12 схем (6 Glaiveai2K, 6 Github_medium), задача — сгенерировать валидный пример. B — с грамматикой; «не поддержано» — llama.cpp отказался превращать схему в грамматику.

Качество на русском

Belebele — понимание прочитанного (100 вопросов, 4 варианта, случайный ответ = 25%), Global-MMLU — знания по школьным и вузовским предметам (100), MGSM — арифметические задачи с рассуждением (40). Для Belebele и MMLU два числа: с грамматикой, которая разрешает ответить только буквой (это знание), и свободный ответ на просьбу «одной буквой» (это ещё и послушность формату; ответ засчитывается, только если начинается с буквы или после «Ответ:»). н/п — сервер не принял грамматику для этой модели (LFM2.5: «Unexpected empty grammar», gpt-oss: ответ не совпал с грамматикой из-за формата рассуждения). Рассуждение выключено везде, где модель это позволяет. tok/s — генерация на MGSM, симв/с — видимого ответа; сравнивать удобнее символы, токенизаторы у моделей разные. RAM — пик за весь прогон.

Вихрь против базовой модели

Разница «Вихрь − база» в процентных пунктах на тех же задачах и в той же квантизации. Плюс — Вихрь лучше.

Выводы и рекомендации

Что ставить

Что видно в цифрах

• Грамматика гарантирует синтаксис, но не форматы. Режим B (json_schema) по сравнению с A (схема в промпте) поднимает валидность маленьких и MoE-моделей (Ling 83 → 92%), но пока в pattern стоит \d, телефоны и даты не проверяются.
  • С [0-9] (режим C) валидно 100% ответов у всех, и точность полей тоже немного растёт (Qwen3-1.7B 94.1 → 95.5%).
  • У больших моделей ответы A, B и C совпадают: при жадной генерации они и так пишут правильный JSON.
• Грамматика может загнать модель в бесконечную строку. В одной схеме JSONSchemaBench есть строковое поле без ограничения длины. Под грамматикой 8 моделей из 14 (все Qwen3/QVikhr-3, Mistral-Small, Ling) зациклились на нём и выдали вроде «jZ2dna2NjZ2d…» до лимита токенов. Qwen3.5, Qwen3.6, gpt-oss, Gemma 4, LFM2.5 и Vistral закончили нормально. В своих схемах стоит задавать maxLength.
• Типичные ошибки извлечения:
  • лишние элементы в списках («торг уместен» в преимуществах квартиры);
  • выдуманная дата визита или время окончания встречи, которых в тексте нет;
  • неверная срочность заявки (normal вместо low);
  • у LFM2.5 лишние цифры в телефонах («+7907129015400») и цена «4990» вместо 4 990 000.
• Команды HA. Ошибки делятся на три вида:
  • опасные: не то действие (Ling: «погаси» → включить), не то устройство (LFM: «включи кондиционер» → обогреватель), несуществующее устройство (Qwen3.6: «свет в ванной»);
  • неполные: gpt-oss в ответ на двойную команду делает один вызов. В реальном цикле агента он, скорее всего, сделал бы второй после результата первого, но здесь проверялся только первый ответ;
  • осторожные: Mistral спрашивает «в какой комнате включить кондиционер?», хотя кондиционер один.
• Свободный ответ и знание — разные вещи. Qwen3-1.7B на просьбу «ответь одной буквой» почти всегда начинает рассуждать, и в свободном режиме набирает 21% на MMLU. С грамматикой, которая разрешает только букву, он набирает 34%. У Qwen3-8B в свободном режиме перекос к ответу «D» (47 из 100 при 28 правильных).
• Скорость.
  • Генерация: MoE-модели 8–24 tok/s, 4B около 10–11 tok/s, плотные 24B 2.5 tok/s.
  • На команду HA уходит 2.5–10 с (у плотных 24B 8–16 с), если системный промпт (~2K токенов с описанием дома) уже в кэше слота. Без кэша на 4B только обработка промпта занимает ~22 с.

Вихрь против базовых моделей

• QVikhr-3 1.7B / 4B / 8B. Скорость и память те же, что у Qwen3. Извлечение JSON и вызов инструментов у них немного хуже, MGSM на 2–5 п.п. хуже. MMLU у маленьких лучше (+11 и +7), у 8B нет. На Belebele у 8B с грамматикой −10, в свободном режиме −1.
• Vistral-24B. Знания и извлечение на уровне Mistral-Small-3.2: 19 из 24 ответов JSON побуквенно совпали. Вызов инструментов сломан: через --jinja с шаблоном из GGUF модель отвечает текстом и ни разу не вызывает инструмент.
• Ограничение сравнения. GGUF Вихря взяты из репозиториев Vikhrmodels, базовые модели — от Qwen, unsloth (Qwen3-1.7B, Mistral-Small). Номинально квантизация одна (Q4_K_M), но детали квантования (imatrix) могут отличаться.

Ограничения

• Синтетические документы однотипны внутри каждого вида (4 на вид). Точность полей отражает, как модель обращается с такими ловушками, а не со всеми возможными документами.
• Команды HA проверены на одном шаге. Инструменты не выполнялись, и модель не видела их результата.
• Выборки маленькие: 100 вопросов Belebele и MMLU, 40 задач MGSM. Разница меньше ~5 п.п. на 100 вопросах и ~10 п.п. на MGSM в пределах шума.
• Рассуждение выключено. gpt-oss рассуждает всегда (reasoning_effort: low), у остальных с рассуждением ответы были бы точнее, но медленнее.

Заметки для фреймворка

• --cache-ram 0. С кэшем промптов в RAM, который включён по умолчанию (8 GiB), каждый запрос с другим промптом на этом iGPU получал ~10 с лишней задержки: сервер считал 1–3 с, клиент ждал 11–13 с. С --cache-ram 0 задержка равна времени сервера. Переиспользование префикса внутри слота работает и без него: вторая команда HA с тем же системным промптом обработала 2062 из 2082 токенов из кэша.
• Gemma 4 на этой сборке (11718) и Intel iGPU.
  • Без --swa-full: ответы — мусор («de de») или пустые, а запросы с грамматикой вешают GPU. В журнале ядра «i915: context reset due to GPU hang», в llama-server ErrorDeviceLost, после чего сервер падает. Уменьшение -ub не помогает.
  • С --swa-full: первый запрос нормальный, но после переиспользования длинного кэшированного префикса все следующие ответы пустые (модель сразу выдаёт конец ответа). Помогает только cache_prompt: false в каждом запросе, ценой полной обработки промпта каждый раз.
  • В llm-bench (build 11706, без --cache-ram 0 и без грамматики) Gemma отвечала нормально. Что именно ломается здесь — сборка или сочетание флагов, — не выяснял; стоит проверить на более новой сборке.
• У LFM2.5 и gpt-oss нельзя ограничить ответ грамматикой root ::= [ABCD]. Сервер отвечает HTTP 500: у LFM «Unexpected empty grammar», у gpt-oss ответ не совпадает с грамматикой из-за канала рассуждения. json_schema у них при этом работает.
• llama.cpp молча пропускает \d в pattern. В логе «unsupported escape: \d, accepting any string», то есть грамматика такое поле не проверяет. В схемах для llama.cpp нужно писать [0-9], а ответ всё равно валидировать в коде.