Edge Computing para IA

¿Qué es Edge Computing?

Edge Computing es el paradigma de ejecutar modelos de inteligencia artificial directamente en dispositivos cercanos a la fuente de datos — en el "borde" (edge) de la red — en lugar de enviar los datos a un servidor remoto en la nube. Esto incluye dispositivos embebidos, móviles, cámaras inteligentes, drones, robots, wearables, y aceleradores dedicados.

En los últimos años, el auge del deep learning ha producido modelos cada vez más potentes (como los vistos en la sección de Transformers o LLMs), pero también más pesados. Esto ha creado una tensión fundamental: la inteligencia se genera en la nube, pero los datos y las acciones ocurren en el mundo real. Edge AI resuelve esta tensión llevando la inferencia al dispositivo, más cerca de donde se origina la información y donde se necesita la respuesta.

Es importante distinguir entre entrenamiento e inferencia. El entrenamiento de modelos de deep learning (como se explica en Entrenamiento de redes neuronales) requiere grandes cantidades de cómputo y se realiza típicamente en la nube, con GPUs como A100 o H100. La inferencia, en cambio, consiste en aplicar un modelo ya entrenado a nuevos datos, y es esta operación la que puede ejecutarse eficientemente en el edge con hardware especializado y modelos optimizados.

☁️ → 📱 El espectro Cloud-Edge

No es binario. Existe un continuo entre la nube y el dispositivo, y dependiendo de la aplicación, la inferencia puede ejecutarse en distintos puntos de ese espectro. Cada nivel ofrece un equilibrio diferente entre potencia de cálculo, latencia, privacidad y coste. A continuación se presentan los cuatro niveles más habituales:

Cloud vs Edge: los retos de la nube

Enviar todos los datos a la nube parece la solución obvia (GPUs potentes, escalabilidad infinita), pero en la práctica hay 5 problemas críticos que hacen inviable este enfoque para muchas aplicaciones:

Pensemos en un ejemplo concreto: una flota de 100 cámaras de seguridad 4K en una fábrica. Si cada cámara envía su stream a la nube para procesamiento con un modelo de detección de objetos (como los que se estudian en Detección de objetos), estaremos generando ~1.2 Gbps de datos de subida, con una latencia de ida y vuelta de 100–200 ms, y un coste mensual de miles de dólares en ancho de banda y computación cloud. Si en lugar de eso procesamos cada cámara localmente con una NPU de $70, la latencia baja a <5 ms, no necesitamos ancho de banda y el coste total es fijo.

¿Por qué Edge AI ahora?

Edge computing para ML no es nuevo — la investigación en redes neuronales compactas existe desde los años 90 — pero tres factores han convergido en la última década para hacerlo viable, accesible y explosivamente demandado:

A estos tres factores se suma un cuarto: la demanda regulatoria y social de privacidad. Regulaciones como el GDPR (Europa), HIPAA (salud en EE.UU.) y la creciente preocupación por la soberanía de los datos han hecho que procesar la información in situ, sin que salga del dispositivo, sea no solo una ventaja técnica sino un requisito legal en muchos dominios.

Métricas clave en Edge AI

En edge computing, la accuracy no es la única métrica (a diferencia de lo habitual en entrenamiento, donde se optimiza principalmente la precisión del modelo — ver Machine Learning Clásico para una revisión de métricas de evaluación). En el edge hay que optimizar un multi-objetivo que equilibra rendimiento, consumo, tamaño y coste:

Para comprender estas métricas, es útil pensar en un ejemplo: si desplegamos un modelo de detección de objetos en un dron agrícola alimentado por batería, nos importa que el modelo sea preciso, pero también que consuma poca energía (para maximizar el tiempo de vuelo), que sea rápido (para procesar cada frame en tiempo real), y que quepa en la memoria del acelerador embebido (típicamente 1–8 GB).

Widget: calculadora Cloud vs Edge

Compara el coste total de propiedad (TCO) de desplegar inferencia en la nube vs en dispositivos edge durante un período determinado.

Historia del Edge AI

Panorama del hardware para Edge AI

No todos los aceleradores son iguales. Cada tipo de hardware tiene un perfil diferente de rendimiento, consumo, flexibilidad y coste. Elegir el correcto depende de la aplicación. A continuación se resumen los seis tipos principales de aceleradores para edge AI, ordenados de mayor eficiencia energética (TOPS/W) a mayor flexibilidad de programación:

NPUs: Neural Processing Units

Una NPU (Neural Processing Unit) es un circuito integrado (ASIC) diseñado exclusivamente para ejecutar operaciones de redes neuronales: convoluciones, multiplicaciones de matrices, activaciones. No puede correr código arbitrario como una GPU — pero al estar especializado, alcanza una eficiencia energética extraordinaria.

Para entender por qué las NPUs son tan eficientes, hay que recordar qué operaciones dominan en una red neuronal. Como se explica en MLP y Convolución y fundamentos, las redes neuronales consisten fundamentalmente en multiplicaciones de matrices (operaciones MAC: Multiply-ACcumulate) seguidas de funciones de activación. Una GPU de propósito general dedica una parte significativa de su silicio a control de flujo, cachés y unidades de punto flotante de alta precisión (FP32/FP64). Una NPU, en cambio, elimina todo lo innecesario y dedica prácticamente todo su silicio a arrays masivos de unidades MAC en aritmética entera (INT8), con un flujo de datos tipo dataflow que minimiza el movimiento de datos — la operación más costosa energéticamente en un chip (consultar Sze et al., 2020 para una revisión completa de arquitecturas de hardware para DNN).

Hailo

Hailo es el fabricante de NPUs más relevante en edge AI. Su chip Hailo-8 ha sido adoptado por Raspberry Pi, drones, cámaras de seguridad y vehículos autónomos.

Otras NPUs relevantes

GPUs Edge: NVIDIA Jetson

La familia NVIDIA Jetson lleva GPUs CUDA completas al edge. A diferencia de las NPUs, las GPUs son programables: pueden ejecutar cualquier modelo, cualquier framework, con soporte completo de CUDA, cuDNN y TensorRT.

Esta flexibilidad es crucial en escenarios donde el modelo cambia frecuentemente, donde se necesitan operadores personalizados, o donde la aplicación combina múltiples modelos en un pipeline complejo (por ejemplo, detección + seguimiento + reconocimiento facial + análisis de comportamiento). Mientras que una NPU requiere recompilar y validar cada modelo contra su set de operadores soportados, en Jetson basta con exportar el modelo desde PyTorch y optimizarlo con TensorRT — el mismo workflow que en cualquier GPU de servidor, pero en un módulo que consume 7–60 W. La documentación oficial de NVIDIA para Jetson Developer Kits incluye guías detalladas de cómo comenzar.

FPGAs para Edge AI

Una FPGA (Field-Programmable Gate Array) es un chip de lógica reconfigurable: puedes diseñar circuitos digitales a medida sin fabricar un ASIC. Esto la sitúa entre la flexibilidad de una GPU y la eficiencia de una NPU.

Las FPGAs destacan en aplicaciones donde se necesita determinismo temporal estricto: cada inferencia tarda exactamente el mismo tiempo, sin variabilidad (jitter). Esto es un requisito en dominios de seguridad funcional como la automoción (ISO 26262), la aviación (DO-254) y los sistemas médicos. Además, las FPGAs permiten implementar pipelines de procesamiento completamente en hardware, lo que puede lograr latencias de microsegundos o incluso nanosegundos — ordenes de magnitud más bajas que cualquier GPU o NPU. Para una introducción más amplia a la aplicación de FPGAs en aprendizaje profundo, véase la revisión de Venieris et al. (2018).

Xilinx / AMD Kria

La familia Kria de AMD (antes Xilinx) son System-on-Modules (SoMs) con FPGA + CPU ARM diseñados específicamente para Edge AI:

¿Qué es una DPU (Deep Processing Unit)?

La DPU es un IP core (bloque de propiedad intelectual) que se sintetiza dentro de una FPGA para acelerar inferencia de redes neuronales. AMD/Xilinx proporciona DPUs configurables:

Otros aceleradores edge

Widget: comparador de hardware edge

Selecciona dispositivos y compáralos en rendimiento, eficiencia y coste.

¿Por qué optimizar modelos para edge?

Un modelo ResNet-50 en FP32 ocupa ~98 MB y necesita ~4 GFLOPs por inferencia. Una YOLOv8-L pesa ~84 MB y requiere ~165 GFLOPs. Estos modelos no caben, o son demasiado lentos, en dispositivos con 1-8 GB de RAM y aceleradores de 4-40 TOPS. La solución: comprimir sin destruir.

Pruning (poda de redes)

Pruning elimina parámetros o estructuras redundantes de una red neuronal. La idea fundamental, formalizada en la célebre Lottery Ticket Hypothesis (Frankle & Carlin, 2019), es que dentro de una red grande existe una subred más pequeña (el "billete ganador") que, entrenada aisladamente, alcanza la misma accuracy que la red completa. En la práctica, muchos pesos son cercanos a cero y contribuyen poco a la salida: pueden eliminarse sin degradar significativamente el rendimiento.

El pruning puede verse como el complemento del entrenamiento: mientras que técnicas como las descritas en Regularización (weight decay, dropout) fuerzan al modelo a no depender de parámetros individuales, el pruning materializa esa redundancia eliminándolos explícitamente. Es importante distinguir dos enfoques fundamentalmente diferentes:

import torch
import torch.nn.utils.prune as prune

model = torch.hub.load('pytorch/vision', 'resnet18', pretrained=True)

# Pruning no-estructurado: eliminar 40% de pesos por magnitud
for name, module in model.named_modules():
    if isinstance(module, torch.nn.Conv2d):
        prune.l1_unstructured(module, name='weight', amount=0.4)

# Hacer permanente (eliminar el hook de pruning)
for name, module in model.named_modules():
    if isinstance(module, torch.nn.Conv2d):
        prune.remove(module, 'weight')

# Verificar sparsity
total = sum(p.numel() for p in model.parameters())
zeros = sum((p == 0).sum().item() for p in model.parameters())
print(f"Sparsity: {zeros/total*100:.1f}%")

# Pruning ESTRUCTURADO: eliminar 30% de filtros por norma L2
for name, module in model.named_modules():
    if isinstance(module, torch.nn.Conv2d):
        prune.ln_structured(module, name='weight', amount=0.3, n=2, dim=0)

Cuantización

Cuantización reduce la precisión numérica de los pesos y activaciones: de FP32 (32 bits) a INT8 (8 bits), INT4, o incluso binario. Es la técnica más impactante para edge: reduce tamaño 4× y acelera inferencia 2-4× en hardware con soporte nativo INT8.

La intuición detrás de la cuantización es que las redes neuronales son sorprendentemente robustas a la reducción de precisión. Durante el entrenamiento (ver Entrenamiento de redes neuronales), se usan gradientes en FP32 para hacer ajustes finos. Pero una vez entrenado, el modelo no necesita tanta precisión para inferir: los pesos solo se leen, no se actualizan. Matemáticamente, cuantizar consiste en mapear un rango continuo de valores a un conjunto discreto de niveles. Para cuantización uniforme asimétrica, la transformación es:

Donde \(s\) es el scale (factor de escala) y \(z\) es el zero point (offset para mapear el rango).

Tipos de cuantización

import torch
from torch.quantization import quantize_dynamic, quantize

# ═══════════════════════════════════════════════
# 1. Dynamic Quantization (sin dataset de calibración)
# ═══════════════════════════════════════════════
model_fp32 = ...  # tu modelo entrenado

model_int8 = quantize_dynamic(
    model_fp32,
    {torch.nn.Linear, torch.nn.LSTM},  # capas a cuantizar
    dtype=torch.qint8
)

# Comparar tamaños
import os
torch.save(model_fp32.state_dict(), "model_fp32.pt")
torch.save(model_int8.state_dict(), "model_int8.pt")
print(f"FP32: {os.path.getsize('model_fp32.pt')/1e6:.1f} MB")
print(f"INT8: {os.path.getsize('model_int8.pt')/1e6:.1f} MB")

