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

MAATRIX

В официальной библиотеке Ollama у deepseek-r1 на каждый размер всего три варианта файла: Q4_K_M, Q8_0 и fp16 — промежуточных Q5_K_M и Q6_K там нет вовсе. А привычный совет «берите Q4_K_M и не думайте» на рассуждающей модели работает хуже обычного: квант меняет не только качество ответа, но и длину цепочки размышлений, то есть время ожидания. Ниже: где брать недостающие уровни, как низкий квант ломает </think> и почему у настоящей R1 всё иначе.

Три уровня в библиотеке и как называется всё остальное

Первое, обо что спотыкаются: дописать нужный квант к тегу не выйдет.

$ ollama pull deepseek-r1:14b-q5_K_M
Error: pull model manifest: file does not exist

Дело не в регистре букв. Такого файла нет: официальные теги содержат только Q4_K_M, Q8_0 и fp16, а имя обязано включать метку дистилляции — базовую модель, из которой сделан дистиллят: deepseek-r1:14b-qwen-distill-q8_0, deepseek-r1:8b-0528-qwen3-q8_0, deepseek-r1:70b-llama-distill-q4_K_M. Короткий тег без суффикса всегда указывает на Q4_K_M.

Что скачано на деле, показывает ollama show deepseek-r1:8b:

  Model
    architecture        qwen3
    parameters          8.2B
    context length      131072
    quantization        Q4_K_M

Строка architecture qwen3 важнее строки про квант: внутри не DeepSeek, а дообученный Qwen, и при сжатии он ведёт себя как Qwen. Недостающие уровни берут с Hugging Face по имени репозитория, регистр значим строго (Q6_K, не q6_k):

ollama run hf.co/bartowski/DeepSeek-R1-Distill-Qwen-14B-GGUF:Q6_K

Что именно жмётся: дистилляты, MoE и родной FP8

Под именем DeepSeek живут две разные вещи, и жмутся они по-разному.

Дистилляты (1.5B–70B) — обычные плотные Qwen и Llama, дообученные на рассуждениях R1, и правила наследуются от базы: у сборок на Qwen2.5 словарь 151 936 токенов, входная с выходной матрицами съедают до 14 % параметров семёрки, и переход с Q4 на Q3 экономит меньше, чем ждёшь. Разбор эффекта — в статье про квантование Qwen 2.5.

Настоящая R1 на 671B — разреженная MoE: 256 маршрутизируемых экспертов плюс один общий, восемь активных на токен, 61 слой. Скрытый размер 7168, промежуточный размер эксперта 2048, три матрицы на эксперта: 2048 × 7168 × 256 × 3 ≈ 11,3 млрд на слой, и так на 58 слоях с MoE — около 654 миллиардов из 671, то есть 97 % модели, лежит в маршрутизируемых экспертах. На внимание, общий эксперт, три плотных первых слоя и эмбеддинги приходится примерно 17 миллиардов.

Отсюда логика динамических квантов сообщества (Unsloth UD-IQ1_S, UD-Q2_K_XL): эксперты жмутся до полутора-двух бит, а те 17 миллиардов остаются в четырёх-восьми битах. По размеру файла это проценты, по связности — пропасть: наивно сжатая до двух бит R1 уходит в бесконечный повтор и вставляет обрывки кода в середину рассуждения, а сборка с поднятым вниманием отвечает осмысленно на тех же 131 ГБ.

И деталь, которой нет ни у одной другой модели: R1 обучалась и выложена в FP8, а не в bf16, поэтому путь до GGUF выглядит как FP8 → bf16 → квант. Следствие: deepseek-r1:671b-q8_0 весит 713 ГБ, то есть больше оригинального релиза — это не «почти оригинал», а раздутая копия того, что изначально было восьмибитным.

Сколько весит каждый уровень: таблица по всей линейке

Размеры файлов GGUF; прочерк — такого уровня нет.

Шаг между соседними уровнями — 12–17 %, а не «вдвое»: между Q4_K_M и Q5_K_M у 14b всего 1,5 ГБ, экономить нечего. 70b даже в Q4_K_M — это 42,5 ГБ, то есть машина от 64 ГБ RAM и меньше токена в секунду. И держать три уровня рядом дорого: у 14b это 33 ГБ в /usr/share/ollama/.ollama/models.

Почему на рассуждающей модели квант бьёт сильнее

Стандартная метрика качества кванта — рост перплексии на английском тексте — для DeepSeek обманывает. Ответ обычной модели это 100–200 токенов, ответ R1 — цепочка на 600–2000, где каждый шаг опирается на предыдущий: округление, из-за которого модель выбрала другой токен на двухсотом шаге, разворачивается в неверный вывод. Перплексия усредняет, а в рассуждении важен худший шаг.

Замер: deepseek-r1:14b, 8 vCPU / 32 ГБ RAM, Ubuntu 24.04, num_ctx 16384, num_predict 2048, temperature 0.6. Шестьдесят задач: сорок логических и арифметических на русском, двадцать — извлечение JSON.

Главное — предпоследняя строка. Q3_K_M генерирует на 21 % быстрее Q4_K_M, но ответ целиком отдаёт на полторы минуты дольше. На низком кванте модель теряет уверенность, перепроверяет себя и раздувает цепочку вдвое: выигрыш в токенах в секунду съедается ростом их числа. На обычной модели такого эффекта нет.

Последняя колонка — про незакрытый тег: восемь ответов на Q3_K_M уперлись в num_predict, так и не выйдя из блока размышлений, и вернулись пустым content с done_reason: length. Ошибки нет, HTTP 200, ответа тоже нет — для приложения это случайные пропуски.

