Comments 46
На видеокарте с 24 ГБ памяти, о которой мы говорили выше, модель в кванте Q4_K_M обычно работает в пределах 8–16 тысяч токенов
ну а турбоквант не пробовали использовать?
у меня на rtx 3090 24gb
qwen 3.6 27b на 128к токенов занимает (на вин11) 22-23gb vram и с mtp имеет скорость ~50ток/с
qwen 3.6 35b занимает 24gb vram но скорость +105ток/с на контексте 128к
недавно появился Qwythos-9B-1M там 1млн токенов контекста с моделью занимают 18gb vram
но большие объёмы данных долго обрабатываются, но теперь хотя бы возможность есть такая
так же рекомендую попробовать форки квена и другие, сейчах их стало больше
Qwen3.6-40B-Claude-4.6-Opus-Deckard-Heretic-Uncensored-Thinking-NEO-CODE-Di-IMatrix-MAX-GGUF
Qwopus3.6-27B-Coder-Compat-MTP
Qwopus3.6-35B-A3B-Coder-MTP
p.s. использую форк llama.cpp с тубоквантом но там готовые сборки под вин 11 не последних версий
с такими настройками (пример)
llama-server.exe -c 128000 -m “D:\models\Qwopus3.6-35B-A3B-Coder-MTP\Qwopus3.6-35B-A3B-Coder-MTP-Q4_K_M.gguf” --mmproj “D:\models\Qwopus3.6-35B-A3B-Coder-MTP\mmproj-F32.gguf” --port 8080 --no-context-shift --no-mmap -ctk tbqp3 -ctv tbq3
p.s.s. в gemma 4 не вижу смысла, все последние квены буквально лучше почти во всём (для написания кода)
p.s.s.s. и ещё рекомендую если использовать стоковые квены то использовать к ним и это froggeric/Qwen-Fixed-Chat-Templates
p.s.s. в gemma 4 не вижу смысла, все последние квены буквально лучше почти во всём (для написания кода)
Ну так-то автор явно сказал, что для чата, а не для кода использует. Ну и в целом, мне gemma вполне себе нравится, для кода ее не используют, потому-что по-дефолту она нихрена с тулзами работать не может и постоянно ломается на их вызовах, гугловцы это вылечили месяц назад, сделав пул-реквест: https://huggingface.co/google/gemma-4-31B-it/discussions/118 но настолько ленивые жопы, что так и не замержили. Если его забрать и использовать - кодить будет значительно лучше. Хотя лучше или хуже Квена - не берусь сказать, пока есть подписки от работодателя, пользуюсь ими для кодинга, с локальными только немного попробовал, но на моем ноуте уж безумно долго даже MoE. Но использую в своих проектах для агентов и с новым темплейтом gemma4-26 ни разу на тулзах не упала, хотя раньше всегда ломалась и она и 31b. И даже 31b через OpenRouter - они все ломаются. Чат темплейт по ссылке, кстати, подходит для любых gemma4, включая qat, он у всех у них одинаковый.
я на релизе пробовал кодить через чат на gemma 4 26b/31b и они были близки к qwen 3.5, но вышел квен 3.6, а потом и форки (квопусы и пр.) и все они значительно лучше))
На релизе что у геммы, что у квена было полно косяков и с косячными квантами, и с чат темплейтом, и с поддержкой в llama.cpp/lmstudio/итд. У меня есть несколько тестовых вопросов и на релизе гемма сильно лажала - особенно на одном вопросе, генерировала 10к думающих токенов и всегда отвечала фигню. Сейчас намного лучше, gemma4-26b на этом же вопросе делает 1500-6000 (в среднем 3к) думающих токенов и почти всегда отвечает правильно. При этом qwen3.6-35b в среднем думает 6к токенов и отвечает неправильно намного чаще. Я сейчас на работе, вечером могу вопрос показать. Что гемма, что квен, тестил на 6бит квантах.
Этот вопрос не значит, что гемма лучше квена, просто показывает насколько большая разница в качестве геммы на релизе и сейчас.
Интересно. А какие сборки gemma используете? Я в самом начале после появления в opencode пробовал и очень часто налетал на зацикливание. В итоге пока сижу на qwen3.6
Вообще самую базовую, просто все от задач зависит. В опен коде и подобных агентных средах gemma плохо себя показывает не потому что модель плохая, а потому что цель у нее другая. Она сама по себе не приспособлена к решениям подобного плана, и в базе расчитана на максимально человечный диалог. Квен в этом плане как раз наоборот обучен под использование различных инструментов и выполнение различных действий. Ну и снова же гемма4 выпускалась как модель для дообучения, т.е. в зависимости от ваших хотелок вы можете докрутить ее как вам вздумается
Можете привести 1-2 модели которые "значительно лучше" оригинальных? Я довольно скептически отношусь ко всякого рода попыткам улучшить оригинальные модели, но если у вас есть положительный опыт их использования то с удовольствием протестирую предложенные модели.
как я выше и писал
Qwen3.6-40B-Claude-4.6-Opus-Deckard-Heretic-Uncensored-Thinking-NEO-CODE-Di-IMatrix-MAX-GGUF
Qwopus3.6-27B-Coder-Compat-MTP
Qwopus3.6-35B-A3B-Coder-MTP
Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressiv
один только Uncensored у меня работает лучше (и в бенчмарках), просто не отказываясь от спорных задач, например я делал майнер апи ключей, где надо было регистрировать аккаунты, обходить капчу с помощью распознавания локальной нейронкой изображений и на каждом акк-е делать апи ключи и их сохранять
По поводу “спорных задач” пожалуй соглашусь что некоторые из этих моделей могут с ними справляться лучше, хотя думаю и для базовых моделей существуют обходные пути позволяющие их выполнить. (Так например получить системный промпт у Qwen3.6 не особо сложная задача если проявить чуток фантазии, хотя если спросить напрямую она эту информацию наотрез отказывается выдавать.)
Но могут ли они лучше решать задачи с которыми базовые модели плохо справляются. Например при написании кода для работы с графами или непосредственно при работе с объектами описывающими графы у тойже Qwen3.6 постоянно возникают проблемы. Думаю дообучение на датасетах созданных из ответов более “умных” моделей или “отключение цензуры” значимого эффекта тут не даст.
В любом случае спасибо за подборку, обязательно протестирую на своих задачах в которых у Qwen3.6 возникали серьёзные сложности.
Вам уже перечислили интересные варианты.
Но стоит ещё посмотреть специальные квантования с повышенной точностью. Для qwen3.6-35b это DuoNeural, fraQtl, APEX. Я в основном сейчас пользуюсь fraQtl с mtp.
Насколько понимаю это своего рода “квантование со специализацией” под более узкую область знаний. Да, под конкретные задачи это интересные варианты учитывая сегодняшние цены на железо. У меня с железом ситуация боле менее приемлемая, при необходимости могу запускать Q8, по этому не так актуально.
А вот чего я пока не нашёл и что на мой взгляд былобы очень полезным, так это модели дообученные на коде и документации свежих библиотек/фреймворков. Часто сталкиваюсь с затыками изза того что модель пишет код под старые версии библиотек а потом тратит ещё раза в 2-3 больше токенов на поиск/исправление вызванных этим ошибок. В итоге либо приходится давать примеры работы с новыми версиями либо заменять их на старые.
По субьективным ощущениям Ornith1.0 (35B MoE) показала себя неплохо по сравнению с Qwen3.6 (35B MoE) в задачах анализа и улучшения небольших проектов. Сама она основана на Qwen3.5.
Использовалась на практически чистом Pi, без плагинов. Возможно с более серьезной обвязкой разница в результатах будет менее заметна.
Да, она мне тоже недавно попалась на глаза. На мой взгляд результаты бенчмарков выглядят слишком хорошо чтобы быть правдой. В рабочих задачах ещё тестирую, но пока значимого прогресса относительно Qwen3.6 не вижу, +- похожие ошибки и затыки.
Так например (из простого) на запрос сгенерировать граф типовой зоны для MUD для одной из комнат она сделала два выхода в одном направлении. И в целом граф получился кривоватый, хотя чуть лучше чем у Qwen3.6.
Скрытый текст
{ "from": "foyer", "to": "entrance", "dir": "S" },
{ "from": "foyer", "to": "great_hall", "dir": "N" },
{ "from": "foyer", "to": "kitchen", "dir": "E" },
{ "from": "foyer", "to": "library", "dir": "W" },
{ "from": "foyer", "to": "armory", "dir": "S" },Есть у той же геммы есть неплохой оптимизированный под локальный запуск клон - https://huggingface.co/unsloth/gemma-4-31B-it-qat-GGUF/blob/main/gemma-4-31B-it-qat-UD-Q4\_K\_XL.gguf. Там слои сжаты и она дообучена именно на такое квантование. А так в основоном надо под свои цели дообучать, модель сама по себе достаточно универсальна
А как вообще по производительности и стабильности этот форк?
Я сейчас как основной использую ik_llama.cpp. Он быстрее (сейчас не так значительно, как 1-2 месяца назад, но все равно ощутимо), а самое главное не так расточителен к памяти. Я не знаю, что сейчас намудрили с llama.cpp, но qwen3.6-27b (точно сборку не помню, квант q4_k_m) при включении mtp просто не лезет в память с максимальном контексте квантованном в q8_0, а на ik_llama еще 2 гб остается от 32 гб.
Как qwen 3.6 35b в 24 гиг поместить? И мне казалось, чем больше параметров в модели, тем медленнее работает, как 35b может выдавать в два раза больше токенов чем 27b?
Это MOE-модель, там через черточку указано число активных параметров A3B на каждый токен. А 27B - плотная модель. Для запуска 3.6-35b достаточна карта с 6Gb VRAM и 32Gb ОЗУ, нужные эксперты будут подгружаться в видеопамять в процессе генерации.
и ещё контекст квантуется по алгоритмам турбокванта
примерно с такими результатами
В MoE моделях во время инференса работает только пара "экспертов" (например 7-8 миллиардов параметров из 35), поэтому скорость получается выше, чем у плотной модели на 27B, где вычисляется вся матрица
Спасибо, очень интересно и полезно.
По Qwen3.6/Gemma4/Mistral точно такие же впечатления остались.
Gemma4 (использовал 26B-A4B) - лучшая в работе с языком
Qwen3.6 (35B-A3B) - отличные технические навыки
Mistral (уже и не помню, что именно запускал) - с русским прям беда
В Gemma4 технические аспекты сильно прокачали (относительно Gemma3), она на уровне Qwen3.6 (а то и немного лучше). Ограничение в очень небольшом плавающем окне внимания - всего 1024 токена. В агентских сценариях это сильно ограничивает модель. Но в режиме “запрос -> ответ” незаметно )
Из неожиданностей - Gemma4 26B-A4B памяти на контекст требует в разы больше, чем Qwen3.6 35B-A3B.
По ограничению контекста - да, чем меньше тем лучше. Но постоянно раздувающийся контекст хорошо попадает в кеш запросов ) Хотя и не скажу что в llama.cpp кеш запросов так уж идеально работает.
P.S. использование llama.cpp как прод-решение выглядит несколько странным. У llama.cpp проблемы с параллельным выполнением запросов - приходится ограничиваться последовательной обработкой разных запросов (может уже и работает - но в любом случае там очень ограниченный контекст получается). Наверное оправдано только для небольших развертываний на “домашнем” железе, где у llama.cpp очень хорошая оптимизация.
Извините, но Ваше сообщение говорит о том, что Вам нужно подтянуть матчасть. Почти все категоричные утверждения некорректны.
Конкретнее ) Максимум к чему можно действительно придраться - к критике llama.cpp )
Ну взять например ваше утверждение, что "Gemma4 26B-A4B памяти на контекст требует в разы больше, чем Qwen3.6 35B-A3B". Размер памяти под контекст это математическая величина, которую можно рассчитать по формуле (llama.cpp это делает при старте и заранее выделяет требуемый размер памяти). Контекст у Qwen3.6 действительно занимает меньше места, за счёт своей архитектуры, но эта разница не в разы. За счёт того что сама модель Qwen3.6 на 35 млрд параметров, а Gemma на 26, то она весит больше, то итоговое потребление памяти (модель+контекст) примерно одинаковое
А вы пробовали?
Вот я тоже думал, что “то на то и выйдет”. Добавлю только что активных у Gemma чуть больше, что должно сказаться на размере контекста, но не критично - там не сильно больше выходит, если точные цифры брать, а не просто на A3B и A4B ориентироваться.
Но потом запустил на 262к контекста Qwen3.6 35B-A3B и Gemma4 26B-A4B. Qwen3.6 35B-A3B выел около 32GB, а Gemma4 26B-A4B уже 59GB потребовала при одинаковых настройках (Q8 квантование контекста и Q4_K_M для моделей). И да, именно эти цифры я увидел в логе llama.cpp / ik_llama.cpp.
Так что архитектурные различия зарешали в данном случае.
Mistral создан для программирования и технических вопросов. Он единственный из всех тестируемых мной моделей около 10 разных локальных формализованных кодовых моделей смог справится с решением проблем с возможностью 3 попыток. У него высокая степень встраивания в инфру.
Qwen3.6 27b по всем бенчам обходит gemma 31b, требования к железу аналогичные в целом.
Про ручную сборку промптов не понял, любой движок конвертирует запрос через chat template. Я не прав? Там конечно есть нюансы - разные модели чуть по разному обрабатывают входные роли, но уж токены а-ля <start_of_turn> зачем руками расставлять? И нет никакой проблемы перенести промпт между моделями, если движок конвертирует через корректный chat template.
Про используемые сэмплинг параметры ещё бабка надвое сказала, не такой там большой диапазон рабочих параметров, чтобы ими гибко управлять. На маленькой модели нестандартная температура скорее приведет к более частым протечкам токенов в ответ или циклам.
Отдельно стоит сказать про то, что новые модели это всегда баги движка, особенно если используется mtp, стриминг, тул колинг.
Реальный опыт это:
- обновили vllm, всё сломалось
- поставили корректную версию, гпу недозагружена
- модель 1 раз из 10 выдаёт цикл, 1 раз из 10 неправильно генерирует порядок токенов, движок неправильно парсит, получаете thinking секцию в content или тул колл как сырой json. 1 раз из 10 модель выдает рандомный бред. Количество проблем увеличивается с ростом сложности задачи и входных токенов.
База: сначала мы ставим фреймворк, чтобы он решал все за нас, а потом героически выпиливаем его, потому что он решает все за нас :))
Я с удивлением обнаружил, что режим thinking во большинстве случаев ухудшает качество ответа и на Гемме-3 и на Квине-3.6, естественно, увеличивая ожидание. Неожиданно!
Качество ответа зависит от квантования модели, от квантования кэша, от формулировки задачи (промпта), от прочих настроек, включая температуру. Может быть выбрав правильные настройки вы с удивлением обнаружите, что в большинствое предыдущих случаев вы просто делали это не правильно?
С режимом думалки есть такая ерунда, я сейчас весьма приблизительно опишу (хоть и не совсем это будет верно) : когда оно "думает", все эти размышления это первый вызов модели, затем результаты мышления передаются как часть системного промпта в нее же. И вот тут смотря какая длина контекста выходит всей огромной портянки, если портянка действительно огромна, то модель начинает путаться в этой инфе потому что у нее банально не хватает мозгов обьять это необьятное. Поэтому качество вывода может упасть.
Вы немного отстаете. Вышла уже давно gemma4, и вот она фигачит со скоростью паровоза на любые темы. Это реально крутая и мощная модель, но только для разговоров. Приколы их цензуры до сих пор блокируют ей свободу к нужным весам. В технических задачах может выдавать бредятину как собственно и ее одноклассники, но все же чаще.
Соглашусь с вами, я эксперементирую сейчас с написанием своего агента поверх локальной gemma 4 12b, режим размышления у меня заменяется суммаризацией каждого шага, диалога, и разбиением задачи на подшаги, каждый шаг это отдельное окно без полной истории, равное 8к токинов, + сумированая информация с предыдущего шага, + глобальнвя цель + ещё некоторые ухищрения, определенная в начале диалога, как оказалось в таком режиме модель идеально фокусируется на задаче, вызов инструментов проходит практически без ошибок, + самоконтроль, так же модель явно начала говорить я не знаю, а не галюцинировать и придумывать небылицы, если нет релевантной информации или задача не имеет полных данных для ее решения, потому что нет размытия фокуса мусором из предыдущих шагов, и если, включить режим рассуждения то все ломается так как модель начинает путаться в своих же рассуждениях, и это моделька 12b даже не 21 или тем более 31b
А агент какой? В Pi плагинчик какой-нибудь? Пишите статью! :)
Все стандартно, LM studio с gemma4 12b доступ по api, + мой код на питоне который и реализует функцию агента(можно использовать любую модельку, но лучше всего сейчас работает именно gemma4)
На счёт написания статьи, ещё рано, хочу испытать эту концепцию на разных бенчмарках, проверить реальную итоговую длину возможного непрерывного диалога с моделью, где будут смешанные темы, от написания кода до обычных философских рассуждений, насколько долго модель сможет сохранять фокус, адекватно суммаризировать, что бы не терялась нить смысла и истории общения, накопление опыта и учебы на своих же ошибках в длинных временных промежутках, будет ли прирост "ума" у модели, на сколько хорошо она сможет решать задачи которых не было в ее обучающем датасете, так же надо провести эксперементы с созданием личности, (возможно смена личности в конкретном подшаге на выполняемой задаче, когда модель выбирает вётку программиста, или рассуждений) не просто "ты программист в 100500 поколении". А к примеру как будет вести себя модель если ей сказать что она человек чье сознание было оцифровано из умирающего тела ?)))
Обычно модели при длительном диалоге, с увеличением контекста в окне, начинают игнорировать даже системный промт, а так же подхалимничать, помните знаменитый ответ в длинном диалоге " Ты совершенно прав " )))) даже если пользователь начинает нести охинею, модель вместо того что бы поправить, или не согласиться, поддакивает пользователю, даже если тот решит сброситься с крыши )))
У меня этого нет принципиально, модель не тащит за собой предыдущий контекст где она в сотый раз соглашается с пользователем тем самым модель всегда адекватна как в первый раз.
Текущий минус, это все работает медленнее обычного чата, из за кратно большего числа запросов к модели, чем сложнее задача тем больше шагов должна выполнить модель.
Плюсы, скорость и точность генерации модели практически всегда линейная, за счёт малого фиксированного окна.
Я в своих опытах обнаруживал, что глубокие размышления ухудшают способность модели к вызову правильной цепочки тулов.
Модель начинает сомневаться, передумывать, она уже вроде составила правильный вызов тула но вдруг опять начинает задумываться правильно ли она поняла описание тула. Мечется, соображает, а надо было всего-то одну функцию с двумя параметрами вызвать.
Та же модель с пониженным уровнем размышления с той же задачей вызова тулов справлялась быстрее и лучше.
Пробовал на каких-то небольших моделях уровня 10b-20b параметров.
А как правильно настроить распределение слоев для moe модели? Какая логика?
Статья большая и насыщенная, но в одном пакете слишком много технологий закинуто, голова болит. Я думаю надо писать как надо, не надо говорить нам как не надо, мы сами поймем на своих неизбежных ошибках. Вот кстати про работу с локалками вся база тут выдана, вы молодцы. Но на счет фреймворков не согласен, так как есть графовые фрейморки с грамотной обвязкой. Также согласен, что все вышеперечисленные кандидаты вставляют палки по-своему, и поэтому доверия к ним нету, но также они кушают производительность во время работы. Как я понял они работают чисто на интентах выбора и встроенных инструкциях с механизмами подтверждения. Это бред и тупик по причине тупости нейросети. Поэтому либо пишем самописное решение под задачу, либо думаем какими логическими приколами эту задачу выполнить.
За GBNF спасибо. Пригодится для самодельного агента на llm.
Открытые LLM в продакшене: 8 выводов о llama.cpp, Gemma и Qwen