Главная / Статьи / Kimi K3 и другие большие модели локально: пять открытых репозиториев

Kimi K3 и другие большие модели локально: пять открытых репозиториев

Пять open source-репозиториев, которые втискивают модели фронтирного масштаба в ноутбук или одну GPU с помощью стриминга с диска, кэширования экспертов и выгрузки, — с реальными цифрами скорости.

1386 слов

Фронтирные модели на столе, а не в дата-центре

Облачные модели больших лабораторий впечатляют и стоят дорого. Стоит построить на них что-то серьёзное, и счёт быстро растёт. Модели с открытыми весами, которые почти не уступают платным, существуют давно, но на обычной машине большинству всё равно приходилось покупать инференс у кого-то ещё. Горстка open source-проектов это меняет. И речь не об игрушечных моделях. Они нацелены на модели фронтирного класса, обучение которых стоило миллионы, и запускают их офлайн на вашем железе без платы за токены.

Все пять репозиториев ниже решают одну задачу: как ужать то, что создано для дата-центра, чтобы оно поместилось на столе? Отвечают они очень по-разному.

Что общего у этих проектов

Разрыв огромный. Модели вроде Kimi K3 нужно 1,56 ТБ только на хранение весов, а у ноутбука обычно 16 или 32 ГБ RAM. Каждый инструмент здесь — способ обойти это несоответствие, и способы делятся на три семейства:

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

Различаются они и в другом. Одни — универсальные движки инференса для сотен моделей, другие построены ровно под одну архитектуру. Одним нужна GPU, другие сознательно без неё обходятся. Некоторые — исследовательские эксперименты на грани возможного, а другие можно разворачивать уже сегодня.

1. Kimi K3 на C

Kimi K3 — mixture-of-experts-модель от Moonshot AI на 2,78 триллиона параметров, и в ряде бенчмарков она обходит Claude. Ещё недавно вы бы решили, что входной билет — серверная ферма размером со склад.

Этот репозиторий с этим не согласен. Это движок инференса на переносимом C99: 176 КБ кода и никаких зависимостей — ни BLAS, ни PyTorch, ни GPU. Автору удалось запустить полную модель на ноутбуке всего с 8 ГБ RAM.

Вывод побайтово совпадает на ноутбуке с 8 ГБ и на рабочей станции со 128 ГБ, меняется только скорость. С 8 ГБ вы ждёте около 26 секунд на токен — мучительно, но работает. Дайте ему достаточно RAM, чтобы вся модель держалась в памяти, и ожидание сократится до 5,6 секунды на токен.

Весь фокус в стриминге с диска. Поскольку K3 — mixture-of-experts-модель, на каждый токен активно лишь около 4% параметров. Движок читает с диска только нужных экспертов, прямо в вычисления, и даже не пытается держать в памяти всю модель. Весь движок — один C-файл без зависимостей.

Чтобы попробовать:

# Clone the repo
git clone https://github.com/FareedKhan-dev/kimi-k3-in-c.git
cd kimi-k3-in-c

# Build
make

# Run with a preset matching your hardware
./bin/k3 ~/k3model --trunk ~/k3trunk --preset laptop \
  --tok ~/k3model --prompt "The capital of France is" --gen 8

2. WARP

Если C-движок выше — минимальное доказательство концепции, то WARP — версия с серьёзной инженерией. Его сделала команда SQLiteAI: это встраиваемый движок инференса на C, который сохраняет ту же идею стриминга с диска и добавляет поверх настоящую оптимизацию.

Общий ствол модели остаётся в памяти, и с диска приходят только эксперты, выбранные для текущего токена. Вся оставшаяся RAM становится ограниченным кэшем экспертов, так что часто выбираемые эксперты остаются в памяти. Упреждающий роутер идёт ещё дальше: он предсказывает, какие эксперты понадобятся следующему слою, и начинает читать их заранее.

Итог: контейнер K3 сжимается с 1,56 ТБ до 982 ГБ, и его может запустить MacBook Pro с 64 ГБ, хотя лишь примерно на 0,6 токена в секунду.

Проект описывает себя как управляемый людьми и написанный LLM. Его долгосрочная цель слегка безумная: довести WARP до того, чтобы K3 работала достаточно хорошо и могла заниматься улучшением самой себя.

Установка:

# Clone
git clone https://github.com/sqliteai/waste.git
cd waste

# Build (requires C compiler)
make

# Run with auto-detected memory budget
./waste run ~/models/k3.waste "What is the capital of Italy?"

# Or specify a memory budget manually
./waste run ~/models/k3.waste "Explain quantum computing" --budget 48GB

3. Deltafin

Deltafin начинается с вопроса, который мало кому приходит в голову. Что, если запустить полную K3 — все 16 экспертов на каждый токен, без всякого прунинга — на потребительском железе, а потом сделать это максимально быстрым?

Это не столько инженерный выбор, сколько философия. Другие проекты срезают углы: обрезают экспертов, пропускают слои или используют черновую модель для спекуляции. Deltafin так не делает. Его правило качества звучит так: каждый токен решает только K3. Маленькие черновые модели могут угадывать наперёд, и именно отсюда берётся большая часть скорости, но K3 проверяет каждую догадку, и до вас ничего не доходит без её одобрения.

Цифры скромные, и их честно называют. Ноутбук на M1 Max сейчас выдаёт около 0,29 токена в секунду. Но самое интересное — график прогресса в README. Примерно за неделю проект вырос с 0,014 до 0,29 токена в секунду: двадцатикратный рост за счёт упорной оптимизации. Миссия проекта формулирует позицию прямо: скорость никогда не должна достигаться за счёт качества модели.

Команда считает успехом, если фронтирная модель работает на домашней системе примерно за 15 000 долларов вместо инфраструктуры на 2 000 000 долларов.

С чего начать:

# Download the latest release from GitHub
# https://github.com/gavamedia/deltafin/releases

# Run with model path (auto-detects hardware)
./deltafin --model /path/to/k3-checkpoint


# The binary handles expert routing, memory management,
# and hardware acceleration automatically.

4. llama.cpp

Это название вы, скорее всего, уже слышали. Именно llama.cpp сделал локальный инференс массовым.

Его создатель, Георгий Герганов, начал с простой идеи: запускать модели LLaMA на чистом C/C++ с минимумом зависимостей. Без PyTorch, без Python-рантайма, только прямая производительность от железа до модели. Идея выросла в самый популярный движок локального инференса. Он поддерживает сотни моделей на CPU, GPU (CUDA, Metal, Vulkan, SYCL) и даже на кое-каком необычном железе.

Вокруг него сложилась целая экосистема. Ollama, LM Studio и GPT4All, а также множество других инструментов в духе «просто запусти модель локально» внутри построены на llama.cpp. Его можно назвать ядром Linux для локального ИИ-инференса.

Использование:

# Install via Homebrew (easiest)
brew install llama.cpp

# Download and run any GGUF model from Hugging Face
llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF

# Or launch an OpenAI-compatible API server
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

# Build from source
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp && cmake -B build && cmake --build build

5. FlexGen

FlexGen подходит для другой ситуации: у вас одна обычная GPU, и за ночь нужно прогнать через модель миллионы токенов.

Это движок высокопроизводительной генерации от команды FMInference для запуска больших языковых моделей при ограниченной памяти GPU. Он опирается на эффективную по вводу-выводу выгрузку. Если веса не помещаются в память GPU, они уходят в RAM процессора или даже на диск, и вся схема настроена на пропускную способность, а не на низкую задержку.

Например, он может запустить OPT-175B, которой при полной точности нужно 350 ГБ памяти GPU, на одной T4 с 16 ГБ, выгружая веса на диск. Задержка на токен для чата никудышная. А вот для ночных пакетных задач вроде бенчмаркинга (есть интеграция со стэнфордским фреймворком HELM) или обработки данных — то, что нужно.

Все пять репозиториев идут к одной цели — запускать ИИ локально, каждый со своей стороны. Вместе они указывают одно направление: прочь от отправки ваших данных на серверную ферму, к сильнейшим моделям, которые живут на вашем собственном устройстве.