NVIDIA Alpamayo 2 Super: una puerta de aceptación para modelos docentes de conducción autónoma

Si un modelo puede producir una ruta plausible, explicar la escena y etiquetar actores cercanos, la pregunta difícil no es si parece inteligente. Es si la evidencia es suficientemente buena para permitir que esa salida toque la generación de datos, el etiquetado, la destilación o la evaluación. Ahí es donde una puerta de aceptación de NVIDIA Alpamayo 2 Super demuestra su utilidad.

NVIDIA Alpamayo 2 Super ocupa una parte sensible de la pila de conducción autónoma. NVIDIA lo describe como un modelo abierto de razonamiento de visión-lenguaje-acción, con 34 mil millones de parámetros, para el desarrollo de vehículos autónomos, que combina un Cosmos 3 Super Reasoner de 32 mil millones de parámetros con un Action Expert basado en difusión. La publicación técnica de NVIDIA describe el experto de acción como un modelo de 2 mil millones de parámetros, mientras que la ficha del modelo en Hugging Face lo describe como de 2,3 mil millones de parámetros, por lo que los equipos deben registrar en qué fuente y revisión del artefacto se basan. La publicación oficial dice que puede usar video multicámara, contexto lingüístico e historial de movimiento previo para producir trayectorias futuras, trazas de razonamiento Chain-of-Causation, metaacciones de alto nivel, respuestas de escena y etiquetas automáticas de razonamiento. Útil, sí. Listo para confiar por defecto, no.

La visión impopular es que el lanzamiento del modelo es menos importante que el proceso de aceptación que lo rodea. Un modelo docente fluido puede hacer que las canalizaciones de datos débiles fallen más rápido. Este artículo define la Puerta de Aceptación de Modelos de Conducción Autónoma de Optijara, una forma práctica de decidir si Alpamayo 2 Super pertenece a un flujo de trabajo de modelo docente, una cola de etiquetado automático, un sistema de propuesta de trayectorias, un flujo de trabajo de simulador, un cuaderno de investigación o una categoría bloqueada. No es un resumen de lanzamiento de robotaxi y no trata las afirmaciones del proveedor como prueba de producción. La misma disciplina se aplica a otros modelos de alta capacidad que entran en flujos de trabajo operativos, incluidas las pautas de aceptación tratadas en evaluación de infraestructura de IA y pruebas de aceptación de búsqueda de IA con anclaje.

Qué es Alpamayo 2 Super y qué no es

Rol del modelo: docente, motor de datos y generador de evidencia

Alpamayo 2 Super debe evaluarse primero como un modelo docente y de motor de datos fuera de línea, no como una política de conducción predeterminada. NVIDIA dice que puede generar trayectorias y trazas Chain-of-Causation, predecir metaacciones como ceder el paso o cambiar de carril, responder preguntas sobre escenas y crear etiquetas automáticas CoC con anclaje 2D. Eso apunta a usos prácticos en enriquecimiento de datasets, análisis de fallos, destilación de políticas, minería de escenarios y apoyo a la evaluación.

El matiz importa. Un modelo docente puede proponer etiquetas, trayectorias o explicaciones que ayuden a un equipo a inspeccionar datos más rápido. También puede equivocarse con confianza. Una traza de razonamiento puede exponer evidencia, pero no es una prueba. Una trayectoria puede parecer suave mientras falla una comprobación de marco de coordenadas, un cambio de escena contrafactual o una simulación en bucle cerrado.

Por qué la apertura para uso comercial no equivale a preparación para producción

La publicación de NVIDIA dice que el modelo se publica bajo OpenMDW-1.1 y describe permisos de redistribución comercial y de modelos derivados. El texto de la licencia OpenMDW-1.1 concede permiso para operar con materiales del modelo sin restricción, sujeto al cumplimiento, exige conservar los avisos de licencia y origen al distribuir materiales del modelo, establece que las salidas no conllevan obligaciones de licencia, proporciona los materiales tal cual y responsabiliza a los usuarios de derechos, consentimientos y diligencia debida. Los equipos siguen necesitando revisión legal de la ficha del modelo, los avisos del repositorio, los términos de los datasets, los planes de distribución descendente y las obligaciones internas de cumplimiento. La disponibilidad para uso comercial responde a una pregunta de licencia. No valida seguridad, privacidad, reproducibilidad, latencia, calibración, entorno operativo ni gestión de fallos.

Trata las afirmaciones de NVIDIA sobre benchmarks, razonamiento espacial, flujos de trabajo de seguridad y rendimiento como afirmaciones del proveedor hasta que se reproduzcan en la propia canalización de datos del equipo. Es la misma mentalidad de aceptación que los equipos necesitan al evaluar capacidades nativas de lanzamiento en nuevos lanzamientos de modelos o componentes abiertos para uso local, como modelos de seguridad pequeños.

Madurez del artefacto: ficha del modelo, repositorio, configuraciones, datasets y documentación

