AI 訓練與開發工具
Google Releases autofinetune: An Agent That Automatically Searches SFT and GRPO Training Configurations on TPUs
autofinetune lets an agent modify Tunix training code according to a Markdown specification, run evaluations, and retain only Git commits that improve the target metric. Its initial experiments cover SFT for FunctionGemma and GRPO for Gemma 3 1B, but the workflow remains a small-scale, single-metric exploration.
Google's developer team has released `autofinetune`, turning LLM post-training—which traditionally requires repeated manual hyperparameter tuning—into a continuously running agent loop. Users first define the permitted hyperparameter changes, resource constraints, and evaluation objectives in `program.md`, then provide a single `run.py` file. Antigravity CLI and Gemini Flash 3.7 modify the code, launch Tunix jobs, read evaluation results, commit improved versions to Git, revert regressions, and record the trajectory in a TSV file.
In the first case study, FunctionGemma 270M was fine-tuned on a single Cloud TPU v5e. The agent ran 20 experiments within several hours and could adjust the LoRA rank, alpha, target projection layers, optimizer, learning rate, and batch size, but could not change the dataset, number of epochs, or model architecture. The second case used a TPU v6e, Gemma 3 1B, and GSM8K to run GRPO, searching over LoRA settings, rollout temperature, KL penalty, and the system prompt. According to Google, the custom aggregate metric improved by approximately 10% after around 40 experiments.
The technical value lies not in a new optimization algorithm, but in packaging the cycle of “form a hypothesis—modify code—run expensive training—measure—version control” into an auditable loop suitable for batch exploration of a clearly defined, bounded search space. Engineering teams should still note that the GRPO case directly adds numerical accuracy and format accuracy, which may cause the agent to overoptimize a proxy metric. The published material also covers only two models and two sample trajectories, with no comparisons against Bayesian optimization, Population Based Training, or manual tuning. The blog reports 40 experiments over two to three days, while the repository records 45 experiments over roughly four days, indicating that the experimental reporting still needs reconciliation. The repository also requires users to apply a TPU VM crash workaround and demonstrates bypassing permission confirmations. Before using real-world data and cloud accounts, teams should isolate credentials, restrict which files may be modified, cap the TPU budget, and revalidate the winning configuration against a held-out test set.