Тут как-то до сих пор нет консенсуса. Если это Dense - то однозначно работает, если MoE за счет дополнительных GPU целиком влезает, то работает, но ncmoe компенсирует разницу.
А вот если MoE не влезает целиком, то добавление второй GPU пока не ясно - дает эффект или нет. Зависит от разных факторов. В моем случае результат усредняется. И нужно учитывать, что 2 GPU это не VRAM1 + VRAM2, общий расход памяти на контекст будет выше, чем на одной карте.
В последнее время не было больших Dense, поэтому старая Llama-3.3-70B-Instruct-UD-Q3_K_XL 34.9 Гб, просто из расчёта чтобы влезло на 2 GPU:
5090 -ngl 81: 10 t/s
4060 -ngl 32: 2.4 t/s
5090 + 4060 auto: 17 t/s
5090 + 4060 -ts 5,1: 23 t/s
Qwen3.5-122B-A10B-UD-Q4_K_XL 74 Гб:
5090: 23 t/s
4060: 12 t/s
5090 + 4060: 18 t/s
Qwen3.5-122B-A10B-UD-IQ2_XXS 35 Гб:
5090: 67 t/s
4060: 19 t/s
5090 + 4060 auto: 64 t/s.
5090 + 4060 -ts 5,1: 79 t/s
Везде 4k контекст и Win10. У меня 4060 подключена через pcie x1, через nvtop можно посмотреть интенсивность обмена, она довольно низкая для MoE:
ncmoe
Для Dense еще менее интенсивна:
dense
Вообще, ширина канала нужна для Tensor Parallelism, который дает ~2х ускорение на двух GPU, где происходит интенсивный обмен тензорами. В llama.cpp используется Pipeline Parallelism - сначала работает первая GPU, потом вторая GPU, между ними обмен только конечных слоев, которые на конкретной GPU, что не особо интенсивно, но и ускорение только за счет дополнительной быстрой памяти, а не одновременной работы двух GPU.
Хорошая поддержка TP в vllm и sglang. В ik_llama есть режим -sm graph, который делает почти тоже что TP. В llama.cpp есть -sm tensor, но он работает пока не очень, хуже чем sm graph.
Кстати, кто-нибудь пользовался deepseek coder? Какие впечатления?
Сильно устарел. Сейчас для кода нужна поддержка агентного режима и вызова инструментов - то есть нужно что-то, что выходило в последние пол года, или даже пару месяцев.
2 недели назад вышла Gemma4, в размере 31B годная, в размере 26B-A4B слабая, но знает много анекдотов. Но модель 31B что это Dense модель, то есть должна целиком влезать в VRAM для нормальной скорости, в то время как MoE модель можно распределить между VRAM и RAM в cmoe режиме (не обычная выгрузка слоев ngl, cmoe работает по другому) и получить хорошую скоростью, этот режим по умолчанию включен в llama.cpp, но его нет в ollama.
Вчера вышла Qwen3.6-35B-A3B, и это хороший уровень для такого размера. Даже квантованная Qwen3.6-35B-A3B-UD-Q2_K_XL работая с opencode или qwen code не теряет контекст на 128к, но лучше, конечно, UD-Q4_K_XL.
Для пример попросил UD-Q2_K_XL сделать реплику Win11, 1 запрос, результат 40к токенов. На 4060 16гб скорость 60 t/s. Всё двигается, шевелится, плавное, анимированное:
DeepSeek-R1-Distill-Qwen-32B - это был экспериментальный файнтюн Qwen2.5-32B, с плохим качеством. Если нужно отключить мышление, то проще взять именно Qwen2.5-32B, где и качество выше и размышление нормально отключается. Но вообще, с тех пор уже вышло 4 поколения новых Qwen моделей, которые и лучше и легче. И удобнее перейти на gguf, там есть и квантование, и размышление отключается 1 строчкой --reasoning off (и ещё несколькими способами).
Если сравнивать именно с Distill-Qwen-32B, то можно посмотреть даже на мелкие Gemma4 E4B или Qwen3.5 4B, которые очень хороши для своего размера.
Вчера вышла качественная Qwen3.6-35B-A3B сделанная на MoE архитектуре, активных параметров всего 3B, модель очень быстрая, а для запуска хватит 4Гб VRAM. Или свежие MoE Gemma4-26B-A4B и Dense Gemma4 31B, которые вышли 2 недели назад.
В актуальных версиях llama.cpp, по умолчанию включен режим fit, чего нет в ollama и lm studio, fit сам определяет оптимальные параметры загрузки модели, и для MoE он включает режим ncmoe, чтобы максимально использовать GPU для ускорения, остальное крутится в RAM. В статье про это тоже есть.
Модель 31B Q8 тоже не очень - посмотрите ее объяснение своего правильного ответа
У вас не оригинальная Gemma4 31B, а Gemma-4-31B-it-uncensored-heretic над которой провели лоботомию с непредсказуемой деградацией качества. Зануление весов может работать в каких-то сценариях, но общее качество всё равно просядет, особенно на не английском языке. Компенсировать это через высокий Q8 квант не получится, это просто надо учитывать.
Но помимо этого, в llama.cpp на старте было не правильно реализовано внимание у Gemma4, несколько дней назад это исправили, плюс Google выложил правильный шаблон чата который вшит в gguf.
Надо перекачать gguf и скачать свежую llama.cpp. Увеличилось и качество ответов, и модель начала нормально работать в агентах, и теперь расход памяти под контекст не такой огромный, как было вначале.
Без размышления правильно начинает отвечать с UD-Q3_K_XL:
Gemma4 31B UD-Q3_K_XL
UD квантование - это динамическое квантование, в котором тензоры внимания квантуются выше, за счет этого, например, UD-Q3_K_XL становится примерно равен по качеству с привычным Q4_K_M, но весит меньше на несколько Гб, а сравнимый по весу UD-Q4_K_XL будет лучше обычного Q4_K_M.
Свежие Qwen3.5-4B и Gemma-4-E4B. Помимо текста, у этих моделей есть Vision модуль, можно распознавать, переводить, создавать макеты на основе изображений.
Отличная работа. На сколько сложно будет добавить поддержку этой модели в Unsloth?
Они недавно выпустили Unsloth Studio, в которой удобный интерфейс для обучения, легче работать с датасетами, благодаря чему в разы проще обучать различные современные модели (Fine-tune, LoRA, QLoRA 4-bit).
Проще и быстрее поставить qwen code, в котором есть Qwen3.6-Plus с большими бесплатными лимитами, там 1m контекста, качество в разы лучше и быстрая скорость, а для кого-то всё что хуже Opus 4.6 пустая трата времени.
Для переводить, распознавать картинки, вести диалог и тому подобному очень много контекста не нужно, точнее его нужно сбрасывать, а не накапливать. С помощью cmoe можно высвободить много видеопамяти для других параллельных задач, при этом получить скорость большую, чем выдают LM Studio или ollama. Для агентного использования можно прибегать к субагентам, чтобы не накапливать контекст.
Но вообще, на большом контексте важна скорость PP, чтобы её увеличить, нужно увеличить размер пакетов -ub 3072 -b 3072, или больше. Опционально можно квантовать KV-кэш -ctk q8_0 -ctv q8_0, чтобы снизить расход памяти на контекст в 2 раза. Сейчас тестируют TurboQuant от Google Research, которые заявляют, что можно квантовать контекст до 3.5 бит без заметных потерь, что снизить расход памяти в ~4 раза.
90k контекст, pp 579 t/s, tg 17.4 t/s
90к контекст, подготовка промпта заняла 2.5 минуты, что для агентного программирования хороший результат. Просадка tg не только за счёт контекста, но и ncmoe увеличено с 13 до 22, чтобы вместить столько контекста.
Gemma-4-26B-A4B-it-Q4_K_M, запуск с -ncmoe 13, генерация 33 t/s:
Qwen3.5-35B-A3B-UD-Q4_K_XL, запуск с -ncmoe 22, генерация 32 t/s:
Подбор оптимального параметра, -ncmoe 18,20,22
Модели не влезают в 12гб VRAM, но если использовать перераспределение MoE тензоров и запускать напрямую llama.cpp, в которой по умолчанию включен параметр -fit, который автоматически подберет оптимальные параметры запуска, или настраивать -ncmoe вручную, то можно получить ощутимую прибавку к скорости по сравнению со стандартным способом ngl, который по умолчанию используется в Ollama и LM Studio.
Тут, конечно, это уже надо на нормальном датасете обучать, чтобы заметить разницу. Но архитектура старая, поддержки triton нет, обучение будет в разы дольше, чем дообучить даже, например, Qwen3.5 4B.
Но в целом можно попробовать и так. Сходу при запуске инференса со Sparse Attn ошибка:
Так как Sparse Attn тут настроен на 128 токенов, то если запрос меньше, то Sparse должна быть равна Dense и фактически не работать:
Запрос длиннее 128, тут Sparse успешно отсекает и с виду нормально работает:
Попробовал обучить LoRA на первом попавшемся датасете диалогов Den4ikAI/russian_dialogues, датасет на 2.5 млн строк или 40m токенов. Обучил только на первых 10000 за 5-10 минут.
Обучилась успешно, и приобрела особый стиль общения, который присутствовал в датасете:
Датасет, наверное, не очень удачный, но это хороший пример, что если есть base, то из базы можно выровнять (alignment) модель до различных состояний.
Вы пытаетесь работать с base моделью как с instruct моделью.
Base (или pretrain) - это 1 шаг обучения LLM из 3. Смысл pretrain в том, чтобы модель умела составлять буквы в слова, слова в предложения, предложения были орфографически верные, логически правильные, набирала базу знаний и так далее. Такая нейросеть умеет продолжать текст, вы пишите ей “cat = кошка, dog = собака, duck =” и она продолжает “утка”.
Но если вы пытаетесь с ней общаться в чате, то ей будет послан шаблон чата, который может выглядеть очень не типично, например, вот так:
Поэтому базовая модель в таком сценарии начинает генерировать хаотичные ответы. Чтобы base научилась нормально вести диалог, нужно обучить её шаблону.
Для примера, обучим эту ruGPT3 XL base до уровня instruct (до очень примитивного, так как датасет должен быть куда разнообразнее). Генерируем 100 пар вопрос-ответ такого вида:
Теперь из этих пар нужно создать датасет согласно шаблону-чата модели, в данном случае это:
Вопрос: ...
Ответ: ...
Обучаем нейросеть как finetune целиком или как LoRA адаптер. Для примера хватит 3 эпох на 100 примерах:
Через пару минут “ruGPT3XL-instruct” готова. Теперь можно задать какой-нибудь вопрос, которого не было в дополнительном датасете:
Кто такой Шекспир?
Ты знаешь что-то про Fallout?
Мы не учили модель отвечать, кто такой Шекспир, и не учили её ничему про Fallout, это уже было в модели. Мы только научили её обрабатывать шаблон чата, и, побочно, структуре ответа как из энциклопедии. Аналогично её можно научить агентным задачам и так далее.
Только просто выделения контекста недостаточно, нужно его еще заполнить на 100%
Да нет, память целиком выделяет в момент загрузки. Заполненность влияет только на скорость генерации.
GPT-OSS-20B для контекста использует SWA, механизм который в разы снижает потребление VRAM, чтобы его активировать, нужно включить Flash Attention. Полные 128к требуют +6гб VRAM, если включить квантование KV-кэша Q8_0, то будет +3Гб.
В llama.cpp по умолчанию работает новый режим --fit, который автоматически подбирает оптимальные параметры для эффективного использования GPU минус 1гб VRAM (параметр настраивается) и включает flash attention, поэтому такое отличие от LM Studio.
Под эффективным имеется ввиду другое распределение тензоров, те, которые используются всегда, пойдут на GPU, остальные, которые используются периодически, на CPU, и если осталась VRAM, то будет заполнена разреженными слоями с экспертами. Почему это так работает, выше я уже кидал ссылку на статью Вам нужна RAM, а не VRAM, где это объясняется.
В LM Studio можно включить "половину" от этого режима галочкой Force Model Expert Weights onto CPU (во время выбора модели зажать Alt для расширенных настроек), и перепроверить, что включен Flash Attention, чтобы оптимизировать расход памяти под контекст.
Модель для сложных задач и длинных ответов: mlx-community/Qwen2.5-72B-Instruct-4bit (~12 токен/с).
Qwen2.5 устарела на ~1.5 года, даже Qwen3 уже не особо актуальна. Переходите на новые более качественные модели, ваша машина легко потянет современные хорошие MoE-модели, которые в разы быстрее чем Qwen2.5-72B и, что важнее, намного качественнее.
Из современных моделей к 128Гб подойдут: OpenAI GPT-OSS-120B, GLM-4.5-Air 110B, Minimax M2.1 229B (в динамическом квантовании UD gguf, mlx не влезет в 128гб). Малые версии тоже есть, например, Qwen3-30B-A3B-2507 и остальные из современного списка, при этом с того момента успели выйти хорошие новинки.
Динамическое квантование от Unsloth позволяет опустится ниже 4-бит квантования, при этом сохраняя достаточно хорошее качество, так что можно запустить и Qwen3-235B-A22B, и свежий Minimax M2.1 229B.
UD-Q3_K_XL почти не отличается от оригинала, UD-Q2_K_XL хуже на 13%, UD-Q1_K_XL хуже на 30%
Ноутбук у меня вполне бодрый (i9, 64 GB RAM, RTX 4070) Идея была простая: докупить eGPU (а лучше - несколько) и получить относительно мощный сетап без покупки отдельной рабочей станции
Вообще, этот ноутбук позволяет запускать на хорошей скорости GPT-OSS-120B или GLM-4.5-Air и без eGPU, 64Гб RAM хватит, а через 4070 будет приличное ускорение для MoE.
Cerebras осенью представили метод REAP для вырезания "лишних" экспертов из MoE уменьшая размер модели до 50%, по их словам почти без потерь в области программирования и tool-calling: https://arxiv.org/abs/2510.13999
В целом это работает, но вопрос качества остаётся открытым, например, из того, что сразу бросается в глаза, у модели пропадает умение отвечать на русском языке.
Попробовал, ситуация интересная. Мне перевод показался плохим - в каких-то местах выдуманные куски, модель путает "вы-ты", странные конструкции. Но при этом формальная оценка - 91,33, выше, чем у любой другой модели. Добавил результаты в гугл-таблицу, ссылка на которую приведена в статье.
Перечисленные не очень свежие, Mistral-7B и вовсе 2023 года, одна из самых-самых первых, давно вышли более качественнее модели, если брать в том же размере, то это Ministral-3-8B-Instruct-2512, у Phi вышла Phi-4, Gemma выпустила Gemma3, а вместо Llama3 - Qwen3.
Модели, которые можно запустить на GTX 3060 (12 ГБ)
Если стандартные 16Гб RAM, то можно запускать Qwen3-30B-A3B (включая Vision), Granite-4.0-H-Small 32B, GPT-OSS-20B. Если есть 64Гб, то можно запускать, например, GPT-OSS-120B или GLM-4.5-Air, на 96Гб можно запускать новую MiniMax-M2.1 230B, а на 192Гб DDR5 уже можно запустить DeepSeek R1 671B и V3.1.
Вот, например, на медленной AMD RX 6600 (скорость памяти 224 ГБ/с, а у 3060 скорость 360 ГБ/с, скорость LLM напрямую зависит от скорости памяти), модель GPT-OSS-120B выдает 13 t/s:
а по скорости все равно выигрывают nvidia видеокарты, причем даже не самые свежие. новейший ryzen ai max используется в gpd win 5. Вы на полном серьезе считаете, что в карманной приставке будет какая-то мощь, способная потянуть ИИ? Ну загрузите вы какую-нибудь большую модель в 128гб, а дальше что? Отдача 1-2 токена в секунду?
Размер устройства не имеет значения, имеет значение количество каналов памяти и тип памяти.
Скорость генерации LLM линейно зависит от скорости памяти, в GPU используют быструю GDDR6X и DDR7 и широкую шину памяти, получая скорость 1 Тб/c на 4090. В Ryzen AI Max+ 365, как и в NVIDIA DGX Spark, используется DDR5 и всего 4 канала памяти, скорость памяти 256 Гб/с. Для сравнения у 4060ti всего 288 Гб/с, что немногим больше.
Смотря на какой архитектуре модель: Dense или MoE. Новый Devstral 2 123B сделан как Dense, там будет 3 t/s, но многие переходят на MoE, поэтому там будет скорость намного выше.
Ryzen AI Max+ выдает 50 t/s на GPT-OSS-120B, это очень комфортная скорость для работы, и на 128Гб можно запустить более качественные модели, вроде GLM-4.5-Air или MiniMax-M2.1 230B, скорость будет в районе 25-30 t/s.
Тут как-то до сих пор нет консенсуса. Если это Dense - то однозначно работает, если MoE за счет дополнительных GPU целиком влезает, то работает, но ncmoe компенсирует разницу.
А вот если MoE не влезает целиком, то добавление второй GPU пока не ясно - дает эффект или нет. Зависит от разных факторов. В моем случае результат усредняется. И нужно учитывать, что 2 GPU это не VRAM1 + VRAM2, общий расход памяти на контекст будет выше, чем на одной карте.
В последнее время не было больших Dense, поэтому старая Llama-3.3-70B-Instruct-UD-Q3_K_XL 34.9 Гб, просто из расчёта чтобы влезло на 2 GPU:
5090 -ngl 81: 10 t/s
4060 -ngl 32: 2.4 t/s
5090 + 4060 auto: 17 t/s
5090 + 4060 -ts 5,1: 23 t/s
Qwen3.5-122B-A10B-UD-Q4_K_XL 74 Гб:
5090: 23 t/s
4060: 12 t/s
5090 + 4060: 18 t/s
Qwen3.5-122B-A10B-UD-IQ2_XXS 35 Гб:
5090: 67 t/s
4060: 19 t/s
5090 + 4060 auto: 64 t/s.
5090 + 4060 -ts 5,1: 79 t/s
Везде 4k контекст и Win10. У меня 4060 подключена через pcie x1, через nvtop можно посмотреть интенсивность обмена, она довольно низкая для MoE:
Для Dense еще менее интенсивна:
Вообще, ширина канала нужна для Tensor Parallelism, который дает ~2х ускорение на двух GPU, где происходит интенсивный обмен тензорами. В llama.cpp используется Pipeline Parallelism - сначала работает первая GPU, потом вторая GPU, между ними обмен только конечных слоев, которые на конкретной GPU, что не особо интенсивно, но и ускорение только за счет дополнительной быстрой памяти, а не одновременной работы двух GPU.
Хорошая поддержка TP в vllm и sglang. В ik_llama есть режим -sm graph, который делает почти тоже что TP. В llama.cpp есть -sm tensor, но он работает пока не очень, хуже чем sm graph.
Выжать больше из локальных LLM. Ollama медленнее llama.cpp в 3 раза. UD_Q4_K_XL лучше чем Q4_K_M, а вес тот же и т.д
Сильно устарел. Сейчас для кода нужна поддержка агентного режима и вызова инструментов - то есть нужно что-то, что выходило в последние пол года, или даже пару месяцев.
2 недели назад вышла Gemma4, в размере 31B годная, в размере 26B-A4B слабая, но знает много анекдотов. Но модель 31B что это Dense модель, то есть должна целиком влезать в VRAM для нормальной скорости, в то время как MoE модель можно распределить между VRAM и RAM в cmoe режиме (не обычная выгрузка слоев ngl, cmoe работает по другому) и получить хорошую скоростью, этот режим по умолчанию включен в llama.cpp, но его нет в ollama.
Вчера вышла Qwen3.6-35B-A3B, и это хороший уровень для такого размера. Даже квантованная Qwen3.6-35B-A3B-UD-Q2_K_XL работая с opencode или qwen code не теряет контекст на 128к, но лучше, конечно, UD-Q4_K_XL.
Для пример попросил UD-Q2_K_XL сделать реплику Win11, 1 запрос, результат 40к токенов. На 4060 16гб скорость 60 t/s. Всё двигается, шевелится, плавное, анимированное:
DeepSeek-R1-Distill-Qwen-32B - это был экспериментальный файнтюн Qwen2.5-32B, с плохим качеством. Если нужно отключить мышление, то проще взять именно Qwen2.5-32B, где и качество выше и размышление нормально отключается. Но вообще, с тех пор уже вышло 4 поколения новых Qwen моделей, которые и лучше и легче. И удобнее перейти на gguf, там есть и квантование, и размышление отключается 1 строчкой
--reasoning off(и ещё несколькими способами).Если сравнивать именно с Distill-Qwen-32B, то можно посмотреть даже на мелкие Gemma4 E4B или Qwen3.5 4B, которые очень хороши для своего размера.
Вчера вышла качественная Qwen3.6-35B-A3B сделанная на MoE архитектуре, активных параметров всего 3B, модель очень быстрая, а для запуска хватит 4Гб VRAM. Или свежие MoE Gemma4-26B-A4B и Dense Gemma4 31B, которые вышли 2 недели назад.
Подробнее: Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Нужен режим работы cmoe (не просто выгрузка слоев ngl). Вот тут подробнее: Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
В актуальных версиях llama.cpp, по умолчанию включен режим fit, чего нет в ollama и lm studio, fit сам определяет оптимальные параметры загрузки модели, и для MoE он включает режим ncmoe, чтобы максимально использовать GPU для ускорения, остальное крутится в RAM. В статье про это тоже есть.
У вас не оригинальная Gemma4 31B, а Gemma-4-31B-it-uncensored-heretic над которой провели лоботомию с непредсказуемой деградацией качества. Зануление весов может работать в каких-то сценариях, но общее качество всё равно просядет, особенно на не английском языке. Компенсировать это через высокий Q8 квант не получится, это просто надо учитывать.
Но помимо этого, в llama.cpp на старте было не правильно реализовано внимание у Gemma4, несколько дней назад это исправили, плюс Google выложил правильный шаблон чата который вшит в gguf.
Надо перекачать gguf и скачать свежую llama.cpp. Увеличилось и качество ответов, и модель начала нормально работать в агентах, и теперь расход памяти под контекст не такой огромный, как было вначале.
С размышлением может в кванте UD-Q2_K_XL:
Без размышления правильно начинает отвечать с UD-Q3_K_XL:
Gemma4 31B UD-Q3_K_XL
UD квантование - это динамическое квантование, в котором тензоры внимания квантуются выше, за счет этого, например, UD-Q3_K_XL становится примерно равен по качеству с привычным Q4_K_M, но весит меньше на несколько Гб, а сравнимый по весу UD-Q4_K_XL будет лучше обычного Q4_K_M.
Свежие Qwen3.5-4B и Gemma-4-E4B. Помимо текста, у этих моделей есть Vision модуль, можно распознавать, переводить, создавать макеты на основе изображений.
Отличная работа. На сколько сложно будет добавить поддержку этой модели в Unsloth?
Они недавно выпустили Unsloth Studio, в которой удобный интерфейс для обучения, легче работать с датасетами, благодаря чему в разы проще обучать различные современные модели (Fine-tune, LoRA, QLoRA 4-bit).
Но не разглядели главное, на контексте в 90к.
Вот типичные 10к, которые покрывают большинство локальных задач:
Проще и быстрее поставить qwen code, в котором есть Qwen3.6-Plus с большими бесплатными лимитами, там 1m контекста, качество в разы лучше и быстрая скорость, а для кого-то всё что хуже Opus 4.6 пустая трата времени.
Для переводить, распознавать картинки, вести диалог и тому подобному очень много контекста не нужно, точнее его нужно сбрасывать, а не накапливать. С помощью cmoe можно высвободить много видеопамяти для других параллельных задач, при этом получить скорость большую, чем выдают LM Studio или ollama. Для агентного использования можно прибегать к субагентам, чтобы не накапливать контекст.
Но вообще, на большом контексте важна скорость PP, чтобы её увеличить, нужно увеличить размер пакетов -ub 3072 -b 3072, или больше. Опционально можно квантовать KV-кэш -ctk q8_0 -ctv q8_0, чтобы снизить расход памяти на контекст в 2 раза. Сейчас тестируют TurboQuant от Google Research, которые заявляют, что можно квантовать контекст до 3.5 бит без заметных потерь, что снизить расход памяти в ~4 раза.
90к контекст, подготовка промпта заняла 2.5 минуты, что для агентного программирования хороший результат. Просадка tg не только за счёт контекста, но и ncmoe увеличено с 13 до 22, чтобы вместить столько контекста.
DDR4 16Gb (2x8gb 3600 Mhz), Ryzen 3600 6 ядер, RTX 3060 12gb, Win10, драйвера nvidia свежие, cuda 13.1.
Gemma-4-26B-A4B-it-Q4_K_M, запуск с -ncmoe 13, генерация 33 t/s:
Qwen3.5-35B-A3B-UD-Q4_K_XL, запуск с -ncmoe 22, генерация 32 t/s:
Модели не влезают в 12гб VRAM, но если использовать перераспределение MoE тензоров и запускать напрямую llama.cpp, в которой по умолчанию включен параметр -fit, который автоматически подберет оптимальные параметры запуска, или настраивать -ncmoe вручную, то можно получить ощутимую прибавку к скорости по сравнению со стандартным способом ngl, который по умолчанию используется в Ollama и LM Studio.
4060 Ti 16Gb выдает 65 t/s. Модель именно та, что по умолчанию предлагается в LM Studio:
Подробнее, как можно получить больше скорости:
Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Запускаем настоящую DeepSeek R1 671B на игровом ПК и смотрим вменяемая ли она на огромном контексте (160к)
Тут, конечно, это уже надо на нормальном датасете обучать, чтобы заметить разницу. Но архитектура старая, поддержки triton нет, обучение будет в разы дольше, чем дообучить даже, например, Qwen3.5 4B.
Но в целом можно попробовать и так. Сходу при запуске инференса со Sparse Attn ошибка:
Если посмотреть вывод модели, то вероятности обнулены, логиты в бесконечности, а маска внимания все маркирует как False. Можно попробовать починить:
modeling_rugpt3xl.py
Теперь запускается нормально и можно обучить, и чтобы проверить работает ли вообще отсечение, в forward можно добавить отладочную информацию:
Добавить в forward
Так как Sparse Attn тут настроен на 128 токенов, то если запрос меньше, то Sparse должна быть равна Dense и фактически не работать:
Запрос длиннее 128, тут Sparse успешно отсекает и с виду нормально работает:
Попробовал обучить LoRA на первом попавшемся датасете диалогов Den4ikAI/russian_dialogues, датасет на 2.5 млн строк или 40m токенов. Обучил только на первых 10000 за 5-10 минут.
Обучилась успешно, и приобрела особый стиль общения, который присутствовал в датасете:
Датасет, наверное, не очень удачный, но это хороший пример, что если есть base, то из базы можно выровнять (alignment) модель до различных состояний.
Вы пытаетесь работать с base моделью как с instruct моделью.
Base (или pretrain) - это 1 шаг обучения LLM из 3. Смысл pretrain в том, чтобы модель умела составлять буквы в слова, слова в предложения, предложения были орфографически верные, логически правильные, набирала базу знаний и так далее. Такая нейросеть умеет продолжать текст, вы пишите ей “cat = кошка, dog = собака, duck =” и она продолжает “утка”.
Но если вы пытаетесь с ней общаться в чате, то ей будет послан шаблон чата, который может выглядеть очень не типично, например, вот так:
"<|im_start|>user\n{question}<|im_end|>\n<|im_start|>assistant\n{answer}<|im_end|>"Поэтому базовая модель в таком сценарии начинает генерировать хаотичные ответы. Чтобы base научилась нормально вести диалог, нужно обучить её шаблону.
Для примера, обучим эту ruGPT3 XL base до уровня instruct (до очень примитивного, так как датасет должен быть куда разнообразнее). Генерируем 100 пар вопрос-ответ такого вида:
Теперь из этих пар нужно создать датасет согласно шаблону-чата модели, в данном случае это:
Обучаем нейросеть как finetune целиком или как LoRA адаптер. Для примера хватит 3 эпох на 100 примерах:
Через пару минут “ruGPT3XL-instruct” готова. Теперь можно задать какой-нибудь вопрос, которого не было в дополнительном датасете:
Мы не учили модель отвечать, кто такой Шекспир, и не учили её ничему про Fallout, это уже было в модели. Мы только научили её обрабатывать шаблон чата, и, побочно, структуре ответа как из энциклопедии. Аналогично её можно научить агентным задачам и так далее.
Да нет, память целиком выделяет в момент загрузки. Заполненность влияет только на скорость генерации.
GPT-OSS-20B для контекста использует SWA, механизм который в разы снижает потребление VRAM, чтобы его активировать, нужно включить Flash Attention. Полные 128к требуют +6гб VRAM, если включить квантование KV-кэша Q8_0, то будет +3Гб.
В llama.cpp по умолчанию работает новый режим --fit, который автоматически подбирает оптимальные параметры для эффективного использования GPU минус 1гб VRAM (параметр настраивается) и включает flash attention, поэтому такое отличие от LM Studio.
Под эффективным имеется ввиду другое распределение тензоров, те, которые используются всегда, пойдут на GPU, остальные, которые используются периодически, на CPU, и если осталась VRAM, то будет заполнена разреженными слоями с экспертами. Почему это так работает, выше я уже кидал ссылку на статью Вам нужна RAM, а не VRAM, где это объясняется.
В LM Studio можно включить "половину" от этого режима галочкой Force Model Expert Weights onto CPU (во время выбора модели зажать Alt для расширенных настроек), и перепроверить, что включен Flash Attention, чтобы оптимизировать расход памяти под контекст.
Qwen2.5 устарела на ~1.5 года, даже Qwen3 уже не особо актуальна. Переходите на новые более качественные модели, ваша машина легко потянет современные хорошие MoE-модели, которые в разы быстрее чем Qwen2.5-72B и, что важнее, намного качественнее.
Из современных моделей к 128Гб подойдут: OpenAI GPT-OSS-120B, GLM-4.5-Air 110B, Minimax M2.1 229B (в динамическом квантовании UD gguf, mlx не влезет в 128гб). Малые версии тоже есть, например, Qwen3-30B-A3B-2507 и остальные из современного списка, при этом с того момента успели выйти хорошие новинки.
Динамическое квантование от Unsloth позволяет опустится ниже 4-бит квантования, при этом сохраняя достаточно хорошее качество, так что можно запустить и Qwen3-235B-A22B, и свежий Minimax M2.1 229B.
Бенчмарк программирования Aider Polyglot для 1, 2, 3-битного динамического квантования UD:
Вообще, этот ноутбук позволяет запускать на хорошей скорости GPT-OSS-120B или GLM-4.5-Air и без eGPU, 64Гб RAM хватит, а через 4070 будет приличное ускорение для MoE.
Подробнее как запускать такое на ноутбуке или ПК где достаточно RAM и есть немного VRAM:
Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM.
Cerebras осенью представили метод REAP для вырезания "лишних" экспертов из MoE уменьшая размер модели до 50%, по их словам почти без потерь в области программирования и tool-calling: https://arxiv.org/abs/2510.13999
В целом это работает, но вопрос качества остаётся открытым, например, из того, что сразу бросается в глаза, у модели пропадает умение отвечать на русском языке.
На huggingface много моделей в REAP виде уже готовы: https://huggingface.co/models?search=reap
Спасибо за замеры, обычно это называют benchmaxxing. Вот тут у человека, делающего llm-translate, схожий отзыв: https://habr.com/ru/articles/951416/comments/#comment_28935346
Перечисленные не очень свежие, Mistral-7B и вовсе 2023 года, одна из самых-самых первых, давно вышли более качественнее модели, если брать в том же размере, то это Ministral-3-8B-Instruct-2512, у Phi вышла Phi-4, Gemma выпустила Gemma3, а вместо Llama3 - Qwen3.
С недавних пор на 3060 можно запустить и вполне себе большие модели, и с нормальной скоростью. Только нужна ОЗУ и можно ускорять MoE модели с помощью одной GPU.
Если стандартные 16Гб RAM, то можно запускать Qwen3-30B-A3B (включая Vision), Granite-4.0-H-Small 32B, GPT-OSS-20B. Если есть 64Гб, то можно запускать, например, GPT-OSS-120B или GLM-4.5-Air, на 96Гб можно запускать новую MiniMax-M2.1 230B, а на 192Гб DDR5 уже можно запустить DeepSeek R1 671B и V3.1.
Вот, например, на медленной AMD RX 6600 (скорость памяти 224 ГБ/с, а у 3060 скорость 360 ГБ/с, скорость LLM напрямую зависит от скорости памяти), модель GPT-OSS-120B выдает 13 t/s:
Размер устройства не имеет значения, имеет значение количество каналов памяти и тип памяти.
Скорость генерации LLM линейно зависит от скорости памяти, в GPU используют быструю GDDR6X и DDR7 и широкую шину памяти, получая скорость 1 Тб/c на 4090. В Ryzen AI Max+ 365, как и в NVIDIA DGX Spark, используется DDR5 и всего 4 канала памяти, скорость памяти 256 Гб/с. Для сравнения у 4060ti всего 288 Гб/с, что немногим больше.
Смотря на какой архитектуре модель: Dense или MoE. Новый Devstral 2 123B сделан как Dense, там будет 3 t/s, но многие переходят на MoE, поэтому там будет скорость намного выше.
Ryzen AI Max+ выдает 50 t/s на GPT-OSS-120B, это очень комфортная скорость для работы, и на 128Гб можно запустить более качественные модели, вроде GLM-4.5-Air или MiniMax-M2.1 230B, скорость будет в районе 25-30 t/s.
Подробнее про MoE модели: Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM