D'une seule consigne à un agent visuel opérationnel : ce que changent NVIDIA Cosmos et VSS 3.3

Construire un agent d'analyse vidéo complet qui surveille des caméras, fouille des archives et lève des alertes à partir d'une seule phrase ressemble à une promesse audacieuse, et le direct du 1er octobre entend la prouver exactement sur scène. L'animateur accueille Adam, côté gestion produit VSS, et Hassan, côté équipe technique Metropolis, en présentant l'émission comme le premier aperçu pratique des nouveautés VSS 3.3 avant GTC Berlin. Une seule idée porte toute la session : le développeur décrit son besoin en langage naturel, et un agent de codage le transforme en application fonctionnelle. L'annonce et le lien de visionnage de cette émission ont été publiés dans le fil officiel sur forums.developer.nvidia.com, où l'événement est explicitement présenté comme une annonce du programme GTC Berlin.

VSS, pour Video Search and Summarization, est présenté comme une architecture de référence sous l'égide NVIDIA Metropolis qui prend l'analyse vidéo de bout en bout. Le système ingère d'énormes masses de vidéo en direct ou archivées et les convertit en recherche en langage naturel, réponse visuelle aux questions, alertes vérifiées et reporting automatisé. En coulisses, des modèles vision-langage, de grands modèles de langage comme Nemotron, la génération augmentée par récupération et des outils connectés via le Model Context Protocol travaillent ensemble. Parce qu'un agent de production typique regroupe ingestion, détection, alerte, recherche, résumé et reporting sous un même toit, cette intégrité compte énormément. La liste actuelle des capacités et le lien d'essai cloud figurent sur la carte Blueprint officielle à build.nvidia.com, recommandée comme première étape pour qui veut essayer l'architecture.

Au coeur de l'intelligence visuelle se trouve Cosmos, positionné dans l'émission comme un modèle de raisonnement vision-langage ouvert. La distinction cruciale est une découpe en deux temps : d'abord un modèle d'embedding retrouve des clips candidats dans les archives, puis Cosmos vérifie si la condition visuelle demandée s'est vraiment produite. Puisque paraître pertinent et contenir réellement l'événement demandé sont deux choses différentes, cette séparation retrouver-puis-vérifier réduit nettement les fausses alertes. Côté Cosmos 3, une capacité NIM en streaming est annoncée, remplaçant le traitement par morceaux par une fenêtre glissante qui évalue chaque image à son tour. La conception de la famille Cosmos 3, unifiant raisonnement, génération de mondes et génération d'actions en un seul modèle, est expliquée en détail dans l'article technique sur developer.nvidia.com, où modèles ouverts et recettes d'entraînement sont partagés.

L'architecture se divise en trois couches, chacune avec une responsabilité distincte. La couche temps réel effectue extraction de caractéristiques, génération d'embeddings et compréhension des flux, en publiant les résultats vers un bus de messages. La couche analytique enrichit ces données en trajectoires, incidents et enregistrements d'alertes vérifiées. La couche agent orchestre les outils de recherche, de questions-réponses, de résumé et de récupération de clips via le Model Context Protocol. L'infrastructure partagée comprend le service vidéo d'entrée-sortie et de stockage, Kafka, Redis, Elasticsearch et un répartiteur d'entrée, et le système de compétences les réutilise au lieu de les réinstaller à chaque fois. Les références de services et les options de configuration de cette conception en couches sont publiées dans la documentation VSS officielle sur docs.nvidia.com, qui explique aussi les profils de déploiement.

Le chemin d'enregistrement et le chemin temps réel sont délibérément séparés, et cette division conduit toute la démonstration. Le chemin d'enregistrement gère stockage, indexation et récupération, tandis que le chemin temps réel surveille le flux en continu face à la condition définie par l'opérateur. La gestion des règles est regroupée dans un composant appelé pont d'alerte, qui garantit la bonne réception de la règle pendant que Cosmos évalue le flux. Quand un événement est capté, l'application l'expose avec sa preuve vidéo pour que chacun voie ce qui s'est passé de ses propres yeux. Parce que cette conception sépare la surveillance continue de la gestion des règles, le système reste à la fois compréhensible et facile à maintenir.

