Как запустить Qwen3.8-27B локально на RTX3090 (Win10)

На подготовку данной пошаговой инструкции меня вдохновил пост А все-таки Qwen3.8-27B — думает меньше и быстрее чем 3.6 от @rtrgdfb. При повторении действий по скачиванию и конвертации модели из этого поста я понял, что многие технические детали сокращены или не совсем очевидны при первом знакомстве, так как автор, на мой взгляд, ставил целью донести сообщение о том, что Qwen3.8-27B стала лучше, если правильно настроить параметры для средства запуска моделей llama_server (входит в llama.cpp). И вот как раз для новичков и интересующихся возможностями моделей, работающих локально на собственном компьютере, эти детали мне захотелось раскрыть подробнее, вместе с некоторым опытом преодоления возникающих типовых проблем при настройке модели и подготовке программ для нее.

Оглавление

• Что даёт прочтение этой статьи?

• Стартовые условия и замечания перед началом работы

• 1. Подготовка всех необходимых программных средств для запуска модели

  • 1.1 Устанавливаем Python

  • 1.2 Устанавливаем hf

  • 1.3 Устанавливаем Git for Windows

  • 1.4 Устанавливаем CUDA Toolkit 12.8

  • 1.5 Устанавливаем cmake

  • 1.6 Устанавливаем средство для сборки C++ приложений

  • 1.7 Устанавливаем Ninja

  • 1.8 Устанавливаем OpenSSL (Full)

• 2. Собираем llama-сервер из исходников для запуска модели

  • 2.1 Делаем виртуальное окружение Python в папке llama.cpp

• 3. Создаем локальную модель Qwen3.8-27B

  • 3.1 Скачиваем опубликованные веса модели

  • 3.2 Конвертируем веса в gguf-файл модели с точностью F16

  • 3.3 Выполняем квантование модели с параметром Q4_K_M

• 4. Запускаем локальную модель Qwen3.8-27B

• Вместо итогов

Что даёт прочтение этой статьи?

В этой статье описывается подробная последовательность для Windows 10 и RTX3090 по установке всего необходимого программного обеспечения (Python, Git, CUDA Toolkit, CMake, MSVC, Ninja, OpenSSL), сборке llama.cpp из исходников с поддержкой GPU, скачивания модели Qwen3.8-27B с Hugging Face, её конвертации в формат GGUF и квантизации в Q4_K_M (чтобы она целиком поместилась в видеопамять GPU), а так же приведены параметры запуска для локального сервера llama.cpp с OpenAI-совместимым API и веб-интерфейсом, позволяющим общаться с моделью через чат в браузере. Каждый шаг сопровождается объяснением, зачем он нужен, что делает каждая команда и что означает каждый параметр у команды.

Стартовые условия и замечания перед началом работы:

1. Конфигурация локального компьютера:
   Процессор: Intel Core i7-8700K, это шестиядерный процессор

   Оперативная память: 32 ГБ DDR4 (2×16)

   Диски: SSD Samsung EVO 970 1TB (основной диск операционной системы) и внешний диск HDD Ultrastar DC HC320 8Tb (дополнительный для хранения больших файлов, подключен через USB3.0)

   Видеокарта: RTX3090 (с 24 Гб VRAM)

   ⚠️ Конфигурацию компьютера следует учитывать при настройке параметров работы модели локально (см. п. 4 статьи ниже).

2. Версия windows 10 (с помощью команды ver):

   Microsoft Windows [Version 10.0.19045.6456]

3. В качестве средства запуска модели локально используется llama.cpp, другие средства в статье не рассматриваются. Сборка приложения выполняется непосредственно и только для RTX3090 (точнее, архитектуры Ampere), флаг сборки для включения поддержки работы llama.cpp в режиме GPU подробно описан в пункте 2.

4. В качестве консоли командной строки (терминала) в данной статье используется cmd или Powershell. Имеет смысл напомнить о том, что команда where помогает определить, из какого места файловой системы запущена программа команды, что бывает очень полезным при проверке настройки переменной PATH в Windows:

   where cmd
   C:WindowsSystem32cmd.exe
   

5. Очень часто результат выполнения какой-либо команды сопровождается какими-либо текстовым выводом, сообщениями или логами (от сборщика программы, от компилятора, от llama.cpp и так далее) – имеет смысл их анализировать, так как в этих сообщениях могут быть ценные подсказки (неправильно настроен параметр, не найдена программа на компьютере, устаревшее ключевое слово). Проводить анализ можно, например, с помощью бесплатного Deepseek.

6. Также в некоторых случаях в консоли командной строки может выводиться сообщение Отказано в доступе. Это означает, что текущих привилегий пользователя для выполнения команды недостаточно, и нужно запустить консоль с привилегиями администратора.

7. Qwen3.8-27B не является реализацией архитектуры Mixture-of-Experts, как она устроена, можно, например, почитать в этой статье.

1. Подготовка всех необходимых программных средств для запуска модели

1.1 Устанавливаем Python

Python — обязательное предварительное условие для установки командной утилиты Hugging Face CLI (hf), которая устанавливается как пакет Python с помощью pip (см. пункт 1.2 ниже), а так же для работоспособности Python-скрипта convert_hf_to_gguf.py (выполняет конвертацию исходных файлов весов модели из HF в формат GGUF, подробнее в пункте 3.2 ниже).

Шаги по установке Python 3.12 на Windows 10:

1. Открываем официальную страницу https://www.python.org/downloads/windows/ и скачиваем установщик Python 3.12.x — файл python-3.12.x-amd64.exe. Выбираем только 64-битную (amd64) версию: 32-битная версия не подойдёт для работы из-за проблем с совместимостью.

2. Запускаем установщик. На первом экране обязательно ставим галочку "Add python.exe to PATH" внизу окна и жмём “Install Now”. Это добавит Python в системную переменную окружения PATH, благодаря чему команды python и pip будут работать в любом терминале без указания полного пути.

3. Ждём завершения установки и закрываем установщик.

4. Проверяем установку. Открываем новый терминал (cmd или powershell) и выполняем:

   python --version

   В ответ должно быть что-то вроде Python 3.12.x:

   Python 3.12.9

   Проверяем также pip:

   pip --version

   В ответ должно быть что-то вроде:

   pip 25.1 from C:ProgramDataanaconda3Libsite-packagespip

   Если команды выполняются и показывают версию — Python установлен корректно. Если видите ошибку вида 'python' is not recognized as an internal or external command, закройте терминал и откройте новый (PATH подхватывается при запуске терминала) либо переустановите Python, поставив галочку “Add python.exe to PATH”.

⚠️ Если на компьютере уже стоит другая версия Python, ставьте 3.12 рядом с ней и убедитесь, что команда python в терминале указывает именно на версию 3.12. Для выбора версии можно использовать встроенный py-запускатель:

py -3.12 --version

1.2 Устанавливаем hf

hf — это командная утилита (CLI) Hugging Face, которая входит в состав пакета huggingface-hub, устанавливаемого с помощью pip (или его аналогов – pipenv, poetry и т.д.). Она нужна для скачивания весов модели с Hugging Face Hub (используется в пункте 3.1 ниже). Дополнительно можно поставить пакет hf_xet — это Rust-реализация нового протокола хранения Xet, который заметно ускоряет загрузку больших файлов, что целесообразно в рамках текущей статьи при скачивании модели весом более 50ГБ. Если hf_xet установлен, huggingface-hub использует его автоматически, никакой дополнительной настройки не требуется.

