Что показал тест: Swift-1.5-Qwen3.8-Flash-Next против базовой Qwen3.8-Flash-Next
Короткий ответ: Swift-1.5-Qwen3.8-Flash-Next сокращает «переразмышления» базовой Qwen3.8-Flash-Next без статистически значимой потери качества. Качество в агентном бенчмарке Aider остаётся на том же уровне, а расход ресурсов падает примерно в 2,5 раза.
Цифры из опубликованного теста. Прохождение с первой попытки (first-try pass): 41,1% у Swift против 40,2% у базовой модели. Медианный расход токенов на кейс: 6991 против 17646, то есть около 40%. Медианное время на кейс: 608 секунд против 1542, снова около 40%. Парное сравнение по кейсам дало 99 совпадений, 2 победы и 6 поражений, точный тест МакНемара p ≈ 0,29. Такой уровень значимости означает, что разницу между моделями нельзя отличить от случайного разброса на этой выборке: заявлять превосходство одной модели над другой по качеству оснований нет.
Тест опубликовал пользователь returnity в сообществе r/LocalLLaMA, исходная публикация с таблицами и условиями прогона лежит здесь: пост с результатами сравнительного прогона. Swift-версию модели выпустила команда UkisAI, которая строит семейство моделей на базе Qwen вокруг идеи штрафа за избыточные рассуждения, подробности о линейке собраны в разборе о релизе семейства Swift. Редакция AI-Manual собственных измерений не делала, все числа ниже взяты из публикации автора теста.
| Метрика | Qwen3.8-Flash-Next | Swift-1.5-Qwen3.8-Flash-Next |
|---|---|---|
| First-try pass | 40,2% | 41,1% |
| Медианные токены на кейс | 17646 | 6991 |
| Медианное время на кейс | 1542 с | 608 с |
| Корректный diff (well-formed) | 98,1% | 100,0% |
| Восстановление после провала первой попытки | 84% | 78% |
Как устроен бенчмарк Aider и что именно измерялось
Aider это агентный бенчмарк для кодинга: модель получает задачу, сама решает, какие файлы открыть, вносит правки и получает результат проверки. Метрики здесь отличаются от обычных «сколько задач решено».
First-try pass показывает, сколько задач решено с первой попытки, без подсказок и повторных запусков. Retry pass измеряет, как часто модель исправляет ситуацию после неудачного первого прогона. Расход токенов на кейс и время на кейс определяют стоимость агентной сессии: в цикле из сотен задач разница в 10 тысяч токенов на задачу складывается в заметные деньги и часы. Well-formed diff фиксирует, выдала ли модель корректно оформленный патч, который агент смог применить без ручной правки.
По последним двум метрикам картина разная. Swift выдал 100,0% корректных diff против 98,1% у базовой модели, то есть формат патчей у него стабильнее. Зато восстановление после неудачной первой попытки слабее: 78% против 84% у базовой. Практический смысл простой: Swift реже ломает формат ответа, но хуже выкручивается, когда первый заход не сработал.
Почему базовая модель «переразмышляет»: механизм длинных циклов
Причина разницы в расходе ресурсов лежит в поведении reasoning-циклов. Базовая Qwen3.8-Flash-Next часто уходит в длинные серии рассуждений, возвращаясь к уже пройденным шагам и заново перепроверяя то, что уже решено. Swift почти не зацикливается: он чаще останавливается на достигнутом ответе.
Именно на таких зацикливаниях и теряются токены. На 20 самых токенозатратных прогонах базовой модели Swift использовал 29% токенов и решил 16 из 20 задач против 17 из 20 у базовой. Разрыв в один кейс при экономии почти в три раза по токенам. Максимальный расход на одном кейсе: 44k токенов у Swift против 203k у базовой. Разница в 4,6 раза на худшем сценарии, и это тот случай, когда одна задача съедает бюджет целой сессии.
«Переразмышления» (overthinking) это не ошибка в ответе, а патологический паттерн рассуждений: модель многократно повторяет одни и те же шаги, сомневается в уже проверенном выводе и тратит бюджет на внутренний диалог, который не меняет финальный результат. Работа с этим паттерном, а не с длиной рассуждений напрямую, лежит в основе подхода UkisAI; механика штрафа за избыточные токены разобрана в материале о первом релизе Swift Qwen 3.8 27B.
Разбивка по языкам: где Swift экономит больше всего, а где теряет
Языки программирования дают разную экономию токенов. C++ оказался самым сжатым: Swift использовал 29% токенов базовой модели. Для Python и JavaScript этот показатель составил около 46%. Похоже, что на C++ базовая модель уходит в самые длинные циклы рассуждений, и именно там оптимизация даёт максимальный эффект.
Обратная сторона: на C++ Swift потерял 3 из 6 поражений в парном сравнении. То есть самый выгодный по токенам язык оказался и самым рискованным по качеству. Для Python и JavaScript таких потерь в разбивке не видно, там сокращение расхода выглядит безопасным.
Схожий сюжет с распределением по языкам уже всплывал в других тестах дообученных моделей: разные стратегии сокращения reasoning-циклов по-разному сказываются на C++, JavaScript и Python. Сравнение ThinkingCap и Swift на той же базе Qwen3.8-27B разобрано в отдельном материале о трёх моделях в Aider eval suite.
Условия теста: квантование, железо и контекст
Сравнение шло не на «голых» весах. Для Swift автор взял квантование Q5_K_L с Q8_0 engrams, для базовой модели - Q5_K_XL от Unsloth, тоже с Q8_0 engrams. Оба варианта укладываются в 128 ГБ памяти при контексте 262k, и, по словам автора, это лучшее качество, которое безопасно влезает в такие условия.
Из этого следуют две вещи. Первая: тест релевантен именно для локального запуска моделей такого класса на машине с большим объёмом памяти и длинным контекстом. Вторая: квантования у моделей разные, и это само по себе может давать часть разницы. Переносить цифры на другие сборки, меньшие квантования или другой контекст напрямую нельзя.
Выбор квантования вообще сильно влияет на скорость и расход токенов. Насколько велика бывает эта разница даже при одинаковом результате по задачам, видно на примере теста двух квантизаций для 16 ГБ VRAM, где модели прошли одинаковые проверки, но разошлись втрое по времени и токенам.
Ограничения и риски: что важно учесть перед переходом на Swift
Первое и главное: разница в качестве статистически незначима при p ≈ 0,29. Из теста следует сопоставимость моделей, а не превосходство Swift. Если задача требует выжать максимум качества, эти данные ничего не обещают.
Второе: Swift хуже восстанавливается после неудачной первой попытки, 78% против 84% у базовой. В длинных агентных цепочках, где ошибка на раннем шаге ломает весь прогон, это может съесть часть выигрыша по времени.
Третье: на C++ потеряно 3 из 6 поражений. Для проектов с плотной работой на C++ экономия токенов меньше не станет, а вот риск неудачи вырастет.
Четвёртое: тест шёл на одном бенчмарке, на конкретных квантованиях и в одной конфигурации памяти. Aider измеряет агентный кодинг, а не рассуждения в общем виде, не работу с длинными документами и не RAG-пайплайны. Переносить выводы на эти сценарии без собственной проверки не стоит, о чём говорит и сам автор публикации с результатами.
Кому и когда стоит использовать Swift-1.5-Qwen3.8-Flash-Next
Swift имеет смысл там, где важны скорость и бюджет токенов, а стек сводится к Python и JavaScript. Если агент гоняет сотни задач в сутки, сокращение медианного расхода до 6991 токенов и 608 секунд на кейс против 17646 и 1542 меняет и стоимость, и время ожидания результата. Более стабильный формат diff (100% против 98,1%) добавляет практической ценности: меньше ручных правок после прогона.
Для C++ логика другая: сначала прогон на своих задачах. Язык даёт самую большую экономию токенов, но именно на нём сосредоточены потери в парном сравнении, поэтому без проверки на собственном наборе кейсов переход рискован.
Если пайплайн критичен к восстановлению после ошибок, например агент работает автономно и ошибку первого шага уже некому исправить, базовая Qwen3.8-Flash-Next с её 84% восстановления остаётся разумным выбором. Разница в качестве между моделями в тесте не подтверждена как значимая, так что решение стоит принимать по скорости, расходу токенов и поведению на вашем стеке, а не по итоговому проценту прохождения.