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

MAATRIX

Под именем Mistral в библиотеке Ollama живут модели с разными словарями, и одинаковый на вид тег q4_K_M ведёт себя на них по-разному. У семёрки уровней квантования полтора десятка, у mistral-small3.2 — три, а у mistral-nemo почти гигабайт файла уходит на словарь, который толком не жмётся. Ниже — сколько весит каждый уровень, на каком кванте разваливаются вызовы функций и почему на русском тексте более крупная модель отвечает быстрее мелкой.

Что на самом деле скачивается по тегу mistral

Короткий тег mistral — это Mistral-7B-Instruct-v0.3 в Q4_K_M. Что внутри, показывает ollama show mistral:

  Model
    architecture        llama
    parameters          7.2B
    quantization        Q4_K_M

architecture llama — не подмена модели: в GGUF Mistral описан схемой тензоров Llama, отличаясь параметрами (n_head_kv 8, head_dim 128, без sliding-window с v0.2). Смотрите на parameters и quantization.

Дальше начинается разнобой:

• mistral (7B v0.3) — полная лестница от q2_K до q8_0 и fp16, включая q3_K_L, q4_K_S, q5_K_M.
• mistral-nemo (12B, совместно с NVIDIA) — набор уже, но Q5_K_M и Q6_K есть; словарь Tekken на 131 072 токена, окно 128k.
• mistral-small3.1 / 3.2 (24B) — только Q4_K_M, Q8_0 и fp16.
• mixtral (8x7B, 8x22B) — MoE, лестница широкая, но модель легаси.
• codestral, devstral, magistral — специализированные 22–24B на той же базе.

Имя тега включает ревизию, без неё уровень не скачается:

$ ollama pull mistral-small3.2:24b-q5_K_M
Error: pull model manifest: file does not exist

Правильно — mistral:7b-instruct-v0.3-q5_K_M, mistral-nemo:12b-instruct-2407-q6_K. Регистр значим: q и цифры строчные, буквы семейства заглавные. И учтите, что mistral-small3.1/3.2 мультимодальные: картиночный энкодер лежит отдельным проектором и в квантование не попадает — при любом уровне весов это лишние 0,9 ГБ в f16.

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

Размеры GGUF в десятичных гигабайтах, последняя колонка — эффективные биты на вес для семёрки (размер × 8 / 7,25 млрд).

Шаг между уровнями — 12–17 %, а не «вдвое». У семёрки между Q4_K_M и Q5_K_M всего 760 МБ, между Q4_K_S и Q4_K_M — 230 МБ: суффикс _S забирает заметную долю качества за четверть гигабайта.

У Mixtral Q4_K_S и Q4_K_M весят одинаково. Правило _M поднимает до Q6_K выходную матрицу и часть attn_v/ffn_down, но у MoE масса лежит в экспертных тензорах, до которых оно не дотягивается. Берите _M, он не дороже. Полный расчёт памяти вместе с кэшем — в разборе сколько RAM нужно для Mistral.

Словарь: почему у 7B квантование честнее, чем у Nemo

У Mistral 7B v0.3 словарь 32 768 токенов при скрытом размере 4096: входная и выходная матрицы — по 32768 × 4096 = 134 млн параметров, вместе 268 млн из 7,25 млрд, то есть 3,7 % модели. У Nemo словарь Tekken на 131 072 токена при размере 5120: 131072 × 5120 = 671 млн на матрицу, вместе 1,34 млрд из 12,25 млрд — почти 11 %. У Small 24B словарь тот же, но доля падает до 5,7 %.

Видно это в логе конвертации семёрки — 291 тензор, первый и последний:

[   1/ 291] token_embd.weight - [ 4096, 32768,  1,  1], type =    f16,
            converting to q4_K .. size =   256.00 MiB ->    72.00 MiB
[ 291/ 291] output.weight     - [ 4096, 32768,  1,  1], type =    f16,
            converting to q6_K .. size =   256.00 MiB ->   105.00 MiB

177 МиБ на оба тензора против 927 МиБ у Nemo (у него 363 тензора, слоёв 40, а не 32). Следствия два. На семёрке суффикс _L дёшев: Q3_K_L держит выходную матрицу в Q8_0 и стоит 310 МБ сверх Q3_K_M — лучший способ спасти трёхбитную сборку, ведь именно эта матрица отвечает за выбор конкретного токена и ломается первой. На Nemo промежуточные варианты бессмысленны: Q4_K_S экономит против Q4_K_M всего 360 МБ при заметной потере, так что либо Q4_K_M, либо сразу Q5_K_M.

