ainews
Квантизация Qwen3.6-27B до 3.33 BPW без потери качества: проверено на реальной модели, а не на бумаге
Разработчик сжал файнтюн Qwen3.6-27B до 10.4 ГБ (3.33 бита на вес) методом покомпонентной квантизации с KLD-контролем. Главное: на этот раз проверил не отдельные слои, а собранную модель целиком — и нашёл реальную деградацию, которую пришлось чинить вручную. Модуль внимания сжимается почти даром, основная цена качества — в FFN.
Это прямой путь снизить расходы на inference в 2-3 раза без видимой потери качества, если ваши задачи попадают в зону устойчивости модели (code, общие задачи). Главное — валидировать под свою нагрузку, потому что универсальных гарантий тут нет.
Что произошло
Indie-разработчик enginetown опубликовал результаты квантизации файнтюна Qwen3.6-27B (модель Fable-Fusion-711 от DavidAU) с полным циклом проверки — не на отдельных слоях, а на собранной модели.
Три билда: - Bedrock Final: 12.19 ГБ (3.90 BPW), KLD по категориям 0.02–0.04 - Tightrope: 12.13 ГБ (3.88 BPW), чуть хуже на general/toolcalling - Gambit: 10.43 ГБ (3.33 BPW), заметная деградация на general (0.046), но не критичная
Все три варианта не переваливают за KLD 0.1 (красная зона). Gambit проверен на трёх coding-задачах вручную, остальные — только метрики.
Главные находки: 1. Файнтюн переносит сжатие гораздо лучше базовой модели — те же слои (attn_q, attn_k/v, ssm_beta/alpha) дошли до минимума без поломок, где базовая модель ломалась раньше. 2. FFN — узкое горло качества. Слой внимания (attention) можно жать агрессивно почти бесплатно, основная цена — в точности весов feed-forward сетей. 3. Toolcalling в этой модели живучее general-задач (в базовой Qwen было наоборот). 4. Первая версия Gambit провалилась — пришлось откатывать конкретные тензоры и пересобирать модель заново, потому что изолированные тесты слоёв не предсказали реальную деградацию при сборке.
Автор честно говорит: math и toolcalling стресс-тестов не было, ARC-C не проверялся, Bedrock/Tightrope вручную не гонялись. Это не недоделки — просто граница его работы. Дальше — ваша зона ответственности.
Автор: Артём Ковалёв · Источник: reddit.com
Разработчикам. Готовые 3 квантизованные билда на HuggingFace, воспроизводимый метод покомпонентной квантизации с KLD-контролем, реальные примеры, где изолированные тесты врут. Можно взять Gambit под inference на 12GB VRAM или адаптировать метод под свои файнтюны.
Бизнесу. Затраты на inference можно резать в 2.5 раза без видимой потери качества (10GB vs 27GB) — критично для SaaS с AI-бэкендом. Но нужна валидация под конкретные задачи: toolcalling и math деградируют первыми.
Инвесторам. Открытое направление: квантизация файнтюнов переносится не так, как базовых моделей — можно строить специализированные inference-провайдеры под конкретные ниши с радикально более низкой себестоимостью. Рынок пока не насыщен.
- Inference-as-a-Service под coding-задачи на Gambit (10GB) вместо полноразмерных моделей — в 2.5 раза дешевле по GPU
- SaaS-обёртки для квантизации файнтюнов под заказчика с автоматической валидацией по KLD
- Специализированные хостинг-провайдеры для сжатых файнтюнов под toolcalling/code (где деградация минимальна)
- Tooling для покомпонентного KLD-профилирования моделей перед квантизацией — сейчас это ручная работа
- Маркетплейс готовых квантизованных файнтюнов с transparency-отчётами (какие задачи живут, какие деградируют)
- Math и toolcalling деградируют первыми, но стресс-тестов не было — риск скрытых поломок в продакшене
- Два из трёх билдов автор вручную не гонял — качество подтверждено только метриками, реальное поведение неизвестно
- Метод не масштабируется автоматически: каждый файнтюн требует ручной настройки и нескольких итераций пересборки
- KLD <0.1 — это не гарантия качества на специфичных задачах, только общая оценка риска
Это один из немногих постов на Reddit, где разработчик не продаёт хайп, а показывает реальную работу — с провалами, откатами и честными оговорками. Он сжал модель до 10GB, но сам говорит: я не проверял math и toolcalling вручную, два билда вообще не трогал руками, дальше ваша зона риска. Это редкая прозрачность.
Практический вывод простой: если вы крутите inference на своём железе и упираетесь в VRAM — вот готовый путь резать расходы в 2.5 раза. Но валидировать придётся самим, под свои задачи. Универсальной пилюли тут нет, и автор это не скрывает. Для production AI-продуктов это скорее research-направление, чем готовое решение. Для энтузиастов и inference-стартапов — прямая экономия денег.
Комментарии