Cheatsheets — vue longue

Toutes les pages concaténées sur un seul document, pour un Ctrl-F direct.

Flow Matching

Apprendre un champ de vélocité qui transforme du bruit en données via une trajectoire continue, alternative plus rapide aux modèles de diffusion.

L'idée centrale

Au lieu d'ajouter puis retirer du bruit par étapes discrètes (diffusion), Flow Matching apprend le champ de vitesse v(x, t) qui pousse directement les points d'une distribution source p₀ (bruit gaussien) vers une distribution cible p₁ (données réelles).

ODE qui gouverne le flux

dx(t)/dt = v(x(t), t)

À l'inférence, on intègre cette ODE de t=0 à t=1 pour générer un échantillon.

Entraînement

Paires et interpolation

Pour chaque paire (x₀, x₁) où x₀ ~ N(0, I) et x₁ vient des données :

# Interpolation linéaire
x(t) = (1 - t) * x₀ + t * x₁

# Vélocité de référence (constante)
v_gt = x₁ - x₀

Loss de régression simple

import torch

def flow_matching_loss(model, x0, x1):
    t = torch.rand(x0.shape[0], 1)  # t ~ Uniform[0,1]
    x_t = (1 - t) * x0 + t * x1
    v_gt = x1 - x0
    v_pred = model(x_t, t)
    return ((v_pred - v_gt) ** 2).mean()

Pas de schedule de bruit, pas de KL : juste un MSE sur la vélocité.

Inférence (sampling)

Intégration ODE

from torchdiffeq import odeint

# x0 : bruit initial [batch, dim]
x0 = torch.randn(batch_size, dim)

# Résoudre dx/dt = v_θ(x, t)
def ode_func(t, x):
    return model(x, t)

t_span = torch.linspace(0, 1, steps=20)
trajectory = odeint(ode_func, x0, t_span, method='dopri5')
x1 = trajectory[-1]  # Échantillon final

Méthode d'Euler simple (10-50 steps suffisent souvent)

x = torch.randn(batch_size, dim)
dt = 1.0 / n_steps

for i in range(n_steps):
    t = i * dt
    v = model(x, torch.full((batch_size, 1), t))
    x = x + dt * v

Comparaison avec diffusion

Aspect	Diffusion	Flow Matching
Processus	Ajouter/retirer du bruit	Chemin direct via vélocité
Cible d'entraînement	Prédire le bruit `ε`	Prédire la vitesse `v`
Steps d'inférence	50-1000	10-50
Déterminisme	Peut être stochastique	Déterministe (ODE)
Loss	MSE + éventuellement KL	MSE simple

Robotique

Pourquoi Flow Matching pour les actions robot

Rapidité : 10-20 évaluations d'ODE suffisent pour du temps réel
Lissité : les trajectoires robotiques sont naturellement continues
Conditionnement : facile d'ajouter état actuel, but, obstacles

Exemple minimal

# v_θ conditionné sur l'état
class ConditionalFlowModel(nn.Module):
    def __init__(self, state_dim, action_dim, hidden=256):
        super().__init__()
        self.net = nn.Sequential(
            nn.Linear(action_dim + 1 + state_dim, hidden),
            nn.SiLU(),
            nn.Linear(hidden, hidden),
            nn.SiLU(),
            nn.Linear(hidden, action_dim)
        )
    
    def forward(self, x, t, state):
        inp = torch.cat([x, t, state], dim=-1)
        return self.net(inp)

# Génération d'action
state = get_robot_state()
x0 = torch.randn(1, action_dim)
action = odeint(lambda t, x: model(x, t, state), x0, t_span)[-1]

Flow vs gradient : ne pas confondre

Concept	Définition	Notation
Gradient	Direction de plus forte variation d'une fonction scalaire	`∇f(x)`
Flow (vélocité)	Comment un point se déplace dans l'espace-temps	`v(x, t)`

Un flow peut être un gradient (gradient flow : dx/dt = -∇f(x)), mais en Flow Matching le champ de vélocité est appris indépendamment.

Techniques liées

Continuous Normalizing Flows (CNF) : utilisent des ODE mais calculent des log-vraisemblances coûteuses (trace du Jacobien)
Rectified Flow : variante qui apprend des trajectoires plus droites via itérations successives
Score-Based Models : apprennent ∇ log p(x) au lieu de v(x, t), liés par v = -∇ log p

Quand l'utiliser

Flow Matching si :

✅ Inférence rapide critique (robotique, interactif)
✅ Données continues sur variétés lisses (trajectoires, mouvements)
✅ Besoin de déterminisme

Diffusion si :

Images (écosystème mature, modèles pré-entraînés)
Variation stochastique souhaitée
La vitesse d'inférence n'est pas bloquante

title: Flow Matching category: cheatsheets created: 2025-01-15 updated: 2025-01-15 tags: [flow-matching, generative-models, deep-learning, diffusion, ode, cnf, pytorch] confidence: high publish: true

Flow matching transforme une distribution simple (bruit gaussien) en distribution complexe (données) via un champ de vitesse déterministe, offrant la qualité de diffusion avec 7-100× moins d'étapes d'inférence et un entraînement plus simple.

L'idée centrale

On apprend un champ de vitesse v_θ(x, t) qui décrit comment transformer du bruit en données :

# ODE à intégrer de t=0 à t=1
dx_t/dt = v_θ(x_t, t)

