Какое квантование выбрать для Llama 3

MAATRIX

Совет «берите Q4_K_M и не думайте» родился на Llama 2, и на третьем поколении работает хуже. Квантование Llama 3 стоит дороже: модель обучена на 15 триллионах токенов, избыточности в весах почти не осталось, и то же четырёхбитное округление обходится вдвое большей потерей качества. Ниже — замеры, размеры файлов и три места, где сжатие ломается первыми.

Почему Llama 3 переносит квантование хуже, чем Llama 2

Сжатие весов модель переживает за счёт избыточности, а та появляется, когда параметров много, а данных было мало. У Llama 3 наоборот: через восьмимиллиардную модель прогнали 15 триллионов токенов, вплотную подойдя к её пределу. Веса упакованы плотно, и округление бьёт по делу. Меряется это отношением «токенов обучения на параметр» — разница между поколениями шестикратная.

Замер: wikitext-2, 200 чанков по 512 токенов, llama-perplexity из llama.cpp, эталон — логиты fp16. Медианная KL-дивергенция честнее перплексии, она ловит уехавшие отдельные токены: у восьмёрки на Q6_K это 0,006, на Q4_K_M — 0,042, на Q3_K_M — уже 0,17.

У соседнего qwen2.5:7b тот же Q4_K_M даёт +1,3 %, вдвое меньше (разбор его уровней). Отсюда вывод: для Llama 3 привычный Q4_K_M — не «золотая середина», а нижняя граница рабочего диапазона. Поправка на язык: числа сняты на английском, а русского нет среди восьми официально поддерживаемых языков Llama 3.1 — он деградирует раньше и сдвигает границу ещё на полшага.

Теги Ollama: полный набор уровней и ловушка со словом text

Здесь Llama выгодно отличается от других семейств: в библиотеке лежат все K-кванты, а не три уровня, как у deepseek-r1. Для llama3.1:8b доступны q2_K, q3_K_S/M/L, q4_0, q4_1, q4_K_S, q4_K_M, q5_0, q5_1, q5_K_S, q5_K_M, q6_K, q8_0 и fp16.

text вместо instruct. Тег llama3.1:8b-text-q4_K_M — базовая модель без дообучения на инструкциях. Она не отвечает, а продолжает текст: спросили «Что такое KV-кэш?» — получили ещё десять похожих вопросов подряд. Это списывают на низкий квант и качают уровень выше. Отличать по шаблону: ollama show <тег> --template у инструкт-версии печатает строку с <|start_header_id|>system<|end_header_id|>, у text-варианта возвращает пустоту.

Четыре legacy-тега в этом списке (q4_0, q4_1, q5_0, q5_1) — старая схема с одним множителем на блок из 32 весов: при том же размере файла q4_0 теряет вдвое больше q4_K_M, и на x86 брать его незачем. I-квантов и сборок _L, где входная и выходная матрицы подняты до Q8_0, в библиотеке нет. Репозитории Meta на Hugging Face закрыты подтверждением лицензии, а короткий синтаксис токен не передаёт — берите открытые зеркала с imatrix-калибровкой:

ollama run hf.co/bartowski/Meta-Llama-3.1-8B-Instruct-GGUF:Q6_K_L

Отдельная классика — чужой GGUF на старой сборке llama.cpp: токенизатор Llama 3 перешёл на BPE в стиле tiktoken, и бинарники старше весны 2024 его не понимают. Лечится обновлением Ollama, переконвертацией файла — нет.

llama_model_load: error loading model: error loading model vocabulary:
unknown pre-tokenizer type: 'llama-bpe'

Сколько весит каждый уровень и куда уходит место

Размеры GGUF по линейке.

Главное здесь: весь осмысленный диапазон восьмёрки укладывается в 2,6 ГБ — от 4,02 ГБ на Q3_K_M, где модель путается в числах, до 6,60 ГБ на Q6_K, где её не отличить от оригинала. Разница между «врёт» и «эталон» — одна планка памяти, а не другой класс машины.

У маленьких моделей арифметика перевёрнута из-за словаря: он вырос с 32 000 токенов у второго поколения до 128 256. У 1B скрытый размер 2048 и привязанные эмбеддинги — одна матрица на вход и выход, 2048 × 128 256 = 263 млн, то есть 21 % всей модели; у 3B — 12 %, у 8B с раздельными матрицами — 13 %, у 70B — 3 %. Отсюда правило: llama3.2:1b и :3b берите сразу в Q6_K или Q8_0. Путь от Q4_K_M до Q8_0 стоит у однобитной 510 МБ, у трёшки — 1,4 ГБ, а качество меняется сильнее, чем у восьмёрки: эмбеддинги жмутся вместе со всем и тащат обе стороны сети.