Установить можно двумя способами: глобально в системный Python или в виртуальное окружение (venv). По результату они равнозначны — команда hf появится в терминале; разница лишь в том, в какой именно Python-интерпретатор (системный или для данного виртуального окружения) будет установлен пакет huggingface-hub.

Способ 1. Глобальная установка в системный Python

Открываем терминал (cmd или PowerShell) и выполняем:

pip install -U huggingface-hub hf_xet

Флаг -U (сокращение от –upgrade) ставит последнюю доступную версию пакета, а если пакет уже установлен — обновляет его до актуальной. После установки команда hf становится доступной в любом новом терминале, потому что pip кладёт исполняемые файлы в каталог Scripts, который при установке Python (пункт 1.1 выше) уже был добавлен в PATH (галочка “Add python.exe to PATH”).

Способ 2. Установка в виртуальное окружение (venv)

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

1. Создаём окружение. В той папке, где хотим его держать (например, в папке llama.cpp или рядом с моделью), выполняем:
   python -m venv venv

   Команда создаст папку venv со своим собственным pip и своим набором пакетов, не затрагивая системный Python.

2. Активируем окружение:

   • в cmd: venvScriptsactivate

   • в PowerShell: .venvScriptsActivate.ps1

   После активации в начале строки появится префикс (venv) — это признак того, что все последующие команды pip и python теперь работают именно внутри этого окружения.

   ⚠️ Если PowerShell выдаёт ошибку, связанную с политикой выполнения (ExecutionPolicy), выполните один раз Set-ExecutionPolicy -Scope CurrentUser RemoteSigned, либо используйте cmd вместо PowerShell.

3. Устанавливаем hf в активное окружение: pip install -U huggingface-hub hf_xet

4. Когда окружение больше не нужно, деактивируем его командой deactivate (или просто закрываем терминал).

Проверка установки (для обоих способов)

В том же терминале — глобальном или в активированном с помощью venv — выполняем:

hf --version

В ответ команда должна показать установленную версию пакета huggingface-hub. Если команда hf не найдена, значит либо терминал не перезапущен (для способа 1 нужно открыть новый), либо venv не активирован (для способа 2). Если хочется убедиться, что пакет точно установлен, можно выполнить:

python -c "import huggingface_hub as h; print(h.__version__)"

⚠️ Если выбрали виртуальное окружение, не забывайте его активировать перед каждым шагом, где используется hf (в первую очередь при скачивании весов в пункте 3.1 ниже). При глобальной установке активировать ничего не нужно.

1.3 Устанавливаем Git for Windows

Git нужен для скачивания (клонирования) репозитория llama.cpp с GitHub — это делается командой git clone с помощью утилиты командной строки git, которой нет в Windows по умолчанию.

Для установки нужно выполнить следующие шаги:

1. Открываем официальную страницу https://git-scm.com/download/win и скачиваем установщик (файл вида Git-2.x.x-64-bit.exe). Для нашей конфигурации (64-битная система) необходима именно 64-битная версия.

2. Запускаем установщик. На большинстве экранов можно просто жать “Next”, используя значения по умолчанию. На них стоит обратить внимание:

   • “Adjusting your PATH environment” — выбираем вариант “Git from the command line and also from 3rd-party software”. Это добавит git в системный PATH, благодаря чему команда git будет работать в любом терминале.

   • “Choosing the SSH executable to use” — оставляем “Use OpenSSH” (по умолчанию). Встроенный PuTTY-вариант не нужен.

   • “Choosing the default editor used when editing commit messages” — можно оставить Vim, но если не хочется разбираться с ним, выберите “Use Notepad as the Git default editor”.

   • “Configuring line ending conversions” — оставляем “Checkout Windows-style, commit Unix-style” (по умолчанию). Это корректно обрабатывает переводы строк между Windows и репозиториями с Unix-конвенцией.

   • “Configuring the terminal emulator for Git Bash” — можно оставить “Use MinTTY” (по умолчанию).

3. Ждём завершения установки и закрываем установщик.

4. Проверяем установку. Открываем новый терминал (cmd или PowerShell) и выполняем:

   git --version

   В ответ должно быть что-то вроде git version 2.x.x.windows.x. Если команда возвращает результат — Git установлен корректно. Если видите ошибку вида 'git' is not recognized as an internal or external command, закройте и откройте новый терминал (обновленный PATH подхватывается при стартеперезапуске терминала) либо переустановите, выбрав вариант PATH “Git from the command line and also from 3rd-party software”.

5. (Опционально, выполнять не обязательно) Конфигурация имени пользователя и электронной почты

   Git при каждом коммите (записи изменений) хранит в истории имя и e-mail того, кто их внёс. Эти данные не обязательны для работы git clone (шаг 2 ниже), но без них Git выведет некритичную ошибку при первом коммите, а также они полезны, если вы планируете отправлять изменения на GitHub. Поэтому сразу после установки есть смысл задать их глобально — то есть один раз для всех репозиториев на компьютере.

   Открываем терминал и выполняем две команды:

   git config --global user.name "Ваше Имя"
   git config --global user.email "ваша почта@example.com"
   

   Вместо “Ваше Имя” и “ваша почта@example.com” подставьте своё имя и адрес электронной почты.

   Флаг --global означает, что настройки сохраняются в пользовательском конфиге (файл .gitconfig в домашней папке, на Windows это C:Users%USERNAME%.gitconfig) и применяются ко всем репозиториям. Без этого флага Git спрашивал бы эти данные для каждого репозитория отдельно.

   Проверка конфигурации:

   git config --global user.name
   git config --global user.email
   

   Каждая команда должна вывести заданное ранее значение. Если вывод пустой или не совпадает с ожидаемым, повторите команды из предыдущего шага.

   ⚠️ Если вы работаете только локально (без отправки на GitHub), можно указать любые имя и e-mail — они не проверяются. Но если планируете пушить на GitHub, используйте реальные данные аккаунта, чтобы коммиты корректно связывались с вашим профилем.

1.4 Устанавливаем CUDA Toolkit 12.8

CUDA Toolkit — это набор инструментов NVIDIA для разработки и запуска кода на GPU. Для нашей задачи он нужен по двум причинам: во-первых, он предоставляет компилятор nvcc, которым CMake (пункт 1.5) собирает CUDA-код в исходниках llama.cpp под архитектуру GPU RTX3090; во-вторых, он устанавливает библиотеки CUDA Runtime (cudart) и заголовочные файлы, к которым линкуется итоговый llama-server. Без него сборка llama.cpp с поддержкой CUDA невозможна.

RTX 3090 (архитектура Ampere) полностью поддерживается CUDA Toolkit с версией 12.8.

Требования перед установкой:

• Драйвер NVIDIA. CUDA требует достаточно свежий драйвер. Если драйвер старый, установщик CUDA сам предложит установить актуальный. Чтобы не полагаться на это, рекомендую заранее обновить драйвер — либо через NVIDIA GeForce Experience, либо скачав с https://www.nvidia.com/Download/index.aspx (выбрать GeForce RTX 3090, Windows 10, x64).

• Свободное место на диске. Полный CUDA Toolkit занимает несколько гигабайт (зависит от выбранных компонентов).

Для скачивания установщика нужно выполнить следующие шаги:

1. Открываем официальную страницу загрузки https://developer.nvidia.com/cuda-toolkit.

2. В форме выбора параметров указываем:

   • Operating System: Windows

   • Version: 10

   • Architecture: x86_64

3. В поле “Download Options” выбираем “Local Installer” (локальный установщик) — это полный установочный файл на несколько гигабайт. Он надёжнее «Network Installer», потому что всё скачивается один раз и установка идёт с диска, без повторных обращений к сети. Нажимаем “Accept” и ждём, пока файл (cuda_12.8.x_xxx.exe) скачается.