La fenêtre de l'opérateur sur le monde comporte deux volets : l'interface VSS et le chat connecté via OpenClaw. Dans la démo, un assistant nommé Astra assure le travail conversationnel, fonctionnant à l'intérieur d'un agent de codage appelé Codex avec la compétence Build Vision Agent. L'outil entendu comme Codeex dans la vidéo est en réalité l'agent de codage Codex, et le modèle local entendu comme Neatron est en réalité le modèle Nemotron. Les responsabilités des modèles sont réparties proprement : le modèle d'embedding retrouve la vidéo pertinente, le modèle vision-langage évalue les visuels, et le modèle de langage mène la conversation avec l'opérateur. La question de l'opérateur elle-même est d'une simplicité frappante : montrez le liquide qui fuit des bouteilles.

Après l'architecture abstraite, le direct met le cap sur une entreprise concrète : la surveillance d'une usine de jus d'orange. Deux besoins de base de l'opérateur sont définis d'emblée : retrouver ce qui s'est passé dans les enregistrements et être prévenu dès que cela se reproduit sur une caméra en direct. Ils correspondent exactement à la distinction entre où-cela-s'est-produit et prévenez-moi-quand-ça-revient, ce qui justifie directement l'architecture à double chemin. Les images d'usine d'origine servent l'exemple de recherche et d'alerte, tandis que les images de la ligne d'embouteillage sont réservées à la démo de mesure ultérieure. Côté direct, les enregistrements sont rejoués via RTSP pour exercer les flux de streaming avec une vidéo reproductible.

Dans la première consigne, le développeur décrit le cas d'usage, et la compétence répond en interrogeant sur les capacités et les entrées avant de proposer une architecture. Parmi les profils prêts à l'emploi, la configuration personnalisée combinant recherche et alerte temps réel est sélectionnée, et la proposition s'affiche à l'écran : des alertes temps réel par-dessus la Foundation, en conservant l'interface web et le chat opérateur. La charge est répartie sur les GPU : Cosmos 3 tourne sur une carte, le modèle de langage sur une autre, et le détecteur RT-DETR sur des ressources séparées. La condition d'alerte est définie en une phrase : du jus visible s'échappant des bouteilles pendant le remplissage. Le déploiement ne démarre jamais avant que le développeur n'approuve l'architecture, et avec des modèles pré-téléchargés, le temps de session va à l'application elle-même.

Côté vidéo enregistrée, le flux de données avance par étapes traçables. Le service vidéo d'entrée-sortie et de stockage donne accès aux images, le modèle d'embedding convertit le contenu visuel en représentations interrogeables, et Elasticsearch détient l'index de recherche. Quand une question arrive, le système rassemble d'abord des clips candidats, puis Cosmos évalue chaque candidat face à la condition visuelle demandée. L'écart entre paraître pertinent et contenir vraiment l'événement se referme à ce point. Parce que ce pipeline rejoint alertes et chat dans la même interface, l'opérateur fouille l'historique et regarde le direct depuis un seul écran. Réunir recherche et surveillance dans une seule application supprime le coût de construire deux systèmes séparés.

Démo en direct dans une usine de jus

Une fois la recherche et l'alerte combinées, la démo s'étire vers une troisième capacité : la mesure bouteille par bouteille. Pour un opérateur d'usine, savoir jusqu'où le liquide est monté dans chaque bouteille et comment cela se compare au niveau attendu compte au moins autant que les alertes. Pour cette extension, des masques de segmentation basés sur RF-DETR entrent en jeu : l'un marque la bouteille et l'autre le liquide visible, pixel par pixel. Parce que de vraies régions de pixels remplacent les boîtes englobantes, la mesure devient bien plus précise. Les masques viennent du modèle tournant sur GPU, et la logique de mesure les combine avec la calibration caméra pour estimer la hauteur du liquide visible dans la bouteille.

