Déploiement local d’EmbeddingGemma 2 : guide des risques de migration

Déployer EmbeddingGemma 2 en local ne revient pas forcément à remplacer à l’identique un service d’embeddings existant. Le runtime peut changer sans nécessiter beaucoup de modifications côté application, mais toute évolution du contrat de représentation implique généralement de recalculer les vecteurs. Pour limiter les risques, séparez trois décisions : comment exécuter le modèle, si les vecteurs actuels restent compatibles et si la recherche multimodale offre une qualité suffisante sur votre corpus.

La décision de migration en un coup d’œil

EmbeddingGemma 2 est un bon choix si vous avez besoin d’embeddings locaux pour le texte, le code, les images, la vidéo ou l’audio au sein d’une même famille de modèles, et si vous pouvez planifier un recalcul contrôlé. Évitez de remplacer d’abord l’encodeur des requêtes en production pour « rattraper » ensuite le retard sur les documents : un modèle d’embeddings fait partie du schéma de l’index, même lorsque la dimension des vecteurs semble identique.

La fiche technique de Google indique des scores de 61.36 sur MTEB multilingual v2, 78.68 sur MTEB code v1, 67.84 en NDCG@5 sur la recherche de documents visuels, 50.67 en Hit@1 sur la recherche vidéo et 69.54 en MRR@10 sur la recherche audio, le tout en 768 dimensions. Ces chiffres constituent des repères utiles, pas un substitut aux tests sur vos propres requêtes.

Ce qui change — et ce qui ne change pas — avec EmbeddingGemma 2

EmbeddingGemma 2 projette le texte, le code, les images, la vidéo et l’audio dans un espace partagé de 768 dimensions. Le checkpoint est modulaire : le guide officiel pour les développeurs décrit une configuration texte seul de 270M, une configuration texte plus vision de 440M, une configuration texte plus audio de 570M et une configuration complète de 740M. Désactiver un encodeur réduit le nombre de poids chargés et le pic de mémoire ; cela ne crée pas, à lui seul, un nouvel espace sémantique.

Cette nuance est essentielle lors d’une migration. Une requête textuelle produite avec la configuration 270M peut être comparée à un document encodé avec la configuration complète d’EmbeddingGemma 2, car Google indique que ces configurations partagent un espace vectoriel compatible. En revanche, cela ne signifie pas qu’un ancien vecteur issu d’EmbeddingGemma 1, de Qwen, de Nomic ou d’un fournisseur d’API peut être interrogé sans risque avec EmbeddingGemma 2 sous prétexte qu’il comporte lui aussi 768 coordonnées.

Le formatage des tâches fait également partie du contrat. Pour la recherche asymétrique, EmbeddingGemma 2 attend une instruction de requête telle que task: search result | query: ... et un format documentaire comme title: ... | text: .... La recherche de code possède sa propre instruction. Si votre ancien pipeline utilisait d’autres préfixes, un autre découpage, une normalisation différente ou d’autres champs intégrés, consignez ces écarts comme une nouvelle version de représentation et validez-les comme une migration.

Choisir le runtime local le plus simple compatible avec votre besoin

Commencez par Sentence Transformers pour sécuriser la justesse

La fiche officielle du modèle documente google/embeddinggemma-2 avec Sentence Transformers et Transformers. Installez les extras multimodaux si vous avez besoin de prendre en charge les médias :

pip install -U "sentence-transformers[image,audio,video]" transformers

C’est le meilleur point de référence pour une migration : les noms des prompts, la troncature, la normalisation et le comportement des entrées multimodales suivent les exemples officiels. Ce ne sera pas nécessairement le chemin de serving le plus rapide, mais vous disposerez d’une base fiable avant de commencer l’optimisation.

Voici un test minimal pour le texte seul :

from sentence_transformers import SentenceTransformer

model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"vision_config": None, "audio_config": None},
)
query = model.encode(
    "embedding model migration",
    prompt_name="SearchQuery",
    truncate_dim=256,
    normalize_embeddings=True,
)
document = model.encode(
    "Rebuild vectors when the embedding representation changes.",
    prompt_name="Document",
    truncate_dim=256,
    normalize_embeddings=True,
)
print(model.similarity(query, document).item())

Exécutez ce test avant d’ajouter un serveur, de quantifier le modèle ou de brancher une base vectorielle. Il vérifie que le checkpoint, les prompts de tâche, la dimension et la normalisation fonctionnent bien ensemble.

N’adoptez les runtimes de l’écosystème qu’après avoir vérifié la parité fonctionnelle

Le guide de Google cite vLLM, Hugging Face Transformers, Sentence Transformers, SGLang, MLX, Ollama, LM Studio et LiteRT parmi les outils de développement ou de déploiement pris en charge. Considérez cette liste comme un indicateur de disponibilité, pas comme la garantie que chaque runtime expose exactement la même combinaison de texte, image, vidéo, audio, entrées entrelacées, préfixes de tâche, troncature et batching.

