Исключительный повод написать про квантизацию (сжатие) моделей Про квантизации я обычно не пишу, т.к. в бизнес задачах их практически не используют [1]. Но Google Gemma-3-27B стала исключением. Это сама по себе хорошая модель, которая еще и внезапно неплохо умеет в reasoning c SO CoT. Она весит 55GB и при загрузке в GPU в bf16 формате потребует ~ 60GB VRAM для текстовых задач. Это значит, что она влазит в одну H100 80GB. Народ, естественно, начал перепаковывать эту модель в всякие хитрые квантизации, чтобы запускать на карточках поменьше. А потом Google сделали ход конем и выпустили официальный google/gemma-3-27b-it-qat-q4_0-gguf. Эта квантизация условно использует не два байта на один параметр, а в четыре раза меньше (~4 бита на параметр), что транслируется в ~3x экономии памяти. Фишка и отличие здесь в том, что Google использовали __Quantisation Aware Training__ (QAT), которая позволяет пожать модель без особой потери качества. Если раньше у меня были большие надежды на версии qwen-2.5 для умных локальных систем, то сейчас еще больше нравится Gemma-3 (27B и 12B). У них выхлоп на размер сильно больше, думать умеют, поддержка языков заявлена хорошая, а теперь еще и появилось больше способов запускать на разном железе. Возможности для стартапов с локальными моделями прямо подскочили! Ваш, @llm_under_hood 🤗 [1] Квантизации могут экономить память GPU-шек за счет сжатия параметров , но при этом негативно влиять на точность и скорость ответов. Чем сильнее и хитрее пожали, тем больше эффект. И при этом еще и требуется, чтобы такую хитрую квантизацию нормально поддерживал софт и были люди с опытом. bf16 за квантизацию можно не считать, да и fp8 тоже (если он делается при помощи QAT и запускается нативно на GPU последних поколений)