2ch-llama-inference

LLM (большие языковые модели)

То, что сегодня называется LLM или искусственным интеллектом - на самом деле статистическая машина.
Это математическая модель, обученная взаимосвязям на огромном массиве данных (датасете). Она генерирует наиболее вероятный ответ в соответствии с этими взаимосвязями. Интеллекта и сознания там нет. В каком-то смысле это можно назвать умным автокомплитом текста.

Как мы общаемся с LLM?

Большие языковые модели работают с языками. С точки зрения пользователя - на вход подается текст, и ответ тоже представлен текстом. На самом деле все несколько сложнее.

LLM работают не с текстом напрямую, а с токенами. Токены - не всегда целые слова. Это могут быть части слов, символьные последовательности и отдельные символы (например, пробел). Процесс преобразования текста в токены называется токенизацией.

Взаимодействие с моделью проходит в следующем формате:

1. Пользователь подает на вход текст
2. Текст проходит процедуру токенизации, преобразуясь в понятную для модели последовательность токенов
3. Модель обрабатывает запрос и генерирует ответ в токенах
4. Ответ проходит процедуру детокенизации, преобразуясь в понятный пользователю текст

"Память" модели: контекстное окно и контекст

Как устроена "память" модели? Как работают чаты, где множество сообщений?

Память, увы, не безгранична. Лимит токенов, который модель может обработать за раз, называется окном контекста (context window). Чем больше это окно, тем больше ресурсов (в нашем случае - видеопамяти) требуется для его обработки. Контекст (он же KV кеш) - это конкретное число токенов, что модель "видит" в данный момент.

Что будет, когда окно контекста переполнится? В нашем случае, модель перестанет воспринимать новые токены. Например, если предел достигнут прямо во время обработки запроса, то ответ не будет сгенерирован. Если он достигнут во время генерации ответа, генерация будет остановлена.

Форматирование, шаблон разметки (Instruct Template)

Существуют два типа моделей: base и instruct модели.
Базовая (base) модель получается в результате обучения модели на огромном массиве данных и усваивает взаимосвязи данных друг с другом.
Instruct модель - это та же base модель, дообученная понимать команды и следовать инструкциям системы и пользователя.
Вы почти наверняка не занимаетесь ML разработкой (иначе бы не читали эти строки), так что нужно запомнить - во всех случаях нужно использовать instruct модели.

Разницу легче объяснить на примере: если подать base модели запрос: "Как заварить китайский чай?", в качестве ответа мы можем получить асоциативный ряд: "Как сварить кофе? Как приготовить компот?", потому что base модель всегда работает в режиме автодополнения текста и не была специально настроена на формат диалога с пользователем. Хорошая instruct модель во всех подробностях расскажет как именно не обжечь листья и получить вкусный настой. Китайский чай - это здорово.

Чтобы instruct модель корректно распознавала, где заканчивается команда пользователя и начинается ответ, в процессе дообучения используется шаблон разметки (instruct template). Это невидимые в интерфейсе пользователя (фронтенде) специальные токены(special tokens) - маркеры, разделяющие запрос на части: инструкции системы, сообщения пользователя и ответы модели.
Благодаря шаблонам реализуются и сложные функции, такие как вызов внешних инструментов (полезно в программировании) или режим рассуждений (reasoning / thinking), когда модель "думает" перед ответом и выделяет мысли в отдельный блок перед ответом.

Существуют два подхода к форматированию запросов модели: Chat Completion и Text Completion, на языке программистов - два API.
Chat Completion - это формат, адаптированный для универсального использования без привязки к модели. В теле запроса передается последовательных текстовых сообщений с ролями (System, User, Assistant). Вопрос разметки берет на себя бекенд (о нем позже): пользователю не нужно беспокоиться о ее соблюдении.

Text Completion - это формат, при котором вопрос разметки берет на себя пользователь. Запрос не проходит форматирование на стороне бекенда. Он изначально должен посылаться в том виде, в каком его будет обрабатывать модель. Для этого в интерфейсе чата (фронтенде) необходимо выбрать подходящий модели шаблон.

Плюсы Chat Completion в простоте использования и универсальности. Плюсы Text Completion в том, что он предоставляет больше гибкости и возможностей. Например, в контексте ролевой игры или креативных задач (модель отыгрывает персонажа или продолжает историю), это позволяет легче обходить цензуру и направлять модель в нужное русло (благодаря prefill, о чем позже).

Пример instruct шаблона - простой, но гибкий и прекрасный ChatML:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

<|im_start|>system
You are a helpful assistant.<|im_end|>
<|im_start|>user
Hello!<|im_end|>
<|im_start|>assistant
Hi! How can I help you today?<|im_end|>
<|im_start|>user
What's the capital of France?<|im_end|>
<|im_start|>assistant
Paris.<|im_end|>

В данном шаблоне каждая часть сообщения начинается с тега (спецтокена) <|im_start|>, за которым следует указание роли (system, user или assistant), а заканчивается тегом <|im_end|>. Напомню, что данные теги (спецтокены) не видны пользователю в интерфейсе чата (фронтенде): они нужны, чтобы модель корректно обрабатывала запросы. Если используется Chat Completion, пользователю не нужно думать о шаблоне. Если используется Text Completion, нужно выбрать подходящий модели шаблон в интерфейсе фронтенда, чтобы соблюдалось форматирование. Информацию о требуемом шаблоне можно найти в документации модели.

