Cómputo en el robot frente a cómputo externo

Toda carga de trabajo de un robot vive en uno de dos sitios: a bordo, tirando de la batería y de los ventiladores del torso, o fuera del robot, en un servidor alimentado de la red eléctrica a un salto de LAN. La pregunta difícil no es si necesita ambos —casi siempre los necesita—, sino qué carga de trabajo va a cada sitio y por qué. R08 argumenta por qué debe existir una capa de borde dedicada. Este artículo es la decisión carga por carga: el control de motores aquí, el VLM allí, el STT depende, y así sucesivamente.

El planteamiento no es neutral. Hay una respuesta correcta para cada carga de trabajo, y esa respuesta cambia a medida que el silicio a bordo gana terreno. Indicaremos hacia dónde se mueve cada pieza en 2026–2027.

Los dos presupuestos que lo deciden todo

Una carga de trabajo puede ejecutarse a bordo si y solo si cabe en dos presupuestos a la vez: potencia y memoria. La latencia es la tercera restricción, pero normalmente la latencia le dice hacia dónde empujar una carga que ya cabe, no si cabe o no.

Presupuesto de potencia en un humanoide. Un humanoide de 30–50 kg lleva 700–900 Wh de batería. Caminar de forma sostenida consume 200–500 W de los actuadores, con picos de más de 800 W en movimiento dinámico. Estar parado y «pensando» consume 80–150 W de los actuadores (mantener el par es barato, mantener la postura cuesta). Eso deja unos 60–120 W para todo lo demás —cómputo, sensores, ventiladores de refrigeración, radio— si quiere una autonomía útil de dos horas. El presupuesto de cómputo dentro de ese margen es de 30–80 W sostenidos. Hacer funcionar el Jetson a MAX_N (60 W) todo el tiempo reduce a la mitad la autonomía del robot. Esto es física innegociable, no una decisión de diseño.

Presupuesto de memoria. Un Jetson AGX Orin 64 GB son 64 GB de LPDDR5 compartidos entre la CPU y la GPU. Reste el sistema operativo (4–6 GB), ROS 2 y el SDK del fabricante (2–4 GB), los búferes de percepción (2–4 GB para profundidad estéreo y nubes de puntos) y el código de la aplicación. El presupuesto realista utilizable por un LLM/VLM es de 40–48 GB. En un módulo Jetson Thor de 128 GB el techo sube a ~96 GB utilizables. En un Orin NX de 16 GB se desploma a ~8–10 GB utilizables: suficiente para un único modelo pequeño.

Fuera del robot, ambos presupuestos son problemas distintos. Un Kentino AI 96 (4× RTX 5090) tiene 128 GB de VRAM dedicada y 1.0–1.5 kW de potencia de GPU conectado a la red eléctrica. Un Kentino AI 256 (8× RTX 5090) duplica ambas cifras. La potencia y la memoria simplemente dejan de ser restricciones: las cambia por inversión inicial, climatización de la sala y red cableada.

El silicio a bordo, la realidad de 2026

Las opciones a bordo que hoy se montan de verdad en humanoides y cuadrúpedos serios:

Thor es un salto, no una iteración. El techo de 128 GB de memoria y los núcleos tensoriales Blackwell con FP4 nativo llevan la frontera de lo que corre a bordo de «VLM de 7B, a duras penas» a «VLM de 32B, con utilidad» en una sola generación. Las cargas que en 2025 eran estructuralmente externas —VLM de tamaño medio, descripción continua de la escena, planificadores LLM medianos— pasan a ser candidatas a ejecutarse a bordo en 2026 si la solución térmica del robot puede sostener 100–130 W.

Hailo y la clase de NPU dedicadas no son aceleradores de LLM. Sirven para descargar la cadena de visión: deje libre el Jetson principal para el modelo grande y ejecute la visión por computador de cámara siempre activa (detección de objetos, seguimiento, VLM ligero básico) en un chip de 3 W.

La clase Snapdragon QRB es la respuesta para robots centrados en la voz —palabra de activación, conformación de haz, STT— donde un Jetson es excesivo y un Cortex-M se queda corto. Útil, especializada y cada vez más habitual.

Fuera del robot: la gama Kentino AI como referencia

El destino externo al que se refiere toda esta serie es la línea Kentino AI: alimentada de la red eléctrica, rack de 4U o 5U, 4 u 8 GPU sobre EPYC o Xeon, en un conmutador 10 GbE a un salto del robot. Los tres niveles que importan en robótica:

La matriz de decisión

Toda carga de trabajo robótica encaja limpiamente en una de cinco categorías: siempre a bordo, preferiblemente a bordo, indiferente, preferiblemente fuera, solo fuera. El motivo de cada ubicación es el presupuesto limitante: potencia, memoria o latencia.

Tres lecturas de esta tabla que conviene destacar.

Las filas de «siempre a bordo» son física. Ninguna cantidad de ancho de banda arregla un bucle de control que exige respuesta a 1 kHz. Estas no se mueven nunca, por bueno que llegue a ser el cómputo externo o la red.

Las filas de «indiferente» son donde entra el criterio de ingeniería de verdad. Ahí viven casi todos los compromisos interesantes. Que un VLM de 7B se ejecute a bordo o fuera determina buena parte del comportamiento del sistema. No hay una respuesta correcta universal.

Las filas de «solo fuera» se mueven despacio. Un modelo de 72B seguirá siendo, probablemente, solo externo en 2027. Un modelo de 32B pasará a bordo cuando Thor se distribuya en volumen. La frontera de «lo que cabe en el dispositivo» avanza más o menos una clase de tamaño de modelo cada 18–24 meses.

