IA en el borde y despliegue en tiempo real

La IA en el borde (Edge AI) triunfa o fracasa en la ingeniería de despliegue, no en el modelo ni en el silicio: elegir el hardware adecuado para la carga de trabajo, optimizar el modelo para que quepa en ese hardware sin destruir la precisión, construir una canalización de inferencia con garantías de latencia determinista y mantener el sistema actualizado y monitoreado una vez que funciona en una torre de telefonía, un vehículo, una fábrica o una instalación de defensa. Esa ingeniería de despliegue es la disciplina en torno a la cual se construyen nuestros proyectos.

La selección de hardware es una decisión de ingeniería, no una relación con un proveedor

El panorama del silicio de borde en 2026 es el más fragmentado que jamás haya existido. Cada plataforma presenta un perfil distinto de cobertura de operadores, arquitectura de memoria, cadena de herramientas de compilación y curva de costos a gran escala.

La elección equivocada aquí es costosa y difícil de revertir. Un modelo optimizado para TensorRT en Jetson no se transfiere a la arquitectura de flujo de datos de Hailo ni al SDK QNN de Qualcomm sin un trabajo de reoptimización que puede llevar semanas. Antes de comprometernos, perfilamos las cargas de trabajo frente a las plataformas candidatas (con base en nuestra investigación sobre la latencia de la computación de borde industrial):

• Análisis de cobertura de operadores para la arquitectura del modelo.
• Modelado del ancho de banda de memoria: el verdadero cuello de botella en las FPGA es el ancho de banda de la DDR, no el cómputo.
• Simulación del envolvente térmico bajo carga sostenida.
• Costo total de propiedad al volumen de despliegue objetivo.

Un proyecto se define para producir una recomendación de hardware con una justificación cuantificada, no una preferencia de proveedor.

Optimización de modelos que no destruye lo que el modelo aprendió

Lograr que un modelo quepa en el hardware de borde es una canalización, no un solo paso, y el orden importa:

1. Búsqueda de arquitectura dentro de las restricciones del hardware: presupuesto de FLOP, conjunto de operadores admitidos, techo de memoria.
2. Entrenamiento consciente de la cuantización (QAT) orientado a precisión INT8 o INT4 con calibración por canal. La cuantización posterior al entrenamiento es más rápida pero poco fiable: los propios benchmarks de NVIDIA muestran una pérdida catastrófica de precisión en arquitecturas EfficientNet con PTQ tras el plegado de batch-norm, mientras que el QAT puede igualar o superar la precisión de referencia de FP32.
3. Poda estructurada guiada por análisis de sensibilidad, eliminando capacidad redundante sin desencadenar los precipicios de precisión que crea la poda no estructurada.
4. Destilación de conocimiento de un modelo maestro más grande para recuperar la precisión perdida en los pasos de compresión.

Elección de la cadena de herramientas de compilación

La elección de la cadena de herramientas de compilación determina qué es posible, por eso elegimos según el objetivo en lugar de recurrir por defecto a la que usamos la última vez:

• TensorRT ofrece de forma consistente la inferencia más rápida en hardware NVIDIA, pero es de código cerrado y exclusivo de NVIDIA.
• Apache TVM es multiplataforma y de código abierto, pero requiere un ajuste considerable; sin ajuste rinde por debajo de ONNX Runtime, mientras que con ajuste puede igualar a TensorRT en arquitecturas transformer (benchmark de MDPI Electronics, 2025).
• Xilinx Vitis AI maneja la cuantización INT8 para objetivos FPGA, pero tiene una cobertura de operadores parcial que obliga a reimplementar capas manualmente.

La latencia determinista no es la latencia promedio

La mayoría de los benchmarks de IA en el borde reportan el tiempo de inferencia promedio, un número casi inútil para despliegues críticos para la seguridad. Lo que importa es el tiempo de ejecución en el peor de los casos (WCET): lo máximo que jamás tardará el paso de inferencia bajo estrés térmico, presión de memoria, fluctuación de potencia y contención en la planificación del sistema operativo. Un sistema que promedia 2 milisegundos pero ocasionalmente se dispara a 15 milisegundos durante las pausas de recolección de basura no es un sistema en tiempo real (una restricción en torno a la cual está construido nuestro demo funcional de inspección de fabricación con IA en el borde ). Es un sistema rápido que a veces no es lo suficientemente rápido.

Nuestro enfoque consiste en construir canalizaciones de inferencia diseñadas para la cola, no para el promedio:

• Búferes de memoria preasignados para eliminar la fluctuación de asignación.
• Afinidad de CPU fijada para evitar la migración por el planificador.
• Preprocesamiento acelerado por hardware para mantener la ruta de datos fuera de la CPU.
• Posprocesamiento de salida con calibración de confianza ajustada para la distribución de salida desplazada del modelo cuantizado.

En objetivos FPGA, diseñamos para una inferencia determinista de submilisegundo sin ninguna capa de planificación por software; la fusión de sensores basada en FPGA ha demostrado 5,51 ms de latencia con un 99,3 % de precisión en benchmarks académicos (Springer, 2025). Para objetivos basados en GPU, usamos gráficos CUDA y lanzamientos de kernels persistentes para minimizar la sobrecarga del controlador, con análisis de WCET que caracteriza la latencia de cola bajo estrangulamiento térmico. El estrangulamiento térmico por sí solo puede reducir la velocidad de inferencia en un 30 a 50 % en cargas de trabajo sostenidas (benchmark militar de SINTRONES), de modo que un sistema diseñado solo para el caso promedio falla precisamente en las condiciones donde la fiabilidad más importa.

Actualizaciones OTA para modelos que funcionan en campo