Сэмплинг

Вспомним, что LLM - это статистическая машина, которая генерирует наиболее вероятный ответ. Тогда почему модели дают разные ответы на одни и те же запросы? (Если, конечно, температура не равна 0, о чем позже)
Ответ кроется в процессе, что называется сэмплингом. Модель генерирует ответ в токенах, и на самом деле каждому токену следует не один единственный, а целый список возможных вариантов, и каждый обладает некоторой вероятностью. Этот процесс выбора (сэмплинг) повторяется снова и снова для каждого нового токена, пока модель не закончит ответ.

Рассмотрим сэмплинг на примере. Продолжая фразу "Сегодня на завтрак я скушаю", модель должна выбрать один среди следующих вариантов:

1
2
3
4
5

Яичницу - 40%
Кашу - 30%
Бутерброды с сыром - 17.5%
...
Кирпич - 0.00001%

Вариантов может быть очень много, вплоть до тысяч. Как выбрать подходящий вариант, не выбирая самый вероятный? На помощь приходят сэмплеры.

Сэмплер - это алгоритм выбора конкретного токена из списка. Существует множество различных сэмплеров, но рассмотрены будут самые простейшие и необходимые.
Для начала - зачем вообще нужны сэмплеры? По примеру выше, самый вероятный вариант с точки зрения модели - это яичница. Это верный ответ. Однако каша и бутерброды с сыром - тоже. А вот кирпич на завтрак кушать не хотелось бы. Если всегда выбирать самый вероятный ответ (это называется жадным поиском/greedy search), ответы будут лишены разнообразия, будут предсказуемыми, а может и вовсе зациклятся и приведут к проблемам. На первый взгляд может показаться, что самый вероятный ответ - самый правильный. На самом деле все несколько сложнее.

Даже для технических задач: для математики, для программирования важно иметь несколько вариантов ответов.
Одно уравнение может иметь несколько разных путей решения, которые приведут к одному верному результату. Модель может "знать" одно решение, но не знать другого. Если ограничить варианты в процессе решения, модель может не прийти к верному ответу. Или выдать неверный ответ за верный (что будет галлюцинацией), но об этом позже.

Поговорим о конкретных сэмплерах:
Температура - параметр, управляющей тем, насколько "рискованно" модель выбирает токены.
Низкая температура (например, 0.1) делает распределение вероятностей "острым", оставляя самый вероятный вариант единственным в большинстве случаев. Модель отвечает "точнее", но при этом предсказумее. Обычно такая температура используется для программирования и других точных задач.
Высокая температура (например, 1) "сглаживает" вероятности, что позволяет модели выбирать менее вероятные токены. По примеру выше, разница между яичницей (40%) и бутербродами с сыром (17.5%) сократится, несколько уравняя вероятность выбора обоих вариантов. Это добавляет "креативности" модели, однако при слишком высоких значениях приводит к бессмыслице: модель может посчитать, что скушать кирпич - не такая уж и плохая идея.
Температура 0, напротив - способ сделать так, чтобы ответы на одни и те же запросы были всегда одинаковы (упомянутый ранее жадный поиск/greedy search). Когда говорят, что модель "детерминирована", подразумевается именно это.

Top-K - самый простой отсекающий фильтр. Все варианты, кроме первых K самых вероятных, отсекаются. Вернемся к примеру с завтраком. Допустим, задан Top-K = 3. В таком случае, останутся только яичница, каша и бутерброды с сыром.
Это жесткий сэмплер, который с одной стороны отсекает плохие варианты, но с другой - он может отсекать и хорошие.

Top-P - тоже отсекающий фильтр, но чуть более сложный. Вместо того, чтобы оставлять какое-то количество вариантов, Top-P считает их суммарную вероятность.
Модель будет собирать вероятные выборы до тех пор, пока сумма их вероятностей не достигнет P процентов.

Рассмотрим два примера, в обоих случаях Top-P = 0.9 (90%).

1
2
3
4
5

Яичница - 85%
Каша - 6%
Бутерброды с сыром - 4%
...
Кирпич - 0.00001%

Суммарная вероятность первых двух вариантов (85% + 6% = 91%) превысила порог 90%. Все остальные варианты будут отсечены.

1
2
3
4
5
6
7

Яичница - 15%
Каша - 12%
Бутерброды с сыром - 10%
Творог - 9%
Блины - 8%
...
Кирпич - 0.00001%

Чтобы набрать необходимые 90%, понадобится собрать более широкий список возможных ответов, из 10-20 вариантов. У модели нет уверенности в выборе, а значит и больше пространства для "креатива".

Min-P - фильтр, отсекающий наименее вероятные варианты. Остаются только те варианты, которые хотя бы в P раз не менее вероятнее лидера. Рассмотрим на примере, Min-P = 0.1 (10%)
Это значит, что любой токен, вероятность которого менее 10% от вероятности лидера (самого вероятного варианта), будет отсечен.

1
2
3
4
5
6

Яичница - 80%
Каша - 8%
Бутерброды с сыром - 6%
Творог - 2%
...
Кирпич - 0.00001%

