De una sola instrucción a un agente visual funcional: lo que cambian NVIDIA Cosmos y VSS 3.3

Construir un agente completo de análisis de vídeo que vigila cámaras, rastrea archivos y genera alertas a partir de una sola frase suena como una promesa audaz, y el directo del 1 de octubre se propone probarla exactamente sobre el escenario. El presentador recibe a Adam, del lado de gestión de producto VSS, y a Hassan, del equipo técnico de Metropolis, presentando la emisión como el primer vistazo práctico a las novedades de VSS 3.3 antes de GTC Berlin. Una sola idea sostiene toda la sesión: el desarrollador describe lo que quiere en lenguaje natural, y un agente de código lo convierte en una aplicación funcional. El anuncio y el enlace de visionado de esta emisión se publicaron en el hilo oficial en forums.developer.nvidia.com, donde el evento se presenta explícitamente como heraldo del programa GTC Berlin.

VSS, siglas de Video Search and Summarization, se presenta como una arquitectura de referencia bajo el paraguas NVIDIA Metropolis que asume el análisis de vídeo de extremo a extremo. El sistema ingiere enormes volúmenes de vídeo en vivo o archivado y los convierte en búsqueda en lenguaje natural, respuesta visual a preguntas, alertas verificadas e informes automáticos. Entre bambalinas, modelos de visión-lenguaje, grandes modelos de lenguaje como Nemotron, generación aumentada con recuperación y herramientas conectadas vía Model Context Protocol trabajan juntos. Como un agente de producción típico agrupa ingestión, detección, alerta, búsqueda, resumen e informes bajo un mismo techo, esta integridad importa muchísimo. La lista actual de capacidades y el enlace de prueba cloud viven en la tarjeta Blueprint oficial en build.nvidia.com, recomendada como primera parada para quien quiera probar la arquitectura.

En el corazón de la inteligencia visual está Cosmos, posicionado en la emisión como un modelo abierto de razonamiento visión-lenguaje. La distinción crucial es una división en dos fases: primero un modelo de embedding encuentra clips candidatos en el archivo, luego Cosmos verifica si la condición visual pedida ocurrió de verdad. Como parecer relevante y contener realmente el evento pedido son cosas distintas, esta separación de recuperar-y-luego-verificar recorta sustancialmente las falsas alertas. Del lado de Cosmos 3, se anuncia una capacidad NIM en streaming que sustituye el procesado por fragmentos por una ventana deslizante que evalúa cada fotograma por turno. El diseño de la familia Cosmos 3, que unifica razonamiento, generación de mundos y generación de acciones en un solo modelo, se explica en detalle en el artículo técnico en developer.nvidia.com, donde se comparten modelos abiertos y recetas de entrenamiento.

La arquitectura se divide en tres capas, cada una con una responsabilidad distinta. La capa en tiempo real hace extracción de características, generación de embeddings y comprensión de flujos, publicando resultados hacia un bus de mensajes. La capa analítica enriquece esos datos en trayectorias, incidentes y registros de alertas verificadas. La capa de agente orquesta las herramientas de búsqueda, preguntas y respuestas, resumen y recuperación de clips vía Model Context Protocol. La infraestructura compartida incluye el servicio de vídeo de entrada-salida y almacenamiento, Kafka, Redis, Elasticsearch y un balanceador de entrada, y el sistema de habilidades los reutiliza en vez de reinstalarlos cada vez. Las referencias de servicios y las opciones de configuración de este diseño por capas se publican en la documentación oficial de VSS en docs.nvidia.com, que también explica los perfiles de despliegue.

