RustingStrata - движок инференса для GGUF-моделей Qwen, написанный на чистом Rust без ggml. CUDA-ядра компилируются при старте через NVRTC, те же ядра исполняются на Vulkan. Главная особенность - гибридный режим для MoE-моделей, которые не помещаются в VRAM: эксперты, не влезшие на видеокарту, считаются на CPU параллельно с работой GPU, а часто используемые эксперты движок переносит на GPU по ходу генерации.
Автор заявляет, что на его конфигурации (RTX 3060 12 ГБ, Ryzen 5 7600X, 32 ГБ RAM) движок обгоняет оригинальный Strata и llama.cpp по скорости decode: около 36 tok/s на Qwen3.8-Flash-Next против 19-22 у Strata и около 118 tok/s на Qwen3.6-35B-A3B против 68 у llama.cpp при сопоставимом prefill. Все цифры - собственные замеры разработчика, независимого тестирования нет. Исходная публикация с таблицами доступна в посте автора на r/LocalLLaMA.
RustingStrata сравнивают с тремя ориентирами: оригинальным движком Strata, из которого проект вырос, версией на CUDA и версией на Vulkan, плюс llama.cpp как общей точкой отсчёта для локального инференса. Дальше разбираем, что именно даёт прирост, где его нет и на каком железе всё это заводится.
Что такое RustingStrata и почему вокруг него шум
Пост появился 4 ноября 2026 года. Интерес к проекту держится на одном числе: 12 ГБ VRAM и MoE-модель, которая в эти 12 ГБ не влезает. llama.cpp в такой ситуации выгружает часть экспертов в RAM флагом -ncmoe, и decode проседает. RustingStrata предлагает другой режим работы с памятью и на замерах автора выдаёт двузначные tok/s там, где конкуренты показывают заметно меньше.
Чем RustingStrata отличается от llama.cpp и ggml
llama.cpp построен вокруг библиотеки ggml: она отвечает за тензорные операции, квантование и бэкенды. RustingStrata - отдельная реализация на чистом Rust без ggml: своя загрузка GGUF, свои вычислительные ядра. CUDA-ядра компилируются при старте через NVRTC, а не собираются заранее под конкретную архитектуру GPU. Тот же код ядер исполняется на Vulkan.
Автор говорит только о своей реализации и не утверждает, что это единственный Rust-движок для LLM на рынке. Практический смысл разделения простой: от ggml не наследуются ни его ограничения по оффлоаду, ни его набор квантований, зато вся работа с драйверами и тулчейнами ложится на новый код.
Кому адресован движок
Основной сценарий - карты с 8-16 ГБ VRAM и крупные MoE-модели Qwen, которые целиком туда не влезают. Список поддержки на момент публикации:
- Qwen3.5 и Qwen3.6: от 2B до 35B-A3B;
- Qwen3: 4B dense и 30B-A3B;
- Qwen3.8-27B dense;
- Qwen3-Next-80B-A3B;
- Qwen3.8-Flash-Next.
Квантования: от IQ1_S до Q8_0, плюс BF16 и F16. Помимо самого инференса в движке есть чат, OpenAI-совместимый сервер с поддержкой tool calling и команда calibrate, которая подстраивает параметры под конкретную машину. Для тех, кто поднимает локальный API для агентов или автоматизации, это сокращает число компонентов в стеке: сервер и клиент идут в одном бинарнике.
Архитектура движка: Rust, NVRTC и одни ядра на CUDA и Vulkan
Поведение движка определяют три решения: собственная реализация вычислений на Rust без ggml, компиляция CUDA-ядер через NVRTC при старте и общий код ядер для CUDA и Vulkan. Каждое влияет на скорость запуска и на список железа, где движок вообще работает.
Зачем компилировать ядра при старте
Ядра CUDA собираются в момент запуска движка, а не поставляются готовыми под конкретную архитектуру GPU. Плюс очевиден: не нужно искать сборку под свою карту. Минус тоже конкретный: первый старт дольше, нужен рабочий CUDA-тулчейн, а на Windows - установленные VS C++ Build Tools. Это типичный компромисс JIT-подхода, а не уникальная находка проекта, и он же объясняет часть сообщений о проблемах со сборкой.
Что даёт общая кодовая база ядер для Vulkan
Vulkan-бэкенд использует тот же код ядер, что и CUDA. Речь о переносимости кода, а не о равной производительности: на одной модели CUDA выдаёт около 36 tok/s decode, Vulkan - около 30. Vulkan требует поддержки shaderFloat64 и subgroup size 32, поэтому Intel Arc и более старые AMD-карты отпадают на уровне спецификации GPU. Проверять эти два параметра стоит до установки, иначе запуск закончится ошибкой компиляции шейдеров.
На AMD движок тестировали на RX 7900 XT и RX 9070 через Vulkan/RADV. Гибридный режим CPU+GPU работал на контексте 262k на обеих картах, а Qwen3.6-35B-A3B декодировала около 209 tok/s на 7900 XT, опережая llama.cpp на Vulkan и ROCm. Часть специфичных для AMD проблем при этом остаётся открытой, подробности ниже.
Гибридный MoE-инференс: как влезть в 12 ГБ VRAM
В MoE-модели на каждом токене роутер выбирает несколько экспертов из десятков доступных. Именно поэтому такие модели и живут на слабом железе: активных параметров мало, а общий вес большой. Проблема в том, что при генерации набор активных экспертов меняется от токена к токену.
Гибридный режим RustingStrata работает так: эксперты, не поместившиеся в VRAM, считаются на CPU одновременно с работой GPU, а часто используемые эксперты движок постепенно переносит на видеокарту. Отличие от статичного оффлоада в двух вещах - параллельность CPU и GPU и адаптация к реальному паттерну использования экспертов на конкретном промпте.
Пример из замеров: Qwen3.6-35B-A3B в квантовании Q2_K_XL весит 11,7 ГиБ и на 12-гиговую карту целиком не влезает. Движок всё равно выдаёт около 118 tok/s decode на коротком промпте. Это эвристика, а не математически оптимальное распределение, и её поведение зависит от модели, кванта и длины контекста. Другой подход к той же задаче - стриминг весов с SSD, когда эксперты подгружаются с диска; он разобран в материале о запуске Qwen3.8-Flash-Next 177B на RTX 5060 Ti 16 ГБ.
Почему decode ускоряется, а prefill нет
Decode - пошаговая генерация: на каждом шаге активна лишь часть экспертов, и перенос горячих экспертов на GPU плюс параллельная работа CPU дают эффект. Prefill обрабатывает весь промпт сразу и упирается в пропускную способность памяти и вычислителей, а не в выбор экспертов.
Отсюда паритет на prefill: 2216 tok/s у RustingStrata против примерно 2236 у llama.cpp на промпте 4K. Автор прямо не заявляет преимущества по prefill, и это честная позиция. На первом промпте с холодным page cache prefill вообще ограничен чтением с диска, и в более ранних прогонах оригинальный Strata был там быстрее.
Роль MTP-драфтов в ускорении decode
На контексте 32K Qwen3.6-35B-A3B даёт 1800 tok/s prefill и 92 tok/s decode. С включёнными MTP-драфтами decode поднимается до 160 tok/s на простом промпте, а на обычном тексте прирост скромнее, около 16%. Цифру 160 tok/s стоит читать как верхнюю границу на лёгком промпте, а не как типичный результат: на связном тексте ориентир - плюс 16% к базовым 92. Как вообще соотносятся prefill и decode и почему по одному числу нельзя сравнивать движки, разобрано в статье про замеры Qwen 3.8 27B на RTX 5090.
Заявленные цифры: decode, prefill и сравнение с llama.cpp
Сводка замеров автора. Конфигурация одна: RTX 3060 12 ГБ, Ryzen 5 7600X, 32 ГБ RAM. Независимого тестирования нет, настройки llama.cpp подбирал сам автор.
| Модель и квант | RustingStrata | Точка сравнения |
|---|---|---|
| Qwen3.8-Flash-Next, IQ2_XS, промпт 943 токена | Около 36 tok/s decode на CUDA, около 30 на Vulkan; prefill в среднем около 370 tok/s (до 610) на CUDA и около 375 (до 490) на Vulkan | Оригинальный Strata: 19-22 tok/s decode, 140-146 tok/s prefill при тёплом кэше |
| Qwen3.6-35B-A3B, Q2_K_XL, 11,7 ГиБ | Около 118 tok/s decode на коротком промпте, 113 после промпта 4K; 2216 tok/s prefill на 4K | llama.cpp (-ncmoe 12 -ub 2048, flash attention): 68 и 66 tok/s decode, около 2236 tok/s prefill |
| Qwen3-Next-80B-A3B, IQ1_S | Около 92 tok/s decode, большая часть экспертов на CPU | llama.cpp с лучшим вариантом -ncmoe: около 44 tok/s |
Qwen3.8-Flash-Next: CUDA против Vulkan и Strata
По decode CUDA опережает Vulkan: около 36 против около 30 tok/s. По prefill бэкенды почти равны, 370 против 375 tok/s в среднем, различаются лишь пики (610 против 490). Оба варианта заметно быстрее оригинального Strata и по decode, и по prefill.
Модель здесь непростая: четыре потока hyper-connection вместо одного residual, per-layer embeddings, слои DeltaNet вперемешку с attention и крупный MoE, который в 12 ГБ не помещается. Разбор другого движка под эту же модель, Strata от KnownAd4832, есть в материале про 65 ток/с на Qwen3.8-Flash-Next: полезно сравнить, как разные команды решают одну задачу и на каком железе.
Qwen3.6-35B-A3B и Qwen3-Next-80B: где гибридный режим раскрывается
35B-A3B - модельный случай, ради которого режим и делался: 11,7 ГиБ не влезают в 12 ГБ вместе с KV-кэшем и буферами. Здесь разрыв с llama.cpp самый большой: 118 против 68 tok/s на коротком промпте и 113 против 66 после промпта 4K. Отдельно про эту модель и её поддержку в Strata есть разбор сценариев Qwen 3.6 35B.
80B IQ1_S - экстремальный случай: большая часть экспертов остаётся на CPU, но движок всё равно выдаёт около 92 tok/s против примерно 44 у llama.cpp. IQ1_S - сильное квантование с ожидаемой потерей качества, и скорость здесь не единственный критерий: для сложных задач разница в ответах может оказаться важнее tok/s.
Про совпадение вывода: жадный вывод RustingStrata совпадает с argmax оригинального Strata на каждой проверенной позиции, включая близкие значения. С жадным выводом llama.cpp совпадение 98-99% токенов, при этом сам llama.cpp согласуется с собой лишь на 98,3% между batch- и пошаговым режимами. То есть редкие расхождения приходятся на позиции, где разница между кандидатами минимальна.
Требования к железу и настройка: что нужно, чтобы запустить
Проверять совместимость стоит до скачивания моделей, потому что часть требований отсекает железо на уровне спецификации.
NVIDIA и CUDA: что проверить перед запуском
Нужен рабочий CUDA-тулчейн: ядра компилируются через NVRTC при старте. На Windows дополнительно требуются VS C++ Build Tools. Первый запуск займёт больше времени, чем последующие, и это нормально. Тестовая карта автора - RTX 3060 12 ГБ; на картах с меньшим объёмом VRAM поведение гибридного режима будет другим, а часть моделей из списка может стать нерабочей на практике. Команда calibrate подстраивает параметры под конкретную машину, и её имеет смысл прогнать до сравнения скоростей.
AMD и Vulkan: статус «работает, но дорабатывается»
Vulkan-путь реален: тесты на RX 7900 XT и RX 9070 через RADV, гибридный режим на контексте 262k, около 209 tok/s decode на 7900 XT для Qwen3.6-35B-A3B. Часть AMD-специфичных проблем при этом ещё открыта, поэтому рассчитывать на стабильность как на CUDA не стоит. Минимальное условие - поддержка shaderFloat64 и subgroup size 32; Intel Arc и более старые AMD-карты в список не попадают. Детали замеров и оговорки автор приводит в исходном посте.
Ограничения и риски: что важно знать до того, как пробовать
Почему цифры нельзя считать независимым бенчмарком
Одна конфигурация, один автор, конкретные версии моделей и квантований. Нет данных о разбросе между запусками, температурах и фоновой нагрузке. Сравнение с llama.cpp сделано на настройках, которые автор подбирал сам (-ncmoe 12, -ub 2048, flash attention), и он это прямо указывает. При других настройках разрыв может измениться, особенно на границе, где модель почти влезает в VRAM. Воспринимать эти числа как отраслевой стандарт нельзя.
Ограничения по моделям и квантованиям
Поддержка ограничена семейством Qwen: Qwen3.5 и 3.6 от 2B до 35B-A3B, Qwen3 4B dense и 30B-A3B, Qwen3.8-27B dense, Qwen3-Next-80B-A3B, Qwen3.8-Flash-Next. Квантования от IQ1_S до Q8_0, плюс BF16 и F16. Если вы работаете на Llama, Mistral, Gemma или собственных файнтюнах не из семейства Qwen, движок не подойдёт: другие архитектуры не заявлены.
Прочие ограничения, которые стоит держать в голове: требовательный Vulkan-бэкенд, необходимость VS C++ Build Tools на Windows, открытые AMD-проблемы и единственная протестированная конфигурация. Совпадение вывода с llama.cpp на 98-99% токенов - хороший знак, но не гарантия идентичного качества на всех промптах.
Стоит ли переходить: практический вывод
Кому движок даст реальный выигрыш
Владельцам 8-16 ГБ VRAM, которые запускают MoE-модели Qwen (35B-A3B, 80B-A3B) и упираются в низкий decode в llama.cpp. По замерам автора прирост на этих моделях составляет примерно 1,7-2 раза по decode. Второй сценарий: нужен локальный OpenAI-совместимый сервер с tool calling и чат в одном движке, без сборки дополнительных обвязок.
Кому пока рано переходить
Пользователям AMD: часть проблем ещё открыта, статус проекта для этих карт - «работает, но дорабатывается». Тем, кто работает с не-Qwen моделями. Тем, кому критична воспроизводимость и независимые бенчмарки: здесь их пока нет. И тем, у кого llama.cpp уже отлажен и острой боли по скорости нет: выигрыш в tok/s придётся сопоставлять со временем на настройку нового движка.
Разумный шаг - прогнать на своём железе одну и ту же MoE-модель Qwen в RustingStrata и в llama.cpp на одинаковых промптах и квантах, с включённым calibrate и одинаковой длиной контекста. Замеры автора на RTX 3060 показывают направление, но решение стоит принимать по своим числам.