Технічний контекст
Я почав розбиратися в анонсі Google не заради красивої фрази про ефективність, а тому що такі речі безпосередньо впливають на AI automation в продакшені. Якщо модель можна стиснути без помітної втрати якості, то раптом стають реальними сценарії, де раніше все впиралося у VRAM, затримку та вартість заліза.
Суть новини проста: Google виклала офіційні QAT-чекпоінти для Gemma 4. QAT (Quantization-Aware Training) відрізняється від звичайного пост-квантування тим, що модель під час навчання вже "знає" про майбутні втрати точності та підлаштовується під них заздалегідь.
І це надзвичайно важливий момент. Після звичайного PTQ я часто бачу знайому картину: модель формально полегшала, але на складних відповідях починає втрачати логіку. З QAT шанс зберегти якість помітно вищий, оскільки цей компроміс закладається ще на етапі тренування, а не додається в останній момент.
Google випустила щонайменше два варіанти: Q4_0-чекпоінти та мобільний формат. Для vLLM це виглядає цілком практично: квантування підхоплюється безпосередньо з чекпоінта, без додаткової магії в конфігурації.
За цифрами найцікавіше наступне: Gemma 4 31B в QAT W4A16 може стиснутися приблизно з 59 ГБ до 19.8 ГБ. Це близько 66% економії пам'яті, і з такими показниками я вже перестаю сприймати новину як "черговий реліз для розробників".
Мобільний варіант також створено не для галочки. Google окремо наголошує на статичних активаціях та точковому 2-бітному квантуванні decode-шарів, а для Gemma 4 E2B заявлено memory footprint близько 1 ГБ. Для edge це вже не просто теорія, а нормальна інженерна опція.
Вплив на бізнес та автоматизацію
Виграють ті, хто хоче перенести inference ближче до користувача: mobile, локальні асистенти, on-device copilots та сценарії, що вимагають високої конфіденційності. Програють, як завжди, ліниві пайплайни, де модель обрали за бенчмарком, а про реальне розгортання подумали потім.
На практиці це дає три переваги: нижчі вимоги до пам'яті, дешевша інфраструктура та простіша AI implementation там, де раніше доводилося або обрізати функціонал, або відправляти все в хмару.
Проте я б не став рекламувати це як універсальну заміну всім FP16 та BF16 рішенням. Потрібно аналізувати конкретну архітектуру, довжину контексту, KV cache, тип навантаження та поведінку моделі після інтеграції в продукт. Ми в Nahornyi AI Lab вирішуємо такі завдання практично, а не за слайдами презентацій.
Якщо запуск вашої локальної моделі обмежений пам'яттю, затримкою чи вартістю заліза, це чудовий момент, щоб перебудувати AI architecture під реальну задачу. Ми можемо разом розібрати ваш кейс та налаштувати AI solution development так, щоб модель не просто запускалася, а приносила реальну користь без зайвих витрат на сервери.