Отдельная грабля Nemo: у него head_dim = 128, хотя 5120 / 32 = 160. Старые сборки llama.cpp считали размер головы делением и падали на загрузке:

llama_model_load: error loading model: check_tensor_dims: tensor 'blk.0.attn_q.weight'
has wrong shape; expected  5120,  5120, got  5120,  4096

Поддержка появилась в llama.cpp сборки b3436 и в Ollama 0.3. Берёте GGUF из стороннего репозитория — смотрите дату сборки: файл будет битым при любом кванте.

Замер: что ломается первым — JSON, а не текст

Перплексия на английском тексте для Mistral говорит мало: модель чаще работает агентом с вызовом функций, а там ошибка бинарная. Формат жёсткий — служебный токен [TOOL_CALLS] и следом валидный JSON-массив.

Стенд: 8 vCPU, 32 ГБ RAM, Ubuntu 24.04, Ollama на CPU, полоса памяти по sysbench memory --memory-block-size=1M --memory-total-size=20G run — 29 ГБ/с. mistral-nemo:12b, num_ctx 8192, temperature 0.3 (рекомендованная Mistral для Nemo). 120 задач: 60 вызовов функций со строгой схемой и 60 извлечений полей из русского текста.

Типичный сбой на Q3_K_M выглядит не ошибкой, а обычным ответом — модель забывает служебный токен и описывает вызов словами:

Я вызову функцию get_order с параметром order_id = 10423 и верну статус.

Второй по частоте сбой — обёртка в markdown-блок или лишняя запятая перед скобкой, и тогда падает уже клиент: Error: invalid character '}' looking for beginning of object key string. На Q2_K добавляется третий: ответ на русский вопрос через два-три предложения сползает в английский.

Скорость считается просто — на токен читается весь файл, значит токенов/с ≈ полоса ÷ размер. У семёрки: q8_0 — 3,6, q6_K — 4,6, q5_K_M — 5,3, q4_K_M — 6,2, q3_K_M — 7,5 tok/s. Из ряда выбивается IQ4_XS: файл на 10 % меньше q4_K_M, а генерация 5,0 tok/s — распаковка через кодовые книги съедает выигрыш, и I-кванты остаются вариантом для видеокарты. Прочие причины низкой скорости — в статье Ollama медленно генерирует токены.

Токенизатор и KV-кэш: где квант конкурирует с окном

Разница словарей бьёт по производительности сильнее, чем выбор между Q4 и Q5. Замер на одном русском тексте в 10 000 знаков, поданном промптом:

Модель вдвое крупнее обрабатывает тот же русский текст быстрее и занимает под кэш меньше памяти: Tekken режет кириллицу примерно вдвое экономнее. Длинные русские промпты — повод брать Nemo, а не семёрку. На английском и на коде разрыв почти исчезает.

Кэш считается точно: 2 × слои × kv-головы × head_dim × 2 байта на токен.

Отсюда честная неприятность: окно 128k у Nemo стоит 20 ГиБ кэша — почти втрое больше самих весов в Q4_K_M. Ollama по умолчанию открывает 4096 токенов (OLLAMA_CONTEXT_LENGTH), и этого не замечают, пока не упрутся в обрезанный документ.

На 16 ГБ выбор у Nemo такой: Q6_K с окном 8k (10,1 + 1,25) или Q4_K_M с окном 32k (7,48 + 5,0). Для RAG берите второе — потеря трёх вызовов из шестидесяти дешевле обрезанного контекста; для агента с инструментами первое. Компромисс — кэш в q8_0: освобождает половину и требует OLLAMA_FLASH_ATTENTION=1, без него тип кэша игнорируется молча.

Mixtral и остальная линейка: где правила переворачиваются

Правило «меньше файл — быстрее генерация» верно для плотных моделей. У mixtral:8x7b оно ломается: в нём 46,7 млрд параметров, но на токен активны 2 эксперта из 8. Экспертные тензоры — 45,1 млрд из 46,7, активная часть выходит 1,6 + 2/8 × 45,1 ≈ 12,9 млрд, с памяти читается около 7,8 ГБ на токен вместо 26,4. Mixtral в Q4_K_M отдаёт примерно 3,4 tok/s против 1,9 у mistral-small3.2:24b, который весит вдвое меньше.