Antes de probar la calidad, prueba si el artefacto puede fijarse. El conjunto mínimo de evidencia incluye el blog técnico de NVIDIA, la ficha del modelo en Hugging Face, el repositorio de NVLabs, la licencia OpenMDW-1.1, la página de NVIDIA Alpamayo, la página del dataset PhysicalAI Autonomous Vehicles y el repositorio de AlpaSim. Captura hashes de commit cuando estén disponibles, revisión exacta del modelo, versión del cuaderno de inferencia, archivos de configuración, procedencia del dataset, plantillas de prompt y entorno de ejecución.

Si un equipo no puede reproducir el mismo comportamiento de entrada-salida a partir de artefactos fijados, el modelo debe permanecer en modo de investigación. La reproducibilidad no es papeleo. Es la forma en que los equipos depuran la deriva de etiquetas, rastrean fallos y detectan si una actualización posterior del modelo cambió el comportamiento.

La Puerta de Aceptación de Modelos de Conducción Autónoma de Optijara

La Puerta de Aceptación de Modelos de Conducción Autónoma de Optijara tiene cuatro puertas. Cada puerta devuelve aprobado, aprobado condicional o rechazado. Un aprobado permite el siguiente flujo de trabajo controlado. Un aprobado condicional permite experimentación limitada con revisión adicional. Un rechazo bloquea el uso descendente hasta que mejore la evidencia.

Puerta 1: identidad, licencia y reproducibilidad del artefacto

La Puerta 1 pregunta si el modelo es exactamente lo que el equipo cree que es. La revisión debe registrar nombre del modelo, URL de origen, revisión, commit del repositorio, versión de licencia, referencias de datasets, configuración de inferencia, uso previsto y uso bloqueado. Una aprobación para triaje de etiquetado automático fuera de línea no debe convertirse silenciosamente en aprobación para planificación en bucle cerrado.

Puerta 2: contrato de entrada/salida y disciplina de marco de coordenadas

La Puerta 2 define el contrato alrededor de cada salida. Para cada salida aceptada, almacena identificadores de clips fuente, contexto de cámara o sensor cuando esté disponible, alineación de marcas de tiempo, estado de calibración, marco de coordenadas, supuestos de mapa, configuración de prompt o tarea, tipo de salida, metadatos de confianza o evidencia, estado del revisor y límites de uso descendente.

Los errores de marco de coordenadas son peligrosos porque pueden hacer que una ruta parezca válida mientras apunta a un significado físico incorrecto. La puerta de aceptación debe comprobar el orden de las cámaras, el historial de ego-movimiento, la temporización de sensores, los supuestos de proyección y los metadatos de escena antes de que cualquier salida entre en entrenamiento o evaluación.

Puerta 3: evidencia de etiquetas, trazas de razonamiento y citas de actores

La Puerta 3 trata las trazas de razonamiento como evidencia que se debe inspeccionar, no como prueba. Si una traza cita actores o cajas 2D, los revisores deben confirmar que los actores citados existen, son relevantes para la decisión y no están alucinados ni mal ubicados. Si un modelo explica un cambio de carril haciendo referencia a un vehículo, peatón, zona de obras, señal u oclusión, la evidencia debe ser visible o estar respaldada de otra forma por el contexto de entrada.

Puerta 4: preparación para bucle abierto, simulación, modo sombra y canary

La Puerta 4 decide a dónde puede ir el componente a continuación. La reproducción en bucle abierto puede revelar debilidades de trayectoria, etiqueta y explicación, pero no puede probar el comportamiento de conducción en el mundo real porque la salida del modelo no cambia el siguiente estado del mundo. La preparación para bucle cerrado requiere simulación, inyección de fallos, análisis en modo sombra, restricciones canary, comportamiento de respaldo, reglas de reversión y revisión humana.

Matriz de decisión: modelo docente, planificador, etiquetador, simulador o política más pequeña?

La decisión sobre el rol del modelo debe ser explícita. Un modelo docente grande puede ser valioso fuera de línea, mientras que un planificador especializado más pequeño o una política de estudiante pueden ser mejores para latencia, determinismo o entornos operativos estrechos.

La destilación de docente a estudiante debe tratarse como un flujo de trabajo controlado. El docente puede ayudar a generar candidatos o explicaciones, pero el estudiante sigue necesitando validación independiente, conjuntos de evaluación limpios y barreras operativas.

Qué probar antes de confiar en trayectorias, trazas y etiquetas

Validez de trayectoria y coherencia contrafactual

Una trayectoria debe probarse contra geometría, normas de tráfico, restricciones de comodidad cuando estén definidas y cambios de escena. Las pruebas contrafactuales son útiles. Cambia un actor principal, una oclusión, la geometría de la carretera, una pista meteorológica, un supuesto de velocidad, una señal o el contexto de mapa, y luego verifica que la salida cambie de forma razonable. Si una traza supuestamente causal se mantiene igual después de eliminar el factor causal, la traza puede ser teatro explicativo.

Utilidad de las trazas de razonamiento frente a teatro explicativo

