Por qué los robots necesitan cómputo dedicado en el borde

Un humanoide que camina es un problema resuelto. Un humanoide que entiende lo que está mirando, planifica una tarea de varios pasos y recuerda lo que ocurrió hace cinco minutos, no lo es. La capacidad de cálculo que cierra esa brecha no cabe en el robot, y la nube no es el lugar donde ponerla. Este artículo expone el argumento técnico de por qué un servidor de inferencia dedicado on-premise es la respuesta de vanguardia en 2026 para cualquier despliegue robótico lo bastante serio como para hacer trabajo útil.

I01 explica cómo se conectan entre sí el robot y el servidor. Este artículo trata de por qué habría usted de comprar el servidor. Si todavía se pregunta si el on-premise tiene sentido, lea esto primero.

El presupuesto de latencia de decisión

Cada acción que ejecuta un robot se sitúa en uno de los cuatro niveles de latencia. Cada nivel tiene un presupuesto que impone la física de la tarea: si no lo cumple, el comportamiento se rompe de una forma concreta y reconocible.

No son cifras arbitrarias. Proceden del ancho de banda del bucle cerrado en el que se encuentra cada nivel.

El control reactivo funciona de 500 Hz a 1 kHz a nivel de articulación porque así lo exige la dinámica de la pierna de un humanoide de 30 kg: a 100 Hz el miembro entra en resonancia y la marcha diverge. La percepción refleja hereda la frecuencia de imagen de las cámaras (30–60 FPS = 16–33 ms por fotograma) y la escala temporal del contacto físico (un dedo que presiona un objeto cierra un evento de contacto en 20–40 ms). La planificación deliberativa está acotada por las expectativas conversacionales humanas (un segundo se percibe como ágil, dos como lento) y por la latencia de un VLM que resulte útil. El razonamiento estratégico es el único nivel con holgura real, y por eso todo el mundo quiere empujar la planificación hacia él y acaba pagándolo cuando su VLM no da la talla.

Esto no es una opinión de Kentino. El presupuesto de cuatro niveles es la partición que integra toda pila de control robótico solvente: ROS 2, Isaac, Drake, OCS2. Lo que varía es el hardware que se pone detrás de cada nivel.

Qué puede y qué no puede hacer el cómputo a bordo

Un humanoide de 2026 lleva en lo más alto de su ficha técnica una NVIDIA Jetson AGX Orin: 64 GB de memoria unificada, hasta 275 TOPS INT8 dispersos (138 densos) y un consumo configurable de 15–60 W. Es algo genuinamente notable para un módulo embebido. También está muy lejos de lo que necesita un robot moderno gobernado por un VLM.

Haga las cuentas con tres clases de modelo que realmente querría ejecutar en un humanoide:

La Orin AGX de 64 GB alojará un VLM de clase 32B en INT4 si acepta una inferencia lenta, sin batching real y sin cargas de trabajo concurrentes. No alojará los VLM de clase 70B que son de vanguardia en comprensión de escenas en 2026: Qwen2.5-VL 72B, las variantes grandes de Cosmos o los modelos propietarios cuyos pesos los fabricantes no publican. La suma de pesos, caché KV para contexto visual largo y margen para un segundo modelo no cabe.

Hay un segundo dato que se suele pasar por alto: la energía. La cifra de 275 TOPS de la Orin presupone el modo MAX_N (60 W). Eso es una plataforma alimentada por batería quemando 60 W de cómputo por encima de los 200–800 W de carga de los actuadores. Mantener MAX_N de forma sostenida reduce a la mitad la autonomía del robot. En la práctica, la Orin pasa la mayor parte del tiempo en modo 30 W, lo que recorta los TOPS aproximadamente a la mitad y lleva una inferencia ya de por sí justa al terreno de lo «inservible».

Traducción: la Jetson a bordo está dimensionada para los niveles reactivo y reflejo. No está dimensionada para alojar un VLM. Quien le diga que su humanoide «ejecuta Qwen2.5-VL a bordo» o está ejecutando el modelo de 3B o 7B y dándolo por bueno, o está ejecutando el modelo grande a 0,5 FPS y llamándolo demo. Ambas cosas valen para casos de uso concretos. Ninguna es percepción robótica de propósito general.

Por qué la nube es la respuesta equivocada para la robótica en bucle cerrado

La inferencia en la nube es barata, escala sin esfuerzo y no exige capex. Para un robot tiene cuatro problemas, más o menos por orden de gravedad.

