NVIDIA Alpamayo 2 Super : un seuil d'acceptation pour les modèles enseignants de conduite autonome

Si un modèle peut produire une trajectoire plausible, expliquer la scène et étiqueter les acteurs proches, la question difficile n'est pas de savoir s'il paraît intelligent. Elle est de savoir si les preuves sont assez solides pour laisser cette sortie toucher à la génération de données, à l'étiquetage, à la distillation ou à l'évaluation. C'est là qu'un seuil d'acceptation NVIDIA Alpamayo 2 Super justifie son utilité.

NVIDIA Alpamayo 2 Super se situe dans une partie sensible de la pile de conduite autonome. NVIDIA le décrit comme un modèle ouvert de raisonnement vision-langage-action de 34 milliards de paramètres pour le développement de véhicules autonomes, combinant un Cosmos 3 Super Reasoner de 32 milliards de paramètres avec un Action Expert fondé sur la diffusion. L'article technique de NVIDIA décrit l'expert d'action comme ayant 2 milliards de paramètres, tandis que la fiche du modèle Hugging Face le décrit comme ayant 2,3 milliards de paramètres. Les équipes doivent donc consigner la source et la révision d'artefact sur lesquelles elles s'appuient. L'article officiel indique qu'il peut utiliser une vidéo multicaméra, un contexte linguistique et l'historique des mouvements précédents pour produire des trajectoires futures, des traces de raisonnement Chain-of-Causation, des méta-actions de haut niveau, des réponses sur la scène et des auto-étiquettes de raisonnement. Utile, oui. Fiable par défaut, non.

Le point de vue impopulaire est que la publication du modèle compte moins que le processus d'acceptation qui l'entoure. Un modèle enseignant fluide peut faire échouer plus vite des pipelines de données faibles. Cet article définit le seuil d'acceptation Optijara pour modèles de conduite autonome, une méthode pratique pour décider si Alpamayo 2 Super a sa place dans un flux de modèle enseignant, une file d'auto-étiquetage, un système de proposition de trajectoires, un flux de simulateur, un carnet de recherche ou une catégorie bloquée. Ce n'est pas un récapitulatif de lancement de robotaxi, et il ne traite pas les affirmations d'un fournisseur comme des preuves de production. La même discipline s'applique aux autres modèles à fortes capacités qui entrent dans des flux opérationnels, y compris les modèles d'acceptation abordés dans l'évaluation de l'infrastructure IA et les tests d'acceptation de la recherche IA ancrée.

Ce qu'est Alpamayo 2 Super, et ce qu'il n'est pas

Rôle du modèle : enseignant, moteur de données et générateur de preuves

Alpamayo 2 Super doit d'abord être évalué comme modèle enseignant hors ligne et modèle de moteur de données, pas comme politique de conduite par défaut. NVIDIA indique qu'il peut générer des trajectoires et des traces Chain-of-Causation, prédire des méta-actions comme céder le passage ou changer de voie, répondre à des questions sur la scène et créer des auto-étiquettes CoC avec ancrage 2D. Cela indique des usages pratiques dans l'enrichissement de jeux de données, l'analyse d'échecs, la distillation de politiques, l'extraction de scénarios et le soutien à l'évaluation.

La nuance compte. Un modèle enseignant peut proposer des étiquettes, des trajectoires ou des explications qui aident une équipe à inspecter les données plus vite. Il peut aussi se tromper avec assurance. Une trace de raisonnement peut exposer des preuves, mais ce n'est pas une preuve en soi. Une trajectoire peut sembler fluide tout en échouant à un contrôle de repère de coordonnées, à un changement de scène contrefactuel ou à une simulation en boucle fermée.

Pourquoi l'ouverture à l'usage commercial ne signifie pas une préparation à la production

