Dans Core : plus de 2 900 opérations sur 12 backends
Ce que révèle le nombre d’opérations
La multiplication matricielle semble être une tâche unique. Pourtant, son implémentation dépend du sens des valeurs, de leur stockage, de l’accumulation des résultats intermédiaires et du matériel qui exécute le calcul. Une matrice binaire empaquetée et une matrice en virgule flottante peuvent partager une même opération abstraite, tout en exigeant des règles numériques et du code différents.
Core est la base de calcul de Dweve pour l’entraînement et l’inférence. Son catalogue public couvre des centaines de milliers de kernels optimisés à la main, répartis entre plus de 2 900 opérations, 76 catégories, 25 formats numériques et 12 backends. Ces chiffres décrivent différentes parties du système. Une opération nomme le calcul. Un format numérique définit la représentation. Un backend désigne une cible d’exécution. Un kernel implémente une combinaison précise de ces choix.
Il est plus utile de comprendre ces distinctions que de considérer le catalogue comme un unique grand total de fonctionnalités. Un développeur doit savoir si la combinaison requise existe et quel contrat elle respecte.
Le calcul et sa représentation vont de pair
Prenons une réduction : réunir un ensemble de valeurs pour obtenir un résultat. Le mot « somme » ne répond pas à plusieurs questions. Les entrées sont-elles des entiers signés, des valeurs en virgule fixe ou en virgule flottante ? Quelle représentation stocke le résultat accumulé ? Que se passe-t-il si cette représentation ne peut pas contenir la valeur suivante ?
Core associe ces choix à l’opération. Son contrat d’exécution comprend le type de données, la largeur, l’empaquetage, l’accumulateur, le backend, le jeu d’instructions, la politique de dispatch et le mode de déterminisme. Modifier l’un de ces éléments peut changer le sens du calcul, même si le nom de l’opération reste identique.
Les 25 formats numériques couvrent les familles binaire, ternaire, entière, en virgule fixe, adaptative et en virgule flottante. Le nom d’une famille ne suffit qu’à amorcer la description de l’arithmétique. La largeur, le signe, l’échelle et la disposition en mémoire comptent aussi. Il faut donc lire le catalogue comme un ensemble de combinaisons prises en charge, et non comme la promesse que chaque opération existe dans tous les formats imaginables sur toutes les cibles.
Un format d’échange ne peut pas non plus répondre à toutes les questions d’exécution. ONNX décrit un graphe de calcul avec des entrées, sorties et opérateurs typés. Il fournit ainsi aux systèmes une description commune du modèle ; le runtime doit encore implémenter ces opérateurs. La documentation des concepts ONNX explique cette distinction entre représentation du graphe et exécution.
12 backends, des choix d’exécution explicites
Les 12 backends de Core couvrent l’exécution scalaire, les jeux d’instructions CPU ainsi que des cibles GPU et portables. La liste publique comprend Scalar, SSE2, AVX2, AVX-512, NEON, SVE2, CUDA, ROCm, Metal, Vulkan, WebGPU et WASM. Il s’agit de chemins d’exécution au sein de Core, et non de versions distinctes d’un modèle.
Le dispatch sélectionne sur l’hôte courant une implémentation prise en charge pour l’opération et son contrat d’exécution. Le chemin retenu est consigné avec sa cellule d’exécution, l’hôte et le motif du choix. On peut ainsi examiner les choix réellement effectués pendant une exécution.
La portabilité a toutefois ses limites. La documentation de WebAssembly distingue, par exemple, un format binaire portable des API fournies par l’environnement hôte. Le navigateur et les environnements hors navigateur peuvent exposer des interfaces différentes. La documentation sur la portabilité de WebAssembly apporte un éclairage utile sur cette distinction. Le nom d’un backend ne suffit pas à décrire l’environnement d’une application.
La place de Core dans Dweve
La bibliothèque primitives fournit à Core les opérations fondamentales. Core intègre ces bases au système de calcul. Loom repose sur Core et utilise la bibliothèque solvers pour ses tâches de raisonnement. Chaque composant a ainsi un rôle clair : primitives fournit les opérations de base, Core exécute les calculs et Loom construit le raisonnement sur ces fondations.
Dweve est le service. Fabric en est l’API et le portail, par lesquels les personnes et les applications accèdent au service. Fabric ne remplace ni le rôle de calcul de Core ni celui de raisonnement de Loom. L’interface et les systèmes qui la sous-tendent ont des fonctions différentes.
Partez du calcul dont vous avez besoin
Pour évaluer un système de calcul, commencez par définir un calcul concret et la représentation qu’il exige. Demandez ensuite quel backend l’exécutera, quelles règles s’appliquent à l’accumulateur et à l’empaquetage, et quel contrat de rejeu est déclaré. Ces questions rendent le catalogue exploitable par une équipe.
Les chiffres publics de Core décrivent l’étendue du catalogue. Le contrat d’exécution explique comment le lire. Les deux sont indissociables : quels travaux le système couvre, et ce que signifie une implémentation donnée lorsqu’on l’utilise.