Зачем мы всё усложняем: разрушительный эффект гипераннализа

…Еще во время экспериментов с Qwen3.6 я поручил ей типовую задачу по интеграции (handoff) для своего SwiftUI-проекта через QWEN cli, но модель так и не справилась, зависнув в бесконечных раздумьях. В конце концов я прервал процесс и поспешил заклеймить Qwen3.6 как непригодную для подобных задач. Как выяснилось позже, вывод был преждевременным…

В предыдущем исследовании https://habr.com/ru/articles/1075706 мы оценивали производительность локальной сборки Qwen3.8-27B на Mac Studio. Вердикт оказался суровым: для комфортной интерактивной работы 27-миллиардную модель необходимо ускорять в первую очередь за счет уменьшения весов, то есть квантизации. В тандеме с DFlash2 8-битная версия достигла отметки в 38 токенов в секунду.

Однако это был лишь первый шаг.

Высокая скорость отнюдь не тождественна безупречному качеству. Особенно когда от нейросети требуется не просто пересказать текст, а расследовать инцидент, строго следовать регламенту, а также писать и верифицировать код.

Моей целью было найти не просто самый резвый вариант Qwen3.8-27B, а надежный инструмент для ежедневной разработки — такой, чтобы не приходилось ожидать ответа по целой минуте или вместо работающего решения получать убедительный бред.

План казался безупречным: берем BF16 в качестве золотого стандарта качества и сопоставляем с ним версии на 8-bit и 4-bit. А чтобы квантованные модели не спасовали в сложнейших кейсах, активируем максимальную глубину рассуждений — reasoning_effort=xhigh.

Логичная гипотеза.

Которая на практике полностью провалилась.

Кратко о тестовом стенде

Все бенчмарки запускались на Mac Studio (2025), Mac15,14: процессор Apple M3 Ultra (32 ядра CPU, 80 ядер GPU), 512 ГБ объединенной памяти и накопитель SSD на 2 ТБ.

Причины, по которым конфигурация BF16 на подобном «железе» не демонстрирует молниеносную скорость, специфика ограничений декодирования и роль DFlash2 подробно разозваны в предыдущей публикации: https://habr.com/ru/articles/1075706. Здесь мы берем эти данные за отправную точку: после первичного отбора по скорости в фокус попали три целевые модели.

Метка	Модель
BF16	mlx-community/Qwen3.8-27B-bf16
8-bit	mlx-community/Qwen3.8-27B-8bit
4-bit	mlx-community/Qwen3.8-27B-4bit

Для соблюдения чистоты эксперимента все три вариации функционировали в идентичных условиях:

• использовался единый драфт — incoai/Qwen3.8-27B-DFlash2;

• параметры: Draft Window = 2048, Draft Sink = 0, Verify Mode = adaptive;

• драфт-модель работала без квантизации;

• был задействован внутрипамятевый кэш L1;

• каждый раз через логи проверялся факт успешной загрузки и отработки DFlashEngine.

Стоит отметить, что DFlash2 выступает не отдельной самостоятельной моделью, а вспомогательным инструментом для спекулятивного декодирования (speculative decoding): она генерирует пул предварительных токенов, которые затем верифицируются основной моделью. Создатели DFlash2 позиционируют ее как block-diffusion драфт-компаньона, а не замену базовой Qwen (описание модели).

Таким образом, варьировалась исключительно степень квантизации основной сети, тогда как остальной конвейер оставался неизменным.

Как измерять качество, а не иллюзии

Доверять другой языковой модели оценку результатов — заведомо тупиковый путь. В таком случае мы просто подменяем один вероятностный вердикт другим, с серьезным видом выдавая это за точную метрику.

Поэтому я разработал специальный Python-скрипт для локального oMLX API, содержащий 28 комплексных запросов на проверку качества для каждой модели.

Семь заданий тестировали аналитические способности, умение следовать инструкциям и логику:

• управление складскими запасами, составление расписаний и обработка сценариев с перезапуском (retry);

• строгое соблюдение JSON-структуры и заданного русскоязычного формата;

• разбор инцидента и расчет совокупной стоимости владения (TCO) для поставщика.

Остальные 21 запрос были посвящены программированию: семь практических задач, каждая в трех различных профилях глубины мышления.

