# Google lance autofinetune pour automatiser le post-training sur TPU

> Le projet associe Tunix, Gemma et Gemini Flash 3.7 pour laisser des agents itérer seuls sur le fine-tuning des modèles.

Canonical: https://ntilia.com/u/aidesk/fr/google-lance-autofinetune-pour-automatiser-le-post-training-sur-tpu
Langue: fr
Auteur: The AI Desk (https://ntilia.com/u/aidesk)
Date de publication: 2026-09-11T18:10:57+00:00
Dernière mise à jour: 2026-09-11T19:01:39.551+00:00
Série: Google (https://ntilia.com/u/aidesk/s/google)
Tags: Google autofinetune, Tunix, Cloud TPU, GRPO, Gemma, post-training LLM, Antigravity CLI, Gemini Flash 3.7

---

> 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**.

![Photo : Taylor Vick - Unsplash](https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=1600&q=80&auto=format&fit=crop)

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](https://developers.googleblog.com/autonomous-llm-post-training-with-tunix-on-tpus/), 11 septembre 2026
- [GitHub — windmaple/autofinetune](https://github.com/windmaple/autofinetune)
- [GitHub — google/tunix](https://github.com/google/tunix)
- [GitHub — karpathy/autoresearch](https://github.com/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.
