Backends de calcul tensoriel
Statut documentaire : architecture — voir Maturité et preuves.
logiCells sépare la sémantique des tenseurs du backend qui exécute les noyaux numériques. Le Runtime peut ainsi choisir une implémentation selon les capacités disponibles sans faire dépendre le modèle conceptuel d'une API d'accélération particulière.
Dispatch piloté par les capacités
Le moteur distingue trois niveaux utiles de capacités :
- exécution F32 côté hôte pour les opérations flottantes ordinaires ;
- exécution résidente sur périphérique pour conserver les buffers sur un accélérateur entre plusieurs opérations ;
- exécution Transformer résidente pour les noyaux et états qui gagnent à éviter les transferts répétés hôte/périphérique.
Un backend peut indiquer qu'une opération n'est pas supportée. Le dispatch peut alors essayer un autre backend ou une implémentation CPU lorsqu'un chemin de repli existe.
Pourquoi la résidence est importante
Transférer un tenseur vers un accélérateur pour chaque primitive peut coûter plus cher que le calcul lui-même. Les buffers résidents rendent la frontière de transfert explicite :
données hôte
-> upload une fois
-> opérations résidentes
-> réutilisation des intermédiaires
-> download seulement lorsque l'hôte a besoin du résultat
Cette approche est particulièrement importante pour l'inférence Transformer, où normalisation, projections, attention, couches feed-forward et mises à jour du KV cache forment une chaîne longue.
Architecture actuelle
Les sources actuelles du moteur contiennent des chemins d'accélération enregistrés pour WebGPU et MLX, en complément des chemins hôte/CPU. Leur disponibilité dépend de la plateforme et du build ; une application doit donc raisonner en termes de capacités plutôt que supposer qu'un accélérateur nommé est toujours présent.
Règle développeur
Le backend est une préoccupation d'exécution. Les modèles métier, l'identité conceptuelle et les contrats publics ne doivent pas encoder le choix d'un GPU ou d'un accélérateur.
Voir aussi :