Pour chaque runtime candidat, vérifiez cinq points avec une requête réelle : la révision exacte du checkpoint, les modalités que vous utilisez, les dimensions de sortie, la normalisation après troncature et le comportement des préfixes de requête et de document. Un runtime qui sert rapidement le texte mais ignore votre flux de documents visuels n’est pas équivalent au modèle complet.

Un serveur natif compact est une optimisation, pas un plan de migration

Le dépôt public embeddinggemma.c fournit un serveur spécialisé de type C11/Metal pour EmbeddingGemma 300M, avec des variantes CPU, Metal, CUDA, ROCm et Intel XPU. Son README documente un endpoint /v1/embeddings compatible avec l’API OpenAI, des dimensions 768/512/256/128 et le téléchargement d’un modèle Q4_0 de 278 MB. Le projet publie une comparaison contrôlée sur Apple M5 Max face à la build b8981 de llama.cpp, menée sur 54 cellules, avec un avantage de moyenne géométrique de 1.25× ; ces résultats de débit sont propres au projet. Ils ne constituent ni une comparaison de qualité ni la preuve d’une parité multimodale avec le checkpoint 740M.

Son principal intérêt pour une migration tient à la forme de l’API. Si votre application utilise déjà des embeddings au format OpenAI, un serveur local compatible avec cet endpoint peut réduire le travail d’adaptation. Conservez néanmoins le résultat Sentence Transformers comme référence de justesse jusqu’à ce que le comportement du serveur en matière de modalités et de préfixes corresponde à celui de votre pipeline de production.

Risque de reconstruction de l’index : la dimension n’est qu’un des axes de migration

Recalculez les embeddings dès que la fonction source-vers-vecteur évolue

Partez du principe qu’une reconstruction complète est nécessaire si vous changez de famille de modèles, de version, de préfixe de tâche, de normalisation, de découpage, de politique de troncature, de champs intégrés ou de métrique de similarité. Le guide de migration de Qdrant et l’analyse de migration de modèles publiée par Nalar soulignent le même point opérationnel : les vecteurs des documents et ceux des requêtes doivent appartenir à la même version de représentation. Une dimension identique ne suffit pas à établir une compatibilité sémantique.

Ne découpez pas un ancien vecteur de 768 dimensions pour le présenter comme un vecteur EmbeddingGemma 2 de 256 dimensions. Les sorties Matryoshka d’EmbeddingGemma 2 sont entraînées pour des tailles de troncature prises en charge et doivent être renormalisées après la troncature. La fiche du modèle fournit les scores de référence officiels suivants :

La fiche officielle indique également 67.84 en NDCG@5 sur la recherche de documents visuels et 50.67 en Hit@1 sur la recherche vidéo en 768 dimensions. Utilisez ces valeurs comme références en pleine dimension plutôt que d’inventer des scores pour les dimensions réduites. La conclusion fiable reste directionnelle : 256d reste bien plus proche de la qualité complète que 128d, tandis que les scores multimodaux chutent plus fortement en 128d. Régénérez chaque vecteur avec le checkpoint officiel à la dimension retenue au lieu de tronquer les vecteurs d’un autre modèle.

L’espace partagé d’EmbeddingGemma 2 peut éviter une partie du travail

Il existe toutefois une exception importante. Si votre corpus a déjà été encodé avec EmbeddingGemma 2 et que vous chargez simplement un sous-ensemble différent de ses encodeurs, Google indique dans son guide développeur que les configurations partagent un même espace vectoriel. Une requête textuelle peut donc retrouver un document encodé avec le modèle complet. Dans ce cas, il n’est pas forcément nécessaire de régénérer les vecteurs textuels existants uniquement parce que le processus de serving prend désormais en charge la vision ou l’audio.

Les nouveaux enregistrements contenant des médias doivent tout de même recevoir de nouveaux vecteurs. Un index limité au texte ne peut pas retrouver une image, une vidéo ou un élément audio qui n’a jamais été encodé. Ajouter la recherche multimodale reste donc une migration progressive du corpus, même si le checkpoint du modèle ne change pas.

Préparez une bascule blue-green ou des vecteurs nommés

Pour un système en production, le schéma de migration de Qdrant fournit un modèle clair : créer une nouvelle collection, écrire les nouveaux enregistrements dans les deux versions, recalculer les vecteurs à partir des données sources de référence, comparer Recall@10/MRR/nDCG@10, basculer un alias et conserver l’ancienne collection pour permettre un retour arrière. Le guide de Qdrant utilise la version 1.19.0, un exemple en 512 dimensions et des lots de 100 points ; ces valeurs sont illustratives et ne constituent pas des exigences pour EmbeddingGemma 2.