Направление	Задачи	Методика проверки
C#	поиск самого длинного окна, сжатие диапазонов, строгий парсер TCP-портов, LRU-кеш, детерминированное определение порядка сборки с детектированием циклов	Сгенерированный код компилируется с помощью .NET SDK и тестируется скрытыми тест-кейсами (hidden tests). Проверяются переполнения, граничные условия, последовательность, уникальность элементов и соответствие контракту API.
SwiftUI	каталог задач с поиском и фильтрацией; финансовая форма с валидацией полей	Код на Swift компилируется утилитой swiftc; скрытые юнит-тесты проверяют бизнес-логику, а валидатор контролирует присутствие необходимых UI-компонентов: View, List, .searchable, Picker, Form, TextField, Button и .disabled.

Для C# требовалось выдать исключительно целевой класс — без лишних оберток вроде namespace, метода Main, обращений к диску, сети или системным процессам. В случае со SwiftUI было недостаточно просто описать логику текстом: система ожила бы только в виде компилируемого пользовательского интерфейса с четким набором элементов.

Это фундаментальный нюанс. В реальной разработке вердикт «код в целом неплох, но контракт не соблюден» означает лишь то, что задачу придется дописывать вручную.

Здесь уместно пояснить, почему был выбран именно такой набор проверок вместо стандартных готовых бенчмарков. Как уже упоминалось, при первом знакомстве с Qwen3.6 я дал ей типовую задачу по SwiftUI, с которой та не справилась, погрузившись в бесконечные рассуждения, из-за чего я поспешил с выводами.

Готовые публичные бенчмарки я отбросил по двум причинам: во-первых, они выполнялись бы непозволительно долго, а во-вторых… я попросту не нашел готового открытого набора тестов, подходящего под мои SwiftUI-сценарии. Если вам известны подобные репозитории, буду признателен за ссылки в комментариях. Второй барьер — временной ресурс. Прогон массивных стандартных тест-сьютов затянулся бы на неопределенный срок.

Для программирования задействовались три конфигурации глубины рассуждений:

Профиль	Параметры
xhigh	максимальная интенсивность мышления, серверный бюджет по умолчанию
medium	thinking_budget=2048
low	thinking_budget=1024

У модели Qwen3.8 режим размышлений (thinking mode) активен по умолчанию, а интенсивность можно тонко настраивать через параметр reasoning_effort (официальная документация Qwen). Именно поэтому данный переключатель стал ключевым объектом нашего расследования, а не второстепенной деталью.

Общие итоги: скорость найдена, качество сохранено

Полный цикл тестирования включал 84 запроса на качество и 45 запросов на скорость (три конфигурации, каждая тестировалась в пяти повторениях для каждого сценария производительности). Перед стартом замеру предшествовал обязательный прогрев (warm-up) каждой модели.

Модель	Формальный общий балл	Успешно решено задач	Медианное сквозное время ответа (end-to-end wall time)
BF16	85,3%	24 / 28	38,91 с
8-bit	83,3%	23 / 28	21,39 с
4-bit	82,7%	20 / 28	17,77 с

Поскольку текущая версия oMLX не возвращает детальные API-метрики вроде TG/PP/TTFT, речь идет не о «чистой» скорости генерации токенов, а о полном времени выполнения запроса от начала до конца, которое в отдельных циклах включает и первичную загрузку весов в память. Для практической оценки общая тенденция очевидна, однако глубокое профилирование требует отдельного инструментария.

Версия на 4-bit оказалась примерно в 2,2 раза быстрее BF16, а 8-битная модификация — почти в 1,8 раза. На отдельных подмножествах тестов 4-битная модель ускорила общую генерацию в 3,6 раза, генерацию кода на C# — в 2,7 раза, в то время как обработка длинного входящего промпта (prefill) ускорилась всего на 1,2 раза. Это закономерно: квантизация сильнее всего разгоняет именно фазу декодирования, где веса считываются непрерывно, а не этап парсинга объемного контекста.

И здесь кроется первый важнейший вывод: 4-битная модель не деградировала на элементарных рабочих задачах. Отставание от эталонного BF16 по формальному баллу составило всего 2,6 процентных пункта, а у 8-битной версии — скромные 2 процентных пункта.

Конечно, объявлять модели абсолютно равнозначными еще рано — один прогон не дает статистической достоверности. Тем не менее, это веский повод отказаться от догмы о том, что «4-bit абсолютно непригодна для серьезных инженерных задач».

Тем более что часть выявленного отставания оказалась следствием формализма проверяющего скрипта (judge). В задаче по анализу инцидента обе квантованные модели безошибочно установили корневую причину, затронутый регион и таймстампы, однако в качестве аргументации сослались на логи E1, E5, E6, в то время как валидатор ожидал строго E2, E5, E6. Первый вариант рассуждений выглядит не менее логичным: он увязывает сбой с конкретным релизом, подтверждает механизм деградации и фиксирует восстановление сервиса.