L'article de NVIDIA indique que le modèle est publié sous OpenMDW-1.1 et décrit des autorisations de redistribution commerciale et de modèles dérivés. Le texte de la licence OpenMDW-1.1 accorde l'autorisation de traiter les matériaux du modèle sans restriction sous réserve de conformité, exige de conserver les avis de licence et d'origine lors de la distribution de matériaux du modèle, indique que les sorties ne portent aucune obligation de licence, fournit les matériaux tels quels et rend les utilisateurs responsables des droits, consentements et diligences nécessaires. Les équipes ont toujours besoin d'un examen juridique couvrant la fiche du modèle, les avis du dépôt, les conditions des jeux de données, les plans de distribution en aval et les obligations internes de conformité. La disponibilité pour usage commercial répond à une question de licence. Elle ne valide pas la sécurité, la confidentialité, la reproductibilité, la latence, l'étalonnage, l'enveloppe opérationnelle ou la gestion des échecs.

Traitez les déclarations de NVIDIA sur les benchmarks, le raisonnement spatial, les flux de sécurité et les performances comme des affirmations de fournisseur jusqu'à ce qu'elles soient reproduites dans le pipeline de données de l'équipe. C'est le même état d'esprit d'acceptation dont les équipes ont besoin lorsqu'elles évaluent des capacités natives d'une publication dans les lancements de nouveaux modèles ou des composants ouverts pour un usage local, comme les petits modèles de sécurité.

Maturité des artefacts : fiche du modèle, dépôt, configurations, jeux de données et documentation

Avant de tester la qualité, vérifiez si l'artefact peut être épinglé. L'ensemble minimal de preuves est l'article technique de NVIDIA, la fiche du modèle Hugging Face, le dépôt NVLabs, la licence OpenMDW-1.1, la page NVIDIA Alpamayo, la page du jeu de données PhysicalAI Autonomous Vehicles et le dépôt AlpaSim. Capturez les hachages de commits lorsqu'ils sont disponibles, la révision exacte du modèle, la version du carnet d'inférence, les fichiers de configuration, la provenance des jeux de données, les modèles de prompts et l'environnement d'exécution.

Si une équipe ne peut pas reproduire le même comportement entrée-sortie à partir d'artefacts épinglés, le modèle doit rester en mode recherche. La reproductibilité n'est pas de la paperasse. C'est ainsi que les équipes déboguent la dérive des étiquettes, tracent les échecs et détectent si une mise à jour ultérieure du modèle a changé le comportement.

Le seuil d'acceptation Optijara pour modèles de conduite autonome

Le seuil d'acceptation Optijara pour modèles de conduite autonome comporte quatre portes. Chaque porte renvoie réussite, validation conditionnelle ou rejet. Une réussite autorise le flux contrôlé suivant. Une validation conditionnelle autorise une expérimentation limitée avec revue supplémentaire. Un rejet bloque l'usage en aval jusqu'à ce que les preuves s'améliorent.

Porte 1 : identité, licence et reproductibilité des artefacts

La porte 1 demande si le modèle est exactement ce que l'équipe pense qu'il est. La revue doit enregistrer le nom du modèle, l'URL source, la révision, le commit du dépôt, la version de la licence, les références aux jeux de données, la configuration d'inférence, l'usage prévu et l'usage bloqué. Une approbation pour le triage d'auto-étiquettes hors ligne ne doit pas devenir discrètement une approbation pour la planification en boucle fermée.

Porte 2 : contrat d'entrée-sortie et discipline du repère de coordonnées

La porte 2 définit le contrat autour de chaque sortie. Pour chaque sortie acceptée, stockez les identifiants des extraits sources, le contexte caméra ou capteur lorsqu'il est disponible, l'alignement temporel, le statut d'étalonnage, le repère de coordonnées, les hypothèses cartographiques, la configuration du prompt ou de la tâche, le type de sortie, les métadonnées de confiance ou de preuve, le statut du réviseur et les limites d'usage en aval.

Les erreurs de repère de coordonnées sont dangereuses parce qu'elles peuvent faire paraître une trajectoire valide tout en pointant vers un mauvais sens physique. Le seuil d'acceptation doit vérifier l'ordre des caméras, l'historique d'ego-mouvement, le minutage des capteurs, les hypothèses de projection et les métadonnées de scène avant qu'une sortie entre dans l'entraînement ou l'évaluation.

Porte 3 : preuves d'étiquettes, traces de raisonnement et citations d'acteurs

