Google Cloud a fait entrer son service de distillation Gemini en phase de préversion. Ce service consiste à utiliser les réponses et le raisonnement d'un grand modèle pour en entraîner un plus petit, afin de réduire la latence et le coût des appels API. Pendant la période d'accès anticipé, il est impossible de choisir les modèles enseignant et élève : l'enseignant est figé sur gemini-3.1-pro, l'élève sur gemini-2.5-flash.
Les contraintes sont posées d'emblée. L'ID du projet doit d'abord figurer sur une liste d'autorisation ; la documentation invite l'utilisateur à contacter son représentant commercial Google pour en faire la demande. Les tâches de distillation doivent obligatoirement s'exécuter dans la région us-central1, sans autre option possible.
Des exigences très détaillées sur le jeu de données
Les données d'entraînement sont des ensembles de prompts au format JSONL stockés sur Cloud Storage. Dans chaque enregistrement, le champ contents est obligatoire et contient l'entrée côté utilisateur ; systemInstruction est facultatif et sert à définir le prompt système. Les conversations à plusieurs tours alternent entre user et model.
Côté volumétrie, la documentation recommande un minimum de 1 000 échantillons, avec un plafond strict de 50 000 ; le fichier JSONL source ne doit pas dépasser 1 Go ; l'entrée de chaque enregistrement est plafonnée à 8 000 tokens, et la sortie du modèle enseignant à 24 000 tokens. L'ensemble du service n'accepte que du texte brut, les entrées multimodales ne sont pas prises en charge.
Sur les prix et les quotas, la documentation ne dit rien du tout. Ce service relève actuellement de conditions préalables à la disponibilité générale (pré-GA), et Google lui-même précise qu'il n'est pas recommandé pour un usage en production.
Quatre étapes regroupées en une seule tâche
La distillation est une technique ancienne ; pour la mettre en œuvre auparavant, il fallait construire soi-même toute une chaîne : faire générer des réponses en masse par le modèle enseignant, les nettoyer et dédupliquer, utiliser ces données pour affiner (fine-tuning) le modèle élève, puis effectuer une phase d'évaluation. Chacune de ces quatre étapes exigeait d'écrire son propre code et de gérer soi-même sa puissance de calcul. Le service géré regroupe tout cela en une seule tâche : l'utilisateur n'a plus qu'à fournir son jeu de prompts.
Ce qui est gagné, c'est du temps d'ingénierie ; ce qui est perdu, c'est de la liberté de choix. L'enseignant comme l'élève sont tous deux verrouillés sur des modèles précis, ce qui signifie que l'utilisateur ne peut ni recourir à un enseignant plus onéreux pour améliorer la qualité, ni injecter le résultat dans un petit modèle à l'architecture personnalisée. La restriction à la région us-central1 fixe quant à elle directement l'emplacement où résident les données — pour les utilisateurs soumis à des exigences de conformité, ce point pèse davantage que la fonctionnalité elle-même.
Un même mot, deux traitements différents
Le mot « distillation » a pris, ces deux dernières années, une connotation compliquée dans les relations entre la Chine et les États-Unis. Trois agences américaines ont cette année désigné nommément six entreprises chinoises pour avoir distillé des modèles américains ; Anthropic a également évoqué, dans un rapport, des appels à grande échelle passés par des entreprises comme Alibaba. Dans ces contextes, la distillation a été traitée comme une pratique appelant une responsabilisation.
La différence tient aux conditions d'utilisation, pas au geste technique lui-même. Dans le service de Google, l'enseignant comme l'élève sont des modèles maison, l'utilisateur exécute son propre jeu de prompts, et le modèle élève qui en résulte sert le même compte, le tout dans le cadre autorisé. La distillation entre fournisseurs différents — utiliser la sortie de l'API d'une autre entreprise pour entraîner son propre modèle — est généralement explicitement interdite par les conditions de service. La même séquence d'opérations, dans le cadre de l'autorisation, est une fonctionnalité produit ; hors de ce cadre, c'est une rupture de contrat, voire une pièce à conviction pour un litige.
Pour les développeurs en Chine continentale, l'utilité pratique de ce service est proche de zéro. La liste d'autorisation impose de passer par les équipes commerciales, la région est verrouillée sur us-central1 : ces deux barrières cumulées excluent la plupart des projets basés en Chine. Ce qui reste exploitable, c'est l'ensemble de paramètres communiqué par Google : minimum 1 000, plafond de 50 000, entrée de 8 000 tokens — c'est le repère technique que Google donne lui-même à la question « combien de données faut-il pour une distillation », et les équipes menant des travaux similaires peuvent s'en servir comme étalon.
Les zones d'ombre de la préversion
Date de disponibilité générale (GA), tarification, plafonds de quotas : ces trois points manquent encore. La documentation ne précise pas non plus si la liste des modèles enseignant et élève sera étendue. Tant que ces informations ne sont pas complétées, ce service ressemble davantage à un canal de test interne ouvert aux grands clients déjà utilisateurs de Gemini Enterprise qu'à un outil que l'on peut d'ores et déjà intégrer à une feuille de route.
Sources : documentation officielle de Google Cloud, CocoLoop ; les versions des modèles enseignant et élève, la restriction de région, les champs du jeu de données et l'ensemble des plafonds ont été vérifiés ligne par ligne par rapport au document original.