Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 152
reasoning-budget на самое лучшее решение, это как мешком по голове, чтоб все мысли убрать. У 3.8 можно гораздо гибче размышления настраивать с помощью reasoning-effort.
Попробуй такой параметр для llama-server:
--chat-template-kwargs '{"reasoning_effort": "low"}'Можно задавать low, medium, high, и кажется xhigh
xhigh ставится по умолчанию, если не ставить другой параметр. От этого и идут жалобы что модель якобы очень много думает
кажется возникло недопонимание по поводу reasoning-budget
Изначально я добавил эту настройку для 3.6, потому, что 3.6 периодически зацикливалась на: "...I will provide the best answer, I will provide ..." и так по-кругу.
Т.е. reasoning-budget для 3.6 использовался как ограничитель, чтобы модель остановилась, если ушла в цикл. Нужно отметить, что reasoning-budget не обрывает рассуждение на середине, а довольно мягко способствует тому, чтобы модель в него уложилась.
3.8 в этом плане гораздо лучше, за последние 4 дня она ни разу не уходила в подобный цикл. Поэтому я увеличил reasoning-budget и планирую его еще увеличить. Т.е. меня полностью устраивает как она рассуждает и я готов дать ей еще немного пространства для рассуждения (не ограничить, а добавить), рассуждения выглядят обоснованными и вполне логичными, и не затягиваются надолго, если задача сложная модель может потратить больше токенов, но для простых задач тратит совсем немного (значительно меньше чем тратила 3.6), т.е. выглядит так, что 3.8 эффективние использует бюджет.
(вообще конечно нужно поиграть с настройками, но вроде как все и так работает, а времени пока нет)
Понятно, да, как стоп-кран от зацикливания имеет смысл оставить, хотя 4к токенов маловато, у меня бывало 3.6 без зацикливания и по 8к токенов думало над чем-то сложным.
Мне кажется - циклы в мышлении - это артефакт квантования - для 3.6 я вижу разницу между Q3_K_M и Q4_K_M - Если я чате который ушёл в цикл остановить модель и стереть цикл до его старта - Q3 квант опять уйдёт в цикл. Если же в этот чат загрузить Q4 перед началом цикла - он выдаст "wait, no, <minor correction>" и продолжит корректно рассуждать.
Каждый раз одно и тоже, люди используют гиперпарамтеры по умолчанию, потом у них то Qwen 3.6 27B галлюцинирует, то Qwen 3.6 35B A35 зацикливается, то Qwen 3.8 27B долго думает...
Что сложного в том, чтобы открыть, например, unsloth и прочитать:
Qwen3.8-27B is a hybrid thinking model with different default settings for thinking and non-thinking modes. Extra high is enabled by default so if you want shorter thinking traces, you can adjust the thinking effort:
Thinking Mode:
temperature=1.0,top_p=0.95,top_k=20,min_p=0.0,presence_penalty=0.0,repetition_penalty=1.0Instruct (or non-thinking) mode:
temperature=0.7,top_p=0.80,top_k=20,min_p=0.0,presence_penalty=1.5,repetition_penalty=1.0
Сравните рекомендуемые параметры с вашими.
От себя могу добавить, что рекомендуемые параметры точно работают для Q8 и BF16. Для Q4 и ниже уже начинается лотерея т.к. такие модели могут зацикливаться из-за накопленных ошибок.
Добавлю, что у локального Qwen 3.6 действительно был сломан Reasoning - часто зацикливался даже на не очень сложных задачах. Этот дефект был исправлен в сборках Jackrong - все работало отлично на тех же параметрах.
Спасибо за статью.
--reasoning-effort не работает нормально, как я с ним не бился, да xhigh совсем упоротый но ни low ни medium, ни кастомные шаблоны со своими ароматами рассуждений ситуацию не меняют. Я на 3.8 перешёл с 3.6 ThinkingCap, после него это лажа. Только reasoning-budget помог но это костыль. ThinkingCap работал с тем же качеством, но в 5 раз меньше рассуждал без ограничителей. А 3.8 без бюджета вообще не целесообразно.
PS: смотрю у многих проблема с зацикливанием. Используйте вместо llama.cpp форк beellama он мгновенно в фоне их отлавливает.
Заметил что thinkingcap для 3.8 появился, пойду проверять.
Почему использован --temp 0.6, если разработчиками модели рекомендуется 1.0?
так получилось. Я редко использую модель для написания красивых текстов, на письма и что-то короткое 0.6 - нормально, а излишнее творчество мне ни к чему, пусть лучше на один и тот-же вопрос она отвечает более-менее одинаково.
Как я понял температура 1.0 в qwen3.6 не тоже самое что температура 1.0 в qwen3.8. Поэтому для одних и тех же сценариев для qwen3.6 разработчики рекомендуют 0.6, а для qwen3.8 - 1.0
может быть, нужно будет просмотреть, но в целом, то что выдает qwen с 0.6 меня устраивает
Но ведь архитектура моделей одинаковая. Разница только в весах
Абсолютно одинаковая. Даже рекомендуемые параметры у обоих версий одинаковые.
Просто у 3.8 появился reasoning_effort который регулирует глубину рассуждений, температура же отвечает за "качество" рассуждений и постоянство ответов.
Смотрите мой комментарий ниже.
Скорей всего тоже самое, я и на 3.6 использовал 1 хотя везде написано что 0.6 Просто потестил и в 10 случаях из 10 это работало хуже. Это фича для тех времён когда для рассуждений и непосредственно изменения кода использовались разные модели. Можно в клиенте сделать что бы для чата 1 было, а для редактирования файлов 0.6. если работаешь без разделения 0.6 очень вредит, тупеет на порядок в сложных задачах.
Это дает более детерминированный ответ. Некоторые задачи требуют одинакового точного и повторяемого результата. При температуре 1.0 в ответ включается креативность модели, она начинает выдумывать где не надо и ее рассуждения может занести не в ту степь. 1.0 - хорошо для написания уникальных текстов, генерации картинок без повторений. Но цена высокой температуры это галлюцинации, например кривые лица на изображении или люди с 6 пальцами. Для программирования хороший вариант это 0.6-0.7 так как важнее постоянство ответа. Не обязательно придерживаться рекомендаций разработчиков модели, нужно модель настраивать под свои конкретные задачи.
а если не секрет, на каком железе это запускается?
В тексте написано, что на RTX4090. Все остальные параметры железа глубоко вторичны.
на виртуалке с Arch и проброшенной внутрь RTX4090
а можно вопрос? для чего именно виртуалка с арчем? я только что повторил то же самое сразу на вин11
просто я как-то давно вместо винды установил Arch, у него rolling release, вот он так и катится от обновления к обновлению. Виртуалка удобна для экспериментов, потому, что если что-то сломается не нужно все переустанавливать, ну а Arch на виртуалке - потому, что удобно иметь одну систему везде.
На windows система достаточно значительное количество VRAM резервирует, даже если подключить монитор к igpu процессора. На cachy os, используя beellama и сжатие kv кеша kvarn6 у меня получилось запустить модель в 5q без mtp на 24 ГБ vram
Гугл мне сказал что разницы между q4 и q5 практически нет.
Или вы имеете ввиду что скорость адекватная?
Качество модели по идее должно быть лучше. Но я разницы не заметил, если честно :D. Сразу скажу, что я не программист, мои задачи просты: системное администрирование - настрой, установи; задачи связанные с таблицами - напиши скрипт на python - pandas. Кстати, Glimmer для этих задачи мне показался поприятнее - работает быстрее в плане размышлений и в плане ток/сек.
Гугл врёт, в реальных задачах разница большая, даже между q8_K_L и q8_K_XL хоть и разница в точности уже какие то десятые процента. Но на деле попадается задача которую не можшь решить нейронкой убираешь 20к контекста, запускаешь модель на 500мб побольше, и она ее не замечает.
(спасибо! попробую mtp и разные квантования)
а на чем виртуалку крутите, qemu? я чет немного от темы отстал, никогда гпу не пробрасывал на обычных десктопных решениях)
да qemu. Подробную инструкцию дать не смогу, делал пару лет назад, не помню, но не очень сложно, может 1-2 часа. Использовал Archwiki, тогдашний ChatGPT и что-то с форумов.
да у меня сейчас вопрос развертывания не стоит, просто думаю на будущее, что есть варианты для домашнего сервака с виртуалками) спасибо)
Если интересно, то несколько часов назад развернул через docker-compose.yaml на ВМ, которой дал 48ГБ и 6ЦПУ. ВМ крутится на Proxmox с камнем Ryzen 8845HS (gmktec k8 plus). Видеокарты нет. Так что скорость 1.93 токена/сек. Да медленно и долго, но для ознакомления что это вообще такое и как работает - вполне ))
Делал впервые с ИИ от Гугла ))
спасибо очень полезная информация
пользуюсь unsloth там кстати внутри и mtp есть сразу, я вот так включаю
--spec-type draft-mtp --spec-draft-n-max 2и ещё рекомендую всем турбоквант, у меня эта модель в q4_k_m влазит полностью в gpu 24gb с 128к контекста и место ещё остаётся
А сколько токенов в секунду? У меня на 7900хтх максимум 14 почему то
у меня на 3090 40-60ток/с с mtp и 25-30 без mtp
Не покажете конфиг запуска? :)
У меня 14 с мтп
unsloth у меня как-то не зашел, а на счет mtp - хорошая идея, попробую. Спасибо!
вашим способом gguf даже меньше чем у unsloth
и при этом mtp так же в нём уже есть и работает
пример скорости с mtp
Спасибо! У вас кстати скорость получилась больше чем у меня (у меня примерно 45-50 токенов в секунду)
я думаю это из-за виртуалки с пробросом gpu, я раньше в wsl запускал и у меня скорость вроде как меньше была чем в вин11, хотя у меня сейчас должна быть скорость меньше чем у вас (особенно учитывая что у меня только 3090), т.к. турбоквантование контекста сжимает потребление памяти контекстом в 4.74x и уменьшает скорость в 0.87x при этом качество в сравнении с контекстом f16 даже выше на 8%
нашел!!! :) я поставил ограничение мощности видеокарты на 360 Ватт а потом об этом забыл! :))) Так-что виртуалка тут ни при чем
странно, но моя выдаёт такую скорость при 350 ватт-ах, стоковые экстрим параметры на 420 ватт не использую))
интересно! если будет время посижу в выходные посмотрю растройки llama-server. Можете еще раз подсказать какая скорость у Вас получается с какими настройками?
Скрытый текст
llama-server.exe -m “C:\models\Qwen3.8-27B-Q4_K_M\Qwen3.8-27B-Q4_K_M.gguf” --ctx-size 128000 -ngl all --load-mode none -fa on --jinja --temp 0.6 --repeat-penalty 1.1 --top-k 20 --top-p 0.95 --min-p 0.0 --port 8080 --no-context-shift -ctk tbqp3 -ctv tbq3 --spec-type draft-mtp --spec-draft-n-max 2
скорость выше в чате на скриншотах
У вас "старый" gguf от Unsloth.
Давеча они выкатили версию UD 3.0, уменьшив размер и сохранив качество.
поправьте, у вас вместо gguf -> guff
--outfile ~/models1/Qwen3.8-27B/my_conversions/Qwen3.8-27B-F16.guff
залил сорсы своего форка llama.cpp (only cuda), суть такая: это последняя версия llama.cpp но с поддержкой турбоквантования контекста, не уверен насчёт сборки для линукс но может и выйдет что то, тестировал у себя только для вин 11 под rtx 3090
для контекста в режиме турбокванта рекомендую -ctk tbqp3 -ctv tbq3
а для mtp --spec-type draft-mtp --spec-draft-n-max 2
рекомендую -ctk tbqp3 -ctv tbq3
А вы понимаете, что этим делаете лоботомию сети? V кеш еще можно квантовать в Q8, но K кеш должен быть в FP16/BF16. Точность K-кеша критически важна, это суть механизма внимания, в логике которого в конце идет softmax.
Softmax это экспоненциальная функция. Из-за экспоненты даже небольшая погрешность в K сильно искажает веса внимания и модель начинает смотреть не туда или теряет контекст.
Лучше квантуйте напрочь саму модель и урезайте леща длину контекста, вместо того чтобы трогать K кеш, иначе ваши модели будут галлюцинировать и зацикливаться выдавая мусор. А потом пользователи будут писать о том какие плохие модели, не могут ничего.
Квантование модели и квантование кеша это две большие разницы.
только у меня модель не "будут галлюцинировать и зацикливаться выдавая мусор" а работает без проблем, почитайте что и V и что K кэш имеет качество в турбокванте этом выше чем bf16 и по тестам больше задач решает
Нет, это не правда, TurboQuant не делает качество KV-кэша выше, чем у исходного формата bf16 просто потому что bf16 это исходная точность для большинства моделей, а TurboQuant дает сжатие с потерями.
Вы транслируете миф не разобравшись в вопросе.
При работе с очень длинным текстом (256K+ токенов) кэш в формате bf16 полностью забивает видеопамять (VRAM). Модель на bf16 либо падает с ошибкой Out Of Memory, либо вынуждена обрезать контекст и за счет этого проваливает задачу. TurboQuant сжимает кэш в 3-5 раз (до 3-4 бит на элемент), благодаря чему длинный текст влезает в GPU и задача успешно решается.
Также, на небольших выборках квантованная модель за счет шума квантования может случайно угадать на 1-2 теста больше, чем bf16.
В IT-новостях оба эти момента подают как TurboQuant превзошел несжатую модель!!!1.
Нет, это не правда
ну это ваше мнение
случайно угадать на 1-2 теста больше, чем
bf16
ну для вас может и случайно, на я вижу слишком много закономерностей, и турбоквантом именно этим пользуюсь с момента его появления, а их есть не мало разных, в том числе и которые хуже чем bf16
это ваше дело верить или нет, я раньше сам делал тесты и у меня турбоквант показывал себя лучше (на qwen 3.5 9b) но сорян результатов и тестов не осталось
не включают его в офф сборку llama cpp по разным причинам, начиная от того что реализаций разных есть не мало и всё ещё идут споры как правильно это стоит делать и с какой реализацией
ну это ваше мнение
Не только мое, ознакомьтесь, раз, два.
И вы не со мной спорите, а с логикой работы механизмов квантования.
Я верю, что в отдельных тестах у вас что-то показало хорошее, более того у исследователей из Google тоже показало хорошее, вот только потом независимые проверки показали, что это хорошее относится к узкому набору академических задач и моделям БОЛЬШИХ размеров.
Скрытый текст
как я и писал выше, вариаций турбоквантования много, тесты я делал именно этого варианта, также автор на гите приводит пять seeds и пишет о среднем примерно +20% vs f16 так что лично я буду и дальше использовать этот тип турбоквантования т.к. уже пол года пользуюсь и проблем с моделями не вижу, даже если использую их при заполненном контексте
Проблема квантования - это выбросы в оригинале, для этих выбросов нужен bf16, который имеет огромный динамический диапазон, и такие выбросы причина, почему нельзя просто без потерь квантовать контекст. Контекст очень чувствителен к этим выбросам и нельзя их срезать.
В TurboQuant проблему выбросов решили через вращение Адамара. Изначальный вектор переводится в другую систему координат, сохраняя его энергию, но распределяя значения уже более равномерно. Такой новый сглаженный вектор не имеет выбросов и может иметь лучшую математическую стабильность, и плюс хорошо поддается квантованию почти без потерь.
В общем есть теоретическое обоснование, почему TurboQuant может быть стабильнее чем bf16, как это на практике - нужно больше тестов. Вращение Адамара уже реализовано в llama.cpp, поэтому, например, квантовать в Q8_0 на основной ветке стало вполне приемлемо, по сравнению с тем, что было раньше.
В TurboQuant проблему выбросов решили через вращение Адамара.
TurboQuant использует случайное вращение векторов (метод PolarQuant), чтобы размазать крупные выбросы по всем измерениям. Т.е. повезет/не повезет размазать хорошо.
В общем есть теоретическое обоснование
Приведите ссылки, потому что практически проверки это не показывают.
См. комментарий выше.
TurboQuant использует случайное вращение векторов (метод PolarQuant), чтобы размазать крупные выбросы по всем измерениям. Т.е. повезет/не повезет размазать хорошо.
Смысл поворота Адамара в повороте, случайность позволяет перекрутить вектор. “повезет/не повезет” - тут это не применимо, так как мы можем проверить результат. Разница лишь в том, какая часть вектора будет пиком, сглажен он будет целиком и совершенно не важно какая будет итоговая случайная форма, важно только то, что вектор теперь входит в диапазон 3-4 бит.
совершенно не важно какая будет итоговая случайная форма
Как это не важно, если вращение подгоняет вектор под гауссовское распределение. Именно под такую форму математически строится сетка квантования на 3-4 бита. При этом случайная матрица знаков обязательна быть определенной формы так сказать, иначе чистый Адамар в худшем случае может не размазать, а заново собрать пик.
важно только то, что вектор теперь входит в диапазон 3-4 бит.
Размазывая крупный выброс по всем измерениям, мы превращаем его в распределенный фоновый шум. Вектор начинает влезать в малый диапазон, но из-за этого шума проседает точность скалярных произведений в слоях Внимания. Т.е. важно то, насколько точным будет результат в слоях внимания, а не то что вектор теперь влезает в диапазон.
Видимо таки придется написать небольшую статью-гайд про квантование для малых объемов памяти.
>--spec-type draft-mtp --spec-draft-n-max 2
можно поставить --spec-draft-n-max на максимум, и ограничивать количество черновых токенов через минимальную вероятность принятия: --spec-draft-p-min 0.80 - на легко предсказуемых участках будет будет успешно предсказывать больше токенов за раз, на трудно предсказуемых - будет меньше зря пытаться.
Про tbq3 - это не из этой https://habr.com/ru/companies/selectel/articles/1022312/ статьи? Там явная бессмыслица попадается, если присмотреться.
https://github.com/ggml-org/llama.cpp/pull/21038#issuecomment-4150413357 (TQ5 лучше, чем Q8, TQ8 ~FP16) я как-то больше верю.
нет не про эту статью, а из github
К сожалению в распоряжении ПК с 4090 24гб нет, зато есть две 5080 16гб, у кого был опыт использования двух видеокарт для этих целей?
у меня опыта нет, но в целом должно быть юзабельно, gpt говорит вот так следует делать:
Скрытый текст
2 5080 16 ГБ это гораздо лучше для запуска qwen3.8-27b чем одна 4090. Можно использовать менее заквантованную модель и больше контекста
Три 5060ti 16gb в режиме -sm tensor и nvfp4 квантовании и mtp выдают в среднем 60-65 токенов в секунду.
Может у кого есть опыт? Есть 3060, хотел докупить модифицированную 2080ti 22 gb. И не знаю имеет ли смымл для qwen 27b. Адекватная ли будет скорость и размер контекста? Просто не хочется контекст меньше 200к, потому что в агентских сценариях он заполняется очень быстро.
У меня как раз такая конфигурация работала, пока 2080ti 22 gb не сгорела. Два месяца. Скорость вполне приемлемая была - примерно 30-40 t/s с mtp и 500 t/s на заполнение.
У меня опыт есть, правда две 3090. Скейлится замечательно, делать для этого ничего не нужно, правда, конфигом llama.cpp поделиться не могу, т.к. запускаю в LM Studio.
С MTP выходит 50 tps.
нашёл ещё более быстрый вариант "FastMTP" внутри модели "HauhauCS/Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-MTP-GGUF"
но нужно собирать особую сборку llama.cpp
HauhauCS FastMTP: up to 3.02x document TG and 1.93x reasoning TG versus non-MTP — plus up to 35.2% more document TG and 21.1% more reasoning TG than standard embedded MTP.
месяц назад тестировал разные комьюнити версии qwen3.6 , без цензуры, более оригинальные и в результате для моих devops задач самой комфортной оказалась чистая модель от unsoloth, а все сторонние версии наоборот вызывали огромное количество зацикливаний и галлюцинаций. также иногда в комьюнити сборках что-то ломают и для агентской системы модель уже не пригодна ибо aider или openhands перестаёт видеть где код, а где обычный текст
Я вот все хочу разобраться, как самому сделать uncensored модель, да руки не доходят. Думаю, если бы кто-то написал руководство было бы круто. Хотя наверняка кто-то уже написал, вы в эту сторону не смотрели?
Готовое решение есть https://github.com/p-e-w/heretic
p.s. для проверки сделал ещё один форк с турбоквантом + fastmtp и вот мои результаты скорости на rtx3090 (350w)
p.s.s. 128к контекста так же помещаются полностью в vram
Скрытый текст
параметры запуска
llamacppfast/llama-server.exe -m “C:\models\Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-Q4_K_P.gguf” --spec-draft-model “C:\models\Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-FastMTP-32K.gguf” --spec-draft-ngl all --spec-type draft-mtp --spec-draft-n-max 3 --spec-draft-p-min 0 --ctx-size 131072 --parallel 1 --batch-size 2048 --ubatch-size 512 -ngl all --split-mode none --load-mode none -fa on --no-mmap --temp 1.0 --top-k 20 --top-p 0.95 --min-p 0.0 --presence-penalty 0 --repeat-penalty 1.0 --jinja --reasoning on --reasoning-effort xhigh --reasoning-preserve --reasoning-format deepseek --host 127.0.0.1 --port 8080 --no-context-shift -ctk tbqp3 -ctv tbq3
странно но скорость упала, думаю из за турбокванта, хоть и по логам всё ок..
а вот сразу после неё запустил турбоквант + обычный mtp (так же 350w) + froggeric/Qwen-Fixed-Chat-Templates (он кстати по умолчанию делает размышления Medium)
Скрытый текст
параметры запуска
llamacpp2026/llama-server.exe -m “C:\models\Qwen3.8-27B-Q4_K_M\Qwen3.8-27B-Q4_K_M.gguf” --ctx-size 131072 -ngl all --load-mode none -fa on --jinja --temp 1.0 --repeat-penalty 1.0 --top-k 20 --top-p 0.95 --min-p 0.0 --port 8080 --no-context-shift -ctk tbqp3 -ctv tbq3 --spec-type draft-mtp --spec-draft-n-max 2 --chat-template-file “C:\models\chat_template.jinja”
и ещё пробовал работу с лимитом в 500w (реальное потребление было 440w) и скорость выросла но всего около 1% разница..
У меня на стоковой llama.cpp и двух 3090 (350Вт):
$ llama-server --host 0.0.0.0 --port 8081 -m ./Qwen3.8-27B-UD-Q8_K_XL.gguf -ngl 999 -c 240000 --temp
1.0 --top-p 1.0 --top-k 20 --min-p 0.00 --presence-penalty 0.0 -np 1 --spec-type draft-mtp --spec-draft-n-max 2 --reasoning-preserve --cache-ram 32768 --ctx-checkpoints 32 -sm tensor --fit off
...
2.32.873.159 I slot print_timing: id 0 | task 0 | n_decoded = 6623, tg = 64.52 t/s, tg_3s = 64.97 t/s
2.35.901.106 I slot print_timing: id 0 | task 0 | n_decoded = 6833, tg = 64.66 t/s, tg_3s = 69.35 t/s
2.38.910.320 I slot print_timing: id 0 | task 0 | n_decoded = 7063, tg = 64.99 t/s, tg_3s = 76.43 t/s
2.41.929.441 I slot print_timing: id 0 | task 0 | n_decoded = 7310, tg = 65.44 t/s, tg_3s = 81.81 t/s
2.44.934.252 I slot print_timing: id 0 | task 0 | n_decoded = 7529, tg = 65.64 t/s, tg_3s = 72.88 t/s
2.47.995.636 I slot print_timing: id 0 | task 0 | n_decoded = 7779, tg = 66.05 t/s, tg_3s = 81.66 t/s
2.50.998.628 I slot print_timing: id 0 | task 0 | n_decoded = 8007, tg = 66.30 t/s, tg_3s = 75.92 t/s
2.54.009.860 I slot print_timing: id 0 | task 0 | n_decoded = 8227, tg = 66.46 t/s, tg_3s = 73.06 t/s
Q6 влазит с полным контекстом и даёт до 90т/с.
Счастливые обладатели 5090 могут попробовать: https://github.com/Neroued/ninfer - оптимизированный движок под конкретную связку 5090/qwen.
спасибо, добавили уверенности и сам собрал модель на Q6 , весит < чем модель от unsloth. Думаю, что теперь всегда буду сам собирать модели.
ещё собрал sh файл для этого, может кому-то пригодится :
#!/bin/bash
# Путь к папке llama.cpp (измените, если проект лежит в другом месте)
LLAMA_DIR="/path/llama.cpp"
# 1. Проверяем, существует ли виртуальное окружение по абсолютному пути. Если нет — создаем.
if [ ! -d "$LLAMA_DIR/.venv" ]; then
echo "Создаем виртуальное окружение в $LLAMA_DIR/.venv..."
python3 -m venv "$LLAMA_DIR/.venv"
echo "Активируем и устанавливаем зависимости..."
source "$LLAMA_DIR/.venv/bin/activate"
pip install --upgrade pip
# Установка зависимостей, необходимых для convert_hf_to_gguf.py
if [ -f "$LLAMA_DIR/requirements.txt" ]; then
pip install -r "$LLAMA_DIR/requirements.txt"
else
# Если requirements.txt не найден, ставим базовый набор для конвертации
pip install torch torchvision torchaudio transformers sentencepiece safetensors gguf
fi
else
# 2. Если уже существует, просто активируем по абсолютному пути
source "$LLAMA_DIR/.venv/bin/activate"
fi
# 3. КОНВЕРТАЦИЯ
python "$LLAMA_DIR/convert_hf_to_gguf.py" \
/path/qwenHF/Qwen3.8-27B \
--outfile /path/qwenHF/out_model/Qwen3.8-27B-F16.gguf \
--outtype f16
# 4. КВАНТОВАНИЕ
"$LLAMA_DIR/build/bin/llama-quantize" \
path/qwenHF/out_model/Qwen3.8-27B-F16.gguf \
path/qwenHF/out_model/Qwen3.8-27B-Q4_K_M.gguf \
Q4_K_M
Вот и хорошо! Это не сложно!
сам собрал модель на Q6 , весит < чем модель от unsloth
Unsloth используют пропиетарный фреймворк Dynamic, который, по их измерениям, приводит к меньшей деградации качества - видимо за счёт некоторого увеличения размера модели на выходе. Сейчас там уже третья версия https://unsloth.ai/docs/basics/dynamic-3.0-ggufs . Набор утилит из llama.cpp полезен когда есть чисто академический интерес разобраться в принципах.
Dynamic это не название фреймворка, и даже не алгоритм квантования, а обозначение их рецепта динамического квантования, когда разные тензоры квантуются по разному плюс используется imatrix для суб-динамического квантования внутри тензора. Всё это делается скриптом llama.cpp по кастомной схеме, вместо заранее созданных вроде “Q4_K_M”. В llama-quantize указывается --custom-q "$custom", а сам --custom-q уже может быть динамически настроенным:
custom="
# 64 Repeating Layers [0-63] + blk.64 MTP/nextn tensors
## MTP/nextn tensors
blk\.64\..*\.weight=iq4_ks
## Gated Attention/Delta Net [Blended 0-63]
blk\..*\.attn_gate\.weight=iq4_ks
blk\..*\.attn_qkv\.weight=iq4_ks
blk\..*\.attn_output\.weight=iq4_ks
blk\..*\.attn_q\.weight=iq4_ks
blk\..*\.attn_k\.weight=iq4_ks
blk\..*\.attn_v\.weight=iq4_ks
blk\..*\.ssm_alpha\.weight=q8_0
blk\..*\.ssm_beta\.weight=q8_0
blk\..*\.ssm_out\.weight=q6_0
# Dense Layers [0-63]
blk\..*\.ffn_down\.weight=iq4_ks
blk\..*\.ffn_(gate|up)\.weight=iq4_ks
# Non-Repeating Layers
token_embd\.weight=q6_0
output\.weight=q8_0
"
Матрица важности задается через --imatrix, и качество динамического квантования напрямую зависит от imatrix датасета. Сейчас imatrix используют даже для статического квантования Q4_K_M.
Проблема чужих imatrix в том, что они не оптимизированы для русского языка, основной упор делается на английский язык. Создать свой датасет для imatrix под свой сценарий может быть не плохим решением, позволяя сжать модель сильнее, но сохраняя качество для вашего сценария.
И если цель минимальный размер, то стоит смотреть в сторону ik_llama, вот у них как раз именно новые математические алгоритмы квантования, позволяющие тоже качество засунуть в меньший размер. Кванты вроде Q4_K_M или IQ4 созданы не llama.cpp, а ikawrakow, который сейчас в ссоре с ggerganov и поэтому ikawrakow создал форк ik_llama.cpp, где продолжает улучшать алгоритмы квантования и новые SOTA кванты показывают отличные результаты.
Там вроде немного сложнее. Вот попытка сделать подобный пайплайн, адаптированный под консьюмерское железо https://github.com/imrrohitt/OpenDynamicGGUF
Я скорее про то, что это всё еще поиск рецепта, и этот рецепт не универсальный. Dynamic это путь перебора, который завязан на магическом калибровочном датасете, который они не показывают, не указывают длину контекста подбора, процент представление других языков, помимо английского и т.д. Не факт, что этот датасет совпадает с вашим сценарием или языком, что может выражаться в нестабильности ответов, зацикливании или сломанной согласованности с увеличением контекста.
Если выбирать между TurboQuant и выборочным перебором, где определяется какая часть контекста важна, а какая нет на основе собранного кем-то сценарии, то мало кто выберет второй вариант, если будет знать, что TurboQuant дает математическое решение снижения веса контекста в 2-3 раза без значимых потерь. И ik_llama дает математическое уплотнение, уплотняя упаковку самих данных.
Для тех, кому интересно попробовать:
Сборки ik_llama под Win: https://github.com/Thireus/ik_llama.cpp
Квант ik_llama Qwen3.8 27B: https://huggingface.co/ubergarm/Qwen3.8-27B-GGUF
Если выбирать между TurboQuant и выборочным перебором
Спасибо за ссылки. Как TurboQuant связан с квантизацией моделей?
Турбо квант вообще никак не связан с квантизацией модели. Турбо квант квантизирует кэш контекста.
Через аналогию. Аналогично TubroQuant, у ik_llama улучшение за счет новых алгоритмов квантизации, за счет уплотнения всех данных, а не просто за счет перебора и выбора, что оставлять, а что выкинуть.
Насколько я понимаю, без квантования модели пока не влезают в консьюмерское железо. А с квантами результат сильно портят ошибки, которые связаны с накоплением погрешностей вычисления. Вот с этим и пытается бороться UD, подгоняя веса для минимизации ошибок в типичных сценариях. Да, условно с русским может стать хуже, но по крайней мере JSON на выходе будет джейсоном. Оптимизации, связанные с данными, тоже полезны. Просто, как тут выше уже сказали, они решают другие задачи.
Всё таки. Вот зачем. Как-то я очень скептично отношусь к локальным моделькам... Да, это почти уровень opus 4.6 умещающийся в видеокарте на 16-24гб, окей, вау, великолепно... Но в чем смысл? Да если по электричеству посчитать загрузку видеокарты под агента условные 24/7 то выйдет те-же 20 долларов подписки если не дороже... Только вот подписка даст не фронтир 8-10 месячной давности а слегка получше модельки. Нет, для каких-то специфичных целей/условий еще туда-сюда, но для повседневного использования...
хобби, обработка данных без утечки, не у всех питание от сети, я себе скоро поставлю солнечные панели и будет кондей крутить + локальные нейронки, rtx3090 бу не так дорого сейчас (лично я себе покупал для игр и работы с 3d, но наступила эра нейронок..) + недавно вышла minimax h3 для генерации видео, на 24гб работает отлично, при этом у меня подписка gpt и видео-генератора там уже нет + доступны модели всегда, даже когда подписка закончилась
у меня была статья на эту тему: Почему Qwen3.6-27B лучше чем Claude? Железная коробка, которая научилась думать - в которой я попробовал сформлировать ответ на Ваш вопрос - "Зачем". И там длинное обсуждение в комментариях, почитайте.
А если в нескольких словах: приватность, стоимость, гарантированное качество ответа, возможность автономной работы, альтернатива монополии биг-теха на интеллект и знания.
Не уверен, что это действительно уровень Opus, но это неважно. Важно то, что она делает то, что мне нужно (нужно именно мне а не какому-то чуваку из Google, OpenAI, кгб, цру, масад, <подставьте свое>) и делает это значительно быстрее, чем могу сделать я сам и с качеством достаточным для выполнения поставленных задач.
Ну такое. Нет, про приватность то ок, аблитерированные модельки - ну допустим, хотя они ничего нормального писать то и не умеют) (нормальная художка, тем более nsfw, прям больное место абсолютно всех моделей) Но вот всё остальное это на мой взгляд немного натягивание бедного животного на его же хвост, где минусы подаются как плюсы. Чтоб был нормальный контекст (это я с учётом квантования контекста) нужна видеокарта от 32гб (ну или безжалостно квантвоать модельку, но качество страдает) выжать приемлемую скорость декода тоже сложно. Нужно однозначно пихать всё в видеокарту, даже моешка вероятно не поможет, я вот на 32ddr4 и 8гд rtx 3070 запускал 3.8 27b (в q4 k.m кажется), и получил свои честные 3.5 токена в секунду... Ну это ни о чём.
И качество. По бенчмаркам (хотя там вероятно некорректно сравнение обязок) qwen 3.8 27b действительно в общем-то обходит opus 4.6, но блин, может она подойдёт для чего-то относительно несложного, мелких правок, чата, но модельки за последние 8 месяцев вообще говоря улучшились, как и обвязки. И прям существенно. Так что чат да, поиграться да, мелкая несложная работа возможно, если есть видяха стоимость как крыло самолета.
Про то что корпорации следят за нами... Ну Карл. Покажите мне того кто не следит в той или иной мере.
Чтоб был нормальный контекст (это я с учётом квантования контекста) нужна видеокарта от 32гб
я уже чуть ли не в каждом комментарии про турбоквантование говорю😂
суть в том что это специфичное квантование не доступно в базовой сборке llamacpp но есть форки с его поддержкой, оно условно сжимает именно контекст в целых 5 раз!, при этом скорость генерации чуть падает (87%) как бонус качество контекста даже выше чем базовое квантование f16 итого на 24gb vram (даже на вин11 которая сама сжирает не мало vram) у меня занято 22gb на этой модели qwen 3.8 27b q4_k_m с контекстом 128к, при этом если его поднять до 256к будет занято около 23-24gb (желательно при 256к не использовать vision модель) и не нужны не какие 32+gb
более того я запускал популярный форк qwopus 9b на 1млн контекста и он занимал вроде как 18gb vram со всем контекстом..
главный минус запуска на обычных gpu это медленная обработка промпта (не генерация) особенно это чувствуется в режиме агента где часто пересчитывается весь контекст, у меня быстрее всего работает в qwen code cli, думаю там просто меньше всего системный промпт, хотя последние версии стали больше времени думать..
Да, я про турбоквант слышал, но не пользовался. Но даже так, лям контекста 18гигов... Что там остаётся от видеокарты... И 256к на мой взгляд маловато, разве что сжимать постоянно. Ну в общем если кому-то хочется извращаться, то кто я такой чтобы мешать. Сам ведь такой же.
Про то что с турбо квантом "качество" контекста выше чем базовые квантование f16 можете дать ссылку про исследование? Просто я везде на реддите читаю что турбо квант конечно сильно экономит память, но за счёт снижения качества
турбоквант бывает разный, я смотрел на этот (tbqx3/tbq3)
Ну как "такое". У меня локальная нейронка на потоке читает и фильтрует телеграм чаты, где периодически всплывают потенциальные клиенты. И перекидывает мне в личку только важное, чтобы я сам это всё не читал.
С учётом, что чатов таких у меня больше сотни, и пишут туда каждый день, вклбчая просто флуд - на решение такой задачи облаками нужна была бы отдельная подписака, при том что сама задача не очень требовательна к качеству модели. У меня где-то 24го года модель крутится и менять её особо нет смысла, потому что на 8 гигаьайтах видеокарты результат плюс-минус один.
Вообще-то есть, та же гемма 4 e4b очень сильно прокачана для таких задач. Я например уже только её использую для переводов. Есть еще lfm, тоже прокачаны на минимальное железо
Ну я оцениваю в первую очередь целесооразность тратить своё время на эти эксперименты, и понимаю, что целесообразности нет, тк. качество исполнения уже на нужном уровне, а место "хобби-проекта" уже занято ))
Уверены, что качество на месте? А если будет модель, которая в 100 раз быстрее вашего старья, а результат на голову выше? https://huggingface.co/blog/LiquidAI/lfm25-dspark
а не сравнивали с специализированной translate gemma (она на базе гемма 3)
я вот переводил translate gemma 12b, вроде и скрипт - по одной статье. А результат фиговый. (видеокарта 5060ти, 16гб), буквально даже какие-то слова придумывала
Позже - с помощью апи от гигачата (3,5 макс, 50 тысяч токенов бесплатно), делал коррекцию
вы абсолютно правы. я тоже пришел к таким выводам после месяца экспериментов - подписка проще и развивается все это быстрее. Но потом в целом и на ИИ забил, поняв, что не хочу после первой работы еще и дома работать)
Есть модели, которые можно запустить только у себя - никто их не предложит для подписки: например медицинские (MedGemma), или нецензурированные (abliterated, uncensored, ...)
Кроме всего перечисленного в комментариях, еще могу добавить "опыт". Уметь запускать локально может быть баловством (если нет дома специфичных потребностей), но может оказаться "продающим" пунктом в резюме для какой-нибудь работы с высокими требованиями к локализации (финтех, банкинг, медицинская тайна, и так далее).
Но в чем смысл?
Опенроутер уже почти все, зная страйп не понаслышке. Меньше конкуренции, дороже подписки + квоты, ограничения, падения. Как-то клод полдня не был доступен
Это пока $20. Когда инвесторы придут спрашивать у ИИ-компаний о возврате инвестиций, будет $200 за не самую жирную подписку, если вообще подписки останутся. Иначе экономика не сходится.
Для именно бизнеса, тем более из РФ, поставить сервер для программистов и прочих чтобы своими данными наружу не делится.
вполне ок цена этого квена.
1) пользователь условно 100токенов\с (или даже 200)
2) два пользователя это 150 токенов на ДВОИХ (по 75 т\с)
4) четыре к пользователя это 200 токенов в секунду на ЧЕТВЕРЫХ (по 50т\с)
и там дальше параллелится в пределе до ~300 т.с на 10
на том же железе и том-же электричестве
так что общий сервер для разработчиков своих это даже для маленькой конторы очень хорошо.
Интересно когда выйдет Qwen 3.8 MoE?
Через 18 часов: https://huggingface.co/Qwen/Qwen3.8-Flash-Next
Интересно было бы сравнение со свежей Ornith-1.5 35b.
Каким агентом вы пользуетесь? Что вообще вокруг модели?
А какую модель и степень квантования сейчас лучше выбрать для 12гб врам? 4070ти конкретно.
Я бы на вашем месте выбирал бы модель MoE, ибо хороший квант не влезет в врам, низкий квант- мало смысла. Итого- оффлоад в RAM, а это падение скорости. Если рассадить по максимуму экспертов в VRAM, а все что не влезло, то в RAM, и MoE хотя бы скорость не уронит ниже плинтуса. Единственно что- контекст обязательно в VRAM. Я бы посоветовал бы ornith-1.0-35b, сделана на базе qwen, но работает с mtp шустрее сильно. Пробуйте 4 квант, если скорость из-за выгрузки слоев не устроит, опускайтесь на 3 квант. Ну и никаких ollama, только llama.
Плюсик поставить не могу, но спасибо вам за совет. Я пока что только хочу влезть в сферу локальных моделей и думал начать с чего попроще. Думал как раз с олламы начать, просто посмотреть вообще что выйдет, а потом уже лезть в тонкую настройку. Думаете лучше сразу стоит разбираться со всеми параметрами запуска?
Я думаю что ковыряние всего и вся лучше помогает вкатиться в тему, чем просто нажать кнопку и запустить модель. Да это дольше и сложнее, но на выходе будет понимание и опыт, а не тупое нажатие кнопки.
Режим AI в гугле сходу даст конфиг llama.cpp под конкретный набор железа/модель лучше, чем преднастройки ollamы - и этот конфиг можно видеть и править, в отличие от оламы, где пользователь не знает не то, что особенности кванта - даже какую модель скачал(вспоминаем Qwen под видом DeepSeek)
А какая скорость у вас на 4090 получилась?
У меня такие скорости для Qwen3.8-27B-UD-Q4_K_XL (с MTP):
4090 ~ 70-80 t/s
5090 ~ 120 t/s
2x5060ti ~ 40 t/s.
Без MTP примерно вдвое меньше.
В продолжение обсуждения Qwen3.8 решил проверить её не только на обычных промптах, но и в агентском режиме — когда модель сама читает файлы, ищет информацию, меняет код или данные, запускает тесты и решает, когда работу можно закончить. С помощью Claude собран фиксированный корпус из 15 задач трёх уровней сложности (L1, L2, L3). Были обычные исправления кода, работа с несколькими файлами, ложные подсказки, ошибки инструментов, ограничения на изменение файлов, последовательные вычисления и задачи, где вообще ничего исправлять не нужно — надо это понять и вовремя остановиться. Тесты выполнялись на DGX Spark (Ubuntu 24.04, NVIDIA GB10, ARM64) через OpenAI-совместимые vLLM endpoint’ы. Qwen3.8 в отдельном контейнере - модель unsloth/Qwen3.8-27B-NVFP4 max-model-len=32768, max-num-seqs=1, gpu-memory-utilization=0.55, max-num-batched-tokens=8192. Native MTP был включён через --speculative-config {“method”:“mtp”,“num_speculative_tokens”:1}. Qwen3.6 в контейнере - unsloth/Qwen3.6-35B-A3B-NVFP4-Fast, tensor-parallel-size=1, max-model-len=262144, max-num-seqs=4, gpu-memory-utilization=0.40, max-num-batched-tokens=8192. Также был включён MTP, но с двумя speculative tokens, а также prefix caching. В обоих контейнерах использовалась сборка vLLM 0.26.1rc1.dev18+gd223c900d, квантование NVFP4 в формате compressed-tensors, FP8 KV-cache, FlashInfer attention backend и fastsafetensors. У агента было 11 простых tools: чтение и поиск файлов, работа с JSON/CSV, запись файлов, запуск тестов, просмотр ошибок и diff и т.д. Сначала сравнивается Qwen3.8-27B-NVFP4 + MTP и Qwen3.6-35B-A3B-NVFP4 при temperature=0 и включённом thinking:
Метрика Qwen3.8 Qwen3.6
Success 15/15 14/15
L1/L2/L3 5/5 • 5/5 • 5/5 4/5 • 5/5 • 5/5
Tool calls 133 120
Wall clock 1704 с 231 с
Seconds/success 113,6 16,5
3.8 прошла всё, но оказалась почти в 7 раз медленнее. Единственная ошибка 3.6 была интересной: код уже был правильным, тесты проходили, но модель продолжила искать проблему, внесла ненужное изменение и зациклилась. После этого повторен весь тест с отключённым thinking (reasoning_effort=none):
Метрика 3.8 ON 3.8 OFF 3.6 ON 3.6 OFF
Success 15/15 14/15 14/15 15/15
L1 5/5 5/5 4/5 5/5
L2 5/5 5/5 5/5 5/5
L3 5/5 4/5 5/5 5/5
Tool calls 133 107 120 125
Median calls/task 8 6 7 7
Repeat rate 0,75% 0% 1,67% 0%
Constraint violations 0 0 1 0
Prompt tokens 179 572 117 430 152 275 171 384
Completion tokens 27 741 5 166 17 122 9 112
Wall clock 1704,4 с 349,2 с 231,2 с 141,2 с
Successful tasks/min 0,528 2,406 3,633 6,373
Seconds/success 113,6 24,9 16,5 9,4
здесь результат весьма неожиданный - Qwen3.6 без thinking стала одновременно быстрее и лучше: 15/15, ошибочная задача теперь решалась нормально: проверить код → запустить тест → убедиться, что всё хорошо → закончить. Qwen3.8 без thinking ускорилась почти в 5 раз, но получила одну ошибку. Причём не на самой сложной задаче. Ошибка возникла в простой последовательной арифметике: нужно было применить к значению несколько операций и записать результат 1079.0. Модель записывала неправильное число, хотя в финальном тексте потом сама правильно вычисляла 1079.0.
Затем попробовал короткий reasoning:
Budget Результат Первый write Время
64 3/3 PASS ошибка → исправила 59 с
128 0/3 FAIL ошибка 50 с
256 3/3 PASS сразу правильно 82 с
unlimited PASS сразу правильно 79 с
OFF FAIL ошибка 25 с
256 reasoning tokens уже достаточно для правильного вычисления, но по времени выигрыша нет. Ещё один отдельный результат: MTP у Qwen3.8 оказался полезен — скорость выросла примерно с 10,5 до 15,6–17,2 tok/s
Если есть интерес - подробные описания тестов, исходники и результаты могу куда-нибудь выложить.
Я задам нубский вопрос: но как далеко эта модель от OpenAI GPT-5.5?
Судя по [1], по "уровню интеллекта" наравне с GPT-5.5 (medium), 5.6 Luna (max) и 5.6 Sol (low), в агентной работе выше всех GPT-5.5 и 5.6, кроме 5.6 Sol (xhigh) и 5.6 Sol (max). Но количество требуемых для решения задач токенов больше чем в два раза больше, чем даже для самой прожорливой многословной из GPT-5.5/5.6 (более того, 5.6 Sol (high), который в агентной работе на одном уровне с сабжем, тратит в шесть (!) раз меньше токенов на задачу).
здесь можно оценить по разным параметрам https://artificialanalysis.ai/models
Всем привет! народ, а кому то посчастливилось поработать на этих девайсах?https://tenstorrent.com/hardware/cards
скорости обещают весьма и весьма, да и цены приемлемы, уж не проще купить такой девайс за вменяемые деньги чем видеокарты с не ясными перспективами
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А все-таки Qwen3.8-27B — думает меньше и быстрее чем 3.6