Deux échelles de temps différentes de la mesure sont soulignées, et cette distinction façonne l'expérience opérateur. Pendant que le remplissage continue, le nombre affiché compte comme provisoire et une bouteille à moitié pleine n'est jamais tamponnée comme sous-remplie. Une fois le cycle terminé, le composant stocke le résultat final avec l'identité de la bouteille, permettant une comparaison rétrospective. Les cycles 8126 et 8127 sont montrés comme exemples de tels enregistrements identifiés. Quand la vue est occultée ou la mesure faible, l'interface affiche l'incertitude ouvertement au lieu de simuler la confiance. Cette honnêteté compte parce que l'opérateur doit savoir jusqu'où croire chaque nombre.

Quand les enregistrements se terminent, chaque bouteille apparaît avec sa propre identité, sa mesure et son verdict, et la bouteille 8105 vole la vedette avec un sous-remplissage de 28 pour cent. L'opérateur peut joindre cet enregistrement directement dans le chat VSS et demander ce qui lui est arrivé, et l'agent produit une explication concrète à partir des mesures retournées par les outils de remplissage. L'explication peut être vérifiée côte à côte avec la valeur de l'interface, et des questions de suivi peuvent continuer sur le même enregistrement. Deux bouteilles peuvent être jointes ensemble et leurs différences interrogées. L'opérateur parvient ainsi à des conclusions en parlant à l'agent au lieu de mémoriser chaque champ, échappant au fardeau de se souvenir de ce qui s'est passé cinq bouteilles plus tôt sur l'aperçu en direct.

Le système ne se contente pas de regarder les caméras ; des flux de capteurs supplémentaires peuvent être connectés au besoin, et l'agent intègre ces lectures dans ses décisions. La calibration est signalée comme obligatoire en production : la démo utilisait un étalonnage d'exemple enseignant où se situe le 100 pour cent sur ces bouteilles, mais une vraie ligne doit appliquer toutes les procédures existantes dans leur intégralité. L'unité de pourcentage relative à la caméra est expliquée avec soin : le chiffre à l'écran n'est ni des millimètres ni un volume physique, mais le rapport entre la hauteur du liquide visible et la bouteille. Cette clarté de définition évite de mal lire les nombres entre différentes lignes et caméras. Les valeurs de référence et les limites basses se configurent sur ce même rapport. L'intégration de jumeaux numériques allège cette charge en permettant une calibration avancée dans un environnement virtuel : des jumeaux construits avec Omniverse laissent tester les réglages avant de toucher la ligne physique, réduisant le risque de mise en service et les pertes de production, et à mesure que l'écart virtuel-réel se referme, la fiabilité de calibration progresse tandis que les usines multi-caméras gagnent un temps sérieux avec une préparation virtuelle au lieu de réglages sur site.

Calcul de coût : 3 dollars pour construire, des centimes pour tourner

La section coût tourne sur un seul GPU RTX Pro avec des tarifs cloud, répondant à deux questions : combien coûte la construction, et combien coûte l'exploitation continue. Le premier agent se lève après environ 30 minutes de consignes pour un coût annoncé de 3 dollars. Du temps supplémentaire de réglage et d'extension est recommandé après l'installation, mais le premier agent fonctionnel connecté au système tient dans ce budget. Un résumé soigné de cette analyse et le contexte technique des deux nouvelles capacités ont été publiés dans le reportage sur news.bpdata.com, où la réduction des coûts de développement et d'exploitation occupe le devant de la scène.

L'économie unitaire côté exploitation semble remarquablement basse : 100 alertes vérifiées coûtent environ 30 centimes, un rythme qui signifie 1200 alertes par heure. Cent rapports coûtent 85 centimes, illustrés par un scénario de rapport toutes les 10 minutes. Résumer une heure de vidéo coûte 23 centimes, prend 10 minutes sur un seul GPU, et produit six résumés par heure. Environ un millier de requêtes de recherche visuelle par heure se traduit par 3,37 dollars. La flexibilité est présentée comme un atout : le budget GPU peut servir l'interaction opérateur le jour et les tâches génératives comme rapports et résumés la nuit, avec une heure de GPU cloud censée faire tourner toutes ces capacités ensemble.