Ещё два эффекта. Срывы в китайский учащаются: на Q4_K_M вставки внутри <think> попадаются в одном ответе из десяти, на Q3_K_M — в каждом третьем. И размер меняет картину: у 32b тот же Q3_K_M теряет около 6 % верных ответов вместо 20 %, зато 1.5b в Q4_K_M заметно хуже своего же Q8_0 — единственный размер линейки, где восемь бит оправданы.

Второй квант, о котором забывают: KV-кэш

Вторая половина квантования — сжатие кэша ключей и значений, и для DeepSeek она важнее обычного: каждый ход диалога кладёт в историю не только ответ, но и сотни токенов размышлений, так что окно тает вдвое быстрее. Кэш 14b стоит 192 КБ на токен в f16.

Последняя строка честная: q4_0 для кэша на рассуждающей модели стоит столько же качества, сколько понижение весов на целый уровень. Разумный предел — q8_0. Включается парой переменных в drop-in юнита (sudo systemctl edit ollama), и первая обязательна: без флеш-аттеншена тип кэша игнорируется молча.

[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

После перезапуска journalctl -u ollama | grep "KV buffer size" покажет CPU KV buffer size = 1632.00 MiB вместо трёх с лишним гигабайт.

У настоящей R1 и у deepseek-coder-v2 внимание построено на MLA — сжатом латентном представлении KV, и кэш там дешёвый: 68 КБ на токен у 671B и около 30 КБ у шестнадцатимиллиардной MoE, то есть 32k стоят ей гигабайта против шести у плотной 14b. Оговорка: поддержка MLA в llama.cpp появилась не сразу — при странном расходе памяти на coder-v2 начните с обновления Ollama.

Какой уровень брать под задачу и как его скачать

Привычное правило «лучше модель побольше в Q4, чем поменьше в Q8» для DeepSeek работает слабее: на процессоре старшая модель платит за размер дважды — скоростью токена и длиной рассуждения.

Поправки по типу задачи:

• Математика, логика, агенты с инструментами — не ниже Q5_K_M, лучше Q6_K: цепочка длинная, один сбитый шаг портит весь ответ. Для русского сдвиг тот же — наборы для imatrix почти всегда английские, и по-русски деградация приходит раньше.
• Классификация, роутинг, извлечение полей — Q4_K_M достаточно, тем более если рассуждения гасятся через "think": false.
• Код: deepseek-coder-v2:16b — Q6_K (14,1 ГБ). У MoE каждый эксперт маленький, и округление бьёт по нему сильнее, чем по плотной сети: страдает не только выход эксперта, но и маршрутизация. Ниже Q4_K_M опускать не стоит вовсе.

ollama pull deepseek-r1:14b-qwen-distill-q4_K_M
ollama run hf.co/bartowski/DeepSeek-R1-Distill-Qwen-14B-GGUF:Q6_K
ollama rm deepseek-r1:14b     # старый Q4 не нужен

Переквантовать скачанный файл не выйдет: ollama create -q жмёт только из fp16/fp32, а fp16 у 14b — 29,5 ГБ. На видеокарте формат другой: у дистиллятов есть готовые AWQ и GPTQ-Int4 под vLLM, а родные FP8-веса R1 требуют вычислительной способности 8.9 и выше — Hopper или Ada, иначе конвертация в bf16 на 1,34 ТБ. Прочие причины низкой скорости — в разборе почему Ollama медленно генерирует токены.

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

Считать так: файл весов, плюс 10 % на буферы, плюс KV-кэш под ваше окно, плюс 1,5 ГБ системе.

Минимум: 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe. Помещается deepseek-r1:8b в Q4_K_M с окном 8k. Ограничение честное: до Q6_K отсюда не подняться — 6,73 ГБ весов плюс кэш плюс система упрутся в потолок, и первый длинный диалог закончится процессом, убитым по OOM. Восемь гигабайт — ровно один квант без права на эксперимент.

Рабочий вариант: 8 vCPU, 16 ГБ RAM, 160 ГБ NVMe. Здесь появляется выбор: 8b в Q6_K с окном 32k при кэше q8_0, рядом Open WebUI с Postgres в Docker и место под второй квант для сравнения. Это минимальная конфигурация, где разговор про уровень квантования вообще имеет смысл.

Комфорт: 8–16 vCPU, 32 ГБ RAM, от 320 ГБ NVMe. Порог для 14b в Q6_K — уровня, где рассуждения перестают ходить по кругу. Диск тут не про запас: три кванта 14b — уже 33 ГБ.

Границы назову прямо: 70b и тем более 671b на VPS не живут. 42,5 ГБ весов дистиллята Llama требуют 64 ГБ памяти и дают меньше токена в секунду, а динамические кванты R1 на 131–212 ГБ — это выделенный сервер с 256 ГБ RAM. Расчёт памяти по тегам — в разборе сколько RAM нужно для DeepSeek, первый запуск — в статье как запустить DeepSeek на VPS.

Локация — Лондон. Сетевая задержка локальной модели не важна, важно другое — откуда вы качаете. Промежуточных квантов в библиотеке Ollama нет, за ними идут на Hugging Face, а он из российских сетей отвечает нестабильно: двенадцатигигабайтный Q6_K рвётся на середине с dial tcp: i/o timeout, и всё начинается заново. С европейской площадки те же 12 ГБ приезжают за пару минут. Лондон даёт заодно 15–30 мс до пользователей в ЕС и европейскую юрисдикцию, если через модель идут рабочие документы; Франция закрывает тот же сценарий, а российская площадка нужна в одном случае — персональные данные россиян и 152-ФЗ.

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

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