Arquitectura de IA en el edge: cómo habla un robot con un servidor de inferencia on-premise

Si va a comprar un robot humanoide o cuadrúpedo en 2026, la unidad que reciba es solo la mitad del sistema. La otra mitad es el cómputo que ejecuta los grandes modelos que el propio robot no puede alojar. Este artículo explica qué vive realmente en cada sitio, por qué existe la vía on-premise cuando las API en la nube son baratas y cómo se conectan ambas mitades, física y lógicamente.

Está dirigido a compradores e integradores que quieren una imagen clara antes de firmar un pedido, no todavía a los ingenieros que escribirán el código de integración.

El problema de las dos cajas

Un humanoide moderno como el Unitree G1 o el Booster T1 lleva a bordo un módulo de cómputo embebido: normalmente un Jetson Orin (clase NX o AGX) o un SoC de clase Snapdragon, a menudo acompañado de un pequeño MCU dedicado al bucle de control de los motores. Los cuadrúpedos como el Unitree Go2 usan una disposición similar a menor escala.

Ese cómputo a bordo basta para:

• Control de motores en tiempo real — par de las articulaciones, equilibrio, marcha. Funciona entre 500 Hz y 1 kHz y no tolera ningún salto de red. Se queda en local, sin excepciones.
• Reflejos de seguridad inmediatos — protección ante caídas, parada de emergencia, respuesta al contacto. Misma restricción, misma respuesta.
• Percepción de baja latencia — profundidad por estéreo o RGB-D, fusión de IMU, detección básica de objetos (habitualmente una variante ligera de YOLO o MobileNet).
• Palabra de activación por voz y enrutado básico de comandos.

Lo que el cómputo a bordo no puede ejecutar razonablemente:

• Grandes modelos de visión-lenguaje (VLM) como Qwen2.5-VL 72B, NVIDIA Cosmos u OpenVLA. Necesitan decenas de GB de VRAM y consumen demasiado para una plataforma alimentada por batería.
• Grandes modelos de lenguaje (LLM) para diálogo o planificación por encima de la clase 7B–8B cuantizada.
• Planificadores de movimiento basados en difusión o autorregresivos que operan sobre cientos de milisegundos de contexto.
• Memoria de escena y grafos de tareas de largo horizonte.

Esta división no es una opinión de Kentino. Es la partición real con la que se entrega hoy toda plataforma humanoide seria. El módulo de a bordo está dimensionado para la seguridad y la latencia; el pensamiento pesado se traslada fuera.

Ese destino «fuera» puede ser la nube (OpenAI, Anthropic, NVIDIA Cosmos alojado) o un servidor de inferencia on-premise. El resto del artículo trata de cuándo y por qué le interesa la opción on-premise.

Qué vive en cada sitio — el reparto práctico

El reparto en dos cajas: el control local se queda en el robot; la inferencia pesada y el entrenamiento van al servidor on-premise por LAN.

Tres cosas que conviene observar:

1. El robot no necesita un servidor GPU para caminar. Si la LAN se cae, la unidad sigue levantándose, mantiene el equilibrio y evita chocar contra la pared. La cadena off-board añade capacidades —lenguaje, planificación, tareas de largo horizonte—, no sustituye al control local.
2. Algunas cargas de trabajo son negociables. Un VLM pequeño (por ejemplo, Qwen2.5-VL 7B cuantizado) puede ejecutarse en un Jetson Orin AGX. Que lo lleve a bordo o fuera es un compromiso de consumo, térmica y latencia. No hay una única respuesta correcta.
3. El servidor hace más que servir inferencia. Un despliegue serio también ejecuta entrenamiento (para afinar el modelo a un entorno concreto), simulación (Isaac Sim para iterar políticas) y memoria de escena / recuperación. «Servidor de inferencia» es la forma breve de decir «backend de cómputo GPU».

El presupuesto de latencia

La única cifra que determina si su arquitectura va a funcionar es el tiempo de ida y vuelta entre el robot y el servidor.