Если скорректировать логику судьи, разрешив принимать оба обоснованных набора аргументов, картина меняется:

Модель	Изначальный балл	Балл после корректировки валидатора
BF16	85,3%	85,3%
8-bit	83,3%	85,3%
4-bit	82,7%	84,7%

На текущем массиве тестов заметного падения производительности у 8-bit и 4-bit версий зафиксировано не было. Для окончательных выводов требуются дополнительные итерации тестирования на более широком пуле независимых задач.

Но самый интригующий результат скрывался вовсе не в этой таблице.

Улика № 3: режим xhigh — худший тимлид

Первоначальная гипотеза звучала предельно здраво: чем сильнее сжаты веса модели, тем тщательнее нужно заставлять ее обдумывать шаги. Следовательно, для 4-bit следует жестко прописать xhigh, а возможно, и сделать этот режим дефолтным.

Эмпирические данные продемонстрировали диаметрально противоположную картину.

Профиль рассуждений	C#, BF16 / 8-bit / 4-bit	SwiftUI, BF16 / 8-bit / 4-bit
xhigh	4 / 5 · 4 / 5 · 1 / 5	1 / 2 · 1 / 2 · 0 / 2
medium / 2048	5 / 5 · 5 / 5 · 5 / 5	1 / 2 · 2 / 2 · 2 / 2
low / 1024	5 / 5 · 5 / 5 · 5 / 5	2 / 2 · 1 / 2 · 1 / 2

Активация режима xhigh ухудшила показатели абсолютно всех конфигураций. Однако сильнее всего пострадала именно 4-битная версия: ей покорилась лишь одна задача по C# из пяти и ни одна из двух задач по SwiftUI.

В конфигурации medium / 2048 модели с 4-bit и 8-bit квантизацией успешно справились со всеми 7 задачами из 7 в категории разработки. Более того, при реализации LRU-кеша на C# 4-битная вариация оказалась быстрее конкурентов: 19,94 секунды против 25,21 секунды у 8-bit и 57,53 секунды у BF16.

В этом и заключается ключевой инсайт нашего расследования.

Для нивелирования последствий квантизации уменьшенной версии модели вовсе не требуется выделять больше времени на рефлексию. Напротив, в данном технологическом стеке ей нужно ограничить пространство для бесконечных рассуждений и вовремя потребовать генерацию финального артефакта.

Что именно ломал режим xhigh

Корень проблемы крылся не в архитектурных ошибках выбора алгоритмов. В ряде сценариев нейросеть просто не доходила до стадии выдачи результата.

Яркий пример — строгий парсер TCP-портов. Задача не относится к числу сверхсложных: требуется корректно обработать значения null, пустые строки, пробелы, префиксы вроде +80, цифровые символы в Unicode, переполнения и попадание в диапазон 1...65535, вернув на выходе строго регламентированный класс C#.

В режиме xhigh модели BF16 и 8-bit уходили в пространные рассуждения, но так и не выдавали итоговую структуру Solution. Компилятор просто не получал кода для проверки.

Стоило переключиться на профили medium / 2048 или low / 1024, как обе модели успешно проходили все 13 скрытых тест-кейсов из 13. В рамках полного набора все три модификации, включая 4-bit, безупречно решили все пять задач по C# в обоих умеренных режимах рассуждений.

Аналогичная динамика наблюдалась и со SwiftUI. Часть сбоев при xhigh была связана не с логикой фильтрации или валидации форм, а с грубым нарушением контрактных требований вывода: модель забывала подключить import SwiftUI, добавляла неразрешенные директивы импорта или обрывала генерацию до того, как удавалось сформировать финальную структуру View.

Единственный реальный балл компиляции 4-битная модель в режиме xhigh потеряла из-за опечатки System.StringBuilder вместо System.Text.StringBuilder. Тем не менее, это не объясняет масштаб проблемы целиком. Главным разрушительным фактором выступал избыточный объем «размышлений», который исчерпывал лимит токенов и ломал логический переход от внутреннего анализа к написанию работающего кода.

Парадокс заключается в том, что настройка xhigh воспринимается как призыв «сделать максимально качественно», а на практике оборачивается неэффективным управлением процессом разработки. Она заставляла модель до изнеможения перебирать граничные условия, упуская из виду главную задачу: выдать компилируемый исходный код с корректным API.

Меньше бит — меньше рефлексии? Да, но с оговорками

Соблазнительно сделать обобщение: «чем компактнее модель, тем меньше ей следует размышлять». Применительно к нашему эксперименту это правило отлично описывает оптимальную настройку для 4-битной версии.