La ruta de grabación y la ruta en vivo se separan deliberadamente, y esta división conduce toda la demostración. La ruta de grabación gestiona almacenamiento, indexación y recuperación, mientras la ruta en vivo vigila el flujo en continuo frente a la condición definida por el operador. La gestión de reglas se agrupa en un componente llamado puente de alertas, que garantiza la correcta recepción de la regla mientras Cosmos evalúa el flujo. Cuando se captura un evento, la aplicación lo expone junto a su prueba en vídeo para que cada uno vea lo ocurrido con sus propios ojos. Como este diseño separa la vigilancia continua de la gestión de reglas, el sistema resulta a la vez comprensible y fácil de mantener.

La ventana del operador al mundo tiene dos hojas: la interfaz VSS y el chat conectado vía OpenClaw. En la demo, un asistente llamado Astra lleva el trabajo conversacional, funcionando dentro de un agente de código llamado Codex con la habilidad Build Vision Agent. La herramienta que en el vídeo se oye como Codeex es en realidad el agente de código Codex, y el modelo local que se oye como Neatron es en realidad el modelo Nemotron. Las responsabilidades de los modelos se reparten limpiamente: el modelo de embedding encuentra el vídeo relevante, el modelo de visión-lenguaje evalúa lo visual, y el modelo de lenguaje conduce la conversación con el operador. La pregunta del operador es de una sencillez llamativa: muestre el líquido que escapa de las botellas.

Tras la arquitectura abstracta, el directo pone rumbo a un negocio concreto: vigilar una fábrica de zumo de naranja. Dos necesidades básicas del operador se definen de entrada: encontrar qué pasó en las grabaciones y recibir aviso en cuanto vuelva a pasar en una cámara en vivo. Corresponden exactamente a la distinción entre dónde-ocurrió y avísame-cuando-vuelva, lo que justifica directamente la arquitectura de doble ruta. Las imágenes originales de fábrica sirven al ejemplo de búsqueda y alerta, mientras las de la línea de embotellado se reservan para la demo posterior de medición. Del lado en vivo, las grabaciones se reemiten vía RTSP para ejercitar los flujos de streaming con vídeo repetible.

En la primera instrucción el desarrollador describe el caso de uso, y la habilidad responde preguntando por capacidades y entradas antes de proponer una arquitectura. Entre los perfiles listos, se selecciona la configuración personalizada que combina búsqueda con alerta en tiempo real, y la propuesta cae en pantalla: alertas en tiempo real sobre la Foundation, conservando la interfaz web y el chat del operador. La carga se reparte entre GPU: Cosmos 3 corre en una tarjeta, el modelo de lenguaje en otra, y el detector RT-DETR en recursos separados. La condición de alerta se define en una frase: zumo visible escapando de las botellas durante el llenado. El despliegue nunca arranca antes de que el desarrollador apruebe la arquitectura, y con modelos pre-descargados el tiempo de sesión se dedica a la aplicación misma.

Del lado del vídeo grabado el flujo de datos avanza en pasos trazables. El servicio de vídeo de entrada-salida y almacenamiento da acceso a las imágenes, el modelo de embedding convierte el contenido visual en representaciones consultables, y Elasticsearch guarda el índice de búsqueda. Cuando llega una pregunta, el sistema primero reúne clips candidatos, luego Cosmos evalúa cada candidato frente a la condición visual pedida. La brecha entre parecer relevante y contener de verdad el evento se cierra en este punto. Como este pipeline se une a alertas y chat en la misma interfaz, el operador rastrea el historial y mira el directo desde una sola pantalla. Reunir búsqueda y vigilancia en una sola aplicación elimina el coste de construir dos sistemas separados.

Demo en vivo en una fábrica de zumo

Una vez combinadas búsqueda y alerta, la demo se estira hacia una tercera capacidad: la medición botella a botella. Para un operador de fábrica, saber hasta dónde subió el líquido en cada botella y cómo se compara con el nivel esperado importa al menos tanto como las alertas. Para esta extensión entran en juego máscaras de segmentación basadas en RF-DETR: una marca la botella y otra el líquido visible, píxel a píxel. Como verdaderas regiones de píxeles sustituyen a los recuadros, la medición se vuelve mucho más precisa. Las máscaras vienen del modelo corriendo en GPU, y la lógica de medición las combina con la calibración de cámara para estimar la altura del líquido visible dentro de la botella.

