Kimi K3 локально: 2,78 трлн параметров на 8 ГБ ОЗУ

Открытая модель Kimi K3 от Moonshot AI - 2,78 триллиона параметров - теперь заводится на обычном компьютере с 8 ГБ оперативной памяти. Не в облаке, не на видеокарте, на голом CPU. Дальше по делу: как это устроено, что за это платишь по скорости и когда локальный запуск вообще имеет смысл.

Важный дисклеймер сразу. То, что модель гоняется в 8 ГБ ОЗУ, не значит, что порог входа низкий. Веса весят 1,56 терабайта на диске, качать долго, а инференс идёт медленно. Это способ иметь у себя ту же модель, что и топовый провайдер, без зависимости от него - не замена облаку по скорости.

Что за Kimi K3 и почему её пытаются гонять дома

Kimi K3 - открытая под лицензией Apache 2.0 LLM от китайской Moonshot AI. Веса выложены на Hugging Face 27 июля 2026. По размеру это самая большая опен-вейт модель на сегодня: 2,78 триллиона параметров, MoE-архитектура (на каждый запрос активны 16 экспертов из 896), контекст 1 миллион токенов, встроенная vision-башня.

По бенчмаркам она упирается в Claude Fable 5 и GPT-5.6, но обходит Claude Opus 4.8 и GPT-5.5 в коде и агентных задачах. Для локального запуска в память её загрузить не выйдет - на bfloat16 нужны десятки топовых GPU. Ровно поэтому появился проект kimi-k3-in-c от Fareed Khan: C99-реализация инференса, которая гоняет ту же модель на одном CPU и обходится 8,24 ГБ ОЗУ в пике.

Как модель на 1,56 ТБ помещается в 8 ГБ ОЗУ

Ключевая идея - модель не грузится в память целиком. Веса лежат на диске (1,56 ТБ, 96 шардов), а в оперативку подтягивается только тот кусок, который нужен для текущего токена. Автор называет это trunk streaming.

Сверху идут три оптимизации: квантование routed-экспертов, sparse routing (за один запрос активна крошечная доля экспертов), LRU-кэш для кусков, к которым обращаются часто. В сумме - 675-кратное сжатие относительно исходного bfloat16 без потери точности: выход посимвольно совпадает с эталоном при любом пресете памяти.

Весь инференс укладывается в семь C-файлов. Никакого BLAS, никакого фреймворка, никакого GPU - только компилятор C и OpenMP. У репозитория Apache 2.0 и на момент написания статьи около 2,2 тысячи звёзд.

Реальный порог входа: диск, скорость, ограничения

Оперативки нужно 8 ГБ - это правда. Но помимо неё:

• Диск: 1,56 терабайта. Модель нужно скачать целиком с Hugging Face. При канале 1 Гбит/с - около получаса, при обычном домашнем интернете - сутки-двое.
• Скорость инференса. Точных tokens/sec автор в quickstart не приводит, но физика простая: движок постоянно тянет веса с диска, быстрее последовательного чтения SSD не станет. Для интерактивного чата не годится, для батчевых задач - нормально.
• Доступ к весам. Нужен HF_TOKEN от Hugging Face, чтобы вообще скачать шарды.
• ОС и компилятор. Linux или macOS, C-компилятор и OpenMP. Под Windows нативной поддержки нет, только через WSL.

То есть это не замена облачному Kimi для повседневной работы. Это возможность иметь ровно ту же модель локально - для приватных данных, оффлайн-сценариев и страховки от отключения провайдера.

Как запустить kimi-k3-in-c - готовые команды

Минимальный путь из quickstart автора репозитория:

git clone https://github.com/FareedKhan-dev/kimi-k3-in-c
cd kimi-k3-in-c
make -j
make test

export HF_TOKEN=...
./scripts/download-model.sh ~/k3model
./scripts/pack-trunk.sh ~/k3model ~/k3trunk

./bin/k3 ~/k3model \
  --trunk ~/k3trunk --preset server \
  --tok ~/k3model \
  --prompt "The capital of France is" --gen 16 --incremental

Перед скачиванием весов есть смысл прогнать ./scripts/k3-doctor.sh - скрипт проверяет машину и подбирает пресет памяти под неё, чтобы не выяснить на 1,56 ТБ скачки, что у тебя мало SSD.

Если не хочется разбираться с ошибками сборки, make и HF_TOKEN руками - отдай задачу Claude Code одним запросом:

В Claude Code вставь запрос:
"Склонируй github.com/FareedKhan-dev/kimi-k3-in-c, собери проект через
make -j, прогони make test и покажи вывод. Если сборка или тест падают -
объясни причину и предложи фикс. Мой стек: <ОС и версия компилятора>.
Перед тем как качать веса, запусти ./scripts/k3-doctor.sh и покажи
рекомендованный пресет памяти."

Он поставит зависимости, разберётся с версией OpenMP, объяснит, какой пресет подходит под конкретное железо, и не даст запустить скачку 1,56 ТБ на систему, которая её не потянет.

Мини-версия на 0,40B - для чего она реально

На Hugging Face есть inference-optimization/Kimi-K3-0.40B - модель на 400 миллионов параметров вместо 2,78 триллиона. На первый взгляд звучит как "быстрая версия K3 для тех, кому не нужна большая". По факту в карточке модели прямо написано: "This is a tiny version created for testing and development" - тестовый артефакт для разработчиков инференс-кода.

Что это значит на практике: контекст всего 4096 токенов вместо миллиона, vision-башня необучена, стандартный AutoModelForCausalLM её не подхватит, нужен кастомный код из llmcompressor.modeling.kimi_k3. Ставить как замену большой модели для повседневных задач бессмысленно. Смотреть на неё стоит только если сам пишешь инференс-движок и нужен маленький клон с той же архитектурой для отладки.

Локальная модель или облако: когда что выбирать

Простое правило, которого я держусь:

• Облако - когда скорость важнее контроля. Черновики, идеи, переписывание постов, обычная рабочая переписка. Ответ за секунду, платишь за токены.
• Локальная модель - когда данные не должны уходить наружу или нужна страховка от блокировок. Клиентские базы, юридические договоры, персональные документы, черновики продукта до анонса. Медленнее в разы, зато ни один облачный провайдер не читает то, что ты в неё пишешь.

Гибрид рабочий: облако для драфтов и генерации, локалка - для финальной обработки того, что нельзя показывать наружу.

Что делать, если не хочется собирать C99

Есть более лёгкие пути к тем же весам, если руками собирать C-код не хочется.

Первый - unsloth/Kimi-K3-GGUF на Hugging Face. Те же веса в квантованных GGUF-форматах, работают в llama.cpp и LM Studio из коробки, без компиляции. Порог по железу выше (нужно больше ОЗУ или мощный GPU для приличной скорости), зато не надо трогать make и OpenMP.

Второй - AirLLM (lyogavin/airllm на GitHub). Это Python-библиотека, которая тоже стримит слои с диска, но заточена под ситуацию "маленький GPU + большая модель", а не "чистый CPU", как kimi-k3-in-c. Другая ниша, тоже рабочая, если у тебя есть 4-8 ГБ VRAM и не хочется гонять всё на процессоре.

FAQ

Реально работает на 8 ГБ ОЗУ?

Да. Автор репозитория kimi-k3-in-c заявляет 8,24 ГБ пиковой памяти на CPU и приводит воспроизводимые тесты. Код открытый, требования проверяемы.

Сколько весит модель на диске?

1,56 терабайта, 96 шардов. Скачать нужно один раз, потом гонять локально без сети.

Быстрее, чем облачный Kimi?

Нет, заметно медленнее. Это не про скорость, это про приватность и независимость от провайдера. Для интерактивного чата лучше облако, для приватных батчевых задач - локалка.

Нужна видеокарта?

Нет. kimi-k3-in-c работает на чистом CPU, никакого GPU не требует. GGUF-вариант через llama.cpp может утилизировать GPU, если он есть, но это отдельный путь.

Есть ли смысл ставить мини-модель на 0,40B для повседневки?

Нет. Автор карточки на Hugging Face прямо пишет, что это тестовый артефакт для разработчиков инференса, а не полноценная модель. Контекст урезан до 4096 токенов, vision-башня не обучена.

Что дальше

Если хочешь собрать такую систему у себя - у меня есть курс по вайбкодингу и работе с нейросетями в клубе Мандарин Лаб: mandarinedu.ru. Первые уроки открыты бесплатно.

Если нужно внедрить ИИ в бизнес - процессы, агентов, автоматизацию под вашу задачу - пишите мне напрямую: t.me/Philigranchik. Разберу задачу и скажу, что реально автоматизируется, а что нет.