Le moteur du gain d'efficacité est introduit comme échantillonnage adaptatif et expliqué intuitivement. L'approche classique convertit chaque patch d'une image 1080p en jetons pour le modèle, tandis que le système adaptatif observe le changement temporel et spatial. Seuls les jetons des moments et régions où le changement se concentre voyagent vers le grand modèle ; le reste est élagué. Le résultat annoncé est audacieux : la latence chute de 60 pour cent tandis que le même modèle vision-langage sert 40 pour cent de flux simultanés en plus. L'échantillonnage efficace, auparavant livré avec des taux d'élagage fixes, devient une décision adaptative par patch et par image dans la version 3.3. Côté NIM de streaming Cosmos 3, une fenêtre glissante traite chaque image en séquence, poussant la cible d'alerte sous les 300 millisecondes.

Les chiffres de capacité mesurés clarifient aussi l'échelle matérielle : un seul H100 gère 60 flux simultanés alimentant le modèle vision-langage. Les scénarios qui évitent d'injecter chaque image dans le modèle tiennent confortablement sur du matériel edge bien plus petit comme AGX ou DGX Spark. La nouvelle liste de support nomme aussi Jetson Orin, Orin NX et GB300. La même architecture s'étend donc du datacenter au bord d'usine, avec un matériel choisi selon le nombre de flux, la résolution et le modèle préféré. Partager un même jeu de compétences entre une installation edge légère et une lourde centrale renforce l'ambition d'aller partout avec une seule architecture.

Premiers pas et limites

Les profils développeur gardent le système modulaire avec quatre points de départ validés : base, alertes, résumé de longues vidéos et recherche. La compétence part du profil le plus proche de la demande et n'applique que le delta nécessaire, en dédupliquant les services partagés. Quand deux capacités ont besoin du même détecteur, elles partagent un seul détecteur, tandis que Kafka et Elasticsearch sont partagés avec des index séparés si besoin. Toutes les fonctionnalités 3.3 sont essayables dès aujourd'hui depuis la branche principale du dépôt GitHub et les builds nocturnes du registre de conteneurs. Cette ligne de développement ouverte et ce rythme nocturne vivent dans le dépôt VSS sur github.com, avec l'étiquette officielle 3.3 prévue pour atterrir avec GTC Berlin.

Trois étapes sont recommandées pour débuter : la page de démo cloud, le dépôt GitHub et la documentation. Le déploiement cloud en un clic offre une capacité d'essai sur deux RTX Pro, et les charts Docker Compose et Helm se modifient selon les besoins. Les charts Kubernetes, les analyses de sécurité et les paquets NIM prêts pour la production attendent la transition vers la production. Les cas d'usage semblent infinis : inspection industrielle, entrepôt et logistique, analytique sportive, espaces intelligents et validation de procédures se détachent. Un entrepôt de cinquante caméras se brancherait via l'infrastructure RTSP existante et les systèmes de gestion vidéo intacts, avec un matériel dimensionné par la résolution et la fréquence de traitement.

La question de la rétention zéro des données reçoit une réponse directe côté confidentialité et conformité. Sortie de boîte, l'architecture de référence embarque un système de gestion vidéo et Elasticsearch, avec une rétention par défaut de 24 heures dans l'index. Pourtant le système peut aussi s'installer sans gestion vidéo ni base de données, et les politiques de rétention se modifient sur les deux couches. Côté analytique comportementale, un microservice d'exemple est fourni : les métadonnées affluent dans le bus de messages, des heuristiques comme les boîtes se chevauchant et les calculs de vitesse y tournent, et chacun peut attacher son propre service au même bus. Combiner caméras thermiques et optiques est jugé faisable : un modèle séparé comprenant l'entrée thermique corrèle les données brutes de température avec l'information visuelle.