Запуск установщика:

1. Запускаем скачанный .exe-файл.

2. На первом экране (Installation Type) выбираем “Custom (Advanced)” — НЕ “Express”. Express ставит всё подряд без возможности выбрать компоненты, а нам важно контролировать, что именно ставится.

3. Принимаем лицензионное соглашение (Accept).

4. На экране “Components” (список компонентов) убедитесь, что отмечен пункт “CUDA” — он обязателен (включён по умолчанию). Остальные пункты (Nsight Compute, Nsight Systems, Visual Studio Integration, MPS, NSight Graphics и т.д.) — необязательны и занимают место; для сборки llama.cpp достаточно только “CUDA”.

5. На экране выбора пути установки оставляем путь по умолчанию: C:Program FilesNVIDIA GPU Computing ToolkitCUDAv12.8. Менять не следует — некоторые скрипты и инструменты ожидают именно этот стандартный путь.

6. Нажимаем “Install” и ждём завершения. Установка может занять несколько минут.

Проверка установки:

1. Открываем новый терминал (cmd или PowerShell).

2. Выполняем:

   nvcc --version

   В ответ должно быть что-то вроде:

   nvcc: NVIDIA (R) Cuda compiler driver
   Copyright (c) 2005-2025 NVIDIA Corporation
   Built on Wed_Jan_15_19:38:46_Pacific_Standard_Time_2025
   Cuda compilation tools, release 12.8, V12.8.61
   Build cuda_12.8.r12.8/compiler.35404655_0
   

   Если команда распознаётся и показывает версию 12.8 – CUDA Toolkit установлен корректно.

3. Проверяем, что пути добавлены в PATH. Выполняем:

   echo %PATH%
   

   (в cmd; в PowerShell: $env:PATH)

   В выводе должны присутствовать пути вида C:Program FilesNVIDIA GPU Computing ToolkitCUDAv12.8bin и …libnvvp. Установщик добавляет их автоматически.

4. Дополнительно можно проверить переменные окружения:

   echo %CUDA_PATH%
   echo %CUDA_HOME%
   

   Команды должны вернуть значение C:Program FilesNVIDIA GPU Computing ToolkitCUDAv12.8. Установщик задаёт CUDA_PATH (и CUDA_HOME) сам.

   ⚠️Важные примечания:

• Если nvcc не находится в терминале, значит либо терминал не перезапущен (откройте новый), либо при установке пути не были добавлены в PATH (переустановите, выбрав Custom и убедившись, что “CUDA” отмечена).

• Не следует путать CUDA Toolkit с драйвером GPU. Драйвер нужен для работы GPU как устройства, а CUDA Toolkit — это компилятор и библиотеки для разработки. Для запуска модели нужны и драйвер, и toolkit.

• Версия CUDA (12.8) должна совпадать с версией, под которую планируется собирать llama.cpp (см. пункт 2).

1.5 Устанавливаем cmake

CMake — это система сборки (build system), которая собирает проект из исходников: читает файл CMakeLists.txt в папке llama.cpp, находит компилятор (MSVC из пункта 1.6 ниже), находит CUDA-инструменты (nvcc 12.8 из пункта 1.4 выше), и генерирует план сборки, который затем выполняет Ninja (пункт 1.7 ниже).

Стоит отметить, что CMake сам по себе не компилирует CUDA-код — этим занимается nvcc. CMake лишь находит nvcc и правильно выставляет параметры для него. Поэтому CMake должен быть достаточно свежий, чтобы он корректно находил и настраивал часть сборки, связанную с CUDA (я использую версию 3.29).

⚠️Важные примечания:

• Минимальную версию CMake, необходимую для сборки llama.cpp можно увидеть в файле CMakeLists.txt в папке исходников llama.cpp (см. пункт 3).

• NVIDIA рекомендует CMake 3.20+ для корректной работы с CUDA 12.x.

Для установки Cmake нужно выполнить следующие шаги:

1. Открываем официальную страницу https://cmake.org/download/ и скачиваем установщик для Windows — файл вида cmake-3.3x.x-win64-x86_64.exe (64-битный, для x86_64). Если на странице несколько вариантов, берём именно .exe-установщик (не «zip»).

2. Запускаем установщик. На большинстве экранов жмём “Next”, используя значения по умолчанию. Единственный важный пункт:

   • На экране “CMake Setup Type” (или “Add CMake to the system PATH for all users”) обязательно выбираем вариант, который добавляет CMake в системный PATH. В классическом установщике это опция “Add CMake to the system PATH”. Это нужно, чтобы команда cmake работала в любом терминале без указания полного пути.

3. Ждём завершения установки и жмём “Finish”.

Проверка установки

1. Открываем новый терминал (cmd или PowerShell).

2. Выполняем:

   cmake --version

   В ответ должно быть что-то вроде cmake version 3.3x.x. Если команда распознаётся и показывает версию 3.20+ – CMake установлен корректно.

3. Проверяем, что путь до cmake.exe находится в переменной PATH. Выполняем:

   echo %PATH%
   

   (в cmd; в PowerShell: $env:PATH)

   В выводе должен присутствовать каталог, где лежит cmake.exe (например, C:Program FilesCMakebin).

⚠️Примечания:

• CMake работает в связке с компилятором MSVC (пункт 1.6 ниже) и сборщиком Ninja (пункт 1.7 ниже). Все три компонента независимы: CMake генерирует план сборки, MSVC компилирует C++/CUDA-код, Ninja выполняет сборку.

• Если cmake не находится в терминале, значит либо терминал старый (откройте новый), либо при установке не была включена опция добавления в PATH (переустановите с этой опцией).

1.6 Устанавливаем средство для сборки C++ приложений

llama.cpp написан на C++, поэтому, чтобы собрать его из исходников, нужен C++ компилятор. На Windows это можно сделать с помощью MSVC (Microsoft Visual C++) — именно его cl.exe (компилятор) и link.exe (линковщик) запускает Ninja в процессе сборки (пункт 1.7). MSVC поставляется в составе Visual Studio, поэтому ставим Visual Studio Community Edition 2022 — бесплатную полнофункциональную версию, которой достаточно для нашей задачи. В некоторых источниках пишут, что достаточно установить просто Build Tools.

⚠️ Важно не путать два продукта:

• Visual Studio Community — это полная IDE: редактор кода, компилятор MSVC, отладчик и прочее. Бесплатна для личного использования и обучения.

• Build Tools for Visual Studio — это минимальный набор инструментов для сборки (MSVC + Windows SDK) без редактора.

Для сборки llama.cpp достаточно и того, и другого — важно только, чтобы были установлены компилятор MSVC и Windows SDK. Но Community Edition удобнее: если позже захотите открыть проект в редакторе или написать какой-то код на С++ — IDE уже установлена на компьютере.

Требования перед установкой:

• Свободное место на диске. Visual Studio Community с рабочей нагрузкой C++ занимает порядка 10–20 ГБ (зависит от компонентов).

Установка:

1. Открываем официальную страницу https://visualstudio.microsoft.com/ru-ru/downloads/ (или https://visualstudio.microsoft.com/ru/vs/older-downloads/) и находим блок «Visual Studio Community» (или «Скачать Visual Studio 2022» → «Community»). Нажимаем «Скачать» — начнёт качаться небольшой установщик vs_community.exe. Это не сама программа, а оболочка, которая далее скачает нужные компоненты.