Лежит всё в /usr/share/ollama/.ollama/models на корневом разделе; три уровня восьмёрки рядом — 17,3 ГБ, и разные кванты не дедуплицируются. Считать расход через du -sh, чистить лишнее через ollama rm llama3.1:8b-instruct-q4_K_M.

Где ломается на практике: русский, JSON и вызовы инструментов

Перплексия усредняет, а в работе важен худший случай. Стенд: 8 vCPU AMD EPYC, 16 ГБ RAM, Ubuntu 24.04, Ollama, llama3.1:8b-instruct, num_ctx 8192, temperature 0.2. Шестьдесят задач: двадцать ответов на русском, двадцать извлечений полей в JSON по схеме, двадцать вызовов функции с обязательным аргументом.

Последняя колонка проседает раньше остальных. Llama 3.1 помечает вызов инструмента служебными токенами: встроенные идут после <|python_tag|>, а сообщение, за которым последует ответ инструмента, закрывается не обычным <|eot_id|>, а <|eom_id|>. Токены редкие, их вероятности размываются первыми, и модель выдаёт верный по смыслу JSON без обёртки:

{"message":{"role":"assistant","content":"{\"name\": \"get_weather\",
 \"parameters\": {\"city\": \"Москва\"}}","tool_calls":[]},"done_reason":"stop"}

Массив tool_calls пуст, HTTP 200, ошибки нет: приложение не видит вызов и отвечает текстом, а причину ищут в коде агента — где угодно, кроме кванта.

Тонкость про JSON: если передавать схему через поле format, Ollama включает грамматику при декодировании, и синтаксически валидным ответ будет на любом кванте. Гарантируется только форма — на Q3_K_M модель вернёт объект с нужными ключами, но положит в amount строку вместо числа, а в date сегодняшнее число вместо даты из документа. Ошибка молчаливая, всплывает через неделю.

Скорость: сколько на самом деле даёт понижение кванта

Генерация на процессоре упирается в память: на каждый токен читаются все веса, поэтому токенов/с ≈ полоса памяти ÷ размер файла. Обработка промпта идёт батчем и от кванта почти не зависит. Замер на том же стенде, DDR4-3200 с измеренными mbw -n 5 1024 38 ГБ/с, окно 8192, ollama run --verbose:

Переход с q4_K_M на q3_K_M даёт 17 % скорости и обходится вчетверо большей потерей качества — худшая сделка в таблице. Обратный ход стоит те же 15 %: 6,5 против 5,5 токенов в секунду при чтении вслух не различимы, а разница в доле распознанных вызовов функций — вполне.

IQ4_XS ломает ожидания: файл на 10 % меньше q4_K_M, генерация медленнее на 20 %, промпт жуётся в полтора раза дольше — распаковка через кодовые книги съедает выигрыш. I-кванты нужны на видеокарте, где вопрос «влезет в VRAM или нет», и почти бесполезны на CPU. Прочие причины низкой скорости — в разборе почему Ollama медленно генерирует токены.

Второй критерий выбора — влезет ли квант вообще. Ollama проверяет это до загрузки и отвечает отказом, а не свопом:

Error: model requires more system memory (9.2 GiB) than is available (7.4 GiB)

Здесь 9,2 ГиБ — веса плюс KV-кэш под окно плюс накладные; что заняла загруженная модель, показывает ollama ps в колонке SIZE. Полная арифметика — в таблице RAM для Llama 3.

Какой уровень брать под задачу и что не так с официальными квантами Meta

Сначала по бюджету памяти: на фиксированном объёме всегда стоит выбор «модель побольше пожатее или поменьше поточнее».

Правило «следующий размер в низком кванте лучше предыдущего в высоком» на Llama 3 работает только до Q4_K_M: llama3.2:3b-instruct-q6_K осмысленнее llama3.1:8b-instruct-q3_K_S, хотя весит вдвое меньше. Поправки по задаче:

