Что обсуждают в сообществе: суть запроса к Gemma 5
23 сентября 2026 года в сабреддите r/LocalLLaMA появился пост из двух строк. Пользователь /u/CriticallyCarmelized обратился к Google: "Gemma 5, 220B A18B QAT plus ngrams please. Thank you very much!" Второй строкой обозначен запасной вариант: "Will settle for 120B A16B plus ngrams." Оригинал лежит в r/LocalLLaMA.
Смысл запроса укладывается в одно предложение: автор хочет крупную открытую модель с небольшим числом активных параметров, обученную с учётом квантования, и с поддержкой n-грамм. 220B A18B - основной вариант, 120B A16B - то, на что он согласен, если первый не выйдет.
Gemma 5 на 23 сентября 2026 года официально не анонсирована. Google не показывал карточку модели, не называл дату релиза, не публиковал характеристики и бенчмарки. Подтверждённый факт один: есть пост в Reddit с пожеланием и есть обсуждение вокруг него. Ниже разобрано, что стоит за числами, зачем нужны QAT и n-граммы и сколько памяти потребует такая модель, если она когда-нибудь появится.
Что означают 220B A18B и 120B A16B: разбираем параметры модели
Запись вида 220B A18B читается как два числа. 220B - общее количество параметров, то есть весов, которые лежат в файле модели. A18B - количество параметров, которые участвуют в вычислениях на каждом отдельном токене.
У плотной модели второе число всегда равно первому: генерируя очередной токен, Gemma 3 27B задействует все 27 миллиардов весов. Две разные цифры в записи означают Mixture-of-Experts (MoE). Веса разбиты на группы-эксперты, а роутер на каждом шаге решает, какие эксперты включить и с какими весами сложить их результат.
Практический смысл разделения такой: общее число параметров определяет, сколько весов придётся держать в памяти, а активные параметры определяют объём вычислений на токен. 220B A18B означает склад на 220 миллиардов весов, из которого на каждой итерации достают примерно 18 миллиардов. 120B A16B - тот же принцип, но скромнее по обоим числам.
Ни одна из этих конфигураций не подтверждена Google. 220B A18B и 120B A16B взяты из текста поста, а не из спецификации производителя.
Почему активные параметры важны для скорости и железа
Время генерации одного токена зависит от двух факторов: объёма вычислений и количества байт, которое нужно прочитать из памяти. В MoE второй фактор часто перевешивает. Чем больше весов поднимается из VRAM или RAM на каждый токен, тем ниже скорость, и активные параметры как раз описывают эту нагрузку.
Если 220B A18B окажется MoE, по вычислениям на токен она будет сопоставима с плотной моделью примерно на 18B, а знаний в ней будет как в модели на 220B. Отсюда и привлекательность идеи: качество крупной модели при скорости средней. Оговорки тоже есть. Скорость зависит от реализации роутера, от батчинга экспертов и от пропускной способности памяти. На слабой видеокарте с выгрузкой части слоёв на CPU MoE может оказаться медленнее плотной модели меньшего размера.
Отдельно про хранение: в MoE все эксперты должны быть доступны в VRAM или оперативной памяти, даже если на конкретном токене срабатывает лишь часть из них. Экономия идёт на вычислениях, а не на объёме весов.
Сравнение с существующими открытыми моделями
Чтобы оценить масштаб запроса, полезно посмотреть на то, что уже выпущено в открытых весах.
- Gemma 2: плотные модели на 2B, 9B и 27B.
- Gemma 3: плотные 1B, 4B, 12B и 27B, контекст до 128K токенов (разбор линейки).
- Gemma 4: в линейке есть 26B A4B, то есть MoE с 4B активных параметров (обзор с замерами скорости).
- Mixtral 8x7B: около 46B общих параметров при примерно 12B активных.
- Llama 3.1: плотные модели на 8B, 70B и 405B.
Запрошенные 220B A18B не вписываются в эту картину. По общему объёму это больше любой плотной открытой модели Google, а по активным параметрам - уровень 18B-класса. 120B A16B скромнее, но тоже выходит за пределы того, что Google открывал до сих пор.
Размер 120B в обсуждениях вокруг открытых моделей Google уже всплывал: сценарий с открытой мультимодальной Gemma на 120B параметров разбирался отдельно. Это тоже разговор о вероятности, а не о подтверждённом релизе.
QAT: что это и почему пользователи просят квантование с учётом обучения
QAT расшифровывается как Quantization-Aware Training, то есть обучение с учётом квантования. Модель тренируют не в полной точности, а с имитацией квантования внутри графа: веса и активации округляются до низкой разрядности прямо во время обучения, и сеть приспосабливается к этой погрешности заранее.
Альтернативный путь - PTQ (Post-Training Quantization), когда готовые веса сжимают уже после обучения. PTQ дешевле и быстрее, именно так получают большинство GGUF-сборок в Q4. Проблема в том, что при агрессивном сжатии погрешность копится от слоя к слою, и качество проседает тем заметнее, чем меньше бит приходится на параметр.
Для 220B аргумент в пользу QAT простой: сжать такую модель до 4 бит без потерь - рискованное занятие, а QAT-версия изначально обучена жить в этом режиме. Минус тоже есть. QAT требует доступа к полному пайплайну обучения и обходится дорого, поэтому такие сборки выпускает сама компания-разработчик отдельным комплектом весов, а не сторонние квантователи.
Не стоит путать две вещи. QAT улучшает качество 4-битной модели, но не отменяет потребность в памяти: при 220B и 4 битах на параметр получается около 110 ГБ весов, и они всё равно должны где-то лежать. Квантование снижает нагрузку на пропускную способность памяти и вычисления, а не объём хранения в разы.
n-граммы в LLM: зачем они нужны и как помогают
n-грамма - это последовательность из n идущих подряд токенов. Биграмма - два соседних токена, триграмма - три. Само понятие пришло из статистических языковых моделей, где следующее слово предсказывали по частотам предыдущих сочетаний.
В посте фраза "plus ngrams" не расшифрована, поэтому дальше речь о том, что под n-граммами обычно понимают применительно к современным LLM. Это интерпретация, а не заявление автора оригинального поста.
На практике встречаются три механизма.
- Спекулятивное декодирование по n-граммам из контекста. Черновой вариант продолжения берётся из уже виденного текста, а основная модель его проверяет и принимает или отклоняет. На повторяющемся материале, например при правках кода, это даёт ускорение генерации; на свободном тексте выигрыш меньше.
- Запрет повторяющихся n-грамм. Ограничение не даёт модели зацикливаться на одной фразе при длинной генерации. Это про предсказуемость и читаемость вывода.
- Обучаемая n-граммная память. Дополнительный модуль, который хранит статистику частых последовательностей и подсказывает модели следующий токен. В открытых весах такой подход встречается редко.
Польза от n-грамм лежит в области скорости и управляемости, а не знаний. Новых фактов модель от них не получает. Стандартной функцией открытых LLM поддержка n-грамм пока не стала: это внешний механизм, который включается на уровне движка инференса, а не свойство весов. Просьбу из поста поэтому логично читать как пожелание, чтобы Google встроил такую поддержку в саму поставку.
Потянет ли ваше железо: требования к VRAM для 220B/A18B и 120B/A16B
Оценка по памяти делается арифметикой. Формат FP16 и BF16 занимает 2 байта на параметр, Q8 около 1 байта, Q4 около половины байта. Для MoE считают по общим параметрам, потому что хранить нужно все эксперты.
| Конфигурация | FP16 / BF16 | Q8 | Q4 |
|---|---|---|---|
| 220B общих параметров | около 440 ГБ | около 220 ГБ | около 110-120 ГБ |
| 120B общих параметров | около 240 ГБ | около 120 ГБ | около 60-66 ГБ |
К этим числам добавляется запас на контекст и активации. KV-кэш на длинном контексте у крупной модели измеряется десятками гигабайт, поэтому реальное потребление выше базовой оценки примерно на 10-20%, а при контексте в сотни тысяч токенов и сильнее.
- 220B в Q4: порядка 110-120 ГБ на веса и 130-145 ГБ с запасом.
- 120B в Q4: порядка 60-66 ГБ на веса и 70-80 ГБ с запасом.
- 220B в Q8: около 220 ГБ на веса, то есть уровень сервера на несколько ускорителей.
Цифры ориентировочные. Фактическое потребление зависит от реализации движка, от того, квантуются ли эмбеддинги и слои attention, и от реальной длины контекста.
Варианты для домашнего AI-сервера
Четыре потребительские видеокарты по 24 ГБ дают 96 ГБ VRAM. Для 220B даже в Q4 этого мало: часть слоёв придётся считать на CPU или подкачивать с NVMe. Для 120B в Q4 такой объём близок к границе, и скорость будет держаться только при аккуратной настройке.
- 120B в Q4: два ускорителя по 48 ГБ или один на 80 ГБ, тогда веса помещаются целиком.
- 220B в Q4: около 130-145 ГБ суммарной памяти, то есть два ускорителя по 80 ГБ или четыре по 48 ГБ.
- 220B в Q8: порядка 240-260 ГБ, это уже полноценная серверная сборка.
Отдельная история - выгрузка экспертов MoE на CPU. В llama.cpp можно оставить на видеокарте attention и служебные слои, а экспертов держать в оперативной памяти: на каждом токене читается только часть из них, поэтому падение скорости меньше, чем при обычном оффлоаде плотной модели того же размера. Для 120B A16B такой сценарий выглядит рабочим на машине со 128 ГБ RAM и одной видеокартой на 24-48 ГБ. Конкретных токенов в секунду без замеров на реальной сборке обещать не стоит.
Пропускная способность памяти влияет на скорость генерации сильнее, чем число вычислительных блоков. Потребительские и серверные ускорители различаются по этому параметру в разы, поэтому две системы с одинаковым объёмом VRAM могут показывать заметно разную скорость на одной и той же модели.
Почему сообщество хочет именно такие модели: мотивация и контекст
Запрос на крупную MoE с QAT и n-граммами собирается из нескольких практических мотивов.
- Приватность. Данные не уходят на сторонний API, что важно для рабочих документов, переписки и кода.
- Предсказуемость. Версия модели на диске не меняется без вашего участия, лимитов на число запросов нет.
- Расходы. Платить за токены не нужно, но железо, электричество и время на настройку остаются.
- Качество. Хочется получать локально тот уровень, который сейчас доступен в основном через облачные сервисы.
В линейке Gemma уже есть MoE: 26B A4B с 4B активных параметров. Прыжок до 18B активных и 220B общих - это другой класс по железу и по цене ошибки, но направление понятное. Google показал, что умеет выпускать открытые MoE, и сообщество просит продолжить линейку вверх.
Плотные модели упираются в потолок. 27B в Q4 помещается в 24 ГБ VRAM, но по объёму знаний уступает моделям на сотни миллиардов параметров. MoE выглядит способом обойти это ограничение: держать много знаний, считать на каждом токене немного. Мнения расходятся: одним нужна модель для кода, другим для длинных документов и анализа, третьим для творческих задач. Пост /u/CriticallyCarmelized отражает один набор пожеланий, а не позицию всего сообщества.
Что известно о Gemma 5 на самом деле: отделяем факты от предположений
Проверяемая часть материала сводится к нескольким пунктам.
- 23 сентября 2026 года пользователь /u/CriticallyCarmelized опубликовал в r/LocalLLaMA пост с просьбой выпустить Gemma 5 в конфигурации 220B A18B QAT с поддержкой n-грамм и указал запасной вариант 120B A16B с n-граммами (источник).
- Google не анонсировал Gemma 5, не называл сроков и не публиковал спецификаций.
- Бенчмарков, карточек модели на Hugging Face и технического отчёта по Gemma 5 не существует.
Всё остальное - предположения. Риск в том, что числа 220B A18B и 120B A16B начинают цитировать как известные характеристики: выглядят они как спецификация, хотя взяты из двух строк в Reddit.
Сроки экстраполировать тоже не стоит. Предыдущие версии линейки выходили с разными интервалами и разным составом размеров, включая переход от плотных моделей к MoE. Из этой истории не следует, что следующая версия появится в конкретном месяце или окажется крупнее предыдущей.
Проверять стоит по официальным каналам: блог Google, страница Gemma и карточки моделей на Hugging Face. Reddit и агрегаторы новостей полезны как сигнал о настроениях и запросах, но не как источник спецификаций.
Что делать сейчас: практические выводы для пользователей локальных LLM
Ждать Gemma 5 как единственное решение нерационально: сроков нет, характеристик нет, а задачи нужно закрывать сегодня. Порядок действий выглядит так.
- Посчитайте бюджет VRAM. 24 ГБ закрывают модели до 30B в Q4 с запасом под контекст. 48 ГБ открывают 70B в Q4. 96 ГБ и выше - это класс 120B в Q4, но со оговорками по скорости.
- Выберите модель из существующих. Для большинства домашних сценариев хватает 26-31B: сравнение Gemma 4 26B A4B и Qwen3.6-MoE с цифрами по инференсу и reasoning разобрано в отдельном материале. Если видеокарта слабая, есть MoE-модели с примерно 2B активных параметров, рассчитанные на 4-12 ГБ (подборка).
- Разберитесь с форматами квантования. GGUF удобен для llama.cpp и выгрузки слоёв, GPTQ и AWQ - для vLLM и похожих движков. При равной разрядности QAT-сборка предпочтительнее обычной: та же разрядность, меньше потерь в качестве.
- Проверьте фактически доступную память. Часть VRAM занимают система и вывод изображения, поэтому планируйте на 1-2 ГБ меньше номинала.
- Следите за официальными анонсами Google. Выход Gemma 5 будет заметен по карточке модели и техническому отчёту, а не по постам с пожеланиями.
Если задача решается на модели 27-31B сегодня, ждать 220B A18B смысла нет: разница между этими классами измеряется не в гигабайтах VRAM, а в порядке величины. Если нужны знания крупной модели на своём железе, следить за MoE-направлением в открытых линейках стоит, потому что именно там идёт основная борьба за эффективность на один потраченный гигабайт памяти.