Ollama: сравнение квантования Q4, Q8 и fp16

Что меняет квантование в Ollama

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

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

Если Ollama еще не запущена, начните с установки Ollama на VPS. На этой странице предполагается, что ollama ls уже работает.

Как читать теги квантования Ollama, например q4_K_M

Локальные модели поставляются в виде файлов GGUF — формата, который llama.cpp использует для хранения весов на диске. Ollama построена на базе llama.cpp, поэтому теги Ollama содержат названия квантования из llama.cpp без изменений.

Число обозначает целевую разрядность. q4 означает, что большинство тензоров весов упакованы по четыре бита каждый. q8 означает восемь бит. fp16 означает отсутствие квантования: модель представлена в формате 16-битных чисел с плавающей запятой, с точностью, в которой публикуется большинство моделей.

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

Последняя буква обозначает комбинацию. S, M и L определяют, сколько тензоров будет представлено с разрядностью выше целевой. В q4_K_M тензоры, которые сильнее всего теряют в точности при округлении, сохраняются с большей разрядностью, в то время как основная часть остается 4-битной. Именно поэтому q4_K_M выдает более качественный результат, чем старый q4_0, при почти одинаковом размере файла.

Вместо того чтобы угадывать параметры по введенному имени, проверьте, что именно Ollama хранит на диске:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show выводит architecture, parameters, quantization, context length и embedding length. Строка quantization — это достоверный источник информации о модели, которую вы скачали несколько месяцев назад и уже не помните, какую именно версию выбрали.

Количество бит на вес определяет размер файла

Любая оценка размера начинается с одного числа: сколько бит формат тратит на один вес в среднем по всему файлу. Проект llama.cpp публикует измеренные показатели для Llama 3.1 8B в своей документации по квантованию, и они хорошо применимы к любой плотной модели аналогичной структуры.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

Неожиданным в этой таблице является второй столбец. Q4_K_M — это не четыре бита на вес. Он занимает 4.89 бит, так как масштабные коэффициенты блоков и тензоры с повышенной точностью требуют дополнительного места. Q8_0 занимает 8.5 бит, а не восемь, по той же причине. Используйте измеренное значение, и расчеты будут отличаться от реального размера файла на несколько процентов:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

Это и есть файл Q4_K_M размером 4.58 GiB, полученный из двух чисел. Это также, с достаточной точностью, объем памяти, который занимают веса после загрузки. Ollama не распаковывает данные при загрузке: квантованные веса остаются в памяти в том же упакованном виде, а каждый блок преобразуется непосредственно в момент использования.

Что на самом деле поставляет Ollama для каждого размера модели

Библиотека публикует теги q4_K_M, q8_0 и fp16 для большинства семейств моделей. Некоторые новые семейства нарушают этот шаблон и представлены в библиотеке только облачными тегами, которые нельзя загрузить локально — именно с этим ограничением вы сталкиваетесь, пытаясь запустить GLM 5.2 на VPS. Ниже приведены размеры Qwen3 по состоянию на август 2026 года, полученные из списка тегов на странице модели. Каждая цифра ниже — это объем на диске до того, как модель попадет в RAM, и две или три такие модели вместе заполнят корневой раздел небольшого VPS, поэтому стоит знать, где Ollama хранит загруженные модели, прежде чем начинать собирать теги.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

Тег по умолчанию здесь имеет значение. ollama pull qwen3:8b загружает ровно те же 5.2 ГБ, что и ollama pull qwen3:8b-q4_K_M, поскольку тег без суффикса и есть сборка q4_K_M. Q4_K_M — это не компромисс, на который библиотека идет неохотно. Это выбор по умолчанию, сделанный разработчиками upstream, поэтому использование этого варианта — разумный первый шаг для любой модели, которую вы еще не тестировали самостоятельно. Те же соображения определяют выбор тегов при запуске Qwen 3 на VPS.