Яичница - лидер, потому пороговое значение: 80 * 0.1 = 8%. Это значит, что в списке останутся яичница и каша, менее вероятные варианты будут отсечены.
Можно сказать, Min-P работает динамически: когда модель уверена в ответе, она сужает выбор, чтобы наименее вероятно совершить ошибку. Когда модель сомневается, она расширяет выбор, чтобы была креативность.

Если речь не о точных задачах, сегодня зачастую достаточно связки Температура + Min-P. Это классическая комбинация для большинства задач. Если же модель применяется для генерации кода или решения иных точных задач (математика), необходимо использовать рекомендованные разработчиком сэмплеры. В абсолютном большинстве случаев именно рекомендованные сэмплеры дадут лучшие результаты.

На чем запускать модели? Фронтенд и бекенд

Фронтенд - это в той или иной форме интерфейс (например, отдельное приложение-чат, приложение-агент или плагин для IDE), упрощающий пользователю формирование запросов модели. Строго говоря, фронтенд - это менеджер запросов. Иногда фронтенд реализует дополнительные функции (например, API-прослойка для связи с ботом в Телеграме или Дискорде), но по большей части все, что он делает - формирование запросов и часто (но не всегда) визуализация окна ввода и вывода.

Но мы также должны запустить модель на своем компьютере. Для этого используется бекенд (говоря иначе, инференс-движок). Бекенд - специальная программа, которая загружает файл(ы) модели в память компьютера и берет на себя вычисления. Вся логика - токенизация, сэмплинг, обработка запросов, генерация ответов - реализуется именно в бекенде.

Если фронтенд - это визуальная часть системы, то бекенд - это ее ядро, выполняющее работу модели. Фронтенд и бекенд - гораздо более широкие понятия (в программировании это клиент и сервер), но сейчас они рассматриваются исключительно в контексте LLM.

Какой бекенд выбрать? Какой фронтенд?

Выбор бекенда для нас предопределен. Мы ограничены в вычислительных ресурсах, нам критически важна возможность распределять нагрузку между видеокартой и оперативной памятью. Решения вроде vLLM или SGLang созданы для мощных серверов и нам не подходят.
Наш выбор - llamacpp. На сегодняшний день это самый универсальный и доступный open-source проект, который первым внедряет поддержку новых моделей и оптимизаций, несколько раз на дню получает обновления. Благодаря данному проекту стали доступны модели в формате GGUF (который использует технологию квантования, что позволяет запускать тяжелые LLM на обычном домашнем компьютере), но об этом позже.

Почему не выбрать KoboldCPP, Ollama, LM Studio, Unsloth Studio? Есть и другие. К слову, все из перечисленных проектов предоставляют как бекенд, так и фронтенд.
Дело в том, что все эти проекты являются надстройками над llamacpp. Однако наберется немало причин, почему нужно использовать именно llamacpp: KoboldCPP медленно обновляется и имеет ненужные функции, также его фронтенд оставлять желать лучшего; Ollama, LM Studio и прочие коммерческие проекты монетизируют бесплатный труд других людей и предположительно собирают телеметрию с пользователей; их интерфейсы часто ограничивают пользователя в настройках. Можно продолжать, но на самом деле все проще: llamacpp попросту легче. Это самый легкий и прозрачный способ. Ее быстрее установить, легче обновить, и она дает по-настоящему полный контроль над процессом, что позволяет добиться лучших результатов. Более того, в llamacpp уже входит фронтенд - llama-server, который реализует симпатичный, лаконичный и функциональный интерфейс. Сейчас мы в кратчайшие сроки во всем этом убедимся.

llamacpp, HuggingFace, модели и квантование

Пришло время установить llamacpp. Делается это очень просто: переходим по ссылке GitHub репозитория

Для видеокарт Nvidia RTX 50xx и новее - необходимо скачать архивы Windows x64 (CUDA 13) и CUDA 13.1 DLLs.
Для видеокарт Nvidia RTX 40xx и старее - архивы Windows x64 (CUDA 12) и CUDA 12.4 DLLs.
Для видеокарт AMD - Windows x64 (Vulkan).

После этого распакуйте загруженные архивы в удобную папку, по пути которой отсутствует кириллица. Например, C:\LLM\llamacpp. Все, llamacpp установлена. Процесс обновления идентичен. Важно помнить, что это активно развивающийся проект, потому лучше иметь резервные копии предыдущих релизов, которым есть доверие в плане стабильности.

Теперь нам необходимы файлы модели. Самое время познакомиться с HuggingFace - передовой платформой-репозиторием open-source LLM моделей. Все разработчики open-source моделей обязательно загружают их на данный сайт.

Из чего состоят модели? Ранее говорилось, что модель - это математическая функция. Внутри этой функции находятся миллиарды чисел. Эти числа называются параметрами или весами. Чем больше у модели параметров - тем больше знаний она может уместить. Измеряются параметры обычно в миллиардах. Например, если модель называется Llama-3-8B, то это означает, что в модели 8 миллиардов параметров. B - от английского billions, миллиарды.

Архитектура модели - довольно сложный вопрос. Если вкратце, модели состоят из блоков, те в свою очередь содержат два типа слоев: Attention и MLP. Attention слои позволяют модели определять взаимосвязи между данными и фокусироваться на них; MLP (они же FFN) слои отвечают за знания и "ум" модели и составляют основной размер модели по числу параметров.