Una traza útil debe conectar evidencia observada con la salida. No debe limitarse a repetir una regla de conducción genérica. Los revisores deben preguntar qué hechos de la escena se citaron, dónde aparecen en la entrada, qué acción alternativa se rechazó y si la explicación cambiaría bajo un contrafactual.

Calidad de etiquetas automáticas, citas de actores y revisión de cajas 2D

Las etiquetas automáticas necesitan muestreo contra verdad de referencia revisada por humanos. Para cada muestra, inspecciona la identidad del actor, la calidad de la caja 2D, la etiqueta de clase, la gestión de oclusiones, la alineación de marcas de tiempo y si el actor citado influyó realmente en la decisión afirmada. Las afirmaciones cuantitativas de rendimiento sin respaldo no deben entrar en el artículo, el panel o el informe de aceptación a menos que estén vinculadas a una fuente citada o a un resultado de evaluación interna.

Contaminación de datasets, fuga y cobertura de escenarios de cola larga

Mantén separados los datasets de exploración, entrenamiento, validación, revisión de seguridad y despliegue. Divide por ruta, vehículo, hora, clima, configuración de sensores, geografía y familia de escenarios cuando los datos lo permitan. El muestreo de cola larga debe incluir incorporaciones abruptas, usuarios vulnerables de la vía, oclusiones, zonas de obras, prioridad ambigua, señalización inusual, vehículos de emergencia, sensores degradados y combinaciones raras de eventos que por separado serían ordinarios.

El bucle abierto es necesario, el bucle cerrado es distinto

Las pruebas de bucle abierto son necesarias porque permiten a los equipos reproducir escenas grabadas, comparar salidas y depurar etiquetas o trazas de razonamiento. Son insuficientes porque la conducción es interactiva. En contextos de bucle cerrado, cada acción cambia el siguiente estado, lo que puede amplificar errores pequeños.

Un flujo de trabajo por etapas es más seguro: reproducción fuera de línea, simulación con perturbaciones controladas, inyección de fallos, comparación en modo sombra, canary limitado, respaldo, reversión y revisión humana. Las categorías de métricas pueden incluir intervención, colisión, casi accidente, comodidad, cumplimiento de normas, precisión de etiquetado y cobertura de escenarios, pero cada una debe definirse antes de usarse. Evita promediar todo en una sola puntuación. Las regresiones ponderadas por escenario cuentan una historia más honesta que una cifra principal única.

Lista de comprobación de implementación para un sandbox de evaluación de Alpamayo 2 Super

Los modelos docentes grandes suelen usarse mejor fuera de línea, donde las restricciones de cómputo y latencia son más fáciles de gestionar. Si predominan el tiempo de respuesta en línea, el comportamiento determinista o las restricciones de certificación, un planificador especializado o una política compacta pueden ser el mejor componente. Optijara puede ayudar a los equipos a diseñar el sistema de evaluación, el esquema de trazabilidad, el flujo de revisión y los controles de despliegue por etapas sin tratar ningún lanzamiento de modelo como un atajo hacia la preparación operativa.

Errores comunes que los equipos deben evitar

Confundir una demostración sólida con un entorno operativo validado

Una demostración pulida no es un entorno operativo. La puerta de aceptación debe especificar carreteras, sensores, clima, familias de escenarios, usos de salida, requisitos de revisión humana y contextos bloqueados.

Usar trazas de razonamiento como prueba en lugar de evidencia que inspeccionar

Las trazas de razonamiento son útiles porque pueden inspeccionarse. Se vuelven riesgosas cuando los equipos las tratan como explicaciones que se verifican a sí mismas.

Permitir que las etiquetas automáticas contaminen los conjuntos de evaluación

Si las etiquetas generadas por el modelo influyen tanto en el entrenamiento como en la evaluación, la calidad medida puede parecer mejor de lo que es. Mantén los conjuntos de evaluación limpios y gobernados por separado.

Saltarse la licencia y los límites de uso descendente

El acceso a modelos abiertos no elimina la necesidad de revisar límites de redistribución, modelos derivados, datasets, atribución y uso de salidas. La página del dataset PhysicalAI Autonomous Vehicles también presenta una puerta de licencia de dataset separada y restricciones, por lo que la revisión de licencia del modelo y la revisión de licencia del dataset deben rastrearse por separado.

Optimizar para promedios de benchmark mientras se pierden escenarios raros

El rendimiento medio puede ocultar fallos raros pero importantes. Usa evaluación ponderada por escenario y conserva los casos de fallo entre lanzamientos.

Plan de medición y resumen de aceptación legible por máquina

{
  "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"
}

Las advertencias prácticas son bastante claras. El comportamiento del proveedor y del modelo puede variar entre versiones. El coste de implementación es real. Los controles de privacidad deben ir antes de subir o procesar datos. Las cachés y etiquetas pueden quedarse obsoletas. La calidad de la evaluación depende de un diseño limpio de escenarios, los errores de marco de coordenadas pueden invalidar salidas que parecen correctas y las compensaciones operativas deben documentarse antes de ampliar el uso.