Квантование 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 для большинства семейств моделей. Ниже приведены размеры Qwen3 по состоянию на август 2026 года, полученные из списка тегов на странице модели.

[
  {
    "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 ГБ оперативной памяти при использовании любого контекстного окна. Более подробный обзор того, что подходит для конкретного оборудования, см. в какие модели можно разместить на собственном сервере.

Почему 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 и связанные с этим затраты подробно описана работа с размером окна.

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

Учитывайте вес модели, размер KV cache, а также запас оперативной памяти для работы операционной системы и других процессов. Запас в 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

Используйте 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.

Обработка промпта работает иначе. Чтение длинного промпта ограничено вычислительной мощностью, а не пропускной способностью, поэтому дополнительные ядра здесь помогают, в то время как на скорость генерации они почти не влияют. Если сервер быстро обрабатывает промпт объемом 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-файл. Строка 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, поэтому протестируйте этот вариант, прежде чем выделять дополнительную оперативную память под точность.

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

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

Сколько оперативной памяти нужно для модели 8B на VPS без GPU?

Сложите объем весов, 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, чтобы сократить кэш вдвое, или загрузите модель с меньшей квантованностью.