Kimi K3 запускает модель на 2,78 трлн параметров в 8,24 ГБ памяти

Запустить модель на 2,78 трлн параметров в восьми гигабайтах памяти звучит как фокус. Репозиторий kimi-k3-in-c показывает, где спрятана шляпа: модель не помещается в RAM и не пытается. Движок оставляет в оперативной памяти только рабочий набор данных, а большую часть весов читает с накопителя по мере расчёта.

По измерениям автора, полный запуск Kimi K3 достигает пикового потребления 8,24 ГБ RAM. GPU, BLAS и привычный ML-фреймворк не нужны: ядро написано на переносимом C99. Обратная сторона впечатляющей цифры — checkpoint размером 1,56 ТБ, дополнительно упакованный файл плотной части модели на 109 ГБ и десятки секунд ожидания каждого токена.

Как модель помещается в обычную память

Представьте шкаф, из которого для работы нужен один ящик за раз. Нет смысла тащить весь шкаф на стол: достаточно открыть нужный ящик, обработать содержимое и перейти к следующему. Здесь роль шкафа играет быстрый NVMe, а стола — оперативная память.

Kimi K3 использует разреженную архитектуру: на каждом шаге активна лишь часть экспертов. Движок читает выбранные экспертные веса прямо в упакованном четырёхбитном виде, хранит недавно использованные данные в LRU-кэше и последовательно подгружает плотные слои. Размер кэша и число постоянно находящихся в памяти слоёв можно менять под конкретную машину.

По опубликованной таблице, конфигурация с 8 ГБ RAM выдаёт токен примерно за 26,5 секунды. При 64 ГБ показатель сокращается до 19,8 секунды, а при 128 ГБ и более — до 5,6 секунды, поскольку ожидание диска почти исчезает. Автор утверждает, что при одинаковом запросе результат остаётся побайтно одинаковым: меняется время, а не вычисления.

Простой пример — продолжение фразы «The capital of France is». На минимальной конфигурации движок сгенерировал восемь токенов за 261,5 секунды при пиковом потреблении 8,24 ГБ. Это слишком медленно для пользовательского чата, но достаточно, чтобы доказать работоспособность подхода и исследовать модель без стойки ускорителей.

Что потребуется на практике

Главный барьер здесь не RAM, а хранилище. Для checkpoint, упакованной плотной части и служебных файлов требуется около 1,7 ТБ свободного места. Желателен быстрый локальный NVMe: если веса не помещаются в память, накопитель участвует в генерации каждого токена. На медленном SSD результат будет ждать ещё дольше.

Для сборки нужны компилятор C99, OpenMP и процессор с AVX2/FMA на x86-64 либо NEON на Arm. Репозиторий поддерживает Linux, macOS и Windows. Без загрузки многотерабайтной модели можно собрать движок и прогнать тестовый набор: он сравнивает операции и сгенерированные токены с эталонной реализацией на уменьшенной модели с той же вычислительной схемой.

Однако опубликованные показатели пока следует воспринимать как результаты самого автора, а не независимый бенчмарк. Минимальный режим — демонстрация технической возможности, не готовый сервер инференса. В первой версии нет инструментов, изображений, API-сервера и сжатия истории диалога. Даже мощная рабочая станция остаётся значительно медленнее облачного сервиса на GPU.

Зачем разработчику смотреть этот код

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

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