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 — но конкретный порог всё равно придётся проверять на собственном датасете.
А какие у вас впечатления от модели?
ссылка на оригинал статьи https://habr.com/ru/articles/1091786/