Plateforme · AI Funnel

AI Funnel — décrivez votre flux d'IA edge en TOML.

AI Funnel est le moteur d'IA edge déclaratif de MOS4. Le client livre un graphe TOML plus un modèle et un dataset ; Cloud Connect ré-entraîne, optimise, valide contre le matériel de référence, puis OTA le bundle signé. Le runtime sur appareil dispatche le DAG : caméra → GPU → NPU sans copie de pixels CPU.

IA · couche intelligence
~100 TOPS silicium AI-class jusqu'à ~100 TOPS sur le tier AI-class
5 entrées caméra MIPI-CSI, GMSL2, UVC, RTSP, WebRTC
0 lectures pixels CPU tout le chemin critique — caméra vers NPU
Pipeline AI Funnel en trois étapes sur fond sombre — étape 1 fourniture client (TOML, ONNX/TFLite, dataset), étape 2 cloud Munic (réentraînement, quantisation, validation), étape 3 runtime sur device (ECU avec NPU et GPU en mémoire partagée)

Cycle de vie de déploiement

Du TOML au premier frame annoté.

Trois phases. Build s'exécute dans Cloud Connect : ré-entraînement du triage, optimisation NPU uniquement, validation hardware-in-the-loop. Provision s'exécute sur l'appareil à l'arrivée du bundle : DAG dispatché, modèles chargés, GPU et NPU configurés. Run s'exécute par frame : le triage détecte, ai-funnel route, le conteneur client termine le flux.

1 — Build · Cloud Connect

Le client livre, Cloud Connect valide.

Un graphe TOML, un modèle, un dataset COCO. Cloud Connect — le service cloud géré qui connecte la flotte aux micro services MOS4 — ré-entraîne le détecteur de triage unifié sur tous les funnels clients. Il impose les opérations NPU uniquement, optimise pour l'inférence basse précision sur le NPU cible, et applique une porte sur le matériel de référence. La sortie est un bundle de déploiement signé. Le registre est hébergé Munic ou client.

AI Funnel fait partie de la plateforme no-code. Détail Cloud Connect : en savoir plus · démarrer.

Phase de build du cycle de vie de déploiement AI Funnel, dans Cloud Connect. Le conteneur client — funnel.toml, modèles, dataset COCO et code conteneur — est poussé vers un registre hébergé Munic ou client. Depuis le registre, les artefacts alimentent l'entraîneur de triage, qui fusionne plusieurs funnels clients en un seul détecteur de triage unifié. Le résultat alimente l'optimiseur NPU, qui impose les opérations NPU uniquement et l'inférence basse précision. Le modèle optimisé alimente le validateur hardware-in-the-loop, qui exécute le candidat sur du matériel cible de référence et applique une porte sur la précision et la latence. Un bundle qui passe est signé et émis comme bundle de déploiement.

flowchart LR
  CB["Conteneur client<br/>funnel.toml + modèles<br/>+ dataset COCO + code conteneur"]
  REG[("Registre<br/>hébergé Munic ou<br/>hébergé client")]
  TT["Entraîneur de triage<br/>plusieurs funnels → un seul triage"]
  OPT["Optimiseur NPU<br/>ops NPU uniquement · inférence basse précision"]
  HIL["Validateur hardware-in-the-loop<br/>matériel cible de référence<br/>porte précision + latence"]
  BUNDLE["Bundle de déploiement signé"]
  CB --> REG --> TT --> OPT --> HIL --> BUNDLE
  class TT,OPT,HIL ai-node
Phase de build. Les étapes AI-class sont amber : l'entraîneur de triage (plusieurs funnels fusionnés en un seul détecteur), l'optimiseur NPU (ops NPU uniquement, inférence basse précision) et le validateur hardware-in-the-loop qui applique une porte sur la précision et la latence.

Un bundle qui échoue à la porte de précision ou de latence hardware-in-the-loop est renvoyé au client ; seuls les bundles signés et validés atteignent le canal OTA.

2 — Provision · Appareil

DAG dispatché. Pipeline armé.

