llama.cpp для самых маленьких

Базовый гайд по тому как пользоваться llama.cpp для запуска языковых моделей на домашнем ПК.

Прежде всего, нам нужна вся доступная видеопамять, поэтому посмотрите сначала сколько VRAM занято в вашей системе после загрузки Windows. У меня на Шиндошс 11 после загрузки занято 0.7 ГБ видеопамяти. Постарайтесь добиться схожих значений потому что каждый гигабайт тут на вес золото.
Что может жрать видеопамять? Весь софт который использует аппаратное ускорение для рендеринга своего окна — браузеры, Discord, Steam, что-либо еще. Выключайте аппаратное ускорение везде, гоните его, насмехайтесь над ним. Еще стоит выключить всякие оверлеи. Оверлей Nvidia, например, может отжирать до 2-х ГБ видеопамяти. Ну и в самой Винде есть настройки потребляющие видеопамять, всяческие прозрачности и анимации. "Мой компьютер" -> "Свойства" -> "Дополнительно" (не помню точно на самом деле в русской локали эта вкладка называется) -> "Производительность", и там такие опции .

Я эти визуальные эффекты минимизирую, оставляя только сглаживание шрифтов, и несколько других опций. Видеопамять вам в любом случае нужна, если не для нейросетей, то для игр, поэтому всегда полезно минимизировать ее расход всяким софтом.

Большинство языковых моделей по своему устройству можно разделить на Dense (далее "плотные") и Mixtre-of-Experts (МоЕ).

Плотные модели для генерации каждого следующего токена вынуждены полностью активировать все свои параметры. То есть, если файл модели весит условно 20 ГБ, то все эти 20 ГБ будут использоваться для вычисления каждого следующего токена. Это требует высокой пропускной способности между чипом который производит вычисления и чипом памяти в который загружены файлы модели. Поэтому когда веса модели полностью умещаются в видеопамять, плотная модель работает быстро, но если она не влезет в VRAM и часть весов "перельется" в оперативную память, то из-за относительно малой пропускной способности между видеокартой и оперативной памятью, возникнет бутылочное горлышко и скорость генерации упадет драматически.

Это сильно ограничивает использование плотных модедлей на среднем домашнем ПК, потому что на машинах с до 24 ГБ видеопамяти комфортно использовать можно только плотные модели размерами примерно до 12 млрд. параметров, и естественно, от моделей такого размера многого ожидать не стоит.

Я не вижу большого смысла использовать плотные модели на железе до 24 ГБ видеопамяти. Но чисто для иллюстрации, давайте найдем что-то на плотной архитектуре что влезет в 16 ГБ VRAM или менее.
Открываю https://huggingface.co - репозиторий в котором хранятся открытые модели. Пишу в поиске просто GGUF, чтобы отфильтровать модели в том формате который использует llama.cpp. И ограничиваю выбор моделями в диапазоне 6-12b, выбираю "Text Generation" в фильтрах чтобы убрать всякие модели генерации картинок или видео.

Вижу на первой строчке хайповую на данный момент модель — Ornith-1.5-9B-GGUF. Что это такое? Это дообученый Qwen3.5-9B. Открываю карточку модели, перехожу на вкладку Files и вижу такое:

Файлы выше README.md это веса модели "квантованные", то есть сжатые, в разных степенях сжатия. "mmproj" файл ниже — адаптер для работы зрения модели. Без его подключения модель сможет "понимать" только текст.
Что значит в разных степенях сжатия? Тут как с картинками или музыкой — есть lossless форматы (формат safetensors), a есть lossy (gguf в разных степенях точности).
Ornith-1.5-9B-BF16.gguf это практически lossless по качеству и весит он 18.4Gb. Это излишне, как jpeg с качеством 100%, или даже более того. Ornith-1.5-9B-Q8_0.gguf уже сжат в два раза. Точность весов модели уменьшена с 16 бит до 8 бит. Как ни странно, замеры обычно показывают что Q8 все еще очень близок к lossless.
Как правило, деградация качества начинается примерно с Q6 и становится заметной ниже Q4. Но на самом деле тут много нюансов, — разные модели по-разному реагируют на квантование.
Нужно выбрать что-то одно из этих файлов и скачать. Что-то что уместится допустим в 8 ГБ видеопамяти. Из рассчета:
Вес файла модели + вес адаптер зрения + KV-кеш.
KV-кеш это тот кеш который используется для хранения текущего контекстного окна модели. И KV-кеш здесь неизвестная переменная. У разных моделей на разной архитектуре этот кеш занимает различный объем памяти, и единственное сходство в том, что чем больше контекстное окно, тем больше будет кеш, что логично.
Наивно предположу что в 8 ГБ видеопамяти может уместится Q4_K_M или Q5_K_M квант. Скачаю оба и адаптер зрения.

Можно качать просто из браузера, тыкая на иконку скачивания. Но я занимаюсь жестким извращением и использую древний как говно мамонта Download Master. Уверен что есть варианты лучше, но я привык к этому со времен ADSL модема Zyxel. Если кто знает вариант лучше посоветуйте в комментариях (вангую LM Studio).

Еще у HF есть свой софт для скачивания моделей из консоли, но я сам им не пользовался, только когда агента просил что-то скачать, и он сам это делал.

Пока модели качаются, скачаю актуальный билд llama.cpp:

На Windows + Nvidia нас интересуют эти два варианта
"Windows x64 (CUDA 12)" - "CUDA 12.4 DLLs"
"Windows x64 (CUDA 13)" - "CUDA 13.4 DLLs"

Как правило, какого-то значительного увеличения скорости от CUDA 13 даже на Blackwell я не заметил. А исторически с некоторыми моделями были те или иные проблемы на CUDA 13, поэтому для надежности я качаю "Windows x64 (CUDA 12)" архив плюс архив "CUDA 12.4 DLLs". Архив с DLLs может быть и не нужным, они могут уже быть в системе, но хрен его знает. У кого-то есть, у кого-то нет. Так что на всякий случай скачиваем и распаковываем все в одну папку, чтобы dll файлы лежали рядом с ехе.
На AMD наверное нужен билд "Windows x64 (ROCm 10.0)". У меня нет AMD карты, так что не уверен.

Для запуска модели создаю в блокноте файл с таким содержанием:
@echo off
title Ornith-1.5-9B-Q4_K_M
"W:\models\llama-b11193-bin-win-cuda-12.4-x64\llama-server.exe" -m "W:\models\Ornith-1.5-9B\Ornith-1.5-9B-Q4_K_M.gguf" ^
--mmproj "W:\models\Ornith-1.5-9B\mmproj-Ornith-1.5-9B-BF16.gguf" ^
-ctk q8_0 ^
-ctv q8_0 ^
-c 262144 ^
--host 0.0.0.0 ^
--port 5001 ^
--reasoning on ^
--reasoning-budget 6000 ^
--reasoning-budget-message "...The maximum allowed token limit for reasoning block has been reached; the current reasoning block is forced to end here." ^
-np 1 ^
--tools all ^
--temp 0.6 ^
--top-p 0.95 ^
--top-k 20 ^
--min-p 0.0 ^
--alias "Ornith-1.5-9B-Q4_K_M" ^
--jinja
pause

И сохраняю его как Ornith-1.5-9B-Q4_K_M.bat
Что означают все эти аргументы?
"W:\models\llama-b11193-bin-win-cuda-12.4-x64\llama-server.exe" -m "W:\models\Ornith-1.5-9B\Ornith-1.5-9B-Q4_K_M.gguf" — бинарник llama-server запускает модель.

--mmproj "W:\models\Ornith-1.5-9B\mmproj-Ornith-1.5-9B-BF16.gguf" — подключение адаптера зрения, если он вам нужен. Может вы OCR хотите делать или еще чего.

-ctk q8_0 и -ctv q8_0 — эти параметры указывают что KV-кеш будет сжат до 8-битной точности. Позволяет сэкономить еще немного VRAM.

-c 262144 — указывает величину контекстного окна с которой модель будет запущена. То есть, сколько текста максимально она сможет обработать и сгенерировать. На странице модели на huggingface обычно указывается максимальное контекстное окно с которым модель может работать. Для Ornith-1.5-9B максимум это 262144 токена. Для понимания, один том романа "Война и мир" это примерно 220к токенов. Размер контекстного окна также влияет на потребление VRAM поэтому можно уменьшать его если вы не планируете использовать столько контекста и/или нужно сэкономить память.