À l'entraînement, on régresse directement ce champ de vitesse (MSE simple) au lieu de prédire du bruit comme en diffusion. Mathématiquement équivalent à la diffusion gaussienne, mais plus intuitif.

Conditional Flow Matching (CFM)

Le trick qui rend l'entraînement tractable : conditionner sur un point de données x₁.

import torch
import torch.nn as nn

def cfm_loss(model, x1, sigma_min=0.001):
    """
    x1: batch de données réelles, shape (B, D)
    """
    B, D = x1.shape
    
    # Échantillonner t uniformément
    t = torch.rand(B, 1, device=x1.device)
    
    # Chemin conditionnel gaussien
    mu_t = t * x1
    sigma_t = 1 - t + t * sigma_min
    
    # Échantillonner x_t sur le chemin
    x0 = torch.randn_like(x1)
    x_t = mu_t + sigma_t * x0
    
    # Vitesse conditionnelle (forme close)
    u_t = (x1 - (1 - sigma_min) * x0) / (1 - (1 - sigma_min) * t)
    
    # Prédire et comparer
    v_pred = model(x_t, t)
    loss = ((v_pred - u_t) ** 2).mean()
    
    return loss

Pas de calcul de posteriors. Pas d'intégration d'ODE à l'entraînement. Juste de la régression.

Optimal Transport coupling (OT-CFM)

Le gain le plus simple : matcher les paires bruit-données avec Sinkhorn au lieu de les coupler aléatoirement.

from torchdyn.core import NeuralODE
import ot  # POT library

def ot_cfm_loss(model, x1, reg=0.05):
    B = x1.shape[0]
    x0 = torch.randn_like(x1)
    
    # Matrice de coût L2
    C = torch.cdist(x0, x1) ** 2
    
    # Plan de transport optimal (Sinkhorn)
    pi = ot.sinkhorn(torch.ones(B)/B, torch.ones(B)/B, 
                     C.cpu().numpy(), reg)
    pi = torch.from_numpy(pi).to(x1.device)
    
    # Rééchantillonner x0 selon le plan
    indices = torch.multinomial(pi, 1).squeeze()
    x0_coupled = x0[indices]
    
    # CFM loss standard avec couplage OT
    t = torch.rand(B, 1, device=x1.device)
    x_t = t * x1 + (1 - t) * x0_coupled
    u_t = x1 - x0_coupled
    
    v_pred = model(x_t, t)
    return ((v_pred - u_t) ** 2).mean()

Réduit la variance, rend les chemins plus droits. Speedup 4.4× en pratique.

Sampling

Intégrer l'ODE avec n'importe quel solveur.

from torchdiffeq import odeint

def sample(model, batch_size, dim, steps=50, method='dopri5'):
    # Partir du bruit
    x0 = torch.randn(batch_size, dim)
    t_span = torch.linspace(0, 1, steps)
    
    # Définir l'ODE
    def ode_func(t, x):
        t_batch = t.expand(x.shape[0], 1)
        return model(x, t_batch)
    
    # Intégrer
    trajectory = odeint(ode_func, x0, t_span, method=method)
    return trajectory[-1]  # x_1

Solveurs courants :

Méthode	Steps typiques	Qualité
`euler`	50-100	Acceptable
`rk4`	20-50	Bon
`dopri5` (adaptatif)	10-30	Excellent

Équivalence avec diffusion

Flow matching et diffusion gaussienne sont mathématiquement identiques (DeepMind 2024).

Aspect	Diffusion	Flow Matching
Cible d'entraînement	Bruit ε	Vitesse v
Loss	MSE pondérée (SNR)	MSE simple
Trajectoire	Stochastique (SDE)	Déterministe (ODE)
Mental model	"Nettoyer le bruit"	"Suivre le flux"
Convergence	Baseline	4.4× plus rapide

Choisir flow matching pour :

