Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 223
Не нужно для кодирования брать ужатые до Q4, они много теряют, лучше взять поменьше, типа 9B но Q6.
Абсолютно бессмысленное занятие. Потеря от Q4 существенно меньше, нежели от потери 10B+ параметров
Только все 10B+ их не использует, иначе бы mmoe было бы бессмысленно. А рассуждать как вы, лучше на бесплатных облачных писать там хоть 120 B+, только секреты не показывать. Код обычно не секретный, данные чувствительны
Да! Сразу не использует, но как показывает практика МоЕ с 3B активных явно выигрывает у мелких dense моделей с 8-9B. Я рассуждаю так, потому что в последнее время делаю очень много тестов разных моделей.
Так может у вас мелкие старье типа qwen3 coder, или какая-нибудь gemma4 e4b, которая не для кодирования.
Ну какие не старье? llama3.1-8B? Deepseek-R1-8B? Ministral3-8B?
Llama3.1 2024, deepseek r1 январь 2025
И они обе даже близко не стояли с MoE Qwen 3.6. Чтобы не быть голословным - https://benchlm.ai/coding
Я тебе честно скажу, я использую,Gemini 3.1 Pro, потому что бесплатно, а для всякой мелочи и подробных логов qwen3.5-9b-Q8.
Подтверждаю. Плотно тестировал. Практически все что смог скачать с хаггинфейс до 14b. В итоге что-то действительно полезное оказалось только qwen3.6 35b и плотный вариант 27b в экстремальном квантовании. После них разве что на gpt-oss-20b можно смотреть без отвращения
Неверно. Q4 кванты дают деградацию ОЧЕНЬ малую по сравнению с FP16. Для понимания - потеря PPL 0.25 точности, это ужасно мало, в реальной работе незаметно никак.
И еще, чтобы быть правдивым - PPL и NLL показатели по уму надо считать ОТДЕЛЬНО код, простой текст,спец. текст. Часто PPL и NLL меряют на датасете wikitext2, который по своей сути реально текст, и он не гарантирует тоже качество для кода, например.
Я экспериментировал с квантованием, написал свой метод квантования и рантайм, назвал его SVSK - сравнивал с Q4 и на разных моделях.
Мое исследование вот тут: https://github.com/Dookoo2/SVSK
P/S По показателям PPL и NLL мое квантование даже чуть лучше чем QQUF Q4_K_M с imatrix. Пока еще продолжаю работу над проектом.
тут недавно гугл говорил про turboquant, правда там речь шла о хранении kv-cache но что то мне говорит, оно должно универсально подойти и для хранения весов, или может уже есть реализации, вы сравнивали свою с ними?
Нет, KV-cache это не то же самое что сжатие весов модели и оно никаки не подойдет для квантизации.Значения ключей (K) и значений (V) имеют огромный динамический диапазон и генерируется оно динамические, outliers (выбросы значений) огромны и его так просто не сжать. Потому просто квантовать кэш не получится, и это решает turbo-quant. Дает дополнительный compute для рассчета KV, но сильно снижает VRAM требования.
На самом деле это выгодно, чипы GPU сейчас мощные, все нейросети это не compute-bound история, а больше memory-bound, то есть частота памяти и ее емкость роляет сильнее. Так что дополнительный compute не важен, а сокращение memory трафика - то что нужно.
.
А как обстоят дела с KDL? PPL вот вообще не показателен
Не знаю как у вас так получилось, но у меня Qwen 3.6 существенно лучше пишет код нежели Gemma 4. На простейших задачах Gemma 4 у меня показывала настолько плохие результаты, что использовать ее для кодинга просто не имело смысла.
Запускаю вот так:
docker run -d --ulimit memlock=-1:-1 -p 8080:8080 --name qwen3.6-code-turboquant -v ~/models:/models --gpus all local/llama.cpp:full-cuda \
--server --model /models/Qwen3.6-35B-A3B/Qwen3.6-35B-A3B-UD-Q5_K_XL.gguf --alias 'local/Qwen3.6-35B-A3B' --tools all \
--cache-type-k q8_0 --cache-type-v turbo4 --flash-attn on --no-mmap -c 262144 --host 0.0.0.0 --port 8080 \
--reasoning on --api-key sk_no_need_key -t 16 -tb 16 -tbd 16 --mmproj /models/Qwen3.6-35B-A3B/mmproj-BF16.gguf \
--temp 0.6 --top-p 0.95 --top-k 20 --min-p 0 --presence-penalty 0 --repeat-penalty 1.0 --chat-template-kwargs '{"preserve_thinking": true}' \
--image-min-tokens 1024 --no-mmproj-offload -b 4096 -ub 4096 --mlock -ngl 99 --n-cpu-moe 40 --cache-ram 16384тут сборка с турбоквантом для большего количества токенов. Занимает 11Гб видеопамяти и еще 5 остается на KV. С курсором работает прекрасно.
И помимо perplexity(ppl), хорошо бы еще делать тест на KL Divergence.
Если первая метрика показывает как хорошо угадывается следующий токен, то вторая метрика показывает насколько хорошо работает квантизация
Да, я тоже удивился таким результатам. Я уже несколько дней тестирую на кодинге - очень хорошо себя показывает.
Тут надо понимать, что строго говоря, из статьи не следует, что Qwen 3.6 хуже пишет код. Он хуже следует инструкциям. Но если код при этом получается лучше - значит код он пишет лучше. gpt-oss-120b, например, в баш скрипте на 30 строк умудряется пролюбить перенос строки. Зато как следует инструкциям, ух!
Немаловажный вопрос, пишет в чем? Какая IDE или агент? Я все еще в поиске хорошей рабочей связки.
Cursor
Cursor с локальной моделью? Я пытался настроить, но у меня упорно запросы идут в паблик апи вместо заданного урл
Чуть позже напишу статью об этом. У курсора все улетает на их сервера и просто нахрапом это не победить
Укажите токен API и включите переключатель. Как ни странно, если просто указать BaseURL, он его игнорирует. При этом если в LM Studio доступ по токену не включить, а токен непустой - возвращает ошибку (можете отрезать хедер Bearer nginx-ом или caddy). Также у меня курсор не мог достучаться до моего домашнего айпишника (потому что у него сервера на AWS, а вы знаете что у нас происходит с траффиком от AWS), поэтому либо ngrok, либо разверните свой https прокси где-нибудь не здесь.
балуюсь с Kilo Code (в виде плагина для VS Code) и Zed, такая же история, после вашей статьи снова попробовал Gemma - забывает как пользоваться инструментами, постоянно останавливается, приходится подталкивать
Qwen-3.6 - сильно тупее клода, но хоть что-то может родить
практика показывает, что это поведение сжатия и/или сброса/оверфлоу контекста
нет, контекст точно влезает, буквально сразу начинает тупить
Ну спорить не буду. Все зависит от настроек загрузки, построения топологии, создается ли юнифайд KV, какая квантизация этого самого кеша, используется ли офлоад и тд... Может быть "и так и так". В целом, по умолчанию, валится из-за этих двух причин (а если "тупить", то возможно все не влезло в VRAM?)
Если из моделей малышей, конечно, если мы говорим про Qwen3.6, то не удалось получить "лучший результат" на Gemma4 (приблизительно сравнительно по используемым ресурсам). По моему опыту, в целом, Qwen3.6 27b Q4_K_M c флеш-аттеншен и квантизацией KV Q8 - топ. Хотя какой результат считать лучшим? Токены в миллисекунду это не всегда, знаете, лучший результат. Например мне важно качество "лучшего результата".
А может все, что пробовал я - вполне специфические кейсы. Может на диалогах Gemma4 и натрет задник Qwen3.6 :) - Надо послушать что говорят любители Gemma.
Я сейчас для работы агента, использую Hermes для бытовых задач, остановился на Qwen3.6 перепробовав все на свете. И мне прям нравится как она справляется и с агентскими задачками и с собственным системным администрированием. Единственный недостаток, с которым я просто мирюсь, это иногда, на больших контекстах она выдумывает новые похожие на русские слова, путается в склонениях и падежах и чуть чаще выдаёт китайские иероглифы, если это какое-то прям судя по всему сильно базовое для китайского языка слово, очень любит "человек", "хозяин", "дерево". Но, дело делается, поэтому я воспринимаю это просто как веселую фишку. Из последнего цитирую заголовки "ЧТО НАБРАЕТ ОБОРОТЫ", "КРАТКОЕ ОБОЗРЕНИЕ ПО ИСТОЧНИКАМ".
Хотя возможно, я зря её обвиняю, потому что в автороутинге, для легких задач у него стоит в cheap model minimax-m2.7 и скорее всего это от неё артефакты.
Так у меня то же самое, вы же отвечали на мой коммент изначально, Qwen 3.6 гораздо стабильнее геммы. Чаще пользуется инструментами, реже в циклы уходит в размышлениях. План один раз написала лучше клода (он со своим планом три раза обломался на реализации и пришел к тому же решению, что с ходу предлагала Qwen3.6)
Тут важно разделить. В агенте у меня облачная полноразмерная Qwen 3.6, подключенная через openrouter, а не локально запущенный квант. Это прям сильно разные вещи. Держать локальную модельку для агента, который работает в качестве рабочего помощника 24/7 это как-то уж слишком не рационально и не удобно. У него же там задачи по расписанию, модуль памяти, все дела. Проще потратить пару тысяч рублей в месяц на токены по API и на VPS.
Не не не. Стабильность должна быть у обоих. Только потом можно сравнивать качество/скорость. Конечно же, мой коммент, хотя и упоминает качество, говорил про падучесть. Не годится "подпинывать". Оно должно управляться Хостом от начала и до конца.
Так как технологии развиваются со скоростью самолета, естественно, разработчики иногда забывают учесть всю многогранность конфигураций. А могут тупо ошибок наделать.
Так быть не должно. Надо разбираться конкретно в чем там дело. Обе работают - точно совершенно - без всяких пинков
Боюсь, что "разработчики" тут особо не при чем, я полагаю, это неотъемлемое свойство всех этих недетерминированных стохастических технологий. Результат может отличаться от железа на котором запускают, сочетания параметров, запросов, системных промптов, фазы луны - получается шаманство, что при обучении, что при инференсе.
Очень сложно сравнивать поэтому качество у разных моделей. Я не думаю, что в ближайшем будущем будет это решено
а какой смысл выгружать слои в ЦПУ, если она полностью помещается в VRAM ?
условно IQ3_XSS влезает в VRAM. с 65к контекста удобно работать. Меньше контекста - модель даже проект прочитать не может.
Смысл в том чтобы очистить память для контекста, при этом потеряв где-то 1.5 в скорости, при этом получив и память и лучшую квантовку. IQ3_XSS. - это прям нищенская квантовка
я привел пример модели. не суть
разве выгружая слои на цпу вы не теряете в скорости ? при обращении в слой который находится на ЦПУ будет просадка, и это ощутимо, у меня с 50 токенов в таких запросах падает до 20.
Я не вижу разницы на 4070Ti Super и Ryzen 9700X, получается 65 vs 60 TPS, запускаю так: llama-server.exe -m D:\models\Qwen3.6-35B-A3B-UD-Q4_K_XL_nomtp.gguf -c 196608 -np 1 --jinja -fit on
Попробовал вчера собрал llama с поддержкой MTP и франкенштейна Qwen3.6 с нарощенными слоями, как тут люди хвалят, получилось 40 TPU, не знаю, что я делаю не так
Интересно, какие бы модели вы бы выбрали, будь у вас m5max/128gb?
Dense модель Qwen3.6. Пока что она топ среди свободных небольших моделей
Dense модели m5max/128gb как мертвому припарка. 15-20 токенов с секунду
И этого в принципе достаточно. У маков у всех одна проблема - медленная память
Это очень медленно. Невыносимо ждать после флагманских моделей. От 40 уже можно что-то делать, а не ждать 90% времени
Это нормально для чатика, просто пообщаться с моделью. Если задача - напили тесты на этот класс и найди, от чего они валятся, то можно поставить задачу, сходить в магазин, вернуться, оценить прогресс, и перестать баловаться локальными llm.
Да ладно. "Просто неправильно держите". MLX дает больше.
Можно попробовать с MTP speculative decoding, там генерация должна получиться 1.5-2x быстрее.
Для локальной разработки 20 t/s вполне хватает. Ты же код читаешь и вникаешь, а не пытаешься за секунду сгенерить войну и мир
А зачем? За такие деньги уже можно нормальный GPU взять. RTX PRO 5000 или, если надо именно много vram - доску nv-link и четыре V100 32Gb. Это 100% будет быстрее чем мак работать. В маке памяти много, но не настолько она быстрая.
вы стоимость "доску nv-link и четыре V100 32Gb" осознаете?
Что-то не видно таких в продаже
К этому еще надо "обвязку". Mac будет медленнее, но помещаться в сумку, потреблять 6W в простое с включенным экраном :)
Проблема Mac конечно не в скорости памяти, а в том что он не CUDA-не годится (пока) для чего-то по настоящему тяжелого типа видео. Но с другой стороны, прогресс идет.
Когда-то сам смотрел на на доску для двух V100. Но Volta уже legacy, драйвера до 580 и CUDA до 12.х. Сейчас на вторичке начали появлятся A100 32Gb в таком же формате, по характеристикам и сроку поддержки намного привлекательней, но ценник х 3.
если это вопрос не автору, то самые интересные сейчас - qwen 3.6 27b, легенда этой весны. если допилят, то в mtp. Если поместиться, то Qwen 3.5 122B (10B active), особенно когда выйдет обновленная 3.6 версия. Если нет - reap версии, типа Nemotron-3-Super-64B-A12B-Math-REAP или Qwen3.5-REAP-97B-A10B, из вполне может хватить для агентских задач, но кодить с ними может быть опасно, мало ли где произойдет затуп в ответственный момент.
если допилят, то в mtp
Буквально вчера появились ггуфы с мтп головами для квена и геммы, а в ламе близок к мержу пиар по мтп. Собрал, погонял, на 3.6-27B производительность х2 почти. Шикарно.
а можно поподробнее? что собрали? и как настроить?
p.s. нагуглил сам, вроде как должно работать в ik_llama.cpp или собирать самому как описано тут
А что именно тестироваали? Какую модель? Я на прошлой неделе гонял MTP на той же Gemma4 и не получил прироста вообще, грубо говоря на уровне погрешности, разница была 2-4%.
Тоже пробовал MTP https://github.com/ggml-org/llama.cpp/pull/22673 На Qwen3.6-27B-Q4_K генерация токенов возросла с ~27 до ~50. Но не все так хорошо, обработка запроса существенно замедлилась с ~1700 до ~700. GGUF сам собирал используя imatrix от bartowski.
https://mtplx.com/ - 63 t/s пишут.
Контекст сжимается, модель «забывает» что делала
Так может сделать контекст побольше? А то 32К контекст на агентских задачах, это не серьезно.
С полным контекстом на 2080 Ti 22Gb VRAM (65 t/s на пустом контексте):
llama-server.exe -hf unsloth/Qwen3.6-35B-A3B-GGUF:IQ4_NL --host 0.0.0.0 --port 54321 --jinja --parallel 1 --flash-attn on --cache-type-k q8_0 --cache-type-v q8_0 --ubatch-size 256 --batch-size 256 --mmproj-offload --no-mmap --reasoning-budget 8192 --reasoning-budget-message " Thinking token budget is over. Now I must give an answer."С половинным контекстом на 4080 16 VRAM, отключен модуль vision (120 t/s):
llama-server.exe -hf unsloth/Qwen3.6-35B-A3B-GGUF:IQ4_NL --host 0.0.0.0 --port 54321 --jinja --parallel 1 --flash-attn on --cache-type-k q4_0 --cache-type-v q4_0 --ubatch-size 512 --batch-size 512 --mmproj-offload --no-mmap --reasoning-budget 8192 --reasoning-budget-message " Thinking token budget is over. Now I must give an answer."Тут трейдоф - это скорость заполнения - из-за маленького батча она ниже.
зы. Кстати по поводу vision - какой же он днищенский у Gemma и какой божественный у Qwen, тут даже сравнивать нечего.
IQ4_NL далеко не лучшая квантизация, лучше UD-Q4_K_XL. А по поводу мультимодальности, чтобы ее не терять и чтобы она не занимала видеопамять, просто сгружать ее в RAM через --no-mmproj-offload
Вы все правильно написали, в общем случае так и есть, но у меня тут свои причины именно так настроить. Во-первых VRAM не 24Гб а 22. Во вторых мне нужен vision модуль именно в vram потому что при офлоаде он начинает работать на cpu и это очень медленно в моем случае (CPU старый и медленный), а для меня в некоторых задачах нужно чтобы он быстро работал. IQ4_NL выбрал потому что он на 4Гб меньше, чем тот же UD-Q4_K_XL и дает больше места под kv-кэш, так что получается запустить на полном контексте.
у UD слишком сильная деградация и она становится "узколобым".
IQ4_NL не имеет таких проблем.
Кто вам такое сказал? IQ4_NL имеет более агрессивное сжатие, причем сжатие касается именно весов экспертов в MoE. Оно априори не может быть лучше нормальных квантов.
ЗЫ: UD - это общее название методов квантизация от Unsloth
IQ4_NL
Q4_K_M
Про какую деградацию вы там говорите? На тестах IQ кванты показывают себя хуже обычных квантов.
UD может и нормальные для обыденных стандартных популярных распространённых запросах и соответственно тестах.
но если запросы не входят в это(то есть нестандартны) то модели UD глючат жёстко.
а про обычные кванты я не писал.
я про то что IQ4_NL работает стабильней чей UD при непопулярных запросах.
но IQ4_NL менее качественней чем Q4_K_M/
Еще раз! UD - это семейство квантов от Unsloth и никакого отношения ни к Q4_K_M, ни к IQ4_NL не имеют. Есть как UD-Q4_K_M, так и UD-IQ4_NL. И UD-Q4_K_M работает существенно лучше UD-IQ4_NL. О каких глюках вы там говорите я не понимаю. Все прекрасно работает - я не думаю что анализ исходников AOSP16 является "распространенной" задачей для локальных моделей, однако UD-Q4_K_M с ней справился прекрасно
Есть вот такие тесты https://www.reddit.com/r/LocalLLaMA/comments/1rei65v/qwen3535ba3b_quantization_quality_speed/
UD-Q4_K_XL is significantly worse than standard Q4_K_M on this model — both larger file size and nearly 10% higher perplexity. This is consistent with other reports of Unsloth Dynamic quants underperforming on MoE architectures (u/ubergarm's KLD data on Qwen3-30B-A3B showed the same pattern). If you're running Qwen3.5-35B-A3B at Q4, use standard Q4_K_M.
как минимум с этим надо быть осторожным и перепроверить на конкретной задаче и модели, не попадаете ли вы в эту деградацию 10%.
Это старые данные. Модель в таком виде была на HF несколько дней после публикации 3.5. Она действительно была глючной. Потом поправили, и размер её стал на 2Г больше.
Вас не смущает версия Qwen? И PPL малоинформативен в отличии от KDL
Есть вот такие тесты
как минимум с этим надо быть осторожным и перепроверить на конкретной задаче и модели, не попадаете ли вы в эту деградацию 10%.
Перепроверять это правильно, но вы не перепроверили в статье, а используете как пруф цифры, которые уже не актуальны и вводят в заблуждение.
Вы ссылаетесь на старый пост со старыми квантами. Там деградация была, но это была аноримальная деградация из-за использования mxfp4 для ffn-тензоров вместо K-квантов, аномалию почти сразу заметили и исправили. Было проведено большое исследование с квантами, в итоге кванты переделали, способ квантования UD изменили.
График от комментатора выше, где видно преимущество UD квантов Qwen3.6 - это как раз тесты после исправления. По комплексной метрике KLD, которая точнее чем PPL, исправленные UD обходят остальные кванты, включая Bartowski.
https://www.reddit.com/r/LocalLLaMA/comments/1rlkptk/final_qwen35_unsloth_gguf_update/
Проблема новых моделей и квантов в том, что их исправляют несколько раз после выхода, и не стоит использовать посты 3 месячной как источник для статьи, не уточнив были ли исправления. Например, для Gemma4 было 5 исправлений, включая исправления в самой llama.cpp, и каждый раз надо было перекачивать кванты. Вначале Gemma4 была не пригодна во многих задачах, включая вызовы инструментов и агентов, сейчас это всё исправили, но если ссылаться на первые посты про Gemma4, то “выяснится”, что она “не пригодна” полностью.
Дело в том, что это не один день делалось и писалось, а потом еще лежало на модерации. Да, проверять все - это хорошо, но не реально, пока допишешь до конца, можно начинать проверять с начала. Я обязательно посмотрю еще эти кванты, спасибо! Но в последнее время, я что-то прям проникся MXFP4. Unsloth безусловно очень крутые и двигают все вперёд, но как правильно где-то тут заметили, они последнее время очень торопятся и частенько не успевают, выкладывая сырое. Я много раз втыкался, что берешь их квант, их инструкцию буква в букву и оно работает прям плохо. Надо взять за правило ждать хотя бы недели две перед тем как тестировать, а не набрасываться на выходе.
Почему отключаете mmap? --no-mmap, эта фича непревзойденная, модель не загружается в память процесса, ее держит в кеше ОС, в результате все работает быстро и при следующем запуске не тратится в принципе время на загрузку. Без mmap веса модели буквально должны удерживаться в оперативной памяти дважды, в кеше файловой системы и в памяти процесса пока модель работает.
Он ее не держит в кэше, он ее отображает на адресное пространство и первый токен медленный, т.к. mmap вернее ядро делает ленивую загрузку. Мало того, у меня модель постоянно загружена, мне не нужно ее останавливать.
Без mmap веса модели буквально должны удерживаться в оперативной памяти дважды, в кеше файловой системы и в памяти процесса пока модель работает.
С каких это пор кэш ФС у нас обязан удерживаться после загрузки данных в оперативную память?
я имею в виду что бы получить такой же повторный быстрый запуск.
еще момент, при использовании mmap, так как бОльшая часть модели или вся, загружается в GPU vram, хранить в ram эти части уже не требуется, и вылезает второй бонус mmap, частичное хранение весов ram, память становится доступна для других задач, например я в lmstudio выгружал основную модель в vram а второстепенные маленькие в ram (бенчмарки не проводил), работает,.. т.е. это значимая экономия не дешевой памяти.
p.s. кеш ОС не всегда правильно убирает данные из кеша, по уму должна использоваться статистика т.е. что чаще используется то в памяти останется, но на практике там кажется удаляется то что первое в память попало... т.е. может так получиться что в выше описанном случае основная модель начнет повторно подгружать нужные участки с диска, потому что при загрузке дополнительных моделей, из памяти удалились первые попавшиеся куски... но после повторной загрузки все выравнивается и работает.
С ключом --no-mmap процесс памяти занимает меньше ОЗУ. В в производительности разницы не заметил. Как я понял llama-cpp пишет модель в vram, если она полностью вмещается, то отображать файл на память уже не надо. По поводу скорости загрузки - это только на этапе экспериментов важно, кроме того - llama-cpp по скорости загрузки несравнимо быстрее той же vLLM, если диск быстрый - никаких проблем.
Спасибо за статью. С недавних пор решил отказаться от LM Studio в пользу llama.cpp, но я запускаю просто с --fit on, а тут прям такой разбор всех этих флагов, очень познавательно, сам бы ни за что не стал разбираться.
Удивительные результаты у вас получились, мне Gemma4 вообще никак не зашла в плане кодинг ассистента, возможно потому что я тестил на стороне Backend и там Gemma не так сильна. Вероятно ваши результаты как-то зависят от mxfp4 и дополнительных урезаний Qwen, чтобы поместиться в VRAM. У меня macbook и всё нативно с запасом влезает в Unified memory.
P.S. Пробовал работать с Qwen3.6 27B, результаты не то чтобы сильно превосходящие MoE модели, но разница ощущается, а вот скорость просто заставляет плакать, 16-20 tok/sec
--fit on по-умолчанию включен. Так что можете и его убрать ))
Qwen не стала хуже, она не урезана, хотя и выбрана более мелкая по размеру, просто загружена хитрым образом. Я скорее склоняюсь к тому, на сколько просто удачной в пользу той или иной модели оказалась тестовая задача. Надо брать обе и гонять на своих боевых примерах использования. Очень много зависит от того, где модель запущена, в какой оболочке, какая задача, какой систем промпт, как вызываются тулы, тот же скилл суперпауэрс, может творить чудеса, а может выжирать контекст. Вообще самая большая боль на локалках это именно размер контекста который они могут удерживать. Общее правило, что для больших платных моделей, что для локалок, если вы вывалились за 50%, начинаются проблемы, не надо ждать автокомпакции, это работает плохо. И если на условном миллионе 50% это много, то на локалке 50% от заявленного, это прям мало.
у меня на Macbook обратные результаты с инфраструктурными задачами - Gemma4 справилась гораздо лучше.
у gemma4 проблема с окном внимания - оно совсем небольшое (Sliding Window 1024 tokens). Модель быстро “забывает” историю диалога (и это подтверждается тестами). Поэтому для агентских задач плохо подходит - только если контекста надо совсем немного для выполнения задачи.
Но сама модель очень и очень хороша - спору нет.
Самый интересный результат тестирования: Thinking-режим во всех моделях показал худшее следование правилам, чем Fast.
Вероятное объяснение: когда модель «думает», она оценивает полученные инструкции и принимает решение, что нестандартные правила вроде искусственного префикса избыточны. Fast-режим следует буквально, без рефлексии. Для практического использования это важно: если нужно точное следование правилам стиля - Fast-режим надёжнее.
я работаю в Cursor. В последних его версиях 90% моделей thinking. Вы хотите заявить, что они глупее fast? Да и какой тогда смысл в thinking, если он тратит больше токенов и работает хуже?
Предположу, что причина в том, что у вас тесты слишком синтетические, проблемы с квантованием или настройкой моделей и т.п. Т.е. недостоверные результаты тестирования
Очень просто. Есть дурная на мой взгляд и неэффективная привычка, брать самую жирную модель, выкручивать ей хай эффорт и типа хуже не будет. Будет. Она начинает жрать токены, делать оверинжениринг и тому подобные вещи.
Не зря же моделью по умолчанию в том же клоде стоит сонет.
Общее правило, моё, не навязываю. Для исследования, планирования и проектирования, включаем жирную модель с режимом размышления. Её же можем использовать для контроля и рефакторинга, а для тупого выплёвывыания строчек кода по этому плану, подключаем что-то простое и поменьше думающее. У неё задача писать код, а не фантазировать, чисто механическая.
Так быстрее и эффективнее. не зря сейчас набирает популярность подключать дешевый deepseek, для написания кода. В пару к дорогим моделям.
Вот к примеру что сами антропики советуют https://platform.claude.com/docs/en/about-claude/models/choosing-a-model
Вопрос от чайника: можно ли использовать и дискретную, и встроенную видеопамять?
Можно, но не нужно потому что встройка берет из озу. Скорость падает из-за перегонов
Если модель немного не влазит в VRAM, то использование unified memory (GGML_CUDA_ENABLE_UNIFIED_MEMORY=1) быстрее обычного offload (у меня так получалось) + защита от OOM.
Это если обе под ИИ задействовать, то действительно смысла наверное нет.
А если дискретку чисто под ИИ подключить, а встройку к монитору, то должно быть немного эффективней, так как работа с видео-выводом на экран не будет отъедать часть ресурсов видеокарты.
обязательно нужен флаг
--jinja- без него модель просто не увидит инструменты
Он не нужен! jinja включена по-умолчанию. Читайте документацию.
Да тут что автор нагородил в параметрах, почти всё по дефолту включено. По сути, я уже второй месяц юзаю llama.cpp без параметров "тонкой настройки". Порог вхождения в llama.cpp уже давно гораздо проще чем в Ollama. В параметрах запуска достаточно указать хост, порт, папку с моделями - Всё! llama.cpp сам мгновенно подберёт оптимальные параметры для модели и выжмет из вашего железа все соки для достижения максимальной скорости генерации.
Qwen_Qwen3.6-35B-A3B-Q4_K_M.gguf
Q4_K_M - проверенная классика
Формат от автора bartowski, на которого я рекомендую обратить внимание.
Q4_K_M отклоняется от эталона на 2,1%. UD-Q4_K_XL - на 9,7%
Q4_K_M - это не формат от Bartowski, у него не классические статические Q4_K_M кванты, хоть он и называет их так.
Bartowski для всех своих квантов применяет кастомные динамические рецепты, например, ffn он квантует как Q3, хотя должен как Q4, и для всех статических квантов, кроме Q8_0, он применяет свой imatrix, который не должен применяться для классического Q4_K_M.
Другая проблема в том, что в imatrix Bartowski нет или мало русского языка в датасете, и она включает в себя wiki text, поэтому показатели PPL завышены, но на практике квант оказывается сломан и не работает как надо, что трудно понять.
Новее ≠ лучше: перплексия не врет
Но метрики перплексии (PPL) на WikiText-2 рисуют другую картину:
Итог простой: не гонитесь за «новым» и «продвинутым» форматом. Проверяйте метрики конкретно под свою модель. Иногда старое доброе работает лучше.
Перплексия постоянно врёт. К PPL нужно относиться с осторожностью, её не стоит сравнивать в лоб, это не мера качества модели, это первичная оценка деградации квантов в рамках одного создающего, чтобы заметить аномальное отклонение. Для оценки качества кванта вместо PPL используют KLD, эта метрика показывает более объективную деградацию кванта.
Недавно показывал как делается KLD замер, и в качестве сравнения как раз брал классику Q4_K_M, которая выступила на уровне UD-Q3_K_XL.
Unsloth-кванты исторически проседают именно на MoE-архитектурах со сложной маршрутизацией экспертов
Спорное утверждение. В недавней статье я показывал на что способен квант Qwen3.6-35B-A3B UD-Q2_K_XL, этот квант хуже чем UD-Q4_K_XL, но даже в таком низком значении он не сломан и выполняет работу.
UD-Q2_K_XL сделала реплику Win11 с рабочими окнами, пуском и анимациями:
И в агентном режиме создала проект “Minecraft в браузере”, включая правки через Vision:
Gemma4 только в размере Dense 31B смогла что-то подобное повторить, MoE 26B-A4B не справилась и в программировании она сильно хуже себя показывала.
каким агентом вы правки через vision делали? или скил описали?
Это просто скриншоты агенту, в qwen code в новых версиях можно копи-пастить изображения, либо обычным @bug7.png добавлять в диалог.
Кстати, по поводу качества. Пока видел мало обсуждений свежего Qwopus, это Qwen3.5 и 3.6 дообученные на выдаче больших моделей. Есть в разных размерах, включая Qwopus3.5-4B. Сейчас пробую Qwopus3.6-27B-v1-preview, в целом впечатления положительные, как будто бы лучше чем простой Qwen3.6 27B, но нужно больше экспериментов.
Ну да, тема ультраагрессивных квантов не раскрыта, плюсую. gemma-4-26B-A4B-it-UD-Q2_K_XL за несколько запросов в опенкод написало: 1. Клон марио 2. Клон вин 11
Скрытый текст
Примитивно, НО, я тут не парился с системными промптами и вообще впервые увидел опенкод 30 минут назад, плюс используюя турбоквант (AmesianX) модель целиком с контекстом 64к влезает в 15 гигов врамы на 5070ti (1 уходит на 4к монитор). Qwen3.6-35B-A3B-UD-Q2_K_XL.gguf - 128к. У обоих примерно одинаковая картина 90-100 т/с с пустым контекстом 40-60 т/с с заполнением наполовину. Есть проблемы с зацикливанием, но в общем с тулзами могут делать вещи.
Я бы протестировал на чем-то менее шаблонном. Это буквально как попросить модель для генерации изображений воспроизвести Мону Лизу или Квадрат Малевича. Змейку еще можно попробовать попросить написать или Тетрис. Я к тому, что под эти задачи есть 100% максимальное покрытие в данных на которых модель обучена, ей надо быть ну очень тупой и кривой, чтобы на этом облажаться. Просто ради интереса, попробуйте аналогично попросить её написать что-то типа копии игры Kid Kool для NES, будет интереснее.
>например, ffn он квантует как Q3, хотя должен как Q4
Это не так, ffn он квантует >= того, что указано в имени модели.
Вот например значения для Qwen_Qwen3.6-27B-Q4_K_L.gguf:
7: 89128960 | 17408, 5120, 1, 1 | Q6_K | blk.0.ffn_down.weight
8: 89128960 | 5120, 17408, 1, 1 | Q4_K | blk.0.ffn_gate.weight
9: 89128960 | 5120, 17408, 1, 1 | Q4_K | blk.0.ffn_up.weight
Это системная проблема, не связанная с режимом thinking. Qwen-модели текущих версий плохо справляются с длинными агентскими сессиями в OpenCode при работе с большими файлами.
Сильное утверждение, но проверять мы это конечно не будем. MoE Qwen 3.6 вместе с Cursor прекрасно справилась с полными исходниками AOSP16 и позволили разобраться во флоу работы Zygote
я ковыряю qwen и opencode последние две недели, решаю разные задачи, недостатки слабых моделей видны почти сразу, и проблема контекстного окна вылезает прямо видно, чаще всего вылезает в виде циклических повторений блоков последних сообщений.
то что иногда это работает полностью автономно, это просто шикарно, сам в шоке от того как модели читают код и отвечают на вопросы по нему... и не важно что они могут что то опустить, теперь у меня есть буквально возможность, загрузить случайный огромный репозитарий проекта и спросить, а как в такой то хитрой ситуации поведет код, и получить ответ через несколько минут.
У меня максимально возможное количество токенов для модели(если не использовать YaRN) и курсор прекрасно следит за контекстным окном. OpenCode меня выбесил тем, что у него тул коллинг какой-то странный и далеко не всегда работает как надо
Qwen 3.6 из коробки имеет контекст ± как Sonnet, 200к токенов. Если вам память позволяет, конечно.
Встретил упоминание про проблемы с инстументами в OpenCode при использовании локальных моделей. А как с этим бороться? А то спустя несколько вопросов, начинает тупить с записью файлов на диск. Пишет что записал и переубедить не получается
Хорошая статья. Люблю практические. Запускаю на ртх 3070 8 гб - выдают по 27т/с не уверен что смогу выжать больше, но попробую ваши лайфхаки
Вот вы писали про эти 2 параметра, а в недавней статье говорили что их можно на -cmoe поменять. Это так?
Было бы классно гемма4 с ассистентом потести, но жаль что unsloth не спешит выпустить кванты свои для него. Видимо связано с тем что в llamacpp официально еще не завезли mtp
можно да, надо тестировать, это же не сложно. в форках llama уже завезли MTP, но он не даёт прироста в Gemma, во всяком случае у меня не получилось. Вот можно потестировать, придётся правда собрать форк и у него чуть другие ключи запуска чем у оригинала, но все работает. https://huggingface.co/AtomicChat/gemma-4-26B-A4B-it-assistant-GGUF
Возьмите от других assistant-модель - работать будет не хуже.
P.S. я бы рекомендовал уходить от unsloth - они тюнингуют модели под бенчмарки, модели тупеют в других задачах. В частности с русским у них становится заметно хуже. Или без мышления модель начинает откровенно тупить.
Прекрасно работает с русским и отупения не заметил))) У вас там случаем не Cuda 13 стоит?)
Нет, у меня “честный” инференс на CPU )
С русским отупление более заметно на UD-Q2_K_XL. Но UD-Q4_K_XL тоже подвержен, пускай и гораздо менее заметно.
Что более заметно - при отключении мышления Qwen3.6-35B-A3B-UD-Q4_K_XL не сумел написать достаточно простой алгоритм. Прием с этой же задачей “древний” Qwen3-Coder справился с 1й попытки вообще без нареканий.
К слову, Qwen3-Coder тоже UD-Q4_K_XL, что говорит о том, что раньше менее агрессивно квантовали )
Ну а я вместо unsloth теперь качаю кванты от bartowski - и с “проблемным” алгоритмом он прекрасно справился с 1й попытки и без размышлений.
P.S. пробовал вместо unsloth использовать AesSedai, что по бенчмаркам на уровне unsloth. Но он точно также затупил. Так что я теперь на модели “по бенчмаркам” не смотрю совсем. Это даже анти-рекомендация. Высокий балл в бенчмарке достигается за счет заточки под бенчмарк. А все остальное проседает.
P.P.S. “тупление” более заметно в том, что ответы становятся многословнее. Qwen3 мне нравился именно своей немногословностью. Что в думающем режиме, что в не-думающем. А тут у gemma4 ответы были заметно короче, чем у Qwen3.6 (местами в 2 раза короче). На моделях от bartowski же ответы Qwen3.6 немного короче ответов gemma4.
Я могу объяснить такое поведение. У Unsloth упор идет как раз на thinking у него эти слои практически не сжимаются, у bartowski упор на основу. Вот и вся разница. Но unsloth c preserve_thinking выдает прекрасные результаты
preserve_thinking - это немного про другое все-таки. И тем более это не заслуга unsloth. У bartowski он тоже работает - это свойство самой модели (Qwen3.6).
А вот длина ответа - очень интересный показатель ) Жаль, что очень недооцененный при сравнении квантов.
P.S. там нет thinking-слоев. Unsloth стал все слои квантовать динамически, замеряя метрики. Q4_K_X обычно именно слоям внимания выделялось больше места. А в Unsloth Dynamic 2.0 стали подбирать размер под каждый слой, ориентируясь на метрики. И ключевое - у разных экспертов в МоЕ разное квантование идет, что как раз и портит квантование для “неважных” экспертов. А “неважность” определяется по их собственным тестовым данным.
А я и не писал preserve_thinking это заслуга unsloth. У них он просто работает нормально за счет оптимизированного чат темплейта
ОК, они оптимизировали чат-темплейт (хотя еще смотреть надо, в чем именно их заслуга и есть ли отличия от bartowski). Но Unsloth все равно портит модели своим UD. В бенчмарках они хороши, но в реальной работе отстают. И я лично ловил кривые ответы неоднократно.
Даже в Thinking-режиме это видно по многословности ответов относительно bartowski. Да, я не ловил явно кривых ответов в Thinking-режиме от Unsloth (потому как обычно в не-думающем режиме гоняю). Но повышенная длина ответов явно говорит о плохой работе (и разница в разы).
P.S. в чат-темплейте от Unsloth нет никаких отличий касательно preserve_thinking от темплейта bartowski.
Чтобы модель меньше трепалась и больше делала, очень рулит Caveman он к стати и качество работы улучшает благодаря этой немногословности https://github.com/JuliusBrussee/caveman/blob/main/README.md
Хотелось бы видеть в подборке моделей еще gpt-oss-20b. Эта со свистом влезает в 16гб врам вместе с контекстом.
Ну и как уже отметили, для тестов стоило поставить контекст больше, возможно результаты были бы другими
Ну не прям со свистом. Но влезает. Если вам будет полезно субъективное мнение и опыт, то: относительно qwen3.6-35b с включенным cpu-moe по производительности на практике несколько, но не кардинально быстрее, но по качеству работы с кодом очееь заметно хуже. Железо 5060ti 16 gb + xeon e5 2690v4.
У меня также 5060ti 16гб, gpt влезает целиком со всем контекстом и занимает 15.3гб. На пустом контексте 120т/с, на 80к+ 75т/с.
Но с qwen3.6-35b выше 15 т/с я не могу получить (проц Ryzen 7 5700X), что весьма мало
Проверил на одной RTX5060Ti 16GB, получается 45-50 т/с tg и ~200 т/с pp.
llama-server запускал с такими аргументами:
-–mlock --no-mmap --flash-attn on --jinja -ctk bf16 -ctv bf16 -dev CUDA1 -c 131072 -fitc 131072 -fit on -fitt 384 -m /models/bartowski/Qwen3.6-35B-A3B-GGUF/Qwen_Qwen3.6-35B-A3B-Q4_K_L.gguf -mm /models/bartowski/Qwen3.6-35B-A3B-GGUF/mmproj-Qwen_Qwen3.6-35B-A3B-bf16.gguf --reasoning off --temp 0.7 --top-p 0.8 --top-k 20 --min-p 0.0 --presence-penalty 1.5 --repeat-penalty 1.0
тут люди запускают dense qwen 3.6 27b на 16 гб vram с контекстом в 100к юзая турбоквант. Было бы интересно прогнать ее на ваших тестах https://www.reddit.com/r/LocalLLaMA/comments/1svnmgo/quant_qwen3627b_on_16gb_vram_with_100k_context/
Она хорошая, но медленная потому что dense.
В 4-бит квантах она не влазит в 16Гб, а когда она не влазит количество токенов в секунду резко падает
запустил модель Qwen3.6-27B.i1-IQ4_XS-attn_qkv-IQ4_XS.gguf:llama-server.exe -m Qwen3.6-27B.i1-IQ4_XS-attn_qkv-IQ4_XS.gguf -ngl 999 -dev CUDA0 -c 110000 -fa on -ctk turbo4 -ctv turbo4 -fit off --no-mmap -b 4096 -ub 256 --temp 0.6 --top-k 20 --top-p 0.9
потребляет 15.2 гб vram. Скорость не замерял, но работает довольно шустро
tq4 + mtp = 40t/s на qwen27b.
попробовал штук 20 моделей с той же картой+Ubuntu+llama.cpp+cuda13. Все 14b не понравились, понравилась упомянутая Gemma 4 26B-A4B-it 80т/с стабильно, хорошо рассуждает, для кодинга у google ai попросил написать 7 задач на go с усложнением уровня и туда же кидал ответы, Qwen3.6-35B-A3B-UD-Q5 завалилась на 3,с тестами справилась только одна модель cerebras_Qwen3-Coder-REAP-25B-A3B-IQ4_NL.gguf, скорость 40 - 12 т/с, комментарии только на английском и китайском. Возможно еще стоит потеститьopenai_gpt-oss-20b-MXFP4.gguf. Для себя сделал вывод что 16Gb мало, минималка 32Gb. Практическое применение пока придумал только одно - аналитика по эксель файлам с персональными данными, в программировании codex лучше локальных моделей на две головы. Параметры запуска:
./llama-server -m models/bartowski/cerebras_Qwen3-Coder-REAP-25B-A3B-GGUF/cerebras_Qwen3-Coder-REAP-25B-A3B-IQ4_NL.gguf \
-t 7 \
--alias "cerebras_Qwen3-Coder-REAP-25B-A3B-IQ4_NL" \
--ctx-size 32000 \
--cache-type-k iq4_nl \
--cache-type-v iq4_nl \
--flash-attn on \
--parallel 1 \
--temp 0.4 \
--top-k 20 \
--top-p 0.9 \
--min-p 0.1 \
--batch-size 512
--repeat-penalty 1.1 \
--host 0.0.0.0 \
--port 8080
Для себя сделал вывод что 16Gb мало, минималка 32Gb
24 удовлетворительно, Q4 лезет с квантованием контекста до Q8, около 80-90к токенов истории - как рядовой вызов субагента в Claude Code, там примерно такой же бюджет выходит.
Полностью согласен. 16г прям мало, современные открытые модели едва помещаются без танцев с бубном. Надо 24, а лучше 32. Это как с 3D принтерами, можно мучать один, пытаясь выжать из него чуть больше скорости, теряя качество, а можно просто купить второй и сразу ускориться в двое, при условии серийной печати конечно.
Если бы вы почитали бы документацию Unsloth, то поняли бы где вы сделали ошибку. Уберите 13-ую Cuda и замените на последнюю 12-ую. cerebras_Qwen3-Coder-REAP-25B-A3B-IQ4_NL.gguf - не советую использовать этого Франкенштейна на каких-нибудь +- нормальных задачах - мало того что порезаны слои, так еще и кванты ужаты через IQ
Вообще у gemma4 обрезанное swa-окно до 1500 токенов, для кодинга лучше запускать с swa-full
Мышление, что у gemma4, что у qwen3.6 прекрасно выключается через --chat-template-kwargs '{"enable_thinking": false}' (можно и в запросе передавать - переопределяет значение из аргументов).
Для Qwen3-Coder выключать мышление не нужно - это не “думающая” модель. Если результаты в “думающем” режиме другие - значит от прогона зависит.
И gemma4 лучше не использовать с длинным контекстом - у нее окно внимания в 1к токенов (Sliding Window 1024 tokens), на длинных контекстах она просто забывает что было много токенов назад. И с вызовом инструментов у нее не очень - много жалоб на это встречал.
P.S. для gemma4 вышли assistant-модели (--model-draft для основной), ускорение в 1.5 раза - очень неплохо )
По поводу MTP выше несколько раз упоминали. Я делал небольшой быстрый тест, но до конца не разобрался пока и чудо обещанное не получил.
Что делал
Стандартный llama.cpp не поддерживает MTP — потребовался кастомный форк atomic-llama-cpp-turboquant. Собрал его рядом со старой сборкой, не трогая рабочую конфигурацию.
Модели:
Основная:
gemma-4-26B-A4B-it-MXFP4_MOE.gguf(16.6 ГБ) — та же, что в статьеDraft:
gemma-4-26B-A4B-it-assistant.Q4_K_M.gguf(311 МБ) — новая, специально обученная голова для предсказания токенов
Ключевые параметры запуска:
--spec-type mtp
--mtp-head gemma-4-26B-A4B-it-assistant.Q4_K_M.gguf
--draft-block-size 3
--draft-max 8Всё остальное оставил как в рабочих конфигах: --n-cpu-moe 8, --ctx-size 32768, --cache-type-k q8_0 и т.д.
Результат
MTP технически отработал корректно — 73% acceptance rate (47 из 64 задрафтованных токенов были приняты основной моделью).
Но прироста скорости нет:
Старый llama.cpp (baseline) 61,9 t/s Новый форк + MTP ~61–67 t/s
Я так думаю, что это не сработало потому что брал MXFP4 которая и так лезет в память целиком, надо подождать пока такие вспомогательные модельки появятся для чего-то еще и оно будет большего размера, брать кванты выше для Gemma я смысла не вижу, они не влезут в мои 16 гигов и будет шило на мыло.
--draft-max 3 - рекомендуют от 1 до 4, на 3 оптимум (судя по тестам). И попробуйте на ik_llama.cpp, у меня параметры --spec-type mtp --draft-max 3 --draft-p-min 0.0.
У меня draft acceptance rate = 0.54307 ( 290 accepted / 534 generated), на --draft-max 4 немного падает, ускорения меньше (но тут тестовый запрос влияет, тестирую на простом “Что ты умеешь?”). Но судя по всему, atomic-llama-cpp-turboquant нужен хотя бы ради turboquant - чтобы и контекст влезал в VRAM.
А с чего прирост то должен быть - если у вас модель без mtp, надо модель с поддержкой MTP скачивать
Хороший разбор параметров запуска, мало кто вообще лезет дальше дефолтных настроек, только для реального рефакторинга крупных проектов все эти локалки пока годятся максимум как продвинутый автокомплит
Я упёрся в оболочку. Запустить модель не особо сложно, но потом хотелось терминальное приложение типа gemini или copilot, и это как бы тоже можно, ollama позволяет запустить копилот со своей моделью, но потом начинают обламываться вызовы потому что не поддерживает reasoning. И вот что там менять дальше я не разобрался (ну и рогом упираться не стал, честно говоря, бюджет времени на исследование как оно работате был уже потрачене :-) )
Товарищи, а кто-нибудь пробовал Intel Arc Pro B70 для целей локального запуска?
https://serverflow.ru/blog/novosti/intel-predstavila-arc-pro-b70-i-b65-peredovye-ii-uskoriteli-s-32-gb-gddr6-na-arkhitekture-big-battle/
псп чуть выше 5060ti, сомнительная штука
У меня Intel A770 16 Gb.
llama.cpp в Vulkan показывает BF16 - нет, тензорных блоков - нет
Хотя по обещаниям Intel все должно быть. В интернет уверяют, что для B-серии драйвера допилили, а про A-серию "когда нибудь". Intel на мейнстрим в виде llama.cpp и прочего пофиг, на нормальные драйвера пофиг, она черти чем занимается.
у меня простой мак, 8 Гб. LLM Studio установил. Даже закачался дистиллированный DeepSeek. Работать невозможно(
Автор, в целом все грамотно настроил, но у тебя reasoning не работал на Квене нормально потому что:
Qwen3-Coder 30B-A3B coder не поддерживает режима Thinking/Reasoning, но у нее огромный контекст (256К-1М) поправь для неё ещё:
--mmap
--n-gpu-layers 48
Qwen 3.5/3.6 35B-A3B qwen использует chatML для jinja, нужно добавить параметр в llama
--cml
UPD: или просто скачай фикс, вышел недавно:
https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates
--jinja --chat-template-file qwen3.6/chat_template.jinja
Попробуй еще вот эту модельку:
https://huggingface.co/froggeric/Qwen3.6-27B-MTP-GGUF потом расскажешь, как она.
Я пришёл к выводу, что для всех этих локальных инференсов всё же нужно юзать универсальный инструмент VS Code + Continue. Все остальные одеяло на себя тащат со всеми этими спецификациями и ограничениями тупыми ради долларов.
Что самое интересное исправленный чат темплейт, который решает все указанные проблемы, у unsloth появился еще с самого первого выкладывания их тюненной модели))
Continue это что ? для меня самый удобный qwen cli
Continue это oss плагин в VS code, в виде чат-интерфейса как и встроенный copilot, но без привязок и лимитов как copilot, а работающий как отдельный агент (инстанс). Ты сам выбираешь, какой llm/cli/backend использовать. Единственное, нужно немножко попариться, чтобы четко настроить backend (mcp/tools/docs/rag и т.д)
в continue можно много инстансов поднять на разных агентах, то есть это полноценный agentic-workflow инструмент, хотя изначально он создавался как авто-комплитер.
Вывод про следование инструкциям, это же вроде температурой регулируется. Не пробовали прям посильней занижать?? до 0, 0.1, 0.2? У меня часто 0.2, если я уверен в промпте и не требуется вот этого галлюциногенного творчества от модели.
Инструкции из системного промпта берутся, которые всегда сидят в кеше и работают только в stateless (без сохранения состояния модели/без сохранения истории предыдущих запросов). Вы говорите про attention. Снижение температуры как раз на attention влияет, но на моей практике температуру лучше не трогать, а грамотно и кратко составить инструкцию, подбирая каждое слово так, чтобы их векторные представления были далеко друг от друга.
Лучше киньте боевой пример, я наглядно вам покажу
Интересно было почитать. Про свой опыт локальных моделей с слабым и помощнее Mac железом написал здесь:
https://habr.com/ru/articles/1033614/
Посмотрите на квантование APEX . там еще одна "революция" https://github.com/mudler/apex-quant
А локальные модели ищут ответы в интернете?
Да
Ищут не модели в интернете, а обвязка к ней. И если клиент умеет - то и модель может использовать интернет (делается или через MCP, или через обогащение запроса результатами поиска по нему).
Теоретически можно настроить tools (MCP) будут искать. Но tools для поиска или платный, или на забугорных сайтах которые запрещает РосЗапрет.
Или использовать IDE где поиск есть по-умолчанию. Или использовать MCP от Brave и пользоваться бесплатным кредитом, только нужна зарубежная карта
Бесплатно, без СМС и не заблокирован: https://github.com/nickclyde/duckduckgo-mcp-server
Я для поиска в интернете использую MCP https://github.com/pwilkin/mcp-searxng-public и self hosted searxng.
У MCP есть плохая черта, это тяжелая штука, он сидит в контексте и памяти постоянно внутри сессии. Имеет смысл держать поиск в виде MCP, только если это основная функция рабочего процесса. То есть то, что делает агент конкретный воркфлоу, непосредственно и постоянно его использует.
Использовать MCP для поиска в формате иногда если вдруг понадобится, очень не рациональное занятие. Проще сваять скилл и в скилл положить мелкий заранее написанный скрипт, который будет дёргаться в тот момент, когда он нужен и агент будет делать запрос, получать и отдавать ответ и больше не тратить на него ресурсы.
в основном поиск выглядит как - сделать запрос в гугл и получить странички по ссылкам.
полноценно шариться по сайтам, читать форумы и т.п. это кажется нет, или есть но в зачаточном состоянии, и мне кажется причина в том что это опасно, инструкции модель может просто прочитать на сайте, и выполнить их.
p.s. особенно это грустно если вы автономному агенту разрешили скрипты писать и запускать, а вы скорее всего разрешили, даже если в виртуалке.
ну как в зачаточном... что если я покажу вам...
это https://github.com/CloakHQ/CloakBrowser
это https://github.com/bytedance/UI-TARS-desktop
или хотя бы вот это https://www.browseract.com/skill
Все это позволяет полноценно шариться по сайтам, читать форумы, заполнять заявки, делать заказы в интернет магазинах и тому подобное, не привлекая внимание санитаров.
35b вышла неудачная, как и прошлая
27b модель плотная, даже в Q2 будет в разы лучше чем 35b moe даже в q8
Она просто сама по себе в разы лучше, а скорость упадёт процентов на 15
Что по сравнению с арендой облачного сервиса с GPU, насколько это будет дороже токенов по самой модели. Иными словами за сколько часов аренды сервиса он выест стоимость всей видеокарты при заданной конфигурации, вот это было бы интересно
Проще и дешевле взять подписку на облачные модели, на пример https://opencode.ai/ru/zen за эти 20$ рука отсохнет лимиты выжигать. Локалка имеет смысл когда нет интернета или нельзя в интернет. Аренда сервера, возня с ним для запуска с настройками, по моему лишняя трата времени, но точно не экономия денег.
Интересная статья, многое надо проверить. Только хочется заметить, что для реальных задач 32к контекста - это ни о чем. Даже чтоб проект небольшой прочитать этого может не хватить.
Огромное спасибо за статью! Отдельный лайк комментариям! Сам планирую поэкспериментировать на связке x2 RTX 5060 Ti 16GB. Статья как раз вовремя буду настраивать, тестить.
Спасибо за результаты, пойдёт как ориентир. Однако Вы сами не нейросеть? :)
1) у Вас "Gemma 4 - 15,5 ГБ" а в другом абзаце "помещается в VRAM". И потом приводите порог в 15.3.. Если сама сеть 15ГБ+, то в 16ГБ она никак не лезет, Ваши же пороги это подверждают.
Хотя ладно:
2) Не могли бы сказать, кто сжимает Гемму MXFP4 в 15.5 ? Я вижу только 16+ варианты
3) Так понимаю, что llama.cpp ещё не поддерживает NVFP4? Иначе можно было бы взять квант напрямую от Nvidia.
4) И по моим наблюдениям, часто QWEN3.6 –reasoning off работает лучше, чем с размышлениями. Однако уже не раз натыкался, что для qwen надо именно что НЕ ограничивать бюджет на размышления, типа это у них в архитектуре заложено. Однако на железках уровня 5060/5070 выглядит малореально..
Лезет, но прям на тоненького, не под виндой так точно... Моя весит 15,5, а вот где взял не помню, скорее всего тут, хоть тут она и больше
https://huggingface.co/unsloth/gemma-4-26B-A4B-it-GGUF/tree/main
Для написания кода размышлять не нужно, лишняя трата времени, ресурсов и контекста. Размышлять нужно на этапе планирования. Грубо говоря врубаем super-powers, пишем план полностью, потом переключаемся на режим без думания и пишем быстро быстро код. Потом тесты, дебаг и все такое.
качал вчера такую же. После 2-3 запросов модель крашилась. Еще из коробки она не принимала запросы и нужно было template подставлять корректный. Вообщем гемма мне не понравилась, но по бенчу вроде как она лучше умеет кодить, но ей нужны с ходу жесткие инструкции и уточнения каждого чиха.
Может быть эта?
https://huggingface.co/noctrex/gemma-4-26B-A4B-it-MXFP4_MOE-GGUF/tree/main
kv_count у неё меньше чем у версии Unsloth. На что это влияет?
Или обновили, или ещё что.. Сегодня скачал - как написано 16.5, так и на диске занимает 16.5
Впрочем не важно, 15.5 слишком много для реальной работы на GPU, необходимо выносить часть слоёв. Плохо!
Делали бы они все модели 20B, как OpenAI - вот это комфортный размер для 16ГБ. А тут прям как насмешка..
А про паплайн.. спасибо за совет! Я лишь имел в виду, что если уж включать "думание", то его не следует ограничивать, иначе ерунда получается.
llama.cpp с недавнего времени уже поддеживает NVFP4, но аппаратное ускорение все еще полноценно не реализовано. Я пробовал около месяца назад, когда увидел, что добавили поддержку и скорость оказалась даже хуже чем с Q4_K_M. Модель прямо с hf/nvidia использовать не получится, т.к. они не выпускают NVFP4 GGUF.
Вопрос знатокам, а ведь можно же расширить model context (который 32k) до условных 128k, задействуя не VRAM видеокарты, а RAM/Nvme?
GPU Direct Storage/HiFC - это тут применимо вообще? Скорость t/s вообще не важна, главное чтобы слабое железо тянуло сложные задачи. Или все-таки порекомендуете лучше думать в сторону выбора другой модели и квантизации? Ну просто 32к это совсем ниочем, функцию написать и задебаждить максимум…
Можно! --no-kv-offload вам в помощь, но скорости инференса не ждите - сразу раза в 3 ниже
Хотите реально сэкономить на KV, тогда вам путь к сборке кастомного Llama.cpp с turboquant
8Gb VRAM
16Gb RAM
250Gb Nvme
Реально вообще qwen3.6 MoE запустить в llama.cpp?)
Ща буду пробовать сперва эти модельки, потом уже turboquant и танцы с бубном подключать.
Qwen3.6-35B-A3B-UD-IQ4_NL
Qwen3.6-35B-A3B-UD-IQ4_XS
Qwen3.6-35B-A3B-UD-IQ3_S
Qwen3.6-35B-A3B-UD-IQ3_XXS
Спасибо за наводку.
Стоит попробовать эту модельку
Qwen3.6-35B-A3B-Claude-4.7-Opus-Reasoning-Distilled-APEX-I-Mini.gguf
Веса Опуса и технология его мышления закрыты, в утечках антропика их не было. Название этой модели намеренно вводит в заблуждение потенциального пользователя. Это взяли обычный Qwen и дофайнтюнили его на ответах большой коммерческой модели. Что ни разу не одно и тоже за заявленным "Opus-Reasoning" Как это делалось, на каком объёме и каких данных, большой вопрос. Проще говоря, это не модель, это Васянский мод, не стоит с таким связываться. Хотя чисто по приколу и можно пощупать.
Если такое реально нужно, надо делать самому, чтобы знать что ты делаешь, для чего и чем жертвуешь.
Тут суть в APEX-I-Mini. Если не нравится обучение на ответах опуса, можно использовать Qwen3.6-35B-A3B-APEX-I-Mini.gguf
Имею 20т\с на похожей системе
В APEX-I разные эксперты по разному квантуются, в зависимости от “важности”. И “важность” эксперта определяется не вами. А значит на ваших задачах может сильно просесть качество.
Это хороший компромисс, когда ты ограничен 8гб vram и 16гб озу.
Согласен, если вариантов нет - то компромисс. Еще можно какие-нибудь Q2_K_L от bartowski попробовать - с гарантированно равномерным квантованием экспертов.
Потому как в APEX (и в UD от unsloth) отдельные эксперты квантуются выше, а другие - ниже для сохранения размера. Но “важность” экспертов они заведомо не на ваших задачах определяют - хотя бы потому, что основной язык не русский у них.
Еще можно какие-нибудь Q2_K_L от bartowski попробовать - с гарантированно равномерным квантованием экспертов.
Это хороший аргумент, но есть несколько нюансов:
bartowski статические кванты квантует с использованием imatrix, поэтому равномерного квантования там не может быть, неравномерность задается на уровне суперблоков через imatrix.
У него калибровачный датасет 400к токенов, из них только 4к на русском, 1%. И этот 1% не отборных текстов, а каких-то разорванных кусков.
calibration_datav5.txt от Bartowski, отсортирован только русский текст bartowski тоже не квантует равномерно, часть слоев выше, часть ниже.
Bartowski, qwen3.6-35B-A3B, Q4_K_M и Q2_K_L
Поэтому его кванты не чистые статические классические Q4_K_M, а являются динамическими. Хотя тут, смотря что вы имели ввиду под "гарантированно равномерным".
Вообще, мне нравятся кванты от ubergarm, они весят меньше, что важно когда мало VRAM, используют новые алгоритмы квантования, которые сохраняют больше точности, квантование тоже равномерное, без сильных экспериментов, imatrix содержит уже 2% русского текста.
Но кванты ubergarm сложно рекомендовать, так как требуют понимая ik_llama.cpp, которая не имеет автонастроек fit, не дружит с AMD и тому подобное.
Ещё из интересного для квантов, недавно завезли NVFP4 GGUF в llama.cpp. NVFP4 имеет в 2 раза меньший размер микроблоков, что повышает точность суперблоков, и имеет более детальный scale factor чем у MXFP4, когда внутри в рецептах начнут использовать nvfp4 вместо Q4_K, то это, возможно, не плохо повысит качество.
Чистые NVFP4 тоже работают не плохо, уже в GGUF виде можно запускать.
Вот жеж, а я надеялся, что там нет дополнительного тюнинга экспертов… И куда, спрашивается, теперь смотреть? Самому квантовать?
P.S. в любом случае, bartowski менее агрессивно “тюнингует” экспертов - пока явных деградаций не встречал.
В сообществе есть мнение, что датасет для вычисления imatrix должен состоять из полуслучайных данных. Но как я понял к единому мнению так и не пришли. Вот несколько обсуждений которые нашел, когда пытался понять как это работает: https://huggingface.co/mradermacher/model_requests/discussions/1470 https://github.com/ggml-org/llama.cpp/discussions/5006 https://github.com/ggml-org/llama.cpp/discussions/5263
каждый день появляется что то новое, сначала turboquant, mtp, nvfp4... еще пару месяцев и 16гб модели будут выдавать 100тпс )
Я немного слежу за трендами, одно всплывает и закрепляется, другое так и не взлетает.
Сейчас разговоры идут о такой штуке, как узкоспециализированные модели. Берутся данные и эксперты в формат МоЕ, под строго какое-то направление и модель получается маленькая, но дико хорошая в своей узкой области. Думаю в этом есть смысл, под кодинг одну модельку, под медицину другую и так далее.
Отельный разговор форматы под Хуавеевское железо, которое активно набирает обороты из-за высоких цен, пошлин и санкций на Nvidia, W4A16, W8A8 специфично под их архитектуру Ascend.
Если эту тему изучить, есть вариант стать очень востребованным специалистом на изолированных рынках вроде нашего. Но вход там не простой https://support.huaweicloud.com/intl/en-us/bestpractice-modelarts/modelarts_llm_infer_5906001.html
DeepSeek R1 на пример работает на Ascend 910B/C и там стоимость у них 1 юань на миллион токенов.
И у нас уже можно вполне себе купить эти железки
на вашем пк не стоит даже пробовать запускать модели больше 6,5 Гб, места под контекст совсем не будет.
Пробуйте edge модели гугла для слабого железа, типа E2B и E4B
За счет MoE иногда получается удачно запустить модель, не влезающую в RAM. “Нужные” эксперты кешируются, остальное скидывается на диск. Но проблема в том, что надо буквально всю машину под запуск LLM отдавать и результаты очень плавают.
Т.е. ничего кроме LLM не запустить, применимо только если “очень-очень надо”.
В теории, возможно, но скорость будет упираться в SSD. Скорее всего, 2-5 ток/с. Смотрите флаги -cmoe и --mmap.
Вопрос знатокам, а ведь можно же расширить model context (который 32k) до условных 128k, задействуя не VRAM видеокарты, а RAM/Nvme?
Да, только в обратную сторону - модель в RAM, контекст в VRAM. Ну и работает нормально это только на MoE - они под это рассчитаны.
NVME никак не поможет, текстовые сетки упираются всегда в скорость памяти - можете просто сравнить скорость VRAM/RAM/NVME и разница в скорости в разах будет ± соответствовать производительности.
GPU Direct Storage/HiFC - это тут применимо вообще?
Нет, это про чтение моделек с диска.
Попробуй turboquant4. Или связку mtp + turboquant4.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Локальные LLM в реальной работе: Gemma 4, Qwen 3.6 и Qwen Coder