EmbeddingGemma 2 : modèle d'embedding multimodal de 740 millions de paramètres sous licence Apache 2.0
Selon le blog officiel de Google DeepMind du 6 octobre 2026, EmbeddingGemma 2 est publié sous licence Apache 2.0, avec 740 millions de paramètres, capable de projeter texte, code, images, audio et vidéo dans un espace d'embedding unifié, avec un contexte de 8K et des dimensions de vecteurs tronquables.
Ce qui change
Selon un billet de blog officiel publié par Google DeepMind le 6 octobre 2026, Google DeepMind a présenté EmbeddingGemma 2, un modèle d'embedding multimodal destiné à l'inférence en périphérie. Le modèle est construit sur l'architecture Gemma 4, compte 740 millions de paramètres et est publié sous licence Apache 2.0. La source indique qu'il peut mapper nativement des combinaisons de texte, de code, d'images, d'audio et de vidéo dans un espace d'embedding unifié, en s'appuyant sur une technologie issue de Gemini Embedding. Les points de conception rapportés par la source incluent : environ 270 millions de paramètres minimum pour le texte seul, un encodeur visuel d'environ 170 millions et un encodeur audio d'environ 300 millions en modules optionnels ; grâce à l'apprentissage de représentations Matryoshka, les vecteurs de sortie peuvent être tronqués de 768 à 512, 256 ou 128 dimensions, ce qui, selon la source, permettrait jusqu'à environ 6 fois d'économies de stockage ; la fenêtre de contexte est de 8K tokens, ce qui, selon la source, représente 4 fois celle d'EmbeddingGemma 1 et permet de traiter environ 5,5 minutes d'audio, 29 images ou 58 images vidéo. La source fournit aussi des données de référence, dont une progression de MTEB Code de 68,76 à 78,68, soit une amélioration de 9,92 points sur les tâches de code, et elle affirme obtenir des résultats de premier plan parmi les modèles d'embedding multimodaux de moins d'un milliard de paramètres. La source indique également qu'après quantification, les poids texte seul nécessitent environ 191 Mo de mémoire active sur Google Pixel 11 Pro, et le modèle multimodal complet environ 567 Mo. Les poids sont disponibles sur Hugging Face et Kaggle ; la source mentionne une prise en charge à venir dans Gemini Enterprise Agent Platform Model Garden, et une version optimisée pour la périphérie dans LiteRT Community sur Hugging Face.
Conséquences pour les développeurs
Pour les développeurs, la variable centrale de cette publication est l'extension du périmètre des modèles d'embedding du texte vers l'audio, la vidéo et le code, avec des poids publiés sous Apache 2.0, permettant un ajustement et une redistribution autonomes, ce qui impose des contraintes différentes de celles des services d'embedding fermés accessibles uniquement via une API propriétaire. Il faut préciser qu'Apache 2.0 relève de l'ouverture en matière de licence, ce qui est distinct de la disponibilité des poids au téléchargement ; les informations de licence citées ici proviennent du texte source et doivent être vérifiées dans la fiche du modèle et le fichier de licence avant tout usage réel. La source indique qu'EmbeddingGemma 2 partage le tokenizer texte et l'encodeur audio avec Gemma 4, ce qui laisse entendre, selon la source, une empreinte mémoire totale plus faible lorsqu'on combine modèle d'embedding et modèle génératif dans un même pipeline en périphérie ; cela a un impact direct sur le coût de déploiement du RAG hors ligne et des agents en périphérie. La troncature des dimensions vectorielles est un autre paramètre pratique : le stockage dans une base vectorielle et la qualité du rappel font généralement l'objet d'un compromis à mesure que la dimension diminue, et le choix entre 128 et 768 dimensions doit être mesuré en fonction de ses propres volumes de données, sans reprendre directement les arguments de la source. La source mentionne aussi une chaîne d'outils d'inférence et de déploiement couvrant transformers, sentence-transformers, MLX, vLLM, llama.cpp, SGLang, Ollama, LMStudio ainsi que transformers.js et WebGPU côté navigateur, et cite Qdrant pour le stockage vectoriel. Ces noms d'outils sont des options de déploiement listées par la source et ne signifient pas que cette plateforme les a intégrés ou validés pour ce modèle ; cette version n'a pas d'entrée correspondante exacte dans le catalogue en temps réel de KimiSeek, et le téléchargement des poids et les capacités de déploiement en périphérie mentionnés renvoient aux canaux des éditeurs comme DeepMind et Hugging Face, et non à une offre d'API de cette plateforme.
Intégration et évaluation
Recommandation 1 : déterminez d'abord si vous avez besoin d'embeddings multimodaux, puis si vous avez besoin du modèle complet. La source rapporte qu'en multimodal complet, environ 567 Mo de mémoire active sont nécessaires après quantification sur Pixel 11 Pro, contre environ 191 Mo pour le texte seul, et que les encodeurs visuel et audio sont des modules optionnels. Si votre corpus de recherche ne contient que du texte et du code, vous pouvez commencer par ne charger que la voie texte ; n'introduisez les encodeurs correspondants que si vous avez réellement des besoins de recherche audio-vidéo. Le critère d'évaluation opérationnel est le suivant : sur l'appareil cible ou la configuration serveur minimale acceptable, mesurez la latence de démarrage à froid, le pic de mémoire résidente et le débit d'embedding par seconde pour confirmer que le budget de latence reste respecté. Recommandation 2 : réalisez votre propre expérience de rappel sur les dimensions tronquées MRL, plutôt que d'adopter directement les 768 dimensions par défaut. La source mentionne trois paliers de 512, 256 et 128 dimensions et jusqu'à 6 fois d'économies de stockage, mais l'acceptabilité de la qualité de recherche dépend de votre corpus et de la distribution des requêtes. Le critère peut être : sur un ensemble de recherche annoté ou évalué manuellement, comparer les 768 dimensions aux 256 et 128 dimensions en termes de Recall@10 et de latence moyenne de requête, et n'adopter une dimension inférieure que si la baisse de qualité reste dans votre seuil métier. Recommandation 3 : si la recherche de code est votre scénario principal, considérez l'amélioration rapportée de MTEB Code comme un objet à reproduire. Le critère peut être : sur votre propre base de code, mesurer avec le même ensemble de requêtes le taux de correspondance et la performance de recherche interlingue d'EmbeddingGemma 1 et d'EmbeddingGemma 2, car les scores absolus des benchmarks publics ne remplacent pas une comparaison relative sur une base de code privée. Ces éléments sont des recommandations et analyses conditionnelles fondées sur les informations de la source, et non des faits établis par celle-ci.
Limites et points à confirmer
Il faut d'abord préciser qu'EmbeddingGemma 2 n'a pas d'entrée correspondante exacte dans le catalogue en temps réel de KimiSeek : cette plateforme ne propose pas ce modèle, et le téléchargement des poids et les capacités de déploiement en périphérie décrits par la source renvoient aux canaux des éditeurs comme DeepMind et Hugging Face, et non à une offre d'API de cette plateforme. Ensuite, les scores de benchmark de la source (notamment la progression de MTEB Code de 68,76 à 78,68 et l'affirmation de résultats de premier plan sous un milliard de paramètres) proviennent des déclarations de l'éditeur ; le blog ne détaille pas les conditions d'évaluation complètes, la liste des modèles comparés ni la version d'évaluation, et ils ne peuvent donc pas être considérés comme des résultats vérifiés indépendamment ; les performances réelles doivent être reproduites par vos soins. Troisièmement, les données de mémoire et de stockage fournies par la source (environ 191 Mo, environ 567 Mo, jusqu'à 6 fois d'économies) reposent sur un mode de quantification spécifique et sur l'appareil Google Pixel 11 Pro ; elles pourraient ne pas se vérifier sur d'autres matériels ou configurations de quantification. Quatrièmement, l'avantage de mémoire combinée que la source attribue au partage du tokenizer et de l'encodeur audio avec Gemma 4 n'est pas chiffré dans la source. Cinquièmement, la prise en charge par Gemini Enterprise Agent Platform Model Garden est indiquée comme « à venir » dans la source, ce qui relève d'une annonce planifiée et ne signifie pas qu'elle est actuellement disponible ; cette plateforme ne propose pas non plus d'accès API à ce modèle. Les prix et la disponibilité évoluent avec le temps ; les lecteurs doivent se référer aux pages de tarification et aux fiches de modèle actuelles de chaque éditeur.
Illustrations de l’article original
