UNIXS.RU

Компания Moonshot опубликовала данные о размере модели с 2,8 триллионами параметров, и самая маленькая из основных динамических квантизаций занимает 594 ГБ. Именно эта цифра определяет все остальное, что касается запуска Kimi K3 на вашем собственном оборудовании. Она не помещается ни на рабочей станции, ни на одном H100, а машины, способные её вместить, сдаются в аренду почасово.

Оригинальный контент с computingforgeeks.com — пост 170430

В этом руководстве рассказывается, что на самом деле требуется для локального запуска Kimi K3: размеры квантования GGUF, минимальный объём ОЗУ и видеопамяти для каждого из них, как загрузить 594 ГБ весов и скомпилировать файл llama.cpp, адаптированный под конкретную архитектуру, а также пропускную способность по токенам, которую мы измерили на четырёх графических процессорах A100 с 2 ТБ системной памяти. Результаты по скорости — это та часть, с которой стоит ознакомиться, прежде чем арендовать какое-либо оборудование. Все приведенные ниже цифры были измерены в августе 2026 года в Ubuntu 24.04 с драйвером 580.159.03 и CUDA 12.6 при запуске llama.cpp b10245 и квантизатор UD-IQ1_S на четырёх картах A100-SXM4-40GB.

Kimi K3 в цифрах

Технические характеристики взяты из официальной спецификации карты и из данных, которые llama.cpp выводит при загрузке файла.

Свойство	Значение
Общее количество параметров	2,8 Т (llama.cpp считывает 2779,48 Б из GGUF)
Активные на один токен	104B, выбрано 16 экспертов из 896
Слои	93
Размер скрытого слоя	7168
Внимание	Kimi Delta Attention плюс остатки внимания
Контекстное окно	1 048 576 токенов
Визуальный кодер	MoonViT-V2, 401 млн параметров
Лицензия	Лицензия Kimi K3

Архитектура «смеси экспертов» (mixture-of-experts) делает модель теоретически доступной. На каждый токен активируется всего 104 млрд параметров, хотя в памяти находится 2,8 трлн. Это облегчает вычисления. Однако это не влияет на объем занимаемой памяти, поскольку маршрутизатор может выбрать любого эксперта для любого токена, поэтому все они должны оставаться в памяти. Обратите внимание, что в файле llama.cpp GGUF обозначен как 2.8T.A50B, что является собственным учетом активных весов, поэтому не пугайтесь, если загрузчик не согласуется с картой модели.

Рассчитайте необходимый объем памяти

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

Квант	Размер на диске	Требуемый объём ОЗУ и видеопамяти
UD-IQ1_S	594,0 ГБ (14 шардов)	610 ГБ
UD-IQ1_M	648,9 ГБ	665 ГБ
UD-IQ2_XXS	711,1 ГБ	726 ГБ
UD-Q2_K_XL	861,3 ГБ	880 ГБ
UD-Q4_K_XL	1 508,7 ГБ	1,56 ТБ
UD-Q8_K_XL	1 561,2 ГБ	1,6 ТБ

Важна совокупная память, а не только VRAM. Учитывая флаг, описанный в разделе «Обслуживание» ниже, файл llama.cpp хранит веса экспертов в системной оперативной памяти и запускает эти тензоры на бэкенде ЦП — это единственная причина, по которой система с четырьмя графическими процессорами и 160 ГБ VRAM вообще может загрузить модель объёмом 594 ГБ. Ничто не передается по шине; эксперты просто выполняются там, где они находятся. Пригоден ли результат к использованию — это отдельный вопрос, и ответ на него даёт раздел с результатами тестирования.

Наша тестовая система состояла из четырёх карт A100-SXM4-40GB, двух процессоров AMD EPYC 7542, обеспечивающих 128 потоков, и 2015 GiB оперативной памяти. Если вы подбираете конфигурацию собственной системы, разница между объёмом видеопамяти (VRAM) и объёмом объединенной системной памяти имеет здесь большее значение, чем в случае любой другой локальной модели, и разбор соотношения между объединённой памятью и VRAM объясняет, почему. Для бюджетов, рассчитанных на одну карту, и моделей обычного размера соотношение «VRAM к размеру модели» и рейтинги графических процессоров для локальных LLM охватывают разумный сегмент рынка.

Скачать веса

Каждая команда здесь выполняется от имени пользователя root, который предоставляется в арендованных образах с GPU. На компьютере, где вы не являетесь пользователем root, добавьте перед установкой пакета префикс sudo и укажите K3_DIR на путь, принадлежащий вашему пользователю. Настройте пути один раз, чтобы остальные команды оставались короткими:

export K3_DIR=/root/k3
export K3_QUANT=UD-IQ1_S
export K3_MODEL="${K3_DIR}/${K3_QUANT}/Kimi-K3-${K3_QUANT}-00001-of-00014.gguf"

