ThinkingCap-Qwen3.8-27B и Swift-Qwen3.8-27B сокращают медианное число completion-токенов в Aider eval suite почти на 5 тысяч относительно оригинальной Qwen3.8-27B: 7436 и 7301 против 12547. Заявленное в карточках моделей сокращение reasoning-токенов примерно на 40% подтверждается почти буквально.
Качество при этом не просело. ThinkingCap и стоковая Qwen3.8-27B выдали одинаковые first-try pass (27.1%) и retry pass (77.6%). Swift отстал по retry pass (75.7%), зато обошёл обе модели по решениям с первой попытки (30.8%). ThinkingCap оказался единственным, кто дошёл до 100.0% корректных diff-форматов против 99.1% у базы и 98.1% у Swift.
Все три модели прогоняли в llama.cpp 0.5.0 при квантовании Q8_0, по два прогона на каждую. Различия по языкам программирования оказались заметнее, чем разница в общих метриках, и именно они чаще всего определяют выбор.
Что такое ThinkingCap и Swift и зачем их дообучали
Qwen3.8-27B в задачах на код известна привычкой уходить в длинные цепочки рассуждений. На сложной задаче модель может потратить тысячи токенов на промежуточные шаги до того, как выдаст первую строку патча. Это замедляет работу, увеличивает расход токенов и делает поведение модели менее предсказуемым.
ThinkingCap-Qwen3.8-27B и Swift-Qwen3.8-27B - дообученные версии той же базы. Обе решают одну задачу: сократить избыточные reasoning-циклы, не потеряв в качестве решений.
Почему Qwen3.8-27B страдает от лишних reasoning-циклов
Reasoning-модели тратят токены на промежуточные шаги: разбор условия, план, проверку гипотез, переформулировку. Часть этих шагов полезна, часть повторяет уже пройденное. У Qwen3.8-27B вторая категория разрослась настолько, что стала узнаваемой характеристикой: в разборе прямо говорят о «чрезмерных циклах рассуждений, которыми славится 3.8-27B» (результаты прогонов).
На практике это видно по времени ответа. Базовая модель тратит 1481 секунду на кейс и 19.3K токенов на одно решение. Дообученные версии укладываются в 750-777 секунд и 12.1-12.8K токенов. Разница примерно двукратная, и она накапливается на любом длинном пайплайне.
Чем ThinkingCap отличается от Swift по заявлению разработчиков
Формулировки в карточках моделей практически совпадают: сокращение reasoning-токенов примерно на 40% при минимальной деградации производительности. ThinkingCap связывают с лабораторией BottlecapAI. Конкретные методы дообучения в разборе не раскрыты, поэтому сравнивать подходы по описаниям нельзя: заявления почти идентичны, а разница проявляется только в тестах.
Механика сокращения у обеих моделей работает неравномерно. На одних языках и типах задач выигрывает ThinkingCap, на других Swift. Как Swift добивается экономии токенов и что это даёт на практике, разобрано в материале о файнтюне Swift-Qwen3.8-27B.
Как тестировали: методология Aider eval suite
Aider eval suite - стандартный набор задач, где модель редактирует реальные файлы репозитория и отдаёт результат в виде патча. Он считает first-try pass (задача решена с первой попытки), retry pass (решена за несколько попыток), well-formed diff (патч синтаксически корректен), а также completion-токены, секунды на кейс и токены на одно решение.
Условия прогонов: квантование Q8_0, llama.cpp 0.5.0, по два прогона на модель. Автор разбора оценивает погрешность в ±2-3%. Это существенная оговорка: ThinkingCap и Swift по retry pass различаются на 2%, и такой разрыв не выходит за пределы шума. Совпадение ThinkingCap и базовой модели до десятых по обеим pass-метрикам автор тоже называет случайностью, а не следствием одинаковой механики.
Ограничения стоит держать в голове. Выборка небольшая, всё сводится к одному рантайму и одному квантованию. Разбивка по языкам опирается на подмножества задач внутри Aider, и переносить её на другие наборы или рабочие нагрузки без проверки не стоит. Разбор основан на стороннем исследовании, а не на независимой проверке на другой инфраструктуре.
Тот же принцип, не доверять одной метрике, разобран в материале о том, как честно сравнивать локальные модели и почему пиковые tok/s не заменяют p50 и p95.
Сокращение reasoning-токенов: подтверждаются ли заявленные 40%
По медианному числу completion-токенов обе дообученные модели ушли далеко вперёд. Разница между 12547 у оригинала и 7436 у ThinkingCap - почти 5 тысяч токенов, то есть сокращение около 40%. Это почти точно совпадает с тем, что заявлено в карточках моделей (источник метрик).
| Модель | Медианные completion-токены | Секунд на кейс | Токенов на решение |
|---|---|---|---|
| Qwen3.8-27B | 12547 | 1481 | 19.3K |
| ThinkingCap-Qwen3.8-27B | 7436 | 777 | 12.8K |
| Swift-Qwen3.8-27B | 7301 | 750 | 12.1K |
Медианные и средние токены: почему разница важна
Медианы у ThinkingCap и Swift почти совпадают: 7436 и 7301. По средним ThinkingCap использует на 8.5% больше, и причина в более длинном хвосте распределения: находятся задачи, где модель всё ещё уходит в долгие рассуждения. Медиана описывает типичный кейс, среднее чувствительно к редким дорогим выбросам. Если вы планируете бюджет токенов на сотни задач, смотреть стоит на оба показателя.
Поведение на неудачных кейсах: где модели тратят больше всего
Обе дообученные модели тратят больше токенов на кейсах, которые не решили, чем на решённых. У ThinkingCap медиана неудачи 9.4k против 6.8k на успехе. У Swift контраст резче: 13.2k против 5.9k.
Практический смысл простой. В среднем Swift даёт более ровное сокращение, но когда задача уже не поддаётся, он сжигает токены активнее. ThinkingCap реже уходит в дорогой штопор на провале, зато в среднем немного дороже на успешных задачах.
Качество кода: first-try pass, retry pass и well-formed diff
| Модель | First-try pass | Retry pass | Well-formed diff |
|---|---|---|---|
| Qwen3.8-27B | 27.1% | 77.6% | 99.1% |
| ThinkingCap-Qwen3.8-27B | 27.1% | 77.6% | 100.0% |
| Swift-Qwen3.8-27B | 30.8% | 75.7% | 98.1% |
ThinkingCap и стоковая модель совпали до десятых по обеим pass-метрикам. Swift идёт в пределах шума: минус 2% по retry pass и плюс 3.7 процентного пункта по first-try pass.
Для практики это означает, что переход с базы на ThinkingCap по общей точности ничего не меняет: вы покупаете экономию токенов и аккуратность diff. У Swift другая кривая поведения. Он чаще закрывает задачу с первой попытки, но хуже доводит её до конца при повторных.
Почему well-formed diff критичен для автоматизации
В инструментах вроде Aider модель не пишет готовый файл, а генерирует патч в формате diff, который затем применяется к коду. Если структура нарушена, патч либо не применится, либо ляжет криво, и разбираться с этим придётся вручную. На длинном пайплайне даже 1-2% сбоев формата превращаются в регулярные ручные правки.
Поэтому 100.0% у ThinkingCap против 99.1% у базы и 98.1% у Swift - не косметика. Для сценариев, где патчи применяются автоматически без просмотра, это разница между стабильным конвейером и периодическими сбоями на пустом месте.
Различия по языкам программирования: C++, JavaScript, Python
| Модель | C++ first-try / retry | JavaScript first-try / retry | Python first-try / retry |
|---|---|---|---|
| ThinkingCap-Qwen3.8-27B | 11.5% / 61.5% | 35.4% / 85.4% | 27.3% / 78.8% |
| Qwen3.8-27B | 7.7% / 69.2% | 27.1% / 81.2% | 42.4% / 78.8% |
| Swift-Qwen3.8-27B | 11.5% / 69.2% | 37.5% / 81.2% | 36.4% / 72.7% |
C++: почему Swift выигрывает
На C++ у ThinkingCap и Swift одинаковый first-try pass (11.5%), но по retry pass ThinkingCap отстаёт на 8%: 61.5% против 69.2%. Причины в разборе не объясняются, поэтому приписывать преимущество конкретной особенности обучения не стоит. Факт остаётся фактом: на C++ Swift решает больше задач при повторных попытках.
Отдельно стоит заметить, что базовая Qwen3.8-27B на C++ берёт 69.2% по retry pass, то есть ThinkingCap здесь оказался хуже оригинала. Экономия токенов на C++ обошлась в снижение качества.
JavaScript и Python: где ThinkingCap сильнее
JavaScript: ThinkingCap 35.4% first-try и 85.4% retry против 37.5% и 81.2% у Swift. По retry pass ThinkingCap выигрывает около 4%, хотя уступает по первой попытке. Python: 27.3% и 78.8% у ThinkingCap против 36.4% и 72.7% у Swift, разница по retry pass около 6%.
На Python заметен третий нюанс: базовая Qwen3.8-27B берёт с первой попытки 42.4%, заметно больше, чем обе дообученные версии. Сокращение рассуждений забирает у модели часть интуиции, которую она потом компенсирует повторами.
По остальным языкам Aider производительность моделей статистически схожа (p > 0.05), так что делить выбор имеет смысл именно по этим трём (полная разбивка).
Стабильность и предсказуемость: что выбрать для продакшена
Если узкое место - бюджет токенов, Swift ведёт себя ровнее. Медиана 7301, более короткий хвост, равномерное сокращение на разных типах задач. ThinkingCap в среднем на 8.5% дороже именно из-за длинного хвоста: отдельные задачи всё ещё уходят в длительные рассуждения.
По скорости различия минимальны: 750 секунд на кейс у Swift против 777 у ThinkingCap при 1481 у базовой модели. Обе дообученные версии примерно вдвое быстрее оригинала на тех же задачах, и ThinkingCap использует чуть больше токенов на решение, поэтому работает дольше Swift, но речь о нескольких процентах.
Схожая картина уже встречалась в агентных тестах: ThinkingCap экономил около 34% токенов, но показывал бимодальное поведение с редкими дорогими выбросами. Детали и транскрипты - в разборе ThinkingCap против Fable Fusion и стокового Qwen3.6-27B.
Итог: какую модель выбрать под вашу задачу
- C++ и проекты, где важнее добить задачу повторами: Swift-Qwen3.8-27B (69.2% retry pass против 61.5% у ThinkingCap).
- JavaScript и Python: ThinkingCap-Qwen3.8-27B (85.4% и 78.8% retry pass против 81.2% и 72.7% у Swift).
- Автоматические пайплайны с применением патчей без ревью: ThinkingCap, единственная модель с 100% well-formed diff.
- Предсказуемый расход токенов и меньше сюрпризов на провалах: Swift, средний расход ровнее и хвост короче.
- Максимум решений с первой попытки: Swift (30.8% против 27.1%).
Переход с оригинальной Qwen3.8-27B на любую из дообученных версий оправдан, если вы платите за токены или ждёте ответа: экономия около 40% по медиане, время на кейс сокращается почти вдвое, качество по общим метрикам не падает. Выбор между ThinkingCap и Swift определяется языком и тем, насколько критичен формат патча. Чек-лист по подбору модели под agentic coding есть в разборе 35B-моделей для кодинга.
И держите в уме погрешность: два прогона на модель дают ±2-3%, различия в этих пределах (например, 2% по retry pass между ThinkingCap и Swift) считать преимуществом нельзя. Разницу в 6-8% по отдельным языкам уже можно, но её стоит перепроверить на своих задачах до того, как менять модель в рабочем процессе.