Текст носит юмористический характер и написан для @mahmud90 и @MountainGoat
Китайские модели стоят в разы дешевле западных — и каждый месяц кто-нибудь спрашивает: а можно ли просто пересесть на Qwen и не платить за Claude с GPT? Я взял одну реальную задачу и прогнал её через три модели сразу, а потом свёл качество с ценой. Ниже — что получилось и кому Qwen реально подойдёт.
Задача одна на всех: разобрать топ-10 heap alloc_objects выкосонагруженного Go-сервиса по pprof-профилю и выдать фиксы по файлам. Профиль один, требования одни, доступ к репозиторию у всех троих. Go приложение обслуживает миллионы реквестов в минуту, кодовая база по размеру средняя.
Короткий итог
Модель |
Оценка (0–50) |
Если коротко |
|---|---|---|
Codex (GPT-5.5) |
46 |
|
Claude Opus 4.8 |
46 |
|
Qwen 3.7 Max |
43 |
Прогнал |
Что нашли все трое
Главную причину выявили все: функция матчинга источников трафика на каждый запрос заново парсила URL-ы из статической конфигурации (та меняется раз в сутки). Кумулятивно — около 45% всех аллокаций объектов. Фикс у всех одинаковый: парсить конфиг один раз при загрузке, а не в обработке запроса.
То есть как «находилка узких мест» работают все три. Если задача — «покажи, где течёт», Qwen справится не хуже.
Где разница
Профилирование тут не бинарное «запускал / не запускал», а вопрос глубины:
Codex —
-peek(разбивка по вызывающим) +-list. Нашёл то, что видно только на этом уровне: на каждый внешний запрос создаётся новый объект-логгер, код тянет весь хеш из хранилища ради трёх полей, а в проекте уже есть LRU-кэш под соседнюю задачу — можно переиспользовать. Прочитал исходники библиотек, указал версии и строки.Claude —
-peek-разбор, независимо вышел на те же причины. Вровень с Codex по находкам, чуть лучше по готовности к внедрению, но где Codex сам гонял профайлер, Claude иногда советовал «запустите команду сами».Qwen —
-top -cum. Через кумулятив честно нашёл главный корень (45%, статические правила), привёл верный API и структуры, ничего не выдумал. Но-peekне использовал ни разу → пропустил per-request логгер, bid-узел и разбивку по вызывающим.
Единственная серьёзная заноза Qwen
Он предложил переиспользовать один объект в цикле и отдавать указатель в функцию сохранения, вынес это в Quick Win. Сам приписал оговорку «работает, только если сохранение синхронное, иначе Clone()» — но не проверил, что путь асинхронный. А он асинхронный: указатель уходит в канал и сериализуется позже в другой горутине. Такой приём для async прямо небезопасен — порча данных. Codex и Claude этот вариант пометили как недопустимый и дали безопасную альтернативу (копии по значению).
То есть Qwen знает про риск, но не доводит проверку до конца. Это ровно то место, где перед мержем нужен человек или второе мнение.
Рубрика по баллам (0–5)
Критерий |
Codex |
Claude |
Qwen 3.7 |
|---|---|---|---|
Нашёл главную причину |
5 |
5 |
5 |
Глубина профилирования |
5 |
5 |
4 |
Новые находки |
5 |
4 |
4 |
Корректность API/кода |
5 |
5 |
5 |
Безопасность рекомендаций |
5 |
5 |
3 |
Верификация по исходникам |
5 |
5 |
4 |
Готовность к внедрению |
4 |
5 |
4 |
Широта альтернатив |
4 |
3 |
5 |
Лёгкость первого шага |
3 |
5 |
5 |
Плотность/ясность |
5 |
4 |
4 |
Сумма |
46 |
46 |
43 |
Числа субъективны, это не бенчмарк. Но направление держится: разница — в глубине работы профайлером (-peek против -top -cum), а не в «IQ модели». И отдельная заноза Qwen — небезопасный фикс в «быстрых победах» — от профилирования не зависит.
Так нужно ли использовать Qwen?
Да если нет в доступе топовых альтернатив, иначе вы просто теряете свое личное время, чтобы контролить и подчищать за ним.
Что с ценой ?
Подписка на квен стоит 50 долларов у алибабы , купить ее не возможно, каждый день висит оутофсток и будет в наличии в полночь, вторую неделю захожу в полночь никогда не появляются новые подписки. Пришлось купить план за кредиты на $30, то есть оплату за токены + акция на квен макс -50% . На задачу потратил квен минут 10 и 5% токенов. Пакета токенов за 200 долларов мне хватит примерно на 33 часа работы в один поток. Если посмотреть как я работаю в клоде и гпт в 5+ потоков то вообще за день два могу сьесть пакет токенов квена за 200 долларов. Итого в 15-30 раз дороже клода и чатгпт по подписке. Еще раз отмечу что подписку за 50 долларов у квена купить не получилось.
Качество qwen3.7-max?
В целом не плохое, отстает на 2-4 поколения от топовых чатгпт и клода, что вполне достойно, с учетом того что новые поколения выходят чуть реже чем раз в месяц.
А стоит ли включить в пул агентов для работы в связике?
Я не могу сказать что я особо сильно погонял его в большом пуле задач, но в небольшом я не смог получить какой то выигрыш от работы квена в пуле агентов. Так что если есть альтернативы заюзать в связке кодекс, клод или гемени, выберите их.
Комментарии (35)
SergP98
13.06.2026 14:45Хм
Qwen/Qwen3.6-35B квантизованную можно запустить офлайн на рабочей станции с 5090 rtx скажем, без всяких лимитов и со скоростью под сотню токенов в секунду. Оно так окупится быстро
mgis
13.06.2026 14:45А причем тут это если речь об qwen3.7-max, это же разные "весовые категории"?
Qwen3.6-35B для серьезных задач даже близко воспринимать не стоит.
Krypt
13.06.2026 14:45Я экспериментировал с Qwen3.6 27B (имхо, не moe, модели лучше при том же количестве параметров, хотя при этом медленнее)
Результат: https://krypt-lx.github.io/se-steam-battery-calc.htm
Здесь практически всё, кроме конечной математики написано ИИ.
Интересно то, при работе с Qwen3.6 присутствует довольно осязаемый порог сложности задачи, после которого резко падает качество ответа, причём "сложность" не зависит от размера занятого контекста и релевантности к задаче: То есть, пока в коде была только половина вычислений - правки разметки проходили с первого раза и без всяких проблем, но как только в js была добавлена вся математика - появились баги при редактировании gui кода.
При этом в отдельном чате модель смогла решить математический компонент задачи по его текстовому описанию, и результат совпал с тем, который я рассчитал сам.
slabnoff
13.06.2026 14:45Как не странно, но moe вариант в некоторых случаях может оказаться лучше плотного варианта. Как раз в некоторых приложениях кодинга. Все-таки суммарно параметров почти на треть больше и есть мнение (не в одном месте встречал, но официальных подтверждений пока не нашел), что moe вариант дополнительно обучали относительно плотного. Официально, с цифрами, есть тесты, где заметное преимущество у 35b.
fshp
13.06.2026 14:45Гонял локально 27B и 35B. Не знаю что там по тестам, но на практике лично для меня 27B выдает более качественные ответы. 35B иногда ломается и даже тулы перестает запускать, вместо этого в чат выкидывает xml теги тулов.
Важное уточнение: обе модели каантизованы в q4. Но без этого даже 32 гигов в 5090 будет мало.
guryanov
13.06.2026 14:45Та же история, появилась возможность поехать карту h200, долго мучал вопросами, что же на ней можно запустить с контекстом 256к, оказалось что не так много интересного и по качеству работы больше всего qwen3.6-27b понравился
slabnoff
13.06.2026 14:45Чисто личный опыт. 35b слаб на комплексных задачах. Например что-то типа 'нарисуй мне хомяка бегающего по клетке' - приходится 35b пару итераций давать исправляя недоработки, а 27b чаще сделает с первого раза. На чистых кодовых задачах вполне сопоставимо.
Но есть ещё интересный момент. Пока говорить могу чисто субъективно, метрик у меня нет, но думаю как фактически оценить. Очень похоже, что 35b крайне чувствительна к качеству квантования. Видимо очень быстро накапливаются ошибки из-за особенностей архитектуры. Перебирал разные варианты, некоторые натурально ломаются на большом контексте. Но в итоге нашел два отличных квантования от DuoNeural и fraQtl (от них есть и другие модели). Они очень стабильно себя ведут даже в квантовании iq4_xs
MountainGoat
13.06.2026 14:45"сложность" не зависит от размера занятого контекста
Вы помните про половину идиота? После заполнения половины контекста, модель резко тупеет.
Krypt
13.06.2026 14:45Максимальный размер контекста Qwen 3.6 27b - 262144, но на моей машине в память столько просто не помещается, максимальное количество что я использовал было 60k.
На этом масштабе, проблема похоже не зависит от размера контекста: в чате с 7 ранними версиями файла, 60к токенов ответы были более качественными, чем в новом чате с удалёнными копиями (~10k), при том что все требования в чате присутствовали в полной мере.
Qwen в определённый момент начал делать совершенно глупые ошибки, вроде проверки типа получаемого события за пределами обработчика событий ("для оптимизации, чтобы не подписываться на лишние события", как он обосновал в процессе мышления).fshp
13.06.2026 14:45А температуру и другие настройки крутили?
Krypt
13.06.2026 14:45Нет, я был больше заинтересован в решении задачи, чем как именно она решена. (С тем только уточнением, что я программист, но не web-, потому и ИИ) Стояли рекомендованные для "Thinking mode for general tasks" со страницы модели. Хотя нам есть "Thinking mode for precise coding tasks", но стояли не они. Честно говоря просто забыл про них.
slabnoff
13.06.2026 14:45Личный опыт показал, что часто стоит придавить thinking и таки прикрутить температуру. Ну натурально бредить иначе начинает в рассуждениях. Я в итоге обернул llama/ik_llama скриптом для управления моделями и там 4 предустановки и одна кастомная как раз на варианты этих настроек.
Если интересно, могу посмотреть и написать оптимальный вариант для большинства кодинговых задач.
fshp
13.06.2026 14:45Температуру и top_* настройки можно передавать прям в запросе. Например вы можете использовать один и тот же инстанс модели с высокой температурой для оркестрации и с низкой для сабагентов. Самое худшее что в этом случае может случиться - не попадете в кэш и llama начнет весь контекст заново парсить.
slabnoff
13.06.2026 14:45Спасибо. Ведь знаю о такой возможности, а как-то применить даже не пробовал. Иногда может быть очень полезным
slabnoff
13.06.2026 14:45Попробуйте квантование kv кэша. Q8_0 вполне нормально получается. Если инференс на llama.cpp, то можно и турбокванты попробовать (у меня основной инференс на ik_llama, он пока не умеет в турбоквант, но на классической llama.cpp получилось ну очень неплохо).
fshp
13.06.2026 14:45На 5090 влезет квантизованная 27B с 256к контекстом. Если kv кэш опустить до q4, то и на 4090 влезает. 27B это плотная модель, она умнее 35B.
slabnoff
13.06.2026 14:45Q4 квантование kv кэша по опыту сводит с ума 35b/27b qwen3.6 модель с ума при заполнении кэша уже к 100000. Чудесить начинает, особенно если thinking включен - может вообще зациклиться. Q8 или турбокванты - все отлично.
CzarOfScripts
13.06.2026 14:45Она и на 4080 вполне поднимается, правда около 40-48т/с и около 1800т/с на чтение
opium Автор
13.06.2026 14:45Вообще не окупится, тупо считаю карточку без компа в магазине она сейчас стоит 400к рублей примерно, это 5500 долларов, это подписка на 2+ года топовой ллмки кодекса или клода.
Про скорость я вообще молчу на одной видюхе она просто мизерная, а еще у тебя квен этот не влезет в 32 гб видюхи одной , и 100 токенов + в секуду у тебя может быть с контекстом 100к , а я работаю всегда на 1кк-1М контекстом .
То есть тут сравнение телеги и ферари к сожалению.
В свое время я относительно долго был фаналом запускать все у себя , к сожалению этот путь в никуда, конгда полностью перешел на внешние апи все стало в десятки раз быстрее, стабильнее и качественее по каждому параметру. Да держал свои сервера с 4090 и да это было уныло.
arxont
13.06.2026 14:45Как человек немного интересующийся темой могу сказать всё от задач зависит. В некоторых окупается. Тот же RAG - если у тебя ОЧЕНЬ много документов которые сканы PDF и тебе нужно прогнать через хорошие OCR (а тут тоже нейронки рулят да). И токенизировать это всё и в вектор, а потом с этим работать. А если ещё и документы которые ты не хочешь выкладывать в публичный доступ (или нельзя). Ну и насчёт ценника - за 250к рублей можно купить китайского кадавра 4090 с 48 гигами врам, и уже гораздо всё веселее. Ну и для всяких экспериментов - когда не надо беспокоится о лимите, то можно гораздо активнее использовать LLM.
opium Автор
13.06.2026 14:45ну просто прогнать клодом или чатгпт не проще , за те же 200 баксов? чем платить сразу много и вперед ?
я просто видел много случаев где делали по разному, и в них всех железо ни разу не было лучше и дешевле.
то есть какие то случаи есть конечно но их единицы и вероятность что ты попал в них не велика.
Из забавного в итоге я тупо отказался от своего рага, так как гонять ллмку по апи вышло дешевле на голых текстовых знаниях, так как знания в целом одинаковые и запрашивают их часто за счет кеширования там 10х выигрыш в цене идет на апи. Что в свое время стало решающим фактором, цена апи просто на порядок дешевле своего решения.
arxont
13.06.2026 14:45Нет, не проще. Сильно дороже - если один-десять-сто документов то возможно. Плюс дальнейшее хранение и использование. Плюс чисто юридические проблемы если делаешь это не для себя (простейшее - оплата). Плюс возможность в любой момент словить блокировку. Я не спорю что для кодинга лучше, но не кодингом единым живы нейронки :)
avshkol
13.06.2026 14:45Здесь больше подошёл бы заголовок "Нужно ли использовать Qwen для анализа кода на Go? Качество и цена"
А ведь есть ещё масса других задач, где он хорошо справляется в бесплатной версии:
Перевод на русский, в т.ч. научных текстов (не нужно весь целиком, по одной главе)
Разъяснение сложных мест в научных текстах
Выборка и преобразование данных, причём весьма сложное
...
Reller
13.06.2026 14:45Полезное сравнение, спасибо. У нас на проде вывод такой же. Мы давно перестали искать одну лучшую модель и роутим по типу задачи. Найти узкое место это recall, тут Qwen и другие дешёвые отрабатывают нормально. Глубокий разбор с тонкой правкой это precision, там фронтир пока стабильнее.
Но главное вы поймали точно. Небезопасный фикс в быстрых победах. Дешёвая модель увереннее ошибается на краях, и применишь её совет вслепую, экономия на токенах вылезет багом в проде. Поэтому у нас всё, что пишет код, идёт через проверку. Компиляция, тесты, ревью. А дорогая модель или человек подключаются только к тому, что проверка завернула. Дёшево и не страшно.
Получается, роутить полезнее по цене ошибки, а не по абстрактному качеству. Триаж дешёвой, необратимое действие дорогой с проверкой. Вы цену ошибки в оценку закладывали, или считали чистое качество против цены прогона?
MountainGoat
Осторожно, поток нефильтрованного козла:
Жаль, я сам в Go по нулям и потому по примеру не прокомментирую. Равно как и про цену на Qwen. Если у китайцев вменяемо купить не получается, смотрите у NanoGPT. Как я уже писал, я беру DeepSeek по подписке и больше доллара в день ухлопать можно либо специально, либо когда я ему целую гору книг сгрузил для обработки - но тут моя вина, спокойно можно было завести локальную модель под это дело.
Как видите, модели попроще отлично справились бы с задачей, но не с первого раза. Поэтому чем больше у моделей возможности перепроверить себя, тем лучше она работает. Вы им MCP с API не давали? Как раз помогает от непоняток того, что в каком контексте можно использовать.
Есть ещё одна заковыка, я с ней понемножку экспериментирую. В современных типизированных языках людям дано право не писать типы явно там, где их легко вывести. Причём под "современным" языком подразумевается даже С++11 с его auto. Во всех этих случаях человек может навести мышкой, и IDE ему посчитает фактический тип и покажет в всплывашке. (Тумба-юмба с макросами оставим за кадром).
Но у LLM то нету мышки, чтобы наводить! Там, где человек видит
let black_cat: Cat = Cat::new( weight: u32 w, color: Color32 c)LLM читает толькоlet black_cat = Cat::new(w,c). А если ещё и объявление этой функции находится вне контекста, то мрак. В таких случаях LLM как настоящий джун полагается на логику: "ну до меня ж работало - значит правильно". И полностью путается, если до неё это всё работало через сумасшедшее приведение типов, типаColor32умеет самопревращаться изstr. Теперь LLM уверена, что второй аргумент у `Cat::new()` это str.Для решения проблемы в хорошие агентные обёртки добавлена поддержка LSP. Кто не знает: LSP это модули проверки синтаксиса языка через стандартный протокол. Сами они не ИИ, а просто навороченный парсер. У человека они позволяют иметь подсветку проблем в текстовом редакторе ещё до компиляции. А LLM они помогают понять, где она ошиблась с выводами о типе. Но к сожалению, LSP работает уже после написания кода. У меня такое бывает после внедрения LSP, или при работе с агентом прямо из IDE, где он видит ворнинги от IDE, что в общем то же самое. LLM пишет целую правку кода, потом без всяких компиляций останавливается, говорит "А не, не так" и пишет по другому. Это как раз LSP подсветило ошибку в типах.
Это лучше, чем написать 5 файлов и потом переделывать, но всё же не идеал.
Поэтому я сейчас думаю, что в эпоху LLM кода надо бы пересмотреть, что мы считаем хорошим кодом, а что- пахучим. Повторения для LLM не проблема. Сейчас в Rust считается, что писать типы там, где они не нужны - это моветон. Мешает дальнейшему рефакторингу. И это верно. Но если рефакторить тоже будет только LLM? Ей-то не влом в 200 местах одинаковую правку сделать. Что если в LLM коде отказаться от человеческой красоты кода и писать так, как удобно машине. Все типы - явно. Ещё и указание типа в имени объекта вернуть.
Есть и другие оптимизации, которые у нас живут уже в пальцах и делаются сами, но для LLM это просто лишняя нагрузка. Например, форматирование кода. Я его теперь делаю только один раз перед коммитом, хотя раньше оно у меня автоматически делалось при сохранении.
Так что я сейчас пытаюсь LLMить на Расте, при этом заставлять LLM писать типы везде, где это вообще возможно по синтаксису. Но о результатах пока рано. LLM кстати сильно сопротивляется, в размышлениях пря целая драма каждый раз: "в задании и примере сказано писать вот так, но это же не нужно! Ааа! Что же делать! Яду мне, яду!" Короче, просто написать в agents.md что мол вставляй типы везде где можешь - недостаточно.
Genius_Russian_Coders
Полезное сравнение. Ключевое — паттерн: Qwen останавливается на первом ответе, Codex копает глубже. -peek против -top — не деталь, а разница между «вижу проблему» и «понимаю причину». Подтверждаю: без -peek легко пропустить аллокации в middleware.