À l'arrivée du bundle sur l'appareil, le DAG compilé depuis funnel.toml est dispatché : routage caméra et capteur configuré, modèles chargés dans le NPU, shader GPU configuré pour le format de tenseur, le letterboxing et l'extraction ROI. Les mises à jour de modèles utilisent le même canal OTA que le code, avec rollback de flotte, déploiement progressif et épinglage de version.

Phase de provisionnement du cycle de vie de déploiement AI Funnel, sur l'appareil. Le bundle signé est récupéré via le même canal OTA que les mises à jour de code. Le DAG compilé depuis funnel.toml est dispatché, et trois configurations divergent en parallèle : routage caméra et capteur, runtime IA chargeant les modèles dans le NPU, shader GPU ROI configurant le format de tenseur, le letterboxing et l'extraction ROI. Les trois convergent vers un signal prêt — l'appareil est armé pour le premier frame.

flowchart LR
  PULL["Bundle récupéré<br/>même canal OTA que le code"]
  DAG["DAG dispatché<br/>compilé depuis funnel.toml"]
  CFG_CAM["Routage caméra / capteur<br/>configuré"]
  CFG_NPU["Runtime IA<br/>modèles chargés dans le NPU"]
  CFG_GPU["Shader GPU ROI<br/>format tenseur · letterbox · ROI"]
  READY["Prêt · premier frame"]
  PULL --> DAG
  DAG --> CFG_CAM --> READY
  DAG --> CFG_NPU --> READY
  DAG --> CFG_GPU --> READY
  class CFG_NPU ai-node
Phase de provisionnement. La récupération du bundle et le dispatch DAG sont des étapes système ; mos-ai-runtime chargeant le modèle dans le NPU est l'étape AI-class (amber).

3 — Exécution · Par frame

Le triage route ; le DAG se termine.

Chaque frame suit le chemin caméra → tenseur de triage GPU → triage NPU. ai-funnel inspecte les labels et route par détection : le GPU recadre le ROI, le NPU exécute le modèle aval, le résultat boucle soit vers le routeur pour l'étape suivante du DAG, soit sort vers le conteneur client — tracking, carte, message cloud, CAN — selon le nœud terminal du DAG.

Phase d'exécution du cycle de vie de déploiement AI Funnel, par frame sur l'appareil. La caméra ou le capteur produit un frame GPU partagé. Le GPU produit un tenseur de triage. Le modèle de triage NPU émet des labels et des boîtes englobantes vers le routeur DAG AI Funnel. Le routeur dispatche par détection : le GPU recadre la région d'intérêt avec letterboxing et normalisation, le NPU exécute le modèle aval et retourne les labels et la confiance. Le routeur boucle soit vers un autre modèle dans le DAG, soit sort vers le conteneur client, où la charge se termine en tracking, carte, message cloud ou message CAN — selon le nœud terminal du DAG.

flowchart LR
  SRC["Caméra / capteur<br/>frame GPU partagé"]
  GPU1["GPU<br/>tenseur de triage"]
  NPU1["Triage NPU<br/>labels + bboxes"]
  AIF["AI Funnel<br/>routeur DAG"]
  GPU2["GPU<br/>ROI par détection<br/>letterbox · normalise"]
  NPU2["Modèle NPU<br/>labels + confiance"]
  SINK["Conteneur client<br/>tracking · carte · message cloud · CAN"]
  SRC --> GPU1 --> NPU1 --> AIF
  AIF --> GPU2 --> NPU2 --> AIF
  AIF --> SINK
  class NPU1,NPU2 ai-node
Phase d'exécution. Les étapes d'inférence NPU sont amber. Les arêtes routeur-vers-modèle-retour-vers-routeur montrent la boucle DAG ; l'arête finale vers le conteneur client est le terminal DAG.

Pour la matrice d'entrée côté caméra (MIPI-CSI, GMSL2, UVC, RTSP, WebRTC) voir les capacités Vision.

Observabilité

14 métriques intégrées sur tout le pipeline.

Chaque étape du pipeline émet des métriques Prometheus — appels, erreurs, histogrammes de durée, heartbeat watchdog. 14 métriques sur le shader GPU ROI et le runtime IA, sans coût pour l'auteur du service. Voir le catalogue complet des opérations →