Существуют два типа архитектур: Dense и MoE (Mixture of Experts)
Dense (плотные) модели при генерации каждого токена задействуют все параметры. Например, если используется 32B модель, то все 32 миллиарда параметров будут задействованы при генерации каждого токена. Со временем выяснилось, что данная архитектура плохо масштабируется, у нее есть эффективный предел по размеру. Наращивание MLP слоев после некоторого предела теряет эффективность: они не дают модели столько знаний и "ума", сколько наращивание давало прежде. К тому же, чем больше модель данной архитектуры, тем сложнее проводить вычисления attention слоям.
Mixture of Experts (MoE) модели появились позже в качестве ответа на проблемы dense архитектуры. Вместо единого большого MLP пространства, MoE модели используют несколько MLP-пространств поменьше, именуемых экспертами. В процессе генерации ответа модель задействует множество таких пространств, активно переключаясь между ними. Похожим образом работает человеческий мозг: мысли являются результатом разных частей мозга. Благодаря этому MoE модели хорошо масштабируются. Если сравнивать аналогичные по размеру dense и MoE модели, то чаще всего dense модель будет работать лучше. Ведь поскольку она задействует все MLP слои сразу, соответствующим образом масштабированы и Attention слои. У МоЕ моделей Attention слои масштабируются иначе и зачастую меньше. Однако с ростом размера модели проблема перестает быть актуальной: dense модель достигает своего предела, а MoE может эффективно масштабироваться дальше. Отсюда закономерность: MoE модели зачастую больше 100b параметров, а dense модели - до 50b.

Благодаря тому, что MoE модель задействует для ответа только часть MLP-пространства (экспертов), она задействует только часть своих параметров. Например, gemma-4-26B-A4B-it состоит из 26b параметров, но при генерации каждого токена задействует только 4b. Это видно из названия: 26B-A4B. Эти 4 миллиарда называются активными параметрами (active parameters). Иногда использование MoE архитектуры и число активных параметров не отражены в названии явно, в таком случае нужно изучать документацию модели.

Каждый из миллиардов параметров - это число с плавающей точкой. Например, оно может выглядеть так: 0.123. И разумеется, когда мы запускаем модели на собственном компьютере, модель занимает память. Чем больше у нее параметров и чем большей они точности - тем больше памяти нам потребуется.

На домашнем железе, даже продвинутом (скажем, RTX 5090 и 256гб оперативной памяти) мы практически никогда не имеем возможности запустить модели в оригинальном виде (в полной точности): они слишком большие.

Потому применяется квантование - технология сжатия модели.
По сути, квантование - отказ от большей точности в пользу меньшей ради экономии вычислительных ресурсов. Упомянутый параметр 0.123 может стать параметром 0.1.
Таким образом, размер модели может упасть в несколько раз. Та же gemma-4-26B-A4B-it, которую мы вскоре запустим, в оригинальных весах весит почти 52гб. Воспользовавшись квантованием, мы сможем запустить ее, распределив веса между 16гб оперативной памяти и 8гб видеопамяти. Квантованная модель (будем называть ее просто "квант") весит почти 17гб.
В процессе работы компьютеру нужно постоянно перемножать числа между собой. Благодаря тому, что они стали короче, повысится и скорость.

Для большинства задач нет необходимости в полной точности, предлагаемой полными весами моделями. Если квантование не излишне агрессивное, разница между квантованной моделью и оригинальными весами может быть не настолько значительной.
Квантование - глубокая тема, но для нас она сводится к одному вопросу: насколько сильно мы готовы "округлить" веса модели, чтобы она поместилась в нашу память?

В контексте llamacpp и формата GGUF кванты бывают разными. Если искать кванты на HuggingFace, в числе прочих можно обнаружить следующие GGUF кванты: Q8_0, Q4_K_M или IQ3_XS.

Цифра в названии (Q2, Q3...) означает количество бит, которые выделяются на один параметр.
Для понимания лучше всего подойдет обывательский пример с разрешением изображений: чем выше разрешение, тем изображение четче. Иногда нет необходимости в полном разрешении, чтобы передать изображение. Потому существуют технологии сжатия и форматы вроде .jpg. Так и здесь: LLM можно сжать без существенных потерь и получить сопоставимый с оригиналом результат.
Q8 - это почти оригинал. Точность крайне высока, модель почти не теряет в "уме" (знаниях), но по-прежнему занимает много места, пусть и значительно меньше оригинальных весов.
Q4 - это общепринятая золотая середина. Модель сжимается в несколько раз, но при этом сохраняет подавляющую часть своих возможностей.
Q2 - это экстремальное сжатие. Модель становится невероятно легкой относительно оригинальных весов, но вместе с тем теряет большинство своих возможностей.
Существуют также Q5, Q6 кванты.

Но чем отличаются Q4_0 и Q4_K_M, Q4_K_S, Q4_K_XL кванты?
На сегодняшний день кванты формата Q_0 устарели, за исключением Q8_0. На замену им как раз пришли K_M, K_S (и прочие аналоги вроде XS, K_XL). Предполагается, что в таких квантах более осмысленный подход к квантизации конкретных слоев, что должно привести к меньшей потери возможностей модели.

