Le seuil de délégation
Vous pouvez maintenant lancer un job de trois heures sur un problème complexe, et continuer à travailler sur autre chose pendant qu'il tourne.
C'est l’avenir de nos usages qui devient économiquement viable avec l'architecture NVL72.
La différence entre conversation et délégation devient mesurable.
La conversation, c'est une requête: quelques secondes de compute, puis on libère les ressources.
La délégation, c'est un job: des minutes ou des heures de travail parallélisé sur votre problème, avec un budget prévisible.
Cet article explique pourquoi, une fois le modèle capable, cette distinction dépend d'abord de l'infrastructure: c'est elle qui fixe le plancher de variance pour les phases couplées.
Le problème de la prévisibilité
Si vous lancez 10 tâches et que chacune prend "entre 1 et 2 heures", vous pouvez planifier votre journée. Si chacune prend "généralement 1 heure mais parfois 10 heures", vous ne pouvez pas. Même si la moyenne est acceptable, c'est le pire cas qui vous bloque.
Pour mesurer cette prévisibilité, on utilise deux chiffres:
Le temps médian (p50): la durée en dessous de laquelle la moitié des tâches se terminent. Si votre p50 est de 1 heure, cela signifie que la moitié de vos tâches finissent en moins d'une heure.
Le temps au 99ème percentile (p99): la durée en dessous de laquelle 99% des tâches se terminent. C'est le "pire cas raisonnable", celui que vous devez prévoir dans votre planning. Si votre p99 est de 2 heures, cela signifie que 99 tâches sur 100 finissent en moins de 2 heures.
Le ratio entre ces deux chiffres vous dit si votre système est prévisible. Si p99 = 2x p50, votre pire cas est deux fois plus long que votre cas typique. C'est gérable. Si p99 = 10x p50, votre pire cas est dix fois plus long. C'est ingérable. Vous ne pouvez pas planifier, parce qu'une tâche sur cent va bloquer vos ressources dix fois plus longtemps que prévu.
C'est pour cela que le débit vend des GPU, mais que la prédictibilité rend la délégation possible.
Deux configurations
NVIDIA propose maintenant deux architectures pour ses plateformes les plus récentes.
La première est le HGX NVL8, un serveur 8-GPU NVLink. Huit GPU par serveur, compatibles avec les déploiements x86 traditionnels. Dans cette configuration, les 8 GPU communiquent vite entre eux via NVLink. Au-delà de 8, vous passez par InfiniBand ou Ethernet. On peut scaler au-delà de 8 par ces voies et obtenir de bons résultats, mais ce n'est plus le même régime de latence et de variabilité qu'un domaine NVLink rack-scale.
La seconde est le GB200 NVL72, basé sur l'architecture Blackwell. Soixante-douze GPU par rack, conçu comme un domaine NVLink cohérent, un fabric (maillage) all-to-all rack-scale à latence et bande passante plus uniformes que le réseau du datacenter.
Les 72 GPU forment un seul domaine NVLink, ce que NVIDIA présente comme "un seul accélérateur massif": 130 TB/s au niveau du NVLink Switch System intra-rack, et 1,8 TB/s de lien NVLink par GPU, sans traverser le réseau datacenter. Sur le GB200 NVL72, la mémoire agrégée est de l'ordre de 13 TB de HBM3E et 17 TB de LPDDR5X. (Les chiffres varient selon la génération et la configuration; c'est l'ordre de grandeur qui compte.)
C'est un facteur 9 sur la taille du domaine scale-up.
Pourquoi ça compte
Les modèles MoE routent dynamiquement les tokens vers différents experts. Ces experts peuvent résider sur des GPU différents. Si les GPU sont dans le même domaine NVLink, le routage est rapide. S'ils sont séparés par le réseau du datacenter, chaque dispatch paie le coût d'un aller-retour avec une latence plus variable.
Avec un NVL8, dès que votre modèle dépasse ce que 8 GPU peuvent tenir, vous payez ce coût. Avec un NVL72, vous avez 9x plus de marge. Ce n'est pas une amélioration incrémentale. C'est un changement dans l'espace des modèles qu'on peut servir efficacement.
Les modèles de raisonnement illustrent bien ce point. Ils génèrent de longues traces de tokens intermédiaires. Plus le contexte s'allonge, plus l'état par session grossit. Avec un NVL72, la mémoire agrégée permet de maintenir cet état dans le domaine cohérent, plutôt que de le déporter sur le réseau.
Le fait architectural est un domaine all-to-all de 72 GPU avec des caractéristiques intra-rack prédictibles. La conséquence économique est une inférence long-horizon moins chère et plus planifiable.
De la conversation à la délégation
Le NVL72 n'est pas qu'une amélioration de performance. C'est l'infrastructure qui rend possible un nouveau mode d'usage.
Aujourd'hui, l'interaction avec un modèle est conversationnelle. Vous posez une question. Vous attendez la réponse. Le modèle mobilise des ressources pendant quelques secondes, puis les libère. L'échange est synchrone.
Avec le test-time scaling et des domaines cohérents de 72 GPU, un autre mode devient viable. Vous assignez une tâche complexe à une instance. Elle travaille pendant des minutes ou des heures sur votre problème. Pendant ce temps, une autre instance vous assiste sur vos tâches courantes. C'est la délégation. La conversation est une requête. La délégation est un job.
Autrement dit: la délégation, c'est de l'inférence asynchrone, budgétée, multi-trajectoires avec état persistant, planifiée comme du calcul par lots plutôt que servie comme un appel distant interactif.
Pourquoi la variance tue la délégation
Imaginez que vous faites tourner 100 tâches longues en parallèle sur un système chargé à 80%.
Si chaque tâche a une durée prévisible (p99 proche de p50), les tâches se terminent à peu près quand prévu. Vous pouvez en lancer d'autres, planifier vos ressources, tenir vos engagements.
Si chaque tâche a une durée imprévisible (p99 = 10× p50), quelques tâches vont "exploser" en durée. Ces tâches bloquent les ressources. Les autres tâches s'accumulent dans la file d'attente. Le système entier ralentit. Plus vous êtes proche de la saturation, plus ce phénomène s'amplifie.
Le NVL72 attaque une source majeure de cette variance: les allers-retours réseau entre nœuds pendant les phases où tous les GPU doivent se synchroniser. Le gain porte principalement sur les phases couplées (synchronisation collective, dispatch d'experts, opérations all-to-all) où la gigue réseau domine autrement le p99. Quand ces communications passent par le réseau du datacenter, leur durée varie. Quand elles restent dans le domaine NVLink, leur durée est uniforme.
Le NVL72 ne touche pas aux autres sources de variance: l'admission des requêtes, la pression sur le cache KV, ou la latence des appels à des outils externes. Mais il retire la composante réseau de l'équation.
Le budget d'une tâche
Le coût d'une tâche se résume à:
(tokens générés) × (coût par token) + (coût d'opportunité de la latence)
Le NVL72 change les deux termes. Le coût par token baisse, et la latence devient plus prédictible. Prédictible signifie que vous pouvez budgéter, planifier, et exécuter de nombreux jobs longs sans que le pire cas détruise le débit.
Pour rendre ça concret: imaginez un workflow qui explore 200 branches d'un plan, exécute des appels d'outils sur chaque branche, maintient un contexte de 32k à 128k tokens, et fait tourner des boucles de vérification. Avec un coût par token élevé et une latence variable, ce workflow est économiquement non viable. Avec un domaine NVLink cohérent et un coût par token réduit d'un ordre de grandeur, il devient une opération de routine.
Ces datacenters deviennent des usines à tokens. Un rack NVL72 peut être mobilisé pour une tâche, ou planifié et découpé en plusieurs jobs via l'orchestration. La parallélisation ne porte plus seulement sur le modèle, mais sur les usages eux-mêmes.
Ce que l'infrastructure locale ne peut pas faire
On peut émuler certains aspects de la délégation sur machine locale, mais on atteint rarement le régime haute-concurrence à latence prédictible, où la délégation devient économiquement viable comme mode par défaut.
Ce n'est pas une question de modèle open-weights contre closed-source. Un modèle open-weights peut déléguer si vous l'exécutez sur une infrastructure de classe NVL72 louée. Ce qui compte, c'est l'accès à du compute massif, concurrent et orchestré. Le matériel local, mono-utilisateur, atteint rarement ce régime à coût comparable.
La chaîne de dépendance
Cette asymétrie se prolonge en amont.
Les scaling laws (lois d’échelle) créent une dépendance structurelle. La qualité d'un modèle dépend de sa taille. La taille dépend du compute d'entraînement. Le compute d'entraînement dépend de clusters à l'échelle du gigawatt. Ces clusters n'existent que chez les hyperscalers.
Le schéma est simple: l'hyperscaler entraîne sur un cluster de classe gigawatt, puis distille vers un modèle utilisable que vous pouvez exécuter localement. L'artisan traditionnel peut surpasser l'usine sur la qualité. Ici, la qualité est l'échelle. La dépendance va dans un seul sens.
Ce que vous pouvez faire localement, c'est l'orchestration applicative, le fine-tuning sur vos données, et les choix d'intégration. Ce que vous ne pouvez pas faire localement, c'est produire le modèle source ou accéder au régime de délégation parallèle.
Espérer une percée architecturale qui change les scaling laws, c'est parier sur un miracle. Ce n'est pas une stratégie.
Le calendrier
Les datacenters de classe frontier consomment des gigawatts. Selon Epoch AI, 5 datacenters atteindront 1 GW de puissance courant 2026: Anthropic-Amazon, xAI Colossus 2, Microsoft Fayetteville, Meta Prometheus, et OpenAI Stargate Abilene. Le temps de construction pour atteindre cette échelle varie de 1 à 3,6 ans selon le site.
On ne construit pas un datacenter de 1 GW en continu. On le construit par phases. D'abord le permis, puis le raccordement, ensuite la construction, puis la stabilisation. Entre deux phases, la capacité disponible stagne. C'est ce qui ressemble à un plateau vu de l'extérieur.
En ce moment, nous sommes dans cet entre-deux. Puis la marche suivante arrive.
D'après les communications NVIDIA, Vera Rubin NVL72 (second semestre 2026) change de régime. NVLink 6 à 3,6 TB/s par GPU, jusqu'à 260 TB/s par rack. 288 GB de HBM4 par GPU contre 192 GB de HBM3e sur Blackwell. 22 TB/s de bande passante mémoire contre 8 TB/s.
NVIDIA annonce jusqu'à 10x de réduction du coût par token en inférence. Ces chiffres sont des projections. Le fait architectural stable est le domaine NVLink all-to-all de 72 GPU.
Quand le coût par token baisse d'un ordre de grandeur, des usages qui n'étaient pas viables le deviennent. Les modèles de raisonnement long et le test-time scaling, qui génèrent des millions de tokens par session, entrent dans cette catégorie.
L'incertitude qui reste
Est-ce que le Reinforcement Learning à grande échelle fait émerger des capacités de raisonnement qui généralisent au-delà des distributions d'entraînement?
Les résultats récents suggèrent que oui, du moins partiellement.
OpenAI affirme explicitement que la performance de o1 s'améliore avec plus de RL au train-time et plus de temps passé à "réfléchir" au test-time.
Le papier DeepSeek-R1 montre que le RL produit des schémas de raisonnement comme l'auto-vérification et la réflexion sur des tâches vérifiables.
L'annonce de o3 ou GPT-5-Thinking par OpenAI confirme que les "reasoning models" sont une ligne de produit distincte, pas un cas isolé.
Ce sont des affirmations publiées, pas seulement des interprétations externes. Mais la question de jusqu'où ça généralise reste ouverte.
On sait que l'infrastructure est construite sur l'hypothèse que ça scale. C'est un pari de marché, pas une certitude technique. Des centaines de milliards de dollars sont engagés dans des datacenters conçus pour des runs d'entraînement à l'échelle du gigawatt.
Si le pari tient, les modèles de 2027-2028 ne seront pas des versions marginalement améliorées des modèles actuels. Ils opéreront dans un régime différent. Raisonnement long. Décomposition de problèmes complexes. Exploration plutôt que reconnaissance.
Si le pari ne tient pas, il restera l'infrastructure. Qui servira d'autres usages. Mais pas ceux qui justifient les valorisations actuelles.
Ce qu'il faut retenir
L'unité de conception a changé. Les modèles frontier sont conçus pour des domaines scale-up de 72 GPU. Une infrastructure dimensionnée pour des serveurs 8-GPU ne bénéficie pas des mêmes propriétés et ne fournira pas les mêmes usages.
Le mode d'usage change. Le NVL72 permet la délégation, c'est-à-dire des tâches longues qui tournent en parallèle pendant que vous faites autre chose. Il rend économiquement plausible un mode de délégation pour certaines classes de charges de travail, parce qu'il attaque la variance.
La dépendance est structurelle. Les scaling laws impliquent que les modèles de qualité sont produits par ceux qui ont le compute. Le reste opère en aval.
La capacité arrive par marches. Ce qui ressemble à un plateau est souvent un palier d'offre entre deux déploiements. Le calendrier est contraint par la logistique. Vera Rubin au second semestre 2026. Des nouveaux modèles fin 2026 ou début 2027 liés au déploiement de GB200 NVL72. Ce ne sont pas des prédictions. Ce sont des délais de fabrication.
Et les propriétés du système dépendent de l'architecture. 72 GPU dans un domaine NVLink cohérent, ce n'est pas 9 serveurs de 8 GPU connectés par le réseau.
Sources: NVIDIA GB200 NVL72 Specs, NVIDIA GB300 NVL72 Specs, NVIDIA Vera Rubin Technical Blog, OpenAI o1 System Card, DeepSeek-R1 Paper, Epoch AI Frontier Data Centers Hub