Как Google научил крошечную модель понимать текст, картинки, видео и звук: разбираем EmbeddingGemma 2

6 октября 2026 года Google DeepMind выпустила EmbeddingGemma 2 — открытую модель эмбеддингов, которая превращает в векторы текст, код, изображения, видео и аудио. Все они попадают в одно общее 768-мерное пространство, поэтому их можно сравнивать между собой, например искать видео по текстовому запросу.

Главная особенность модели — размер. По данным Google, на Pixel 11 Pro текстовая часть занимает около 191 МБ оперативной памяти, а полная мультимодальная версия — около 567 МБ. Поэтому такой поиск можно запускать прямо на устройстве, а не отправлять данные на сервер.

В этой статье мы разберём, как устроена модель, за счёт чего она такая компактная, как с ней работать и о каких граблях лучше узнать заранее.

▍ Эмбеддинги за минуту

Эмбеддинг — это список чисел (вектор), который описывает смысл содержимого. Похожие по смыслу вещи получают близкие векторы. Фразы «Сегодня чудесная погода» и «На улице так солнечно!» окажутся рядом, а «Он поехал на стадион» — далеко от них.

Дальше всё просто: считаем вектор для запроса, считаем векторы для документов и ищем ближайшие по косинусной близости. Так работают семантический поиск, RAG, кластеризация, поиск дубликатов и рекомендации.

Главная проблема раньше была в том, что для каждого типа данных нужна своя модель, а векторы из разных моделей несравнимы. Вектор текста нельзя положить рядом с вектором картинки. EmbeddingGemma 2 решает именно это: все модальности попадают в одно общее 768-мерное пространство.

▍ Что нового

Первая EmbeddingGemma вышла в сентябре 2025 года, умела только текст и, по данным японского издания livedoor, набрала больше 20 млн скачиваний. Вторая версия выглядит так:

• построена на архитектуре Gemma 4;

• 740M параметров, но модульная: 270M текст + 170M зрение + 300M аудио;

• лицензия Apache 2.0;

• понимает 100+ языков, а на задачах с кодом лучше предшественницы примерно на 14%;

• контекст 8192 токена, в 4 раза больше, чем у первой версии;

• Matryoshka-векторы: 768, 512, 256 или 128 измерений;

• оптимизирована под телефоны и ноутбуки.

▍ Что внутри

Текстовая часть — компактный трансформер. Вот что написано в карточке модели:

Что тут интересного.

Локальное и глобальное внимание. Пять слоёв из шести смотрят только на окно в 1024 токена, и лишь каждый шестой видит всю последовательность целиком. Это сильно экономит память и вычисления на длинных входах.

Огромный словарь. 262 144 токена — это много. Параметры модели делятся на «backbone» (130M) и «embedder» (140M). Судя по цифрам, embedder — это в основном таблица токенов: 262 144 × 512 ≈ 134M. Это просто поиск строки по индексу, а не вычисления, так что реально «работает» только трансформер на 130M параметров. Отсюда и скромные аппетиты по скорости и памяти. (Это моя прикидка по цифрам из карточки, Google такого разбора не публиковала.)

Пулинг. Выходы всех токенов усредняются в один вектор на 512 измерений, затем линейный слой разворачивает его до 768.

▍ Платите только за то, что используете

Зрение (170M) и аудио (300M) — отдельные энкодеры, которые можно не загружать. Нужен только текстовый поиск? Грузим 270M. Нужны ещё картинки? Добавляем зрение.

Google приводит и цифры по оперативной памяти для Pixel 11 Pro: около 191 МБ для текстовой части и около 567 МБ для полной мультимодальной модели. Для сравнения, обычный браузер с парой вкладок съедает больше.

▍ Один вектор на всё: токенный бюджет

Все модальности делят общее окно в 8192 токена, и каждая тратит его по своей «таксе»:

Арифметика сходится: 280 × 29 ≈ 8120, 140 × 58 ≈ 8120, 25 × 327 ≈ 8175.

Если картинки нужны дешевле, можно уменьшить бюджет на изображение (от 70 до 1120 «мягких» токенов). Тогда в окно влезет до ~114 картинок или кадров, но детали будут передаваться хуже.

Самое интересное — интерлив. В один вход можно смешать текст, картинки, видео и аудио, а позицию медиа отметить спецтокенами <|image|>, <|video|> и <|audio|>. На выходе получится один вектор на всё описание. Например, карточка товара из магазина: текст, фото и видеообзор превращаются в один эмбеддинг, который можно сравнить с обычным текстовым запросом «водонепроницаемые кроссовки для трейла».

▍ Матрёшка в векторе

Модель обучена по методу Matryoshka Representation Learning (MRL). Идея в том, что важная информация упаковывается в первые измерения вектора, как матрёшки вкладываются друг в друга. Поэтому 768-мерный вектор можно просто обрезать до 512, 256 или 128 измерений.

