Головна / Статті / 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) чи обробки даних — те, що треба.

Усі п'ять репозиторіїв ідуть до однієї мети — запускати ШІ локально, кожен зі свого боку. Разом вони вказують один напрямок: геть від надсилання ваших даних на серверну ферму, до найсильніших моделей, що живуть на вашому власному пристрої.