Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 28
Осторожно, поток нефильтрованного козла:
Жаль, я сам в 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 что мол вставляй типы везде где можешь - недостаточно.
Хм
Qwen/Qwen3.6-35B квантизованную можно запустить офлайн на рабочей станции с 5090 rtx скажем, без всяких лимитов и со скоростью под сотню токенов в секунду. Оно так окупится быстро
А причем тут это если речь об qwen3.7-max, это же разные "весовые категории"?
Qwen3.6-35B для серьезных задач даже близко воспринимать не стоит.
Я экспериментировал с Qwen3.6 27B (имхо, не moe, модели лучше при том же количестве параметров, хотя при этом медленнее)
Результат: https://krypt-lx.github.io/se-steam-battery-calc.htm
Здесь практически всё, кроме конечной математики написано ИИ.
Интересно то, при работе с Qwen3.6 присутствует довольно осязаемый порог сложности задачи, после которого резко падает качество ответа, причём "сложность" не зависит от размера занятого контекста и релевантности к задаче: То есть, пока в коде была только половина вычислений - правки разметки проходили с первого раза и без всяких проблем, но как только в js была добавлена вся математика - появились баги при редактировании gui кода.
При этом в отдельном чате модель смогла решить математический компонент задачи по его текстовому описанию, и результат совпал с тем, который я рассчитал сам.
Как не странно, но moe вариант в некоторых случаях может оказаться лучше плотного варианта. Как раз в некоторых приложениях кодинга. Все-таки суммарно параметров почти на треть больше и есть мнение (не в одном месте встречал, но официальных подтверждений пока не нашел), что moe вариант дополнительно обучали относительно плотного. Официально, с цифрами, есть тесты, где заметное преимущество у 35b.
Гонял локально 27B и 35B. Не знаю что там по тестам, но на практике лично для меня 27B выдает более качественные ответы. 35B иногда ломается и даже тулы перестает запускать, вместо этого в чат выкидывает xml теги тулов.
Важное уточнение: обе модели каантизованы в q4. Но без этого даже 32 гигов в 5090 будет мало.
чувак попробуй клод и кодекс последние офигеешь вообще от результатов )
Та же история, появилась возможность поехать карту h200, долго мучал вопросами, что же на ней можно запустить с контекстом 256к, оказалось что не так много интересного и по качеству работы больше всего qwen3.6-27b понравился
Чисто личный опыт. 35b слаб на комплексных задачах. Например что-то типа 'нарисуй мне хомяка бегающего по клетке' - приходится 35b пару итераций давать исправляя недоработки, а 27b чаще сделает с первого раза. На чистых кодовых задачах вполне сопоставимо.
Но есть ещё интересный момент. Пока говорить могу чисто субъективно, метрик у меня нет, но думаю как фактически оценить. Очень похоже, что 35b крайне чувствительна к качеству квантования. Видимо очень быстро накапливаются ошибки из-за особенностей архитектуры. Перебирал разные варианты, некоторые натурально ломаются на большом контексте. Но в итоге нашел два отличных квантования от DuoNeural и fraQtl (от них есть и другие модели). Они очень стабильно себя ведут даже в квантовании iq4_xs
"сложность" не зависит от размера занятого контекста
Вы помните про половину идиота? После заполнения половины контекста, модель резко тупеет.
Максимальный размер контекста Qwen 3.6 27b - 262144, но на моей машине в память столько просто не помещается, максимальное количество что я использовал было 60k.
На этом масштабе, проблема похоже не зависит от размера контекста: в чате с 7 ранними версиями файла, 60к токенов ответы были более качественными, чем в новом чате с удалёнными копиями (~10k), при том что все требования в чате присутствовали в полной мере.
Qwen в определённый момент начал делать совершенно глупые ошибки, вроде проверки типа получаемого события за пределами обработчика событий ("для оптимизации, чтобы не подписываться на лишние события", как он обосновал в процессе мышления).
А температуру и другие настройки крутили?
Нет, я был больше заинтересован в решении задачи, чем как именно она решена. (С тем только уточнением, что я программист, но не web-, потому и ИИ) Стояли рекомендованные для "Thinking mode for general tasks" со страницы модели. Хотя нам есть "Thinking mode for precise coding tasks", но стояли не они. Честно говоря просто забыл про них.
Личный опыт показал, что часто стоит придавить thinking и таки прикрутить температуру. Ну натурально бредить иначе начинает в рассуждениях. Я в итоге обернул llama/ik_llama скриптом для управления моделями и там 4 предустановки и одна кастомная как раз на варианты этих настроек.
Если интересно, могу посмотреть и написать оптимальный вариант для большинства кодинговых задач.
Попробуйте квантование kv кэша. Q8_0 вполне нормально получается. Если инференс на llama.cpp, то можно и турбокванты попробовать (у меня основной инференс на ik_llama, он пока не умеет в турбоквант, но на классической llama.cpp получилось ну очень неплохо).
На 5090 влезет квантизованная 27B с 256к контекстом. Если kv кэш опустить до q4, то и на 4090 влезает. 27B это плотная модель, она умнее 35B.
Она и на 4080 вполне поднимается, правда около 40-48т/с и около 1800т/с на чтение
Вообще не окупится, тупо считаю карточку без компа в магазине она сейчас стоит 400к рублей примерно, это 5500 долларов, это подписка на 2+ года топовой ллмки кодекса или клода.
Про скорость я вообще молчу на одной видюхе она просто мизерная, а еще у тебя квен этот не влезет в 32 гб видюхи одной , и 100 токенов + в секуду у тебя может быть с контекстом 100к , а я работаю всегда на 1кк-1М контекстом .
То есть тут сравнение телеги и ферари к сожалению.
В свое время я относительно долго был фаналом запускать все у себя , к сожалению этот путь в никуда, конгда полностью перешел на внешние апи все стало в десятки раз быстрее, стабильнее и качественее по каждому параметру. Да держал свои сервера с 4090 и да это было уныло.
Как человек немного интересующийся темой могу сказать всё от задач зависит. В некоторых окупается. Тот же RAG - если у тебя ОЧЕНЬ много документов которые сканы PDF и тебе нужно прогнать через хорошие OCR (а тут тоже нейронки рулят да). И токенизировать это всё и в вектор, а потом с этим работать. А если ещё и документы которые ты не хочешь выкладывать в публичный доступ (или нельзя). Ну и насчёт ценника - за 250к рублей можно купить китайского кадавра 4090 с 48 гигами врам, и уже гораздо всё веселее. Ну и для всяких экспериментов - когда не надо беспокоится о лимите, то можно гораздо активнее использовать LLM.
ну просто прогнать клодом или чатгпт не проще , за те же 200 баксов? чем платить сразу много и вперед ?
я просто видел много случаев где делали по разному, и в них всех железо ни разу не было лучше и дешевле.
то есть какие то случаи есть конечно но их единицы и вероятность что ты попал в них не велика.
Из забавного в итоге я тупо отказался от своего рага, так как гонять ллмку по апи вышло дешевле на голых текстовых знаниях, так как знания в целом одинаковые и запрашивают их часто за счет кеширования там 10х выигрыш в цене идет на апи. Что в свое время стало решающим фактором, цена апи просто на порядок дешевле своего решения.
Нет, не проще. Сильно дороже - если один-десять-сто документов то возможно. Плюс дальнейшее хранение и использование. Плюс чисто юридические проблемы если делаешь это не для себя (простейшее - оплата). Плюс возможность в любой момент словить блокировку. Я не спорю что для кодинга лучше, но не кодингом единым живы нейронки :)
Нужно ли? Обязательно! Это король локальных ллм
Здесь больше подошёл бы заголовок "Нужно ли использовать Qwen для анализа кода на Go? Качество и цена"
А ведь есть ещё масса других задач, где он хорошо справляется в бесплатной версии:
Перевод на русский, в т.ч. научных текстов (не нужно весь целиком, по одной главе)
Разъяснение сложных мест в научных текстах
Выборка и преобразование данных, причём весьма сложное
...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нужно ли использовать Qwen? Качество и цена