Une architecture à vecteurs nommés peut conserver les anciennes et les nouvelles représentations dans une même collection, à condition que votre base vectorielle le permette et que votre chaîne de mise à jour écrive systématiquement les deux versions. Le guide de migration des vectorizers de Weaviate recommande les alias de collections en production, car l’ancienne collection peut être gardée pour un retour arrière immédiat puis supprimée après validation. L’autre approche — ajouter un vecteur à la collection existante — peut augmenter durablement le stockage et convient mieux à une phase de comparaison qu’à un état final propre.

Qualité multimodale : testez les segments réellement affectés par le modèle

L’espace partagé d’EmbeddingGemma 2 n’a d’intérêt que si le comportement de la recherche correspond à vos données. Un benchmark limité au texte peut confirmer que la migration n’a pas cassé la recherche textuelle tout en passant à côté de problèmes sur les pages PDF, les graphiques, les légendes d’images, les images vidéo, les extraits audio ou les enregistrements entrelacés.

Commencez par créer des segments labellisés distincts :

1. Requête texte → segment de texte.
2. Requête de code → segment de code.
3. Requête texte → image ou document visuel.
4. Requête texte → image vidéo ou segment audio.
5. Requête mêlant texte et médias → document mixte.
6. Requête multilingue → document dans les langues que vous prenez en charge.

Pour la première référence multimodale, restez en 768d ou 512d. La fiche officielle attribue 280 tokens par image, 140 tokens par image vidéo et 25 tokens par seconde d’audio dans une fenêtre de contexte partagée de 8,192 tokens. Les entrées mixtes consomment le même budget : un enregistrement contenant du texte, des images et de la vidéo dispose donc de moins de place pour chaque composant qu’une entrée limitée à une seule modalité.

La fiche indique également que 128d entraîne une baisse de qualité plus marquée sur les tâches multimodales que sur les tâches textuelles. 128d peut donc servir de candidat initial pour un vaste index textuel, mais ne devrait pas être le réglage par défaut d’une archive de médias mixtes. Testez 256d sur vos véritables requêtes de documents visuels et de recherche intermodale avant de valider le gain de stockage.

Comparez un pipeline unifié basé sur EmbeddingGemma 2 à votre pipeline actuel séparant texte et images, avec exactement les mêmes requêtes ; ne déduisez pas la qualité multimodale de la seule architecture à espace partagé du modèle.

Plan de déploiement progressif pour un système RAG existant

1. Inventoriez le contrat actuel. Notez l’identifiant du modèle, la révision du checkpoint, les préfixes, le découpage, les dimensions, la métrique, la normalisation, les champs sources et toutes les modalités déjà indexées.
2. Constituez un jeu d’évaluation représentatif. Définissez des objectifs de Recall@k, MRR ou nDCG, avec des segments distincts pour le texte, le code, les documents visuels, l’audio, la vidéo, les langues et les requêtes longues.
3. Établissez la référence locale. Faites d’abord passer le même corpus dans Sentence Transformers. Mesurez la latence d’encodage, la latence de recherche, la mémoire, la taille de l’index, les erreurs et la distribution des scores.
4. Créez un index candidat versionné. Conservez des identifiants de documents stables et stockez le texte ou les médias sources de référence en dehors du magasin vectoriel afin de rendre le recalcul reproductible.
5. Réconciliez les écritures pendant le recalcul. Utilisez un instantané des sources suivi de la rejoue des changements, ou écrivez les nouveaux enregistrements et les mises à jour dans les deux versions de représentation.
6. Rejouez les requêtes de production en parallèle. Comparez les résultats classés, les taux de résultats vides, la latence et la pertinence annotée sans modifier les réponses visibles par les utilisateurs.
7. Basculez de manière atomique. Associez l’encodeur de requêtes EmbeddingGemma 2 et l’index correspondant sous une même version ou un même alias. Ne déployez jamais le nouvel encodeur de requêtes face à l’ancien index, même temporairement.
8. Conservez un plan de retour arrière. Gardez l’ancien index et l’ancien chemin de requête jusqu’à ce que le trafic représentatif franchisse les seuils d’acceptation ; arrêtez ensuite les écritures doubles et récupérez l’espace disque.

FAQ

EmbeddingGemma 2 peut-il fonctionner uniquement sur CPU ?

Oui, avec un runtime compatible CPU. La fiche du modèle recommande float32 lorsque bfloat16 n’est pas disponible, et la configuration texte seul compte 270M de paramètres. Le débit CPU dépend du runtime, de la précision, du batching et du matériel : mesurez-le donc sur votre corpus plutôt que de reprendre des chiffres obtenus sur GPU.

Le choix du runtime revient à arbitrer entre la fiabilité de la référence, la parité fonctionnelle, l’efficacité du serving et le coût de validation d’une nouvelle version de recherche.