А чем отличаются IQ кванты? Например, IQ4_XS. Их особенность в том, что по возможностям модели они плюс-минус сопоставимы с K квантами, однако при этом весят чуть меньше и работают медленнее. Например, предполагается, что IQ4_XS сопоставим с Q4_K_S. Это хороший вариант, если квант больше совсем чуть-чуть не помещается на доступном железе или хочется сэкономить память.

Но и это не конец. Существуют imatrix кванты. Иногда они отдельно помечаются авторами квантов. Например, коллектив mradermacher на HuggingFace дополнительно помечают репозитории (папки) с imatrix квантами моделей. На примере Gemma 4, стандартные Q_K и IQ_K кванты находятся в репозитории mradermacher/gemma-4-26B-A4B-GGUF, а imatrix кванты - в репозитории mradermacher/gemma-4-26B-A4B-it-i1-GGUF. Да, как Q, так и IQ кванты могут быть или не быть imatrix квантами.
В большинстве же случаев, популярные авторы квантов unsloth и bartowski по умолчанию используют imatrix в своих Q_K квантах.
Как работает imatrix квантование? Прежде чем сжимать модель, модели дают обработать некоторый массив данных. В процессе чтения считывается, какие именно параметры активируются чаще всего и сильнее всего влияют на результат. Эта запись и есть imatrix - importance matrix, матрица важности.
Таким образом, наиболее "важные" параметрые по итогу подвергаются меньшему квантованию, что приводит к лучшим результатам.

Оригинальные веса моделей хранятся в форматах FP16, BF16, FP32. В таких весах они запускаются на высокопроизводительных корпоративных серверах, хотя и там - это уже большая редкость.

Какие все-таки выбирать кванты?
Если подытожить, то в большинстве случаев - это imatrix Q_K кванты. Каких авторов кванты лучше? Зависит от конкретной модели.
Как в принципе понять чьи кванты лучше? Существуют различные метрики вроде PPL и KLD, которые позволяют ограниченно "измерять" эффективность квантования. Это сложная тема, которая точно не нужна новичкам здесь и сейчас. Потому что в любом случае, кванты бывают сломанными: например, в файл кванта не будет вшит необходимый instruct шаблон или на самом этапе квантования произошла ошибка, из-за чего модель может начать повторять одно и то же слово или выводить бессмысленный набор символов.
Бывает, один квант действительно лучше другого, хотя оба работают корректно.
Бывает, в каких-то конкретных случаях более далекий от оригинальных весов квант выдает подходящие результаты. Например, Q4 модель может быть более "расцензуренной", чем Q6 или Q8, поскольку квантизация размыла слои, ответственные за цензуру. Впрочем, это редкий случай. Тонкостей и противоречий в вопросах квантования немало.
Важно запомнить главное - ориентироваться нужно на свой опыт, а не только на теорию.

Золотой стандарт - Q4_K_M для общих задач и Q6-Q8 для точных задач вроде программирования.
Это вовсе не значит, что нельзя использовать Q4_K_S (а иногда даже и Q2_K_XL) для общих задач или Q5 для точных, но ориентир именно таков. Руководствуйтесь собственным опытом, опробуйте разные кванты и решите, что вам подходит.

Теперь встает вопрос: как выбирать кванты под конкретное железо?
Очевидно, модель должна поместиться в память. Dense модель - в видеопамять, MoE модель - в видеопамять или видеопамять и оперативную память. Использовать жесткий диск или SSD не получится, увы: память должна быть быстрой.
Вспомним, что dense модели при генерации токенов задействуют все свои параметры. Dense модель в идеале должна полностью поместиться в видеопамять. Если она даже самая малая ее часть останется в оперативной памяти, скорость генерации упадет очень сильно, так как для каждого токена компьютеру придется гонять данные между медленной оперативной памятью и быстрой видеопамятью. На практике есть случаи, когда это полезно, но в абсолютном большинстве случаев - dense модель должна полностью находиться в видеопамяти.
MoE (Mixture of Experts) модели, напротив, при генерации токенов задействуют только часть своих параметров (активные эксперты). Это значит, что активные эксперты MoE моделей можно держать в видеопамяти, а остальную часть модели - в оперативной памяти.
В этом основное достоинство данной архитектуры: при генерации каждого нового токена компьютера нужно перекачать из оперативной памяти в видеопамять гораздо меньший объем данных, в сравнении с dense моделью того же размера. MoE модели работают достаточно быстро, даже если они не помещаются в видеопамять целиком.

Вспомним про контекстное окно и контекст. Контекст (он же KV кеш) тоже должен находиться в видеопамяти. В противном случае он будет обрабатываться настолько долго, что моделью не получится пользоваться. Возникает логичный вопрос: сколько весит контекст? Зависит от конкретной модели и ее архитектуры.

С опытом придет понимание того, какого размера брать кванты для вашего железа. Поначалу общая рекомендация такая - ~80% видеопамяти можно отвести под веса модели, а остальное - под контекст и систему. В случае MoE моделей подзавязку забивать оперативную память тоже не стоит, всегда следует оставлять безопасный резерв.
На Windows, например, всегда в резерве находятся 0.5гб видеопамяти, недоступные пользователю. Также какое-то количество видеопамяти потребляют рабочий стол, браузер и иные сторонние процессы. Учитывайте это, когда подбираете размер кванта.