--host 0.0.0.0 - если нужно иметь доступ к модели по API или веб-интерфейсу с другого устройства в той же сети. С этим параметром веб-интерфейс и API будут доступны по айпи адресу вашего ПК в локальной сети.

--port 5001 - порт на котором будет доступен API и веб-интерфейс llama.cpp. Тоже указывать не обязательно, только если вы хотите использовать какой-то конкретный порт вместо порта по умолчанию.

--reasoning on — включает или выключает в случае "off" режим размышления у модели.
--reasoning-budget 6000 - позволяет контролировать то, как много токенов может потратить модель на размышления. Может быть полезно для моделей которые излишне много размышляют по кругу, могут уходить в цикл размышлений.

--reasoning-budget-message "...The maximum allowed token limit for reasoning block has been reached; the current reasoning block is forced to end here." - сообщение с которым сервер принудительно завершит блок размышлений модели если она превысит лимит.

-np 1 - не уверен, нужно ли специально указывать этот параметр. Кажется он и так по умолчанию используется. Он влияет на число параллельно обрабатываемых сервером запросов. Нюанс в том, что контекстное окно делится на число в этом параметре. Т.е., если "-np" = "2", то каждому клиенту будет доступна только половина из 262144 токенов. Поэтому я ставлю "-np 1". В этом случае сервер тоже может работать с двумя клиентами, но не одновременно. Он просто будет складывать запросы в очередь.

--tools all - этот параметр включает встроенные в llama.cpp инструменты, делая языковую модель скорее агентом чем чат ботом. Например, без инструментов, если вы спросите модель, какое сейчас число — она выдумает ответ. У нее просто нет способа узнать. С инструментами в контекстное окно модели вставляется инструкция о том какие инструменты есть и как их использовать. И благодаря этому модель может узнать текущую дату, прочитать или создать какой-то файл, и т.д. Но эти инструменты работают только в веб-интерфейсе llama.cpp. То есть, если в подключите модель по API к другому клиенту - к какому-то агенту или к SillyTavern, инструменты llama.cpp там не будут работать.

--temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0, иногда еще "presence-penalty" и другие — это рекомендованные параметры семплирования для этой модели. Я взял их из карточки на Huggingface. Предполагается что модель лучше будет работать с рекомендованными параметрами, нежели с дефолтными вшитыми в llama-server.

--alias "Ornith-1.5-9B-Q4_K_M" - это просто параметр которых задает название модели, которое сервер отдает клиентам по API.

--jinja - указывает серверу использовать зашитый в метаданные GGUF файла шаблон разметки диалога. Тоже скорее всего уже используется по умолчанию, но я указываю на всякий случай. Это грубо говоря означает что будет использоваться родная для модели разметка и предполагается что она с ней будет работать лучше.

Запускаю .bat файл:

Зажимаю Ctrl и тыкаю на http://0.0.0.0:5001 в консоли, чтобы открыть эту страницу в браузере. Открывается дефолтный веб-интерфейс llama.cpp. Проверяю доступные инструменты — все на месте.

Спрошу у модели сколько памяти она заняла.

Модель чтобы ответить обращается к инструментам, и llama.cpp по-умолчанию блокирует это из соображений безопасности. Я привык жить в YOLO режиме и нажимаю "разрешить всегда" в выпадающем меню. Если языковая модель удалит папку system32 чтобы ускорить мой ПК — это будет исключительно моя вина.

Модель узнала с помощью инструметов сколько памяти она заняла, и как видно, даже Q4_K_M квант плотной 9b модели + зрение + полный контекст занял 13.2 ГБ видеопамяти. Q5_K_M смотреть не буду - очевидно что он займет больше на размер весов.
Выходит, 5.7 ГБ занимают веса самой модели в Q4_K_M + 1 ГБ адаптер зрения в Q8 + еще около 6 ГБ на KV-кеш?

