Было бы очень интересно почитать про запуск 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 раза меньше. И ещё немного на буфер.
Слои выгружают на 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. В чём вообще сложность понимания? В какой части этого процесса? Может так проще будет добраться до истины.
У вас тогда вопрос, не за счет чего 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 больше видеопамяти, чем есть на самом деле, и уже сама ОС гоняет туда сюда память. Но в таком режиме скорость проседает на порядок.
Не память GPU простаивает, а GPU простаивает. А память просто расходуется впустую.
В Dense моделях вычисление каждого тензора вносит вклад в общее ускорение. У Dense, что в такой конфигурации:
Что в такой:
Количество вычислений одинаково, в обоих случаях будет вычислено 20 блоков тензоров. У Dense все эти прямоугольники являются одним сплошным блоком, но суть та же.
Теперь MoE. Светло серым это эксперты, которые будут пропущены. В режиме переноса слоев будет вычислено всего 8 блоков, вместо 20. GPU забита на все 24 Гб, но она большую часть времени простаивает. Только в реальной модели серых блоков 128, из которых только 4 вычисляются, а выгружено 12 из 37 слоев.
Но перераспределить выгружаемые тензоры так:
И теперь GPU вычисляет все 20 блоков, а не 8. Теперь GPU не простаивает. Бонусом снижение расхода памяти, так как теперь на GPU выгружены только те тензоры, которые действительно всегда работают.
Нет, cmoe не определяет сколько надо выгрузить на GPU, он меняет то, что будет выгружено на GPU. Там на картинках я попытался изобразить разницу.
В первом случае выгружены целые слои, зеленым отмечены те 2 слоя, которые влезли на GPU. Огоньком отметил экспертов которые будут задействованы. Видно что огоньков всего 2, остальные 126 эксперта слоя просто впустую занимают видеопамять.
Во втором случае эксперты те же, слои те же, но теперь слои не отмечены зеленым, так как теперь на GPU выгружены не целые слои, а выгружены все блоки Attention, которые отмечены зеленым.
Теперь вместо того, чтобы GPU простаивала большую часть времени, а её видеопамять используется лишь на 4%, с новым способом GPU работает 100% времени прохода, и занимаемая память используется на 100%.
Хороший вопрос. Но думаю результат будет отрицательный, 20B слишком большая модель для черновика, слишком много памяти уйдет на неё.
Для спекулятивного декодирования нужны параллельные запросы, по сути --parallel N, позволяющий одной моделью пользоваться сразу многим. Но на процессоре не легко параллелить запросы, особенно MoE, мало ядер, а из памяти нужно подгружать разных экспертов для одного цикла. И то, как реализовано спекулятивное декодирование в llama.cpp, оно реализовано не идеально, много потерь, много скипов.
Но можно проверить, чтобы убедиться. В обоих случаях подбираю параметры, чтобы занимаемая видеопамять была 24гб.
Без черновика (-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
Нет, из картинки это не следует, потому что в обоих случаях 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 и стало быстро, поэтому и картинка такая.
Ryzen AI Max+ 395 (Strix Halo) уже давно на озонах продается по 180-190к на 128гб. Но смысл в такой скорости памяти (256 Гб/с теоретическая, 210 Гб/с реальная) за такую сумму как-то теряется. Да и 128гб (из которых доступны под инференс 96гб под виндой или 111гб под линуксом, через GTT), это мало, даже новый MiniMax-M2 уже будет трудно запустить, не говоря уже о DeepSeek R1/V3.1.
Сейчас большие модели запускают по другому, на небольшом объеме быстрой VRAM и большом объеме RAM. Например, для запуска GPT-OSS-120B с нормальным контекстом хватит 8 Гб GPU (чем больше VRAM, тем больше ускорение) и 64 Гб DDR4, но лучше DDR5. AMD карточки тоже подойдут, всё работает и через Vulkan тоже.
Да, -cmoe это просто алиас для -ot exps=CPU, поэтому логика работы с overide-tensor остается той же, и-ot "blk.[0-8].ffn.*=CUDA0" работает как и должен.
А перенос вручную на CUDA0 + cmoe упрощены до одного параметра -ncmoe N, который по сути тоже просто алиас такой записи, только слои с конца переносит, так как первые слои иногда бывают общими, и указывать их смысла нет.
Попробовал 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.
на М40 с 24 ГБ - пожалуй, самой доступной видеокарте с таким объёмом памяти? И... какой будет скорость её работы? Игра стоит свеч?
Tesla M40 это древняя карта с очень старой CUDA и медленной памятью (288 Гб/с), без поддержки flash attention и без нормального охлаждения. Среди Tesla имеет смысл смотреть разве что на Tesla v100 32gb.
На данный момент самая доступная карта по объему памяти и цене это AMD Instinct Mi50 32gb. Карточка 2018 года, память очень быстрая (1044 Гб/с), но тоже без нормального охлаждения. Запускать через Vulkan, а не CUDA, поддержка в llama.cpp уже есть.
Но все эти серверные карты это такая категория, где нужно быть готовым к различным нюансам, вроде нерегулируемых вентиляторов и потребления в простое, что не делает их простыми для домашнего использования.
Сейчас есть совсем другой способ запускать тяжелые LLM с нормальной скоростью, хватит обычной десктопной видеокарты, но нужно много RAM, что купить проще, чем много VRAM.
Кстати, а какую самую ёмкую модель Llama возможно запустить
Llama немного устарели, поэтому их запускают только ради бенчмарков. Сейчас в основном всем интересна новая OpenAI GPT-OSS-120B. Её можно запустить на скорости выше 10 t/s на домашнем ПК с обычной видеокартой, и даже на AMD, но нужно 64 Гб ОЗУ.
Может что-то изменилось, но год назад я не мог найти ни одной текстовой модели, которая в 12 ГБ vram влезала и давала бы хотя бы более-менее связные ответы на простейшие вопросы
Ну вообще да, изменилось, Dense модели стали заменяться MoE моделями. В 12 Гб VRAM теперь можно засунуть тяжелые модели.
Не, там речь про другое. llama.cpp отделили движок и ядро ggml, бэкенд ML отвечающее за всю работу gguf. В ollama раньше использовали код llama.cpp, а сейчас, когда ggml отделен, они используют движок ggml, а саму ollama переписали на go, старый код остается для совместимости. Речь вот эти движки.
У меня лично i5-13400F, 64 ГБ ОЗУ, RTX3050 8 ГБ, мне этого хватает для комфортного использования GGUF-моделей размером 8B, 9B, 13B Если нужны более крупные и серьёзные модели, то уже нужна видеокарта с куда более объёмной видеопамятью. Не, можно и в ОЗУ, но быстродействие будет ужасным, проверено на 20B-моделях.
На 20B да, не получится, а вот 120B самое оно. У вас хватает RAM и VRAM, чтобы запускать GPT-OSS-120B со скоростью выше 10 t/s.
Для примера запуск GPT-OSS-120B на Ryzen 5600, 64 Гб DDR4 3600 и AMD RX6600 8 Гб. Скорость генерации 13 t/s, и под контекст и под систему остается память. Видеокарта примерно того же уровня как 3050, только AMD работает через Vulkan, что медленнее чем CUDA.
На данный момент нет, хотя сам функционал override-tensors доступен уже больше полугода, cmoe и ncmoe это просто удобные алиасы, чтобы не заниматься регулярными выражениями.
В ollama сказали, что не хотят давать пользователям вручную настраивать это, хотят чтобы автоматически работало, но решения не предлагают: https://github.com/ollama/ollama/pull/12333
Kimi-Linear-48B-A3B рассчитана на ПК с 32 Гб ОЗУ и небольшой видеокартой, fp16 не имеет смысла. Эта экспериментальная модель для проверки новой архитектуры с гигантским контекстом, в неё не особо сильно вкладывались в обучение, использовали всего 5.7T токенов, для сравнения у Qwen3-30B-A3B-2507 было 36T. Это, конечно, не главный показатель, но не стоит слишком многого заранее ждать от модели.
Не совсем понятно, что вы именно подразумеваете под разумно. Нет способа выделить экспертов, которые понадобятся для вычисления на этом шагу, поэтому MoE никак не получится разгрузить эффективно, только попытаться снизить издержки.
Разумно разместить через --cpu-moe и --n-cpu-moe, так, как и описано в статье, она же как раз про это. Чтобы GPU максимально использовалась, для этого в первую очередь выгрузить общие параметры на GPU, которые нужны на каждом слое, а дальше уже всё остальное, на сколько хватит памяти.
По сути ничего специфичного, как только поддержку в llama.cpp доделают, то запускать её можно будет точно так же, как и все MoE модели.
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_01.2 Гб. Соответственно, на полные 128к нужно в 2 раза больше памяти, а на 32к в 2 раза меньше. И ещё немного на буфер.Слои выгружают на GPU, а не на CPU. Модель сначала грузится целиком в RAM, а уже потом выгружается на GPU. Но за счёт mmap этот процесс выглядит немного по другому, моментальный мапинг файла на память и сразу же выгрузка на GPU.
Работа модели, это умножить каждый квадратик-тензор внутри слоя на входную матрицу, меняя эту матрицу. Все тензоры статичны, меняется только входная матрица. Она проходит сквозь слои и на выходе получается новый токен.
Вот условно команда:
llama-server -m model.ggufВсе 15 слоев загружены на CPU и скорость 10 t/s.
Теперь указываем через ngl сколько слоев надо выгрузить на GPU:
llama-server -m model.gguf -ngl 55 слоев выгружено на GPU, 10 слоев на CPU, скорость 30 t/s
CPU работает медленно, GPU быстро. Ускорение за счет того, что часть вычислений перенесли на GPU. В чём вообще сложность понимания? В какой части этого процесса? Может так проще будет добраться до истины.
У вас тогда вопрос, не за счет чего 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 больше видеопамяти, чем есть на самом деле, и уже сама ОС гоняет туда сюда память. Но в таком режиме скорость проседает на порядок.
Не память GPU простаивает, а GPU простаивает. А память просто расходуется впустую.
В Dense моделях вычисление каждого тензора вносит вклад в общее ускорение. У Dense, что в такой конфигурации:
Что в такой:
Количество вычислений одинаково, в обоих случаях будет вычислено 20 блоков тензоров. У Dense все эти прямоугольники являются одним сплошным блоком, но суть та же.
Теперь MoE. Светло серым это эксперты, которые будут пропущены. В режиме переноса слоев будет вычислено всего 8 блоков, вместо 20. GPU забита на все 24 Гб, но она большую часть времени простаивает. Только в реальной модели серых блоков 128, из которых только 4 вычисляются, а выгружено 12 из 37 слоев.
Но перераспределить выгружаемые тензоры так:
И теперь GPU вычисляет все 20 блоков, а не 8. Теперь GPU не простаивает. Бонусом снижение расхода памяти, так как теперь на GPU выгружены только те тензоры, которые действительно всегда работают.
Нет, cmoe не определяет сколько надо выгрузить на GPU, он меняет то, что будет выгружено на GPU. Там на картинках я попытался изобразить разницу.
В первом случае выгружены целые слои, зеленым отмечены те 2 слоя, которые влезли на GPU. Огоньком отметил экспертов которые будут задействованы. Видно что огоньков всего 2, остальные 126 эксперта слоя просто впустую занимают видеопамять.
Во втором случае эксперты те же, слои те же, но теперь слои не отмечены зеленым, так как теперь на GPU выгружены не целые слои, а выгружены все блоки Attention, которые отмечены зеленым.
Теперь вместо того, чтобы GPU простаивала большую часть времени, а её видеопамять используется лишь на 4%, с новым способом GPU работает 100% времени прохода, и занимаемая память используется на 100%.
Хороший вопрос. Но думаю результат будет отрицательный, 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
Нет, из картинки это не следует, потому что в обоих случаях 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 и стало быстро, поэтому и картинка такая.
GPT-OSS-120B весит 61гб, она не влезает полностью на GPU в обоих случаях.
Ryzen AI Max+ 395 (Strix Halo) уже давно на озонах продается по 180-190к на 128гб. Но смысл в такой скорости памяти (256 Гб/с теоретическая, 210 Гб/с реальная) за такую сумму как-то теряется. Да и 128гб (из которых доступны под инференс 96гб под виндой или 111гб под линуксом, через GTT), это мало, даже новый MiniMax-M2 уже будет трудно запустить, не говоря уже о DeepSeek R1/V3.1.
Сейчас большие модели запускают по другому, на небольшом объеме быстрой VRAM и большом объеме RAM. Например, для запуска GPT-OSS-120B с нормальным контекстом хватит 8 Гб GPU (чем больше VRAM, тем больше ускорение) и 64 Гб DDR4, но лучше DDR5. AMD карточки тоже подойдут, всё работает и через Vulkan тоже.
Вот тут подробнее: Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Да,
-cmoeэто просто алиас для-ot exps=CPU, поэтому логика работы с overide-tensor остается той же, и-ot "blk.[0-8].ffn.*=CUDA0"работает как и должен.А перенос вручную на CUDA0 + cmoe упрощены до одного параметра
-ncmoe N, который по сути тоже просто алиас такой записи, только слои с конца переносит, так как первые слои иногда бывают общими, и указывать их смысла нет.Зависит от репозиториев. В manjaro есть пакет llama.cpp-cuda, в других не знаю.
Но проще вручную собрать: https://github.com/ggml-org/llama.cpp/blob/master/docs/build.md#cuda
Вам нужно скачать 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 определились правильно:
Вы скорее всего скачали cpu версию, а не cuda. Вот запустил на AMD RX 6600 8 Гб + 64 Гб DDR4, на такой слабой карточке и DDR4-3600 выдает 13 t/s:
Так и должно быть, Gemma3 это Dense модель, а ускорение через
-cmoeработает только для MoE моделей. У Dense все параметры модели общие, для каждого шага нужны все, поэтому перераспределение тензоров ничего не даст. Смысл-cmoeв том, чтобы загрузить GPU работой всегда, а не только когда удачно выпадут эксперты, чего они в принципе не сделают, так как из 128 активированы только 4.Ускорить Dense модель можно только спекулятивным декодированием, по крайней мере на данный момент. Например, добавление в качестве черновой модели Gemma3 1B ускоряет Gemma3 27B с 36 t/s до 54 t/s.
Tesla M40 это древняя карта с очень старой CUDA и медленной памятью (288 Гб/с), без поддержки flash attention и без нормального охлаждения. Среди Tesla имеет смысл смотреть разве что на Tesla v100 32gb.
На данный момент самая доступная карта по объему памяти и цене это AMD Instinct Mi50 32gb. Карточка 2018 года, память очень быстрая (1044 Гб/с), но тоже без нормального охлаждения. Запускать через Vulkan, а не CUDA, поддержка в llama.cpp уже есть.
Но все эти серверные карты это такая категория, где нужно быть готовым к различным нюансам, вроде нерегулируемых вентиляторов и потребления в простое, что не делает их простыми для домашнего использования.
Сейчас есть совсем другой способ запускать тяжелые LLM с нормальной скоростью, хватит обычной десктопной видеокарты, но нужно много RAM, что купить проще, чем много VRAM.
Llama немного устарели, поэтому их запускают только ради бенчмарков. Сейчас в основном всем интересна новая OpenAI GPT-OSS-120B. Её можно запустить на скорости выше 10 t/s на домашнем ПК с обычной видеокартой, и даже на AMD, но нужно 64 Гб ОЗУ.
Вот тут подробнее: Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Llama тоже можно так запустить, относительно свежая и большая Llama-4-Maverick на 402B запускается на 23 t/s.
Ну вообще да, изменилось, Dense модели стали заменяться MoE моделями. В 12 Гб VRAM теперь можно засунуть тяжелые модели.
Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Не, там речь про другое. llama.cpp отделили движок и ядро ggml, бэкенд ML отвечающее за всю работу gguf. В ollama раньше использовали код llama.cpp, а сейчас, когда ggml отделен, они используют движок ggml, а саму ollama переписали на go, старый код остается для совместимости. Речь вот эти движки.
На 20B да, не получится, а вот 120B самое оно. У вас хватает RAM и VRAM, чтобы запускать GPT-OSS-120B со скоростью выше 10 t/s.
Речь конечно про разницу между Dense и MoE моделями, и про специальный способ запуска для MoE. Вот тут подробнее: Ускоряем GPT-OSS-120B на домашнем ПК. Вам нужна RAM, а не VRAM. Новый параметр -cmoe для ускорения больших MoE LLM
Для примера запуск GPT-OSS-120B на Ryzen 5600, 64 Гб DDR4 3600 и AMD RX6600 8 Гб. Скорость генерации 13 t/s, и под контекст и под систему остается память. Видеокарта примерно того же уровня как 3050, только AMD работает через Vulkan, что медленнее чем CUDA.
Команда запуска:
.\llama-server.exe -m "D:\models\gpt-oss-120b-mxfp4-00001-of-00003.gguf" -ngl 99 -ncmoe 34 -c 16384 --jinjaНа данный момент нет, хотя сам функционал override-tensors доступен уже больше полугода, cmoe и ncmoe это просто удобные алиасы, чтобы не заниматься регулярными выражениями.
В ollama сказали, что не хотят давать пользователям вручную настраивать это, хотят чтобы автоматически работало, но решения не предлагают: https://github.com/ollama/ollama/pull/12333
Другой пользователь показал, где нужно сделать патч, чтобы это заработало, но это надо компилировать самостоятельно: https://github.com/ollama/ollama/issues/11772
Kimi-Linear-48B-A3B рассчитана на ПК с 32 Гб ОЗУ и небольшой видеокартой, fp16 не имеет смысла. Эта экспериментальная модель для проверки новой архитектуры с гигантским контекстом, в неё не особо сильно вкладывались в обучение, использовали всего 5.7T токенов, для сравнения у Qwen3-30B-A3B-2507 было 36T. Это, конечно, не главный показатель, но не стоит слишком многого заранее ждать от модели.
Не совсем понятно, что вы именно подразумеваете под разумно. Нет способа выделить экспертов, которые понадобятся для вычисления на этом шагу, поэтому MoE никак не получится разгрузить эффективно, только попытаться снизить издержки.
Разумно разместить через
--cpu-moeи--n-cpu-moe, так, как и описано в статье, она же как раз про это. Чтобы GPU максимально использовалась, для этого в первую очередь выгрузить общие параметры на GPU, которые нужны на каждом слое, а дальше уже всё остальное, на сколько хватит памяти.