Загрузка и запуск gemma-4-26B-A4B-it

Теперь, когда необходимый минимум теории позади (позади, правда ведь?), мы загрузим подходящий квант модели и начнем пользоваться llamacpp.

Как вы уже поняли, HuggingFace (также HF или Обниморда) - платформа не только для моделей, но и для квантов.
Кванты - довольно большие файлы, и загружать их через браузер не всегда хорошая идея. Для этого, например, можно использовать инструмент HuggingFace-cli (python) или aria2 (протокол и клиенты, которые его реализуют).
На загрузке подробно останавливаться не стоит. Вы справитесь.

Загрузким необходимый квант модели gemma-4-26b-A4B-it из репозитория.
Какой выбрать квант под ваше железо?
Для конфигурации "16гб оперативной памяти и видеокарта с хотя бы 8гб видеопамяти" в данном случае подойдет Q4_K_M квант.
Для конфигурации "32гб оперативной памяти и видеокарта с хотя бы 16гб видеопамяти" - Q8_0 квант.
Также видно, что в репозитории есть некие mmproj кванты. mmproj файл - это визуальный прожектор, необходимый для того, чтобы модель могла распознавать изображения. Если любопытно попробовать - загрузите себе mmproj-google_gemma-4-26B-A4B-it-f16.gguf. В llamacpp bf16 прожекторы всегда были проблемными. Разницы между bf16 и fp16 прожекторами на практике нет.

Наконец-то можно приступить к запуску.
llamacpp запускается и управляется через терминал (консоль, cmd в Windows). Для удобства лучше создать .bat файл, содержащий необходимые команды, по сути это будет ярлык старта.

Рассмотрим как это делается на примере трех сценариев.
gemma-4-26B-A4B-it, 16гб оперативной памяти, 8гб видеопамяти:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

cd "C:\LLM\llamacpp"
llama-server.exe --api-key key ^
--host 127.0.0.1 ^
--port 8080 ^
--model "C:\LLM\Models\gemma-4-26B-A4B\google_gemma-4-26B-A4B-it-Q4_K_M.gguf" ^
--alias gemma-4-26B-A4B-it-Q4_K_M ^
--flash-attn on ^
-b 512 ^
-ub 512 ^
-np 1 ^
-c 64000 ^
--cache-ram 0 ^
--swa-checkpoints 3 ^
--n-gpu-layers 999 ^
--n-cpu-moe 29 ^
--top-k 64 ^
--top-p 0.95 ^
--temp 1.0

pause

Построчно разберемся что здесь происходит. Позже этот шаблон легко адаптировать для других моделей.
Для начала необходимо указать директорию, где находится llamacpp, если только .bat файл не находится в той же папке. Для удобства лучше держать их в отдельной папке.

Далее происходит запуск самого llama-server, при желании можно указать api-key: ключ, который необходимо указать при подключении к бекенду. Это необязательно и полезно если планируется подключаться с нескольких устройств.

Далее можно указать адрес и порт запуска: llama-server реализует API (точку подключения), к которому можно подключиться с любого фронтенда. Если не указать свои адрес и порт, будет использован адрес 127.0.0.1:8080.

Далее указывается путь до gguf файла кванта. Если модель большая, у нее может быть несколько gguf файлов. Выглядеть это может так Qwen3.5-122B-A10B-Q6_K_L-00001-of-00003.gguf. В таком случае путь указывается только до первого файла, остальные будут задействованы автоматически.

Параметр alias отображает название модели при работе с ней через фронтенд.

Параметр flash-attn отвечает за включение Flash Attention, умного алгоритма, что значительно ускоряет работу модели. Он должен быть всегда без исключений включен.

Параметры b и ub отвечают за логический и физический размер файл батч-файла. Чем больше батч-файл, тем быстрее обрабатываются запросы (не путать со скоростью генерации ответа) и тем больше потребляется видеопамяти. Скорость обработки запроса также называется prompt processing (PP). Для простоты пусть параметры -b и -ub будут равны. Для dense моделей зачастую достаточно значения 128, 256 - если очень важна скорость. Для MoE моделей нужны значения больше, поскольку значительная часть весов модели находятся в оперативной памяти. Значения могут доходить до 1024 и даже 2048, при этом нет смысла делать их больше.

Параметр np отвечает за количество серверных слотов: сколько запросов могут обрабатываться одновременно. Если не планируется параллельно обрабатывать несколько запросов, лучше указываться -np 1. Некоторые модели, как Gemma 4, могут потреблять дополнительную память за каждый слот (за счет SWA, о чем позже).

Параметр c отвечает за размер контекстного окна. Когда вы только подбираете значения и работаете с незнакомой моделью, для удобства отталкивайтесь от значения 16000 или меньше. Если поймете, что есть больше свободной видеопамяти, тогда можно увеличить контекстное окно.

