EmbeddingGemma 2 спустя сутки: что осталось от обещаний Google

6 октября Google DeepMind выпустила EmbeddingGemma 2 — компактную open-weight схема для embeddings, которая умеет работать не только с текстом и кодом, но и с изображениями, видео и аудио. Спустя сутки релиз уже появился в локальном стеке разработчиков, а первые сравнения показывают более неоднозначную картину, чем следует из формулировки Google о «лучшем в классе».

Главная идея модели — собрать разные типы данных в единое 768-мерное пространство. Поэтому текстовый запрос можно сопоставлять с изображениями, аудио или видеокадрами без отдельной цепочки из speech-to-text, image captioning и нескольких embedding-моделей. Google рассчитывает таким образом упростить локальный семантический поиск, RAG, классификацию и маршрутизацию.

740 млн параметров в модульной модели

У новой EmbeddingGemma 740 млн параметров: текстовый компонент состоит из 270 млн параметров, еще 170 млн приходится на визуальный энкодер и 300 млн — на аудиоэнкодер. Последние можно подключать выборочно. Для текстовых сценариев Google рекомендует загружать только 270-миллионную часть модели.

Архитектура построена на базе технологий Gemma 4, используется 24 слоя, hidden size 2048 и окно контекста 8192 токена. На выходе модель формирует вектор размерностью 768.

Для мультимодальных запросов можно смешивать текст, изображения, видео и аудио в одном контексте. Google оценивает 8K-контекст около в 29 изображений, 58 видеокадров либо 5,5 минуты аудио.

Локальный запуск

Google изначально проектировала EmbeddingGemma 2 под edge-устройства. После квантизации организация получила на Pixel 11 Pro около 191 МБ активной RAM для text-only версии и примерно 567 МБ для полной мультимодальной конфигурации.

Это открывает вполне практичные сценарии: поиск по фотографиям без отправки данных в облачный сервис, поиск нужного момента в видео по тексту или голосовой заметке, локальный RAG по файлам и классификация входящих данных.

Одновременно 567 МБ нельзя автоматически воспринимать как «цельный размер модели на любом железе». Это конкретный показатель для оптимизированной версии на Pixel 11 Pro. В локальном GGUF-стеке практический объём может быть выше: один из ранних разборов оценивал мультимодальный GGUF около в 730 МБ до учёта части runtime-расходов.

Исходник

В MTEB Code результат вырос с 68,76 до 78,68, то есть почти на 10 процентных пунктов. А вот в мультиязычном MTEB изменения минимальны: 61,15 → 61,36.

Google позиционирует новую схема как вариант для индексации локальных репозиториев и retrieval внутри coding agents. В этом сценарии EmbeddingGemma 2 действительно выглядит интереснее первой версии.

Но здесь уже возникает первый вопрос к формулировке best-in-class.

На опубликованных независимых сопоставлениях EmbeddingGemma 2 не выглядит абсолютным лидером отбора информации из текста. В частности, Qwen3-Embedding-0.6B демонстрирует 64,33 на MTEB multilingual и 70,70 на английском MTEB против 61,36 и 68,46 у EmbeddingGemma 2.

На мультимодальных задачах ситуация тоже не такая однозначная. Google приводит для EmbeddingGemma 2 64,64 на MIEB Lite, 57,28 на MMEB Image, 67,84 на Visual Document, 50,67 на Video и 69,54 на MSEB Retrieval.

Но независимые сравнения уже показывают, почему с такими результатами стоит быть осторожнее. В частности, на MMEB v2 у Qwen3-VL-Embedding-2B приводится результат около 73,2 против 59,01 у EmbeddingGemma 2. Да, Qwen заметно крупнее и не решает ту же задачу по памяти и поддержке аудио, но тезис «маленькая схема обходит большие» здесь работает только для части специализированных сравнений.

При этом полноценного независимого лидерборда, который бы уже после релиза проверил EmbeddingGemma 2 на большом количестве одинаково настроенных задач, пока нет. Следовательно делать вывод, что Google получила свежий универсальный SOTA-embedder, рано.

Нюансы

В документации Google прямо указано, что EmbeddingGemma 2 нельзя запускать в float16. Из-за диапазона активаций модель может выдавать NaN или молча деградировать, не сообщая об ошибке. Рекомендуются bfloat16 или float32.

Это не баг в привычном смысле — скорее важная особенность, которую легко пропустить при переносе модели в уже существующий пайплайн.

Есть и ещё одна тонкость с сокращением размерности вектора. MRL позволяет уменьшить embedding с 768 до 512, 256 или даже 128 измерений. На 256d качество снижается умеренно, зато индекс становится втрое меньше. На 128d экономия уже шестикратная, но мультимодальное качество проседает заметно сильнее: MMEB v2 падает с 59,01 до 45,65.

Для практической эксплуатации это означает, что 256d сейчас выглядит значительно более разумным компромиссом, чем максимальное сжатие до 128d — но конкретный порог всё равно придётся проверять на собственном датасете.

А какие у вас впечатления от модели?