CLI Hugging Face — самый быстрый способ переместить такой объём данных. Передача данных теперь осуществляется через бэкенд Xet, который поставляется в качестве базовой зависимости. Во многих руководствах до сих пор рекомендуется установить hf_transfer дополнительный модуль и экспортировать HF_HUB_ENABLE_HF_TRANSFER; однако этот дополнительный модуль больше не существует в текущих huggingface_hub релизах, а переменная является устаревшей и не выполняет никаких действий. Ubuntu помечает системный Python как управляемый извне, поэтому устанавливайте в virtualenv, а не пытайтесь бороться с pip:

apt install -y python3-venv
python3 -m venv "${HOME}/.venvs/hf"
"${HOME}/.venvs/hf/bin/pip" install -U huggingface_hub
export PATH="${HOME}/.venvs/hf/bin:${PATH}"
export HF_XET_HIGH_PERFORMANCE=1
hf download unsloth/Kimi-K3-GGUF --include "${K3_QUANT}/*" --local-dir "${K3_DIR}"

Большинство арендуемых образов с GPU уже помещают вас в среду Python с conda или virtualenv, и в этом случае первые три строки не нужны. По каналу связи дата-центра все 594 ГБ были загружены за 235 секунд со стабильной скоростью 2,5 ГБ/с. Для домашнего подключения следует рассчитывать на гораздо больше времени. При полной пропускной способности линии такая же передача данных займет около 80 минут при скорости 1 Гбит/с и более 13 часов при типичном домашнем подключении со скоростью 100 Мбит/с, а поскольку реальная пропускная способность составляет около 85–90 процентов от этих значений, планируйте примерно 90 минут и 15 часов соответственно. Перед продолжением проверьте количество фрагментов:

du -sh "${K3_DIR}/${K3_QUANT}" && ls "${K3_DIR}/${K3_QUANT}" | wc -l

Четырнадцать фрагментов общим объёмом 554 GiB составляют полный набор UD-IQ1_S:

554G	/root/k3/UD-IQ1_S
14

Оставьте фрагменты на своих местах. llama.cpp считывает весь набор из первого файла, поэтому выполнять слияние не требуется.

Скомпилируйте llama.cpp с поддержкой Kimi K3

По состоянию на август 2026 года основная ветка llama.cpp не поддерживает эту архитектуру, хотя в исходном репозитории открыт и находится в активном состоянии пулл-реквест, добавляющий текстовую модель. Unsloth поддерживает ветку, которая работает на сегодняшний день. Она также содержит модуль обработки изображений MoonViT, который не рассматривается в данном руководстве, поскольку при загрузке по ссылке выше извлекается только каталог quant, а отдельный файл проектора, необходимый для обработки изображений, пропускается. Склонируйте форк и перейдите в ветку с пулл-реквестом:

git clone https://github.com/unslothai/llama.cpp
cd llama.cpp
git fetch origin pull/48/head:kimi-k3-fullsize-vision
git checkout kimi-k3-fullsize-vision
git checkout daef2b3e1b5b1ac7b575f13b13a9450cb2d02862

Последняя строка не является обязательной, но рекомендуется. Головка пулл-реквеста по-прежнему обновляется, и daef2b3e — это именно тот коммит (сборка b10245), на основе которого были получены все приведённые ниже значения.

Соберите с включенной поддержкой CUDA. Установка архитектуры, соответствующей вашим картам, значительно сокращает время компиляции; для A100 подходит значение 80. Для Ada используйте 89, а для Hopper — 90. Blackwell делится на две части: 100 охватывает модели для центров обработки данных B100, B200 и GB200, а 120 — серию RTX 50 и RTX PRO 6000. Обе целевые архитектуры Blackwell требуют CUDA 12.8 или более поздней версии. Само по себе число архитектуры обеспечивает компиляцию PTX вместе с кодом устройства, поэтому карта, более новая, чем ваша целевая, всё равно запускает бинарник, выполняя его динамическую компиляцию (jitting), но обратное неверно: если вы скомпилируете для 90 и запустите на A100, то не получите образа ядра, доступного для выполнения на устройстве.

cmake -B build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=80
cmake --build build --config Release -j $(nproc) \
  --target llama-cli llama-server llama-bench llama-gguf-split

Это заняло 248 секунд на 128 ядрах. Запускайте загрузку и сборку одновременно, поскольку ни одна из этих операций не конкурирует за ресурсы другой, а вместе они составляют основную часть затрат на настройку. Если CUDA ещё не работает на хосте, сначала воспользуйтесь нашим руководством по установке драйвера NVIDIA и CUDA, чтобы решить эту проблему.