Las cifras que dominan el presupuesto son la latencia del modelo en el servidor y, si va por radio, el jitter del Wi-Fi. El transporte en sí rara vez es el cuello de botella en una LAN cableada. Por eso la mayoría de instalaciones robóticas serias usan un cable de conexión o un punto de acceso Wi-Fi 6/6E dedicado con línea de visión sobre la zona de trabajo.

Si su robot debe responder a una orden verbal en menos de un segundo, las cuentas son aproximadamente estas:

captura de audio       ~ 50 ms
palabra clave + STT    100–250 ms  (a bordo o fuera, usted elige)
TTFT del LLM (plan)    200–500 ms  (en el servidor)
LLM, 20 tokens         600–1200 ms
TTS                    100–300 ms
reproducción de audio  ~ 50 ms
                       --------------
                       ~ 1.1 – 2.3 s

Hoy no hay forma de bajar de un segundo de extremo a extremo con un LLM de 70B en el bucle. O acepta la latencia, o usa un modelo más pequeño on-premise (clase 8B–13B), o divide la respuesta (confirmar de inmediato y planificar en segundo plano).

Es el tipo de compromiso que no tiene nada que ver con la red y todo con la elección del modelo. También es el tipo de compromiso en el que tener servidor propio importa: puede cambiar de modelo, ejecutar varios a la vez, agrupar las peticiones de otra forma. Con una API en la nube, se queda con lo que el proveedor sirva.

Por qué on-premise

La inferencia en la nube es barata, escala sin esfuerzo y no exige capex. Entonces, ¿por qué iba nadie a comprar un servidor de cuatro u ocho GPU cuando una clave de API de OpenAI cuesta cincuenta dólares?

Hay cuatro razones reales, en orden aproximado de frecuencia con que deciden la compra:

1. Los datos no salen del edificio. Los despliegues industriales, de defensa, sanitarios y sujetos al RGPD europeo a menudo no pueden enviar datos de sensores en bruto a una nube de terceros. El robot ve una planta de fabricación, la habitación de un paciente, un banco de laboratorio. Ese vídeo es confidencial, está regulado o es competitivamente sensible. La inferencia on-premise lo resuelve limpiamente. La nube no.

2. Suelo de latencia. Toda llamada a la nube suma entre 15 y 40 ms de RTT por WAN a la latencia del modelo. Para la mayoría de tareas robóticas es aceptable. Para control reactivo en lazo cerrado —coger y colocar a velocidad, recuperar el equilibrio tras un empujón, manipulación fina— ese suelo WAN es demasiado. On-premise lo deja por debajo de 1 ms.

3. Coste con carga sostenida. Una sola llamada a un VLM de 70B apenas cuesta nada al proveedor; a usted le cobra unos céntimos. Pero un robot que «piensa todo el rato» hace miles de llamadas por hora. Un laboratorio de investigación que entrena y una flota de robots que infieren contra los mismos modelos pueden saturar entre 5.000 y 15.000 dólares al mes en gasto de nube. Un servidor on-premise de 4 u 8 GPU se amortiza en menos de doce meses con esa carga.

4. Elección de modelo y personalización. Quiere afinar un VLM sobre su entorno concreto. Quiere ejecutar un modelo que los proveedores de nube no alojan. Quiere combinar modelos de pesos abiertos de distintos fabricantes en una cadena propia. On-premise se lo permite. Las API en la nube, no.

Si ninguna de esas cuatro razones aplica a su despliegue, use la nube. La respuesta honesta es que quizá entre el 30 % y el 40 % de los compradores de robótica necesitan realmente on-premise; el resto lo eligen por prestigio o porque a su departamento de compras le incomoda la nube. Ambas razones también son válidas, pero no vamos a fingir lo contrario.

Topología de red

Topología de red: robot en Wi-Fi 6E → AP dedicado → switch 10 GbE → servidor de inferencia. La salida e internet son opcionales.

Algunas notas prácticas que suelen pillar a la gente por sorpresa:

• Wi-Fi 6E es el mínimo, no el máximo. La banda de 6 GHz es la única con un comportamiento de baja latencia constante en entornos con otros dispositivos. Calcule un AP por cada ~50 m² de área de trabajo del robot, con línea de visión si es posible.
• El cable sigue siendo mejor. Si el robot admite conexión por cable (algunos humanoides de investigación sí, los cuadrúpedos normalmente no), úsela durante el desarrollo. Trabajar con una LAN de menos de un milisegundo es muchísimo más agradable que pelearse con el Wi-Fi.
• La salida a internet es opcional, pero útil. Incluso en un despliegue totalmente on-premise, suele querer salida WAN para actualizar modelos, descargar datos de mapas, traerse contenedores NVIDIA NGC y enviar telemetría a su propia monitorización. Protéjala con un cortafuegos estricto; no exponga el robot ni el servidor a internet.
• La sincronización horaria importa. Monte un servidor NTP local. La fusión de sensores y la planificación de movimiento fallan de formas sutiles cuando los relojes se desvían entre el robot, el servidor y cualquier dispositivo auxiliar de borde.

Alimentación y refrigeración

Un servidor Kentino AI de 4 GPU (4× RTX 5090 o 4× RTX Pro 6000 Blackwell) consume 1.8–2.4 kW sostenidos bajo carga. Uno de 8 GPU consume 3.5–4.5 kW. No son cifras de sobremesa: requieren circuitos de 16 A y un flujo de aire de rack adecuado.

Para un laboratorio de robótica, el presupuesto aproximado es:

Planifique la sala antes de la instalación, no después. La mayoría de laboratorios que «añadieron cómputo GPU más tarde» acaban saltando los diferenciales el primer mes.

El flujo de aire importa tanto como los vatios. Los servidores Kentino AI usan flujo industrial de rack de delante hacia atrás con ventiladores de 120 mm y están diseñados expresamente para carga sostenida 24/7. No son torres de sobremesa y saturarán la climatización de una sala pequeña. O los instala en un armario con refrigeración dedicada, o los lleva a otra sala y tiende un enlace de 10 GbE.

Pila de software — qué se ejecuta realmente

Aquí es donde vive la implementación. La imagen general:

Reparto del software: ROS 2 en el robot se comunica por gRPC con el servidor de inferencia que ejecuta vLLM / SGLang.

Un par de decisiones con opinión:

• vLLM es la pila de servicio por defecto para VLM y LLM basados en transformers. Es más rápido que la inferencia directa de HuggingFace y admite batching continuo y caché de prefijos. SGLang es una buena alternativa si trabaja con salida estructurada o flujos de tipo agente.
• llama.cpp es la respuesta correcta cuando ejecuta un modelo pequeño (clase 7B–13B) en una GPU con la que vLLM no se lleva bien (por ejemplo, una RTX 4090 con paralelismo de tensores caprichoso), o en el propio robot.
• NVIDIA Triton cuesta más de montar, pero es la opción adecuada si mezcla tipos de modelo (LLM + visión + habla) y quiere una única capa de servicio para todos.
• ROS 2 Humble es la lengua franca. Los SDK de los fabricantes (Unitree, Booster, EngineAI) incluyen envoltorios de ROS 2. Construya su integración sobre ROS 2 y no sobre el protocolo propietario del fabricante, salvo que tenga un motivo concreto.

Un ejemplo concreto

Imagine la instalación de producción viable más sencilla: un humanoide (Unitree G1), un servidor de inferencia (Kentino AI 256 Turin Dual con 8× RTX 5090), un switch y un AP, en un laboratorio de 30 m².

Hardware:
- Unitree G1 (una unidad, ~1 kW de consumo en carga)
- Kentino AI 256 Turin Dual / 8× RTX 5090 (~4 kW sostenidos)
- Switch 10 GbE (5 puertos, ~30 W)
- AP Wi-Fi 6E (~15 W)
- Circuito trifásico de 32 A o 2× monofásico de 16 A
- ~6 kW de refrigeración dedicada (aire acondicionado split)

