Что именно сделал Grawnch: суть эксперимента за минуту
Kimi-K3.1-Pro - MoE-модель на 2,8 трлн параметров, которая даже в нативном MXFP4/BF16 занимает около 1,77 ТБ. Чтобы просто удержать её в видеопамяти, нужно примерно 22 GPU по 80 ГБ. Энтузиаст под ником Grawnch сжал модель до 775 ГБ и запустил на одной видеокарте.
Сжатие выборочное. Квантованию подверглись только маршрутизируемые MoE-эксперты, по трём уровням точности: 2,81, 2,56 и 1,44 бита на вес (bpw), в среднем около 1,92 bpw против примерно 4,0 bpw у базовой модели. Shared-эксперты, слои внимания и эмбеддинги остались в нативном BF16/F32. Итог: 775 ГБ, на 56% меньше исходных 1,77 ТБ.
Запуск прошёл на одной NVIDIA RTX PRO 6000 Blackwell (96/102 ГБ VRAM) с 176 ГБ системной RAM, замеры делались в Colab. Заявленные цифры: 36,8 tok/s в batch/prefill и 10,8 tok/s в одиночном декоде, 29/30 на AIME 2025 и 29/30 на LiveCodeBench, как у полной модели. Работает это на двух самодельных компонентах: загрузчике и движке офлоада Strata и библиотеке fused-ядер деквантования dr-triton.
Главное ограничение проговорим сразу: перед нами результаты одного автора в Colab, а не независимое тестирование. Ниже методика, цифры и то, где заканчивается применимость. Первоисточник - пост Grawnch в r/LocalLLaMA.
Почему 2,8 трлн параметров - это отдельная инженерная задача
MoE (Mixture of Experts) экономит вычисления, а не память. На каждом токене роутер выбирает небольшую часть экспертов, и модель считает только их. У Kimi-K3.1-Pro 93 слоя, и в каждом 384 маршрутизируемых эксперта: даже если на один токен активируются единицы, все веса должны где-то лежать.
Отсюда 1,77 ТБ и примерно 22 GPU по 80 ГБ только для размещения. Это стоимость хранения, а не счёта. И 1,77 ТБ - это уже сжатый нативный формат: в чистом BF16 те же 2,8 трлн параметров заняли бы порядка 5,6 ТБ.
Цель эксперимента формулировалась прямо: уместить полную 93-слойную модель на одну GPU плюс системную RAM плюс быстрый NVMe, не убив способности к кодингу и математике. Компромисс по точности допустим, потеря работоспособности на задачах - нет.
Готовые схемы вроде Q4_K_M в llama.cpp применяют одну сетку точности к большинству тензоров слоя. Для модели, где основная масса весов сосредоточена в экспертах, такой подход означает либо слишком большой файл, либо просадку на чувствительных компонентах. Grawnch пошёл другим путём: разные компоненты получили разную точность.
Трёхуровневое квантование MoE-экспертов: что сжали, а что оставили
bpw, bits per weight, - среднее число бит на один параметр. 4,0 bpw соответствует примерно четырём битам на вес, 1,92 bpw - чуть меньше двух. Средний bpw по экспертам упал примерно вдвое, а общий размер модели - на 56%: остаток разницы объясняется тем, что часть тензоров не сжималась вообще.
Уровней точности три: 2,81 bpw, 2,56 bpw и 1,44 bpw. Сколько экспертов попало в каждый уровень и по какому критерию их распределяли, в приведённых данных не раскрыто. Это важно для тех, кто захочет повторить: раскладку придётся либо запрашивать у автора, либо подбирать самому.
Почему три уровня, а не один
Один уровень точности означает один компромисс для всех экспертов сразу. Три уровня позволяют держать в высокой точности тех, кто срабатывает чаще или сильнее влияет на выход, и агрессивно сжимать остальных. Заявленный результат, совпадение с базой на двух бенчмарках, говорит, что раскладка подобрана удачно. Воспроизвести её по описанию нельзя, и это часть той самой экспериментальности кванта, о которой автор говорит сам.
Что осталось в BF16/F32 и почему это важно
Shared-эксперты, которые работают на каждом токене без роутинга, слои внимания и эмбеддинги сохранены в нативной точности. Логика простая: сжимали самое объёмное, не трогали самое чувствительное к потере битов. Поэтому деградация вышла умеренной: разреженная часть модели получила удар, плотная осталась нетронутой.
Strata и dr-triton: как модель работает, когда не влезает в VRAM
775 ГБ не помещаются в 96 ГБ видеопамяти, поэтому веса разложены по трём уровням. Загрузчик Strata распределяет экспертов между ними и решает, что подтянуть заранее.
Три уровня памяти простыми словами
- Tier 1: горячая VRAM видеокарты. Самое быстрое место, объём ограничен 96/102 ГБ.
- Tier 2: pinned RAM, то есть page-locked системная память, которую ОС не выгружает в swap. Копирование из неё на GPU идёт напрямую, без промежуточного буфера, поэтому она быстрее обычной RAM.
- Tier 3: NVMe mmap. Файл с весами отображён в адресное пространство процесса, ядро подгружает страницы по требованию. Медленно, зато дёшево и объёмно.
Разница в скорости между уровнями измеряется порядками, поэтому задача планировщика - держать наверху то, что понадобится скоро, и не гонять лишний раз с диска. Похожая механика out-of-core подгрузки экспертов разбиралась в материале про Betelgeuse и prefill крупной MoE на 12 ГБ VRAM; там же показаны ограничения прямого сравнения со Strata.
Prefetch по роутеру: почему это ключ к скорости
Роутер решает, какие эксперты нужны, до выполнения слоя. Значит, список весов известен заранее, и их можно начать подтягивать, пока GPU считает предыдущий слой. Strata использует router lookahead prefetching; по заявлению автора, эффективность попаданий в его тестировании составила 97,9%. Простыми словами: почти в 98 случаях из 100 нужный эксперт уже лежал там, где его ждали, и обращение к NVMe не тормозило вычисления. Цифра получена в тестировании автора, независимой проверки нет.
dr-triton: деквантование без раздувания трафика
Второй компонент решает другую проблему. Если распаковать веса на CPU и передать на GPU в BF16, по PCIe поедет 16 бит на параметр вместо 1,92. Разница более чем в восемь раз, и на модели в сотни гигабайт это критично. Fused Triton-ядра из dr-triton держат веса упакованными в пути и распаковывают их только в GPU SRAM, уже на месте. Похожий приём с Triton-ядрами и memory-mapped весами на NVMe описан в разборе проекта с внешней таблицей на 6,4 млрд векторов.
Заявленные бенчмарки и throughput: что показывают цифры
Замеры сделаны на всех 93 слоях (Layer 0..92 плюс lm_head) на одной RTX PRO 6000 Blackwell с 96/102 ГБ VRAM и 176 ГБ RAM в Colab.
| Метрика | Базовая Kimi-K3.1-Pro | Kimi-K3.1-Pro-Coder, 775 ГБ |
|---|---|---|
| AIME 2025, Pass@1 (30 задач) | 29/30 (96,67%) | 29/30 (96,67%), совпадение по всем 30 задачам |
| LiveCodeBench (30 задач) | 29/30 (96,67%) | 29/30 (96,67%) |
| Top-1 token agreement | 100% | 95,20% |
| Top-5 token agreement | 100% | 99,92% |
| Средний KLD | 0 | 0,0191 |
| Perplexity, AIME 2025 Math | 2,2135 | 2,2358 (+1,01%) |
| Perplexity, LiveCodeBench Hard | 2,1136 | 2,1562 (+2,02%) |
| Perplexity, LiveCodeBench Overall | 2,6911 | 2,7629 (+2,67%) |
| Размер весов | 1,77 ТБ | 775 ГБ (-56%) |
| Режим | Заявленная скорость | Конфигурация |
|---|---|---|
| Batch / prefill | 36,8 tok/s | 1 x RTX PRO 6000 Blackwell, 176 ГБ RAM |
| Одиночный декод | 10,8 tok/s | 1 x RTX PRO 6000 Blackwell, 176 ГБ RAM |
Любые цифры скорости и эффективности в таких отчётах читаются только вместе с конфигурацией железа. Как отделять измеримые величины от лозунгов, разбирали в материале про «100% эффективности GPU».
Почему 29/30 - это не «модель не потеряла ничего»
Совпадение на двух наборах по 30 задач - сильный, но ограниченный сигнал. Тридцать задач дают шаг в 3,3 процентного пункта: одна ошибка заметно меняет итог. Прогон один, Pass@1, без повторов и без независимого воспроизведения. При этом квант не идентичен базе, и это видно по другим строкам таблицы: top-1 agreement 95,20% означает, что примерно каждый двадцатый токен расходится с базовой моделью, а рост перплексии на 1,01-2,67% фиксирует реальное расхождение в распределении вероятностей.
Практический вывод: на математике и коротких задачах по кодингу квант держится на уровне базы. Про длинный контекст, другие языки, агентные сценарии и работу с инструментами в источнике данных нет, и переносить туда результаты нельзя.
10,8 tok/s в одиночном декоде: много это или мало
10,8 tok/s - рабочий темп для чата и генерации кода, но без запаса: ответ на 500 токенов будет печататься около 46 секунд. 36,8 tok/s в batch-режиме комфортнее для пакетных задач: прогон набора тестов, обработка массива промптов, офлайн-генерация.
Учтите, что обе цифры получены в Colab на связке одной GPU и 176 ГБ RAM. На карте с меньшим Tier 1 и частыми обращениями к NVMe результат будет другим, и насколько другим, источник не сообщает. Для ориентира: разбор запуска DeepSeek V4.1 Flash 8K с квантованием Strata на RTX 5090 и 64 ГБ DDR5 описывает примерно 10 tok/s в похожем по идее сценарии офлоада.
Ограничения, о которых автор говорит прямо
- Кастомный упакованный layout. Маршрутизируемые эксперты лежат в нестандартном формате, поэтому шарды не загрузятся напрямую в vanilla llama.cpp или vLLM. Нужен либо Strata, либо собственный загрузчик с поддержкой этого формата.
- Уровни подбираются под железо. Разбиение VRAM / RAM / NVMe не универсально, его пересчитывают под конкретную конфигурацию.
- Статус кванта. Автор называет его экспериментальным и прямо пишет, что 775 ГБ - решение не для всех.
- Проверка. Результаты одного человека в Colab, третьей стороной не воспроизводились.
Обход есть, если у вас уже собран свой offloading-пайплайн или кастомный PyTorch/Triton-раннер: можно не использовать планировщик Strata, а импортировать standalone-модуль деквантования dr-triton / strata_coder и управлять размещением самостоятельно. Вариант для тех, кто готов писать код вокруг, а не запускать одну команду.
Кому подход реально применим
Энтузиастам с одной мощной картой и большим объёмом RAM. 96 ГБ VRAM плюс 176 ГБ RAM - конфигурация, на которой эксперимент и ставился. Интерес двойной: увидеть, что вообще выжимается из такого железа, и получить доступ к модели, которая иначе требует двух десятков ускорителей.
Владельцам карт на 24-32 ГБ. Схема допускает перекос: уменьшить Tier 1 и сильнее опереться на RAM и NVMe. Работать будет, но медленнее, и конкретных цифр для такого сценария в источнике нет. Зато 512 ГБ DDR5 меняют картину заметно: почти весь Tier 3 можно перенести в RAM и почти не обращаться к диску.
Командам с продакшн-нагрузкой. Скорее нет. Кастомный layout, отсутствие поддержки в llama.cpp и vLLM, экспериментальный статус кванта и полное отсутствие независимых замеров - набор рисков, который не окупается на фоне более компактных моделей на стандартных раннерах.
Как перенести идеи на более доступные модели
Идея, которую стоит забрать, формулируется в одну строку: сжимать в первую очередь самое объёмное и наименее чувствительное, оставляя внимание и эмбеддинги в высокой точности. Для меньших MoE-моделей это работает так же: эксперты занимают основную долю весов, а качество держится на shared-части, внимании и нормализации.
Второй переносимый принцип - prefetch по роутеру. Если модель не влезает в VRAM и вы используете офлоад, знание того, какие эксперты понадобятся на следующем слое, позволяет подгружать их заранее и убирать простой GPU.
Практика проще теории: для обычных моделей берите готовые инструменты. llama.cpp и vLLM дают свои схемы квантования и офлоада, поддерживают GGUF и не требуют собирать загрузчик. Пример такой сборки на 11 ГБ VRAM: сравнение MoE-моделей 35B, 120B и 176B на GTX 1080 Ti в llama-server. Strata и dr-triton остаются экспериментальными наработками без релизного цикла и документации, а цифр для других моделей в источнике нет, поэтому обещать их не станем.
Что в итоге: стоит ли следить за этим направлением
Эксперимент показывает рабочую связку: агрессивное квантование маршрутизируемых экспертов плюс послойный офлоад с предсказанием по роутеру позволяют держать модель на 2,8 трлн параметров на одной GPU и не потерять результаты на конкретных бенчмарках. Для proof of concept одного автора это сильный результат.
Что мешает назвать это готовым решением: нет независимой проверки, нет поддержки в популярных раннерах, конфигурацию уровней нужно подбирать под своё железо, а раскладка экспертов по уровням не описана. Повторять имеет смысл, если готовы разбираться с кастомным layout, отладкой загрузчика и тем, что часть заявленных цифр придётся перепроверять самому.
Следить за направлением стоит: квантование MoE и офлоад с предсказанием маршрутизации развиваются быстро, и приёмы из этого эксперимента рано или поздно доберутся до массовых раннеров в более удобном виде.