1. El suelo de latencia de la WAN. Una llamada a la nube bien afinada dentro de la UE alcanza 15–40 ms de ida y vuelta solo en la WAN, más 5–15 ms de sobrecarga de TLS / HTTP / balanceador, más el tiempo de inferencia del modelo, más el viaje de vuelta. Cruzar el Atlántico añade otros 80–120 ms de ida y vuelta. Para una consulta de percepción refleja («¿hay un obstáculo delante de mí?»), añadir 30–50 ms antes incluso de que arranque el modelo supone incumplir el presupuesto. Para la planificación deliberativa a 200–500 ms quizá lo tolere, pero cada paquete perdido, cada retransmisión y cada conmutación de torre de telefonía lo catapultan al nivel superior.

2. Jitter. El RTT de la WAN no es una constante. Es una distribución. Mediana de 25 ms, P99 de 250 ms, P99.9 de varios segundos. Un robot que actúa en el mundo real no puede admitir una pausa de varios segundos porque haya oscilado una ruta BGP. El P99.9 de una LAN on-premise es de 1–2 ms.

3. Coste con carga sostenida. Una sola inferencia de un VLM de 70B apenas le cuesta nada a un proveedor de nube: cobra unos céntimos. Un robot que está «percibiendo siempre» hace una llamada al VLM cada 100–500 ms mientras está activo. Eso son de 7.000 a 36.000 llamadas por hora y por robot. Una flota de tres robots funcionando ocho horas al día en el extremo alto son 850.000 llamadas. Incluso a $0.005 por llamada en un endpoint alojado de 72B, son $4,250 al día y $125k al mes. Un servidor on-premise con 8 GPU se amortiza en menos de tres meses con esa carga.

4. Soberanía del dato. El robot ve una planta de fábrica, la habitación de un paciente, un laboratorio de investigación, un almacén con una distribución de inventario propietaria, un campo de entrenamiento militar. Ese vídeo está protegido o regulado por el RGPD, HIPAA, ITAR o la simple sensibilidad competitiva. Enviarlo a una nube de terceros —aunque firme un acuerdo de tratamiento de datos— o está prohibido o supone una carga de cumplimiento nada trivial. La inferencia on-premise hace desaparecer la cuestión de la soberanía del dato: los bytes nunca salen del edificio.

Hay un quinto problema, más difuso: el bloqueo con el proveedor. Las API de nube sirven los modelos que el proveedor quiere servir, con las cuantizaciones y las ventanas de contexto que el proveedor ha elegido. Usted no puede ejecutar un VLM ajustado a medida en el endpoint de OpenAI. No puede fijar un commit concreto de un modelo de pesos abiertos. No puede mezclar en una misma canalización modelos de fabricantes rivales. Para prototipar, estas restricciones no molestan. Para un despliegue robótico en producción que debe ser predecible durante años, sí.

El argumento del servidor dedicado en el borde

Un servidor de inferencia dedicado on-premise vive en la LAN, a uno o dos saltos del robot. Para la línea Kentino AI se trata de un servidor de rack de 4U, con host EPYC o Xeon, 4 u 8 GPU, conectado a un switch de 10 GbE. Las cifras que aporta:

Las dos columnas en las que la opción on-premise arrasa son el rendimiento sostenido y la elección de modelo. Son también las dos que más pesan en las cargas de trabajo que enumeramos a continuación.

Un Kentino AI 256 Turin Dual representativo, con 8× RTX 5090, reúne 256 GB de VRAM agregada y 1,0–1,5 kW de consumo de GPU bajo carga. Es suficiente para alojar simultáneamente:

• Qwen2.5-VL 72B en INT4 (~45–50 GB de pesos + 10–20 GB de KV por pareja de GPU, con paralelismo de tensores sobre 4 GPU)
• Qwen2.5 32B solo texto (planificación, diálogo) en 2 GPU
• Un VLA pequeño (OpenVLA 7B o Cosmos-Reason 7B) en 1 GPU para la intención de movimiento
• Memoria de escena / almacén RAG (pgvector o ChromaDB) en la CPU del host
• Capacidad de ajuste fino de políticas en línea en la GPU restante mientras el robot está en su base

