## Synthèse — Architecture d’Exécution NeuroBrix 2025

(Version professionnelle, stable, sans spéculation)

### 1. Positionnement technique

NeuroBrix est un runtime multihardware et multivendor, conçu pour exécuter des modèles IA modernes avec une approche déterministe, sans fallback implicite, en appliquant la Zero Fallback Policy sur l’ensemble du pipeline.

Son rôle est de :
	•	analyser les modèles,
	•	produire un graphe interne maître (NBX Graph),
	•	générer un topology.json fidèle,
	•	répartir les opérations entre moteurs d’exécution (Triton, CPU, Universal GPU),
	•	garantir la compatibilité totale avec tous les modèles modernes.

### 2. Topology Generation — Méthode validée

ONNX n’est pas fiable pour obtenir un graphe exact.
Il dégrade certaines opérations, en supprime d’autres, et force des approximations (GELU éclaté, LayerNorm v17, attention décomposée…).

La seule méthode garantissant un topology.json 100% correct est :

1. Tracer le modèle directement au niveau PyTorch

En capturant :
	•	la séquence exacte des opérations,
	•	les shapes,
	•	les attributs,
	•	les dépendances entre tensors,
	•	les branches dynamiques (si elles existent).

2. Construire le NBX Graph (graphe interne normalisé)

Avec la terminologie NeuroTax, indépendante de tout framework.

3. Générer le topology.json depuis le NBX Graph

Jamais depuis ONNX.

Cette méthode est 100% fiable, reproductible, déterministe.

### 3. Exécution — Architecture hybride NeuroBrix

#### 3.1. Triton comme moteur GPU primaire

Triton offre :
	•	performance proche des kernels NVIDIA optimisés
	•	portabilité future multi-vendor
	•	code open-source, transparent
	•	un modèle de programmation lisible
	•	une indépendance CUDA totale

Toutes les opérations tensorisées supportées par Triton sont routées vers execution: "triton".

#### 3.2. Universal GPU Backend (multivendor)

Pour les opérations GPU nécessitant un backend autre que Triton,
NeuroBrix utilise un exécuteur générique multi-hardware :
	•	SYCL / OneAPI (Intel, CPU, GPU, FPGA)
	•	ROCm HIP (AMD)
	•	Metal Performance Shaders (Apple)
	•	SPIR-V / Vulkan Compute (Android, ARM, AMD, mobiles)
	•	OpenCL (fallback universel)

Ce backend permet d’exécuter sans CUDA, et sans dépendre de NVIDIA.

#### 3.3. CPU Execution

Pour les opérations non intensives ou non tensorisées :
	•	shape logic
	•	permutation
	•	slicing
	•	mapping
	•	routing logique
	•	argmax non intensif

→ execution: "cpu"

#### 3.4. Metadata Execution

Pour les opérations de structure uniquement :
	•	inférences de shape
	•	transformations logiques
	•	opérations ne modifiant pas les données

→ execution: "metadata"

#### 3.5. Zero Fallback Policy

Aucune substitution silencieuse, aucune improvisation.
Si une opération n’a pas d’exécuteur :
→ NeuroBrixUnsupportedOperationError

### 4. Export ONNX

ONNX est utilisé uniquement comme format d’interopérabilité, pas comme source de topologie.

Opset recommandé : 19 ou 20 pour les exports futurs,
mais NeuroBrix reste compatible avec tous les opsets précédents.

### 5. Capacité Triton vs opérations IA

Triton peut couvrir 95% des opérations des modèles IA modernes :
MatMul, MLP, Attention, LN/RMSNorm, Softmax, Conv, SiLU, Reshape, Normalize…

Les 5% restants sont pris en charge soit par CPU, soit par Universal GPU Backend.

Conclusion :
NeuroBrix n’a aucune dépendance obligatoire à CUDA, PyTorch ou NVIDIA.

---

### 6. Architecture Runtime Modulaire (Janvier 2026)

L'exécuteur runtime a été refactorisé en architecture modulaire :

#### 6.1. Avant (executor.py monolithique)
- **3022 lignes** - God Object anti-pattern
- Flow logic, CFG, synthesis, extraction mélangés

#### 6.2. Après (architecture modulaire)
- **772 lignes** - Orchestrateur uniquement

```
core/runtime/
├── executor.py               # Orchestrateur ONLY
├── flow/                     # Flow Handlers
│   ├── base.py               # FlowContext, FlowHandler ABC
│   ├── iterative_process.py  # Diffusion (pre_loop → loop → post_loop)
│   ├── static_graph.py       # Single-pass
│   ├── forward_pass.py       # Sequential transformer
│   └── autoregressive.py     # Token generation
├── resolution/               
│   └── input_resolver.py     # Résolution inputs
├── synthesis/                
│   └── input_synthesizer.py  # Synthèse inputs
├── extraction/               
│   └── output_extractor.py   # Extraction outputs
└── cfg/                      
    └── cfg_executor.py       # Classifier-Free Guidance
```

#### 6.3. Principes
- **Factory Pattern**: `@register_flow` + `get_flow_handler()`
- **Single Responsibility**: Chaque handler gère UN flow type
- **ZERO HARDCODE**: Configuration depuis topology.json
