$ grep -r Tag: «qwen»

Проводил сегодня интересный эксперимент. Всё то же техническое задание в файле, на создание markdown-редактора на Rust и GTK. Два разных подхода.

1. Задание целиком выполняется с помощью Claude Code моделью Opus 5. Для этого Claude Code запустил отдельного субагента с новым контекстом для чистоты эксперимента.
2. Задание выполняется связкой Opus 5 и локально запущенной модели Qwen3.6-35B-A3B. Здесь Opus 5 выступает как оркестратор и мозги, а всё написание кода делегируется модели Qwen. Оркестратор — тоже отдельный субагент с чистым контекстом, чтобы условия у обоих подходов были одинаковые.

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

Во-первых, было интересно, справится ли связка двух моделей с заданием. Во-вторых, хотелось выяснить, будет ли разница в расходе токенов. Результаты довольно интересные.

Результаты

Справились оба.

По формальному критерию — ничья. По токенам связка дешевле в 1,77 раза по выводу и в 2,08 раза по чтению кеша, и это реальная экономия: локальная модель своих лимитов не тратит.

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

Экономия при этом в лимитах, а не в скорости: по времени связка вдвое медленнее.

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

Выводы

Делегировать локальной модели стоит, если нужен ровно оговорённый результат и ты готов сам нарезать задачу на этапы и проверять каждый. Лимиты это экономит почти вдвое.

Оркестратор при этом обязан работать из свежего контекста. У меня был и третий прогон, где я управлял Qwen прямо из длинной рабочей сессии, — он съел втрое больше только на том, что каждый ход перечитывал накопленную историю. Всю выгоду это сожрало.

Но платишь за экономию инициативой. Связка закрывает список требований, а не делает продукт. Если нужно второе — дешевле не делегировать.

Удивительный прогресс всего за несколько месяцев в развитии моделей и llama.cpp. До этого я тестировал модель Qwen3.6-27B, она не влезала в мои 16 гигабайт видеопамяти, работала довольно медленно, генерация была 12-18 токенов в секунду.

С моим тестовым заданием (маркдаун редактор на Rust и GTK под Linux) она справилась за примерно 20 часов.

Как эксперимент было интересно, но с практической точки зрения бесполезно. Слишком долго.

И вот за это время и вышла модель Qwen3.6-35B-A3B на архитектуре MoE - 35B параметров всего, но на каждый токен активируется только ~3B (8 routed-экспертов + 1 shared из 256). За счёт этого модель работает как значительно более лёгкая по вычислениям, сохраняя при этом качество, близкое к куда более крупным моделям того же класса. В llama.cpp появилась и поддержка этой архитектуры, и куча улучшений производительности, и MTP (Multi-Token Prediction) — дополнительная "голова" предсказания нескольких токенов вперёд, обученная вместе с моделью. MTP даёт ~1.4-2.2x ускорение генерации без потери точности, хотя для MoE-моделей прирост обычно скромнее (~1.15-1.25x).

Так вот, сегодня я решил этой модели скормить своё тестовое задание. Предварительно Claude Code погонял разные тесты и нашёл оптимальные настройки для этой модели.

Сказать, что я удивлён, ничего не сказать. Во-первых, модель целиком влезает в видеопамять. Во-вторых, я получил размер контекста 256k, чего ранее с другими моделями не бывало (даже с небольшими моделями были проблемы).

Скорость обработки промпта примерно 260-400 токенов в секунду. Скорость генерации на пустом контексте была под 100 токенов в секунду, по мере заполнения контекста скорость снизилась до 62-65 токенов в секунду. Но это всё равно чертовски быстро.

От первого промпта до запуска приложения, в котором был кривой и неработающий UI, модель 27B у меня добралась часов за 10. Модель 35B сегодня добралась за 50 минут!

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

Интересно будет теперь погонять эту модель на своих реальных проектах. Кто знает, может мечта о годной локальной модели для кода не так уж и далека от осуществления.

Перепробовал за последние месяцы много разных локальных моделей. У меня есть свой тест для них — файл с подробным заданием для редактора заметок под Linux на Rust. Подсветка синтаксиса (несложно, есть из коробки в системном компоненте) и панель предварительного просмотра, которая должна показывать отформатированный текст. В целом, довольно похоже на моё приложение Swifty Notes, но на Rust.

Так вот, Qwen3.6-27B пока что единственная модель, которая добралась до финиша. Работала она в течение 3 дней (не круглосуточно, а только когда я был у компа и мог её направить). Редко, но всё-таки модель испытывала проблемы с вызовом инструментов. Иногда не могла отредактировать файл и останавливалась — приходилось просить её попробовать ещё раз. В целом эту часть я бы оценил на 4 из 5.

Самое главное — модель не ходила кругами. Rust здесь очень удачный выбор: если есть ошибка, то проект просто не компилируется. А в сочетании с тем, что техническое задание требует сначала писать тесты, а потом код (Test Driven Development), очень много проблем находится и исправляется на самых ранних стадиях. И тут модель себя показала неплохо. Достаточно быстро исправляла ошибки, следовала инструкциям из ТЗ и изучала документацию, если вдруг использовала несуществующий API или просто нужно было проверить, что доступно. Тут твёрдая 4 из 5.

Размер модели — 17.5 гигабайт. Я скачал её через LM Studio, но запускал через llama.cpp — на удивление, скорость работы моделей там гораздо выше, хотя вроде бы LM Studio её же и использует. Возможно, более свежие версии llama.cpp просто уже более оптимизированы.

В видеопамять модель не влезает целиком (у меня 16 ГБ), поэтому частично работала на CPU, что очень сказалось на скорости. 15.94 ГБ видеопамяти и ещё около 12 ГБ оперативной памяти занимало всё это чудо в пике (когда контекст уже был близок к заполнению). Размер контекста я выставил 64k — поначалу хватало неплохо, но ближе к концу, когда объём кода вырос, модель довольно часто делала сжатие контекста. Хотя в целом с задачей такого размера модель справилась.

Скорость работы я бы оценил на 2 из 5.

Когда модель отрапортовала, что всё готово, я запустил приложение и увидел, что в панели просмотра у меня просто текстом HTML вместо рендера. Пришлось попросить модель это исправить, и спустя ещё часа полтора-два я получил приемлемый результат. Но стоит упомянуть, что с флагманскими моделями тоже такое сплошь и рядом — с первого раза большие задачи, как правило, не получаются, требуются правки и уточнения.

Итого: Claude Code сделал бы это задание минут за 20–30, и, скорее всего, ещё минут 20–30 я бы потратил на доделывание. Округлим до 1 часа. С Qwen3.6-27B на это понадобилось в сумме около 20 часов работы без остановки, то есть примерно 3 полноценных рабочих дня. Конечно, большую часть времени ты просто сидишь и смотришь, как модель работает. Скорость генерации на предварительных тестах, которые мне помог провести Claude, на моём железе была 12–18 токенов в секунду.

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

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