La porte 3 traite les traces de raisonnement comme des preuves à inspecter, pas comme des preuves définitives. Si une trace cite des acteurs ou des boîtes 2D, les réviseurs doivent confirmer que les acteurs cités existent, sont pertinents pour la décision et ne sont ni hallucinés ni mal placés. Si un modèle explique un changement de voie en faisant référence à un véhicule, un piéton, une zone de travaux, un signal ou une occlusion, la preuve doit être visible ou autrement soutenue par le contexte d'entrée.

Porte 4 : préparation à la boucle ouverte, à la simulation, au mode shadow et aux canaris

La porte 4 décide où le composant peut aller ensuite. La relecture en boucle ouverte peut révéler des faiblesses de trajectoire, d'étiquette et d'explication, mais elle ne peut pas prouver le comportement de conduite réel parce que la sortie du modèle ne change pas l'état suivant du monde. La préparation à la boucle fermée exige simulation, injection d'échecs, analyse en mode shadow, contraintes de canari, comportement de secours, règles de retour arrière et revue humaine.

Matrice de décision : modèle enseignant, planificateur, étiqueteur, simulateur ou politique plus petite ?

La décision sur le rôle du modèle doit être explicite. Un grand modèle enseignant peut avoir de la valeur hors ligne, tandis qu'un planificateur spécialisé plus petit ou une politique étudiante peut être meilleur pour la latence, le déterminisme ou des enveloppes opérationnelles étroites.

La distillation enseignant vers étudiant doit être traitée comme un flux contrôlé. L'enseignant peut aider à générer des candidats ou des explications, mais l'étudiant a encore besoin d'une validation indépendante, d'ensembles d'évaluation propres et de garde-fous opérationnels.

Ce qu'il faut tester avant de faire confiance aux trajectoires, traces et étiquettes

Validité des trajectoires et cohérence contrefactuelle

Une trajectoire doit être testée par rapport à la géométrie, aux règles de circulation, aux contraintes de confort lorsqu'elles sont définies et aux changements de scène. Les tests contrefactuels sont utiles. Changez un acteur de tête, une occlusion, la géométrie de la route, un indice météo, une hypothèse de vitesse, un panneau ou le contexte cartographique, puis vérifiez que la sortie change d'une manière raisonnable. Si une trace supposément causale reste la même après retrait du facteur causal, la trace peut relever du théâtre explicatif.

Utilité des traces de raisonnement contre théâtre explicatif

Une trace utile doit relier les preuves observées à la sortie. Elle ne doit pas se contenter de reformuler une règle de conduite générique. Les réviseurs doivent demander quels faits de scène ont été cités, où ils apparaissent dans l'entrée, quelle action alternative a été rejetée et si l'explication changerait sous un contrefactuel.

Qualité des auto-étiquettes, citations d'acteurs et revue des boîtes 2D

Les auto-étiquettes doivent être échantillonnées par rapport à une vérité terrain revue par des humains. Pour chaque échantillon, inspectez l'identité de l'acteur, la qualité de la boîte 2D, l'étiquette de classe, la gestion de l'occlusion, l'alignement temporel et la question de savoir si l'acteur cité a réellement influencé la décision revendiquée. Les affirmations quantitatives non étayées sur les performances ne doivent pas entrer dans l'article, le tableau de bord ou le rapport d'acceptation, sauf si elles sont liées à une source citée ou à un résultat d'évaluation interne.

Contamination des jeux de données, fuites et couverture des scénarios de longue traîne

Séparez les jeux de données d'exploration, d'entraînement, de validation, de revue de sécurité et de déploiement. Divisez par itinéraire, véhicule, heure, météo, configuration de capteurs, géographie et famille de scénarios lorsque les données le permettent. L'échantillonnage de longue traîne doit inclure les insertions, les usagers vulnérables, les occlusions, les zones de travaux, les priorités ambiguës, la signalisation inhabituelle, les véhicules d'urgence, les capteurs dégradés et les combinaisons rares d'événements autrement ordinaires.

La boucle ouverte est nécessaire, la boucle fermée est différente