Две оговорки. Ниже Q4_K_M на MoE спускаться нельзя: Q2_K соблазнителен, 17,3 ГБ влезают в 24 ГБ памяти, но округление бьёт и по маршрутизатору — модель выбирает не тех экспертов, и ответ разваливается сильнее, чем у плотной модели такого же размера файла. И Mixtral 8x7B — легаси конца 2023 года: mistral-small3.2:24b в Q4_K_M обходит его по качеству при вдвое меньшем файле. Mixtral оправдан, когда памяти 32 ГБ и больше, а важна скорость.

У codestral:22b словарь 32k, как у семёрки, и та же чувствительность выходной матрицы: ниже Q5_K_M не берите — пропущенная скобка ломает файл целиком, тогда как проза ошибку в одном токене переживает. Учтите лицензию: Codestral идёт под MNPL, коммерческое использование требует отдельного соглашения; mistral, mistral-nemo, mistral-small3.x, devstral и magistral — Apache 2.0.

Русский чат и суммаризация — Nemo от Q4_K_M, ровнее с Q5_K_M; вызовы функций и строгий JSON — не ниже Q5_K_M; классификация и роутинг переживают даже mistral:7b в Q3_K_L. Промежуточные уровни для mistral-small3.2 берут только с Hugging Face:

ollama pull mistral-nemo:12b-instruct-2407-q6_K
ollama run hf.co/bartowski/Mistral-Small-3.2-24B-Instruct-2506-GGUF:Q5_K_M
ollama ps        # модель целиком в RAM, если видите 100% CPU

Пережать скачанный файл не выйдет: ollama create -q работает только из fp16/fp32, а fp16 у Nemo — 24,5 ГБ.

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

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

Error: model requires more system memory (10.2 GiB) than is available (7.6 GiB)

Минимум: 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe. Помещается mistral:7b в Q4_K_M с окном 8k: 4,37 + 0,44 + 1,0 + 1,5 = 7,3 ГБ. Ограничение честное — до Q5_K_M отсюда не подняться, а Nemo не влезет ни в каком уровне. Восемь гигабайт дают ровно один квант без права на эксперимент.

Рабочий вариант: 8 vCPU, 16 ГБ RAM, 160 ГБ NVMe. Это mistral-nemo в Q4_K_M с окном 32k либо mistral:7b в Q6_K с запасом под второй квант. Здесь разговор про уровень впервые имеет смысл: два файла лежат рядом, и выбор делается по вашим промптам, а не по чужой таблице.

Комфорт: 8–16 vCPU, 32 ГБ RAM, от 320 ГБ NVMe. Порог для mistral-nemo в Q6_K с полным окном и для mistral-small3.2 в Q4_K_M. Диск тут не про запас: три уровня Nemo — уже 26 ГБ в /usr/share/ollama/.ollama/models, старые файлы сами не исчезают.

Границы назову прямо: mixtral:8x22b и mistral-large на VPS не живут — от 85,6 ГБ весов, 128–192 ГБ RAM и около токена в секунду. И mistral-small3.2:24b на процессоре в любом кванте даёт около двух токенов в секунду: ответ в 500 токенов — четыре минуты. Нужен живой диалог с моделью крупнее двенадцати миллиардов — это GPU-сервер под инференс LLM, а не CPU-тариф.

Локация — Лондон (UK). Сетевая задержка локальной модели безразлична: веса лежат у вас, наружу ничего не ходит. Важно, откуда вы качаете. Промежуточных уровней для mistral-small3.2 в библиотеке Ollama нет, за ними идут на Hugging Face, а он из российских сетей отвечает нестабильно: шестнадцатигигабайтный Q5_K_M рвётся на середине с dial tcp: i/o timeout, и всё начинается заново. С европейской площадки 16 ГБ по гигабитному каналу приезжают за две-три минуты. Лондон даёт заодно 15–30 мс до пользователей в ЕС, Франция закрывает тот же сценарий. Российская площадка нужна при персональных данных россиян и 152-ФЗ — тогда веса проще выкачать один раз и перенести файлом.

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

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