2. Запускаем vs_community.exe. Откроется окно выбора рабочих компонентов (workloads).

3. В списке компонентов ставим галочку «Разработка классических приложений C++» (в английской версии — «Desktop development with C++»). Именно она содержит компилятор MSVC и Windows SDK, необходимые для сборки llama.cpp.

   • Прочие рабочие компоненты (.NET, веб, Azure, Unity, Android и т.д.) нам не нужны — снимите их галочки, чтобы не тянуть лишнее.

   • Внизу того же окна есть раздел «Индивидуальные компоненты» (Individual components). Убедитесь, что отмечены «Компилятор C++ для x64 (MSVC)» и «Windows 11 SDK» (или «Windows 10 SDK»). Обычно они включаются автоматически вместе с рабочим компонентом C++; если вдруг нет — отметьте вручную.

4. В поле «Место установки» оставьте путь по умолчанию (обычно C:Program FilesMicrosoft Visual Studio2022Community). Менять не следует.

5. Нажимаем «Установить» (Install). Установщик скачает и установит выбранные компоненты — это может занять от нескольких минут до получаса в зависимости от скорости сети. Ждём завершения и закрываем окно.

Проверка установки

Самый простой способ убедиться, что компилятор на месте, — запустить «родную» для MSVC командную строку. Она называется x64 Native Tools Command Prompt for VS 2022 (меню Пуск → «Visual Studio 2022» → «x64 Native Tools Command Prompt for VS 2022»). Открыв её, выполняем:

cl

В ответ должны появиться сведения о компиляторе (что-то вроде Microsoft (R) C/C++ Optimizing Compiler и версия вида 19.xx.xxxxxxx). Это значит, что MSVC установлен корректно. Нажмите Ctrl+C, чтобы выйти из режима ожидания ввода. Альтернативная проверка — выполнить в том же окне where cl; должен отобразиться путь к cl.exe.

⚠️ Важно для сборки

Обычный cmd или PowerShell, которые открываются из меню Пуск, не содержат в PATH компилятор MSVC (cl.exe, link.exe) и заголовки Windows SDK. По этой причине собрать llama.cpp в них не получится: CMake не найдёт компилятор, а Ninja не сможет его запустить.

Поэтому для сборки llama.cpp (шаг 2 ниже) всегда используйте x64 Native Tools Command Prompt for VS 2022 — она сама подставляет все необходимые переменные окружения (PATH, INCLUDE, LIB) для 64-битной сборки. Запомните это название: на шаге 2 ниже мы именно вернемся к ней для выполнения команды сборки.

1.7 Устанавливаем Ninja

Ninja — это сборщик (build tool), то есть программа, которая непосредственно выполняет сборку: запускает компилятор на каждом файле, собирает результаты и линкует итоговый exe-файл. Если CMake — это архитектор, который составил план стройки (что и в каком порядке собирать), то Ninja — это бригада, которая этот план исполняет.

• CMake НЕ компилирует код. Он читает CMakeLists.txt, находит компилятор (MSVC из пункта 1.6) и CUDA-toolchain (nvcc из пункта 1.4), решает, какие задачи нужно выполнить и в какой последовательности, и выкладывает этот план в файл build.ninja. На этом его работа на этапе сборки заканчивается.

• Ninja берёт этот план и исполняет его: запускает cl.exe для C++ файлов, nvcc для CUDA-ядер, link.exe для финальной сборки llama-server.exe — причём задачи, которые не зависят друг от друга, выполняет параллельно, что ускоряет сборку проекта такого размера, как llama.cpp.

Почему используется именно Ninja, а не другой сборщик (например, MSBuild из Visual Studio):

• это рекомендуемый способ сборки llama.cpp на Windows: в документации проекта приведены команды именно с генератором -G Ninja.

• он заметно быстрее по времени сборки и проще по логике ошибок — в логе видно, какая именно команда упала;

• Ninja не требует установленного Visual Studio — достаточно компилятора из шага 1.6 выше;

Способ установки 1. Через winget (рекомендуется)

Открываем PowerShell и выполняем:

winget install Ninja-Ninja.Ninja

winget скачает последнюю версию Ninja и добавит её в PATH. После установки закройте и откройте новый терминал.

Способ установки 2. Ручная установка из архива

У официального проекта Ninja нет .exe-установщика для Windows — дистрибутив распространяется архивом.

1. Открываем страницу релизов https://github.com/ninja-build/ninja/releases.

2. В последнем релизе скачиваем файл ninja-win.zip (например, ninja1.12.2-win.zip).

3. Распаковываем архив в отдельную папку, например C:ninja (внутри окажется один файл ninja.exe).

4. Добавляем эту папку в системный PATH: Пуск → поиск «Переменные среды» → «Изменение переменных среды для системы» → «Переменные среды…» → в блоке «Системные переменные» выбираем Path → «Изменить…» → «Создать» → вставляем C:ninja → OK во всех окнах.

   Более простой вариант: просто скопировать ninja.exe в папку, которая уже есть в PATH (например, C:Program FilesCMakebin из шага 1.5), — тогда менять переменные окружения не придётся.

Проверка установки:

1. Открываем новый терминал (cmd или PowerShell) — PATH подхватывается при старте.

2. Выполняем:

   ninja --version
   

   В ответ должно быть что-то вроде 1.12.x. Если команда распознаётся и показывает версию — Ninja установлен корректно.

3. При желании проверяем, что путь до ninja.exe находится в PATH. Выполняем:

   echo %PATH%
   

   (в cmd; в PowerShell: $env:PATH)

   В выводе должна присутствовать папка, где лежит ninja.exe.

⚠️ Примечания:

• Если ninja не находится в терминале, значит либо терминал старый (откройте новый), либо папка с ninja.exe не попала в PATH.

• Некоторые новые версии CMake умеют автоматически подгрузить Ninja при генерации, если он не найден. Но всё-таки лучше поставить его явно, тогда сборка не будет зависеть от сети и от конкретной версии CMake.

• В пункте 2 мы зададим CMake генератор -G Ninja — именно тогда CMake начнёт использовать установленный здесь Ninja для исполнения плана сборки.

1.8 Устанавливаем OpenSSL (Full)

OpenSSL — это криптографическая библиотека (libssl + libcrypto) и стандартная реализация протоколов TLS/SSL. В контексте нашей задачи она нужна для сборки llama.cpp с поддержкой SSL: если при сборке CMake найдёт OpenSSL, то llama-server сможет принимать HTTPS-соединения (TLS), а не только незащищенный HTTP. Это пригодится, если вы планируете обращаться к серверу из других машин или из программ, которые требуют именно https-эндпоинт.

⚠️ OpenSSL — это необязательная зависимость. Как следует из документации llama.cpp, если он не установлен, проект соберётся и будет работать корректно, просто без SSL-поддержки. В пункте 2 ниже мы передаём CMake флаг -DOPENSSL_ROOT_DIR, чтобы впоследствии не приходилось собирать приложение снова.

Откуда скачивать

Официальные бинарные пакеты OpenSSL для Windows выпускает Shining Light Productions (SLB) — страница загрузки: https://slb.certificate.com/openssl/download/ (на неё же ведёт ссылка с сайта openssl.org). Там лежат готовые .exe-установщики, собирать OpenSSL из исходников под Windows не нужно.

Какой файл выбрать: Full или Light

На странице несколько установщиков. Для 64-битной Windows нужен файл вида Win64OpenSSL_3_x_y.exe (например, Win64OpenSSL_3_2_3.exe) — это полная (Full) редакция. Не берите:

• Win64OpenSSL_Light_3_x_y.exe (Light) — облегчённая редакция;

• Win32OpenSSL_... — 32-битные пакеты; у нас всё остальное (MSVC, CUDA, сама сборка) 64-битное, поэтому 32-битный OpenSSL нам не подойдёт.

• Full — полный дистрибутив: инструменты (openssl.exe), заголовочные файлы (include/openssl/*.h), общие библиотеки (DLL) с импортируемыми .lib, статические библиотеки и полный набор алгоритмов/шифров.

• Light — урезанный вариант: только бинарный исполняемый файл openssl.exe.

Для сборки приложения llama.cpp CMake-модулю find_package(OpenSSL) нужны заголовки и библиотеки libssl/libcrypto — они есть в полном пакете, поэтому берём его.

Установка

1. Скачиваем Win64OpenSSL_3_x_y.exe с https://slb.certificate.com/openssl/download/.

2. Запускаем установщик и принимаем лицензионное соглашение.

3. На экране выбора пути установки оставляем путь по умолчанию: C:Program FilesOpenSSL-Win64. Важно: именно этот путь мы укажем на шаге 2 в команде CMake (-DOPENSSL_ROOT_DIR="C:/Program Files/OpenSSL-Win64"), поэтому менять его не стоит.

4. Установщик предложит добавить OpenSSL в PATH (для текущего пользователя или для всех). Ставим галочку — тогда команда openssl будет работать в любом терминале.

5. Ждём завершения установки и закрываем окно.

Проверка установки

1. Открываем новый терминал (cmd или PowerShell).

2. Выполняем:

   openssl version
   

   В ответ должно быть что-то вроде OpenSSL 3.x.y .... Если команда распознаётся и показывает версию 3.x — OpenSSL установлен корректно. Если видите ошибку вида 'openssl' is not recognized as an internal or external command, то либо закройте и откройте новый терминал, либо при установке не была включена опция добавления в PATH и нужно переустановить.

3. Убедимся, что все нужные для сборки компоненты на месте:

   dir "C:Program FilesOpenSSL-Win64bin"
   dir "C:Program FilesOpenSSL-Win64lib"
   dir "C:Program FilesOpenSSL-Win64includeopenssl"
   

   Ожидаем увидеть: в bin — openssl.exe, libssl-3-x64.dll, libcrypto-3-x64.dll; в lib — импортируемые библиотеки libssl.lib и libcrypto.lib; в includeopenssl — заголовочные файлы (ssl.h, evp.h и другие). Именно эта тройка (заголовки + библиотеки + DLL) — нужна CMake, чтобы собрать llama.cpp с поддержкой SSL.

⚠️ Примечания:

• Если вы не планируете использовать HTTPS и хотите упростить сборку, этот шаг можно пропустить — тогда в пункте 2 просто уберите из команды CMake флаг -DOPENSSL_ROOT_DIR, и проект соберётся без SSL-поддержки.

• Версия: подойдёт любая актуальная OpenSSL 3.x; подгонять её под версии CUDA/MSVC не нужно — это независимые компоненты.

2. Собираем llama-сервер из исходников для запуска модели

Для начала сборки необходимо скачать исходные файлы (в любую папку, в которой планируем собирать, я создал папку Sources в корне 8Tb-диска):

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp

Теперь внутри папки llama.cpp создаем папку build и переходим в неё:

mkdir build
cd build

⚠️ Важно: в каком терминале выполнять команду сборки. Команду сборки нужно выполнять не в обычном cmd и не в PowerShell, а в x64 Native Tools Command Prompt for VS 2022 (меню Пуск → «Visual Studio 2022» → «x64 Native Tools Command Prompt for VS 2022»). Только в ней в PATH и переменных окружения (INCLUDE, LIB) есть компилятор MSVC (cl.exe) и заголовки Windows SDK из пункта 1.6 — без них CMake не найдёт компилятор, и сборка упадёт с ошибкой вида «No CMAKE_CXX_COMPILER could be found».

Запуск команды конфигурации сборки

cmake .. -G Ninja -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=86 -DGGML_CUDA_F16=1 -DCMAKE_BUILD_TYPE=Release -DOPENSSL_ROOT_DIR="C:/Program Files/OpenSSL-Win64"

Разберём по частям, что задаёт каждая часть этой команды:

• .. — аргумент: путь к каталогу с исходниками. Команда выполняется из папки сборки (build), а CMakeLists.txt проекта лежит на уровень выше, поэтому “…” означает “собирай проект из родительской папки”.

• -G Ninja — выбор генератора CMake. CMake сгенерирует план сборки в формате Ninja (файл build.ninja) и передаст его сборщику Ninja, установленному в пункте 1.7. Это рекомендуемый способ сборки llama.cpp на Windows.

• -DGGML_CUDA=ON — флаг для сборки с поддержкой CUDA: собранный проект будет использовать GPU от NVIDIA. Без этого флага llama.cpp собрался бы без поддержки видеокарты (только в режиме CPU).

• -DCMAKE_CUDA_ARCHITECTURES=86 — задает целевую архитектуру GPU, 86=Ampere, проект не будет собираться с поддержкой других архитектур, что позволит уменьшить размер сборки.

• -DGGML_CUDA_F16=1 — устанавливает использование 16-битных чисел с плавающей точкой (FP16, “half precision”) в части вычислений на GPU. Настройка этого флага даёт меньший расход памяти видеокарты и прирост скорости. Если по какой-то причине CMake в новой версии выдаст предупреждение о неизвестном флаге, его можно просто убрать при сборке.

• -DCMAKE_BUILD_TYPE=Release — задаёт конфигурацию сборки: Release — оптимизированная сборка с включённой оптимизацией компилятора и без отладочной информации, что даёт максимальное быстродействие собранной версии llama.cpp.

• -DOPENSSL_ROOT_DIR="C:/Program Files/OpenSSL-Win64" — флаг указывает путь к библиотеке OpenSSL (корневая папка её установки) для сборки llama.cpp с поддержкой HTTPS/TLS. Если флаг не указан, то проект всё равно соберётся без SSL-поддержки и будет работать корректно, просто без функций, связанных с HTTPS.

Запуск команды компиляции

cmake --build . --config Release

После завершения сборки в папке .bin появятся исполняемые файлы llama.cpp.

2.1 Делаем виртуальное окружение Python в папке llama.cpp

В пункте 3.2 ниже мы будем конвертировать скачанные веса в GGUF с помощью скрипта convert_hf_to_gguf.py. Это Python-утилита из состава llama.cpp, и у неё довольно тяжёлый набор зависимостей: PyTorch (torch), transformers, gguf, numpy, sentencepiece, protobuf. Ставить их напрямую в системный Python нежелательно: это засорит глобальную установку и может привести к конфликтам версий с другими проектами. Поэтому для этой утилиты создаём отдельное виртуальное окружение (venv) прямо в папке llama.cpp — принцип тот же, что мы разбирали в пункте 1.2 (Способ 2) выше.

Создаём и активируем окружение:

1. Открываем терминал (cmd или PowerShell) и переходим в папку llama.cpp — туда, где лежат исходники и лежит скрипт convert_hf_to_gguf.py.

2. Создаём окружение командой:

   python -m venv venv
   

   В папке llama.cpp появится каталог venv со своим pip и своими пакетами.

3. Активируем его:

   • в cmd: venvScriptsactivate

   • в PowerShell: .venvScriptsActivate.ps1

   После активации в начале строки появится префикс (venv) — с этого момента команды python и pip работают именно внутри этого окружения.

4. Устанавливаем зависимости в виртуальное окружение – берём готовый список зависимостей из самого llama.cpp:

   pip install -r requirements.txt
   

   Файл requirements.txt в корне llama.cpp уже перечисляет всё необходимое для Python-скриптов проекта (в том числе для convert_hf_to_gguf.py): PyTorch, transformers, gguf, numpy, sentencepiece, protobuf и т.д.

⚠️ Установка займёт время и скачает несколько гигабайт (в основном из-за PyTorch).

Проверка и использование:

1. Убедитесь, что префикс (venv) отображается в строке терминала — окружение активно.

2. Проверить, что зависимости на месте, можно так:

   python -c "import torch, transformers, gguf; print(torch.__version__)"
   

   Должны отобразиться версии установленных пакетов без ошибок. Если увидите ModuleNotFoundError — значит, окружение не активно или зависимости не установлены.

3. Создаем локальную модель Qwen3.8-27B

3.1 Скачиваем опубликованные веса модели

Официальные веса лежат в публичном репозитории Qwen на Hugging Face Hub — Qwen/Qwen3.8-27B (точное имя репозитория сверяйте на странице модели). В составе репозитория находятся следующие файлы:

• веса модели в формате safetensors, разбитые на части (файлы вида model-00001-of-00XXX.safetensors);

• служебные файлы: config.json, токенайзеры (tokenizer.json, tokenizer_config.json и др.), generation_config.json.

У модели порядка 27 млрд параметров, каждый из которых в 16-битном формате (BF16) занимает 2 байта: 27 × 10⁹ × 2 байта ≈ 54 ГБ (плюс немного на служебные файлы). Перед запуском скачивания убедитесь, что на целевом диске свободно не менее ~60 ГБ.

Предварительные условия:

• установлены huggingface-hub + hf_xet (пункт 1.2 выше) — команда hf доступна в терминале;

• модель публичная, поэтому токен Hugging Face не требуется.

Команда скачивания

Открываем терминал (cmd или PowerShell) и выполняем:

hf download Qwen/Qwen3.8-27B --local-dir D:modelsQwen3.8-27B

Разберём по частям параметры загрузки:

• Qwen/Qwen3.8-27B — идентификатор репозитория в формате «владелец/имя_репозитория».

• --local-dir D:modelsQwen3.8-27B — папка, куда складываются файлы. Без этого флага файлы установились бы в кэш по умолчанию (%USERPROFILE%.cachehuggingfacehub), откуда их потом пришлось бы переносить. Можно указать свой путь — главное, чтобы диск был подключён и на нём было не менее 60 ГБ свободного места.

⚠️ Примечания:

• Пока идёт загрузка, hf показывает прогресс по каждому файлу и фактическую скорость — по ней и стоит сверять оценку времени из расчёта ниже.

• Прерывание не страшно: если сеть упала или компьютер ушёл в сон, просто выполните ту же самую команду заново — загрузка продолжится с места обрыва, уже скачанные части повторно не качаются. Поэтому для многочасовой загрузки имеет смысл в настройках питания Windows выставить «Сон — Никогда».

Проверка результата

После завершения перечисляем содержимое папки:

dir D:modelsQwen3.8-27B

В папке должны присутствовать все safetensors из набора (без пропусков в нумерации частей), config.json, файлы токенайзера и generation_config.json. Совокупный размер файлов должен совпасть с размером репозитория, указанным на странице модели (~54 ГБ). Именно эту папку с весами мы укажем в пункте 3.2 ниже при конвертации в GGUF.

Оценим время скачивания при скорости 5 Мбит/с:

54 ГБ × 8 = 432 Гбит = 432 000 Мбит; 432 000 Мбит ÷ 5 Мбит/с = 86 400 с = 24 часа;

Итог – при такой скорости время скачивания модели составит около суток;

⚠️ Практический совет: запускайте скачивание на вечер выходного, отключите сон компьютера, и к утру следующего дня (или чуть позже) модель будет готова к конвертации в пункте 3.2 ниже.

3.2 Конвертируем веса в gguf-файл модели с точностью F16

Прежде чем выполнять команду, разберёмся, что именно мы делаем, зачем нужен формат GGUF и почему размер результата по размеру окажется практически таким же, как у исходных весов.

Зачем нужен формат GGUF

GGUF (GPT-Generated Unified Format) — бинарный формат хранения языковых моделей, созданный разработчиками llama.cpp. Это самодостаточный контейнер — в одном файле объединяется всё, что нужно для запуска модели:

• сами веса (тензоры всех слоёв сети);

• метаданные об архитектуре: количество слоёв, размер скрытого слоя, число головок внимания, размер контекста и т.д. — то есть всё, что движку нужно для правильной сборки графа вычислений;

• токенайзер (словарь): соответствия между токенами и текстом, служебные токены;

• дополнительные служебные параметры (шаблон диалога, имя модели и пр.).

До появления GGUF для работы с llama.cpp приходилось собирать набор из нескольких файлов: файл с весами, файл токенайзера, конфигурация — можно было легко потерять один из них или перепутать версии. Благодаря GGUF-формату всё лежит в одном контейнере, поэтому GGUF стал де-факто стандартом для локального запуска: его понимают llama.cpp и его производные, Ollama, LM Studio и другие движки.

Что именно происходит при конвертации

Скрипт convert_hf_to_gguf.py не обучает и не квантует модель — он последовательно делает три вещи:

1. Читает исходник. Скрипт получает папку с весами (результат пункта 3.1) и читает из неё config.json (по нему определяется архитектура модели и все её параметры), токенайзер и все части *.safetensors по очереди.

2. Переводит на «язык» llama.cpp. В Hugging Face тензоры именованы по собственным правилам (например, model.layers.0.self_attn.q_proj.weight), а llama.cpp ожидает свои имена (например, blk.0.attn_q.weight). В скрипте есть таблицы соответствий имён для каждой поддерживаемой архитектуры — по ним переименовываются все десятки тысяч тензоров. Там, где нужно, тензоры также перекладываются (транспонируются) под тот порядок хранения в памяти, который ожидает библиотека ggml; в зависимости от архитектуры и версии llama.cpp некоторые проекции могут объединяться или, наоборот, раздельно храниться. Это оптимизация для вычислений, и к квантованию отношения не имеет.

3. Приводит тип и упаковывает в один файл. Здесь работает флаг --outtype f16: каждый вес приводится из исходного типа (у моделей Qwen это BF16) к типу F16 (float16). Затем всё записывается в единый GGUF-файл последовательно: сначала заголовок (служебные байты GGUF, версия формата, метаданные: архитектура, токенайзер, параметры), затем по каждому тензору его описание (имя, размерности, тип, смещение в файле), и сами веса.

Почему общий размер модели при этом не меняется

Мы конвертировали модель в формат GGUF, а выходной файл получился примерно того же размера (~54 ГБ), что и исходники. Причина проста — конвертация с --outtype f16 не меняет размер выходного файла:

• В исходных safetensors каждый из 27 млрд параметров хранился как 16-битное число (BF16): 27×10⁹ × 2 байта ≈ 54 ГБ;

• В GGUF-файле каждый параметр по-прежнему хранится как 16-битное число (F16): 27×10⁹ × 2 байта ≈ 54 ГБ.

Всё, что мы сделали, это поменяли формат 16-битного числа, а не уменьшили количество бит. Разница между BF16 и F16 — во внутренней раскладке этих 16 бит: у BF16 шире динамический диапазон (8 бит экспоненты, как у FP32) при меньшей точности (7 бит мантиссы), у F16 диапазон уже (5 бит экспоненты), но точность выше (10 бит мантиссы). Для нейросетей это практически взаимозаменяемые форматы — отсюда и равенство размеров входных файлов и выходного GGUF-контейнера модели (на самом деле GGUF-файл может оказаться чуть больше суммы safetensors — на десятки мегабайт из-за накладных расходов контейнера (заголовок, метаданные, токенайзер, описания тензоров).

Сокращение размера модели происходит только на следующем шаге 3.3, при квантовании в Q4_K_M на каждый параметр в среднем уходит около 4,8 бита вместо 16, и файл уменьшается примерно втрое (~16–17 ГБ).

Запуск команды конвертации

Сначала создаём папку, в которой будет лежать результат:

mkdir ..modelsQwen3.8-27Bmy_conversions

Затем запускаем конвертацию (из папки llama.cpp, с активированным виртуальным окружением из пункта 2.1 выше):

(venv) D:llama.cpp>python convert_hf_to_gguf.py ..Qwen3.8-27B_official_sources_from_Qwen --outfile ../models/Qwen3.8-27B/my_conversions/Qwen3.8-27B-F16.gguf --outtype f16

Разберём команду по частям:

• ..Qwen3.8-27B_official_sources_from_Qwen — путь к папке со скачанными весами (результат пункта 3.1).

• --outfile ... — имя и путь результирующего GGUF-файла.

• --outtype f16 — точность весов в результирующем файле: F16 (float16).

Проверка результата

После завершения в папке my_conversions должен оказаться файл Qwen3.8-27B-F16.gguf размером ~54 ГБ. Время конвертации зависит от скорости диска: последовательно считывается ~54 ГБ и записывается примерно столько же, поэтому на HDD это может занять от десятка минут до часа и более. Если скрипт упал с ошибкой, то самая частая причина состоит в том, что зависимости не установлены в активном venv (шаг 2.1 выше): проверьте активацией окружения и командой python -c "import torch, transformers, gguf" установленные зависимости.

3.3 Выполняем квантование модели с параметром Q4_K_M

На этом шаге мы уменьшаем модель до размера, который влезает в нашу видеокарту. Напомню, что мастер-файл в F16 весит ~54 ГБ, а у RTX 3090 — 24 ГБ видеопамяти. Загрузить модель «как есть» не получится — пришлось бы раскидывать слои модели между GPU и оперативной памятью, что резко снижает производительность (узким местом становится медленная DDR4, скорость генерации токенов падает до 3-5 токеновсек). Квантование решает именно эту проблему.

Что происходит при квантовании

Квантование — это снижение точности, с которой в файле хранятся веса модели. В мастер-файле каждый из 27 млрд параметров занимает 16 бит (F16). При квантовании в Q4_K_M тот же параметр в среднем занимает около 4,8 бита. При этом веса не «обрезаются» до 4 бит напрямую: инструмент разбивает веса тензора на небольшие группы, для каждой группы подбирает масштабирующий коэффициент (scale) и смещение (min), а в файл записывает уже не сами значения, а сжатые 4-битные индексы плюс эти коэффициенты. При загрузке модели сервер llama.cpp восстанавливает приблизительные значения весов из индексов и коэффициентов — отсюда и название «квантование»: непрерывные числа заменяются набором дискретных уровней внутри каждой группы.

Что это даёт практически:

• Снижение размера файла. 27×10⁹ параметров × 16 бит ≈ 54 ГБ превращаются в 27×10⁹ × ~4,8 бит ≈ 16–17 ГБ — файл становится примерно в 3,3 раза меньше.

• Модель целиком помещается в видеопамять. ~16–17 ГБ весов плюс KV-кэш (контекст) укладываются в 24 ГБ RTX 3090, и инференс (ответ) у модели идёт полностью на VRAM GPU, без задействования RAM. Это главный практический выигрыш: модель не просто стала меньше, но ещё и работает на полной скорости видеокарты.

• Прирост скорости генерации. Генерация токенов упирается в пропускную способность памяти: чтобы выдать каждый новый токен, из памяти приходится перечитать все веса сети. Если объём данных в ~3 раза меньше, то и время на их чтение в разы меньше (реальный прирост чуть скромнее, но ощутимый).

• Небольшую потерю точности. Квантование — это сжатие с потерями: часть точности весов безвозвратно теряется, и обратно F16-версию из Q4_K_M восстановить не получится. Именно поэтому на шаге 3.2 мы сначала сделали полноразмерный мастер: из него можно получить модели других квантований при необходимости.

Почему выбран именно Q4_K_M

llama.cpp поддерживает много типов квантования — от Q2_K (~2,6 бита на вес) до Q8_0 (~8,5 бита). Больше бит — выше качество, но и больше файл. Ориентировочная карта размеров для нашей 27B-модели:

• Q4_K_S — ~4,5 бита — ~15 ГБ;

• Q4_K_M — ~4,8 бита — ~16–17 ГБ (наш выбор);

• Q5_K_M — ~5,9 бита — ~20 ГБ;

• Q6_K — ~6,6 бита — ~22 ГБ;

• Q8_0 — ~8,5 бита — ~29 ГБ (в 24 ГБ видеопамяти уже не помещается).

Буква K означает принадлежность к семейству «K-quants» — схемы хранения, которые точнее «простых» Q4_0/Q5_0. Их принцип — двухуровневое масштабирование: веса каждого тензора разбиваются на суперблоки по 256 значений, а каждый суперблок — на 8 малых блоков по 32 значения. Для каждого малого блока вычисляется собственный масштаб (scale) и смещение (min); для всего суперблока дополнительно хранится ещё один, более точный общий масштаб. Иными словами, каждый весовый параметр калибруется «на двух уровнях»: своим локальным коэффициентом внутри группы из 32 и общим для суперблока из 256. Ошибка округления отдельных весов до 4 бит таким образом частично компенсируется этими более точными коэффициентами групп — за счёт этого K-quants при том же числе бит заметно лучше сохраняют качество, чем старые одноуровневые схемы (Q4_0).

Буква M (Mix) означает, что это «смешанный» тип: большинство тензоров хранится в 4-битном представлении, но наиболее значимые для качества — в первую очередь выходной слой (матрица, предсказывающая токены) и часть внутренних MLP-проекций — сохраняются с повышенной точностью (Q6_K). Это стоит лишь несколько процентов размера и заметно улучшает качество по сравнению с «чистым» Q4_K_S. Поэтому Q4_K_M считается де-факто стандартом рекомендаций для локального запуска больших моделей: наилучший баланс «размер/качество», который ещё и влезает в 24 ГБ видеопамяти.

Как квантование делается с помощью llama-quantize

Инструмент llama-quantize входит в состав llama.cpp и уже собран вместе с остальными файлами в пункте 2 выше. В отличие от скрипта конвертации (пункт 3.2 выше), ему не нужен Python и виртуальное окружение — это готовый исполняемый файл, лежащий в папке buildbin рядом с llama-server.exe.

Запуск инструмента — это три аргумента: входной файл, выходной файл и тип квантования. Что происходит под капотом:

1. Читает мастер-файл. Открывает F16-GGUF из шага 3.2, считывает все тензоры, метаданные и токенайзер.

2. Квантует каждый тензор. Применяет описанную выше схему: разбивает веса на суперблоки, подбирает scale/min, сжимает значения в 4-битные индексы; для выделенных «важных» тензоров использует более точный Q6_K — это и есть часть «Mix».

3. Записывает результат в новый файл. Метаданные, параметры архитектуры и токенайзер копируются из мастера как есть, а веса записываются уже в новом сжатом формате. Получившийся файл самодостаточен: его так же, как и F16, можно отдать llama-server.

4. Исходный файл не трогает. Мастер в F16 остаётся нетронутым — если Q4_K_M по какой-то причине не устроит, из того же мастера можно сделать Q5_K_M или Q8_0, не качая и не конвертируя модель заново.

Операция выполняется на CPU (GPU не требуется), использует несколько ядер процессора, а её время ограничено в основном чтением ~54 ГБ с диска — на конфигурации из статьи это около 10 минут. В консоль при этом печатается отчёт по каждому тензору: имя, размерность и тип, в который он был записан (можно увидеть и основные q4_K, и более точные q6_K для отдельных слоёв).

Запуск команды квантования

Запускаем из корня папки llama.cpp (та же рабочая папка, что и на шаге 3.2). Сам инструмент лежит в подпапке buildbin, поэтому указываем его полным путём (либо заранее добавьте buildbin в PATH — тогда можно просто написать llama-quantize). Все остальные пути в команде относительные — отсчитываются от текущей папки:

buildbinllama-quantize ..modelsQwen3.8-27Bmy_conversionsQwen3.8-27B-F16.gguf ..modelsQwen3.8-27Bmy_conversionsQwen3.8-27B-Q4_K_M.gguf Q4_K_M

Разберём по частям:

• buildbinllama-quantize — сам инструмент llama-quantize.exe из папки сборки. Если buildbin есть в PATH, этот путь можно опустить.

• ..modelsQwen3.8-27Bmy_conversionsQwen3.8-27B-F16.gguf — входной файл: полноразмерный мастер, созданный на шаге 3.2. Он только читается и не изменяется.

• ..modelsQwen3.8-27Bmy_conversionsQwen3.8-27B-Q4_K_M.gguf — выходной файл. Кладем его рядом с мастером в my_conversions: все варианты модели остаются в одном месте.

• Q4_K_M — целевой тип квантования. Список всех поддерживаемых типов (q4_k_s, q5_k_m, q6_k, q8_0 и др.) можно посмотреть командой llama-quantize -h.

Проверка результата

После завершения в папке my_conversions должен оказаться файл Qwen3.8-27B-Q4_K_M.gguf размером ~16–17 ГБ (вместе с мастером F16). Проверяем:

dir ..modelsQwen3.8-27Bmy_conversionsQwen3.8-27B-Q4_K_M.gguf

Если размер близок к ожидаемому (~16–17 ГБ) — квантование прошло успешно, и файл готов к загрузке в llama-server на шаге 4. Мастер-файл (~54 ГБ) при этом по-прежнему лежит в my_conversions — оставьте его на месте: из него можно получить другие варианты квантования.

⚠️ Примечания:

• Свободное место. Перед запуском на целевом диске должно быть свободно не менее ~17 ГБ под результат (сам мастер при этом никуда не денется).

• Не удаляйте мастер раньше времени. Квантование — операция односторонняя: F16 из Q4_K_M не восстановить.

• Q4_K_M — не единственный вариант. Если после запуска покажется, что ответы модели заметно ухудшились, из того же мастера можно сделать Q5_K_M (~20 ГБ) — он тоже влезет в 24 ГБ видеопамяти и даст чуть лучшее качество. Q6_K (~22 ГБ) — верхняя граница для нашей карты; Q8_0 (~29 ГБ) целиком в VRAM уже не помещается.

4. Запускаем локальную модель Qwen3.8-27B

Все приготовления завершены: веса скачаны (пункт 3.1 выше), сконвертированы в GGUF (пункт 3.2 выше) и выполнения их квантизация в Q4_K_M (пункт 3.3 выше). Осталось загрузить модель в llama-server — серверную утилиту из состава llama.cpp, собранную в пункте 2. Она делает две вещи: поднимает HTTP-сервер с OpenAI-совместимым API (чтобы к модели могли обращаться программы) и предоставляет встроенный веб-интерфейс, где можно поговорить с моделью через чат в браузере.

Команда запуска (Windows, cmd):

llama-server -m ./my_conversions/Qwen3.8-27B-Q4_K_M.gguf -ngl 999 ^
 --port 8882 ^
 --temp 0.6  ^
 --top-p 0.95 ^
 --top-k 20 ^
 --min-p 0.00 ^
 -t 6 -c 64000 ^
 --cache-type-k q8_0 --cache-type-v q8_0 ^
 --parallel 1 --flash-attn on --presence-penalty 0.52 --repeat-penalty 1.0 --repeat-last-n 206 ^
 --reasoning-budget 8192 --reasoning-budget-message "Let's move on to the final answer." --chat-template-kwargs "{"reasoning_effort": "xhigh"}" ^
 --reasoning-preserve  --spec-type draft-mtp --spec-draft-n-max 3 ^
 --cache-ram 16384

⚠️ Два практических замечания перед разбором параметров:

• Символ ^ в конце строки — это знак продолжения строки в cmd: все эти строки вместе образуют одну команду, разбитую на строки для читаемости. В PowerShell роль ^ играет обратная кавычка `.

• Путь к модели указан относительно текущей папки: команду нужно выполнять из той папки, где лежит подпапка my_conversions (в нашей схеме это D:modelsQwen3.8-27B), либо поправить путь под своё расположение файла.

Теперь разберём каждый параметр по отдельности:

Что должно произойти после запуска:

1. В консоли сервер напечатает лог загрузки: архитектуру модели, распределение слоёв между GPU и CPU, размер KV-кэша, а затем строку вида listening on http://127.0.0.1:8882.

2. Открываем в браузере http://127.0.0.1:8882 — это встроенный веб-интерфейс на локалхосте, в нём можно сразу начать диалог с моделью.

3. Заработает программный доступ — через OpenAI-совместимый API на том же порту (например, http://localhost:8882/v1/chat/completions).

⚠️ Примечания:

• Остановка сервера — Ctrl+C в том терминале, где он запущен.

• Первый запуск может занять заметно больше времени, чем следующие: сервер прогревает (warmup) вычисления и выделяет память под KV-кэш.

• Если сервер сообщает, что часть слоёв не поместилась на GPU и осталась на CPU, то это не ошибка — просто уменьшите контекст (-c) или добавьте/усильте квантование KV-кэша; в нашем раскладе (Q4_K_M + q8_0-кэш + 64k контекст) всё должно уложиться в 24 ГБ VRAM.

• Все параметры выборки (temp, top-p, top-k, штрафы) можно менять не только в команде запуска, но и в запросах к API — там они переопределяют значения по умолчанию сервера.

Вместо итогов

Если вы дошли до этого места, то значит, вас можно поздравить с первым опытом настройки и запуска модели локально! Теперь вы можете оценить, какой объём действий на самом деле нужно выполнять для, казалось бы, простой операции запуска модели.

Встроенный чат модели по ссылке http://127.0.0.1:8882 замеряет скорость генерации токенов модели, у меня получилась скорость генерации от 30 (без mtp-параметров) до 55 токенов в секунду (с mtp-параметрами). Также скорость генерации токенов можно посмотреть в логах терминала, в котором запущен llama-server.

⚠️ Если скорость генерации у модели получилась в районе 5-10 в секунду, то нужно посмотреть, нет ли сообщения от llama-server о нехватке объёма VRAM.

Далее поднятый локальный сервер можно использовать как безлимитный API при разработке с помощью агентов, но это уже тема отдельной статьи.

Буду признателен за обратную связь по формату и целесообразности подобных инструкций. Спасибо за внимание!