Параметр cache-ram отвечает за кеширование контекста. Предположим, ваш чат с моделью занимает 20 тысяч контекста. С каждым новом запросом модель будет обрабатывать только новую часть. Однако если в начале контекста произойдут изменения, например, будут отредактированы инструкции (они находятся в самом начале запроса), то бекенд высвободит кешированный контекст, и его нужно будет обрабатывать заново. Параметр cache-ram добавляет дополнительное кеширование в оперативную память и отражает размер этого кеш-файла в мегабайтах. Когда есть свободное место в кеш-файле, при редактировании контекста или переключении на новый, бекенд будет не высвобождать старый контекст, а выгружать его туда. Так что когда будет решено вернуться к предыдущему контексту, он не будет высчитываться с нуля, а будет взят из кеш-файла. Это полезно, например, когда часто редактируются инструкции с одних на другие или еще при каких-либо обстоятельствах когда ведутся два разных чата. Стандартный размер кеш-файла в llama-server, если его не указывать вручную - 8 гигабайт. Важно учитывать, что выделение памяти под него динамическое: он заполняется по мере необходимости, а не сразу. В данном конкретном случае у нас 16гб оперативной памяти, и если мы не откажемся от кеш-файла, то в какой-то момент словим переполнение памяти и как следствие - краш бекенда.

Параметр swa-checkpoints актуален только для моделей с SWA (Sliding Window Attention), к коим относится и Gemma 4. Если вкратце, то SWA - особый вид внимания к контексту. Модель отдает внимание последним N токенам, что позволяет экономить видеопамять, выделяемую под контекст. Но это добавляет дополнительные расходы для кеширования: кеш моделей с SWA не может быть легко отредактирован. Если удалить или отредактировать одно из сообщений в чате с моделью без SWA, контекст будет пересчитан ровно с того момента. Если же это модель с SWA, контекст будет пересчитан полностью. Если только нет ближайшего чекпоинта (контрольной точки), что и реализует параметр swa-checkpoints. Стандартное значение - 32. Однако важно учитывать, что чекпоинты тоже занимают оперативную память. В случае с моделью Gemma 4 один чекпоинт в среднем весит 260мб. Как и в случае с кеш-файлом, память под чекпоинты выделяется по мере надобности. У нас ограниченное количество оперативной памяти, потому, чтобы не было переполнения, следует задействовать только 3 чекпоинта. Система чекпоинтов достаточно продвинута, чтобы смещать чекпоинты к более актуальным частям контекста, потому это не должно быть проблемой.

Параметр n-gpu-layers отвечает за выгрузку слоев модели на видеокарту. Напомню, что в случае dense моделей, они всегда должны находиться в видеопамяти. Потому принято задавать значение 999: мы изначально не знаем, сколько слоев у модели, потому наверняка выгружаем их все. Но ведь у нас MoE модель, которая должна частично находиться в оперативной памяти, так почему мы выгружаем ее в видеопамять полностью? Ответ лежит в следующем параметре.

Параметр n-cpu-moe отвечает за выгрузку MoE весов на процессор (для работы с оперативной памятью). Сначала мы при помощи n-gpu-layers выгружаем все слои (и, соответственно, все веса модели) в видеопамять. Затем, если это MoE модель, при помощи n-cpu-moe мы переносим часть весов экспертов из видеопамяти в оперативную память. Соответственно, чем больше параметр n-cpu-moe, тем больше весов модели выгружаются в оперативную память. Параметр n-cpu-moe принимает целочисленное значение, означающее количество первых слоев модели, из которых будут выгружены соответствующие веса. В данном конкретном случае, учитывая квант и предполагаемую конфигурацию 16гб оперативной памяти и 8гб видеопамяти, оптимально использовать n-cpu-moe 29.

Теперь осталось настроить сэмплеры для фронтенда llama-server.
Изначально рекомендуется взглянуть на рекомендации создателей модели. Часто они опубликованы на HuggingFace, иногда в отдельной документации.
Для модели Gemma 4 это температура 1, Top-K 64, Top-P 0.95. Последние три строки команды запуска из примера задают данные сэмплеры. Учтите, что это настройка сэмплеров для веб-интерфейса llamacpp, и если используется другой фронтенд - сэмплеры нужно настраивать в нем. Более того, эта настройка и вовсе опциальна: сэмплеры можно выбрать в фронтенде llama-server.

Команда pause нужна, чтобы терминал не закрывался, если есть ошибка при вводе команды. Например, неправильно указан путь до gguf кванта модели.

Учтите, что важно соблюдать синтаксис: принципиально важно, чтобы некоторые команды начинались с -, некоторые с --. Символ ^ - перенос строки. Важна и пустая строка между концом команды для llama-server и pause. Обязательно ознакомьтесь с документацией llama-server.

Можно запускать модель и полноценно ей пользоваться. Веб-интерфейс llamacpp лаконичен, но удобен и функционален. После запуска он доступен по адресу host:port из параметров запуска выше, т.е. в данном случае по адресу http://127.0.0.1:8080

Далее я покажу, как подключить визуальный прожектор (mmproj файл) для того, чтобы модель могла распознавать картинки, а также параметры запуска для Q8_0 кванта.
При подключении визуального прожектора важны два нюанса.
Во-первых, прожектор тоже занимает видеопамять.
Во-вторых, можно настраивать качество обработки изображений.

Для начала разберемся как подключить прожектор.
Вот пример команды для того же кванта и конфигурации:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