Les tests en boucle ouverte sont nécessaires parce qu'ils permettent aux équipes de rejouer des scènes enregistrées, de comparer les sorties et de déboguer les étiquettes ou les traces de raisonnement. Ils sont insuffisants parce que la conduite est interactive. Dans les paramètres en boucle fermée, chaque action change l'état suivant, ce qui peut amplifier de petites erreurs.

Un flux par étapes est plus sûr : relecture hors ligne, simulation avec perturbations contrôlées, injection d'échecs, comparaison en mode shadow, canari limité, secours, retour arrière et revue humaine. Les catégories de métriques peuvent inclure intervention, collision, quasi-accident, confort, conformité aux règles, précision de l'étiquetage et couverture des scénarios, mais chacune doit être définie avant usage. Évitez de tout moyenner dans un seul score. Les régressions pondérées par scénario racontent une histoire plus honnête qu'un seul chiffre de titre.

Liste de contrôle d'implémentation pour un bac à sable d'évaluation Alpamayo 2 Super

Les grands modèles enseignants sont souvent mieux utilisés hors ligne, où les contraintes de calcul et de latence sont plus faciles à gérer. Si le temps de réponse en ligne, le comportement déterministe ou les contraintes de certification dominent, un planificateur spécialisé ou une politique compacte peut être le meilleur composant. Optijara peut aider les équipes à concevoir le système d'évaluation, le schéma de traçabilité, le flux de revue et les contrôles de déploiement par étapes sans traiter une publication de modèle comme un raccourci vers la préparation opérationnelle.

Erreurs courantes que les équipes doivent éviter

Confondre une démonstration forte avec une enveloppe opérationnelle validée

Une démonstration soignée n'est pas une enveloppe opérationnelle. Le seuil d'acceptation doit préciser les routes, capteurs, conditions météo, familles de scénarios, usages des sorties, exigences de revue humaine et contextes bloqués.

Utiliser les traces de raisonnement comme preuve au lieu de preuves à inspecter

Les traces de raisonnement sont utiles parce qu'elles peuvent être inspectées. Elles deviennent risquées lorsque les équipes les traitent comme des explications auto-vérifiantes.

Laisser les auto-étiquettes contaminer les ensembles d'évaluation

Si les étiquettes générées par le modèle influencent à la fois l'entraînement et l'évaluation, la qualité mesurée peut paraître meilleure qu'elle ne l'est. Gardez les ensembles d'évaluation propres et gouvernés séparément.

Ignorer la licence et les limites d'usage en aval

L'accès ouvert au modèle ne supprime pas la nécessité d'examiner les limites de redistribution, de modèles dérivés, de jeux de données, d'attribution et d'usage des sorties. La page du jeu de données PhysicalAI Autonomous Vehicles présente aussi une porte de licence et des restrictions distinctes pour le jeu de données. L'examen de la licence du modèle et celui de la licence du jeu de données doivent donc être suivis séparément.

Optimiser les moyennes de benchmark tout en manquant les scénarios rares

La performance moyenne peut masquer des échecs rares mais importants. Utilisez une évaluation pondérée par scénario et conservez les cas d'échec entre les versions.

Plan de mesure et résumé d'acceptation lisible par machine

{
  "model_role": "offline teacher and data-engine candidate",
  "allowed_uses": ["reviewed auto-label triage", "trajectory proposal analysis", "teacher-to-student distillation sandbox", "simulation scenario exploration"],
  "blocked_uses": ["direct closed-loop control", "unreviewed production labels", "commercial deployment without license review"],
  "required_evidence": ["pinned artifacts", "coordinate-frame validation", "human-reviewed labels", "counterfactual tests", "leakage controls", "rollback plan"],
  "decision": "conditional_pass_for_offline_evaluation_only"
}

Les réserves pratiques sont assez simples. Le comportement du fournisseur et du modèle peut varier selon les versions. Le coût d'implémentation est réel. Les contrôles de confidentialité doivent précéder tout téléversement ou traitement de données. Les caches et les étiquettes peuvent devenir obsolètes. La qualité de l'évaluation dépend d'une conception propre des scénarios, les erreurs de repère de coordonnées peuvent invalider des sorties qui semblent correctes, et les compromis opérationnels doivent être documentés avant d'élargir l'usage.