WASTE: движок, который гоняет Kimi K3 на 2,78 трлн параметров прямо с диска

Проект WASTE опубликовал встраиваемый инференс-движок на языке C без сторонних зависимостей, который умеет запускать модели со смесью экспертов (MoE), не помещающиеся в оперативную память целиком. Демонстрационный кейс, полная открытая версия модели Kimi K3 (2,78 трлн параметров, изначально опубликована как 1,42 ТБ, после конвертации в формат WASTE, 982 ГиБ). Движок запустил её на обычном ноутбуке MacBook Pro с 64 ГБ оперативной памяти со скоростью 0,45, 0,62 токена в секунду. Это не урезанная, не дистиллированная и не уменьшённая версия модели, используются все веса.

Идея в том, что у MoE-модели на каждый токен активируется лишь около 4% весов, остальные простаивают. WASTE держит в памяти постоянную «магистраль» модели (27,28 ГБ, это минимальный порог, ниже которого движок вообще не запустится) и стримит с диска только тех экспертов, которые нужны для текущего токена: один эксперт, ровно одно чтение с диска (pread), без лишних обращений. На каждый токен с диска читается около 17 ГБ данных экспертов. Веса экспертов хранятся сжатыми векторным квантованием (3,00 бита на вес), чтения идут в обход дискового кэша операционной системы, чтобы не искажать замеры. По умолчанию на машине с 64 ГБ движок берёт себе бюджет 46 ГБ, из которых 17,56 ГБ отводится под кэш экспертов.

Скорость чтения диска критична: на внутреннем SSD, 12,78 ГБ/с, и модель работает без задержек; при подключении диска через USB, только 0,94 ГБ/с, и то же чтение растягивается на тринадцать секунд вместо долей секунды. Авторы прямо советуют конвертировать модель на внутренний NVMe-диск, а внешний использовать только для скачивания.

Из возможных путей ускорения сработали не самые очевидные. Уменьшение числа читаемых байт и увеличение кэша в памяти, оба варианта не дали эффекта: у роутера этой модели нет «хвоста», который можно было бы отбросить, а кэш, который не помещается в память целиком, нельзя нарастить ни за какие деньги. Помогло другое: перекрытие чтения экспертов с диска с вычислениями (арифметикой) дало прирост скорости примерно в 1,6 раза. А упреждающая подгрузка, когда роутер следующего слоя запускается на промежуточном состоянии ещё до того, как этот слой реально нужен, и заранее заказывает чтение вероятных экспертов, подняла долю попаданий в кэш с 14% до 38%, не увеличив объём читаемых данных. Предсказание роутера оказывается верным в 92% случаев для лучшего варианта и в 81%, если считать по первым шести вариантам. Оба приёма точные: финальный результат генерации не меняется, меняется только момент, когда данные читаются с диска. Попытка ужать «магистраль» модели до 3-битного квантования, наоборот, не сработала, вывод модели заметно ухудшился, хотя предсказания кэша остались верными.

Корректность движка проверена сверкой с эталонной реализацией на PyTorch: итоговые логиты совпадают с точностью до 3,6×10⁻⁶, а визуальный модуль, до 2,3×10⁻⁶ относительно собственного эталона. В демонстрационном запуске (ответ на вопрос «Какая столица Италии?») движок выдал 16 токенов за 25,78 секунды (0,62 токена в секунду) с попаданием в кэш экспертов 9038 раз против 14514 промахов (38%). При этом промежуточная конфигурация с бюджетом 52 ГБ памяти показала себя крайне нестабильно: пять прогонов дали от 0,03 до 0,46 токена в секунду, разброс в пятнадцать раз при абсолютно одинаковой статистике попаданий в кэш (3652/8124), то есть дело не в самом движке, а в том, помещается ли его память в систему рядом с остальными процессами или нет. Авторы также фиксируют: если запустить конфигурацию на 46 ГБ сразу после тяжёлых прогонов на 52 или 58 ГБ, машина ещё не восстановилась от подкачки страниц (paging), и скорость может провалиться до 0,02 токена в секунду, такие замеры считаются недействительными.

