Le modèle a la gloire, le substrat décide

On passe nos journées à parler de modèles. Lequel raisonne le mieux, lequel génère la plus belle vidéo, lequel coûte le moins cher au million de tokens.

Mais cette semaine, le pipeline de facturation de Cloudflare — des centaines de millions de dollars de revenus — a ralenti progressivement sans qu’aucune métrique habituelle ne bouge [3]. Le coupable n’était pas un modèle. C’était une structure invisible, sous la surface.

Et si le vrai sujet n’était jamais le modèle, mais ce sur quoi il repose ?

Le mot “modèle” cache trois choses différentes

Fei-Fei Li et l’équipe de World Labs posent un constat qui devrait nous rendre humbles : le monde n’est pas fait de mots [1]. Là où un modèle de langage apprend la structure statistique du texte, un world model apprend celle de l’espace et du temps : comment la lumière tombe sur une surface, comment un objet réagit à une force.

Le problème, c’est que “world model” est devenu l’un des termes les plus surchargés de l’IA. Vision, robotique, RL, génératif — chacun en revendique un, et chacun parle d’autre chose. L’article propose une taxonomie nette, héritée de la boucle agent → action → état → observation des POMDP : un renderer sort des pixels (la fidélité visuelle), un simulator sort un état physiquement fidèle (la structure), un planner sort des actions [1].

La leçon dépasse l’IA spatiale : tant qu’on ne sait pas précisément quelle couche on construit, on empile des malentendus. La précision sur le substrat n’est pas un détail académique — c’est la condition pour que le système tienne.

Calculer cher une fois, servir pas cher mille fois

Cette discipline du substrat, on la retrouve telle quelle dans un système de recommandation à grande échelle. Le problème classique : on veut des historiques comportementaux riches et du deep learning moderne, mais on a besoin d’une latence à la milliseconde pour scorer des millions d’utilisateurs sous contrainte de coût [2].

La réponse, dans la recherche d’emploi : un User Behavior Modeling qui apprend des longs historiques hors ligne avec de gros modèles de séquences, puis distille chaque utilisateur dans un embedding compact de taille fixe, servi via un feature store [2]. Le calcul lourd se fait une fois ; les petits modèles en production le consomment comme une simple feature dense. Résultat : des gains de plusieurs pourcents sur plusieurs surfaces, sans réécrire la chaîne de serving.

Le produit, ici, ce n’est pas le gros modèle. C’est la représentation qu’il laisse derrière lui. La structure, encore.

À l’échelle, ce que tu ne lis même pas peut te tuer

Retour à Cloudflare. Pour offrir une rétention par namespace, l’équipe change la clé de partitionnement de (day) à (namespace, day). Hypothèse raisonnable : comme chaque requête filtre sur un namespace, le nombre de parts lues par requête ne change pas — donc les perfs non plus [3].

Deux mois plus tard, les jobs de facturation s’effondrent. I/O, mémoire, parts lues : tout est normal. Jusqu’à ce qu’ils tracent la durée des requêtes contre le nombre total de parts dans le cluster. Corrélation indéniable [3]. Des parts qu’on ne lit même pas coûtaient cher par leur simple existence, à cause d’un verrou interne profondément enfoui. L’abstraction cachait un coût global que personne ne mesurait.

Le bon paramètre d’hier est le piège de demain

Le même piège, en plus sournois : les réglages qui pourrissent avec la croissance.

Chez WMG, un chunk TimescaleDB de 30 jours qui allait très bien quand la table était petite a fini par tuer le job de compression — devenu trop gros pour finir en une passe [7]. La recommandation officielle — le chunk actif doit tenir dans ~25 % de la mémoire — est une cible mobile : à débit d’ingestion croissant, le même intervalle de temps représente toujours plus d’octets.

“A 30-day chunk that was fine a year ago can be a problem today.”

Même histoire chez Netflix, à l’autre échelle. Sur Cassandra, les wide partitions de leur abstraction TimeSeries finissent par provoquer des latences en secondes, des pauses GC et des timeouts — d’où un système de repartitionnement dynamique qui réajuste la stratégie au lieu d’empiler des serveurs [4]. “Smarter alternatives than just throwing more money at the problem”, écrivent-ils. La structure d’hier n’est pas un acquis ; c’est une dette qui mûrit.

La vraie question n’est pas l’outil, mais où vit la complexité

Jack Vanlightly le formule mieux que personne sur les share groups Kafka : le parallélisme doit être comptabilisé quelque part [5]. Soit l’unité de parallélisme est visible du broker (un consumer, une connexion TCP, de l’état de protocole), soit elle est locale au client (un thread virtuel, une tâche async, invisible du broker). Traiter 60 000 messages/s avec une seconde de traitement chacun, ça fait 60 000 consumers… ou 60, selon où tu mets la complexité.

“You most definitely can hold share groups wrong. Don’t just rely on the defaults.”

Et quand cette complexité reste implicite, on la paie en opérabilité. C’est exactement le moteur de la migration d’un orchestrateur monolithique en Clojure vers Apache Airflow : non pas des fonctionnalités d’ordonnancement plus riches, mais rendre la structure lisible et explicite — des DAGs Python où les dépendances sautent aux yeux, l’isolation des pannes, la possibilité de relancer une seule étape [6]. Le gain n’est pas dans l’outil. Il est dans le fait de sortir la complexité de l’ombre.

La prochaine fois qu’un système ralentit sans raison apparente, la vraie question n’est peut-être pas “quel modèle, quel outil ?” mais “quelle structure ai-je cessé de regarder ?”

---

Sources

1. A Functional Taxonomy of World Models
2. Distilling Long-Tail User Behavior into Scalable Embeddings for Job Search
3. Our billing pipeline was suddenly slow. The culprit was a hidden bottleneck in ClickHouse
4. Dynamic Repartitioning for Time Series Workloads
5. Broker-Visible vs Client-Local Parallelism — Jack Vanlightly
6. Migrating from a Monolithic Orchestrator to Apache Airflow
7. Why we shrank our TimescaleDB chunks from 30 days to 7

Pour aller plus loin

• Modernizing Your Data Platform for the Age of AI | Free Guide from Dagster — le guide qui relie justement ces fondations data au passage à l’échelle des usages IA.
• Kafka Share Groups and Parallelizing Consumption — Part 1 — pour creuser le “vous tenez vos share groups dans le mauvais sens” avant le billet sur le parallélisme.
• From Words to Worlds: Spatial Intelligence is AI’s Next Frontier — l’essai fondateur de Fei-Fei Li qui pose pourquoi l’IA spatiale est la prochaine frontière.

Cet article a été rédigé en m’appuyant sur une IA pour m’aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.