Зачем? Чтобы экономить место и ускорять поиск. Если у вас миллион документов в float32, то при 768 измерениях это около 3 ГБ векторов, а при 128 — около 0,5 ГБ. Разница в 6 раз.

Что при этом происходит с качеством (данные из карточки модели):

До 256 измерений потери небольшие. На 128 текст ещё держится, а вот мультимодальные задачи заметно проседают: в MMEB v2 падение с 59,01 до 45,65. Google прямо советует 128d только для текстовых сценариев и проверять на своих данных.

▍ Что с качеством

Основные результаты полной модели (768d) против первой EmbeddingGemma:

Честный вывод из таблицы: на многоязычном тексте модель почти не продвинулась (61,36 против 61,15). Зато код подрос на 10 пунктов, а главное — появились картинки, видео и звук, которых у предшественницы не было вовсе. Google при этом называет модель одной из сильнейших мультимодальных эмбеддеров до 1 млрд параметров, но все цифры выше — собственные замеры Google, независимые сравнения стоит смотреть отдельно.

▍ Код

Самый простой сценарий — текстовый поиск через sentence-transformers:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer('google/embeddinggemma-2')

query = 'What causes the northern lights?'
document = 'The northern lights are caused by charged particles from the sun.'

query_emb = model.encode(query, prompt_name='SearchQuery')
doc_emb = model.encode(document, prompt_name='Document')

print(model.similarity(query_emb, doc_emb))

Обратите внимание на prompt_name. Модель обучена с короткими инструкциями-префиксами вроде task: search result | query: ... для запроса и title: ... | text: ... для документа. Без них она работает, но точность ниже. Если у документа есть заголовок, форматировать его нужно вручную:

doc_emb = model.encode(f'title: {title} | text: {content}')

Префиксы бывают для поиска, вопросов-ответов, проверки фактов, поиска по коду, классификации, кластеризации и сравнения предложений. Важно: они применяются только к тексту, картинки, видео и аудио подаются без префикса.

Обрезка вектора средствами библиотеки:

query_emb = model.encode(
    query,
    prompt_name='SearchQuery',
    truncate_dim=256,
    normalize_embeddings=True,
)

А если режете вручную, не забудьте нормализовать результат:

import numpy as np

v = emb[:256]
v = v / np.linalg.norm(v)

Загрузка только текстовой части с правильной точностью:

import torch
from sentence_transformers import SentenceTransformer

dtype = torch.bfloat16 if torch.cuda.is_bf16_supported() else torch.float32

model = SentenceTransformer(
    'google/embeddinggemma-2',
    model_kwargs={'torch_dtype': dtype},
    config_kwargs={'vision_config': None, 'audio_config': None},
)

И мультимодальный интерлив, один вектор на всё описание товара:

model = SentenceTransformer('google/embeddinggemma-2')

emb = model.encode({
    'text': 'Waterproof running shoes. <|image|> Breathable mesh upper. <|image|> Grip test on wet rock: <|video|>',
    'image': ['shoe.jpg', 'mesh.jpg'],
    'video': 'demo.mp4',
})

Каждый плейсхолдер в тексте заполняется соответствующим ключом по порядку. Полученный вектор напрямую сравнивается с любым другим вектором EmbeddingGemma 2, в том числе с текстовым запросом.

▍ Грабли

float16 ломает модель. Активации модели выходят за диапазон float16, и вы получите NaN или тихо испорченные эмбеддинги, причём без ошибки. Используйте bfloat16 или float32. На большинстве CPU это float32.

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

Разные размерности у запросов и документов. 768-мерный запрос нельзя сравнивать со 128-мерным корпусом.

Забыли про префиксы. Модель не сломается, но потеряет в точности.

Языки неравнозначны. Заявлено 100+ языков, но Google сама оговаривается, что качество может различаться между ними. Для русского проверяйте на своих данных.

Нет защитных механизмов. Это предобученный эмбеддер без пост-обучения на безопасность. Фильтрацию выдачи и проверки на предвзятость придётся делать на уровне вашего приложения.

▍ Где взять и как запустить

Веса лежат на Hugging Face и Kaggle. Для локального запуска есть GGUF-версии от Unsloth, а поддержку заявляют MediaPipe, LiteRT, vLLM и Ollama. Для серверной раздачи есть рецепт в документации SGLang: модель в BF16 весит около 1,5 ГБ, так что подойдёт практически любая серверная видеокарта.

А если хочется потрогать без установки, на Hugging Face есть демо webml-community/embeddinggemma-2-webgpu, где модель считает эмбеддинги прямо в браузере на WebGPU.

▍ Итоги

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

Станут ли эмбеддинги на устройстве таким же стандартом, как распознавание речи на устройстве, покажет время.

Залипательное ДЕМО

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку