TurboQuant TQ3_1S: как 3.5 бита спасают 16-гигабайтные видеокарты от Qwen3.5

3.5 бита? Серьезно?

Когда в чате мелькнуло сообщение про «3.5-битный формат», я подумал, что кто-то перепутал новости про ИИ с шуткой про дробные биты. Но нет. TQ3_1S — реальный форк llama.cpp, который втискивает веса модели в 3.5 бита вместо привычных 4 (Q4_0) или даже 8. Зачем? Чтобы Qwen3.5-27B наконец-то влез в 16 ГБ видеопамяти без отвратительной деградации.

Что за магия внутри TQ3_1S?

Основа — метод квантования с поворотом Уолша-Адамара (Walsh-Hadamard rotation). Если отбросить математику, это хитрая перестановка значений перед тем, как их сжать. Вместо того чтобы квантовать веса напрямую, их сначала «перемешивают» этой матрицей. Результат? Распределение становится более «удобным» для сжатия.

Формат использует 8 центроидов (предзаданных значений) на блок. Вот откуда 3.5 бита: log2(8) = 3 бита, плюс один знаковый бит на блок — итого 3.5 бита на вес в среднем. Технически это Q3_KS (K-Quant с scale), но с поворотом. Разработчики утверждают, что потеря точности минимальна, а экономия памяти — 12.5% против Q4_0.

Q4_0 против TQ3_1S: цифры не врут

Бенчмарки на 01.04.2026 для модели Qwen2.5-7B (для чистоты эксперимента) показывают любопытную картину.

Потери в perplexity (PPL) около 4%. На практике для чата или RAG это почти незаметно. Скорость просела на 10% — плата за дополнительные вычисления поворота. Но главный выигрыш — память. Для Qwen3.5-27B разница в 3-4 ГБ становится решающей.

1 Достаем форк с поддержкой TQ3_1S

Официальный llama.cpp пока не принял эти изменения (на 01.04.2026). Нужен специальный форк. Клонируем его и собираем с CUDA.

git clone https://github.com/user/llama.cpp-turboquant-tq3_1s.git
cd llama.cpp-turboquant-tq3_1s
make clean && LLAMA_CUDA=1 make -j

Если сборка прошла успешно, в папке `bin` появится `quantize` с поддержкой нового формата.

2 Квантуем модель в TQ3_1S

Допустим, у вас есть оригинальная модель Qwen3.5-27B в формате FP16. Конвертируем ее в GGUF, а затем квантуем.

# Конвертация в GGUF (используем python скрипт из форка)
python convert.py ./qwen3.5-27b --outtype f16 --outfile qwen3.5-27b-f16.gguf

# Квантование в TQ3_1S
./bin/quantize qwen3.5-27b-f16.gguf qwen3.5-27b-tq3_1s.gguf q3_ks-wa

Ключевой параметр — `q3_ks-wa`. `wa` — это и есть Walsh-Hadamard rotation. Без него будет обычный Q3_KS, который работает хуже.

3 Запуск и первые впечатления

Запускаем модель через `main` или `server`:

./bin/main -m qwen3.5-27b-tq3_1s.gguf -n 256 --gpu-layers 99 -p "Translate this to French: Hello, how are you?"

С `--gpu-layers 99` все слои уедут на GPU. Потребление видеопамяти: около 15.2 ГБ для 27B модели. Для сравнения, Q4_0 съедал бы ~17 ГБ. Разница в 1.8 ГБ — как раз то, что нужно для комфортной работы без свапа.

Кому зайти на TQ3_1S, а кому — обойти стороной

Этот формат — для тех, кто упирается в потолок видеопамяти. У вас 16 ГБ карта, а хочется 27B-модель? TQ3_1S ваш выбор. Если же у вас 24 ГБ или больше, возможно, лучше использовать более качественные форматы вроде AWQ или GPTQ.

Не стоит использовать TQ3_1S, если:

• Вы гонитесь за максимальной скоростью — 10% просадка может быть чувствительна.
• Ваша задача требует предельной точности (например, генерация кода или сложные рассуждения).
• Вы используете очень старую GPU без хорошей поддержки CUDA ядер для нужных операций.

А что там с 1-битным квантованием? Это же еще круче?

Спросите любого, кто пробовал — и он скривится. На 01.04.2026 1-битные методы все еще остаются экспериментом для очень специфичных задач. Как мы писали в тестах, качество падает катастрофически. TQ3_1S — разумный компромисс между агрессивным сжатием и адекватностью модели.

Итог? Если вы задыхаетесь от нехватки памяти — TQ3_1S ваш спасательный круг. Собирайте форк, квантуйте модель и наслаждайтесь тем, что 27B-параметры наконец-то работают там, где раньше не могли. И не обращайте внимание на скептиков, говорящих о дробных битах — они просто не пробовали.

Подписаться на канал