El TTFT del VLM Qwen2.5-VL 72B en este hardware se sitúa en el rango de 200–400 ms con una sola petición, y sube a 1–4 segundos con fuerte carga concurrente. El streaming de tokens va a 25–50 tok/s. Eso basta para situar un VLM de 72B en el nivel de planificación deliberativa (100 ms – 1 s) con un robot, y en el de razonamiento estratégico (1 s – varios s) para una flota pequeña. Ninguno de los dos niveles es un problema; los niveles reactivo y reflejo se quedan a bordo, que es donde deben estar.

Brecha de capacidad: qué cubre únicamente el nivel de borde dedicado

El servidor on-premise no es solo «el mismo robot, pero más rápido». Habilita una clase de cargas de trabajo que los otros dos niveles no pueden alojar por razones estructurales. La lista honesta:

1. Realimentación de comprensión de escena en tiempo real. Un VLM de 72B mirando la cámara del robot cada 200–500 ms y devolviendo una descripción estructurada de la escena que consume el planificador. La nube no puede hacerlo a escala por el jitter de la WAN y por el coste. A bordo no se puede porque el modelo no cabe. On-premise cierra el bucle en 250–500 ms en total.

2. Fusión multicámara con VLM. Un humanoide tiene de 3 a 5 cámaras (cabeza, dos muñecas, dos de cuerpo o pecho). Ejecutar un VLM sobre todas ellas a la vez —para anclaje espacial, gestión de oclusiones o coordinación ojo-mano— multiplica por cinco la carga de inferencia. La nube limita la cuota o cobra por flujo. A bordo cabe un flujo a pequeña escala. On-premise agrupa los cinco en el mismo endpoint de VLM.

3. Planificación de tareas de horizonte largo con memoria de escena persistente. «Ayer dejé la llave inglesa en el segundo estante. Encuéntrala.» Esto exige un VLM, un LLM y un almacén vectorial funcionando juntos con estado persistente entre sesiones del robot. Ese estado tiene que vivir en algún sitio estable, consultable y rápido. Eso es una base de datos en el servidor, no una ventana de contexto en la nube por llamada, ni 4 GB de RAM en la Jetson.

4. Ajuste fino de políticas en línea. El robot recoge demostraciones de tareas durante el día. Por la noche, mientras está en su base, usted ejecuta ajustes finos LoRA sobre los datos del día contra un VLA base, publica el adaptador actualizado y mañana el robot es mejor. Esto supone de 2 a 5 veces la huella de memoria de la inferencia. La nube factura entrenamiento y almacenamiento por separado. On-premise lo absorbe en la misma máquina.

5. Coordinación de flotas multirrobot. Dos o tres robots que comparten una memoria de escena, se coordinan en las tareas y vigilan el estado de los demás. La capa de coordinación entre robots quiere una latencia inferior a 10 ms. On-premise, con un servidor compartido en la LAN, la ofrece. La nube no: la actualización de cada robot sale hacia una región, vuelve y llega al siguiente robot.

6. Iteración sim-to-real. Isaac Sim ejecutándose en las mismas GPU que sirven la inferencia, generando datos sintéticos de entrenamiento y validando las actualizaciones de política antes de que lleguen al robot real. Eso es medio día por iteración en la nube (solo por el movimiento de datos) y un bucle de 30 minutos on-premise.

Nada de esto es ciencia ficción. Todas son cargas de trabajo que los integradores de robótica ejecutan hoy, en 2026. Ninguna funciona con soltura en ninguno de los otros dos niveles.

Por qué esta es la respuesta de vanguardia en 2026

El estado del arte en percepción robótica en 2026 es el VLM en el bucle. El modelo mira el mundo, razona sobre él en lenguaje, emite planes estructurados y la política los ejecuta. Esto era una idea de investigación en 2023, una demo de producto en 2024 y es un patrón de producción en 2025–2026.

La tendencia que fuerza el nivel on-premise es sencilla: los VLM que funcionan son cada vez más grandes, no más pequeños. Qwen2.5-VL 7B es bueno. Qwen2.5-VL 72B es sensiblemente mejor. Los modelos propietarios que los laboratorios punteros no publican son aún mayores. La vía del «VLM pequeño que corre en el dispositivo» existe y seguirá existiendo, pero va de 12 a 18 meses por detrás de la frontera, con una brecha de capacidad apreciable. Si quiere el comportamiento de la frontera, aloje el modelo de la frontera. Y el modelo de la frontera no cabe en una Jetson.