• Русский чат и суммаризация — Q5_K_M минимум, Q6_K ровнее в падежах и терминах.
• Вызовы функций, агенты, строгий JSON — Q6_K: пропущенный вызов дороже полутора гигабайт памяти.
• Английский текст, классификация, роутинг — Q4_K_M хватает.
• llama3.2:1b и :3b — только Q6_K или Q8_0.
• Файнтюны — на полшага выше базовой рекомендации: правки от дообучения тоньше весов и стираются раньше.

В октябре 2024 года Meta выпустила официальные квантованные версии Llama 3.2 1B и 3B — редкий случай, когда автор модели сделал эту работу сам. Рецептов два: обучение с учётом квантования плюс LoRA-адаптеры (максимум качества) и SpinQuant с поворотами матриц (максимум переносимости). Схема одна: четыре бита группами по 32 веса на линейных слоях, восемь бит поканально на эмбеддингах и голове. Против bf16 заявлены размер меньше на 56 %, память — на 41 %, скорость на телефоне выше в 2–4 раза.

Оговорка честная: в Ollama их не загрузить — сборки выложены в формате ExecuTorch под телефоны, а не в GGUF. Ближайший аналог на сервере — imatrix-кванты. Из той же серии официальный Llama-3.1-405B-Instruct-FP8: восемь бит Meta считает безопасным потолком, а всё ниже отдаёт сообществу.

Какой сервер под выбранный квант взять в MAATRIX

Выбор кванта и выбор тарифа — одна задача с двух сторон. Есть машина — уровень берётся из таблицы выше. Есть требование к качеству — считаем обратно: файл нужного уровня плюс 10 % на буферы, KV-кэш под окно и 1,5 ГБ системе.

Минимум — 4 vCPU / 8 ГБ RAM / 60 ГБ NVMe. Здесь живёт llama3.2:3b-instruct-q6_K (2,64 ГБ) с окном 16k и скоростью около 12 токенов в секунду: бот, разметка, извлечение полей. Восьмёрка влезает ровно в одном виде — Q4_K_M с окном 8k и без соседей: веса, гигабайт кэша и система съедают 7,5 из восьми. Подняться до Q5_K_M нельзя, а для Llama 3 это принципиально: у неё Q4_K_M — нижняя граница, а не середина.

Комфортный вариант — 8 vCPU / 16 ГБ RAM / 120–160 ГБ NVMe. Целевая конфигурация: llama3.1:8b-instruct-q6_K (6,60 ГБ) с окном 16k, рядом Open WebUI с Postgres и место под второй-третий квант для сравнения на своих задачах. Переход с 8 на 16 ГБ покупает не «запас», а другое качество ответов: разница Q4_K_M против Q6_K на русском и на вызовах функций видна без метрик.

Для llama3.3:70b считайте от 64 ГБ RAM: даже Q4_K_M это 42,5 ГБ, а Q2_K на 26,4 ГБ бессмысленна — семидесятка в двух битах проигрывает восьмёрке в шести. И прямо: на процессоре 70B выдаёт 1,5–2 токена в секунду, для интерактива непригодно, нужен GPU. Квантовать свой файнтюн через ollama create -q q5_K_M можно только из fp16, выкачав сперва 16,1 ГБ исходника.

Локация — Лондон (UK). Сетевая задержка локальной модели безразлична, веса лежат у вас. Важна скорость закачки, и здесь вдвойне: выбрать квант нельзя, не скачав два-три варианта. Семнадцать гигабайт по гигабитному каналу с британской площадки — около трёх минут, а из российских сетей многогигабайтные слои реестра Ollama и Hugging Face регулярно рвутся на середине, и ollama run hf.co/... за imatrix-сборкой часто не отвечает вовсе. Лондон даёт заодно 15–30 мс до пользователей в ЕС и европейский правовой периметр, если через модель идут рабочие документы. Оговорка: ограничение лицензии Llama 3.2 для мультимодальных версий касается юрисдикции владельца компании, а не адреса машины, — переездом сервера не снимается. Данные обязаны оставаться в России по 152-ФЗ — берите российскую площадку.

Ollama из каталога apps.maatrix.io ставится автоматически при заказе: вставлять команды не нужно, автоустановка работает на Ubuntu и Debian, доступы появляются в личном кабинете в разделе «Доступ». Дальше остаётся один ollama pull с полным тегом. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT. Установка по шагам — в статье как запустить Llama 3 на VPS, поломки после запуска — в разборе частых ошибок.

Частые вопросы