Plataforma · AI Funnel
AI Funnel — describa el flujo de IA en el edge en TOML.
AI Funnel es el motor declarativo de IA en el edge de MOS4. El cliente entrega un grafo TOML más un modelo y un dataset; Cloud Connect reentrena, optimiza, valida contra hardware de referencia y luego envía por OTA el bundle firmado. El runtime en dispositivo despacha el DAG: cámara → GPU → NPU sin copias de píxeles por CPU.
Ciclo de vida de despliegue
Del TOML al primer frame etiquetado.
Tres fases. La build se ejecuta en Cloud Connect: reentrenamiento de triaje, optimización solo NPU, validación hardware-en-el-bucle. La provisión se ejecuta en el dispositivo cuando llega el bundle: DAG despachado, modelos cargados, GPU y NPU configurados. La ejecución tiene lugar por frame: el triaje detecta, ai-funnel enruta, el contenedor del cliente termina el flujo.
1 — Build · Cloud Connect
El cliente envía, Cloud Connect valida.
Un grafo TOML, un modelo, un dataset COCO. Cloud Connect — el servicio en la nube gestionado que conecta la flota a los micro services MOS4 — reentrena el detector de triaje unificado en todos los funnels del cliente. Aplica operaciones solo NPU, optimiza para inferencia de baja precisión en la NPU objetivo y valida el resultado contra hardware de referencia. La salida es un bundle de despliegue firmado. El registro es alojado por Munic o por el cliente.
AI Funnel es parte de la plataforma no-code. Detalle de Cloud Connect: más información · primeros pasos.
Fase de build del ciclo de vida de despliegue del AI funnel, dentro de Cloud Connect. El contenedor del cliente — funnel.toml, modelos, dataset COCO y código de contenedor — se envía a un registro alojado por Munic o por el cliente. Desde el registro, los artefactos alimentan el entrenador de triaje, que fusiona varios funnels del cliente en un único detector de triaje unificado. El resultado alimenta el optimizador NPU, que aplica operaciones solo NPU e inferencia de baja precisión. El modelo optimizado alimenta el validador hardware-en-el-bucle, que ejecuta el candidato contra hardware de destino de referencia y aplica una barrera de precisión y latencia. Un bundle que pasa se firma y se emite como bundle de despliegue.
flowchart LR
CB["Contenedor del cliente<br/>funnel.toml + modelos<br/>+ dataset COCO + código de contenedor"]
REG[("Registro<br/>alojado por Munic o<br/>por el cliente")]
TT["Entrenador de triaje<br/>varios funnels → un triaje"]
OPT["Optimizador NPU<br/>ops solo NPU · inferencia de baja precisión"]
HIL["Validador hardware-en-el-bucle<br/>hardware de destino de referencia<br/>barrera de precisión + latencia"]
BUNDLE["Bundle de despliegue firmado"]
CB --> REG --> TT --> OPT --> HIL --> BUNDLE
class TT,OPT,HIL ai-node Un bundle que no supera la barrera de precisión o latencia del validador hardware-en-el-bucle se devuelve al cliente; solo los bundles firmados y validados llegan al canal OTA.
↓ OTA · mismo canal que las actualizaciones de código
2 — Provisión · Dispositivo
DAG despachado. Pipeline armado.
Cuando el bundle llega al dispositivo, el DAG compilado desde funnel.toml se despacha: routing de cámara y sensor configurado, modelos cargados en la NPU, el shader GPU configurado para formato tensor, letterboxing y extracción de ROI. Las actualizaciones de modelos usan el mismo canal OTA que el código, con rollback de flota, despliegue gradual y fijación de versión.
Fase de provisión del ciclo de vida de despliegue del AI funnel, en el dispositivo. El bundle firmado se descarga mediante el mismo canal OTA que las actualizaciones de código. El DAG compilado desde funnel.toml se despacha y tres configuraciones se despliegan en paralelo: routing de cámara y sensor, el runtime de IA cargando los modelos en la NPU, y el ROI shader GPU configurando formato tensor, letterboxing y extracción de ROI. Las tres convergen en una señal de listo — el dispositivo está armado para el primer frame.
flowchart LR PULL["Bundle descargado<br/>mismo canal OTA que el código"] DAG["DAG despachado<br/>compilado desde funnel.toml"] CFG_CAM["Routing de cámara / sensor<br/>configurado"] CFG_NPU["Runtime de IA<br/>modelos cargados en NPU"] CFG_GPU["ROI shader GPU<br/>formato tensor · letterbox · ROI"] READY["Listo · primer frame"] PULL --> DAG DAG --> CFG_CAM --> READY DAG --> CFG_NPU --> READY DAG --> CFG_GPU --> READY class CFG_NPU ai-node
↓ primer frame
3 — Ejecución · Por frame
El triaje enruta; el DAG termina.
Cada frame recorre cámara → tensor de triaje GPU → triaje NPU. ai-funnel inspecciona las etiquetas y enruta por detección: la GPU recorta el ROI de nuevo, la NPU ejecuta el modelo posterior, el resultado o bien vuelve al router para la siguiente etapa del DAG o sale al contenedor del cliente — seguimiento, mapa, mensaje en la nube, CAN — según el nodo terminal del DAG.
Fase de ejecución del ciclo de vida de despliegue del AI funnel, por frame en el dispositivo. La cámara o el sensor produce un frame GPU compartido. La GPU produce un tensor de triaje. El modelo de triaje NPU emite etiquetas y bounding boxes al router DAG de AI funnel. El router despacha por detección: la GPU recorta la región de interés con letterboxing y normalización, la NPU ejecuta el modelo posterior y devuelve etiquetas y confianza. El router o bien vuelve al bucle para encadenar otro modelo en el DAG o sale al contenedor del cliente, donde la carga de trabajo termina como seguimiento, mapeo, un mensaje en la nube o un mensaje CAN — el nodo terminal depende del DAG.
flowchart LR SRC["Cámara / sensor<br/>frame GPU compartido"] GPU1["GPU<br/>tensor de triaje"] NPU1["Triaje NPU<br/>etiquetas + bboxes"] AIF["AI funnel<br/>router DAG"] GPU2["GPU<br/>ROI por detección<br/>letterbox · normalizar"] NPU2["Modelo NPU<br/>etiquetas + confianza"] SINK["Contenedor del cliente<br/>seguimiento · mapa · mensaje nube · CAN"] SRC --> GPU1 --> NPU1 --> AIF AIF --> GPU2 --> NPU2 --> AIF AIF --> SINK class NPU1,NPU2 ai-node
Para la matriz de entradas de cámara (MIPI-CSI, GMSL2, UVC, RTSP, WebRTC) ver Capacidades de Vision.
Observabilidad
14 métricas integradas a lo largo del pipeline.
Cada etapa del pipeline emite métricas Prometheus — llamadas, errores, histogramas de duración, heartbeat del watchdog. 14 métricas en el ROI shader GPU y el runtime de IA, sin coste para el autor del servicio. Ver el catálogo completo de operaciones →
Dobles de prueba
Desarrolle sin hardware.
| Componente fake | Alcance de la prueba | Ejecutable en CI |
|---|---|---|
| Fake del runtime de IA | Stub de inferencia de modelo | Sí — sin hardware NPU |
| Fake del ROI shader GPU | Stub de extracción de ROI GPU | Sí — sin GPU requerida |
| Fuente / sumidero de frames simulado | Pub/sub de bus de frames | Sí — puro host |
| Fuente de archivo sim | Reproducción de entrada de cámara | Sí — basado en archivos |
Construya y valide el pipeline completo en cualquier portátil. Ver el SDK y el flujo de trabajo del desarrollador →
FAQ
Preguntas frecuentes
-
¿Cruzan bytes de píxeles por la CPU en el camino crítico?
No, por diseño. La cámara, la GPU y la NPU intercambian el mismo frame de memoria compartida mediante paso de handles — sin copias de buffer en ningún paso.
-
¿Qué formatos de modelo acepta el runtime de IA?
TFLite directamente. ONNX se convierte automáticamente en el pipeline para que los equipos que usan rutas de exportación ONNX puedan suministrar cualquiera de los dos formatos.
-
¿Puedo ejecutar varios modelos concurrentemente?
Sí. El runtime de IA carga varios modelos simultáneamente. La reentrada al mismo modelo se previene por construcción. El modo de serialización (por modelo o carril único global) es configurable sin recompilación.
-
¿Puedo desarrollar sin hardware NPU?
Sí. Los fakes publicados por el proveedor (runtime de IA, ROI shader GPU, fuente/sumidero de frames, reproducción de archivos) permiten desarrollar y probar la integración del pipeline completo sin hardware NPU, sensor de cámara ni Bazel.
FAQ de arquitectura
Detalles de implementación
-
¿Cómo funciona técnicamente la transferencia sin copia?
Los frames de cámara cruzan el límite de proceso mediante paso de handles. El ROI shader GPU los importa y ejecuta shaders de cómputo de recorte, redimensión y normalización enteramente en la GPU. El handle del tensor de salida se entrega al runtime de IA, que dirige el delegado NPU del proveedor de silicio.
-
¿Está disponible la memoria compartida GPU-a-NPU en la variante AI-class MIPI-CSI?
No. La memoria compartida GPU-a-NPU solo está disponible en la variante AI-class con puente serializador. La variante MIPI-CSI usa extracción de ROI GPU y entrega el tensor a la NPU como buffer estándar. Ambas variantes comparten el mismo pipeline ROI Vulkan.
Plataforma Text-IA
AI Language — la plataforma de inteligencia textual.
AI Funnel es el motor Build de inteligencia visual. La plataforma complementaria para texto es AI Language — LLM en dispositivo, RAG refuse-preferred, defensa de inyección de prompt en cuatro capas y voz multilingüe, todo sin conexión de forma predeterminada.
Ambas plataformas se ejecutan en el mismo dispositivo, compartiendo el EventBus y el canal OTA de MOS4. AI Funnel ejecuta el pipeline visual; AI Language ejecuta el pipeline de lenguaje. Juntas forman la capa runtime de la MOS4 AI Software Suite.
Explorar más
Capacidades relacionadas
Hardware AI-class
Factores de forma, niveles de silicio y opciones de conectividad para el despliegue de AI Funnel.
Plataforma no-code
AI Funnel es uno de los cuatro motores declarativos. Combínelo con Multi Stacks, procesado de señal y procesado de eventos — todos configurados en TOML o YAML, sin código requerido.
SDK y herramientas de desarrollo
Micro services con hot-swap, herramientas CLI y una biblioteca de dobles de prueba para desarrollo fuera del objetivo.
Traiga el modelo y el dataset.
Traiga la tarea de inferencia; ingeniería recorrerá el camino de captura a NPU en un dispositivo objetivo.