La nube podría seguir el ritmo en teoría. En la práctica no lo hace, por las cuatro razones anteriores (latencia, jitter, coste, soberanía) y porque los laboratorios punteros reservan los modelos más grandes a niveles de asociación a los que una startup de robótica no tiene acceso. Los VLM de pesos abiertos de clase 70B sí existen, sí se pueden alojar y rinden bien en servidores de 8 GPU estándar. Esa confluencia —modelos de pesos abiertos de clase frontera más hardware multi-GPU de mercado— es la razón de que on-premise sea la respuesta correcta ahora mismo y no lo fuera en 2023.

Esto tampoco es una opinión de Kentino. El nivel de inferencia on-premise es aquello sobre lo que está construida la pila Isaac de NVIDIA, aquello para lo que las grandes plataformas de robótica publican arquitecturas de referencia y aquello que está aprovisionando todo integrador serio con el que hemos hablado en los últimos seis meses. El mercado alcanzó al hardware, que alcanzó a los modelos, y 2026 es el año en que todo encajó.

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

Para ser honestos: el nivel de borde dedicado es excesivo en varios casos reales.

• Robots teleoperados. El operador es el planificador. El robot es una marioneta con un enlace de control. No hay VLM en el bucle; la poca inferencia que se hace (estimación de pose, codificación de vídeo de baja latencia) corre en la Jetson. Añada nube para lo pesado si hace falta. No se necesita servidor de GPU.
• Cuadrúpedos de inspección sencillos. Un robot de clase Spot o Go2 recorriendo una ronda fija con detección de nivel YOLO y una cámara térmica no necesita un VLM de 72B. La Jetson a bordo hace el trabajo. Los datos van a la nube para su análisis después de la ronda, no durante.
• Demos y pilotos puntuales. Necesita el sistema funcionando para una feria, una presentación a cliente o una prueba de concepto de tres semanas. La nube se lo resuelve en una tarde. El capex on-premise es un error para una carga que se va a desmontar en un mes.
• Uso aficionado y educativo. Un laboratorio universitario con un G1 EDU, presupuesto ajustado y foco en el entrenamiento por refuerzo más que en la inferencia. La Jetson y una estación de trabajo con una sola 4090 bastan para investigar con sentido. El nivel completo Kentino AI de 8 GPU es una factura con la forma equivocada.
• Cargas puramente lingüísticas. Un robot que habla pero no ve: un asistente de voz con patas. Una API de LLM en la nube vale. El presupuesto de latencia es conversacional, no de bucle cerrado.

El patrón: si su robot no ejecuta un VLM real dentro del bucle cerrado de percepción, no necesita el nivel de borde dedicado. Si lo ejecuta, sí.

Cuándo la vía on-premise se justifica

El nivel de borde dedicado pasa a ser la respuesta correcta cuando se cumple al menos una de las siguientes condiciones, e idealmente dos o más:

1. Hay un VLM real en el bucle cerrado. No «para preguntas ocasionales», sino dentro del bucle de percepción-acción, ejecutándose cada 100–500 ms. Esta es la razón estructural de que exista el on-premise.
2. Carga sostenida. Ocho horas al día, cinco días a la semana, de forma indefinida. El capex se amortiza. El coste por llamada en la nube se acumula sin fin.
3. Los datos no pueden salir del edificio. RGPD, HIPAA, ITAR, competencia o simple prudencia. Los bytes se quedan en la LAN. No es negociable.
4. Varios robots. Dos o más unidades compartiendo memoria de escena o coordinando tareas. La amortización del servidor compartido se reparte por robot y el presupuesto de latencia entre robots se desploma.
5. La personalización importa. VLM ajustados a medida, versiones de modelo fijadas, cabezas propietarias sobre backbones abiertos, cuantizaciones de nicho. La libertad es el producto.
6. La velocidad de iteración importa. El equipo publica actualizaciones de política cada semana o más a menudo. Simulación y entrenamiento en el mismo hardware que la inferencia reducen el ciclo de días a horas.

Si marca tres o más de esos puntos, la pregunta ya no es si on-premise, sino de qué tamaño. El nivel Kentino AI 96 de cuatro GPU (RTX 4090 o 5090) basta para un robot haciendo trabajo real. El Kentino AI 256 de ocho GPU (5090 o Pro 6000 Blackwell) es la forma adecuada para una flota pequeña, para los VLM más grandes o para cualquier despliegue que, además de inferencia, requiera entrenamiento.

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 son bienvenidos en info@kentino.com.