Edge AI vs IA en la nube es una de las primeras decisiones de arquitectura en cualquier proyecto IoT con machine learning, y equivocarse se nota más tarde en alertas lentas, facturas de ancho de banda enormes o revisiones de privacidad que bloquean el despliegue. Esta comparativa explica dónde gana cada enfoque en latencia, privacidad, coste y tamaño del modelo, te da una lista de comprobación para decidir y muestra un patrón híbrido en el que los resultados del edge fluyen por MQTT hacia modelos en la nube.
Los dos enfoques en resumen
Edge AI ejecuta la inferencia en el dispositivo o en un gateway a su lado. Los datos del sensor se quedan en local y el dispositivo publica conclusiones: una etiqueta de clase, una puntuación de anomalía, un recuento. Si necesitas una introducción, empieza por qué es edge AI.
La IA en la nube envía los datos a servidores donde los modelos se ejecutan con una capacidad de cómputo prácticamente ilimitada. El dispositivo es una fuente de datos; la inteligencia reside de forma centralizada.
En la práctica, muy pocos sistemas en producción son puramente lo uno o lo otro. La pregunta útil es qué decisiones corresponden a cada lugar.
Edge AI vs IA en la nube: comparación lado a lado
| Factor | Edge AI | IA en la nube |
|---|---|---|
| Latencia | Milisegundos, sin ida y vuelta por la red | Ida y vuelta por la red más colas; varía con la conectividad |
| Funciona sin conexión | Sí | No |
| Ancho de banda | Bajo; solo los resultados salen del dispositivo | Alto si se transmiten datos en bruto (vídeo, audio, vibración de alta frecuencia) |
| Privacidad | Los datos en bruto se quedan en la instalación | Los datos en bruto salen de la instalación y deben protegerse en tránsito y en reposo |
| Tamaño del modelo | Limitado por la memoria y la energía del dispositivo | Modelos grandes, ensembles y LLM son viables |
| Contexto entre dispositivos | Solo lo que ve un dispositivo | Correlaciona todos los dispositivos, instalaciones e histórico |
| Actualización de modelos | Despliegue en la flota, versionado, reversión | Un único despliegue |
| Coste de hardware | Por dispositivo; los aceleradores encarecen | Infraestructura compartida; pagas cómputo y transferencia |
| Coste operativo | Principalmente fijo tras el despliegue | Crece con el volumen de datos y la tasa de inferencia |
| Monitorización | Más difícil; requiere telemetría de los dispositivos | Más fácil; logs y métricas centralizados |
Ninguna de estas filas es decisiva por sí sola. Una parada de seguridad que debe reaccionar en decenas de milisegundos pertenece al edge sea cual sea el coste. Una previsión para toda la flota que necesita el histórico de todas las instalaciones pertenece a la nube sea cual sea la latencia.
Latencia y fiabilidad
La inferencia en el edge está limitada por la capacidad de cómputo del dispositivo, y ese límite es predecible. La inferencia en la nube depende de la red, que no lo es. Los enlaces móviles, el Wi-Fi saturado de una fábrica y las ventanas de mantenimiento añaden retrasos o cortes. Si la acción que sigue a una predicción es física, como rechazar una pieza, detener una cinta o abrir una válvula, mantén la decisión en el edge y trata la nube como receptora del resultado.
Privacidad y gobierno de datos
Las cámaras y los micrófonos son los casos más claros. Enviar vídeo de personas a una nube de terceros plantea cuestiones de consentimiento, conservación y residencia de los datos. Ejecutar la detección en local y publicar "2 personas en la zona B" evita la mayoría de ellas. La misma lógica se aplica a los datos de producción que un fabricante considera confidenciales: una tasa de defectos es menos sensible que las imágenes de un producto nuevo.
Coste: adónde va el dinero
Edge AI concentra el coste al principio, en hardware e ingeniería: aceleradores, carcasas robustas y el trabajo de reducir los modelos. La IA en la nube convierte el coste en un gasto recurrente que escala con el volumen de datos. Para señales continuas de alta frecuencia, como el vídeo, enviarlo todo a la nube suele ser la opción cara. Para datos escasos, como una lectura cada pocos minutos, la inferencia en la nube puede salir más barata porque evitas hardware más inteligente en cada instalación. Estima ambas opciones con tus propias tasas de datos en lugar de fiarte de reglas generales.
Tamaño y capacidad del modelo
Los microcontroladores ejecutan modelos que se miden en kilobytes; los módulos edge con GPU ejecutan modelos de detección con millones de parámetros; la nube ejecuta lo que puedas pagar, incluidos los grandes modelos de lenguaje. Si la tarea requiere un conocimiento amplio del mundo, un contexto largo o razonar sobre muchas fuentes, pertenece a la nube. Si es una tarea de percepción acotada, como "¿este sonido es anómalo?", un modelo edge pequeño suele ser igual de preciso. Qué es TinyML explica hasta dónde se puede reducir.
Lista de comprobación para decidir
Responde a estas preguntas para cada predicción que haga tu sistema:
- ¿Depende una acción de la predicción en menos de un segundo? Si es así, edge.
- ¿Debe el sistema seguir funcionando sin internet? Si es así, edge.
- ¿Los datos en bruto son sensibles o están regulados? Si es así, mejor edge y publicar resultados derivados.
- ¿La tasa de datos en bruto es alta (vídeo, audio, sensores de kHz)? Si es así, mejor edge.
- ¿La predicción necesita datos de muchos dispositivos o un histórico largo? Si es así, nube.
- ¿El modelo necesita más memoria de la que tiene tu clase de dispositivo? Si es así, nube o un dispositivo edge de nivel gateway.
- ¿El modelo cambiará cada semana? En la nube es más fácil iterar; el edge necesita un pipeline de actualización sólido.
La mayoría de los proyectos acaban con un reparto: percepción en el edge, contexto y planificación en la nube.
El patrón híbrido: los resultados del edge fluyen por MQTT hacia modelos en la nube
La arquitectura híbrida tiene tres capas:
- Dispositivos edge que ejecutan modelos de percepción y publican resultados compactos en topics como
site/area/line/device/inference. - Un broker que distribuye esos resultados. Los dispositivos nunca necesitan saber quién los consume.
- Consumidores en la nube que se suscriben a los resultados de muchos dispositivos y ejecutan modelos de segunda etapa: detección de anomalías en la flota, previsiones, correlación de causas raíz o un LLM que resume los eventos para los operarios.
La nube también puede devolver decisiones: un nuevo umbral, una petición de muestra en bruto o un aviso de actualización del modelo publicado en un topic de comandos al que se suscribe el dispositivo.
MQTT encaja aquí porque los resultados del edge son eventos pequeños y frecuentes con muchos consumidores. Un broker MQTT en la nube se sitúa de forma natural entre las capas, de modo que los dispositivos edge se conectan hacia fuera por TLS y no hace falta abrir puertos de entrada en las redes de las instalaciones.
Ejemplo: un agregador en la nube
Este worker en Python se suscribe a los resultados de inferencia de todos los dispositivos bajo un prefijo y aplica una regla sencilla de segunda etapa sobre toda la flota: si varios dispositivos de la misma línea informan de anomalías en una ventana corta, publica una alerta a nivel de línea. Ese tipo de correlación es algo que ningún dispositivo edge individual puede hacer.
import json
import time
import uuid
from collections import defaultdict, deque
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/3f9c1a7e" # usa tu propio prefijo único
SUB = f"{PREFIX}/+/+/+/inference" # site/area/device/inference
WINDOW_S, MIN_DEVICES = 120, 2
recent = defaultdict(deque) # clave de línea -> deque de (ts, device)
def on_connect(client, userdata, flags, reason_code, properties):
print("connected:", reason_code)
client.subscribe(SUB, qos=1)
def on_message(client, userdata, msg):
_, _, _, site, area, device, _ = msg.topic.split("/")
result = json.loads(msg.payload)
if result.get("label") == "normal":
return
key = f"{site}/{area}"
now = time.time()
q = recent[key]
q.append((now, device))
while q and now - q[0][0] > WINDOW_S:
q.popleft()
devices = {d for _, d in q}
if len(devices) >= MIN_DEVICES:
alert = {"scope": key, "devices": sorted(devices), "window_s": WINDOW_S,
"reason": "correlated anomalies"}
client.publish(f"{PREFIX}/{site}/{area}/alerts", json.dumps(alert), qos=1)
print("ALERT", alert)
q.clear()
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"cloud-agg-{uuid.uuid4().hex[:6]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()
Simula dos dispositivos edge que informan de anomalías:
P=connectmq/demo/3f9c1a7e
mosquitto_pub -h broker.connectmq.com -p 1883 -i dev-a-81 -q 1 \
-t "$P/site1/pumps/pump-01/inference" -m '{"label":"bearing_wear","score":0.81}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i dev-b-82 -q 1 \
-t "$P/site1/pumps/pump-02/inference" -m '{"label":"cavitation","score":0.77}'
El agregador imprime y publica una alerta de línea. Cuando un solo worker no basta, ejecuta varias copias con una suscripción compartida de MQTT 5 como $share/agg/connectmq/... para que el broker reparta los mensajes entre ellas; en ConnectMQ, las suscripciones compartidas están disponibles a partir del plan Serverless (Paid). Ten en cuenta que un correlador con estado como este necesita que los mensajes de una misma línea lleguen al mismo worker, así que particiona por topic en lugar de compartir a ciegas.
Errores habituales en los sistemas híbridos
- Transmitir datos en bruto "por si acaso". Envía muestras en bruto solo bajo petición o ante una anomalía, por un topic separado.
- Dejar que la nube tome decisiones críticas en el tiempo. Mantén el reflejo en el edge y usa la nube para las políticas.
- Sin campos de versión. Cada resultado debe indicar la versión del modelo que lo generó para que los modelos en la nube puedan tener en cuenta los cambios.
- Ignorar los límites de tamaño de mensaje. Los resultados deben quedar muy por debajo del límite de tu broker; en el servidor MQTT público gratuito, pensado solo para pruebas y prototipos, ese límite es de 64 KB.
- Topics de comandos sin autenticación. Todo lo que pueda cambiar el comportamiento de un dispositivo debe pasar por un broker privado con credenciales y TLS.
Para saber más sobre cómo encajan estas capas en un sistema AIoT completo, lee la guía de IA e IoT, y cuando llegue el momento de elegir hardware, compara placas en hardware para edge AI comparado.
Conecta edge y nube con ConnectMQ
El patrón híbrido solo funciona si el enlace entre el edge y la nube es fiable y seguro. ConnectMQ ofrece un broker MQTT gestionado con MQTT 5, TLS en el puerto 8883 y suscripciones compartidas en los planes de pago, para que puedas centrarte en los modelos en lugar de en operar el broker. Crea un broker con el plan Serverless gratuito en app.connectmq.com, sin tarjeta de crédito.
Preguntas frecuentes
¿Es edge AI mejor que la IA en la nube?
Ninguna es mejor en general. Edge AI gana en latencia, funcionamiento sin conexión y privacidad; la IA en la nube gana en tamaño del modelo, contexto entre dispositivos y facilidad para iterar. La mayoría de los sistemas IoT usan ambas.
¿Puedo empezar en la nube y pasar al edge más adelante?
Sí, y es un camino habitual. Diseña primero el formato del mensaje de resultados para que, cuando la inferencia pase al dispositivo, los consumidores en la nube sigan recibiendo los mismos mensajes en los mismos topics.
¿Qué debe enviar un dispositivo edge a la nube?
Resultados de inferencia con marca de tiempo, confianza y versión del modelo, un latido periódico y muestras en bruto solo cuando se soliciten o cuando se detecte una anomalía.
¿La IA híbrida edge-nube necesita un broker de mensajería?
No es estrictamente necesario, pero un broker desacopla los dispositivos de los consumidores, gestiona la conectividad intermitente con QoS y sesiones y te permite añadir nuevos consumidores en la nube sin tocar los dispositivos.