Se subrayan dos escalas de tiempo distintas de la medición, y esta distinción moldea la experiencia del operador. Mientras el llenado continúa, el número mostrado cuenta como provisional y una botella a medio llenar jamás se sella como falta de llenado. Terminado el ciclo, el componente guarda el resultado final con la identidad de la botella, permitiendo la comparación retrospectiva. Los ciclos 8126 y 8127 se muestran como ejemplos de tales registros identificados. Cuando la vista se ocluye o la medición es débil, la interfaz muestra la incertidumbre abiertamente en vez de fingir confianza. Esta honestidad importa porque el operador debe saber hasta dónde creer cada número.

Cuando los registros se completan, cada botella aparece con su propia identidad, medición y veredicto, y la botella 8105 se roba el show con una falta de llenado del 28 por ciento. El operador puede adjuntar ese registro directo al chat VSS y preguntar qué le pasó, y el agente produce una explicación concreta desde las mediciones devueltas por las herramientas de llenado. La explicación puede cotejarse lado a lado con el valor de la interfaz, y las preguntas de seguimiento pueden continuar sobre el mismo registro. Dos botellas pueden adjuntarse juntas e interrogarse sus diferencias. El operador llega así a conclusiones hablando con el agente en vez de memorizar cada campo, librándose de recordar qué pasó cinco botellas atrás en la vista previa en vivo.

El sistema no solo mira cámaras; flujos extra de sensores pueden conectarse si hace falta, y el agente pliega esas lecturas en sus decisiones. La calibración se marca como obligatoria en producción: la demo usó una calibración de ejemplo que enseña dónde está el 100 por cien en esas botellas, pero una línea real debe aplicar todos los procedimientos existentes en su totalidad. La unidad de porcentaje relativa a cámara se explica con cuidado: la cifra en pantalla no son milímetros ni volumen físico, sino la proporción entre la altura del líquido visible y la botella. Esta claridad de definición evita malinterpretar números entre distintas líneas y cámaras. Valores de referencia y límites bajos se configuran sobre esa misma proporción. La integración de gemelos digitales aligera esta carga al permitir calibración anticipada en un entorno virtual: los gemelos construidos con Omniverse dejan probar ajustes antes de tocar la línea física, recortando riesgo de puesta en marcha y pérdidas de producción, y a medida que la brecha virtual-real se cierra, la fiabilidad de calibración mejora mientras las plantas con muchas cámaras ahorran tiempo serio con preparación virtual en vez de ajustes en sitio.

Cálculo de costes: 3 dólares para construir, céntimos para operar

La sección de costes corre sobre una sola GPU RTX Pro con precios cloud, respondiendo dos preguntas: cuánto cuesta construir y cuánto cuesta seguir operando. El primer agente se levanta tras unos 30 minutos de instrucciones con un coste declarado de 3 dólares. Se recomienda tiempo extra de ajuste y extensión tras la instalación, pero el primer agente funcional conectado al sistema cabe en ese presupuesto. Un resumen cuidado de este análisis y el contexto técnico de ambas capacidades nuevas se publicó en el reportaje en news.bpdata.com, donde recortar costes de desarrollo y operación ocupa el centro.

La economía unitaria del lado operativo parece notablemente baja: 100 alertas verificadas cuestan unos 30 céntimos, un ritmo que significa 1200 alertas por hora. Cien informes cuestan 85 céntimos, ilustrados con un escenario de informe cada 10 minutos. Resumir una hora de vídeo cuesta 23 céntimos, toma 10 minutos en una sola GPU, y rinde seis resúmenes por hora. Alrededor de mil consultas de búsqueda visual por hora se traducen en 3,37 dólares. La flexibilidad se presenta como virtud: el presupuesto GPU puede servir interacción del operador de día y tareas generativas como informes y resúmenes de noche, con una hora de GPU cloud capaz de correr todas estas capacidades juntas.

