Mistral finge que un mejor modelo VLA resuelve el problema de la física.
El anuncio de Robostral Navigate es una señal clara de que el laboratorio está aburrido de solo predecir el siguiente token en una ventana de chat. Quieren adentrarse en el mundo físico. En apariencia, tiene sentido. Si puedes construir un modelo que entienda el mundo a través de texto e imágenes, ¿por qué no dejar que ese modelo conduzca un robot? Pero hay una diferencia enorme entre que un LLM alucine una cita legal falsa y que un robot alucine un camino claro a través de una puerta de vidrio. Una es una anécdota graciosa para un blog; la otra es un reclamo de seguro muy costoso.
Mistral está pivotando hacia la encarnación, pero lo hace desde una perspectiva software-first. Están apostando a que el principal cuello de botella en robótica es el “cerebro”—la capacidad de razonar sobre una escena y traducirla en un movimiento. Esta es una visión optimista. Cualquiera que haya trabajado con hardware real sabe que el “cerebro” suele ser la parte fácil. La difícil es el ruido en los sensores, la deriva en los actuadores y la pura impredecibilidad de un suelo alfombrado.
El núcleo técnico del proyecto consiste en mapear píxeles a acciones. En lugar de tener un modelo de visión separado que alimente a un planificador que luego alimente a un controlador, Robostral Navigate intenta colapsar estos pasos. Es un enfoque de Visión-Lenguaje-Acción (VLA). Es esencialmente como intentar aprender a conducir un coche viendo diez mil horas de videos de YouTube y luego entregarte las llaves sin haberse sentado nunca en el asiento del conductor. Se ve impresionante en una demo porque el “entorno” suele ser un laboratorio controlado o una simulación donde la física es limpia y la iluminación es perfecta.
Pero ¿esto realmente resuelve el problema de navegación, o solo hace que el robot parezca más seguro mientras se estrella? (la mayoría de nosotros ni siquiera podemos hacer que un Roomba evite una alfombra). El problema con los VLA es que a menudo carecen de una verdadera comprensión de la persistencia espacial. Ven un frame, predicen un movimiento. Si el frame tiembla o la iluminación cambia, el “razonamiento” puede evaporarse al instante. Ya hemos visto esto antes con los primeros modelos de visión y lenguaje que podían describir una habitación perfectamente pero no podían decirte si una silla estaba lo suficientemente cerca para sentarse.
Es un movimiento audaz, pero se siente como una solución de software a un problema de hardware.
Luego está la realidad del hardware. El mayor obstáculo sigue siendo la latencia de la inferencia. Para que un robot se mueva con fluidez, necesitas un bucle de retroalimentación ajustado. No puedes tener un robot pausándose 200 milisegundos esperando a que un transformer decida si una caja de cartón es un obstáculo o una puerta. Si el modelo es demasiado pesado para ejecutarse en el edge, el robot se convierte en un títere atado. Si requiere una conexión a la nube para funcionar, una sola caída de paquete se convierte en una colisión física.
Mistral no ha dedicado mucho tiempo a hablar sobre los requisitos de VRAM para el compute a bordo. Si esto requiere un chip de clase H100 para mantener una tasa de fotogramas razonable, no es un modelo de robótica—es una curiosidad de investigación. La fricción del mundo real no se trata solo de evitar paredes; se trata del consumo de energía y el calor generado por las GPUs atadas a la espalda del robot.
La industria está actualmente obsesionada con las leyes de escalado, pero escalar un modelo no escala automáticamente su utilidad en un espacio físico. No puedes “apostar por el conteo de parámetros” para salirte con una actuador lento.
Para finales del Q3, veremos si este modelo puede realmente operar en una plataforma móvil sin un enlace de alto ancho de banda a una granja de servidores. Si las demos continúan siendo puramente simuladas o atadas a la nube, esto es solo otro ejercicio en la persecución de benchmarks.
El modelo es una pieza ingeniosa de ingeniería, pero no es una solución.