cd "C:\LLM\llamacpp"
llama-server.exe --api-key key ^
--host 127.0.0.1 ^
--port 8080 ^
--model "C:\LLM\Models\gemma-4-26B-A4B\google_gemma-4-26B-A4B-it-Q4_K_M.gguf" ^
--mmproj "C:\LLM\Models\gemma-4-26B-A4B\mmproj-google_gemma-4-26B-A4B-it-f16.gguf" ^
--alias gemma-4-26B-A4B-it-Q4_K_M ^
--flash-attn on ^
-b 512 ^
-ub 512 ^
-np 1 ^
-c 16128 ^
--cache-ram 0 ^
--swa-checkpoints 3 ^
--n-gpu-layers 999 ^
--n-cpu-moe 29 ^
--top-k 64 ^
--top-p 0.95 ^
--temp 1.0

pause

Для подключения визуального прожектора необходимо указать путь до mmproj файла. Поскольку прожектор тоже требует видеопамять, было снижено количество контекста с 64 до 16 тысяч.
Благодаря визуальному прожектору и совместной работе модели и бекенда, изображения преобразуются в токены.

В следующем примере запустим Q8_0 квант, визуальный прожектор и зададим максимальное качество обработке изображений.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

cd "C:\LLM\llamacpp"
llama-server.exe --api-key key ^
--host 127.0.0.1 ^
--port 8080 ^
--model "C:\LLM\Models\gemma-4-26B-A4B\google_gemma-4-26B-A4B-it-Q8_0.gguf" ^
--mmproj "C:\LLM\Models\gemma-4-26B-A4B\mmproj-google_gemma-4-26B-A4B-it-f16.gguf" ^
--image-min-tokens 1120 ^
--image-max-tokens 1120 ^
--alias gemma-4-26B-A4B-it-Q8_0 ^
--flash-attn on ^
-b 1120 ^
-ub 1120 ^
-np 1 ^
-c 200000 ^
--cache-ram 0 ^
--swa-checkpoints 16 ^
--n-gpu-layers 99 ^
--n-cpu-moe 29 ^
--top-k 64 ^
--top-p 0.95 ^
--temp 1.0

pause

Под качеством обработки изображений понимается количество токенов, которое выделяется на изображение.
Максимальное количество токенов определяется архитектурой модели, узнать его можно в документации на HuggingFace или сайте создателей модели.
В случае с Gemma 4 максимум - 1120 токенов на изображение. Соответственно, чтобы добиться максимального качества обработки во всех случаях, задаем минимальное и максимальное количество токенов на изображение - 1120. Делается это командами image-min-tokens и image-max-tokens.

Вы теперь знаете, как запускать модель через llamacpp. Dense модели, MoE модели, модели с поддержкой визуального прожектора.
Поначалу может быть немного трудно подобрать квант и настройки, соответствующие своему железу, но это вопрос опыта. Если не удается уместить квант, всегда можно взять квант меньше, уменьшить количество контекста, отказаться от визуального прожектора или уменьшить батч-файл. Опций много, и со временем вы найдете свой подход.

Также можно, но в целом не рекомендуется квантовать контекст. Для того, чтобы это сделать, необходимо использовать команды -ctk, -ctv. Подробнее можно почитать в документации llama-server.

На этом объяснение подходит к концу. Вы теперь знаете необходимый минимум теории, как работать с llamacpp, плюс-минус представляете как выбирать кванты для своего железа и запускать их.

Куда двигаться дальше и про ценность опыта

Представленная здесь информация - это упрощенный, но весьма конкретный технический фундамент. Однако вопрос использования LLM во многом субъективен. Существует множество нюансов.

Например, как именно промптить (инструктировать, задавать инструкции) модель? Подходов множество, и редко когда можно сказать, что один объективно лучше другого. К тому же, существует множество неопределенных, размытых понятий. Промпт - это и инструкции, и весь запрос пользователя целиком. Если это не первый запрос в чате - то под промптом и вовсе понимается весь чат целиком, который становится новым, расширенным запросом. Помните? Запрос → ответ.

Кванты одной и той же модели могут давать разные результаты, и однозначно определить какие лучше сложно. Существующие метрики PPL и KLD - лучше, чем ничего, но не дают полную картину. Не говоря уже о том, что разные модели и семейства моделей выдают разные результаты, которому одному пользователю могут понравиться, а другому - нет.

Также нельзя сказать, что одна модель однозначно лучше другой только потому, что она больше. Если разница в размере существенна, большая модель скорее всего обладает большим количеством знаний и более совершенным "умом", но это не значит, что она лучше во всех задачах.
Например, существуют модели, специализирующиеся на программировании, и они могут превосходить те, что больше их вдвое-втрое, но предназначаются для общих задач.

Можно продолжать долго, итог один - руководствуйтесь собственным опытом. Прислушивайтесь к опыту других, но не нужно принимать его как истину в последней инстанции или тратить время на споры, оспаривая чужой опыт или доказывая свой.

Ну, а если возникли проблемы или есть что обсудить - помните про GIGO (Garbage In - Garbage Out). Формулируйте свои мысли ясно, прикладывайте контекст и необходимую информацию. В первую очередь, так вы сэкономите время самим себе. Этот принцип важен при взаимодействии и с моделью, и с людьми. Будьте осмысленны в том, что пишете.

Это все. Надеюсь, было полезно. Напоминаю, что критика и предложения принимаются в #llama треде на Дваче.