Пропорции сохраняются для каждой строки. Переход от q4_K_M к q8_0 увеличивает размер примерно на семьдесят процентов, а не ровно в два раза, поскольку тензоры эмбеддингов и вывода масштабируются иначе, чем остальные параметры. Версия fp16 примерно в три раза больше, чем q4_K_M. Модель 32B в формате q4_K_M занимает 20 ГБ весов, что уже превышает объем, который может вместить сервер с 16 ГБ RAM при использовании любого контекстного окна. Более подробный обзор того, что подходит для конкретной машины, см. в разделе какие модели можно разместить самостоятельно.

Почему KV-кэш — это вторая, зависящая от контекста стоимость

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

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

Эти параметры модели берутся из её конфигурации: 36 слоев, 8 голов ключей/значений и размерность головы 128. ollama show содержит архитектуру и количество параметров, а config.json модели на Hugging Face — остальные данные. Умножьте стоимость одного токена на размер окна, и кэш перестанет быть погрешностью вычислений.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

При стандартном окне Ollama в 4096 токенов кэш добавляет 0.6 ГБ сверх весов. Увеличьте окно до 32k, и только один кэш достигнет 4.83 ГБ, что почти равно объему памяти для квантованных весов, а минимальный объем для всей модели составит 10 ГБ. Это нижний предел, так как поверх него еще располагаются вычислительные буферы и операционная система. Итоговое значение можно увидеть в столбце SIZE команды ollama ps после загрузки модели.

Размер окна задается на сервере, а не для каждого запроса, если вы запускаете Ollama как сервис:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Для установки через systemd используйте drop-in файл:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Перезапустите сервис с помощью sudo systemctl restart ollama, затем проверьте столбец CONTEXT в ollama ps, чтобы подтвердить размер окна, с которым была загружена модель. OLLAMA_KV_CACHE_TYPE позволяет квантовать сам кэш: f16 используется по умолчанию, q8_0 потребляет примерно вдвое меньше памяти, чем f16, а q4_0 — примерно четверть. Это глобальная настройка, поэтому она применяется ко всем моделям на сервере. На маломощном оборудовании с большим окном уменьшение кэша вдвое освобождает больше памяти, чем любое другое изменение. В Настройка num_ctx и связанные с этим затраты подробно описано само окно. Кэш также выделяется для каждого слота параллельного запроса, а не один раз на сервер, поэтому разрешение Ollama отвечать на два запроса одновременно удваивает рассчитанный вами объем памяти. Это арифметика, лежащая в основе выбора количества параллельных слотов и лимита очереди.

Что поместится на VPS объемом 8, 16 или 32 ГБ

Вес модели, плюс KV-кэш, плюс запас оперативной памяти для операционной системы и других запущенных процессов. Запас в 2 ГБ является комфортным для небольшого VPS.

8 ГБ. Модель 4B в квантовании q4_K_M занимает 2.6 ГБ и оставляет место для длинного контекстного окна. Модель 8B в q4_K_M помещается со стандартным окном 4k, но с минимальным запасом. Не планируйте использовать 8B с окном 32k, так как нижний порог в 10 ГБ уже превышает возможности системы.

16 ГБ. Модель 8B в q4_K_M с окном 16k или 32k работает комфортно. Модель 14B в q4_K_M требует 9.3 ГБ под веса и помещается с умеренным размером окна. Модель 8B в q8_0 занимает 8.9 ГБ, поэтому она также поместится; сравнение этих двух вариантов на ваших собственных промптах — самое полезное занятие, которое можно провести в рамках этой темы.

32 ГБ. Модели 14B в q8_0 (16 ГБ) и 32B в q4_K_M (20 ГБ) загружаются успешно. Сборка 32B с большим окном будет работать на пределе возможностей, поэтому следите за ollama ps, вместо того чтобы полагаться на предположения.

Что деградирует при квантовании в первую очередь

Ошибка квантования распределяется по работе модели неравномерно. Связность речи сохраняется дольше всего, и именно поэтому повреждения легко пропустить: модель с плохим квантованием всё ещё пишет грамотные предложения. В первую очередь страдает точность. Точное воспроизведение номера версии, сигнатуры API или даты. Длинные цепочки рассуждений, где небольшая ошибка на втором шаге приводит к неверному ответу на восьмом. Строгие форматы вывода, где одна неверная скобка делает вызов инструмента нерабочим.