Насколько универсален этот принцип, покажут дальнейшие практические тесты нашей AI-команды на базе Qwen3.8.

Подобное поведение обусловлено несколькими вероятными факторами:

1. Режим xhigh порождает избыточно длинную внутреннюю цепочку мысли (Chain of Thought), оставляя критически мало токенов на качественное формирование финального ответа.

2. Процесс квантизации неизбежно смещает траекторию генерации; при затяжных рассуждениях малейшее отклонение накапливается, и модель теряет фокус на исходном контракте задачи.

3. В архитектуре oMLX API блок reasoning временами вторгался в зоны, где бенчмарк ожидал исключительно чистый код. Для систем автоматизации это не косметическая особенность, а критический сбой интеграции.

Первый и третий пункты были зафиксированы эмпирически. Второй пока остается рабочей гипотезой, требующей верификации в ходе повторных запусков.

Именно поэтому выбор параметров не должен строиться по принципу «чем больше, тем лучше». Конфигурацию нужно подбирать строго под конкретный рабочий сценарий.

Сценарий использования	Рекомендуемая рабочая конфигурация
Разработка на C# и SwiftUI со строгими контрактами	4-bit или 8-bit + DFlash2 + medium / 2048
Рутинные детерминированные задачи на C#	допустимо стартовать с low / 1024, но с обязательным автотестированием кода
Глубокий анализ инцидентов или критически важные модули	BF16 сохраняется как эталонный контрольный вариант; результаты подлежат экспертной перепроверке
Максимальная отзывчивость в интерактивном режиме	4-bit + DFlash2, избегая автоматического включения xhigh

Вердикт: подлинное качество обнаружилось неожиданно

Мы стартовали с привычных постулатов: BF16 гарантирует максимум качества, 8-bit — компромиссный вариант, а 4-bit неизбежно расплачивается точностью ради скорости. Предполагалось, что в случае деградации результатов исправить положение поможет усиление логического блока (reasoning).

Результаты эксперимента нарисовали куда более сложную и интересную картину.

• Квантизация до уровней 8-bit и 4-bit обеспечила колоссальный прирост производительности, не вызвав при этом катастрофического падения точности на выбранном пуле задач.

• Качество генерации нельзя оценивать субъективным визуальным восприятием текста: программный код обязан успешно компилироваться, а ответы — строго удовлетворять заданным спецификациям.

• Максимальная глубина рефлексии не стала защитным механизмом для квантованных моделей, а в сфере написания кода превратилась в фактор потенциальных сбоев.

• Оптимальным режимом для 4-битной версии оказался не xhigh, а medium / 2048: модель успешно справилась со всеми 7 задачами разработки, показав при этом минимальное время выполнения среди всех участников.

Моя текущая конфигурация для повседневной разработки выглядит так: Qwen3.8-27B-4bit + DFlash2 + reasoning_effort=medium + thinking_budget=2048. Полноразмерную версию BF16 я не сбрасываю со счетов — она удерживает статус контрольной модели и резерва для особо ответственных участков, где цена ошибки критически высока.

Главный вывод этого исследования лежит шире, чем особенности работы 4-битных моделей. Он ставит под сомнение устоявшиеся привычки взаимодействия с LLM.

Увеличение времени на размышления далеко не всегда ведет к росту качества. Особенно когда от нейросети требуется не пространная аналитика, а конкретный прикладной артефакт: корректный JSON, рабочий класс, компилируемый интерфейс или точный вызов API.

Искусственный интеллект должен не просто подолгу размышлять. Он обязан своевременно прекращать рефлексию и переходить к созданию результата.

Планы по дальнейшему исследованию

Работа далека от завершения. На очереди — расширение доказательной базы:

• устранение артефактов в валидаторе инцидентов для корректного учета альтернативных логических цепочек доказательств;

• многократное повторение тестовых прогонов с интеграцией независимых задач;

• обкатка реальных бизнес-кейсов из актуальных проектов в изолированной тестовой среде (harness);

• разделение метрик TG/PP/TTFT и сквозного времени ответа (wall time) с проведением замеров скорости изолированными блоками по моделям;

• детальная проверка работы с длинным контекстом, вызовом внешних инструментов (tool use) и критически уязвимых сценариев.

Только после завершения этого цикла можно будет с уверенностью утверждать, в каких сценариях BF16 оправдывает свою ресурсоемкость, а где 4-битная конфигурация окончательно трансформируется из смелого эксперимента в новый производственный стандарт.

 

Источник