В актуальные Mac Studio ставят LPDDR5 память, что означает практическую бесперспективность затеи с инференсом для больших моделей. Там все счастье заканчивается на этапе когда модель в принципе влезла. Но несколько токенов в секунду, которые выдает девайс, это далеко за гранью комфортной работы.
Вы путаете двухканал в обычном ПК, где на ddr5 предел это 100-120 гб/с и многоканал в маках и серверах. Только в маках еще есть специальные ядра для тензорных вычислений.
Скорость у U3 Ultra 512 Гб заявлена 819 гб/с, у 4090 для сравнения заявлена 1008 гб/с. Разница всего 23% по скорости и огромная по объему.
Если отключить аппаратное ускорение в браузерах, а в Windows отключить "Планирование графического процессора с аппаратным ускорением", то получите 22 t/s в LM Studio. Почти 40% ускорения. Переходите на llama-server и получите 30 t/s.
Совсем безумие, перейти на линукс и будет 34 t/s. И через llama-server и через LM Studio.
Qwen 30B(MoE). NVidia 4090 - 32.93 t/s.
4090 может выдавать намного больше, там ведь всего 3B активных параметров, а версия из LM Studio Q4_K_M весит всего 17.5гб. В моем случае выдает 112 t/s под Windows и 135 t/s под Linux.
Во всех случаях запуск llama-bench сборки без GPU, только avx2. Если запускать через сборку с GPU, даже если указать -ngl 0, pp будет считаться на GPU. pp - это подготовка промпта и всей истории диалога. tg - генерация новых токенов.
AMD Ryzen 5600g + b550 phantom gaming 4 + 4x 16gb ddr4 3600 16-19-19-39 CR1 Чтение в aida: 50851 MB/s Latency: 74 ns Модель saiga_nemo_12b.Q8_0, запуск llama-bench сборка без GPU, только avx2:
pp: 13.52 t/s
tg: 3.89 t/s
Intel Core i7-14700 (без K) + msi pro z790-p + 2x 48gb ddr5 6400 KingBank 32-39-39-99 CR2 Чтение в aida: 97709 MB/s Latency: 71.2 ns Модель та же, запуск идентичный. Память заводится на заводском XMP 6400:
pp: 26.01 t/s
tg: 6.98 t/s
Intel Core i7-14700 (без K) + msi pro z790-p + 4x 48gb ddr5 5400 KingBank 38-38-38-77 CR2 Чтение в aida: 80734 MB/s Latency: 75.6 ns Модель та же, запуск идентичный. Дешевые китайские 4 планки не завелись на XMP, пришлось снизить до 5200-5400:
Начиная с 0.3.14 в LM Studio это в явном виде работает, можно отключать, можно менять стратегию заполнения, чтобы вначале заполнялась самая быстрая. LM Studio 0.3.14: Multi-GPU Controls
Но это сделать сложно, использую обычную материнскую плату на AMD x470 чипсете. Там какие-то сложность с вторым PCI-E16x, если установлен второй SSD(
Вы можете подключить gpu в любой маленький x1 pcie, или урезанный x16, либо даже в слот для nvme через переходник. Для инференса достаточно x1 pcie 1.0, не важны ни x16 линии, ни версии pcie.
Ширина канала виляет только на время загрузки слоев в память видеокарты - один единственный раз во время загрузки модели, а на сами вычисления это уже никак не влияет. На материнках обычно стоит много pcie 3.0 x1, это 1 гб/с, если загружать с sata ssd, то упретесь в скорость диска, а не канала pcie, а если с nvme, то будет 16 секунд на загрузку, вместо 6 секунд.
Так что можно утыкать всю материнку кучей видях через удлинители, на localllama периодически люди выкладывают своих монстров франкенштейна, где видеокарты кто как смог закрепил вне корпуса, и там обычно их от 4 до 10.
В типичный домашний комп можно без проблем засунуть 3.5 слотовую 4090 и 2 слотовую 4060ti/5060ti, нужно только материнку правильно подобрать, чтобы расстояние между двумя pcie было достаточным. У меня на b550 phantom gaming 4 идеально влезло, не пришлось ничего придумывать.
Скажите, что важнее для второй видеокарты, скорость самого чипа или размер памяти? Или на ней то же будет производиться исполнение и важно и то и другое?
Слои распределятся по видеокартам, поэтому каждая будет вычислять, но требования к этому на столько малы по сравнению к скорости памяти, что фактически важны только объем и скорость памяти.
Может мы говорим про разные вещи, пробовал грузить 70B модели в lmstudio в 4090, вроде они не должны помещаться в память и работало быстрее чем 0.01 t/s, не помню точно с какой скоростью, но не так медленно.
У Nvidia настройка CUDA System Memory Fallback или CUDA политика резерва системной памяти, по умолчанию включена, когда в память gpu не влезают данные, она загружает их в "своп" в обычную память, в эти моменты модель начинает дико тормозить, как и вся система.
Может показаться, что это работает просто от того, что ollama или LM Studio не эффективно заполняют vram, и там есть еще место. Если у вас это действительно работает, то это стоит изучить подробнее.
А так, у всех проектов основанных на llama.cpp есть возможность выгружать часть слоев на GPU, сколько хватит памяти, а часть оставлять на CPU. LM Studio делает это автоматически. В новой версии можно явно указать, чтобы модель не выходила за пределы реальной памяти.
А можно с этого момента подробнее? У меня не то что бы залежи видеокарт поэтому никогда не смотрел как использовать две. Может поделитесь ссылкой как это дело настраивать?
Всё автоматически заработает, если вместо CUDA выбрать Vulkan - то заработает даже для AMD + Nvidia + Intel.
Если у вас разнородные видяхи, например, у 4060 память имеет скорость 288 гб/с, у 5060 448 гб/с, а у 4090 1 тб/с, то нужно выбрать стратегию приоритетной разгрузки, сначала максимально загружать 4090, а потом остальные, а не разгружать слои равномерно.
Ну и еще несколько деталей:
В LM Studio пока нельзя указывать override-tensor, если интересует эта опция, то придется воспользоваться text-generation-webui, там это указывается в extra-flags поле. Это в основном затронет MoE модели, для остальных не важно.
В text-generation-webui можно легко создавать множество ролей и быстро переключаться между ними, у каждой роли будет своя история диалогов. Тут легче закидывать модели для тестирования, достаточно копировать их в models папку, не нужно создавать подпапки как в LM Studio.
Если есть встройка, можно в Windows в "настройках графики" указать путь до любого exe'шника, например, браузера или оболочки винды dwm, и перекинуть их на встройку, чтобы высвободить занятые пару гб под винду и браузер. Либо в браузере отключить 3d ускорение, а в настройках графики Windows отключить планирование gpu с аппаратным ускорением. Это имеет смысл, если не хватает чуть-чуть до загрузки целиком модели в vram.
В LM Studio полезно выбирать версии квантов, например найти unsloth версии. IQ4_XS кванты, влезают в 40гб vram для 70-72B моделей, а UD-Q2_K_XL влезет в 32гб.
В LM Studio или ollama не оптимально в автоматическом режиме заполняется VRAM, когда можно загрузить еще 3-4гб они не догружают. Тут поможет ручное управление, мониторить nvidia-smi или диспетчер задач, и смотреть реальную загрузку памяти.
У LM Studio по умолчанию выключено квантование KV-кэша, если его включить, можно еще выиграть пару гб.
Немного информации про разные кванты
У gguf есть 2 вида квантов: статические k-кванты и i-кванты с применением матрицы важности imatrix. k-кванты просто квантуют тензоры, без выбора какие тензоры важнее в общей куче. В i-квантах приоритет отдается квантам, которые подсвечиваются через imatrix. imatrix создается из txt файла с различным набором текстов, поэтому финальная модель будет квантована с учетом тех видов текстов, что там были, и можно сделать свою imatrix заточенную, например, на нужный язык.
Все квантуют по разному, поэтому кванты называются одинаково, но они будут разные. Например, самые популярные кванты от bartowski заточены на английский язык, он использует английскую imatrix везде, даже не для i-квантов, он квантует статичные k-кванты вплоть до Q6 через английскую imatrix. Если у вас приоритет на другой язык, лучше взять статичные кванты от lm-studio, или новые кванты от Unsloth.
В ik_llama есть продвинутые кванты, они на данный момент лучше остальных вариантов. Такие кванты могут конвертироваться на лету через ключ -rtr при загрузке модели, но это отключает mmap. Можно их переконверитровать и сохранить результат, либо немного готовых есть у https://huggingface.co/ubergarm. Но это для совсем энтузиастов, которые хотят выжать максимум из минимального объема, и которые не боятся компиляции и консоли, так как ik_llama не предоставляет готовые бинарники.
Регистрация на openrouter не замороченная, пускает любую почту, в поиске просто ввести free и будет много новинок, которые можно протестировать, в том числе и через API.
Сейчас предел для энтузиаста это модели 30B. Это влезет на хороший домашний компьютер с 4090 или 5090. Может быть можно замахнуться на 70B, но по видеопамяти вы уже выйдете за пределы 5090
Так энтузиасту с 4090 достаточно добавить одну 5060 ti 16гб, чтобы вмещать 72B IQ4_XS полностью в vram. А 5090 + 16гб открывает доступ к 123B моделям (Large 2 123B или Command A 111B).
и будет использовать видео-своп(не знаю как правильно называется, подкачку из оперативы), работать будет все равно быстрее чем на любом CPU.
Не, не будет. Это будет на порядок медленнее чем на любом CPU, на практике "видео-своп" дичайшие тормозит и все рекомендуют его отключать, чтобы случайно не залезть в него. Падение на 70B моделях с 2 t/s до 0.01 t/s.
Вот и все реалии.
Еще со времен первой MoE модели, которую Mistral представили 2 года назад, это не так. У них была Mixtral-8x7B размером 46.7B и она показывала себя сильно лучше 30B тех времен, модель обходила Llama2-70B и конкурировала с chatgpt-3.5.
После этого MoE шагает по планете, включая проприетарные модели, вроде Grok, Gemini и по слухам gpt-4o.
Для энтузиастов сейчас есть такие локальные MoE:
Llama 4 Scout - размер 109B, скорость 20 t/s, большой запас по скорости. Хватит 8гб gpu.
Llama 4 Maverick - размер 402B, скорость 19 t/s. Хватит 12гб gpu.
Qwen3-235B-A22B - размер 235B, скорость 4.5-6.5 t/s.
DeepSeek V3/R1 - размер 671B, скорость 2-3 t/s.
Граница комфортного использования это где-то 5 t/s.
Детали не так важны, главное, что энтузиасты дома не заперты на 30B моделях и никогда не были. До этого была отличная MoE модель Mixtral 8x22b и её отличный файнтюн WizardLM-2.
Душные детали. Почему MoE быстрое и большое, а Dense тяжелое. Параметры запуска для ускорения
MoE модели не монолитны, они состоят из отдельных экспертов и на вычисление каждого токена на каждом шагу задействуется только часть экспертов. На каждом шагу MoE-роутер выбирает какие эксперты будут задействованы для следующего токена, они могут быть как разными, так и совпадать какое-то время, и на каждом шагу работает только ограниченное число экспертов, поэтому модель работает в разы быстрее, чем Dense модель такого же размера.
В теории Dense модели такого же размера будут лучше, но на практике это не всегда так. Был пример Dense модели Llama 3.1 размером 405B, она выступала не сильно лучше, и даже хуже, чем модель Llama 3.3 70B.
Ускорение для MoE можно достигнуть выгрузив тензоры всех экспертов в GPU, всех кроме тяжелых ffn тензоров, это делается через команду: -ot exps=CPU или --override-tensor "([0-9]+).ffn_.*_exps.=CPU"
Архитектура MoE бывает разной, например, Llama 4 имеет общих экспертов, и так как общие эксперты участвуют в вычислении токена на каждом шагу, то выгрузка тензоров дает хорошее ускорение, так как общие эксперты всегда в быстрой видеопамяти.
У Qwen3 нет общих экспертов, поэтому тут не получится получить стабильное ускорение, но можно выгрузить столько экспертов, сколько влезает через команду: -ot blk.(1[2-9]|[2-8][0-9]|9[0-3]).ffn.*=CPU Команда указывает, что первые 11 экспертов пойдут на GPU, а остальные 82 на CPU. Тут обычное регулярное выражение, 11 слоев рассчитаны на 24гб vram.
Если несколько видеокарт, можно тензоры раскидать по устройствам:
Это работает и на обычной llama.cpp, но так как много тензоров остаются на CPU, полезно будет взять ik_llama, откуда и пришли все эти оптимизации с override-tensor - это форк llama.cpp который затачивается на оптимизации работы на CPU, улучшенные кванты, которые конвертируются на лету из обычных, и немного ускоряет GPU.
В командную строку нужно добавить параметры: -fmoe -amb 512 -rtr -rtr параметр который запускает автоматическую конвертацию модели в улучшенный квант от ik_llama, но он отключает mmap (если mmap включен и модель не влезла в память, она будет загружаться с диска), поэтому модель будет загружаться сразу в память и памяти должно быть достаточно. -ngl сколько выгрузить слоев на gpu.
Благодаря оптимизациями от ik_llama, то, например, Maverick 402B если запускать его через ik_llama.cpp, то на 32k контексте скорость с 19 t/s падает всего до 15 t/s, при расходе видеопамяти 14гб.
Если у вас больше 1 GPU, то будет ошибка при выгрузке всех возможных слоев через -ngl 95 и придется снизить её до 93-94. Это снизить скорость генерации, поэтому лучше собрать ik_llama добавив DGGML_SCHED_MAX_COPIES=1 (по умолчанию 4):
Есть принудительное отключение мышления через флаг, чтобы даже пустых размышляющих тегов не было, но это делается через шаблон чата jinja, а не через управляющие токены.
Там же рекомендуют отключить "rotating context management" через флаг --no-context-shift, чтобы размышляющие токены не вытеснялись во время генерации, пока размышление не будет завершено, и модель не уходила в бесконечный цикл размышлений или не снижалось качество размышлений.
Зацикливание - это частая проблема шаблона чата или плохих квантов. В данном случае была проблема с шаблоном чата в llama.cpp и следовательно во всех производных, вроде ollama и LM Studio, и все кванты испорчены. Меньше суток назад это исправили, нужно обновить софт и перекачать кванты.
Спустя 38к токенов размышления ответ дан правильный
Запустить можно хоть с nvme на домашнем ПК, для больших MoE это сейчас частое явление набирающее популярность. Всё упирается в скорость работы, и тут нет простого ответа. Если модель влезает в VRAM - всё будет очень быстро.
Цифра рядом с B это в среднем и есть количество памяти, то есть 32B будет требовать 32гб памяти в кванте не отличимом от оригинала (Q6 или Q8). Но если нужен размер точнее, то зайдя в карточку gguf версии модели, все размеры будут указаны:
Пример для Qwen3-32B-GGUF
В gguf файл спроектирован так, что он повторяет структуру памяти и просто мапятся в память как есть, поэтому размер файла будет равен размеру занимаемому памяти. Сверх этого места нужно сколько гб на контекст. Чем больше контекст, тем больше ГБ нужно. Для 128k может потребоваться в 2 раза больше размера самой модели. Контекст тоже можно квантовать и использовать flash attention и скользящее окно.
Q6 и Q8 это часто избыточные кванты для больших моделей, типичные кванты которые считаются близким к оригиналу это Q4_K_M или Q5_K_M, или если памяти впритык, то IQ4_XS. I-кванты это квантование через матрицу важности imatrix, они обычно точнее, чем K-кванты, поэтому могут выдавать тоже качество с меньшим размером, но требуют в ~2 раза больше вычислительных мощностей при выполнении, весят меньше, поэтому они могут помочь засунуть модель в память, когда Q4_K_M никак не влезает.
На практике, чем больше модель, тем меньше шансов, что она влезет в железо, и тем легче она переносит квантование, поэтому появился вариант UD квантов, это динамическое квантование от Unsloth. Такие кванты можно брать и UD-IQ3 и даже UD-IQ2 - они будут хуже, чем Q4_K_M, но за счет нового подхода они выступают на достойном уровне, даже 1.58 битные версии.
Забыл добавить в статью, что переключаться между режимом размышления и без размышления нужно тегами /think и /no_think в системном промпте, либо прямо в тексте.
Запрос без размышлений, в системной промпте указал /no_think, что делает этот тег по умолчанию для всего, блок размышлений создается, но он пустой:
После этого, несмотря на системный промпт, можно послать запрос на размышление через /think, и блок с размышлениями заполняется:
Для тех, у кого вообще нет желания что-то скачивать и запускать, но есть желание потыкать старые игры, есть эмулятор js-dos в браузере через wasm, и есть разные сайты, позволяющие это запускать. Например, на этом сайте собраны различные русские версий игр: https://dos.zone/ru/
Сразу есть и виртуальное управление для игры с мобильных устройств:
Максимальная сейчас это maverick 400B, behemoth 2T они не выложили.
Регистрируетесь в openrouter.ai, работает и на временную почту, ищете там free модели через поиск написав "free" и используете через api (например, через клиент https://msty.app/ или любой другой поддерживающий openai completion api), либо у них есть чат на сайте.
Зачем вы кидаете ссылку на статью, которую вы, видимо, сами не читали, и в которой написано ровно то, что я вкратце написал? Там даже картинками все проиллюстрировано. Единственное, чего там нет, это разницы между pp и tg, но это не так важно.
Микс экспертов (MoE) пришел намного раньше появления рассуждающих моделей. Первая MoE модель Mixtral-8x22B появилась еще год назад, когда даже техники CoT не было, не то, что рассуждающих моделей.
То, как вы описываете MoE не соответствует действительности. MoE работает точно так же как Dense, они по кругу гоняют выходной слой отправляя его в первый слой.
В MoE на каждом новом шагу выходной вектор подается на вход модели, и обученный маршрутизатор (Gating Mechanism) находит признаки в этом векторе, выдает веса вероятностей, которые соответствуют каждому эксперту, после этого выбирается Top-K экспертов, которые и будут активированы для этого шага цикла вычисления одного токена, и дальше снова по кругу как в Dense моделях.
Тут нет никаких разбивок вопроса внутри, никаких перепроверок и никаких внутренних диалогов. MoE это способ масштабировать модель, а не про внутренние диалоги экспертов. MoE позволяет выдавать качество 140B моделей, работая при этом со скоростью моделей 17B, но повышая требования к памяти до 400B модели. Когда у вас нет проблем с железом, как не распараллеливай, запуская монолитную 400B вы не получите быстрый скоростей, а скорость это важно для всяких chatGPT сервисов.
И сам термин "рассуждающие модели" многими понимается не правильно. Это не способ модели размышлять, из-за чего и появляются различные неправильные выводы о том, что "модель не все этапы размышления показывает", это способ масштабировать модель снизив требования к этапу обучения, что равносильно повысить качество модели оставив обучение на том же уровне.
Ошибка модели зависит от 3 факторов:
вычисляемая мощность обучения
размер датасета
количество параметров
Сейчас временно уперлись во все 3 фактора. Например, нельзя просто наращивать размер модели не увеличивая размер датасета (модель llama 3.3 70B примерно равна по качеству llama 3.1 405B). Или из-за нехватки данных для обучения нельзя просто увеличивать количество шагов/эпох обучения - будет переобучение. И так далее.
Зависимость очень прямая
Выходом стало масштабировать 4 фактор - увеличить мощность предсказания модели (test-time compute).
Смысл тут в том, что модель набрасывает несколько ответов, и видя эти ответы может оценить их качество своим стандартным механизмом self-attention, который одинаков для Dense (QwQ-32B) и для MoE (R1), тем самым отбросить ошибочные варианты.
Этот эффект пользователи уже давно могли наблюдать через механизм "А если подумать?". Когда первый раз модель отвечает не правильно, но если её попросить подумать над ответом, то второй или третий будут уже правильными.
И тут важен не сам фактор размышления в стиле мыслей, это просто красивая обертка, важен сам факт того, что модель получает черновые ответы и она через attention может оценить их качество, прежде чем выдать финальный ответ.
Диалоги длились по 5 минут, но не особо насыщенные. Полные стенограммы всех диалогов выложены тут: https://osf.io/jk7bw/files/osfstorage в файле tt_message_anonymized.csv
Сомнительно.
Вы путаете двухканал в обычном ПК, где на ddr5 предел это 100-120 гб/с и многоканал в маках и серверах. Только в маках еще есть специальные ядра для тензорных вычислений.
Скорость у U3 Ultra 512 Гб заявлена 819 гб/с, у 4090 для сравнения заявлена 1008 гб/с. Разница всего 23% по скорости и огромная по объему.
DeepSeek R1 671B Q4 запускают на 18 t/s при потреблении в 51 ватт.
Если отключить аппаратное ускорение в браузерах, а в Windows отключить "Планирование графического процессора с аппаратным ускорением", то получите 22 t/s в LM Studio. Почти 40% ускорения.
Переходите на llama-server и получите 30 t/s.
Совсем безумие, перейти на линукс и будет 34 t/s. И через llama-server и через LM Studio.
4090 может выдавать намного больше, там ведь всего 3B активных параметров, а версия из LM Studio Q4_K_M весит всего 17.5гб.
В моем случае выдает 112 t/s под Windows и 135 t/s под Linux.
Во всех случаях запуск llama-bench сборки без GPU, только avx2. Если запускать через сборку с GPU, даже если указать -ngl 0, pp будет считаться на GPU.
pp - это подготовка промпта и всей истории диалога.
tg - генерация новых токенов.
AMD Ryzen 5600g + b550 phantom gaming 4 + 4x 16gb ddr4 3600 16-19-19-39 CR1
Чтение в aida: 50851 MB/s
Latency: 74 ns
Модель saiga_nemo_12b.Q8_0, запуск llama-bench сборка без GPU, только avx2:
pp: 13.52 t/s
tg: 3.89 t/s
Intel Core i7-14700 (без K) + msi pro z790-p + 2x 48gb ddr5 6400 KingBank 32-39-39-99 CR2
Чтение в aida: 97709 MB/s
Latency: 71.2 ns
Модель та же, запуск идентичный. Память заводится на заводском XMP 6400:
pp: 26.01 t/s
tg: 6.98 t/s
Intel Core i7-14700 (без K) + msi pro z790-p + 4x 48gb ddr5 5400 KingBank 38-38-38-77 CR2
Чтение в aida: 80734 MB/s
Latency: 75.6 ns
Модель та же, запуск идентичный. Дешевые китайские 4 планки не завелись на XMP, пришлось снизить до 5200-5400:
pp: 23.75 t/s
tg: 5.85 t/s
Через консоль: https://github.com/ggml-org/llama.cpp/tree/master/tools/rpc
Не знаю есть ли GUI для этого.
Начиная с 0.3.14 в LM Studio это в явном виде работает, можно отключать, можно менять стратегию заполнения, чтобы вначале заполнялась самая быстрая. LM Studio 0.3.14: Multi-GPU Controls
Вы можете подключить gpu в любой маленький x1 pcie, или урезанный x16, либо даже в слот для nvme через переходник. Для инференса достаточно x1 pcie 1.0, не важны ни x16 линии, ни версии pcie.
Ширина канала виляет только на время загрузки слоев в память видеокарты - один единственный раз во время загрузки модели, а на сами вычисления это уже никак не влияет. На материнках обычно стоит много pcie 3.0 x1, это 1 гб/с, если загружать с sata ssd, то упретесь в скорость диска, а не канала pcie, а если с nvme, то будет 16 секунд на загрузку, вместо 6 секунд.
Так что можно утыкать всю материнку кучей видях через удлинители, на localllama периодически люди выкладывают своих монстров франкенштейна, где видеокарты кто как смог закрепил вне корпуса, и там обычно их от 4 до 10.
В типичный домашний комп можно без проблем засунуть 3.5 слотовую 4090 и 2 слотовую 4060ti/5060ti, нужно только материнку правильно подобрать, чтобы расстояние между двумя pcie было достаточным. У меня на b550 phantom gaming 4 идеально влезло, не пришлось ничего придумывать.
Слои распределятся по видеокартам, поэтому каждая будет вычислять, но требования к этому на столько малы по сравнению к скорости памяти, что фактически важны только объем и скорость памяти.
У Nvidia настройка
CUDA System Memory FallbackилиCUDA политика резерва системной памяти, по умолчанию включена, когда в память gpu не влезают данные, она загружает их в "своп" в обычную память, в эти моменты модель начинает дико тормозить, как и вся система.Может показаться, что это работает просто от того, что ollama или LM Studio не эффективно заполняют vram, и там есть еще место. Если у вас это действительно работает, то это стоит изучить подробнее.
А так, у всех проектов основанных на llama.cpp есть возможность выгружать часть слоев на GPU, сколько хватит памяти, а часть оставлять на CPU. LM Studio делает это автоматически. В новой версии можно явно указать, чтобы модель не выходила за пределы реальной памяти.
Всё автоматически заработает, если вместо CUDA выбрать Vulkan - то заработает даже для AMD + Nvidia + Intel.
Если у вас разнородные видяхи, например, у 4060 память имеет скорость 288 гб/с, у 5060 448 гб/с, а у 4090 1 тб/с, то нужно выбрать стратегию приоритетной разгрузки, сначала максимально загружать 4090, а потом остальные, а не разгружать слои равномерно.
Ну и еще несколько деталей:
В LM Studio пока нельзя указывать override-tensor, если интересует эта опция, то придется воспользоваться text-generation-webui, там это указывается в extra-flags поле. Это в основном затронет MoE модели, для остальных не важно.
В text-generation-webui можно легко создавать множество ролей и быстро переключаться между ними, у каждой роли будет своя история диалогов. Тут легче закидывать модели для тестирования, достаточно копировать их в models папку, не нужно создавать подпапки как в LM Studio.
Если есть встройка, можно в Windows в "настройках графики" указать путь до любого exe'шника, например, браузера или оболочки винды dwm, и перекинуть их на встройку, чтобы высвободить занятые пару гб под винду и браузер. Либо в браузере отключить 3d ускорение, а в настройках графики Windows отключить планирование gpu с аппаратным ускорением. Это имеет смысл, если не хватает чуть-чуть до загрузки целиком модели в vram.
В LM Studio полезно выбирать версии квантов, например найти unsloth версии. IQ4_XS кванты, влезают в 40гб vram для 70-72B моделей, а UD-Q2_K_XL влезет в 32гб.
В LM Studio или ollama не оптимально в автоматическом режиме заполняется VRAM, когда можно загрузить еще 3-4гб они не догружают. Тут поможет ручное управление, мониторить nvidia-smi или диспетчер задач, и смотреть реальную загрузку памяти.
У LM Studio по умолчанию выключено квантование KV-кэша, если его включить, можно еще выиграть пару гб.
Немного информации про разные кванты
У gguf есть 2 вида квантов: статические k-кванты и i-кванты с применением матрицы важности imatrix. k-кванты просто квантуют тензоры, без выбора какие тензоры важнее в общей куче. В i-квантах приоритет отдается квантам, которые подсвечиваются через imatrix. imatrix создается из txt файла с различным набором текстов, поэтому финальная модель будет квантована с учетом тех видов текстов, что там были, и можно сделать свою imatrix заточенную, например, на нужный язык.
Все квантуют по разному, поэтому кванты называются одинаково, но они будут разные. Например, самые популярные кванты от bartowski заточены на английский язык, он использует английскую imatrix везде, даже не для i-квантов, он квантует статичные k-кванты вплоть до Q6 через английскую imatrix. Если у вас приоритет на другой язык, лучше взять статичные кванты от lm-studio, или новые кванты от Unsloth.
В ik_llama есть продвинутые кванты, они на данный момент лучше остальных вариантов. Такие кванты могут конвертироваться на лету через ключ -rtr при загрузке модели, но это отключает mmap. Можно их переконверитровать и сохранить результат, либо немного готовых есть у https://huggingface.co/ubergarm. Но это для совсем энтузиастов, которые хотят выжать максимум из минимального объема, и которые не боятся компиляции и консоли, так как ik_llama не предоставляет готовые бинарники.
https://openrouter.ai/meta-llama/llama-4-scout:free
https://openrouter.ai/meta-llama/llama-4-maverick:free
Регистрация на openrouter не замороченная, пускает любую почту, в поиске просто ввести free и будет много новинок, которые можно протестировать, в том числе и через API.
Например, интересный новый мердж двух моделей R1 и V3-0323:
https://openrouter.ai/tngtech/deepseek-r1t-chimera:free
Или неизвестная новинка от DeepSeek под названием Prover V2:
https://openrouter.ai/deepseek/deepseek-prover-v2:free
Так энтузиасту с 4090 достаточно добавить одну 5060 ti 16гб, чтобы вмещать 72B IQ4_XS полностью в vram.
А 5090 + 16гб открывает доступ к 123B моделям (Large 2 123B или Command A 111B).
Не, не будет. Это будет на порядок медленнее чем на любом CPU, на практике "видео-своп" дичайшие тормозит и все рекомендуют его отключать, чтобы случайно не залезть в него.
Падение на 70B моделях с 2 t/s до 0.01 t/s.
Еще со времен первой MoE модели, которую Mistral представили 2 года назад, это не так.
У них была Mixtral-8x7B размером 46.7B и она показывала себя сильно лучше 30B тех времен, модель обходила Llama2-70B и конкурировала с chatgpt-3.5.
После этого MoE шагает по планете, включая проприетарные модели, вроде Grok, Gemini и по слухам gpt-4o.
Для энтузиастов сейчас есть такие локальные MoE:
Llama 4 Scout - размер 109B, скорость 20 t/s, большой запас по скорости. Хватит 8гб gpu.
Llama 4 Maverick - размер 402B, скорость 19 t/s. Хватит 12гб gpu.
Qwen3-235B-A22B - размер 235B, скорость 4.5-6.5 t/s.
DeepSeek V3/R1 - размер 671B, скорость 2-3 t/s.
Граница комфортного использования это где-то 5 t/s.
Детали не так важны, главное, что энтузиасты дома не заперты на 30B моделях и никогда не были. До этого была отличная MoE модель Mixtral 8x22b и её отличный файнтюн WizardLM-2.
Душные детали. Почему MoE быстрое и большое, а Dense тяжелое. Параметры запуска для ускорения
MoE модели не монолитны, они состоят из отдельных экспертов и на вычисление каждого токена на каждом шагу задействуется только часть экспертов. На каждом шагу MoE-роутер выбирает какие эксперты будут задействованы для следующего токена, они могут быть как разными, так и совпадать какое-то время, и на каждом шагу работает только ограниченное число экспертов, поэтому модель работает в разы быстрее, чем Dense модель такого же размера.
В теории Dense модели такого же размера будут лучше, но на практике это не всегда так. Был пример Dense модели Llama 3.1 размером 405B, она выступала не сильно лучше, и даже хуже, чем модель Llama 3.3 70B.
Ускорение для MoE можно достигнуть выгрузив тензоры всех экспертов в GPU, всех кроме тяжелых ffn тензоров, это делается через команду: -ot exps=CPU или --override-tensor "([0-9]+).ffn_.*_exps.=CPU"
Архитектура MoE бывает разной, например, Llama 4 имеет общих экспертов, и так как общие эксперты участвуют в вычислении токена на каждом шагу, то выгрузка тензоров дает хорошее ускорение, так как общие эксперты всегда в быстрой видеопамяти.
У Qwen3 нет общих экспертов, поэтому тут не получится получить стабильное ускорение, но можно выгрузить столько экспертов, сколько влезает через команду: -ot blk.(1[2-9]|[2-8][0-9]|9[0-3]).ffn.*=CPU
Команда указывает, что первые 11 экспертов пойдут на GPU, а остальные 82 на CPU. Тут обычное регулярное выражение, 11 слоев рассчитаны на 24гб vram.
Если несколько видеокарт, можно тензоры раскидать по устройствам:
Это работает и на обычной llama.cpp, но так как много тензоров остаются на CPU, полезно будет взять ik_llama, откуда и пришли все эти оптимизации с override-tensor - это форк llama.cpp который затачивается на оптимизации работы на CPU, улучшенные кванты, которые конвертируются на лету из обычных, и немного ускоряет GPU.
В командную строку нужно добавить параметры: -fmoe -amb 512 -rtr
-rtr параметр который запускает автоматическую конвертацию модели в улучшенный квант от ik_llama, но он отключает mmap (если mmap включен и модель не влезла в память, она будет загружаться с диска), поэтому модель будет загружаться сразу в память и памяти должно быть достаточно.
-ngl сколько выгрузить слоев на gpu.
Подробнее про значение всех команд: https://github.com/ikawrakow/ik_llama.cpp/discussions/258
Благодаря оптимизациями от ik_llama, то, например, Maverick 402B если запускать его через ik_llama.cpp, то на 32k контексте скорость с 19 t/s падает всего до 15 t/s, при расходе видеопамяти 14гб.
Пример полного запуска
Если у вас больше 1 GPU, то будет ошибка при выгрузке всех возможных слоев через -ngl 95 и придется снизить её до 93-94. Это снизить скорость генерации, поэтому лучше собрать ik_llama добавив DGGML_SCHED_MAX_COPIES=1 (по умолчанию 4):
У https://huggingface.co/ubergarm/ есть кванты заточенные под ik_llama, включая команды запуска и другие подробности.
В их карточке модели или на их гитхабе, указаны только эти два, других видимо нет.
Есть принудительное отключение мышления через флаг, чтобы даже пустых размышляющих тегов не было, но это делается через шаблон чата jinja, а не через управляющие токены.
Там же рекомендуют отключить "rotating context management" через флаг
--no-context-shift, чтобы размышляющие токены не вытеснялись во время генерации, пока размышление не будет завершено, и модель не уходила в бесконечный цикл размышлений или не снижалось качество размышлений.Зацикливание - это частая проблема шаблона чата или плохих квантов.
В данном случае была проблема с шаблоном чата в llama.cpp и следовательно во всех производных, вроде ollama и LM Studio, и все кванты испорчены. Меньше суток назад это исправили, нужно обновить софт и перекачать кванты.
https://www.reddit.com/r/LocalLLaMA/comments/1kaodxu/qwen3_unsloth_dynamic_ggufs_128k_context_bug_fixes/
Запустить можно хоть с nvme на домашнем ПК, для больших MoE это сейчас частое явление набирающее популярность. Всё упирается в скорость работы, и тут нет простого ответа. Если модель влезает в VRAM - всё будет очень быстро.
Цифра рядом с B это в среднем и есть количество памяти, то есть 32B будет требовать 32гб памяти в кванте не отличимом от оригинала (Q6 или Q8). Но если нужен размер точнее, то зайдя в карточку gguf версии модели, все размеры будут указаны:
В gguf файл спроектирован так, что он повторяет структуру памяти и просто мапятся в память как есть, поэтому размер файла будет равен размеру занимаемому памяти. Сверх этого места нужно сколько гб на контекст. Чем больше контекст, тем больше ГБ нужно. Для 128k может потребоваться в 2 раза больше размера самой модели. Контекст тоже можно квантовать и использовать flash attention и скользящее окно.
Q6 и Q8 это часто избыточные кванты для больших моделей, типичные кванты которые считаются близким к оригиналу это Q4_K_M или Q5_K_M, или если памяти впритык, то IQ4_XS.
I-кванты это квантование через матрицу важности imatrix, они обычно точнее, чем K-кванты, поэтому могут выдавать тоже качество с меньшим размером, но требуют в ~2 раза больше вычислительных мощностей при выполнении, весят меньше, поэтому они могут помочь засунуть модель в память, когда Q4_K_M никак не влезает.
На практике, чем больше модель, тем меньше шансов, что она влезет в железо, и тем легче она переносит квантование, поэтому появился вариант UD квантов, это динамическое квантование от Unsloth.
Такие кванты можно брать и UD-IQ3 и даже UD-IQ2 - они будут хуже, чем Q4_K_M, но за счет нового подхода они выступают на достойном уровне, даже 1.58 битные версии.
Забыл добавить в статью, что переключаться между режимом размышления и без размышления нужно тегами
/thinkи/no_thinkв системном промпте, либо прямо в тексте.Запрос без размышлений, в системной промпте указал
/no_think, что делает этот тег по умолчанию для всего, блок размышлений создается, но он пустой:После этого, несмотря на системный промпт, можно послать запрос на размышление через
/think, и блок с размышлениями заполняется:Если вы качали UD - динамические кванты, они сейчас сломаны, работают только Q6 и Q8.
Пока протестировал Qwen3-30B-A3B-Q6_K, он работает нормально.
Как будто бы кому-то вообще не наплевать, что там за маркетинговый мусор сняла или сгенерировала microsoft.
Поддерживает под линуксом.
Обычно для винды для всех популярных проектов есть amd rocm форк, включая поддержку многострадальных rx 6600 и 6700, Forge не исключение:
https://github.com/likelovewant/stable-diffusion-webui-forge-on-amd
Для тех, у кого вообще нет желания что-то скачивать и запускать, но есть желание потыкать старые игры, есть эмулятор js-dos в браузере через wasm, и есть разные сайты, позволяющие это запускать.
Например, на этом сайте собраны различные русские версий игр: https://dos.zone/ru/
Сразу есть и виртуальное управление для игры с мобильных устройств:
Максимальная сейчас это maverick 400B, behemoth 2T они не выложили.
Регистрируетесь в openrouter.ai, работает и на временную почту, ищете там free модели через поиск написав "free" и используете через api (например, через клиент https://msty.app/ или любой другой поддерживающий openai completion api), либо у них есть чат на сайте.
https://openrouter.ai/meta-llama/llama-4-maverick:free
Доступны и другие free модели, включая новую Gemini 2.5 pro, которая на данный момент является рекордсменом по удержанию длинного контекста.
https://openrouter.ai/google/gemini-2.5-pro-exp-03-25:free
Если без регистрации:
на https://lmarena.ai/ в разделе Direct Chat или side-by-side уже добавили maverick, там можно сравнить разные модели.
На deepinfra всегда добавляют новинки, но лимиты лютые.
Зачем вы кидаете ссылку на статью, которую вы, видимо, сами не читали, и в которой написано ровно то, что я вкратце написал? Там даже картинками все проиллюстрировано. Единственное, чего там нет, это разницы между pp и tg, но это не так важно.
Микс экспертов (MoE) пришел намного раньше появления рассуждающих моделей. Первая MoE модель Mixtral-8x22B появилась еще год назад, когда даже техники CoT не было, не то, что рассуждающих моделей.
То, как вы описываете MoE не соответствует действительности. MoE работает точно так же как Dense, они по кругу гоняют выходной слой отправляя его в первый слой.
В MoE на каждом новом шагу выходной вектор подается на вход модели, и обученный маршрутизатор (Gating Mechanism) находит признаки в этом векторе, выдает веса вероятностей, которые соответствуют каждому эксперту, после этого выбирается Top-K экспертов, которые и будут активированы для этого шага цикла вычисления одного токена, и дальше снова по кругу как в Dense моделях.
Тут нет никаких разбивок вопроса внутри, никаких перепроверок и никаких внутренних диалогов. MoE это способ масштабировать модель, а не про внутренние диалоги экспертов.
MoE позволяет выдавать качество 140B моделей, работая при этом со скоростью моделей 17B, но повышая требования к памяти до 400B модели. Когда у вас нет проблем с железом, как не распараллеливай, запуская монолитную 400B вы не получите быстрый скоростей, а скорость это важно для всяких chatGPT сервисов.
И сам термин "рассуждающие модели" многими понимается не правильно. Это не способ модели размышлять, из-за чего и появляются различные неправильные выводы о том, что "модель не все этапы размышления показывает", это способ масштабировать модель снизив требования к этапу обучения, что равносильно повысить качество модели оставив обучение на том же уровне.
Ошибка модели зависит от 3 факторов:
вычисляемая мощность обучения
размер датасета
количество параметров
Сейчас временно уперлись во все 3 фактора. Например, нельзя просто наращивать размер модели не увеличивая размер датасета (модель llama 3.3 70B примерно равна по качеству llama 3.1 405B). Или из-за нехватки данных для обучения нельзя просто увеличивать количество шагов/эпох обучения - будет переобучение. И так далее.
Выходом стало масштабировать 4 фактор - увеличить мощность предсказания модели (test-time compute).
Смысл тут в том, что модель набрасывает несколько ответов, и видя эти ответы может оценить их качество своим стандартным механизмом self-attention, который одинаков для Dense (QwQ-32B) и для MoE (R1), тем самым отбросить ошибочные варианты.
Этот эффект пользователи уже давно могли наблюдать через механизм "А если подумать?". Когда первый раз модель отвечает не правильно, но если её попросить подумать над ответом, то второй или третий будут уже правильными.
И тут важен не сам фактор размышления в стиле мыслей, это просто красивая обертка, важен сам факт того, что модель получает черновые ответы и она через attention может оценить их качество, прежде чем выдать финальный ответ.
Диалоги длились по 5 минут, но не особо насыщенные.
Полные стенограммы всех диалогов выложены тут: https://osf.io/jk7bw/files/osfstorage
в файле tt_message_anonymized.csv