Последний пункт — это практический тест. Когда модель должна вернуть JSON, который парсит ваш код, повреждения от квантования проявляются как ошибка парсинга, а не как едва заметное ухудшение качества текста, поэтому вы заметите это в тот же день. Агент для написания кода — самый суровый вариант этого теста, так как он заставляет модель выполнять вызов инструмента за вызовом, поэтому настройка агента на ваш сервер Ollama выявит слишком агрессивное квантование в течение нескольких часов.

Ниже четырёх бит потери становятся значительными. Типы q3 и двухбитные квантования существуют для тех, кто пытается уместить большую модель на слабое оборудование, и они являются реальным вариантом, когда альтернатива — вообще не запускать модель. Это плохой выбор по умолчанию. Между q4_K_M и q8_0 разрыв достаточно мал, чтобы опубликованная таблица перплексии не помогла вам определиться с выбором для вашей рабочей нагрузки, поэтому не пытайтесь полагаться на неё. Запустите оба варианта на тридцати собственных промптах и оцените результат.

Когда q8_0 или fp16 оправдывают использование RAM

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

Используйте fp16 только по двум причинам. Либо вы сами квантуете модель и вам нужен исходный файл, либо вы замеряете базовые показатели, чтобы понять, сколько потеряла ваша 4-битная сборка. Работа на fp16 потребляет в три раза больше памяти, чем q4_K_M, при разнице, которую большинство людей не заметит в слепом тесте, а на системе только с CPU это также снижает скорость генерации токенов в три раза.

Более важное правило при фиксированном объеме памяти: большая модель в квантовании q4_K_M обычно превосходит меньшую модель в q8_0. 9.3 ГБ весов модели 14B против 8.9 ГБ весов модели 8B занимают почти одинаковый объем RAM (оперативной памяти), при этом большая модель обладает большими знаниями. Проверьте это на своих собственных промптах, а не принимайте на веру.

Инференс только на CPU ограничен пропускной способностью памяти

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

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

50 ГБ/с — это примерное теоретическое значение для двухканальной памяти DDR4-3200. Ваша доля будет меньше, так как VPS делит эту шину со всеми остальными арендаторами на машине, поэтому рассматривайте эти цифры как недостижимый максимум. Важна сама зависимость: при работе на CPU уменьшение количества бит на вес вдвое примерно удваивает скорость генерации токенов. Квантование — это самый эффективный рычаг ускорения на машине без GPU. Будет ли полученная скорость приемлемой, зависит от модели, а в статье Nemotron 3.5 Lightning на VPS этот расчет выполнен для конкретной сборки, тега и объема оперативной памяти. Вторая часть времени ожидания зависит от того, какой объем текста решит сгенерировать модель: при скорости 10 токенов в секунду ответ из 600 токенов займет целую минуту, поэтому ограничение ответа через num_predict часто экономит больше времени, чем очередной шаг снижения точности.

Обработка промпта работает иначе. Чтение длинного промпта ограничено вычислительными ресурсами, а не пропускной способностью, поэтому дополнительные ядра здесь помогают, хотя почти не влияют на скорость генерации. Если машина быстро обрабатывает промпт на 4k токенов, а затем медленно генерирует ответ — это нормальное поведение.

Не принимайте расчеты на веру. Измерьте количество токенов в секунду на своей машине с одним и тем же промптом при каждом уровне квантования и опирайтесь на полученные вами цифры.

Самостоятельное квантование модели

Ollama может создать квантованную модель из исходных данных в формате fp16 или fp32. Это необходимо, если вы выполнили дообучение (fine-tuning) и для модели еще нет готового тега в библиотеке. Укажите в Modelfile путь к неквантованным весам:

FROM /path/to/my/model/f16

Затем выполните сборку и проверку:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize поддерживает q8_0, q4_K_S и q4_K_M. Здесь нет опций q6_K или q5_K_M, поэтому для них квантование выполняется с помощью собственного инструмента llama.cpp, после чего готовый файл GGUF импортируется. У этого способа импорта есть свой нюанс: несоответствие шаблона чата, из-за которого модель начинает выдавать бессвязные ответы. Процесс решения этой проблемы описан в разделе импорт GGUF-файла в Ollama. Строка quantization из ollama show позволяет убедиться, что сборка выполнена согласно вашим параметрам.

