Swift-Qwen3.8-27B сокращает объём «размышлений» базовой Qwen3.8-27B на 30-50% при сопоставимом качестве ответов. Это сторонний файнтюн от UkisAI: архитектура та же, меняется поведение модели во время внутренних цепочек рассуждений. Автор доработки выявил reasoning-marker токены, которые подталкивают модель к избыточному «обдумыванию», и штрафовал их через обучение с подкреплением. Дополнительно в модель перенесли компонент из ThinkingCap-Qwen3.6-27B, которую сделала команда BottleCap AI.
Практический смысл простой. Reasoning-модели тратят основное время не на сам ответ, а на внутренние рассуждения, и у Qwen3.8-27B эта привычка выражена особенно заметно. Меньше reasoning-токенов означает меньше времени до ответа, меньшую нагрузку на GPU и ниже счёт у тех, кто платит за токены. Если коротко: тот же результат, но дешевле и быстрее.
Дальше разберём, за счёт чего достигается экономия, что показал независимый прогон через Aider и почему цифры 30-50% пока стоит считать заявкой разработчика, а не измеренным стандартом.
Что такое Swift-Qwen3.8-27B и зачем понадобился файнтюн
Базой послужила Qwen3.8-27B, модель на 27 млрд параметров с режимами рассуждений. Swift-Qwen3.8-27B это не официальный релиз Qwen, а доработка сторонней команды UkisAI, выложенная отдельно от апстрима. Файнтюн не переписывает веса с нуля: он корректирует то, как модель распределяет бюджет токенов между «мыслями» и финальным ответом.
Проблема, которую он решает, хорошо знакома всем, кто гонял Qwen 3.8 локально. Модель может выдать 15-20 тысяч токенов рассуждений на задачу, где хватило бы двух тысяч, а иногда и вовсе не доходит до ответа, упираясь в лимит контекста. Мы разбирали это поведение отдельно в материале про разницу между режимами xhigh и medium: разрыв по объёму генерации там измеряется в разы.
UkisAI пошла не по пути обрезки рассуждений «в лоб». Заявленная цель звучит как сохранение качества при меньшем числе reasoning-токенов: 30-50% экономии, а не отключение режима мышления целиком. Это принципиально разные вещи. Отключить thinking можно и штатными средствами, о чём есть отдельный разбор отключения reasoning на MacBook Pro с M5 Max, но тогда модель теряет глубину там, где она нужна.
Как устроен файнтюн: reasoning-marker токены и RL
Механика держится на двух компонентах: обучении с подкреплением против конкретных токенов-триггеров и переносе готового решения из родственной модели.
Что такое reasoning-marker токены
Reasoning-marker токены это токены, которые регулярно появляются в начале или в ходе длинной цепочки рассуждений и статистически связаны с переходом к избыточному «обдумыванию». Они не несут новой информации о задаче, но запускают очередной виток размышлений: модель как будто проговаривает вслух «а теперь проверю ещё раз» и уходит на новый круг.
Важный нюанс: сами по себе такие токены полезны. Это механизм самопроверки, который помогает на сложных задачах. Вред начинается, когда их доля в генерации растёт и цепочка превращается в цикл. Именно эту границу и пытались сместить: не убрать самопроверку, а сократить её частоту там, где она уже не даёт прироста к ответу.
Роль RL в сокращении overthinking
Через обучение с подкреплением автор штрафовал генерацию reasoning-marker токенов. Модель получала сигнал: длинная цепочка без улучшения результата поощрения не приносит. Награда привязывалась к качеству итогового ответа, а не к количеству «размышлений», поэтому экономия не превращалась в деградацию.
Гарантий пропорционального сокращения это не даёт. RL смещает вероятности, а не отключает механизм жёстко: на действительно сложной задаче модель по-прежнему может уйти в длинное рассуждение, и это нормальное поведение, а не баг файнтюна.
Перенос компонента из ThinkingCap-Qwen3.6-27B
Вторая часть работы это перенос компонента из ThinkingCap-Qwen3.6-27B от BottleCap AI. ThinkingCap строилась на предыдущем поколении 27B и уже решала задачу упорядочивания рассуждений. Готовый компонент перенесли в новую базу, чтобы не изобретать то же самое заново.
Такой гибрид объясняет, почему результат получился относительно быстрым: часть улучшений взята из проверенной модели, а не выведена с нуля. При этом перенос компонента не единственный источник улучшений, и приписывать весь выигрыш только ему некорректно.
Тест через Aider: насколько меньше токенов и времени
Пользователь, опубликовавший пост о модели, прогнал её через Aider, инструмент для работы LLM с кодовой базой, и сравнил с базовой Qwen3.8-27B. Результат по расходу токенов заметный.
| Показатель | Базовая Qwen3.8-27B | Swift-Qwen3.8-27B |
|---|---|---|
| Completion-токены на задачу | около 12 500 | около 7 300 |
| Время на задачу | базовый уровень | примерно вдвое меньше |
| Pass1 / Pass2 | близкие значения | близкие значения |
| Well-formed diff | близкие значения | близкие значения |
Что измеряли: completion-токены, Pass1/Pass2, well-formed diff
Completion-токены это всё, что модель сгенерировала в ответе, включая рассуждения и сам патч. Pass1 и Pass2 показывают, проходит ли решение тесты с первой или второй попытки. Well-formed diff отражает, насколько корректно оформлен патч: применяется ли он к файлам без ручной правки.
Ключевое здесь то, что метрики качества остались на прежнем уровне. Файнтюн не выиграл за счёт того, что стал хуже: при близких Pass1, Pass2 и well-formed diff он потратил примерно на 5,2 тыс. токенов меньше, то есть около 40% экономии. Это попадает в заявленный диапазон 30-50%.
Ограничения теста: один пользователь, нет деталей
Тест провёл один человек и выложил результат публично. Не раскрыто, на каких именно задачах, с какими настройками sampling, на каком железе и в каком квантовании всё считалось. Это единичный случай, а не аудит, поэтому цифры 7,3 тыс. и 12,5 тыс. стоит воспринимать как ориентир, а не как воспроизводимый бенчмарк.
Более того, нет данных о других независимых прогонах. Пока это единственная публичная проверка, на которую можно опереться, и делать на её основе выводы «модель всегда экономит 40%» нельзя.
Что это даёт на практике: скорость, стоимость, сценарии
Основной эффект от сокращения reasoning-токенов это время до ответа и стоимость инференса. Логика линейная: меньше токенов на выходе значит меньше шагов декодирования и меньше счёта при оплате по токенам. На слабом железе эффект заметнее, потому что скорость генерации там ограничена.
Для локального запуска: требования к VRAM и скорость
Файнтюн не меняет архитектуру, поэтому требования к железу те же, что и у базовой Qwen3.8-27B: 27 млрд параметров, что при 4-битном квантовании укладывается примерно в 16-18 ГБ VRAM, а при более высоких точностях и длинном контексте аппетит растёт до 24 ГБ и выше. Квантование и параметры контекста влияют на память сильнее, чем сам файнтюн.
Сокращение цепочек рассуждений ускоряет работу в первую очередь на машинах, где каждый сгенерированный токен стоит секунд. Если вы запускаете модели через llama.cpp, параметры мышления и их влияние на скорость разобраны в материале про управление режимами мышления Qwen 3 в llama.cpp.
Для агентов и кодогенерации: экономия токенов и времени
Агентные сценарии чувствуют такую экономию сильнее всего. Одна задача может включать десятки шагов, и на каждом модель рассуждает заново. Если шаг становится короче на 30-50%, на длинной цепочке это накапливается: суммарный расход падает, а время выполнения задачи сокращается.
Пример из Aider это ровно такая ситуация: около 7,3 тыс. completion-токенов против 12,5 тыс. у базовой модели и примерно вдвое меньше времени на задачу при близком качестве патча. Для точечной правки одного файла разница незаметна, для прогонов на сотнях задач она складывается в часы.
Стоит помнить, что экономия токенов не всегда конвертируется в пропорциональное снижение затрат. Итоговая стоимость зависит от тарифов, от соотношения входных и выходных токенов и от того, кто платит за простой GPU. Точные цифры для своего стека можно получить только на своих задачах.
Кому стоит попробовать Swift-Qwen3.8-27B
Файнтюн имеет смысл в первую очередь тем, кто использует Qwen3.8-27B как рабочую лошадку, а не как демонстрацию возможностей.
- Разработчики, которые держат локальную модель для кодогенерации и патчей через Aider или аналогичные инструменты. Экономия токенов и времени тут ощущается напрямую.
- Владельцы домашних GPU-серверов, где inference упирается в скорость генерации, а не в качество картинки. Более короткие цепочки рассуждений означают меньше занятого времени на GPU.
- Команды, внедряющие AI-агентов с многошаговыми задачами. Каждый сэкономленный reasoning-токен умножается на число шагов.
- Энтузиасты, которые ведут сравнения моделей и хотят посмотреть на альтернативу базовому поведению Qwen 3.8. Подход к честным замерам и метрикам вроде p50 и p95 разобран в материале про тесты нескольких моделей на DGX Spark.
Есть категория задач, где экономия может навредить. Сложная математика, многошаговые доказательства, тонкий рефакторинг, где ошибку дешевле поймать на этапе рассуждений, чем на этапе тестов. Там длинные цепочки себя оправдывают, и укорачивать их файнтюном рискованно.
Ограничения и риски: что важно знать перед использованием
Главное ограничение лежит на поверхности: 30-50% это заявление создателей модели. Масштабного независимого бенчмарка, который бы это подтвердил, нет. Единственная публичная проверка это прогон одного пользователя через Aider без раскрытия условий.
Дальше по списку:
- Неизвестно, на каких задачах и датасетах считалась экономия. На другом профиле задач цифры могут оказаться скромнее.
- Сравнений с другими моделями класса 27B и с альтернативными файнтюнами в открытых данных нет.
- Экономия токенов не равна пропорциональной экономии денег: всё зависит от инфраструктуры и тарифов.
- Теоретически возможна потеря качества на части задач, где рассуждения критичны. Близкие Pass1/Pass2 в одном тесте этого не исключают, они лишь показывают, что на конкретных задачах деградации не было.
- Файнтюн сторонний. Совместимость с конкретной версией llama.cpp, vLLM или другого рантайма придётся проверять самому.
Итог: стоит ли переходить на Swift-Qwen3.8-27B
Файнтюн выглядит разумным выбором для агентных и кодовых сценариев, где важнее пропускная способность, чем максимальная глубина рассуждений. Механика понятная и не выглядит маркетингом: найдены конкретные токены-триггеры, применён RL, перенесён компонент из ThinkingCap-Qwen3.6-27B. Единственный публичный тест через Aider дал сокращение с 12,5 тыс. до 7,3 тыс. completion-токенов и примерно вдвое меньше времени при близком качестве патча.
Заменять базовую модель вслепую не стоит. Правильный шаг это прогнать обе версии на своих задачах: взять десяток типичных запросов, замерить completion-токены, время до ответа и качество результата, а не полагаться на чужие 30-50%. Если ваши задачи проходят без потери качества, экономия реальная и касается вашего счёта. Если нет, базовая Qwen3.8-27B остаётся рабочей опцией, а режимы мышления у неё управляются штатными средствами.