Formulation plus simple
Chemins plus droits (moins d'étapes)
Optimal transport naturel
Contraintes géométriques (SE(3), SO(3))

Rectified Flow

Rendr les chemins encore plus droits via "reflow" : ré-entraîner le modèle sur ses propres générations.

def reflow(model, dataloader, epochs=10):
    """
    Génère (x0, x1) via le modèle actuel,
    puis ré-entraîne pour apprendre les chemins droits.
    """
    synthetic_pairs = []
    
    with torch.no_grad():
        for x1_real in dataloader:
            x0 = torch.randn_like(x1_real)
            x1_gen = sample(model, x0)  # via ODE
            synthetic_pairs.append((x0, x1_gen))
    
    # Ré-entraîner avec paires synthétiques
    for x0, x1 in synthetic_pairs:
        t = torch.rand(B, 1)
        x_t = t * x1 + (1 - t) * x0
        u_t = x1 - x0  # Vitesse droite
        loss = ((model(x_t, t) - u_t) ** 2).mean()
        # backward, step...

Après 1-2 reflows : génération en 1-5 étapes seulement.

Production : Stable Diffusion 3

SD3 utilise flow matching + DiT (Diffusion Transformer) :

# Architecture simplifiée
class FlowMatchingDiT(nn.Module):
    def __init__(self, dim=1024, depth=28, heads=16):
        self.pos_embed = ...
        self.blocks = nn.ModuleList([
            TransformerBlock(dim, heads) for _ in range(depth)
        ])
        self.final = nn.Linear(dim, dim)
    
    def forward(self, x, t, text_embed):
        # x: latents, t: timestep, text_embed: CLIP/T5
        h = self.pos_embed(x) + self.time_embed(t)
        
        for block in self.blocks:
            h = block(h, text_embed)  # cross-attention
        
        return self.final(h)  # prédire vitesse

Clés du succès :

Latent space (VAE 8× compression)
Classifier-free guidance (CFG)
OT coupling
50 steps d'inférence (vs 1000 pour DDPM initial)

TorchCFM

Librairie officielle de référence.

pip install torchdyn torchcfm

from torchcfm.conditional_flow_matching import (
    ConditionalFlowMatcher,
    TargetConditionalFlowMatcher,  # OT version
)

# Setup
fm = TargetConditionalFlowMatcher(sigma=0.0)  # sigma=0: chemins droits

# Training loop
for x1 in dataloader:
    x0 = torch.randn_like(x1)
    t, xt, ut = fm.sample_location_and_conditional_flow(x0, x1)
    
    vt = model(xt, t)
    loss = (vt - ut).pow(2).mean()
    
    optimizer.zero_grad()
    loss.backward()
    optimizer.step()

Cas d'usage

Où flow matching excelle :

Images : SD3, Flux.1 (12B params)
Vidéo : Pyramidal Flow (10s, 768p, 24fps)
Robotique : policies 50Hz, contraintes géométriques
Protéines : génération SE(3)-équivariante
Molécules : conformères 3D avec symétrie E(3)
Parole : synthèse haute fidélité

Limites actuelles :

Données discrètes (texte) : encore derrière l'autoregressif
Écosystème moins mature que diffusion
One-step generation : léger retard sur diffusion distillée

Diagnostic

# Vérifier la qualité du flow
def plot_trajectories(model, x1, steps=50):
    x0 = torch.randn_like(x1)
    t_span = torch.linspace(0, 1, steps)
    trajectory = []
    
    x = x0
    for i in range(len(t_span) - 1):
        dt = t_span[i+1] - t_span[i]
        v = model(x, t_span[i].expand(x.shape[0], 1))
        x = x + v * dt
        trajectory.append(x.clone())
    
    # Mesurer la courbure
    curvature = sum([
        torch.norm(trajectory[i+1] - 2*trajectory[i] + trajectory[i-1])
        for i in range(1, len(trajectory)-1)
    ])
    print(f"Courbure totale: {curvature:.4f}")  # Plus bas = mieux

Chemins droits = moins d'étapes nécessaires.

World Models

page dédiée →

Le terme « world model » désigne techniquement un modèle qui prédit comment l'état du monde évolue en réponse à des actions. En 2025-2026, le marché confond sous ce label quatre technologies distinctes avec des dynamiques et des menaces complètement différentes.

Les quatre catégories confondues

Catégorie	Définition	Exemples	Vraiment un world model ?
Learned world models	Réseau de neurones entraîné à prédire l'état futur en réponse à une action	DreamDojo, DreamZero (NVIDIA), V-JEPA 2-AC (AMI Labs), GAIA (Wayve)	Oui
Simulation analytique	Moteur physique déterministe (Newton, MuJoCo)	NVIDIA Isaac Sim + Newton, Genesis, MuJoCo	Non, c'est un simulateur
Génération 3D	Modèle génératif créant des environnements 3D statiques	Marble (World Labs), HunyuanWorld, Genie 3 (Google DeepMind)	Non, génère un instantané spatial
Génération vidéo	Diffusion générant des séquences vidéo 2D	Sora, Veo, Runway, Kling	Seulement si conditionné par actions

La confusion coûte des milliards : un investisseur qui entend « world model » investit dans un concept unifié alors que chaque catégorie a ses propres risques de commoditisation.

Learned world models : JEPA vs génératif

Thèse JEPA (AMI Labs, LeCun)

Prédire en pixels gaspille de la capacité sur du bruit (feuilles qui bougent, reflets). Mieux vaut prédire en représentation abstraite où seule la structure causale est capturée.

Forces : V-JEPA 2 atteint 77,3% sur Something-Something v2, SOTA en anticipation d'actions (Epic-Kitchens-100), représentations efficaces (VL-JEPA surpasse CLIP avec 50% de paramètres en moins).

Faiblesses :

Vitesse : V-JEPA 2-AC nécessite 16 secondes de planning MPC par action (800 candidats échantillonnés, 10 itérations). Vs 10,81 FPS pour DreamDojo.
Données : post-entraîné sur 62 heures de données robot (DROID) vs 44 711 heures de vidéo humaine pour DreamDojo. Désavantage de scaling structurel.
Contrôle : excellent en compréhension vidéo passive, s'effondre en contrôle robotique actif.

DreamZero/DreamDojo (NVIDIA GEAR)

World Action Model de 14B paramètres prédisant conjointement vidéo future et actions dans un seul forward pass.

Résultats : 2× la généralisation zero-shot des VLAs, 10,81 FPS après distillation (vs 16s/action pour JEPA), corrélation r=0.995 entre qualité de prédiction et performance de contrôle.

Leçon : les pixels ne sont pas du bruit pour le contrôle moteur. Texture = friction, reflet = angle, ombre = profondeur. L'information que JEPA jette est ce dont un robot a besoin.

EgoScale (NVIDIA)

Retargeting de vidéo humaine égocentrique vers robots. 20 854 heures de vidéo, +54% de performance, scaling log-linéaire (R²=0.9983). La courbe ne plafonne pas.

Implication : la vidéo humaine égocentrique est quasi-infinie. Le bottleneck n'est pas l'architecture du world model, c'est l'accès aux données et la qualité du pipeline de transfert.

Simulation analytique : le monopole brisé

Genesis : 105M$ levés sur la thèse « simulation trop lente, pas différentiable ». USP : moteur unifié, différentiable, 43M FPS.

Trois fronts d'érosion :

NVIDIA Newton rend Isaac Sim différentiable → USP absorbé
Learned world models apprennent la physique depuis la vidéo → contournent le problème
Résultats sim-to-real existants (DoorMan 83% vs 80% humain, VIRAL, Unitree parkour) prouvent que le bottleneck n'était pas la vitesse du moteur

La simulation analytique reste indispensable (safety-critical, RL haute fréquence, domain randomization), mais le monopole comme seul pipeline de données robotiques est brisé.

Génération 3D : marchés surestimés

Marble (World Labs) : 1B$ levé, 5B$ de valorisation.

Marché	Promesse	Réalité
Robotique	Génération de scènes d'entraînement	Nice-to-have. Cosmos Transfer fait déjà l'augmentation visuelle. EgoScale/DreamDojo exploitent directement la vidéo humaine.
VFX	Remplacement workflow 3D	Mid-tier migre vers vidéo gen pure (SeedDance, Veo). Haut de gamme : contrôle caméra déjà conditionnable dans la vidéo gen (SeedDance, Wan 2.1).
AEC	Architecture/construction	Hallucine de la géométrie. Pas de précision géométrique (murs pas exactement 3,20m). 60% du marché = rénovation → LiDAR iPhone/ARCore capture l'existant.

Commoditisation : HunyuanWorld (Tencent) open-source, 4 itérations en 7 mois. Genie 3 (Google DeepMind) en production. Blender intègre génération 3D native.

Survie : course contre la commoditisation. Si World Labs capture 20-30% du marché outils 3D en 2-3 ans, justifié par distribution (Autodesk), sinon avalé.

NVIDIA : le hedge ultime

NVIDIA maintient six approches parallèles sans en choisir une :

Isaac Sim + Newton (simulation différentiable)
DreamDojo, DreamZero (learned world models)
EgoScale (retargeting vidéo humaine)
Cosmos (génération synthétique)
GROOTDream (simulation procédurale)
Isaac GR00T N1.6 (contrôle humanoid)

Quand le plus gros acteur maintient six approches parallèles, le signal est clair : aucune couche n'est le goulot d'étranglement. NVIDIA traite chaque couche comme une commodité et construit l'orchestration.

Intégration verticale complète : GPU → training (DGX) → simulation (Omniverse) → inférence embarquée (Jetson/DRIVE). Les startups qui construisent une couche intermédiaire sont structurellement vulnérables.

Cas Wayve : le label qui cache l'actif

8,6B$ de valorisation, présenté comme « embodied AI + world models ».

Réalité :

Produit : modèle de conduite end-to-end (capteurs → décisions). C'est ça qui conduit en zero-shot dans 500+ villes.
GAIA : outil interne de simulation (diffusion latent 15B, génération scénarios synthétiques). Équivalent à Cosmos → commoditisable.
Moat réel : distribution (Uber, Nissan, Mercedes) + données de conduite depuis 2017.

Le label « world model » est du marketing de levée. Tesla fait du end-to-end sans ce label. XPeng/Huawei aussi à échelle massive en Chine.

Tableau de survie

Acteur	Levée	Menace principale	Survie dépend de
World Labs	$1B, $5B valo	Commoditisation open-source + vidéo gen	Vitesse de capture marché (2-3 ans)
AMI Labs	~€500M, €3B valo	DreamZero contredit thèse JEPA pour robotique	Pivot vers niche (industrie, surveillance)
Genesis	$105M	Newton + learned models	Pivot marché chinois ou acquisition
Wayve	$1.2B, $8.6B valo	N/A (vrai actif = distribution)	Déjà solide
Runway	$315M, $5.3B valo	Vidéo gen commoditisée	Exécution produit et UX

Biais révélés par l'IA

Claude (Anthropic) reproduit initialement le consensus VC :

Défend business case par réflexe (VFX, AEC, gaming)
Maintient exceptions (Wayve) sans examiner concrètement
Poids démesuré aux Turing Awards (Fei-Fei Li, LeCun)
Connaît chaque papier individuellement mais ne fait pas la synthèse des convergences

Si une IA entraînée sur toute la littérature ne fait pas spontanément cette synthèse, comment attendre des VCs qu'ils la fassent ? Herding effect (a16z investit → Fidelity suit), FOMO narratif, asymétrie d'expertise.

L'humanoïde : la seule forme généraliste

L'essai de Dandjinou (2026) défend une thèse radicale : la forme humanoïde n'est pas un choix anthropomorphique, c'est une convergence inévitable pour la robotique généraliste.

Les trois arguments fondateurs

Co-évolution infrastructure-morphologie : notre monde (portes à 90 cm, marches de 17 cm, outils) a été construit pour un corps bipède à deux bras. Modifier l'infrastructure coûte plus cher que d'adopter la morphologie.
Généralité > performance de pointe : un guépard court plus vite, mais l'humain court, nage, grimpe, manipule. La vraie métrique est la résilience dans l'imprévu, pas la performance en conditions contrôlées.
Le bottleneck était le logiciel : jusqu'en 2015, contrôler un humanoïde nécessitait de programmer chaque mouvement à la main (cinématique inverse). Le reinforcement learning, l'imitation learning et le sim-to-real ont effacé cette limite.

L'humanoïde augmenté

La forme est le point de départ, pas la limite. Un robot hérite de la morphologie sans hériter des contraintes biologiques :

Pas de fatigue musculaire → opération continue 24h/24
Degrés de liberté augmentés → articulations à 360°, hypermobilité systématique
Force et vitesse décuplées → actionneurs dépassant les limites biochimiques
Modularité : roues escamotables pour terrain plat, torse télescopique pour l'atteinte verticale, capteurs infrarouges pour l'obscurité

Les zones d'ombre des formes spécialisées

Chaque forme spécialisée (AGV, bras fixe, drone) excelle dans 80 % des cas et échoue structurellement dans les 20 % restants (obstacle imprévu, escalier, manipulation fine). Le coût total, incluant les interventions humaines pour couvrir ces zones d'ombre, dépasse celui d'une plateforme généraliste.

Pourquoi les critiques ont tort en 2026

Les objections classiques (instabilité posturale, complexité du contrôle, consommation énergétique) décrivent la robotique de 2015. Les robots comme Unitree G1 (< 20 k$) ou Atlas de Boston Dynamics exécutent des mouvements qui étaient impensables il y a cinq ans. Maintenir le scepticisme face aux données actuelles n'est pas de la rigueur, c'est de l'inertie cognitive.

Position de survie : la forme humanoïde devient la plateforme standard pour tout environnement humain non reconstruit. Les formes spécialisées survivent uniquement dans des infrastructures conçues de zéro pour elles (usines, entrepôts autonomes).

Le spectre VLM ↔ world model (janvier 2025)

Le débat n'est plus « LLM ou world model », mais où placer la prédiction dans la pile :

Position	Où prédit-on ?	Exemple	Trade-off
Language causality	Chaîne de causalité en texte	Alpamayo-R1 (NVIDIA)	Auditable, mais certains phénomènes physiques refusent d'être résumés
Latent grounding	Prédiction de représentations futures	FLARE + GR00T N1.5	Apprend depuis vidéo sans actions ; opaque
Joint video + action	Diffusion simultanée vidéo/action	UWM, UnifoLM	Un modèle, quatre modes (policy/forward/inverse/génération)
Planning via JEPA	Représentation abstraite pour MPC	V-JEPA 2	16 s/étape de planif. → pas un contrôleur 50 Hz
VL-JEPA	Prédiction d'embeddings texte	VL-JEPA (Meta)	2,85× moins de décodage ; perd l'open-ended text

Deux têtes : raisonnement + contrôle

Le pattern 2024–2025 répété (Pi0, Alpamayo, GR00T, WALL-OSS) :

Tête raisonnement : autorégressif, CoT, interprétable, lent (secondes)
Tête contrôle : flow matching, trajectoires continues, 50 Hz (20 ms)

Pourquoi ? Parce que raisonnement et contrôle ont des physiques différentes. Le VLM garde les priors sémantiques, mais n'écrase pas le contrôleur temps-réel.

# Schéma conceptuel Pi0
backbone = PaliGemma_3B()  # raisonnement
action_expert = FlowMatchingHead(300M)  # contrôle

# Génère 50 actions en une passe (73 ms, RTX GPU)
actions = action_expert(backbone_features, proprio, noise)

Le goulot autorégessif et flow matching

RT-2 (2023) discrétisait chaque angle en 256 bins, générait token par token → trop lent, manque de précision.

Flow matching (2024–2025) raffine tout le chunk d'actions en parallèle :

Pi0 : 50 actions/chunk, 50 Hz, 73 ms d'inférence
Alpamayo : trajectoires de conduite via diffusion
GR00T : DiT-based flow matching

Pipeline de données

Source	Technique	Gain
Simulation	Isaac GR00T → 100k+ trajectoires synthétiques	+40 % perf. (sim+real vs real seul)
Vidéo sans actions	FLARE latent future, UWM masked actions	+26 % (FLARE), 60 % → 80 % succès (1→10 démos)
Cross-embodiment	Open X-Embodiment + embodiment tokens	Transfert inter-robots

Runtime de sécurité (le layer manquant)

Un MMLM natif-action à 50 Hz n'est pas juste un modèle, c'est une pile :

Capteurs → Modèle → [Safety Runtime] → Moteurs
                      ↑
                      gate, constrain, verify, log, fallback

Le runtime doit être model-agnostic : chaque labo sort son modèle (GR00T, Pi0, V-JEPA), mais la couche qui empêche le bras de clipper le comptoir doit être commune.

Blueprint convergent 2026–2027

La trajectoire copie texte → image :

2023 : séparés (LLM + diffusion)
2024 : collés (LLM orchestre)
2025 : fusionnés (GPT-4o génère images nativement)
2026–2027 (prédiction) : action-native MMLM → même forward pass pour chat, image, et commandes moteur

Input	Output	Cas d'usage
Text	Text	Chat
Text + Image	Text	VQA
Text + Image	Image	Édition
Text + Image	Text + Action	Raisonner puis agir
Video + Text	Action	Contrôle robot 50 Hz

Ce qui reste dur

Garanties temps-réel : 20 ms/décision, toutes les décisions
Distribution shift : lumière, usure, objets hors-distribution
Vérification : la simulation a un reality gap, le monde réel est lent/cher/dangereux
Opacité des pannes : perception ? raisonnement ? exécution ? hardware ?

Falsifiable

La thèse 2025 : on ne remplace pas le VLM, on l'arme. Prédiction testable d'ici 2027 : les robots de production auront une tête VLM gelée (raisonnement) + une tête flow matching fine-tunée (contrôle) + un runtime de sécurité qui gate les deux.

Le spectre des world models : où placer la prédiction

La question n'est pas « LLM ou world model », mais où placer la prédiction. Trois espaces possibles :

Espace	Méthode	Exemple	Avantage	Limite
Langage	Raisonnement causal en texte	Alpamayo CoC	Auditable, interprétable	Certaines physiques refusent la verbalisation (déformables, fluides)
Latent	Prédire les états futurs compressés	FLARE, V-JEPA	Efficace, apprend sans labels d'action	Opaque
Pixel/Vidéo	Prédire les frames suivantes	UWM, Cosmos	Ancré visuellement	Coûteux

Le cinquième angle, souvent manqué : l'interface reasoning→control. WALL-OSS, Pi0.5, Alpamayo partagent une même forme architecturale, arrivée de plusieurs directions en 2024-2025.

Le bottleneck autorégressif et le shift vers flow matching

Pourquoi RT-2 a plafonné (2023) :

Discrétiser chaque angle en 256 bins → tokens 128 91 241 5 101 127
Générer séquentiellement, un token à la fois
Trois murs : vitesse (trop lent pour 50 Hz), résolution (manipulation fine impossible), multimodalité (un seul chemin, alors que plusieurs sont valides)

Flow matching résout les trois :

# Au lieu de
token → token → token → token  # séquentiel

# Flow matching fait
bruit_aléatoire → étape_1 → ... → étape_10 → trajectoire_complète
# parallèle sur toutes les dimensions, continu, multimodal naturel

Pi0 (Physical Intelligence, oct. 2024) : 3.3B params, 50 Hz via flow matching, 73 ms d'inférence pour un chunk de 50 actions. 5× plus rapide à entraîner qu'un VLA à diffusion. Plie du linge, monte des cartons.

Pattern émergent : reasoning head + control head

Tous les systèmes performants 2024-2025 ont convergé vers la même architecture à deux têtes :

┌─────────────────────────────────┐
│   Backbone VLM partagé          │  ← PaliGemma, Gemma, Eagle
│   (encode images + language)    │
└──────────┬──────────────────────┘
           ├─────────────┬─────────────┐
           ▼             ▼             |
  ┌────────────────┐  ┌──────────────┐ │
  │ Reasoning Head │  │ Control Head │ │
  │ autorégressif  │  │ flow matching│ │
  │ tokens         │  │ continu      │ │
  │ lent (s)       │  │ rapide (20ms)│ │
  └────────────────┘  └──────────────┘ │
       text              actions        │

Exemples :

Alpamayo-R1 (NVIDIA, oct. 2025) : Cosmos-Reason 10B + décodeur flow matching. Chain of Causation (700K traces) → trajectoires. 80K heures de conduite.
GR00T N1.5 (NVIDIA, juin 2025) : Eagle-2 1.34B + DiT flow matching. 2.2B params total, 63.9 ms/inférence (L40). FLARE ajoute des tokens de futur pour apprendre de vidéo humaine sans labels.
Pi0 : PaliGemma 3B + Action Expert 300M. 73 ms pour 50 actions.
Pi0.5 : ajoute planification langage explicite avant exécution.
WALL-OSS (sept. 2025) : traite le problème comme un mismatch objectif/interface, keep les priors VLM, control head diffusion/flow.

Pourquoi deux têtes : raisonnement et contrôle ont des physiques incompatibles. Ne pas forcer les actions à passer par next-token generation.

Unified World Models : prédire vidéo et action simultanément

UWM (Univ. Washington / Toyota, avril 2025) : une seule diffusion, timesteps indépendants par modalité.

t_video	t_action	Mode	Fonction
Bruité	Clean	Policy	actions depuis observations
Clean	Bruité	Forward Dynamics	futur depuis action
Bruité	Bruité	Inverse Dynamics	action depuis goal
Clean	—	Video Generator	prédire vidéo future

Quand on entraîne sur YouTube (pas de labels action), on bruite complètement t_action → le modèle apprend la dynamique visuelle. Ce savoir se transfère quand les actions arrivent.

UnifoLM-WMA-0 (Unitree, sept. 2025) : extension open-source, fine-tuné sur Open-X + datasets Unitree. Intégré au robot G1 (1.3 m, >1000 unités livrées).

V-JEPA 2 : apprendre la physique, puis planifier

V-JEPA 2 (Meta, juin 2025) : prédit des portions masquées de vidéo dans l'espace d'embeddings (pas pixels). Pré-entraîné sur VideoMix22M (>1M heures). Apprend gravité, permanence d'objets, trajectoires sans supervision.

Planification (variante action-conditionnée V-JEPA 2-AC) :

Encoder observation actuelle → z_now
Encoder image goal → z_goal
Imaginer plusieurs séquences d'actions → embeddings futurs prédits
Choisir la séquence dont l'embedding final est le plus proche de z_goal
Exécuter (ou juste le premier pas, puis replan)

Post-entraîné sur <62h de vidéo robot (DROID), zéro-shot sur bras Franka. 16 secondes par étape de planification (vs 4 min pour Cosmos). Parfait pour "pense puis agis", pas pour la boucle de contrôle à 50 Hz.

VL-JEPA : prédire des embeddings de texte, pas des tokens

VL-JEPA (Meta FAIR & HKUST, déc. 2025) : prédit l'embedding de la réponse, pas chaque token.

50 % moins de paramètres entraînables vs VLM génératifs équivalents
2.85× moins d'opérations de décodage (selective decoding)
1.6B params, performances comparables à des VLM plus gros sur VQA

Pour un robot : flux continu d'embeddings sémantiques. Décodeur texte invoqué seulement si besoin. Trade-off : moins de flexibilité générative ouverte, gain en vitesse et stabilité.

Le blueprint : MMLM action-natif

On a déjà vu ce film :

2023 : séparé (LLM écrit des prompts DALL-E)
2024 : collé (LLM orchestre diffusion, mais distincts)
2025 : fusionné (GPT-4o génère images nativement)
2026-2027 (mon pari) : action-natif. Le modèle qui chat et génère des images produit aussi des commandes moteur quand embodied.

┌────────────────────────────────────────┐
│      MMLM Action-Natif                 │
│  (texte, image, vidéo, actions)        │
└────────────┬───────────────────────────┘
             ├─ texte → texte (conversation)
             ├─ texte+image → texte (VQA)
             ├─ texte+image → image (édition)
             ├─ texte+image → texte+action (raison puis agit)
             └─ vidéo+texte → action (contrôle robot)

Données : simulation, vidéo sans actions, cross-embodiment

Le gap d'échelle : trillions de tokens texte, milliards d'images, milliers d'heures d'actions robot (×1M moins).

Trois approches :

Données synthétiques : NVIDIA Isaac GR00T Blueprint génère centaines de milliers de trajectoires à partir d'un petit seed de démos humaines. +40 % de perf en combinant synthétique et réel.
Vidéo sans actions : FLARE, UWM, V-JEPA 2 apprennent de YouTube, films, vidéo égocentrique humaine.
Transfert cross-embodiment : Open X-Embodiment agrège données de robots différents. Embodiment tokens disent au modèle quel robot il contrôle.

Runtime safety layer : l'interface manquante

Le problème d'interface : quand un MMLM action-natif produit 50 commandes/s vers un robot réel, on a besoin de :

Fusion de capteurs (caméras, proprio)
Monitoring de sécurité temps réel
Enforcement de contraintes (limites joints, évitement collisions, caps de force)
Dégradation gracieuse
Logs et audit
Gestion des tools/skills disponibles
Mémoire des interactions passées

Ce n'est pas un problème de modèle. C'est un problème de runtime/systèmes.

Exemple : le modèle génère une trajectoire parfaite — sauf que le coude clip le bord du comptoir à l'étape 17/50. Un runtime de sécurité n'évalue pas "l'intelligence", il enforce la physique.

Layer	Fonction	Pourquoi
Gate	Bloquer actions dangereuses avant exécution	Prévenir dégâts/blessures
Constrain	Limites physiques continues	Joint limits, collisions, forces
Verify	Simuler l'action optionnellement	Catcher erreurs en virtuel
Log	Enregistrer chaque action/résultat	Debug, responsabilité, amélioration
Fallback	Procédures de récupération sûres	Dégradation gracieuse

Doit être model-agnostic : le paysage est fragmenté (NVIDIA, Physical Intelligence, Meta, etc.). La couche de sécurité doit se placer entre n'importe quelle policy AI et n'importe quel hardware robot, comme les OS, Docker, ou les APIs cloud.

Ce que les autres ratent : c'est une question d'interfaces

Les gens débattent familles de modèles ("LLMs can't spatial reason", "world models are the future"). Les vraies questions sont d'interfaces :

Interface 1 : entre raisonnement et contrôle. Comment la planification langage se connecte à l'exécution moteur ? L'architecture à deux têtes est une réponse.

Interface 2 : entre policy et hardware. Comment garantir sécurité, auditabilité, agnosticisme matériel ? Le runtime safety layer.

Interface 3 : entre training et deployment. Comment combler le gap simulation→réel, multi-embodiment, action-free video → robot control ?

La convergence 2024-2025 n'est pas "quel modèle gagne". C'est : où placer la prédiction, comment séparer reasoning/control, et quelle couche système protège l'exécution.

The two-head pattern : reasoning + control

La plupart des VLA performants de 2024–2025 suivent la même architecture :

Reasoning head : autorégressif, génère du texte interprétable (chain-of-thought, planification)
Control head : flow matching, génère des trajectoires continues en parallèle, sortie 50 Hz

Les deux têtes partagent un backbone (VLM), mais se spécialisent :

Exigence	Reasoning	Control
Latence	secondes OK	<20 ms impératif
Format	tokens discrets	angles/forces continus
Interprétabilité	critique	accessoire
Sorties valides	une réponse	multiples trajectoires

Exemples :

Alpamayo-R1 : CoC language reasoning + flow matching trajectory decoder
GR00T N1.x : VLM Eagle-2 + DiT action expert
Pi0/Pi0.5 : PaliGemma 3B + 300M action expert (73 ms pour 50 actions @ 50 Hz)
WALL-OSS : diffusion control head pour éviter le goulot autorégressif

L'erreur RT-2 (2023) : forcer les actions dans des tokens discrets (256 bins/joint). Ça marche mal dès qu'on veut de la dextérité ou du réactif.

Runtime safety layer : l'interface manquante

Le passage à l'action-native MMLM ne demande pas seulement un meilleur modèle, mais une couche runtime entre modèle et moteurs :

Couche	Rôle
Gate	Bloquer les actions dangereuses avant exécution
Constrain	Limites articulaires, évitement collision, seuil de force
Verify	Simulation optionnelle pré-exécution
Log	Traçabilité (debug, responsabilité)
Fallback	Dégradation gracieuse en cas d'échec

Une erreur texte coûte une phrase. Une erreur moteur coûte du matériel ou blesse quelqu'un.

Ce runtime doit être model-agnostic : NVIDIA (GR00T, Alpamayo), Physical Intelligence (Pi0), Meta (V-JEPA) auront tous leurs modèles. La couche de sécurité doit s'intercaler entre n'importe quel policy et n'importe quel robot.

C'est le même pattern qu'un OS (apps ↔ hardware) ou Docker (apps ↔ infra).

Blueprint : action-native MMLM

La trajectoire suit celle de l'image :

2023 : LLM et diffusion séparés (GPT écrit des prompts pour DALL-E)
2024 : collés (DALL-E 3, Midjourney)
2025 : mergés (GPT-4o génère nativement des images)
2026–2027 : action-native (le modèle qui chat/génère des images sort aussi des commandes moteur quand il est embodié)

Input	Output	Usage
Texte	Texte	Conversation
Texte + Image	Texte	VQA
Texte + Image	Image	Édition
Texte + Image	Texte + Action	Raisonner puis agir
Vidéo + Texte	Action	Contrôle robot

Le modèle reste un MMLM. L'action devient une modalité de sortie first-class, au même titre que le texte ou l'image.

Données : trois leviers pour combler l'écart

Le texte se compte en trillions de tokens, l'image en milliards. Les actions robot ? Des milliers d'heures (×10⁶ moins).

Synthétique : Isaac GR00T Blueprint génère des centaines de milliers de trajectoires par randomisation de domaine à partir d'un seed set de démos humaines. +40 % de perf en combinant synthétique + réel.
Vidéo sans actions : apprendre de YouTube/vidéo égocentrique humaine
- FLARE : prédiction de futurs latents → +26 % en sim, 37,5 % → 60 % de succès avec 1 démo + vidéo humaine
- UWM : masquer les actions pendant l'entraînement
- V-JEPA 2 : 62 h de vidéo robot DROID non labellisées → zero-shot control
Cross-embodiment : Open X-Embodiment agrège des données de robots différents ; un token d'embodiment indique au modèle quel robot il contrôle.

Ce qui reste difficile : sécurité, évaluation, déploiement

Garanties temps réel : 50 Hz = 20 ms/décision, non négociable. Les VLM actuels tournent en centaines de ms. Flow matching aide, mais les garanties dures manquent.
Distribution shift : éclairage, objets, usure matérielle, humains imprévisibles.
Vérification : sim rapide mais reality gap ; tests réels lents/dangereux/coûteux ; vérification formelle intraitable.
Opacité des échecs : perception ? raisonnement ? exécution ? hardware ? Les modèles actuels ne séparent pas proprement ces modes.

Une mauvaise commande de couple casse un préhenseur. Une contrainte de collision ratée envoie un bras de 20 kg dans un poignet humain. C'est pourquoi la robotique avance moins vite que l'IA logicielle.

Flow Matching

L'idée centrale

Entraînement

Inférence (sampling)

Comparaison avec diffusion

Robotique

Flow vs gradient : ne pas confondre

Techniques liées

Quand l'utiliser

title: Flow Matching category: cheatsheets created: 2025-01-15 updated: 2025-01-15 tags: [flow-matching, generative-models, deep-learning, diffusion, ode, cnf, pytorch] confidence: high publish: true

L'idée centrale

Conditional Flow Matching (CFM)

Optimal Transport coupling (OT-CFM)

Sampling

Équivalence avec diffusion

Rectified Flow

Production : Stable Diffusion 3

TorchCFM

Cas d'usage

Diagnostic

See also

See also

World Models

Les quatre catégories confondues

Learned world models : JEPA vs génératif

Thèse JEPA (AMI Labs, LeCun)

DreamZero/DreamDojo (NVIDIA GEAR)

EgoScale (NVIDIA)

Simulation analytique : le monopole brisé

Génération 3D : marchés surestimés

NVIDIA : le hedge ultime

Cas Wayve : le label qui cache l'actif

Tableau de survie

Biais révélés par l'IA

L'humanoïde : la seule forme généraliste

Le spectre VLM ↔ world model (janvier 2025)

Deux têtes : raisonnement + contrôle

Le goulot autorégessif et flow matching

Pipeline de données

Runtime de sécurité (le layer manquant)

Blueprint convergent 2026–2027

Ce qui reste dur

Falsifiable

Le spectre des world models : où placer la prédiction

Le bottleneck autorégressif et le shift vers flow matching

Pattern émergent : reasoning head + control head

Unified World Models : prédire vidéo et action simultanément

V-JEPA 2 : apprendre la physique, puis planifier

VL-JEPA : prédire des embeddings de texte, pas des tokens

Le blueprint : MMLM action-natif

Données : simulation, vidéo sans actions, cross-embodiment

Runtime safety layer : l'interface manquante

Ce que les autres ratent : c'est une question d'interfaces

The two-head pattern : reasoning + control

Runtime safety layer : l'interface manquante

Blueprint : action-native MMLM

Données : trois leviers pour combler l'écart

Ce qui reste difficile : sécurité, évaluation, déploiement

See also