Что вы увидите при возникновении проблем

Всё выполняется на CPU, хотя вы ожидали работу на GPU. Изучите столбец PROCESSOR:

ollama ps

Там выводится 100% GPU, 100% CPU или разделение, например 48%/52% CPU/GPU. Разделение означает, что веса модели вместе с KV-кэшем не поместились в VRAM (видеопамять, память на графической карте), поэтому часть модели была размещена в системной оперативной памяти. Скорость при этом падает почти до уровня работы только на CPU, так как генерация каждого токена ожидает завершения работы медленной части. Уменьшите размер контекстного окна, используйте квантование кэша или загрузите сборку меньшего размера. Добавление ядер процессора не поможет.

Модель завершается принудительно (killed) во время загрузки. Проверьте логи ядра и службы:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

Строка, содержащая Out of memory: Killed process, означает, что суммарный объем весов, KV-кэша и буферов превысил объем доступной оперативной памяти на сервере. На VPS без настроенного swap вся система может зависнуть на несколько секунд перед появлением этой строки.

Качество ответов ухудшилось, хотя вы ничего не меняли. Две сборки одной и той же модели могут находиться в ollama ls под разными тегами, и скрипт, который скачивает образ без указания тега, будет следовать за тем, на что в данный момент указывает библиотека. Выполните ollama show для конкретного тега, который запрашивает ваш клиент, и прочитайте строку quantization, вместо того чтобы доверять имени в конфигурационном файле.

FAQ

Какую квантованную версию Ollama мне выбрать?

Начните с q4_K_M. Это стандартный тег, который библиотека Ollama использует по умолчанию для большинства моделей, поэтому ollama pull qwen3:8b и ollama pull qwen3:8b-q4_K_M загружают один и тот же файл. Переходите на q8_0 только в том случае, если у вас достаточно свободной оперативной памяти, а задача чувствительна к мелким ошибкам, например, при вызове инструментов (tool calling) или генерации структурированного JSON. Если объем памяти ограничен, модель большего размера с квантованием q4_K_M обычно работает лучше, чем модель меньшего размера с q8_0. Протестируйте это сочетание, прежде чем расходовать RAM на высокую точность.

Означает ли q4_K_M действительно четыре бита на вес?

Нет. Для модели Llama 3.1 8B этот показатель составляет 4.89 бит на вес, так как каждый блок весов хранит собственный масштаб, а наиболее важные тензоры сохраняются в более широком формате. По той же причине Q8_0 фактически использует 8.5 бит, а не восемь. Используйте измеренное значение для расчетов: количество параметров, умноженное на количество бит на вес и деленное на восемь, дает размер файла в байтах.

Сколько RAM нужно для модели 8B на VPS только с CPU?

Сложите объем весов, KV-кэша и запас для системы. Модель Qwen3 8B с квантованием q4_K_M занимает 5.2 ГБ. При стандартном окне контекста в 4096 токенов кэш добавляет 0.6 ГБ, что дает минимальный порог около 5.8 ГБ без учета вычислительных буферов и операционной системы. При окне в 32k только один кэш потребует 4.83 ГБ. Планируйте 8 ГБ для короткого окна и 16 ГБ, если вам нужно длинное.

Почему модель загружает CPU на 100%, если в системе есть GPU?

Выполните ollama ps и посмотрите на столбец PROCESSOR. Значение 100% CPU или частичное распределение, например 48%/52% CPU/GPU, означает, что веса и KV-кэш не поместились в VRAM, поэтому Ollama перенесла часть или всю модель в системную память. Частая причина — размер окна контекста превышает возможности видеокарты, так как кэш выделяется под весь объем окна при загрузке модели. Уменьшите окно с помощью OLLAMA_CONTEXT_LENGTH, установите OLLAMA_KV_CACHE_TYPE=q8_0, чтобы сократить кэш вдвое, или загрузите модель с меньшей квантованной версией.