Desplegar un modelo es el comienzo, no el final. Los modelos se desvían a medida que el mundo cambia a su alrededor: degradación de sensores, cambios ambientales, cambios en la cadena de suministro que alteran la distribución de los datos. Detectar la deriva en el borde es más difícil que en la nube porque el ancho de banda es limitado y no se puede transmitir telemetría en bruto a un sistema central sin agotar el presupuesto de conectividad. Implementamos la detección de deriva del lado del borde usando métodos estadísticos: divergencia KL y índice de estabilidad poblacional , calculados localmente, enviando aguas arriba solo métricas resumidas. Cuando la deriva supera los umbrales, el sistema puede activar flujos de trabajo de reentrenamiento automatizados o señalar el caso para revisión humana.

El propio mecanismo de actualización conlleva riesgos, y el adecuado depende del contexto regulatorio:

• Automoción: La UNECE R155 y la R156 son obligatorias para todas las nuevas homologaciones de tipo de vehículo desde julio de 2024. La R155 exige un Sistema de Gestión de Ciberseguridad en toda la cadena de suministro; la R156 exige un Sistema de Gestión de Actualizaciones de Software para todo el ciclo de vida del software del vehículo. Cualquier modelo de IA entregado mediante OTA se rige por la R156.
• Dispositivos médicos: El borrador de directriz de la FDA de enero de 2025 sobre funciones de software de dispositivos habilitados con IA introduce el Plan de Control de Cambios Predeterminado, que permite actualizaciones de modelos posteriores a la comercialización sin una nueva presentación si los cambios se mantienen dentro de parámetros preaprobados. La FDA autorizó 295 dispositivos médicos habilitados con IA/ML en 2025, con un 62 % clasificados como Software como Dispositivo Médico.
• Defensa y soberanía: La OTA a menudo no es una opción en absoluto. Los entornos aislados (air-gapped) usan medios físicos firmados criptográficamente o diodos de datos unidireccionales, con verificación de integridad acorde a los requisitos de seguridad a nivel de componente de la IEC 62443-4-2 (esta clase de compilación de borde denegada y desconectada es para lo que está diseñado nuestro demo funcional de autonomía de drones en entornos sin GPS ).

Diseñamos infraestructura de actualización que se ajusta al contexto: cumplimiento SUMS automotriz, documentación PCCP de la FDA o flujos de trabajo con medios físicos aislados y seguimiento de la cadena de custodia.

Cuándo la IA en el borde es la elección equivocada

No toda carga de trabajo de inferencia pertenece al borde. Es la elección equivocada en cuatro situaciones:

• Los modelos de lenguaje grandes por encima de aproximadamente 7.000 millones de parámetros : no funcionan de forma significativa en el silicio de borde actual fuera de versiones fuertemente cuantizadas y con capacidad reducida.
• Cargas de trabajo con arquitecturas de modelo que cambian rápidamente, donde se prevé cambiar de familia de modelos trimestralmente: la inferencia en la nube las sirve mejor, porque cada ciclo de optimización específico del hardware añade semanas.
• Despliegues de bajo volumen por debajo de unos pocos cientos de dispositivos, que rara vez alcanzan el punto de cruce del TCO donde la inversión en hardware de borde se amortiza; el costo de la inferencia en la nube a esa escala es manejable.
• Cargas de trabajo donde los datos ya están en la nube, como el análisis de datos agregados de muchos sitios: llevar la inferencia al borde no aporta nada.

El punto de cruce del TCO para el borde frente a la nube suele situarse entre los 12 y 24 meses según el volumen de despliegue y la frecuencia de inferencia. A gran escala los números son decisivos: 50.000 dispositivos que ejecutan 60 inferencias por minuto generan aproximadamente 3.000 millones de llamadas a la API al mes, lo que se traduce en aproximadamente 300.000 dólares mensuales solo en costos de inferencia en la nube (análisis del sector de CIO). El hardware de borde para esa flota cuesta más por adelantado, pero se estabiliza en 10 dólares por dispositivo al mes en costos continuos, con un consumo de energía de 10 a 25 vatios por nodo. Modelamos el punto de equilibrio del TCO para cada proyecto, de modo que la decisión se fundamente en números, no en suposiciones.

IA multimodal y generativa en el borde

El borde ya no se limita a los modelos de clasificación y detección:

• Los modelos de visión y lenguaje Cosmos Nemotron de NVIDIA funcionan en Jetson Orin para el razonamiento multiimagen.
• El 10H de Hailo ejecuta modelos de lenguaje de 2.000 millones de parámetros con una latencia de primer token de menos de un segundo y un rendimiento de más de 10 tokens por segundo a menos de 5 vatios.
• La plataforma Modalix de SiMa.ai se asoció con Cerence para llevar CaLLM Edge, un modelo de lenguaje pequeño embebido de grado automotriz, al silicio de borde.
• Latent AI lanzó lo que denomina la primera plataforma de IA de borde agéntica del sector, combinando la optimización de modelos con MLOps automatizado para flujos de trabajo basados en agentes en hardware de borde.

Los dispositivos de borde ahora pueden ejecutar respuesta a preguntas visuales, interfaces de operador en lenguaje natural (véase nuestro whitepaper sobre el imperativo arquitectónico más allá de los envoltorios de API para la IA de voz) y cadenas de razonamiento breves que antes requerían viajes de ida y vuelta a la nube. Las restricciones son reales: las ventanas de contexto son limitadas, los tiempos de respuesta escalan con la longitud de la secuencia y se necesita una ingeniería de prompts cuidadosa para mantenerse dentro de la distribución de salida fiable del modelo cuantizado. Ayudamos a los equipos a identificar qué capacidades generativas se benefician del despliegue en el borde frente a cuáles se sirven mejor con una llamada a la nube y almacenamiento en caché en el borde.