Correspondencia de los niveles de latencia

El presupuesto de latencia de cuatro niveles de I01 se traduce directamente en una ubicación:

Los dos niveles intermedios son donde están las verdaderas decisiones de arquitectura. Una carga refleja que justo cabe en 50 ms puede caber fuera del robot por LAN cableada (0.5 ms de ida + 40 ms de inferencia + 0.5 ms de vuelta = 41 ms), pero reventar el presupuesto por Wi-Fi 6E con carga (8 ms × 2 + 40 ms = 56 ms, más la fluctuación). Por eso los cables de conexión importan durante el desarrollo: permiten ver si una carga de trabajo fundamentalmente cabe fuera del robot antes de pelearse con la red inalámbrica.

La realidad de la red

Lo externo solo funciona si funciona la red. Las cifras reales:

Para cargas deliberativas (presupuesto de 100 ms a 1 s), Wi-Fi 6E con un SSID dedicado y un AP en línea de visión basta. Para cargas reflejas (10–50 ms), el cable es la respuesta segura y el Wi-Fi 6E la respuesta afortunada. Planifique en consecuencia: si la tarea del robot tiene algún componente reflejo fuera del robot, diseñe con una opción cableada para el desarrollo y un modo de reserva para cuando el Wi-Fi se degrade.

El patrón híbrido: división rápido/lento

El patrón al que converge la mayoría de despliegues serios de 2026 es la división rápido/lento de VLM: un VLM pequeño a bordo para respuesta instantánea, un VLM grande fuera para decisiones meditadas, y ambos alimentando el mismo planificador.

Forma concreta:

División rápido/lento: el 7B a bordo se encarga de la respuesta inmediata; el 72B externo, del razonamiento meditado y de actualizar el plan.

El modelo rápido resuelve «hay una persona caminando hacia mí, reduce la velocidad». El modelo lento resuelve «la persona que camina hacia mí es el operario, que me pidió pararme si se acerca con la carpeta roja, y eso es una carpeta roja, así que me paro». El modelo rápido se compromete primero con un comportamiento seguro; el lento lo mejora.

La migración: qué pasa a bordo en 2026–2027

Tres fuerzas comprimen el lado externo: Thor llega en volumen (2070 TFLOPS FP4, 128 GB de memoria unificada, margen de 130 W: un salto estructural respecto a Orin); la eficiencia de los VLM sigue mejorando (un VLM de percepción «suficientemente bueno» era de 70B o más en 2024, es de 32B en 2026 y plausiblemente será de 13B–20B en 2027); y la decodificación especulativa con pequeños modelos borrador permite servir calidad de modelo grande con latencia de modelo pequeño.

Las cargas con más probabilidades de migrar a bordo en los próximos 18 meses: VLM de escena de clase 7B (ya en movimiento), planificador LLM de 13B (Thor lo deja holgado), la cadena STT-LLM-TTS de contexto corto para voz y VLM de 7B ajustados a un dominio concreto.

Las cargas que no migran: todo lo de 70B o más, la memoria de escena a escala de flota, el entrenamiento y la simulación, y la fusión VLM multiflujo. Estas siguen fuera del robot hasta 2027 como mínimo. El ancho de banda de memoria y la potencia de la batería no ceden tan rápido.

Dos configuraciones concretas

Un solo G1 EDU, laboratorio de investigación. A bordo, un AGX Orin ejecuta ROS 2, YOLOv11-s a 30 FPS, STT con Whisper-distil y Qwen2.5-VL 7B INT4 a 5–8 FPS (deliberativo). Fuera, un Kentino AI 96 (4× RTX 5090, 128 GB de VRAM) ejecuta vLLM con Qwen2.5-VL 72B y Qwen2.5 32B solo texto, memoria de escena en pgvector e Isaac Sim en las GPU ociosas.

Flota pequeña, 3 humanoides, clase Thor a bordo. Cada unidad lleva un SoC de visión Hailo-15 para detección multicámara siempre activa, Whisper-small en el propio dispositivo y Qwen2.5-VL 32B INT4 a 10–15 FPS, de forma nativa y ya sin ir al límite. Fuera, un Kentino AI 256 (8× RTX 5090, 256 GB de VRAM) aloja un Qwen2.5-VL 72B compartido y un Llama-3.1 70B para planificación, un almacén pgvector compartido entre los tres robots y dos GPU reservadas para el ajuste fino LoRA nocturno.

Dónde sí funcionan los despliegues de un solo nivel

Todo a bordo funciona para cuadrúpedos de tarea única (patrulla perimetral con YOLO + cámara térmica), robots teleoperados (el operario es el planificador, sin VLM en el bucle), robots de demostración o educativos con los modelos más pequeños y cualquier despliegue sin red alguna (inspección en exteriores, emplazamientos remotos).

Todo en la nube funciona para asistentes robóticos solo de voz sin bucle de percepción cerrado, prototipos donde la rapidez de puesta en marcha importa más que nada y despliegues en los que los datos van de todos modos, y de forma deliberada, a una carga de trabajo en la nube.

El híbrido es la respuesta para todo lo que queda en medio, que es aproximadamente el 90% de la robótica seria en 2026. Si está construyendo cualquier cosa con percepción con VLM en el bucle, acabará con los dos niveles. Planifíquelo desde el primer día.

---

Esto forma parte de la Kentino Wiki, una serie de referencia sobre computación de IA, robótica y los sistemas que las conectan. Comentarios y correcciones son bienvenidos en info@kentino.com.