Comments 60
Для VR где разрешение может достигать 4K на глаз как раз лучше больше VRAM иметь)
Даже без VR на больших разрешениях типа 11520×2160 или 23040×4320 нужно много VRAM, иначе в играх будет 1 fps. А ещё можно рендерить в 3D пакетах всякое 16K на GPU и тут тоже будет нужно много VRAM.
Но тут речь про LLM, а не графику. У меня OSS 120b выдает 11–16 токенов в секунду в зависимости от настроек, при этом карта забита под 0 и ничего другого в неё уже не влезет.
А описанный в статье способ, фактически, позволяет если не ускорить, то хотя бы одновременно загрузить дополнительно несколько моделей и переключаться между ними, не делая полной выгрузки и повторной загрузки. Например, комбинировать OSS120b с каким‑нибудь VLLM и SDXL.
вот же спасибо добрый человек. утащил в сохраненное
Из тех, которые пробовал, меня больше всего, по соотношению скорость-качество, устраивает gpt-oss-120b. На моём компьютере выдаёт 12 т/с при пустом контексте и при заполнении контектса до 32к - около 6 т/с. DeepSeek V3.1 работает, но скорость не более 1.5 т/с. Если качество не сильно нужно, то использую gpt-oss-20b, даёт до 40 т/с на пустом и около 12 т/с при 32к контексте.
Но я использую ik-llama.
Tesla P40, Xeon 2698 v3, RAM DDR4-2133 192GB
Обычно на ik_llama не должно быть такой просадки при увеличении контекста даже на P40, так как их основная особенность это сохранение производительности на огромном контексте.
Но так как речь идет про GPT-OSS, то ik_llama не лучший вариант для запуска, автор ik_llama решил не доводить поддержку SWA в GPT-OSS до конца.
Вообще, кванты, которые не созданы специально для ik_llama (то есть IQK кванты) я стараюсь запускать на ванильной llama.cpp. По ощущениям после длительного расхождения основной ветки и форка там как будто бы чаще проявляются какие-то разные проблемы для не родных квантов, особенно это проявляется в mxfp4, в котором и есть GPT-OSS.
Попробуйте протестировать ваш сценарий на оригинальной llama.cpp с включенным -cmoe.
Сегодня наконец-то собрал llama.cpp. Да, на самом деле на ней GPT-OSS работает быстрее. И главное нет просадки по токенам из-за контекста.
Особенно порадовала GPT-OSS-20В. Скорость 55-65 ток/сек, что для моего железа прям вообще супер. И как по моим ощущениям она работает на уровне GPT-3.5, а этого чаще всего более чем достаточно.
Вангую, что в следующем году появятся фермы -майнинга- AI GPU. Но тут нужно считать экономику
вот чего я не понял - как часто этот роутер переключает экспертов. Если на каждом токене, то это же надо постоянно загружать одних экспертов в VRAM, других выгружать. И это уже не вычисления будут, а бесконечная закачка RAM->VRAM. А если один раз загрузили VRAM и всё время там гоняем одних и тех же экспертов, то не понятно зачем тогда все остальные. Получается мы задействуем только 5% всей модели.
Допустим скорость псие 64 гб в сёк, если один эксперт весит 3 гб, то это 21 раз можно его загнать в секунду, что тоже не так и мало.
Чаще чем на каждом токене. 36 + 1 слоев, в каждом слое свой роутер и свои 128 экспертов, итого 36 роутеров и гора экспертов, прямой проход по нейросети активирует последовательно эти 36 роутеров и каждый выбирает по 4 эксперта своего слоя. И только проделав всё это генерируется 1 новый токен.
Работает за счёт того, что в 36 слоях 36 блоков внимания, за один проход нейросети надо рассчитать все 36 блоков. При активации -cmoe в VRAM загружены не эксперты, а эти тензоры внимания, эксперты же остались на CPU в обычной RAM.
Ускорение происходит за счёт того, что GPU теперь считает только тензоры внимания, а не разреженные слои с экспертами, из-за этого GPU постоянно ускоряет вычисления для каждого слоя, а в классическом варианте GPU бы простаивала как только прошли слои, которые были выгружены целиком.
можно на примере, который я прикидываю для себя? Новомодная Kimi-Linear-48B-A3B-Instruct : 48B параметров, из них активно 3B. допустим, квантование float 16, вся модель весит 96Гб. Активные компоненты всего 6Гб. Если взять одну 3090 24Гб, в ней влезет четверть модели. (Если взять две 3090 25 Гб уже половина модели влезет в VRAM). Как разумно разместить эту модель?
Kimi-Linear-48B-A3B рассчитана на ПК с 32 Гб ОЗУ и небольшой видеокартой, fp16 не имеет смысла. Эта экспериментальная модель для проверки новой архитектуры с гигантским контекстом, в неё не особо сильно вкладывались в обучение, использовали всего 5.7T токенов, для сравнения у Qwen3-30B-A3B-2507 было 36T. Это, конечно, не главный показатель, но не стоит слишком многого заранее ждать от модели.
Не совсем понятно, что вы именно подразумеваете под разумно. Нет способа выделить экспертов, которые понадобятся для вычисления на этом шагу, поэтому MoE никак не получится разгрузить эффективно, только попытаться снизить издержки.
Разумно разместить через --cpu-moe и --n-cpu-moe, так, как и описано в статье, она же как раз про это. Чтобы GPU максимально использовалась, для этого в первую очередь выгрузить общие параметры на GPU, которые нужны на каждом слое, а дальше уже всё остальное, на сколько хватит памяти.
Сейчас попробовал выгрузить часть экспертов на GPU
llama-server.exe --alias ggml-org_gpt-oss-120b --model "E:\LLM\ggml-org\gpt-oss-120b-GGUF\gpt-oss-120b-mxfp4-00001-of-00003.gguf" -ot "blk.[0-8].ffn.*=CUDA0" -cmoe -ngl 99 -c 32768 -b 2048 -ub 256 --threads 32 --jinja --host 0.0.0.0 --port 8080
В логах не нашёл, где бы это отразилось (в ik-llama это видно в логах загрузки). Но при генерации получил 30% прироста на модели GPT-OSS-120В.
Возник вопрос, на самом деле работает -ot "blk.[0-8].ffn.*=CUDA0" в llama.cpp этот ключ или у меня просто совпало так? В ik-llama он работает, это я проверял несколько раз.
Да, -cmoe это просто алиас для -ot exps=CPU, поэтому логика работы с overide-tensor остается той же, и-ot "blk.[0-8].ffn.*=CUDA0" работает как и должен.
А перенос вручную на CUDA0 + cmoe упрощены до одного параметра -ncmoe N, который по сути тоже просто алиас такой записи, только слои с конца переносит, так как первые слои иногда бывают общими, и указывать их смысла нет.
А можно такое повернуть с ollama?
На данный момент нет, хотя сам функционал override-tensors доступен уже больше полугода, cmoe и ncmoe это просто удобные алиасы, чтобы не заниматься регулярными выражениями.
В ollama сказали, что не хотят давать пользователям вручную настраивать это, хотят чтобы автоматически работало, но решения не предлагают: https://github.com/ollama/ollama/pull/12333
Другой пользователь показал, где нужно сделать патч, чтобы это заработало, но это надо компилировать самостоятельно: https://github.com/ollama/ollama/issues/11772
Можно ли так развернуть 120b на vllm? cpu inference не особо быстрый и не запускается с 120b
Вообще, на старте выпуска gpt-oss-120b (и ее меньшей версии), было очень много хейта. В основном уровня "ха-ха, смотрите, это зацензурено!". В реальности же получилась очень хорошая модель с неплохими знаниями, при этом достаточно быстрая. Пожалуй, на моем ноуте (4060 + 80гб рам) это самое лучшее, что можно запустить с приемлемой скоростью.
Автору спасибо за отличную статью и прекрасные трюки с подробным объяснением. llama.cpp сейчас пишется с такой быстрой скоростью, что не успеваешь разбираться, что же в нее нового запихали.
Попробовал unsloth/gemma-3-12b-it-GGUF на:
GPU: 1x RTX 5090
CPU: 48 Cores
Memory: 128 GB
Disk: 200 GB
Что без флагов 11t/s что с -c 32000 -ngl 99 -ub 4092 -b 4092 -ncmoe 25 11t/s, что с -c 32000 -ngl 99 -ub 4092 -b 4092 -cmoe 11t/s. вообще никакого влияния на производительность 🤷
Попробовал unsloth/gemma-3-12b-it-GGUF
вообще никакого влияния на производительность 🤷
Так и должно быть, Gemma3 это Dense модель, а ускорение через -cmoe работает только для MoE моделей. У Dense все параметры модели общие, для каждого шага нужны все, поэтому перераспределение тензоров ничего не даст. Смысл -cmoe в том, чтобы загрузить GPU работой всегда, а не только когда удачно выпадут эксперты, чего они в принципе не сделают, так как из 128 активированы только 4.
Ускорить Dense модель можно только спекулятивным декодированием, по крайней мере на данный момент. Например, добавление в качестве черновой модели Gemma3 1B ускоряет Gemma3 27B с 36 t/s до 54 t/s.
🤦 сорян, не ту модель скопировал в сообщение. Вот:
unsloth/gpt-oss-120b-GGUF - её использовал. Gemma 3 12b показывает гораздо выше t/s на такой карте.
Сейчас проверяю ту же OSS-120B на 3060. Надеюсь будет заметна разница в скорости. через полчаса-час скину результаты
Вы скорее всего скачали cpu версию, а не cuda. Вот запустил на AMD RX 6600 8 Гб + 64 Гб DDR4, на такой слабой карточке и DDR4-3600 выдает 13 t/s:
чуда не произошло ):
3.6 t/s при любых раскладах
GPU 1x RTX 3060
CPU 26 Cores
Memory 51.2 GB
Можете дать ссылку на cuda версию? не понимаю как отличить её от cpu на huggingface
Запускал как рекомендует сам huggingface
Вам нужно скачать 2 архива вот тут https://github.com/ggml-org/llama.cpp/releases
cudart-llama-bin-win-cuda-12.4-x64.zip
llama-b6942-bin-win-cuda-12.4-x64.zip
После этого разархивировать cudart в папку с llama.cpp. Проверьте при загрузке, что ваши GPU определились правильно:
У меня сервер на linux и я устанавливал llama.cpp через brew - это неправильный способ? о_О
Покопался в логах. Действительно дело в GPU. Буду копать в эту сторону. Спасибо!
~$ llama-server -hf lmstudio-community/gpt-oss-120b-GGUF --host 0.0.0.0 --port 8080 -c 32000 -ngl 99 -ub 4092 -b 4092 -ncmoe 25
warning: no usable GPU found, --gpu-layers option will be ignored
warning: one possible reason is that llama.cpp was compiled without GPU support
warning: consult docs/build.md for compilation instructions
Зависит от репозиториев. В manjaro есть пакет llama.cpp-cuda, в других не знаю.
Но проще вручную собрать: https://github.com/ggml-org/llama.cpp/blob/master/docs/build.md#cuda
Упомянутая Qwen3-4B-Instruct-2507 очень неплохо работает даже на смартфоне трехлетней давности с 8ГБ памяти :)
Первая картинка смущает. Как модель полностью на GPU может проигрывать модели частично выгруженной на CPU?
GPT-OSS-120B весит 61гб, она не влезает полностью на GPU в обоих случаях.
А из картинки следует, что переходите на (частичное использование) CPU (вместо GPU) и получите прирост в скорости.
Нет, из картинки это не следует, потому что в обоих случаях CPU используется на всю катушку. Вопрос только в том, является ли GPU дорогим хранилищем или нет. Из картинки следует то, что из этих 24Гб эффективно использовались только 1-2Гб, а остальные были просто дорогим хранилищем, и cmoe позволяет перестать в холостую занимать VRAM, и правильно занятые 3Гб дадут большую скорость, чем было.
В первом случае без cmoe мы выгружаем 24гб на GPU стандартным способом и получаем 18 t/s, во втором случае мы делаем умную выгрузку на GPU через cmoe, снижаем расход VRAM до 3 Гб и получаем 24 t/s.
В статье же подробное объяснение как это работает, и почему вначале модель занимала 24Гб VRAM и было медленно, а стало 3Гб VRAM и стало быстро, поэтому и картинка такая.
В первом случае без cmoe мы выгружаем 24гб на GPU стандартным способом и получаем 18 t/s, во втором случае мы делаем умную выгрузку на GPU через cmoe, снижаем расход VRAM до 3 Гб и получаем 24 t/s.
А можете ткнуть носом, где написано, за счет чего происходит прирост скорости?
Три раза прочитал статью, но так и не понял. Все что понял: cmoe определяет, сколько надо выгрузить на GPU. Этим мы управляем расходом VRAM. Это понятно.
Но почему при бОльшем использовании CPU мы получаем прирост в скорости - не понятно. По логике должно быть наоборот: CPU медленней + имеются дополнительные расходы на обмен данными между CPU и GPU.
Нет, cmoe не определяет сколько надо выгрузить на GPU, он меняет то, что будет выгружено на GPU. Там на картинках я попытался изобразить разницу.
В первом случае выгружены целые слои, зеленым отмечены те 2 слоя, которые влезли на GPU. Огоньком отметил экспертов которые будут задействованы. Видно что огоньков всего 2, остальные 126 эксперта слоя просто впустую занимают видеопамять.
Во втором случае эксперты те же, слои те же, но теперь слои не отмечены зеленым, так как теперь на GPU выгружены не целые слои, а выгружены все блоки Attention, которые отмечены зеленым.
Теперь вместо того, чтобы GPU простаивала большую часть времени, а её видеопамять используется лишь на 4%, с новым способом GPU работает 100% времени прохода, и занимаемая память используется на 100%.
Это не отвечает на вопрос за счет чего произошло увеличение скорости? Ну простаивает GPU память, ну и ладно...
Как использование медленного CPU и RAM увеличило скорость генерации?
Не память GPU простаивает, а GPU простаивает. А память просто расходуется впустую.
В Dense моделях вычисление каждого тензора вносит вклад в общее ускорение. У Dense, что в такой конфигурации:
Что в такой:
Количество вычислений одинаково, в обоих случаях будет вычислено 20 блоков тензоров. У Dense все эти прямоугольники являются одним сплошным блоком, но суть та же.
Теперь MoE. Светло серым это эксперты, которые будут пропущены. В режиме переноса слоев будет вычислено всего 8 блоков, вместо 20. GPU забита на все 24 Гб, но она большую часть времени простаивает. Только в реальной модели серых блоков 128, из которых только 4 вычисляются, а выгружено 12 из 37 слоев.
Но перераспределить выгружаемые тензоры так:
И теперь GPU вычисляет все 20 блоков, а не 8. Теперь GPU не простаивает. Бонусом снижение расхода памяти, так как теперь на GPU выгружены только те тензоры, которые действительно всегда работают.
все равно не понятно откуда увеличение скорости :)
Поспрашивал в чатиках тг. Мне объяснили так:
При обычной загрузки модели на GPU, если она целиком не влазит в GPU, то ллама.цпп динамически подгружает слои во время выполнения. Т.е. постоянно гоняет слои туда сюда.
А если мы принудительно разместим часть слоев на CPU то ничего гонять не нужно. Из-за этого и прирост. Хотя сама CPU конечно медленнее.
У вас тогда вопрос, не за счет чего MoE с cmoe быстрее, а про то, как вообще работает классическое ускорение в llama.cpp при комбинации GPU + CPU.
Допустим нужно 100 вычислений на генерацию 1 токена.
GPU делает 8 вычислений и 92 на CPU.
GPU делает 20 вычислений и 80 на CPU.
Какой вариант будет быстрее? GPU считает быстрее, чем больше операций влезло на GPU, тем лучше. Операции можно производить только над тензорами, которые находятся в прямом доступе, на GPU над теми, что в VRAM, на CPU над теми что в RAM.
Остальное будет рассчитано на CPU. За счёт того, что сколько-то удалось перенести на GPU, за счёт этого и ускорение.
llama.cpp это единственный бэкэнд который вообще позволяет разделить вычисления на CPU + GPU, во всех остальных это либо GPU, либо CPU.
Но никто ничего не подгружает динамически, особенно llama.cpp. Слои или тензоры один раз загружают и больше не гоняются туда сюда во время выполнения. Часть вычислений проводиться на GPU, та часть которая загружена в VRAM, а оставшаяся часть вычисляется на CPU.
Единственный вариант, когда они туда сюда гоняются, это когда используется shared память Windows, которая делает вид, что у GPU больше видеопамяти, чем есть на самом деле, и уже сама ОС гоняет туда сюда память. Но в таком режиме скорость проседает на порядок.
У вас тогда вопрос, не за счет чего MoE с cmoe быстрее, а про то, как вообще работает классическое ускорение в llama.cpp при комбинации GPU + CPU.
Мне в том же чатике сказали и для денс модели можно часть слоев принудительно выгрузить на CPU. Т.е. эта техника не только для MoE применима.
Никто ничего не подгружает динамически, особенно llama.cpp. Слои или тензоры один раз загружают и больше не гоняются туда сюда во время выполнения. Часть вычислений проводиться на GPU, та часть которая загружена в VRAM, а оставшаяся часть вычисляется на CPU.
Если это верно, то тогда снова не понятно за счет чего получается прирост...
Слои выгружают на GPU, а не на CPU. Модель сначала грузится целиком в RAM, а уже потом выгружается на GPU. Но за счёт mmap этот процесс выглядит немного по другому, моментальный мапинг файла на память и сразу же выгрузка на GPU.
Работа модели, это умножить каждый квадратик-тензор внутри слоя на входную матрицу, меняя эту матрицу. Все тензоры статичны, меняется только входная матрица. Она проходит сквозь слои и на выходе получается новый токен.
Вот условно команда:
llama-server -m model.gguf
Все 15 слоев загружены на CPU и скорость 10 t/s.
Теперь указываем через ngl сколько слоев надо выгрузить на GPU:
llama-server -m model.gguf -ngl 5
5 слоев выгружено на GPU, 10 слоев на CPU, скорость 30 t/s
CPU работает медленно, GPU быстро. Ускорение за счет того, что часть вычислений перенесли на GPU. В чём вообще сложность понимания? В какой части этого процесса? Может так проще будет добраться до истины.
Все понятно :) Непонятно почему вы изображаете обратно противоположную ситуацию :)
Возьмем ваш же пример (и немного его расширим | цифры условные):
15 слоев загружены на CPU. 0 слоев на GPU (память 0 Gb VRAM). Cкорость 10 t/s.
10 слоев загружены на CPU. 5 слоев на GPU (память 1 Gb VRAM). Cкорость 30 t/s.
(продолжим) 5 слоев загружены на CPU. 10 слоев на GPU (память 2 Gb VRAM). Cкорость 60 t/s.
И т.д.
Т.е. чем больше мы поместим слоев на GPU (и чем больше займем памяти VRAM) тем выше скорость. А у вас на первой картинке (в статье) показана обратная ситуация. Чем больше мы заняли памяти VRAM, тем МЕНЬШЕ скорость.
Не чем больше заняли VRAM, тем меньше скорость, а была скорость базовая и бездумно заполненная VRAM. Мы провели оптимизации и увеличили базовую скорость, бонусом снизили расход VRAM. Главное отличие Dense от MoE в том, как используются ресурсы GPU. MoE имеет разреженные слои, и важно, чтобы GPU не простаивала попадая в эти дыры.
Как это в живую выглядит. Вот сейчас на ПК не загружены модели, на фоне крутится видео, браузеры и так далее, поэтому 1 Гб VRAM уже занято.
Теперь загружаю GPT-OSS-120B классическим способом, выгрузим много слоев на GPU, сколько влезет в 24 Гб. Влезло 13 слоев из 37, количество слоев которые будут выгружены на GPU управляется параметром ngl.
CUDA_VISIBLE_DEVICES="0" ./llama-server -m "/home/shh/alpaka/models/gpt-oss-120b-mxfp4-00001-of-00003.gguf" -ngl 13 --jinja
Вся VRAM занята (23.6 Гб), скорость 16.2 t/s. Обычно слоями не получается заполнить прям впритык, так как размер слоя может быть больше объема свободной памяти.
Теперь применяю ту самую щепотку cmoe:
CUDA_VISIBLE_DEVICES="0" ./llama-server -m "/home/shh/alpaka/models/gpt-oss-120b-mxfp4-00001-of-00003.gguf" -ngl 99 -cmoe --jinja
Видимо, что занято VRAM теперь всего 4Гб, а скорость выросла до 23.2 t/s.
Если переключиться на встройку, то можно высвободить этот 1 Гб, и получить чуть лучшие скорости, но сути это не меняет. Prompt Eval Time это время подготовки промпта PP, так как тут он всего 75 токенов, то это работает моментально, а та скорость что отображена - это время подзагрузок, так как это первый запуск после загрузки.
Было занято 22.6 Гб и скорость была 16.2 t/s, а стало занято 3 Гб и скорость выросла до 23.2 t/s. Картинка именно эту ситуацию и отображает.
Классный материал, спасибо!
Вы не запускали (ну вдруг) в спекулятивном режиме oss-20b (драфт) + 120b + выгрузка экспертов для мастера?
Ps тот случай когда ссылка на ТГ канал нужна но её нет )
Хороший вопрос. Но думаю результат будет отрицательный, 20B слишком большая модель для черновика, слишком много памяти уйдет на неё.
Для спекулятивного декодирования нужны параллельные запросы, по сути --parallel N, позволяющий одной моделью пользоваться сразу многим.
Но на процессоре не легко параллелить запросы, особенно MoE, мало ядер, а из памяти нужно подгружать разных экспертов для одного цикла. И то, как реализовано спекулятивное декодирование в llama.cpp, оно реализовано не идеально, много потерь, много скипов.
Но можно проверить, чтобы убедиться. В обоих случаях подбираю параметры, чтобы занимаемая видеопамять была 24гб.
./llama-server -m "gpt-oss-120b-mxfp4-00001-of-00003.gguf" -fa 1 -ngl 99 -ncmoe 32 -c 8192 --jinja -md "gpt-oss-20b-mxfp4.gguf" -ngld 99 -ncmoed 0 --no-mmap
Без черновика (-ncmoe 24): 31.8 t/s
С черновиком: 23.5 t/s
Черновик на вторую GPU: 23.8 t/s
Скорость упала, даже если основная модель запущена с -ncmoe 24 как и без черновика, а черновик работает на второй GPU. Видимо как раз уперлось в CPU.
Для Dense на CPU ситуация получше, там можно вычислять для разных запросов одни и те же уже загруженные тензоры, но и тут упрется в количество ядер. Например, используем только 8 Гб VRAM, модели Qwen3-32B + Qwen3-1.7B. Ядер 8 больших + 12 малых.
Без черновика: 3.5 t/s
С черновиком 8 ядер: 4.4 t/s
С черновиком 20 ядер: 5.1 t/s
Спасибо за проверку.
Сейчас подумал и пришел к выводу что действительно, prefill этап быстрый и читая только один поток генерации черновика мастер будет большую часть времени простаивать занимая ценную vram, а при необходимости перехватить генерацию для 2+ потоках черновика шанс того что в памяти окажутся необходимые эксперты - небольшой, в итоге случится затык
Отличные статьи у Вас, спасибо!
Было бы очень интересно почитать про запуск Qwen3-Next-80B подобным образом или только на CPU.
Подскажите, выходит, что GPT-OSS-120B можно довольно эффективно крутить на 64ГБ RAM + 16ГБ VRAM, если критичные слои загрузить на видеокарту, а остальное в оперативную память? Как раз сама модель около 60ГБ + около 20ГБ остается на приличный контекст, ОС и прочее, верно?
Было бы очень интересно почитать про запуск Qwen3-Next-80B подобным образом или только на CPU.
По сути ничего специфичного, как только поддержку в llama.cpp доделают, то запускать её можно будет точно так же, как и все MoE модели.
выходит, что GPT-OSS-120B можно довольно эффективно крутить на 64ГБ RAM + 16ГБ VRAM, если критичные слои загрузить на видеокарту, а остальное в оперативную память? Как раз сама модель около 60ГБ + около 20ГБ остается на приличный контекст, ОС и прочее, верно?
20 Гб на контекст это много, контекст в 128к без квантования занимает всего 4.5 Гб.
В статью добавил пример запуска на Ryzen 5600g 64 Гб DDR4-3600 и AMD RX 6600 8Гб. У видеокарты медленная память 224 Гб/с, и нет ускоряющих ядер, всё работает через Vulkan, процессор не топовый, и DDR4 не самая быстрая, поэтому скорость 13.1 t/s, что для такой конфигурации очень даже хорошая скорость.
Всё влезло, память осталась и для ОС, так как то, что выгружено в VRAM будет освобождено в обычной памяти через mmap, и на видеокарте остался запас для дополнительного контекста.
У GPT-OSS внимание сделано на SWA, поэтому суммарно контекст занимает не так много места. На 64к контекста без квантования нужно 2.25 Гб, с квантованием -ctk q8_0 -ctv q8_0 1.2 Гб. Соответственно, на полные 128к нужно в 2 раза больше памяти, а на 32к в 2 раза меньше. И ещё немного на буфер.
Спасибо за ответ. Я так понимаю, Вы запускаете на базе ОС Windows. Читал, что на Windows производительность LLM существенно ниже, чем на Linux, так ли это? Подбираю конфигурацию ПК для инференса.
Во всех случаях одинаковый ncmoe или ngl. Результат со 2 замера, первый прогревочный. Там где full - модель целиком влезла на GPU.
В текстовом виде
GPT-OSS-120B
.\llama-bench.exe -m "D:\models\openai_gpt-oss-120b-MXFP4.gguf" -ncmoe 24 -ngl 99
Windows 10: PP = 202.89 t/s, TG = 21.49 t/s
Windows 11: PP = 303.42 t/s, TG = 24.44 t/s
Manjaro Linux: PP = 373.16 t/s, TG = 37.58 t/s
MiniMax M2
.\llama-bench.exe -m "D:\models\MiniMax-M2-UD-Q3_K_XL-00001-of-00003.gguf" -ncmoe 50 -ngl 99
Windows 10: PP = 71.65 t/s, TG = 10.61 t/s
Windows 11: PP = 101.02 t/s, TG = 11.65 t/s
Manjaro Linux: PP = 118.19 t/s, TG = 17.24 t/s
Qwen3-30B-A3B
.\llama-bench.exe -m "D:\models\Qwen3-30B-A3B-Instruct-2507-UD-Q4_K_XL.gguf" -ngl 99
Windows 10: PP = 6031.43 t/s, TG = 228.62 t/s
Windows 11: PP = 6597.88 t/s, TG = 240.00 t/s
Manjaro Linux: PP = 6974.54 t/s, TG = 248.14 t/s
Gemma3 27B
.\llama-bench.exe -m "D:\models\gemma-3-27b-it-UD-Q5_K_XL.gguf" -ngl 99
Windows 10: PP = 2992.65 t/s, TG = 41.38 t/s
Windows 11: PP = 2969.42 t/s, TG = 42.23 t/s
Manjaro Linux: PP = 3016.84 t/s, TG = 42.72 t/s
Mistral-Small-3.2-24B
.\llama-bench.exe -m "D:\models\Mistral-Small-3.2-24B-Instruct-2506-UD-Q4_K_XL.gguf" -ngl 99
Windows 10: PP = 3806.94 t/s, TG = 59.54 t/s
Windows 11: PP = 3833.66 t/s, TG = 60.33 t/s
Manjaro Linux: PP = 3877.24 t/s, TG = 60.76 t/s
Не гарантирую, что у вас будет такая же разница.
Более низкий результат на Windows 10 может быть связан с тем, что процессор с P-ядрами и E-ядрами i7-14700, и вроде как Windows 10 не умеет правильно управлять какие куда.
Поправка для GPT-OSS-120B под Windows 10.
Это всё на одинаковом железе? А какое железо?
Железо одинаковое, i7-14700 (без K и без F), DDR5-4800 4x48Гб, 4090.
Windows 11 свежая, Windows 10 с последними обновлениями, но давно с нуля не переустанавливалась и пережила смену множества железа, так что причина может быть и в этом.
Верно же, что замена памяти с 4800 на 6000 даст значительный прирост производительности инференса?
Зависимость tg линейна от скорости памяти. Разница между 4800 и 6000 в 20-25% по скорости памяти, было 72гб/с, стало 90 гб/с, было 10 t/s, стало 12 t/s.
Но в GPT-OSS-120B большую часть расчётов берет на себя видеокарта, так что прибавка скорости должна быть совсем незначительна от такого небольшого ускорения памяти CPU.
Не пробовали запускать GLM-4.6 на вашем железе? Если да, то сколько выдает t/s ?
GLM-4.6-UD-Q3_K_XL, -cmoe, занято VRAM 11Гб + контекст
Linux:
Windows 10:
Использование ncmoe не дает особого эффекта, так как модель слишком большая, -ncmoe 88, 23Гб
Более крупный квант GLM-4.6-Q4_K_S, который не влезает в 188 GiB, влезает за счёт разгрузки на GPU, -ncmoe 88
Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM