Что такое Betelgeuse и какие цифры он показывает
Betelgeuse (bel-cli / bel-server) запускает MoE-модель в квантовании IQ4_XS класса ~100GB+ с полными 4-битными экспертами на RTX 3060 12GB при 16GB системной RAM. Замеры автора: 14.0 tok/s на одной планке 16GB DDR4 и 24.0 tok/s на двух планках по 8GB DDR4. Суммарный объём памяти в обеих конфигурациях одинаковый, меняется только режим работы ОЗУ.
Для сравнения в тех же условиях: стоковый llama.cpp выдаёт ~0.5 tok/s на одной планке и ~0.6 tok/s на двух, Strata с ключом --low-ram держится на ~4-5 и ~5-6 tok/s. Разрыв со стоковым движком измеряется десятками раз.
Вывод Betelgeuse побайтово совпадает с выводом стокового llama.cpp: в таблице автора для IQ4_XS в обеих конфигурациях стоит 100% byte-exact. Все цифры ниже взяты из публикации автора проекта на r/LocalLLaMA от 31 октября 2026 года. Независимых замеров на момент публикации нет, поэтому числа стоит читать как отчёт разработчика, а не как лабораторный бенчмарк.
Короткий глоссарий, чтобы дальше не буксовать:
- MoE (mixture of experts): архитектура, где на каждом токене роутер выбирает несколько экспертных подсетей, а не весь набор весов.
- IQ4_XS: 4-битное квантование; здесь эксперты остаются полными 4-битными, без дополнительного сжатия.
- tok/s: скорость декодирования, число токенов в секунду; для русского текста это примерно 1-2 токена на слово.
- Victim cache: кэш для вытесненных данных; сюда попадают эксперты, освободившие слот в видеопамяти.
Почему большая MoE-модель вообще влезает в 12GB VRAM и 16GB RAM
MoE не требует держать в памяти все веса одновременно. На каждом токене активируется небольшая часть экспертов, поэтому Betelgeuse держит в VRAM пул слотов под активных экспертов, а остальной объём модели лежит на NVMe и подтягивается по мере надобности. Для модели класса ~100GB+ это единственный способ уложиться в 12GB видеопамяти.
Ключевой механизм называется Exclusive Host RAM Victim Cache. Когда эксперт вытесняется из видеопамяти, он не улетает сразу на диск, а оседает в кэше в оперативке. Оттуда его можно вернуть по PCIe заметно быстрее, чем с накопителя. Параметр MOE_DROP_MMAP при этом удаляет дублирующиеся GGUF-страницы из page cache ОС: VRAM и RAM не хранят копии одних и тех же весов, и память не тратится дважды.
Второй элемент - асинхронный аппаратный DMA (MOE_DMA=1) между пулом слотов VRAM и NVMe-накопителем. Пока GPU считает текущий слой, движок подтягивает следующие эксперты, и ожидание диска частично перекрывается вычислениями.
Магии здесь нет. Это агрессивное управление кэшем, и цена у него конкретная: нужен быстрый NVMe, а пропускная способность RAM становится узким местом. Похожий подход со стримингом весов с SSD разобран в материале про запуск Qwen3.8-Flash-Next 177B на RTX 5060 Ti 16 ГБ: там на каждый токен читается около 270 МиБ, и скорость упирается в накопитель.
Результаты тестов: IQ4_XS, IQ2_XS и Q8_K_XL на RTX 3060 12GB
Сводка из таблицы автора. Стенд один и тот же: RTX 3060 12GB, 16GB DDR4 суммарно, меняются только конфигурация планок и квантование.
| Квантование | Память | Стоковый llama.cpp | Strata (--low-ram) | Betelgeuse | Совпадение с llama.cpp |
|---|---|---|---|---|---|
| IQ4_XS | 1x 16GB, один канал | ~0.5 tok/s (thrash) | ~4-5 tok/s | 14.0 tok/s | 100% byte-exact |
| IQ4_XS | 2x 8GB, два канала | ~0.6 tok/s (thrash) | ~5-6 tok/s | 24.0 tok/s | 100% byte-exact |
| IQ2_XS (GSQ-RCO) | 1x 16GB, один канал | 1.47 tok/s | 8.11 tok/s | 22.03 tok/s, бёрсты до 48 | 100% byte-exact |
| Q8_K_XL | 1x 16GB, один канал | OOM или <0.1 tok/s | Does not fit | 8.0 cold / 12.0 warm tok/s | 100% byte-exact |
Три термина из таблицы, которые легко прочитать неправильно.
Thrash означает, что движок не столько считает, сколько непрерывно подкачивает веса: время уходит на чтение, а не на матмулы. Именно в этом состоянии стоковый llama.cpp проводит почти всё время на модели такого класса.
Cold и warm различаются состоянием кэша. 8.0 tok/s - первый прогон, когда рабочий набор экспертов ещё не осел в памяти; 12.0 tok/s - режим после прогрева, когда повторные обращения попадают в кэш. Разница почти в полтора раза, и в реальной работе вы получите скорее вторую цифру.
Бёрсты до 48 tok/s у IQ2_XS означают короткие пики на удачных участках генерации, а не устойчивую скорость. Ориентироваться стоит на базовые 22.03 tok/s. Таблицу целиком автор приводит в исходном посте.
Q8_K_XL - 8-битное квантование, весит примерно вдвое больше 4-битного. Здесь показательны два провала: стоковый llama.cpp уходит в OOM или деградирует ниже 0.1 tok/s, а Strata модель просто не вмещает. Betelgeuse остаётся работоспособным даже в таком варианте.
Почему двухканальная память удваивает скорость: разбор victim cache и DMA
Прирост с 14.0 до 24.0 tok/s при том же суммарном объёме 16GB объясняется пропускной способностью памяти, а не её ёмкостью.
Одна планка 16GB в одноканальном режиме упирается примерно в 17-19 GB/s. Этого хватает, чтобы CPU и движок PCIe H2D DMA начали конкурировать за единственный 64-битный канал: пока процессор читает веса, видеокарта не может забрать попадания в victim cache на полной скорости. Канал один, очередь общая.
Две планки по 8GB дают два канала и ~38 GB/s. Аппаратный DMA-движок GPU забирает попадания в victim cache по PCIe, не вставая в очередь к процессору, и IQ4_XS выходит на 24.0 tok/s. Это типичная конфигурация игрового ПК с 16GB, и для такого сценария она оказывается выгоднее, чем одна планка той же ёмкости.
Практический вывод: перед запуском проверьте режим работы памяти. Если в слотах стоит одна планка на 16GB, вторая такая же может дать больше, чем любой апгрейд видеокарты в этом классе задач. Оговорка: цифры получены на DDR4 у конкретного автора, на DDR5 абсолютные значения будут другими, хотя логика с числом каналов сохранится.
Что происходит, когда узкое место смещается с памяти на патчи и планировщик, показывает эксперимент с ускорением MoE-инференса в llama.cpp на RTX 4080: часть оптимизаций даёт прирост, часть приводит к регрессиям.
Byte-exact parity: почему ускорение не ломает качество вывода
«100% byte-exact» в таблице означает, что текст на выходе Betelgeuse побайтово совпадает с текстом стокового llama.cpp на тех же промптах, том же квантовании и тех же настройках сэмплирования. Движок меняет то, как веса попадают в VRAM, и не трогает арифметику и роутинг.
Этим подход отличается от схем, где скорость покупают урезанием модели: отбрасыванием «холодных» экспертов по весам роутера или переходом на более низкое квантование. Такие приёмы ускоряют работу, но меняют вывод, и заметить это можно далеко не сразу.
Границы утверждения стоит обозначить честно. Parity заявлен для IQ4_XS в обеих конфигурациях памяти, а также для IQ2_XS и Q8_K_XL по данным таблицы. Универсальной гарантией для любых моделей и настроек это не становится: методику замеров автор не раскрывает, число промптов и длина контекста в публикации не указаны. Проверять совпадение на своих задачах придётся самому.
Кому подойдёт Betelgeuse, а кому - нет
Пробовать имеет смысл, если у вас RTX 3060 12GB или карта схожего класса по объёму VRAM, 16GB DDR4 в двухканальном режиме и NVMe-накопитель. Второй сценарий - одна планка 16GB: прирост будет скромнее (14.0 tok/s), но всё равно кратно выше стокового llama.cpp.
Ограничения, о которых говорит сам характер цифр:
- Все измерения сделаны одним человеком на одном стенде, независимого воспроизведения нет.
- Проект в активной разработке, поведение между версиями может меняться.
- Скорость зависит от NVMe и пропускной способности RAM; на медленном SATA-диске картина будет другой.
- Выигрыш заявлен для MoE-моделей. У плотных моделей все веса участвуют в каждом токене, механизма кэширования экспертов там нет, и преимущество не заявлено.
- Один запрос за раз, как у большинства подобных решений; серверные сценарии с параллельными клиентами автор не описывал.
Альтернативный путь для крупной MoE-модели - нарастить RAM и держать экспертов в памяти целиком, без чтения с диска. Такой сценарий разобран в материале про 64 ГБ RAM для локальной LLM, где апгрейд с 32 до 64 ГБ DDR5 убрал стриминг с диска. Выбор между подходами упирается в бюджет и в готовность экспериментировать с новым движком.
Где взять Betelgeuse, модель и PR: ссылки и статус проекта
Автор указывает три источника: GitHub-репозиторий Betelgeuse Engine (bel-cli и bel-server), HuggingFace-бандл Alpha-Orionis-XS (3.2GB dense плюс эксперты) и upstream PR в llama.cpp. Точные адреса перечислены в оригинальной публикации, и брать их стоит оттуда: сторонние пересказы быстро устаревают, а репозиторий обновляется.
Статус проекта: активная разработка. Автор сообщает, что переносит ту же архитектуру стриминга и victim cache на DeepSeek V4.1 Flash, и ранние тесты в процессе разработки показывают около 25 tok/s на том же классе железа. Это не релизный бенчмарк и не обещание: цифра может измениться к моменту готового билда. Как DeepSeek V4.1 Flash ведёт себя на другом железе, разобрано в материале про 10 токенов в секунду на RTX 5090.
Чек-лист перед запуском:
- Проверьте режим памяти: две планки в правильных слотах дают два канала, одна планка - один.
- Убедитесь, что модель лежит на NVMe, а не на SATA-SSD или HDD.
- Заложите время на чтение логов: холодный старт медленный, и первая цифра скорости будет ниже установившейся.
- Сравните вывод с llama.cpp на своём промпте, если качество критично.
- Держите под рукой альтернативу: стоковый llama.cpp или Strata, если сборка не заведётся.
24 tok/s для модели класса ~100GB+ на карте с 12GB VRAM - рабочий режим для чата и генерации кода, если ваша конфигурация совпадает с той, на которой получены цифры. Начните с проверки каналов памяти: это самое дешёвое изменение в конфигурации, которое в опубликованных тестах дало прирост с 14.0 до 24.0 tok/s.