Test doubles

Développer sans matériel.

Fakes publiés par le provider pour CI et développement hors cible
Composant fake Portée de test Exécutable en CI
Fake runtime IA Stub d'inférence de modèle Oui — sans NPU
Fake shader GPU ROI Stub d'extraction ROI GPU Oui — sans GPU requis
Source / sink de frames mock Pub/sub sur bus de frames Oui — hôte pur
Source fichier sim Relecture d'entrée caméra Oui — fichier

Construisez et validez le pipeline complet sur n'importe quel ordinateur portable. Voir le SDK et le workflow développeur →

FAQ

Questions fréquentes

  • Les pixels traversent-ils jamais le CPU dans le chemin critique ?

    Non, par conception. Caméra, GPU et NPU échangent le même frame en mémoire partagée via passage de handles — aucune copie de tampon à aucune étape.

  • Quels formats de modèles le runtime IA accepte-t-il ?

    TFLite directement. ONNX est auto-converti dans le pipeline, donc les équipes utilisant des chemins d'export ONNX peuvent fournir l'un ou l'autre format.

  • Peut-on exécuter plusieurs modèles en parallèle ?

    Oui. Le runtime IA charge plusieurs modèles simultanément. La ré-entrée du même modèle est empêchée par construction. Le mode de sérialisation (par modèle ou voie unique globale) est configurable sans recompilation.

  • Peut-on développer sans matériel NPU ?

    Oui. Les fakes publiés par le provider (runtime IA, shader GPU ROI, source/sink de frames, relecture fichier) permettent de développer et de tester en intégration le pipeline complet sans matériel NPU, capteur caméra ou Bazel.

FAQ Architecture

Détails d'implémentation

  • Comment fonctionne techniquement le handoff zéro-copie ?

    Les frames caméra traversent la frontière de processus via passage de handles. Le shader GPU ROI les importe et exécute les compute shaders de recadrage, redimensionnement et normalisation entièrement sur le GPU. Le handle du tenseur de sortie est remis au runtime IA, qui pilote le délégué NPU du fournisseur de silicium.

  • La mémoire partagée GPU-vers-NPU est-elle disponible sur la variante AI-class MIPI-CSI ?

    Non. La mémoire partagée GPU-vers-NPU est disponible uniquement sur la variante AI-class pont sérialiseur. La variante MIPI-CSI utilise l'extraction ROI GPU et transmet le tenseur au NPU comme tampon standard. Les deux variantes partagent le même pipeline ROI Vulkan.

Plateforme Text-IA

AI Language — la plateforme d'intelligence textuelle.

AI Funnel est le moteur Build d'intelligence visuelle. La plateforme complémentaire pour le texte est AI Language — LLM sur appareil, RAG refuse-preferred, défense en quatre couches contre l'injection de prompt et voix multilingue, tout hors ligne par défaut.

Les deux plateformes s'exécutent sur le même appareil et partagent l'EventBus et le canal OTA MOS4. AI Funnel exécute le pipeline visuel ; AI Language exécute le pipeline de langage. Ensemble elles forment la couche runtime de la MOS4 AI Software Suite.

Voir la plateforme AI Language →

Explorer davantage

Capacités associées

Matériel AI-class

Facteurs de forme, tiers silicium et options de connectivité pour le déploiement AI Funnel.

Voir le matériel →

Plateforme no-code

AI Funnel est l'un des quatre moteurs déclaratifs. Combinez avec multi stacks, traitement du signal et traitement d'événements — tout configuré en TOML ou YAML, sans code requis.

Voir la plateforme no-code →

SDK et outils développeur

Micro services hot-swap, outillage CLI et bibliothèque de test doubles pour le développement hors cible.

Voir le SDK →

Apportez le modèle et le dataset.

Apportez la tâche d'inférence ; l'ingénierie parcourra le chemin capture-vers-NPU sur un appareil cible.

Vous construisez sur MOS4 ?

Une réponse de l'équipe d'ingénierie, ~24 h. Pas de pitch, pas de NDA.

Parler à l'équipe