Bitsandbytes долгое время был стандартом для квантизации и LoRA-тренировки, но архитектурный прогресс обошёл его стороной. Репозиторий transformers5-qwen3.5-recipe показал: GGUF с APEX-квантованием и fused-ядрами запускает дообучение MoE-модели Qwen3.6-35B-A3B в 16 GiB VRAM без CPU offloading. Скорость на Strix Halo - 6.5 s/it при batch size 1, context chunk 2048 и LoRA rank 4. Это прямой ответ на запрос ML-инженеров, которые хотят тренировать большие модели на локальном железе, не теряя поддержку новых архитектур.
Ключевое отличие - fused dequant-matmul и специализированные MoE kernels. Они объединяют деквантизацию и матричное умножение в одном проходе GPU, исключая накладные расходы на промежуточные тензоры. Для MoE-архитектур с разреженной активацией экспертов это даёт кратный выигрыш по памяти и скорости. Bitsandbytes с его универсальными 4- и 8-битными оптимизаторами такого не предлагает.
Проблема: bitsandbytes не справляется с новыми архитектурами
Bitsandbytes проектировался для dense-моделей с классическим attention. Когда индустрия пошла в сторону Mixture of Experts, linear attention и DeepSeek WTF attention, библиотека осталась на месте. Попытка применить 4-битный QLoRA к Qwen3.6-35B-A3B через bitsandbytes упирается в две стены: отсутствие нативных MoE-оптимизаций и неспособность эффективно работать с нестандартными attention-паттернами.
Результат - модель с 35B параметров требует либо несколько GPU с большим объёмом VRAM, либо CPU offloading. Последний сценарий убивает скорость: переброска градиентов и состояний оптимизатора между RAM и VRAM добавляет 3-5x оверхед к времени итерации. Для сравнения: Qwen3.6-35B-A3B в стандартном QLoRA через bitsandbytes не помещается в 16 GiB VRAM даже с offloading - не хватает памяти под активации и KV-кэш при длине контекста 2048 токенов.
Проблема усугубляется с каждой новой архитектурой. DeepSeek WTF attention, использующий разреженные паттерны, не имеет соответствующих оптимизаций в bitsandbytes. Linear attention, снижающий сложность с O(n²) до O(n), тоже остаётся без аппаратно-дружественных квантизованных реализаций. Инженеры, работающие с передовыми моделями, вынуждены искать альтернативы.
Решение: GGUF и APEX-квантование - тренировка Qwen3.6-35B-A3B в 16 GiB VRAM
Репозиторий transformers5-qwen3.5-recipe демонстрирует работающий пайплайн. Стек: GGUF как формат хранения весов, APEX-квантование для сжатия и fused-ядра для исполнения. Модель Qwen3.6-35B-A3B с 35B параметров (из которых активны 3B на токен) тренируется на одной GPU с 16 GiB VRAM. Никакого offloading на CPU - все вычисления на чипе.
Параметры тренировки: batch size 1, context chunk length 2048, LoRA rank 4. Это минимальная конфигурация для содержательного дообучения. Увеличение rank до 8 или 16 пропорционально увеличит потребление памяти, но 4 - рабочий компромисс между качеством адаптации и VRAM-бюджетом. GGUF хранит веса в квантизованном виде (APEX), а fused-ядра деквантизуют их «на лету» непосредственно перед умножением.
Fused dequant-matmul и MoE kernels: как это работает
Стандартный подход: загрузить квантизованную матрицу, деквантизовать в FP16, выполнить матричное умножение, выгрузить результат. Три отдельные операции, каждая со своим чтением/записью в память. Fused dequant-matmul делает всё в одном GPU-ядре: читает сжатые веса, восстанавливает их во внутренних регистрах и сразу перемножает с активациями. Промежуточный FP16-тензор не материализуется в VRAM - экономия до 50% пикового потребления памяти на линейных слоях.
Для MoE-архитектур fused-ядра идут дальше. Qwen3.6-35B-A3B содержит 128 экспертов, из которых на каждый токен активируются 8. Стандартный код загружает всех экспертов в память и маскирует неактивных. Fused MoE kernel загружает только активных экспертов для текущего батча, выполняет деквантизацию и умножение, агрегирует результаты через разреженный reduce. Память под неактивных экспертов не резервируется. На 35B-модели это разница между 24+ GiB и 16 GiB VRAM.
APEX-квантование добавляет гибкость: веса экспертов можно квантизовать с разной битностью в зависимости от их важности. Часто используемые эксперты - 4 бита, редкие - 2 бита. Это сохраняет качество при дальнейшем снижении VRAM-потребления. Bitsandbytes такой гранулярности не даёт - все слои квантизуются единообразно.
Сравнение GGUF и bitsandbytes: почему GGUF становится стандартом
Разрыв между двумя подходами нарастает с каждым кварталом. Bitsandbytes стабилен, но статичен. GGUF развивается вместе с архитектурами моделей. Сравним по трём ключевым осям.
| Критерий | GGUF | Bitsandbytes |
|---|---|---|
| Поддержка MoE | Нативные fused MoE kernels, загрузка только активных экспертов | Универсальные dense-оптимизаторы, все эксперты в памяти |
| Linear attention | Поддержка через кастомные compute-ядра | Отсутствует |
| DeepSeek WTF attention | Экспериментальная поддержка, активная разработка | Отсутствует |
| Диапазон квантизации | 1-bit, 2-bit, 3-bit, 4-bit, 5-bit, 6-bit, 8-bit | 4-bit и 8-bit |
| Гранулярность квантизации | Поэкспертная, послойная, поканальная | Послойная |
| VRAM для Qwen3.6-35B-A3B (LoRA rank 4) | 16 GiB | Не помещается / требует offloading |
Поддержка новых архитектур: MoE, linear attention и DeepSeek WTF
MoE - главный драйвер перехода на GGUF. Модели класса Qwen 3.6, DeepSeek-V4, Gemma-4-MoE требуют эффективной работы с экспертами. GGUF даёт fused MoE kernels, которые загружают только активных экспертов и выполняют деквантизацию внутри compute-ядра. Bitsandbytes применяет стандартный QLoRA-пайплайн, где все эксперты квантизуются и хранятся в VRAM - для 128 экспертов по ~300M параметров каждый это мгновенно упирается в потолок памяти.
Linear attention - архитектурный тренд 2026 года, снижающий сложность инференса с квадратичной до линейной. GGUF уже имеет экспериментальные ядра под этот тип внимания, что позволяет тренировать модели с контекстом 128K+ токенов без экспоненциального роста VRAM. Bitsandbytes не предлагает специализированных оптимизаций - linear attention исполняется через универсальные dense-ядра, теряя все преимущества архитектуры.
DeepSeek WTF attention использует разреженные паттерны внимания, динамически определяемые на лету. Это требует гибкой системы выделения памяти и нестандартных матричных операций. GGUF с его модульной системой бэкендов адаптируется под такие паттерны. Bitsandbytes жёстко привязан к классическому dense attention и не может эффективно обслуживать разреженные структуры.
Типы квантизации: от 4-bit до 1-bit
Bitsandbytes предлагает два варианта: NF4 (4-bit NormalFloat) и FP8. Первый - для QLoRA-тренировки, второй - для инференса. Этого достаточно для dense-моделей поколения 2023-2024 годов. GGUF расширяет диапазон до 1-битных представлений. Зачем нужен 1-bit? Для MoE-моделей с сотнями экспертов 1-битная квантизация редко используемых экспертов снижает общий объём модели в 3-4 раза при минимальной потере качества - активные эксперты остаются в 4-bit.
Практический пример: Bonsai-27B использует троичную квантизацию (-1, 0, +1) для сжатия модели до 8.39 ГБ при 2.5 битах на параметр, сохраняя 92.2% точности полной версии. GGUF поддерживает такие сценарии нативно. Bitsandbytes с его бинарным выбором «4 или 8 бит» не даёт пространства для манёвра.
Производительность на практике: тесты на Strix Halo
Strix Halo - платформа AMD с унифицированной памятью до 128 ГБ и стеком ROCM. На ней референсная тренировка Qwen3.6-35B-A3B через GGUF + APEX показывает 6.5 секунд на итерацию. Параметры: batch size 1, context chunk length 2048 токенов, LoRA rank 4. Это означает, что одна эпоха на датасете из 10,000 примеров займёт около 18 часов непрерывной тренировки.
Для сравнения: аналогичная конфигурация на bitsandbytes с CPU offloading дала бы 25-35 s/it на том же железе - в 4-5 раз медленнее. Причина: offloading гоняет градиенты через PCIe-шину на каждом шаге оптимизатора, а универсальные dense-ядра не используют разреженность MoE. Fused-ядра GGUF держат все данные на GPU и обрабатывают только активных экспертов.
6.5 s/it - не предел. При увеличении batch size до 4 скорость выходит на плато ~5.8 s/it за счёт лучшей утилизации compute-юнитов. Контекст 2048 токенов выбран как компромисс: большинство инструкционных датасетов укладывается в это окно, а VRAM-потребление KV-кэша остаётся управляемым. Для задач с длинным контекстом (суммаризация, multi-turn диалоги) можно увеличить chunk length до 4096, но это добавит 2-3 GiB к VRAM-бюджету.
Расширение экосистемы: torch-ggml-ops и портирование на другие GPU
Одно из ограничений GGUF - историческая привязка к llama.cpp и CPU-инференсу. Публикация torch-ggml-ops меняет ситуацию. Это PyTorch-биндинги для fused-ядер, которые позволяют вызывать dequant-matmul и MoE kernels напрямую из Python-кода без прослойки C++.
Практическое следствие: портирование на GPU AMD (ROCM) и Intel (XPU) сводится к перекомпиляции ядер под целевой бэкенд. PyTorch-обвязка остаётся неизменной. Инженер, работающий на Intel Arc или AMD Radeon, может использовать тот же тренировочный скрипт, что и владелец NVIDIA RTX - достаточно указать флаг --backend rocm или --backend xpu.
Это критически важно для индустрии, где доминирование NVIDIA в AI-тренировках постепенно размывается. AMD Strix Halo с 128 ГБ унифицированной памяти и Intel Falcon Shores с XPU-стеком становятся реальными альтернативами для локальной тренировки больших моделей. GGUF с torch-ggml-ops даёт им единый интерфейс.
Ограничения и когда GGUF может не подойти
GGUF не серебряная пуля. Производительность fused-ядер зависит от конкретной конфигурации GPU: на старых архитектурах без поддержки быстрых atomic-операций выигрыш от fused MoE kernel может быть скромнее. Тесты на Strix Halo репрезентативны для RDNA 3.5, но на RDNA 2 или NVIDIA Turing цифры будут другими.
Поддержка DeepSeek WTF attention и некоторых вариантов linear attention остаётся экспериментальной. В продакшен-пайплайнах, где критична стабильность, стоит проверять воспроизводимость результатов на целевой архитектуре. Bitsandbytes для старых dense-моделей (Llama 3, Mistral, Qwen 2.5) остаётся достаточным и более предсказуемым решением - его кодовая база обкатана на тысячах проектов.
Ещё один нюанс: GGUF требует конвертации весов модели в свой формат. Для кастомных архитектур это может потребовать написания конвертера. Bitsandbytes работает с нативными PyTorch-весами «из коробки» - для быстрого прототипирования на знакомой архитектуре это быстрее.
Выводы: стоит ли переходить на GGUF для LoRA-тренировки
Если вы тренируете MoE-модели или работаете с новыми архитектурами внимания - переходите. GGUF с APEX-квантованием и fused-ядрами позволяет запустить Qwen3.6-35B-A3B в 16 GiB VRAM без offloading, что невозможно в bitsandbytes. Скорость 6.5 s/it на Strix Halo - достаточная для полного цикла дообучения за одну ночь.
Если ваш парк - dense-модели поколения 2023-2024 на NVIDIA GPU - bitsandbytes остаётся рабочим вариантом. Но архитектурный тренд неумолим: MoE, linear attention и сверхдлинные контексты становятся стандартом. GGUF уже сейчас поддерживает их на уровне ядер, а bitsandbytes - нет.
Практический следующий шаг: склонировать transformers5-qwen3.5-recipe, запустить референсную тренировку на своём железе и замерить реальную скорость. Репозиторий содержит готовые конфигурации и скрипты. Результаты на вашей GPU могут отличаться от Strix Halo, но порядок цифр будет сопоставим. Дополнительно рекомендуем изучить наше сравнение GGUF и DS4 Flash на ROCM для оценки альтернативных форматов квантизации и разбор Gemma-4-26B против Qwen3.6-MoE для выбора оптимальной MoE-архитектуры под локальное развёртывание.