Cuando la decisión de un sistema de inteligencia artificial tiene que tomarse en unas decenas de milisegundos y junto a una cinta transportadora que no se detiene, la conversación sobre qué modelo usar cambia por completo. Ya no importa tanto cuál es el modelo más capaz en un benchmark académico, importa cuál cabe en el equipo que hay realmente instalado en planta, responde dentro del ciclo de la máquina y se puede mantener en cien ubicaciones sin enviar a nadie a cada una. Ese es el terreno de la inferencia en el edge, y es un terreno que se rige por restricciones físicas, no por la conversación habitual sobre qué modelo es más grande o más preciso.
Latencia como requisito de proceso, no como métrica de rendimiento
En la nube, la latencia se mide en la conversación de rendimiento: cuántos milisegundos tarda una respuesta y si eso afecta a la experiencia de usuario. En el edge industrial, la latencia es un requisito de proceso, no una métrica de calidad. Si una máquina tiene que decidir si rechaza una pieza antes de que llegue al siguiente punto de la línea, esa decisión tiene una ventana de tiempo fija, marcada por la velocidad física de la cinta, no por lo que sea razonable para un servidor.
Esa ventana suele ser de decenas de milisegundos, y dentro de ella hay que meter la captura, el preprocesado, la inferencia y la actuación. Un modelo que en la nube tardaría unos segundos en responder, sencillamente no sirve, por muy preciso que sea.
Hardware real: qué se puede ejecutar en un equipo industrial y con qué consumo
El hardware disponible en el edge industrial no es el mismo que el de un centro de datos. Son equipos con memoria limitada, sin refrigeración activa potente, a menudo con restricciones de consumo eléctrico y pensados para operar de forma continua durante años en condiciones de planta, con polvo, vibración y variación de temperatura. Un modelo que asume la disponibilidad de una GPU de centro de datos no tiene sentido en ese contexto.
El benchmark MLPerf Tiny de MLCommons, desarrollado específicamente para medir el rendimiento de sistemas de inferencia de muy bajo consumo, es una referencia útil a la hora de comparar hardware de edge de forma objetiva, en lugar de fiarse solo de las cifras que ofrece cada fabricante. Mide no solo la velocidad, sino también el consumo energético, que en dispositivos que llevan años funcionando de forma ininterrumpida es tan relevante como la precisión del modelo.
Modelos pequeños bien afinados frente a modelos grandes generalistas
Aquí está la decisión de fondo del artículo. Frente a la tentación de desplegar un modelo grande y generalista, capaz de resolver muchas tareas a la vez, la alternativa que suele funcionar mejor en el edge es un modelo pequeño, afinado específicamente para la tarea concreta que tiene que resolver en ese punto de la línea. Es una decisión que no va sobre coste total de propiedad, sino sobre restricción física: el modelo generalista simplemente no cabe, no responde a tiempo o consume más de lo que el equipo puede disipar.
Un modelo pequeño bien afinado con datos propios del proceso suele superar en la práctica a un modelo grande genérico para esa tarea concreta, precisamente porque no tiene que repartir su capacidad entre casos que nunca se van a dar en esa línea. Es la misma lógica de especialización que aparece en el primer blog de este número, sobre visión artificial en planta: el dataset propio y la tarea concreta pesan más que la capacidad genérica del modelo.
Mantenimiento en campo: actualizar cien dispositivos no se parece a actualizar un servidor
El coste que más se subestima al planificar un despliegue de inferencia en el edge no es el del hardware inicial, es el de mantenerlo en el tiempo. Un modelo desplegado en un servidor centralizado se actualiza una vez y ya está disponible para todos los que lo consumen. Un modelo desplegado en cien dispositivos de planta, repartidos por distintas líneas o incluso distintas plantas, se opera como una flota: hace falta gestionar versiones, poder hacer rollback si una actualización falla, comprobar que la actualización llegó a cada dispositivo y decidir qué pasa con los que no responden.
Este es un problema de gestión de flota, no de ciencia de datos, y conviene diseñarlo desde el principio del proyecto, no añadirlo después como una ocurrencia tardía. La conectividad intermitente propia de muchos entornos industriales hace que ese mecanismo de actualización tenga que tolerar dispositivos que tardan días en recibir un cambio, sin que eso rompa la coherencia del sistema.
Qué pasa si se cae la línea de datos
En el edge, las preguntas que ordenan el proyecto son físicas antes que algorítmicas: qué cabe en el equipo que hay en planta, si responde dentro de la ventana que marca la línea y si alguien podrá mantenerlo con los años sin desplazarse a cada ubicación. Y ese equipo no vive aislado, porque forma parte de una red de planta cuya convergencia entre IT y OT conviene tener resuelta, del mismo modo que un proyecto de visión artificial en planta depende de su dataset y de su umbral. Cuando todo encaja, el modelo pequeño deja de ser una concesión y se convierte en la mejor decisión de ingeniería.