El motor de la ganancia de eficiencia se presenta como muestreo adaptativo y se explica intuitivamente. El enfoque clásico convierte cada parche de una imagen 1080p en tokens para el modelo, mientras el sistema adaptativo observa el cambio temporal y espacial. Solo los tokens de los momentos y regiones donde el cambio se concentra viajan al gran modelo; el resto se poda. El resultado anunciado es audaz: la latencia cae un 60 por ciento mientras el mismo modelo de visión-lenguaje sirve un 40 por ciento más de flujos simultáneos. El muestreo eficiente, antes servido con tasas fijas de poda, se vuelve una decisión adaptativa por parche y por fotograma en la versión 3.3. Del lado NIM de streaming de Cosmos 3, una ventana deslizante procesa cada fotograma en secuencia, empujando la meta de alerta bajo los 300 milisegundos.

Las cifras medidas de capacidad también aclaran la escala de hardware: una sola H100 gestiona 60 flujos simultáneos alimentando el modelo de visión-lenguaje. Los escenarios que evitan inyectar cada fotograma en el modelo caben holgadamente en hardware edge mucho menor como AGX o DGX Spark. La nueva lista de soporte nombra también Jetson Orin, Orin NX y GB300. La misma arquitectura escala así del datacenter al borde de fábrica, con hardware elegido según número de flujos, resolución y modelo preferido. Compartir un mismo juego de habilidades entre una instalación edge ligera y una central pesada refuerza la ambición de llegar a todas partes con una sola arquitectura.

Primeros pasos y límites

Los perfiles de desarrollador mantienen el sistema modular con cuatro puntos de partida validados: base, alertas, resumen de vídeo largo y búsqueda. La habilidad parte del perfil más cercano al pedido y solo aplica el delta necesario, deduplicando servicios compartidos. Cuando dos capacidades necesitan el mismo detector, comparten un solo detector, mientras Kafka y Elasticsearch se comparten con índices separados si hace falta. Todas las funciones 3.3 se prueban desde hoy en la rama principal del repositorio GitHub y las builds nocturnas del registro de contenedores. Esta línea abierta de desarrollo y su ritmo nocturno viven en el repositorio VSS en github.com, con la etiqueta oficial 3.3 prevista para aterrizar con GTC Berlin.

Tres paradas se recomiendan para empezar: la página de demo cloud, el repositorio GitHub y la documentación. El despliegue cloud en un clic ofrece capacidad de prueba en dos RTX Pro, y los charts de Docker Compose y Helm se modifican según necesidad. Los charts de Kubernetes, los análisis de seguridad y los paquetes NIM listos para producción esperan la transición a producción. Los casos de uso parecen infinitos: inspección industrial, almacén y logística, analítica deportiva, espacios inteligentes y validación de procedimientos destacan. Un almacén de cincuenta cámaras se conectaría vía la infraestructura RTSP existente y los sistemas de gestión de vídeo intactos, con hardware dimensionado por resolución y frecuencia de procesado.

La pregunta de retención cero de datos recibe respuesta directa en privacidad y cumplimiento. Recién salida, la arquitectura de referencia embarca un sistema de gestión de vídeo y Elasticsearch, con retención por defecto de 24 horas en el índice. Pero el sistema también puede instalarse sin gestión de vídeo ni base de datos, y las políticas de retención se cambian en ambas capas. Del lado de analítica de comportamiento, se provee un microservicio de ejemplo: los metadatos fluyen al bus de mensajes, heurísticas como cajas solapadas y cálculos de velocidad corren allí, y cualquiera puede conectar su propio servicio al mismo bus. Combinar cámaras térmicas y ópticas se ve factible: un modelo separado que entiende la entrada térmica correlaciona los datos brutos de temperatura con la información visual.