Авторы говорят, что не нашли других опубликованных демонстраций стриминга модели такого масштаба с диска на потребительском железе, но подчёркивают, что это не системный обзор, а лишь то, что нашёл их собственный поиск: в репозитории нет ни библиографии, ни таблицы сравнения, и они прямо приглашают присылать контрпримеры. Формат и движок не привязаны именно к Kimi K3: та же связка запускает и модель поменьше, Kimi-Linear-48B-A3B-Instruct, контейнер которой занимает 19 ГБ, порог по памяти, 1,87 ГБ, а скорость, 10,7 токена в секунду; авторы называют её хорошим способом попробовать WASTE, не отводя под K3 отдельный диск.

Ключевые факты

Движок WASTE, встраиваемая C-библиотека без сторонних зависимостей: держит «магистраль» модели в памяти (порог 27,28 ГБ) и стримит веса MoE-экспертов прямо с диска, по одному чтению на эксперта.
На нём, по словам авторов (не проводивших системного обзора рынка), впервые публично показан запуск полной, не урезанной версии Kimi K3 (2,78 трлн параметров, контейнер 982 ГиБ) на обычном MacBook Pro с 64 ГБ ОЗУ, 0,45, 0,62 токена в секунду.
Корректность подтверждена сверкой с PyTorch-эталоном: логиты совпадают до 3,6×10⁻⁶.
Перекрытие чтения с диска и вычислений даёт ×1,6 к скорости, а упреждающая подгрузка экспертов следующего слоя поднимает попадания в кэш с 14% до 38% без роста объёма чтения, оба приёма точные, результат генерации не меняется.
Тот же движок и формат работают с моделью поменьше, Kimi-Linear-48B-A3B-Instruct (19 ГБ, порог 1,87 ГБ), на 10,7 токена в секунду, как более практичный способ попробовать инструмент.

Почему это важно

До сих пор запуск моделей такого масштаба (сотни миллиардов, единицы триллионов параметров) на потребительском железе считался нерешённой задачей: даже наиболее задокументированные схемы для моделей класса 671 млрд параметров рассчитаны на сервер с терабайтом памяти DDR5. WASTE показывает, что дело не в принципиальной невозможности, а в инженерии: полная модель на 2,78 трлн параметров реально отвечает на вопросы на обычном ноутбуке, пусть и медленно. Авторы сами оговариваются, что не проводили систематического обзора и не нашли других публичных демонстраций такого масштаба именно потому, что специально искали, то есть заявление о первенстве не абсолютное, но развёрнутого сравнения на рынке действительно нет. Важен и более широкий тезис проекта: каждый токен, отвеченный облачным API, оплачивается дважды, по счёту и электричеством дата-центра, и WASTE задуман как первый шаг к тому, чтобы часть этой траты можно было не платить вовсе, отвечая моделью локально.

Кому это важно

Инструмент нацелен на разработчиков, которым нужен ответ модели без сети и без счёта за токен: движок можно встроить прямо в своё приложение, публичный API состоит всего из двадцати шести функций (открыть модель под заданный потолок ОЗУ, сгенерировать ответ, сохранить сессию, закрыть), и CLI-утилита сама является лишь клиентом этого API, без скрытых привилегий. Это интересно тем, у кого данные не должны покидать машину (условие «нельзя отправить эти данные в API» превращается в «запусти это здесь»), исследователям и энтузиастам, которые хотят пощупать топовую открытую MoE-модель без сервера с терабайтом DDR5, а также разработчикам инференс-движков, как пример работающих и неработающих приёмов ускорения при чтении с диска.

Как это применить

Практически: 32 ГБ ОЗУ модель формально откроют, но с сильной подкачкой страниц, реальным требованием авторы называют 64 ГБ. Диск, на который сконвертирован контейнер, должен быть внутренним и быстрым (NVMe): через внешний USB-накопитель скорость чтения падает почти в 14 раз и чтение одного токена растягивается до тринадцати секунд, внешний диск годится только для скачивания. Конвертация делается один раз конвертером на Python (сам движок в рантайме Python не использует, только libc и pthreads). Для встраивания достаточно вызвать waste_open() с указанием жёсткого потолка памяти (ram_budget_bytes, 0, автоматический подбор под конкретную машину), затем waste_generate() и waste_close(). Есть переключатели: WASTE_LOOKAHEAD=0 отключает упреждающую подгрузку экспертов, WASTE_MLOCK=trunk закрепляет магистраль в памяти (на итоговую скорость не влияет), а флаг --verify включает проверку контрольной суммы каждой записи при промахе кэша (стоит около 1% времени на K3 и около 5% на Kimi-Linear, оправдано для скачанного, но не для сконвертированного самим пользователем контейнера). Тем, кто не готов выделять диск под 982-гигабайтный контейнер K3, авторы предлагают тот же движок и формат для модели поменьше, Kimi-Linear-48B-A3B-Instruct (контейнер 19 ГБ, порог памяти 1,87 ГБ, скорость 10,7 токена в секунду), как способ опробовать WASTE перед тем как связываться с K3.

Можно ли доверять

Соответствие эталону движок подтверждает численно: логиты финального выхода совпадают с расчётом на PyTorch до 3,6×10⁻⁶, визуальный модуль, до 2,3×10⁻⁶. Оптимизации (перекрытие чтения с вычислениями, упреждающая подгрузка) описаны как точные, статистика попаданий в кэш и итоговые числа идентичны при включённом и выключенном приёме, меняется только момент чтения, а не результат. Авторы честно фиксируют собственные ошибки измерений в отдельном документе, а не тихо их исправляют, и прямо признают, что их заявление о первенстве («не нашли других таких демонстраций») основано на собственном поиске, а не на системном обзоре рынка, в репозитории нет ни библиографии, ни таблицы сравнения. При этом в тексте источника не указано ни одно имя автора или компании: аккаунт, опубликовавший ссылку на Hacker News, это отправитель, а не подтверждённый автор проекта. Все цифры, собственные измерения авторов на конкретном коммите репозитория, независимого повторения замеров сторонними тестировщиками в источнике не приведено.

Риски и подводные камни

Главный компромисс, скорость: 0,45, 0,62 токена в секунду означает, что развёрнутый ответ модель печатает буквально по слову в несколько секунд, для интерактивного использования или продакшена это не подходит, инструмент годится для демонстрации возможности, а не для повседневной работы. Конфигурация чувствительна к точному объёму памяти: бюджет в 52 ГБ на той же машине даёт пятнадцатикратный разброс скорости (от 0,03 до 0,46 токена в секунду) при идентичной статистике кэша, то есть попадает ли процесс в доступную память рядом с остальной нагрузкой, решается ещё до старта и непредсказуемо для пользователя, а бюджет в 58 ГБ стабильно плох. Замеры на одной и той же машине искажаются порядком запуска: если прогнать конфигурацию на 46 ГБ сразу после тяжёлых прогонов на 52 или 58 ГБ, машина не успевает выйти из подкачки страниц, и скорость может упасть до 0,02 токена в секунду, авторы прямо называют такие числа недействительными. Попытка сжать резидентную «магистраль» модели до 3-битного квантования не удалась: кэш продолжал предсказывать верно, но скорость не выросла, а качество ответов заметно просело. И ниже минимального порога кэша экспертов (17,0 ГБ) попадания в кэш не «снижаются», а буквально равны нулю, работать в этом режиме бессмысленно.

«За каждый токен, отвеченный облачным сервисом, платят дважды: один раз по счёту, и второй раз, электричеством дата-центра, где крутится модель, которая, с трудом, неуклюже, но по-настоящему, поместилась бы на железо, уже стоящее на столе.»

— авторы проекта WASTE