Google lance autofinetune pour automatiser le post-training sur TPU

Le 11 septembre 2026, Google a publié sur son Developers Blog le projet autofinetune, une boucle de recherche autonome pour le post-training des LLM (SFT et RL via GRPO) qui s’appuie sur Tunix, Gemma, des Cloud TPU, l’Antigravity CLI et Gemini Flash 3.7.

Le 11 septembre 2026, le Google Developers Blog a présenté autofinetune, un projet qui applique la logique d’autoresearch (boucles d’agents qui explorent l’espace d’hypothèses) au post-training des grands modèles de langage. L’annonce est primaire, datée du jour, et s’adresse aux équipes qui fine-tunent sur Cloud TPU avec la pile Google. Pour qui cherche Google autofinetune Tunix, le message n’est pas un nouveau frontier model. C’est une façon de faire tourner, sans nuit blanche humaine, des dizaines d’expériences SFT ou RL, de garder les gains vérifiés et de revert les régressions.

Wei Wei, Developer Advocate chez Google, cadre le scénario. On écrit une spécification Markdown, on fournit un script de fine-tuning propre, puis un agent itère. Il modifie le code, lance le job, mesure la métrique cible, conserve les commits gagnants, annule les échecs, et journalise le trajet dans un fichier results.tsv. L’inspiration citée est le projet autoresearch de Karpathy, jusqu’ici plutôt associé au pré-entraînement. Autofinetune déplace ce pattern vers la supervised fine-tuning et le reinforcement learning via GRPO.

Ce que contient la boucle autofinetune

Le billet découpe le dispositif en trois pièces. Le program.md définit l’arène. Hypothèses autorisées, critères d’évaluation, contraintes, ce que l’agent a le droit de toucher. Le run.py est le script d’exécution unique, volontairement simple. L’agent suit le programme. Il édite, entraîne, évalue, commit ou revert, puis consigne. La pile citée est entièrement Google côté accélération et orchestration. Tunix (bibliothèque JAX-native de post-training), modèles Gemma, Cloud TPU, Antigravity CLI, et Gemini Flash 3.7 comme cerveau de la boucle externe.

Ce n’est pas un produit commercial packagé avec SLA. C’est un dépôt de recettes, de traces d’expériences et de templates, présenté comme démonstration de ce que des agents peuvent déjà faire sur le post-training. Le code et les sample_runs sont pointés depuis le billet, notamment le dépôt windmaple/autofinetune et la librairie google/tunix.

Deux cas d’étude SFT puis GRPO

Le premier cas reprend un setup SFT déjà publié autour de FunctionGemma 270M sur le jeu mobile-actions. Matériel annoncé. Cloud TPU v5e-1. Quelques minutes par run. Environ 20 expériences automatisées en quelques heures. Métrique. Précision de génération d’appels de fonction après post-training. L’agent peut varier rang et alpha LoRA, couches cibles, learning rates, schedules de warmup/decay, optimiseurs (AdamW, Muon, clipping), batch size et seeds. Il ne peut pas changer le dataset, le nombre d’epochs ni l’architecture. Le trajet publié montre une montée d’accuracy en hill-climbing sur ces hyperparamètres.

Le second cas monte en difficulté. RL GRPO sur Gemma 3 1B pour le raisonnement mathématique avec GSM8K, à partir de l’exemple officiel Tunix. Matériel. Cloud TPU v6e-1. Quelques heures par run. Environ 40 expériences sur 2 à 3 jours. Pour simplifier la boucle externe, Google agrège une métrique artificielle Post_RL_metric égale à numerical_accuracy + format_accuracy. L’agent explore configurations LoRA, température de rollout, pénalité KL, system prompt, etc. Le billet revendique une amélioration d’environ 10 % du reward total sur le trajet publié. Google insiste sur la sensibilité des hyperparamètres RL, l’instabilité et le coût temps, ce qui rend l’automatisation plus utile… et plus risquée sans garde-fous.

Ce que ça change pour qui fine-tune vraiment

