«Интеллект в секунду»: почему самая умная модель не всегда решает задачу быстрее

Не «кто умнее», а «кто быстрее приходит к верному результату»

13 сентября 2026 года в блоге Hugging Face вышла авторская статья Sonny DeSorbo (ник darkc0de) с заголовком, который сам автор строит как вопрос: что происходит, когда скорость начинает мешать. Это community-публикация отдельного автора, а не отчёт исследовательской группы, и в финале текста он это подчёркивает: «не стоит воспринимать всё это слишком серьёзно, это просто обмен мнениями».

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

Две Qwen — два разных ресурса

В качестве примера автор берёт пару актуальных моделей Qwen. Qwen3.8-27B — плотная модель на 27 млрд параметров; в карточке модели она описана как нативная vision-language модель, понимающая изображения и видео, с управляемым режимом размышления, предназначенная доводить сложные многошаговые задачи до конца, а её заявленные результаты — GPQA Diamond 89,2, LiveCodeBench v6 90,3 и IFBench 79,5.

Qwen3.5-35B-A3B устроена принципиально иначе: 35 млрд параметров всего и только около 3 млрд активируемых на каждый токен. Это разреженная Mixture-of-Experts архитектура, которую автор описывает как спроектированную под высокую пропускную способность при относительно низких вычислительных затратах; её опубликованные результаты — GPQA Diamond 84,2, LiveCodeBench v6 74,6 и IFBench 70,2.

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

Ожидаемое время до успеха

Простую метрику автор выводит как отношение времени одной попытки к вероятности успеха в этой попытке: ожидаемое время до успеха = время попытки / вероятность успеха. В его числовом примере модель A тратит 60 секунд на попытку и успешна в 90% случаев — это примерно 66,7 секунды ожидаемого времени; модель B тратит 20 секунд и успешна в 60% случаев — примерно 33,3 секунды.

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

Где скорость перестаёт помогать

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

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

Разная квантизация внутри одной модели

Тот же компромисс виден внутри одной модели: Q4_K_M хранит веса с меньшей точностью и обычно требует меньшей пропускной способности памяти, а Q5_K_M сохраняет больше информации из исходных весов, но расходует больше памяти. Автор ссылается на опубликованные измерения llama.cpp: для одной тестовой модели Q4_K_M дал рост перплексии примерно на 0,175 относительно базовой линии, а Q5_K_M — примерно на 0,057.

Числовой пример из текста: Q4_K_M завершает попытку за 40 секунд и успешна в 72% случаев, Q5_K_M — за 50 секунд и в 90% случаев; по формуле ожидаемое время в обоих случаях выходит одинаковым — около 55,6 секунды. Отсюда практическое правило: Q4 выигрывает, пока отношение вероятностей успеха P(Q4)/P(Q5) больше отношения времён T(Q4)/T(Q5). Если Q4 работает за 80% времени Q5, она выдерживает примерно 20-процентное относительное падение вероятности успеха, прежде чем её преимущество исчезает.

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

Что автор предлагает измерять вместо токенов в секунду

Взамен существующих бенчмарков, которые отдельно мерят точность рассуждений, отдельно пропускную способность в токенах и отдельно деградацию перплексии, автор предлагает бенчмарк Persistent Challenge Completion, сокращённо PCC. Модель получает сложную задачу с объективным валидатором, фиксированный бюджет времени по стенным часам, фиксированный набор инструментов и воспроизводимое начальное состояние и обязана продолжать работу до успеха или до истечения бюджета.

Основная метрика — Validated Work per Second, то есть количество успешно завершённых задач, делённое на общее время. Агрегат автор предлагает считать как площадь под кривой завершения, а нормализованный балл задаёт формулой (1/N) × Σ (B − tᵢ)/B, где N — число задач, B — максимальный бюджет времени, а tᵢ — момент успешного завершения задачи i; нерешённые задачи получают ноль, поэтому задача, закрытая в начале бюджета, стоит дороже закрытой у самого дедлайна.

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

Что здесь доказано, а что нет

Главное ограничение материала автор обозначает сам: это обмен мнениями в формате «AI powwow», а не отчёт об эксперименте, и никакого прогона предложенного бенчмарка PCC в публикации нет — есть только его описание и формулы. Поэтому числа вида 0,175 против 0,057 по перплексии или гипотетические 15 против 60 секунд на попытку следует читать как иллюстрации аргумента, а не как измеренный результат сравнения.

Другая часть утверждений проверяема и совпадает с первоисточником: значения GPQA Diamond 89,2 против 84,2, LiveCodeBench v6 90,3 против 74,6 и IFBench 79,5 против 70,2, а также ключевая разница архитектур — 27 млрд плотных параметров против 35 млрд всего и примерно 3 млрд активируемых — подтверждаются карточками моделей в официальном репозитории Qwen на Hugging Face. Практический вывод текста сводится к смене вопроса: не «какая модель самая умная» и не «какая квантизация самая быстрая», а «какая конфигурация даёт больше проверенной, корректной работы за единицу времени».