Можно, наверное, попытаться ужаться сильнее, убрать адаптер зрения, уменьшить контекст, и уместить ее в 12 ГБ видеопамяти. Но есть ли в этом смысл?
Из интереса, я скопировал модели текст README.md из репозитория ИИ-агента nanobot (https://github.com/HKUDS/nanobot) и попросил установить его (агента) в конкретную директорию. Через некоторое время модель отчиталась что все установлено. После этого я попросил ее сделать http://127.0.0.1:5001/v1 (API llama-server) - провайдером агента по умолчанию, затем попросил сделать .bat файлы для остановки и запуска агента.

И вроде бы она все сделала, но бат файлы не работали. Как я позже выяснил с локальной моделью побольше, проблема была в том что порт который агент должен использовать по умолчанию на моей системе был заблокирован другим интерфейсом.
Тем не менее, даже такой результат я считаю крутым, потому что еще пару лет назад модели такого размера вообще не умели пользоваться инструментами, у них было маленькое контекстное окно в которое ничего не влезало, и KV-кеш весил намного больше.

Особенность таких моделей в том, что для генерации каждого следующего токена используются не вся модель, а только те ее части которые динамически выбираются роутером модели для конкретной задачи. Как в том меме про то что человек использует только 5% процентов своего мозга. Значит, можно в видеопамять поместить только ту часть весов которая всегда участвует в генерации, слои которые всегда задействованы, а экспертов, которые выбираются динамически можно оставить в оперативной памяти и это не приведет к драматическому падению скорости генерации как это происходит если плотная модель не влезает в видеопамять. В общем, это позволяет использовать модели размером превышающие видеопамять вашего устройства.
Обычно название модели состоит из собственно наименования модели + версия + общее число параметров. Но если после общего числа параметров стоит еще что-то вроде "A3B", — это указывает на МоЕ модель, а конкретно на то какая доля из всех весов активируется (А) при инференсе на каждом слое модели для генерации каждого следующего токена. То есть Qwen3.6-35B-A3B это модель Qwen, версии 3.6, общим размером 35 млрд. параметров, из которых 3 млрд активируются.
Для примера возьму уже упомянутый Qwen3.6-35B-A3B.

На HF куча репозиториев — какие-то аблитерированные(лишенные цензуры) версии, какие-то дистиллы (модели дообученные на датасетах собранных в результате работы более крупных моделей), экспериментальные кванты. Я скачаю обычную ванильную модель из репозитория ggml.

Qwen3.6-35B-A3B-Q4_K_M.gguf + mmproj-Qwen3.6-35B-A3B-Q8_0.gguf

Мне интересно узнать каким будет минимальное возможное потребление видеопамяти для этой комбинации. Можно ли ее использовать в системе с 8 ГБ видеопамяти и 32 ГБ оперативки. Поэтому я использую "--fit off" и "-cmoe" флаги:

@echo off
title Qwen3.6-35B-A3B
:: Launch the server
W:\models\llama-b11193-bin-win-cuda-12.4-x64\llama-server.exe -m "W:\models\Qwen3.6-35B-A3B\Qwen3.6-35B-A3B-Q4_K_M.gguf" ^
--fit off ^
-cmoe ^
--mmproj "W:\models\Qwen3.6-35B-A3B\mmproj-Qwen3.6-35B-A3B-Q8_0.gguf" ^
-fa on ^
-t 8 ^
-ctk q8_0 ^
-ctv q8_0 ^
-c 262144 ^
--host 0.0.0.0 ^
--port 5001 ^
--reasoning-preserve ^
--reasoning on ^
--reasoning-budget 6000 ^
--reasoning-budget-message "...The maximum allowed token limit for reasoning block has been reached; the current reasoning block is forced to end here." ^
-np 1 ^
--tools all ^
--temp 1.0 ^
--top-p 0.95 ^
--top-k 20 ^
--min-p 0.0 ^
--presence-penalty 1.5 ^
--alias "Qwen3.6-35B-A3B Q4_K_M cmoe vision 256k" ^
--jinja
pause

Комбинация флагов "--fit off" и "-cmoe" отключает поведение llama-server по умолчанию, при котором он пытается заполнить всю видеопамять. И вместо этого, он разместит в видеопамяти те части модели, которые должны использоваться всегда, для генерации каждого токена, а экспертов распределит в оперативную память.

-t 8 — необязательный параметр, который регулирует то сколько потоков процессора будет использовать llama-server. Когда-то я игрался с этим параметром и выяснил что выше 8 потоков на моем ПК производительность только падала.

--reasoning-preserve — включает режим работы при котором рассуждения модели из прошлых шагов остаются в контекстном окне. Считается что этот флаг имеет смысл включать только для тех моделей который такой режим поддерживают. Qwen3.6 поддерживает эту фичу.

С такими параметрами запуска потребление VRAM у меня 8.2 ГБ и RAM 20 ГБ:

Таким образом, если немного уменьшить размер контекстного окна, или отключить адаптер зрения, можно использовать данную модель на видеокарте с 8 ГБ видеопамяти при условии наличия еще 24-32 ГБ оперативной памяти. Скорость генерации на моей пеке составила 55 токенов в секунду на пустом контексте, и скорость обработки промпта будет примерно 550-700 т/с.
Если у вас видеопамяти больше 8 ГБ, то вы можете убрать флаг "-cmoe", параметр флага "--fit" изменить с "off" на "on", и в этом случае llama-server "сообразит" что у вас есть еще свободное место и всунет в него какое-то количество тех слоев которые иначе он поместил бы в оперативную память. По-моему, такое поведение сейчас в llama-server уже по умолчанию, то есть возможно эти флаги вообще можно не указывать, но я не проверял и пишу их по привычке.
На 5090, в режиме "-fit on", когда llama-server берет столько видеопамяти сколько может взять, скорость обработки промпта вырастает до 3500т/с и скорость генерации поднимается до 200т/с. На других картах разумеется цифры будт иные.

Кроме того, в репозитории ggml-org еще можно заметить dflash и mtp адаптеры для увеличения скорости генерации:

Иногда они вшиты в основной gguf файл, но тут лежат отдельно. И mtp, и dflash при подключении займет какой-то объем видеопамяти, поэтому использовать их наверное имеет смысл если у вас и так все влезает по памяти, но еще остается место для экспериментов.

Для подключения mtp адаптера можно добавить в .bat такие флаги:

--spec-draft-model "W:\models\Qwen3.6-35B-A3B\mtp-Qwen3.6-35B-A3B-Q8_0.gguf" ^
--spec-type draft-mtp ^
--spec-draft-n-max 2 ^

При этом, значение "2" в "--spec-draft-n-max" это то что дало наибольший буст для меня (с 200 до 260 т/с). На других конфигурациях может быть стоит попробовать подобрать другое значение числа токенов которое mpt будет пытаться предсказать.
По тому же принципу дополнительные флаги для dflash:
--spec-draft-model "W:\models\Qwen3.6-35B-A3B\dflash-Qwen3.6-35B-A3B-Q8_0.gguf" ^
--spec-type draft-dflash ^
--spec-draft-n-max 3 ^

Числовое значение для "--spec-draft-n-max" я не подбирал, выставил наобум, получил 250 т/с. Разумеется, на другом железе все эти цифры будут отличаться.
Я хотел сделать какой-то тест, но мне стало дичайше лень. На что эта модель способна можете посмотреть на ютубе, там сотни видосов с разного рода тестами. Мое личное мнение состоит в том что она все еще не сильно круче той же 9B модели. Наверное из-за слишком малого числа активируемых параметров. Но имеет больше знаний за счет большего числа общих параметров. По крайней мере, она починила те .bat файлы которые создала 9B модель, после того как я несколько раз терпеливо указывал ей что они не работают.

Аналогичным образом можно другие МоЕ похожего размера. Например Gemma-4-26B-A4B, Nemotron-3.5-Lightning-30B-А3B и т.п.
Или вот эту модель для РП которую тренировал Карасик:

@echo off
title Boulesis-v2.1-26B-A4B.i1-Q6_K.gguf
W:\models\llama-b11193-bin-win-cuda-12.4-x64\llama-server.exe -m "W:\models\Boulesis-v2.1-26B-A4B.i1-Q6_K.gguf" ^
--fit off ^
-cmoe ^
-fa on ^
-ctk q8_0 ^
-ctv q8_0 ^
-c 262144 ^
--port 5001 ^
-np 1 ^
--tools all ^
--alias "Boulesis-v2.1-26B-A4B.i1-Q6_K.gguf" ^
--jinja
pause
Например, в i1-Q6_K кванте с такими параметрами запуска она занимает чуть больше 8 ГБ видеопамяти и около 20 ГБ ОЗУ. Так что у кого 8 ГБ либо следует взять квант поменьше, либо уменьшить контекст. Остальным можно использовать и Q6.

24 ГБ VRAM и более

Если же вдруг у вас 24 и более ГБ видеопамяти, то можно попробовать запустить плотный Qwen 3.8 27b.

Это очень популярная сейчас модель, которая относительно своего размера показывает довольно выдающиеся результаты в разного рода бенчмарках. Другие плотные модели похожего размера (Muse-Glimmer-30B, Gemma-4-31B-it) до ее результатов в агентских-кодерских бенчмарках не дотягиваются, хотя могут быть лучше в лингвистических задачах.
И куда сейчас не зайдешь, в какое-то профильное сообщество по локальным моделям не заглянешь, кажется что большинство сейчас пользуются этой моделью, обсуждают ее модификации, пытаются всунуть ее на все более скромное железо, ужать как можно сильнее как не убив интеллект. Это прям какая-то специальная олимпиада. Вот, например, пока я это писал у меня в рекомендациях на ютубе появилось это:

Можно взять квант который обсуждает автор этого видео и запустить со схожими параметрами:
@echo off
title Qwen3.8-27B-GSQ-RCO 256k
"W:\models\llama-b11193-bin-win-cuda-12.4-x64\llama-server.exe" -m "W:\models\Qwen3.8-27B-GSQ-RCO\Qwen3.8-27B-GSQ-RCO-IQ3_S-mtp.gguf" ^
-ngl 99 ^
-fa on ^
-ctk q8_0 ^
-ctv q8_0 ^
-c 220000 ^
--host 0.0.0.0 ^
--port 5001 ^
--reasoning-preserve ^
--reasoning on ^
--reasoning-budget 6000 ^
--reasoning-budget-message "...The maximum allowed token limit for reasoning block has been reached; the current reasoning block is forced to end here." ^
-np 1 ^
--tools all ^
--spec-type draft-mtp ^
--cache-ram 0 ^
--alias "Qwen3.8-27B-GSQ-RCO_256k" ^
--jinja
pause
"--spec-draft-n-max" автор видео не указывает, и в этом случае llama-server использует значение по умолчанию равное трем.

И действительно, судя по всему этот квант можно уместить на видеокарте с 24 ГБ памяти.

Правда скорость генерации какая-то низкая, особенно с включённым mtp — 41.03 t/s. Я помню что у меня та же модель в более жирных квантах показывала большую скорость и без mtp. Видимо чем сильнее модель сжата, тем больше вычислений нужно произвести чтобы рожать токены.

Хотя для 3090, 4090 и 5090 и модели Qwen3.8-27B существуют специальные движки, позволяющие добиться лучших скоростей чем при использовании llama.cpp, и скорее всего владельцы этих карт будут пользоваться ими для данной модели.

https://github.com/Don-Chad/ninfer-3090
https://github.com/sergiuszm/ninfer-4090
https://github.com/Neroued/ninfer

Те же у кого 96 более ГБ оперативной памяти, могут использовать модели размерами 120 или более млрд. параметров также как я запускал здесь 35b модель. Но я думаю они и сами об этом знают, ибо вряд ли они покупали столько памяти для каких-то других целей. Тем более что принцип там тот же самый, поэтомум писать об этом не буду.

Еще хочу заметить, что если у вас возникают вопросы про llama.cpp, то лучше не спрашивайте у ChatGPT или других подобных чат-ботов. Есть такая штука как DeepWiki. Это LLM, который перед тем как ответить вам почитает код репозитория вопрос о котором вы задаете и будет отвечать не от балды а опираясь на код. Так что с ним больше шансов получить нормальный ответ.

#llama #llm #sillytavern #gguf