Загрузка и обслуживание модели

Вот конфигурация, которая фактически была загружена на систему с 160 ГБ VRAM. Веса MoE обрабатываются на CPU, всё остальное — на GPU:

./build/bin/llama-server \
  --model "${K3_MODEL}" \
  --n-gpu-layers 99 --cpu-moe --no-mmap \
  --ctx-size 8192 --temp 1.0 --top-p 0.95 \
  -t $(nproc) --host 127.0.0.1 --port 8080

Здесь ключевую роль играют два флага. --cpu-moe сохраняет тензоры экспертов каждого слоя в системной оперативной памяти, что и позволяет модели пройти обучение. --no-mmap загружает весь файл в память, а не выгружает его с диска по мере необходимости, и при наличии 2 ТБ оперативной памяти это правильное решение, поскольку выгрузка 554 ГиБ через кэш страниц при обработке каждого токена приводит к катастрофе. Загрузка заняла около девяти минут.

Два предупреждения по поводу второго флага. Теперь файл llama.cpp выводит уведомление об устаревании, направляющее вас к --load-mode, и истинным эквивалентом --no-mmap — это --load-mode none, а не --load-mode mmap , как, судя по всему, подсказывает сообщение. Что ещё важнее: полностью откажитесь от --no-mmap вовсе, если суммарный объём вашей RAM и VRAM меньше, чем quant. Именно отображение памяти позволяет машине с недостаточным объёмом памяти переключиться на чтение весов с диска, вместо того чтобы быть убитой «жнецом» OOM. Это будет мучительно медленно, но программа будет работать.

Значения параметров выборки соответствуют рекомендациям Moonshot. Температура 1,0 с top-p 0,95 для одношаговой работы, top-p 1,0 для агентных циклов. Прежде чем тратить на это реальное время, убедитесь, что сервер действительно отвечает:

curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"Say hello."}],"max_tokens":16}'

От этого вызова следует ожидать двух вещей. При измеренной скорости на ответ этих шестнадцати токенов уходит примерно две с половиной минуты, что является первым честным сигналом о том, как будет выглядеть остальная часть процесса. И ответа не поступает. K3 — это модель, предназначенная исключительно для мышления, поэтому столь низкий лимит полностью расходуется на мыслительный процесс. В зависимости от того, распознаёт ли парсер форка теги мышления K3, вы получите пустой content с мыслью, извлечённой в reasoning_content, либо content , заполненный необработанными мыслями. В любом случае при шестнадцати токенах ответа нет, а сервер продолжает работать. Позже это поведение становится реальной проблемой, и в разделе о качестве к этому вопросу ещё вернёмся.

На чем на самом деле работает Kimi K3

Скорость обработки промптов составила 12,87 токенов в секунду при использовании llama-bench, а при коротких промптах через сервер — от 5,5 до 6,2 токенов в секунду. И на этом история заканчивается: 0,10 токена в секунду, и оставалась стабильной на протяжении всего окна выборки.

Один токен каждые десять секунд — это непригодная модель чата. Ответ из 500 токенов занимает час и двадцать три минуты. Мы прервали llama-bench тест генерации через 17 минут, поскольку не было обработано даже 128 токенов, а на один короткий вопрос так и не был сгенерирован полный ответ в рамках арендованного бюджета.

Причина кроется в пропускной способности памяти, а не в вычислительной мощности. Загрузка графического процессора на протяжении всего теста колебалась от 0 до 1 процента, при этом использовалось лишь 64 ГБ из 160 ГБ видеопамяти. Каждый токен должен извлекать свой активный набор экспертов из системной оперативной памяти, и именно это чтение является «бурьевым барьером». Добавление графических процессоров не помогает, если только их количество не достаточно для размещения всей модели.

Две попытки настройки не привели к значимым изменениям. Передача --numa distribute на этой восьмиузловой NUMA-машине дало от 5,85 до 6,12 токенов в секунду при обработке запросов по сравнению с 5,54–6,23 без него, что находится в пределах погрешности. Ядро также отметило, что numa_balancing как включенный и снижающий производительность, а этот файл в контейнере доступен только для чтения, поэтому его нельзя было отключить.

Ошибка: «cudaMalloc failed: out of memory» при выделении 96937,09 MiB на устройстве 3

Попытка сохранить эксперты последних 15 слоёв на графических процессорах с помощью --n-cpu-moe 78 немедленно заканчивается сбоем:

ggml_backend_cuda_buffer_type_alloc_buffer: allocating 96937.09 MiB on device 3: cudaMalloc failed: out of memory
alloc_tensor_range: failed to allocate CUDA3 buffer of size 101645909504
llama_model_load: error loading model: unable to allocate CUDA3 buffer

Объёма VRAM было достаточно. Проблема заключалась в распределении. Файл llama.cpp назначает индексы самых верхних слоёв последнему устройству, поэтому все 15 экспертных слоёв, размещённых на GPU, оказались на одной карте объёмом 40 ГБ, и система запросила у неё 97 ГБ. Для уравновешивания этой ситуации требуется явное -ot распределение тензоров по четырём устройствам, а не использование упрощённого подхода, основанного на количестве слоёв. Учитывая, что основным ограничением является общая пропускная способность памяти, выгода от правильного выбора этого регулярного выражения невелика.

Хорош ли результат?

Оценивать качество по 1-битовому кванту, работающему со скоростью одну десятую токена в секунду, несправедливо по отношению к модели, поэтому мы вместо этого запустили те же запросы на хостируемой эталонной модели. Moonshot обучает и использует K3 с весами MXFP4, так что даже это не BF16, но модель ведет себя так, как задумывали её авторы. Оба ответа были правильными.

При решении задачи об объединении пересекающихся интервалов модель выдала стандартное решение «сортировка, затем проход» со сложностью O(n log n), правильно обработав соприкасающиеся интервалы, такие как [1,4] и [4,5] как поддающиеся слиянию, возвращала новые списки, а не изменяла входные данные вызывающего кода, и перечисляла пустой вход, одиночные интервалы, неотсортированный вход и полностью вложенные интервалы в качестве обрабатываемых случаев.

При получении трапа systemd с вопросом, почему SSH завершает работу после перезагрузки, когда ssh.socket отключен в Ubuntu, система определила активацию сокета в качестве механизма, объяснила, что отключение модуля сокета не приводит к включению ssh.service, и предложила как путь повторного включения, так и явный переход на автономный демон. Это правильный ответ на вопрос, который ставит в тупик многих администраторов.

Одно из таких поведений обойдётся вам дорого, если вы его упустите. По умолчанию Kimi K3 требует очень больших затрат на вывод заключения. При ограничении вывода в 1200 токенов наш вопрос о systemd вернул совершенно пустой результат, причём все 1200 токенов были израсходованы на скрытое вычисление. Увеличение лимита до 4000 токенов снова привело к пустому результату после 4088 токенов вычислений, причём оплата производилась за пределами лимита, а не останавливалась на нём. Только снижение интенсивности вывода привело к получению ответа, на который ушло 1116 токенов. Запланируйте пять тысяч или более токенов на вывод за каждый вызов, либо уменьшите интенсивность вывода, иначе вы будете платить за «мысли» и ничего не получите.

Сколько стоит запуск Kimi K3 локально

Приобретение оборудования, на котором эта модель работает хорошо, — это не решение для домашней лаборатории. Чтобы поместить все 594 ГБ в VRAM и избежать нехватки пропускной способности при генерации, потребуется как минимум восемь карт по 80 ГБ, а Unsloth сообщает о производительности примерно 20 токенов в секунду на оборудовании класса B200. Самая плотная карта для рабочей станции, которую можно заказать, — это 96 ГБ RTX PRO 6000 Blackwell, и даже для 1-битового квантирования потребуется семь таких карт. Это уже стойка, а не рабочая станция.

Честное сравнение — это аренда. Наша система из четырёх A100 обходилась в 3,87 доллара в час, а весь процесс, включая загрузку, сборку и тестирование, стоил 8,29 доллара. В результате получилась модель, слишком медленная, чтобы с ней можно было «пообщаться». Сервер, достаточно мощный для быстрой работы, стоит в несколько раз дороже в час, а хостинг Kimi K3 обходится в 3 доллара за миллион входных токенов и 15 долларов за миллион выходных. Окупаемость по сравнению с API измеряется месяцами непрерывного использования, и эти расчёты оправданы только в том случае, если у вас есть нормативные требования, обязывающие хранить весовые коэффициенты в собственном здании. Мы арендовали ресурсы через vast.ai, где секундная тарификация позволяет проводить подобные эксперименты недорого.

Для большинства людей практичным решением будет использовать Kimi K3 в качестве API-модели, а на собственном оборудовании запускать что-то меньшего размера. Модель класса 30B на одной карте объёмом 24 ГБ обеспечивает интерактивную скорость для реальной работы, и обновленная RTX 3090 остаётся самым дешёвым способом попасть в этот ценовой диапазон. Наше руководство по локальному LLM llama.cpp и настройка Ollama охватывают именно этот путь. Если вам нужен именно K3 без аппаратного обеспечения, Kimi CLI с OpenRouter предоставляет к нему доступ через ключ API. Для обслуживания моделей с производственной параллельностью, а не для однопользовательского чата, следует сравнить движки SGLang и vLLM, и любой, кто подбирает машину для локального вывода, должен начать со сборки локальной рабочей станции ИИ.