Software en el servidor:
- Ubuntu 22.04, CUDA 13, Docker
- vLLM sirviendo Qwen2.5-VL 72B en INT4
- vLLM sirviendo Qwen2.5 32B (solo texto, para planificación)
- pgvector para la memoria de escena
- Isaac Sim para el trabajo de políticas
- Prometheus + Grafana

Software en el robot:
- Driver ROS 2 de Unitree
- Nodo ROS 2 propio de enrutado de comandos
- Cliente gRPC hacia los endpoints de vLLM
- YOLO local para detección rápida de obstáculos

Es una arquitectura real y viable que puede comprar y poner en marcha en dos o tres semanas. El presupuesto total del lado de cómputo (servidor, red, instalación eléctrica, refrigeración adicional) se sitúa entre 60k € y 90k € según la configuración. El robot es una partida aparte.

Para un laboratorio de investigación con 2–4 robots, el mismo servidor escala: vLLM gestiona bien las peticiones concurrentes y el cuello de botella pasa a ser la memoria de GPU (si quiere alojar más modelos a la vez) o la potencia disponible.

Qué falla

Lista honesta de los fallos que hemos visto, en orden aproximado de frecuencia:

• Jitter de Wi-Fi bajo carga. Una red que iba bien se congestiona cuando se suma un dispositivo nuevo, la latencia salta de 5 ms a 80 ms y el comportamiento reactivo del robot se degrada. Solución: SSID dedicado para robótica, solo 6 GHz, AP con línea de visión.
• Cambiar de modelo tumba el sistema. Actualiza el VLM, vLLM tiene que recargar y la cadena de comandos del robot agota el tiempo de espera. Solución: servicio azul/verde, dos endpoints y cambiarlos de uno en uno.
• Estrangulamiento térmico del servidor. Con entrenamiento e inferencia sostenidos, el aire acondicionado de la sala no da abasto y las GPU reducen frecuencia. La latencia de inferencia se duplica en silencio. Solución: dimensionar la refrigeración a 1.3× la carga sostenida, vigilar la temperatura de las GPU y alarmar a 80 °C.
• Fallos de cables y conectores en el robot. Los robots vibran. Los cables se fatigan. Cuente con un fallo de cable de red o de sensor por robot y trimestre en las unidades de uso intensivo. Tenga recambios.
• Driver de NVIDIA y versión de CUDA desparejados tras un apt-get upgrade. Esto le pasa a todo el mundo exactamente una vez. Fije la versión del driver, use contenedores y no ejecute apt-get dist-upgrade en un servidor que funciona.
• Deriva de reloj entre robot y servidor. Las marcas de tiempo de los sensores se desvían decenas de milisegundos, la fusión de sensores produce basura y nadie entiende por qué. Solución: NTP local, vigilarlo y alarmar con una deriva > 5 ms.

Ninguno de estos problemas es catastrófico. Todos son predecibles una vez que los ha visto una vez.

Cuándo la vía on-premise es la respuesta equivocada

Por honestidad: el servidor de inferencia on-premise es la respuesta equivocada cuando —

• Su robot es puramente teleoperado y su operador ya está sentado ante una estación de trabajo en la nube. Use la nube sin más.
• Despliega un único cuadrúpedo para una tarea de inspección en exteriores y no necesita inferencia con modelos grandes; el cómputo de a bordo basta.
• Su huella de modelo cabe realmente en un Jetson Orin AGX (50–70 W de TDP) y su presupuesto de latencia permite trabajar a bordo. El Orin puede ejecutar un LLM de 7B en INT4 a una velocidad utilizable.
• Se trata de una demo puntual. La nube se monta antes, es más barata con carga cero y puede desmontarla en una tarde.

La vía on-premise es la correcta cuando el despliegue es sostenido, los datos son sensibles, el presupuesto de latencia es ajustado o las necesidades de personalización son reales. La mayor parte del trabajo serio en robótica en 2026 cumple al menos una de esas condiciones.

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