# ═══════════════════════════════════════════════
# 2. Static Quantization (con calibración)
# ═══════════════════════════════════════════════
model_fp32.eval()
model_fp32.qconfig = torch.quantization.get_default_qconfig('x86')
model_prepared = torch.quantization.prepare(model_fp32)

# Calibrar con datos representativos
with torch.no_grad():
    for images, _ in calibration_loader:  # ~100-1000 batches
        model_prepared(images)

# Convertir a INT8
model_quantized = torch.quantization.convert(model_prepared)

import tensorflow as tf

# Cargar modelo entrenado
model = tf.keras.models.load_model('my_model.h5')

# ═══════════════════════════════════════════════
# 1. Post-Training INT8 Quantization
# ═══════════════════════════════════════════════
def representative_dataset():
    """Dataset de calibración (~100-1000 muestras)"""
    for images, _ in calibration_ds.take(200):
        yield [tf.cast(images, tf.float32)]

converter = tf.lite.TFLiteConverter.from_keras_model(model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_dataset
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
converter.inference_input_type = tf.uint8
converter.inference_output_type = tf.uint8

tflite_quant_model = converter.convert()

# Guardar
with open('model_int8.tflite', 'wb') as f:
    f.write(tflite_quant_model)

print(f"Tamaño: {len(tflite_quant_model) / 1e6:.1f} MB")

# ═══════════════════════════════════════════════
# 2. Quantization-Aware Training (QAT)
# ═══════════════════════════════════════════════
import tensorflow_model_optimization as tfmot

qat_model = tfmot.quantization.keras.quantize_model(model)
qat_model.compile(optimizer='adam', loss='sparse_categorical_crossentropy')
qat_model.fit(train_ds, epochs=3)  # Fine-tune con QAT

# Convertir a TFLite INT8
converter = tf.lite.TFLiteConverter.from_keras_model(qat_model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
tflite_qat = converter.convert()

Knowledge Distillation

Knowledge Distillation (Hinton et al., 2015) entrena un modelo pequeño (student) para imitar las salidas de un modelo grande (teacher). El student aprende no solo las etiquetas correctas, sino la distribución de probabilidades del teacher — las "soft labels" contienen información valiosa sobre qué clases son similares entre sí.

La idea es elegante: un modelo grande aprende representaciones ricas del mundo; un modelo pequeño, entrenado solo con etiquetas duras (one-hot), no tiene acceso a esas relaciones. Al transferir el conocimiento mediante soft labels con temperatura, el student hereda parte de esa riqueza representacional. En el contexto de edge, la destilación es especialmente valiosa porque permite diseñar modelos pequeños que rinden como grandes, sin necesidad de ejecutar el modelo grande en el dispositivo. Variantes modernas como DistilBERT han demostrado que es posible comprimir un modelo de 110M parámetros (BERT-base) a 66M manteniendo el 97% de su rendimiento en tareas de NLP. Para modelos de visión, la técnica se combina frecuentemente con pruning y cuantización para lograr compresiones aún mayores.

\(T\) = temperatura (suaviza las distribuciones), \(\alpha\) = balance entre loss duro y soft, \(z_t, z_s\) = logits del teacher y student.

NAS: diseño automático de arquitecturas

Neural Architecture Search (NAS) busca automáticamente la arquitectura óptima dadas restricciones de hardware (latencia, FLOPs, tamaño). En lugar de diseñar manualmente la estructura de la red (número de capas, canales, tipo de operación en cada bloque), NAS explora un espacio de búsqueda enorme de posibles arquitecturas y selecciona la que mejor cumple los requisitos.

Las familias de modelos más usadas en edge fueron diseñadas con variantes de NAS. La idea clave es la búsqueda hardware-aware: en lugar de optimizar solo la accuracy, la función objetivo incluye la latencia real medida en el dispositivo target (Tan et al., "MnasNet", 2019). Esto produce arquitecturas que son inherentemente eficientes en el hardware de destino, a diferencia de comprimir un modelo grande a posteriori. Combinado con las técnicas de pruning, cuantización y destilación descritas anteriormente, NAS permite lograr puntos de operación accuracy/latencia que serían imposibles de alcanzar con diseño manual.

Compilación y conversión de modelos

El paso final antes del despliegue es compilar el modelo para el hardware objetivo. Cada target tiene su propio compilador que optimiza el grafo computacional:

import torch
import tensorrt as trt

# 1. Exportar a ONNX
model = torch.hub.load('ultralytics/yolov5', 'yolov5s', pretrained=True)
model.eval()
dummy = torch.randn(1, 3, 640, 640)
torch.onnx.export(model, dummy, "yolov5s.onnx",
                  opset_version=13,
                  input_names=['images'],
                  output_names=['output'],
                  dynamic_axes={'images': {0: 'batch'}})

# 2. Compilar con TensorRT (trtexec CLI)
# $ trtexec --onnx=yolov5s.onnx \
#           --saveEngine=yolov5s.engine \
#           --fp16 \                    # o --int8 --calib=calib.cache
#           --workspace=1024 \
#           --batch=1

# 3. Inferencia con TensorRT en Python
import pycuda.driver as cuda
import pycuda.autoinit
import numpy as np

logger = trt.Logger(trt.Logger.WARNING)
with open("yolov5s.engine", "rb") as f:
    engine = trt.Runtime(logger).deserialize_cuda_engine(f.read())

context = engine.create_execution_context()
# ... allocate buffers, run inference, postprocess ...

Widget: simulador de cuantización

Visualiza cómo la cuantización reduce el tamaño del modelo y su impacto en accuracy. Ajusta el número de bits y el tipo de modelo para ver la compresión resultante.

Ecosistema de herramientas para Edge AI

Llevar un modelo del entrenamiento al edge requiere una cadena de herramientas que conecta frameworks de ML con el hardware objetivo. El ecosistema ha madurado enormemente y hoy existen soluciones end-to-end para cada plataforma.

El diagrama siguiente muestra el flujo típico: el modelo se entrena en un framework estándar (PyTorch, TensorFlow, JAX), se exporta a un formato de intercambio (ONNX o SavedModel), se optimiza y compila para el hardware target, y finalmente se despliega con un runtime específico. Existe también un camino alternativo para FPGAs (hls4ml) que convierte el modelo directamente en hardware RTL, sin pasar por una DPU. Para quienes buscan profundizar en el despliegue en general, el submódulo de Puesta en Producción cubre Docker, Kubernetes y serving frameworks.

TensorRT (NVIDIA)

TensorRT es el compilador/runtime de NVIDIA para optimizar modelos en GPUs (desktop, server y Jetson). Es la herramienta más madura para Jetson y probablemente la más usada en producción para inferencia en GPUs NVIDIA.

TensorRT actúa como un compilador de grafos computacionales: toma un modelo entrenado (en formato ONNX, PyTorch o TensorFlow) y lo transforma en una representación altamente optimizada para la GPU específica donde se va a ejecutar. Las optimizaciones incluyen fusión de operaciones (por ejemplo, Conv + BatchNorm + ReLU se fusionan en un solo kernel CUDA), selección del kernel más rápido para cada operación mediante autotuning, y cuantización a FP16/INT8 con calibración automática. La documentación completa está disponible en la documentación oficial de TensorRT. El proceso de optimización se resume en cuatro pasos:

TensorFlow Lite

TFLite es el runtime de Google para inferencia en edge. Es el formato más universal: funciona en Android, iOS, Linux, microcontroladores (TFLite Micro), y soporta delegados hardware (GPU, NNAPI, Edge TPU, Hexagon).

La fuerza de TFLite está en su ecosistema de delegados (delegates): plugins que permiten que las operaciones del modelo se ejecuten en el acelerador disponible del dispositivo, sin cambiar el código. Por ejemplo, el mismo archivo .tflite puede ejecutarse en una CPU ARM con XNNPack (SIMD optimizado), en un Edge TPU de Coral, o en una GPU móvil mediante OpenGL/Metal, simplemente cambiando el delegado. Para desarrolladores que trabajan con modelos de clasificación o detección (ver Clasificación y Transfer Learning y Detección de objetos), TFLite ofrece una biblioteca de modelos pre-optimizados listos para desplegar. Las principales plataformas soportadas son:

ONNX y ONNX Runtime

ONNX (Open Neural Network Exchange) es el formato estándar de intercambio de modelos, desarrollado originalmente por Microsoft y Facebook. ONNX Runtime es el motor de inferencia de Microsoft que ejecuta modelos ONNX con Execution Providers (EP) para diferentes hardware.

La propuesta de valor de ONNX es resolver la fragmentación del ecosistema: en lugar de que cada hardware requiera su propio formato (TensorRT para Jetson, TFLite para Coral, Vitis AI para FPGA...), ONNX ofrece un formato intermedio único desde el que se puede optimizar para cualquier target. En la práctica, la mayoría de compiladores de edge aceptan ONNX como formato de entrada. ONNX Runtime extiende esto proporcionando un motor de inferencia unificado con Execution Providers que abstraen el hardware subyacente:

import onnxruntime as ort
import numpy as np

# Crear sesión con TensorRT EP (Jetson) o CPU fallback
providers = ['TensorrtExecutionProvider',
             'CUDAExecutionProvider',
             'CPUExecutionProvider']

session = ort.InferenceSession("model.onnx", providers=providers)

# Ver qué EP se está usando
print(f"Using: {session.get_providers()}")

# Inferencia
input_name = session.get_inputs()[0].name
result = session.run(None, {input_name: np.random.randn(1, 3, 224, 224).astype(np.float32)})
print(f"Output shape: {result[0].shape}")

OpenVINO (Intel)

OpenVINO (Open Visual Inference and Neural Network Optimization) es el toolkit de Intel para optimizar y desplegar modelos en hardware Intel: CPUs (con instrucciones AVX-512/AMX), GPUs integradas (Xe), VPUs (Myriad X) y las nuevas NPUs de Meteor Lake.

Vitis AI y HLS4ML: frameworks para FPGA

Vitis AI

Vitis AI (AMD/Xilinx) es el framework completo para desplegar modelos en FPGAs con DPU. Incluye:

# ═══════════════════════════════════════════════
# 1. Cuantización con Vitis AI (PyTorch)
# ═══════════════════════════════════════════════
from pytorch_nndct.apis import torch_quantizer

model = load_my_model()  # Modelo PyTorch entrenado
model.eval()

# Crear quantizer
quantizer = torch_quantizer(
    quant_mode='calib',       # Modo calibración
    module=model,
    input_args=torch.randn(1, 3, 224, 224),
    output_dir='quantized/',
    bitwidth=8                # INT8
)

quant_model = quantizer.quant_model

# Calibrar con datos representativos
with torch.no_grad():
    for images, _ in calib_loader:
        quant_model(images)

quantizer.export_quant_config()

# ═══════════════════════════════════════════════
# 2. Compilar para DPU (terminal)
# ═══════════════════════════════════════════════
# $ vai_c_xir \
#     -x quantized/model_int.xmodel \
#     -a /opt/vitis_ai/compiler/arch/DPUCZDX8G/KV260/arch.json \
#     -o compiled/ \
#     -n my_model

# ═══════════════════════════════════════════════
# 3. Inferencia con VART en la FPGA
# ═══════════════════════════════════════════════
import xir
import vart
import numpy as np

# Cargar modelo compilado
graph = xir.Graph.deserialize("compiled/my_model.xmodel")
subgraphs = graph.get_root_subgraph().toposort_child_subgraph()
dpu_subgraph = [s for s in subgraphs if s.has_attr("device") and s.get_attr("device") == "DPU"]

runner = vart.Runner.create_runner(dpu_subgraph[0], "run")

# Preparar buffers
input_tensors = runner.get_input_tensors()
output_tensors = runner.get_output_tensors()

# Ejecutar inferencia
input_data = preprocess(image)  # Preprocesado del input
job_id = runner.execute_async([input_data], [output_buffer])
runner.wait(job_id)

HLS4ML: Machine Learning en hardware puro

hls4ml (HLS for Machine Learning) es un framework open-source que traduce redes neuronales directamente a circuitos digitales (RTL) usando High-Level Synthesis. No usa DPU — cada capa se convierte en hardware dedicado. Desarrollado originalmente en el proyecto Fast Machine Learning del CERN, hls4ml ha demostrado que es posible ejecutar inferencia de redes neuronales en nanosegundos, algo imposible con cualquier solución basada en software. Modelos como las Spiking Neural Networks o las Graph Neural Networks, que tienen estructuras irregulares, son candidatos interesantes para aceleración en FPGA con enfoques de este tipo.

import hls4ml
import tensorflow as tf
from tensorflow import keras

# 1. Definir modelo pequeño (trigger LHC)
model = keras.Sequential([
    keras.layers.Dense(64, activation='relu', input_shape=(16,)),
    keras.layers.Dense(32, activation='relu'),
    keras.layers.Dense(32, activation='relu'),
    keras.layers.Dense(5, activation='softmax')
])
model.compile(optimizer='adam', loss='categorical_crossentropy')
model.fit(X_train, y_train, epochs=50)

# 2. Configurar hls4ml
config = hls4ml.utils.config_from_keras_model(model, granularity='name')

# Ajustar precisión por capa
for layer in config['LayerName']:
    config['LayerName'][layer]['Precision']['weight'] = 'ap_fixed<16,6>'
    config['LayerName'][layer]['Precision']['bias']   = 'ap_fixed<16,6>'
    config['LayerName'][layer]['Precision']['result'] = 'ap_fixed<16,6>'
    config['LayerName'][layer]['ReuseFactor'] = 1  # Full parallel

# 3. Convertir a HLS
hls_model = hls4ml.converters.convert_from_keras_model(
    model, hls_config=config,
    output_dir='hls_output/',
    backend='VivadoAccelerator',  # o 'Vitis'
    board='kria-kv260'
)

# 4. Compilar y sintetizar
hls_model.compile()
hls_model.build(csim=True, synth=True)  # Simular + sintetizar

# Ver recursos
hls4ml.report.read_vivado_report('hls_output/')
# → Latencia: ~50 ns, LUTs: 15%, DSPs: 8%, BRAMs: 3%

Edge Impulse y otras plataformas MLOps edge

Edge Impulse es una plataforma cloud para desarrollar modelos de ML para edge de forma visual (no-code/low-code). Cubre el pipeline completo: recoger datos → etiquetar → entrenar → optimizar → desplegar.

Aplicaciones de Edge AI por sector

Edge AI no es una tecnología que exista en el vacío: su valor emerge cuando se aplica a problemas reales donde la nube no es viable. A continuación se presentan los sectores más relevantes donde el despliegue en dispositivos edge está generando un impacto transformador. Muchas de estas aplicaciones combinan técnicas de detección de objetos, segmentación, modelos recurrentes para series temporales, y modelos de aprendizaje por refuerzo para control autónomo.

Proyectos de Edge AI: clásicos y modernos

🏛️ Proyectos clásicos y fundacionales

🚀 Proyectos modernos y de referencia

Limitaciones y retos del Edge AI

A pesar de sus ventajas, el despliegue de modelos en edge conlleva retos significativos que es importante comprender antes de comprometerse con esta aproximación. No todos los problemas se resuelven con edge — hay escenarios donde la nube sigue siendo la mejor opción (modelos muy grandes, cargas variables, prototipado rápido). Los principales retos se agrupan en seis categorías:

Papers y recursos fundamentales

Edge AI es un campo en rápida evolución. A continuación se recopilan los papers más influyentes, organizados por temática, junto con los recursos de documentación más útiles para comenzar a trabajar con hardware y frameworks edge. Para profundizar en los fundamentos teóricos, se recomienda consultar también los submódulos de Convolución y fundamentos (para entender las operaciones que se aceleran) y Regularización (técnicas relacionadas con la compresión de modelos).

Widget: selector de hardware edge

Responde unas preguntas sobre tu proyecto y te recomendaremos el hardware edge más adecuado.