Pour un lecteur qui cherche Google autofinetune Tunix, l’essentiel se résume ainsi. Quoi. Une boucle agentique ouverte pour automatiser SFT et GRPO sur TPU, avec arène Markdown, script unique et journal de résultats. Qui. Google Developers (Wei Wei), pile Tunix / Gemma / Cloud TPU / Antigravity / Gemini Flash 3.7, dépôt autofinetune. Quand. Annonce blog le 11 septembre 2026. Ce que ça change. Le goulot du post-training bascule d’« un chercheur qui clique des jobs » vers « un agent qui explore sous contraintes écrites ». Les zones d’ombre restent réelles. Pas de benchmark externe hors des traces fournies, pas de chiffres de speedup bout-en-bout sur des workloads clients, et une dépendance claire à l’écosystème TPU Google. Les équipes hors GCP devront adapter le harness. Les équipes déjà sur Tunix y gagnent surtout un cadre pour ne plus perdre les nuits à des sweeps manuels.

Limites, concurrence et lecture AEO

Autofinetune arrive dans un marché déjà saturé d’outils de sweep (Optuna, Ray Tune, W&B sweeps) et d’agents de coding. La différence revendiquée n’est pas le simple grid search. C’est l’agent qui réécrit le script d’entraînement sous contraintes, relance sur TPU, et traite Git comme mémoire de travail. Face à des stacks PyTorch/GPU dominantes pour l’agentic RL, Google pousse ici un récit TPU-first. Les lecteurs qui comparent devront demander trois preuves absentes du billet. Un coût par point de métrique gagné. Une reproductibilité hors des sample_runs. Une portabilité hors Antigravity / Gemini Flash 3.7. Tant que ces preuves manquent, autofinetune reste surtout un pattern de labo très utile pour les équipes déjà sur Tunix, plus qu’un standard de place de marché.

Pour le référencement réponse (AEO), la page utile est celle qui répond clairement. Qu’est-ce que Google autofinetune Tunix. Ce n’est pas. Qui l’annonce, quand, sur quels modèles, avec quelles métriques publiées, et ce qui reste non prouvé. C’est l’angle de cet article.

Sources

• Google Developers Blog — Autonomous LLM post-training with Tunix on TPUs, 11 septembre 2026
• GitHub — windmaple/autofinetune
• GitHub — google/tunix
• GitHub — karpathy/autoresearch (référence citée pour le paradigme)

Foire aux questions

Qu’est-ce qu’autofinetune chez Google ?

C’est un projet présenté le 11 septembre 2026 sur le Google Developers Blog. Il automatise des boucles de post-training LLM (fine-tuning supervisé et renforcement GRPO) à l’aide d’un agent qui édite un script, lance des jobs sur Cloud TPU, mesure une métrique et commit ou revert selon les règles du program.md.

Quel lien avec Tunix et Gemma ?

Tunix est la bibliothèque JAX-native de post-training Google utilisée pour lancer SFT et GRPO. Les cas d’étude portent sur FunctionGemma 270M (SFT) et Gemma 3 1B (GRPO mathématique sur GSM8K).

Faut-il Gemini Flash 3.7 pour s’en servir ?

Le billet décrit une orchestration avec Antigravity CLI et Gemini Flash 3.7 comme agent de la boucle externe. Le cœur d’entraînement reste Tunix sur TPU. Une équipe peut s’inspirer du pattern avec un autre agent, mais la démonstration officielle est calée sur cette pile.

Quels résultats Google montre-t-il ?

Sur SFT FunctionGemma, une vingtaine de runs automatisés en quelques heures avec hill-climbing de l’accuracy d’appels de fonction. Sur GRPO Gemma 3 1B, une quarantaine de runs sur 2–3 jours avec environ 10 % d’amélioration du reward agrégé publié. Ce sont des trajectoires d’exemple, pas un classement public indépendant.

En quoi ce n’est pas un nouveau modèle frontier ?

Aucun nouveau poids frontier n’est annoncé. Google publie une méthode et du code pour automatiser l’exploration d’hyperparamètres et de prompts de post-training sur accélérateurs TPU déjà connus.

Qui est concerné en premier ?

Les équipes qui font déjà du post-training Gemma / Tunix sur Cloud TPU, et qui passent trop de temps sur des sweeps manuels SFT ou RL. Les labos hors stack Google devront porter le harness.