Scaling Laws for Code: A More Data-Hungry Regime

## Lois de scaling pour le code : pourquoi Chinchilla ne suffit pas

### 1. Ce qui est mesuré et comment

L'étude couvre 117 runs d'entraînement, modèles de 0,2B à 3,8B paramètres, tokens de 2B à 128B — une grille systématique qui manquait jusqu'ici pour le code. Les auteurs ajustent deux lois de scaling : la loi de Chinchilla (2022, DeepMind), qui prédit la perte optimale en fonction du budget compute via L(N,D) = E + A/N^α + B/D^β, et la loi de Farseer, formulation plus expressive qui ajoute un terme d'interaction entre N et D. Sur l'ensemble des runs, Farseer obtient une meilleure précision prédictive que Chinchilla, ce qui n'est pas anodin : les décisions d'allocation compute pour les prochains modèles de code reposent directement sur ces fits.

### 2. Le ratio données/paramètres : l'écart central

La loi de Chinchilla prescrit, pour le langage naturel, un ratio optimal d'environ 20 tokens par paramètre (modèle de 70B → ~1,4T tokens). Les résultats de cette étude indiquent que le code exige un ratio substantiellement plus élevé. Les auteurs ne publient pas un chiffre unique normalisé, mais la direction est claire : à budget compute égal, un modèle de code optimal doit être entraîné sur davantage de données et avec un modèle plus petit que ce que Chinchilla recommanderait pour du texte.

Pourquoi ? Le code a une syntaxe stricte, une sémantique formelle, et une distribution de tokens très différente du texte naturel — les identifiants, les structures de contrôle, les appels de fonctions créent des dépendances longue portée que le modèle doit mémoriser avec précision, pas approximer. La redondance statistique exploitable par les lois NL est moindre : chaque token compte davantage.

Conséquence directe : les labs qui ont calibré leurs runs de code sur Chinchilla ont probablement sous-entraîné leurs modèles en données, même s'ils ont atteint le budget FLOPs cible. CodeLlama, StarCoder 2, DeepSeek-Coder — tous entraînés sur des corpus de 500B à 2T tokens — pourraient être repositionnés rétrospectivement comme sous-optimaux si le ratio correct est significativement au-dessus de 20 tokens/paramètre.

### 3. Mélanges code-NL : le piège du budget élevé

Les expériences sur les mélanges code + langage naturel produisent un résultat contre-intuitif mais actionnable. En régime resource-constrained (budget compute faible, peu de tokens disponibles), ajouter du NL au corpus d'entraînement améliore les performances sur les benchmarks de code. Le NL agit comme régularisateur, transfère des capacités de raisonnement général, compense la rareté des données code de qualité.

Mais à budget compute élevé, la relation s'inverse : le NL devient un frein. Le modèle aurait mieux fait de consommer davantage de tokens code purs. Ce résultat a des implications directes pour les décisions de curriculum des modèles actuels. Les modèles de la génération 7B–70B entraînés avec des mélanges code/NL à grande échelle (type Llama 3 avec fine-tuning code, ou Qwen2.5-Coder) opèrent probablement dans le régime où le NL pénalise — sauf si leur corpus code est suffisamment massif pour compenser.

### 4. Perdants potentiels et implications pratiques

**Les recettes Chinchilla appliquées au code** : toute organisation ayant dimensionné ses runs de code sur la loi Chinchilla standard a potentiellement mal alloué son compute. Le coût n'est pas nul — un modèle 1B entraîné sur 20B tokens quand il aurait fallu 60B+ tokens représente des FLOPs gaspillés ou une performance sous-optimale.

**Les benchmarks actuels** : si les modèles dominants sur HumanEval, MBPP, ou SWE-bench sont sous-entraînés en données selon cette nouvelle loi, les classements actuels reflètent un régime suboptimal généralisé — les écarts entre modèles pourraient se redistribuer significativement avec un entraînement recalibré.

**Les fournisseurs de données synthétiques** : la conclusion que le code est data-hungry renforce la demande de données code de haute qualité et de synthèse de code (type OSS-Instruct, Magicoder). Les pipelines de génération de données synthétiques pour le code deviennent encore plus stratégiques.

Limite à noter : l'étude plafonne à 3,8B paramètres. L'extrapolation à 70B ou 405B repose sur l'hypothèse que les lois fittées restent valides hors de la fenêtre d'observation — une hypothèse standard mais non vérifiée ici. Les résultats sont néanmoins suffisamment robustes pour orienter les décisions d'allocation à l'échelle des labs mid-size.