FRnOG 39 - Khaled Maalej : Software friendly solution for new levels of supercomputing
Category
🤖
TechnologieTranscription
00:00 Bonsoir, je vais vous parler un peu, Philippe a parlé d'un CPU, moi je vais parler plus d'un GPU-like aujourd'hui.
00:08 Rapidement, Vésora c'est une société qui a été créée en 2015, avec le focus dès le départ de réseau, ce qu'on appelle aujourd'hui le Memory Wall.
00:16 C'est quoi le Memory Wall ? C'est comment je peux augmenter l'efficacité de calcul d'un GPU ou d'un système avec une grosse capacité de calcul,
00:24 sans souffrir de la bande passante pour accéder à la mémoire extérieure.
00:28 Ce qu'on vise en quelque sorte, on vise deux marchés qui sont très consommateurs de calculs aujourd'hui, qui sont la voiture autonome et le Generative AI.
00:36 On construit des puces et on est en modèle Fabless, donc on utilise aussi TSMC pour la fenderie.
00:44 Alors très rapidement, je vais essayer d'aller vite.
00:47 Alors nous on revisite complètement l'architecture, donc dans les chips en général, les chips classiques ou les GPU,
00:54 on va retrouver un peu une mécanique qui se base sur les caches pour ramener la data de la mémoire externe jusqu'au registre,
01:01 pour pouvoir alimenter les unités de calcul, sachant que toute cette mécanique là, elle sert à quoi ?
01:06 Elle sert un petit peu à maintenir ces éléments de processing occupés le maximum du temps possible.
01:12 Or aujourd'hui, cette architecture là, quand on commence à aller vers les 1 petaflop en termes de capacité de calcul,
01:18 on voit qu'on a un peu du mal à alimenter les unités de calcul.
01:22 Alors très rapidement, nous ce qu'on fait, on vient fusionner un petit peu toutes ces structures là en unités centrales,
01:28 donc une mémoire centrale avec une très forte bande passante.
01:31 Alors ça, ça permet effectivement d'augmenter la bande passante pour accéder à la data, mais ça ne résout pas tous les problèmes.
01:36 Ce qu'on fait également, c'est qu'on transforme un peu toute cette mémoire là en registre.
01:41 C'est-à-dire l'architecture, elle est dessinée de façon à ce que toutes les datas qui sont stockées dans cette mémoire centrale soient vues comme des registres.
01:48 Donc ça c'est très bien, mais ça crée aussi d'autres problèmes.
01:52 Typiquement, les problèmes de compilation.
01:54 Si vous prenez aujourd'hui un compilateur, vous lui donnez des centaines ou des milliers de registres, il va pouvoir s'en sortir.
02:00 Mais si vous lui donnez des dizaines de millions de registres, il ne peut pas résoudre le problème.
02:05 Donc une façon pour résoudre ça, c'est que nativement dans notre circuit, on ne gère pas d'escalaires,
02:10 on gère nativement des matrices et des vecteurs.
02:13 Du coup, on est un peu ce qu'on appelle un "Q-DAFRI", c'est-à-dire que tous ces opérateurs classiques sur les matrices et les vecteurs sont gérés intrinsèquement dans le silicium.
02:23 Pour vous donner des ordres de grandeur, aujourd'hui si vous prenez un GPT-4,
02:28 je pense qu'on sait ce que c'est à peu près aujourd'hui ce que c'est un GPT-4,
02:32 c'est à peu près 1,8 pétaparamètre comme neural network en quelque sorte,
02:39 on tourne autour d'une efficacité de 3%.
02:42 Alors 3% ce n'est pas assez pour déployer tout ce qui est de Generative AI.
02:46 Aujourd'hui on bloque complètement sur le déploiement de Generative AI parce qu'on a un coût de requête qui est extrêmement élevé.
02:53 Donc si vous regardez un peu le chat GPT sur le nombre de requêtes qu'il gère aujourd'hui,
02:56 vous voyez très bien qu'ils sont montés très rapidement à 2 milliards de requêtes par mois,
03:00 qui est extrêmement peu en quelque sorte et qu'on n'arrive pas à aller plus loin.
03:05 Pourquoi ? Parce que le coût de la requête reste autour de 0,1$,
03:09 sachant que l'objectif du marché c'est de descendre à 0,2 cents.
03:13 Donc en fait le delta est encore très important et le chemin est encore long.
03:17 Nous dans notre architecture on arrive en fait à avoir une efficacité de 50%
03:21 et donc de pouvoir vraiment atteindre ce coût là en fait pour une requête chat GPT.
03:28 Alors très rapidement on a deux lignes de produits dans notre cas,
03:31 on a une ligne de produit Data Center, c'est la partie Yotune 8.
03:35 Donc ça ce sont des solutions qui peuvent aller jusqu'à 6,4 petaflops.
03:39 Ça incorpore aussi 8 mémoires HBM dans le système, donc on a 192 GB.
03:45 Donc c'est quand même des petits monstres de calcul ce qu'on voit là.
03:49 Ceci étant même avec un monstre de calcul comme celui-ci,
03:52 on n'arrive pas à mapper un GPT 4 aujourd'hui.
03:54 On est obligé d'en mettre plusieurs dans toute la chaîne
03:58 et arriver à mapper cet algorithme là sur plusieurs puces.
04:01 Et puis après on a une deuxième ligne de produit qui va démarrer à 800 TFLOP
04:06 en termes de processing power, qui elle adresse plutôt le marché de la voiture autonome
04:10 et le marché de tout ce qui est Embedded AI.
04:13 Donc on a deux lignes de produit, une qui va vraiment très haut en termes de puissance de calcul
04:17 qui intègre beaucoup de mémoire en fait dans la puce, donc 192 GB,
04:22 et un deuxième qui est plus légère mais ça reste quand même des solutions à 800 TFLOP.
04:28 Alors en termes de flow de développement, on est une société qui fait des chips,
04:33 on développe du hardware, mais en fait on passe beaucoup plus de temps
04:36 sur nos outils de développement, sur nos plateformes de développement
04:38 que sur le développement du Cilicium en lui-même.
04:40 Donc typiquement sur la partie compilation, on a deux niveaux de compilation.
04:44 On a un compilateur AI qui permet de s'interfacer avec tous les frameworks existants,
04:49 donc typiquement PyTorch, OnNNX, TensorFlow.
04:52 On va générer un code C++, puis après un deuxième compilateur LLVM
04:57 qui lui va prendre ce code-là et va le mapper sur notre coeur.
05:02 En fait, le code qui est généré, il peut être généré par le premier algorithme AI,
05:07 mais il peut aussi être écrit par les ingénieurs.
05:10 On a un code type MATLAB-like ou TensorFlow-like qu'on vient compiler au niveau LLVM.
05:16 Le code est développé comme s'il tournait sur le host-processeur qui contrôle notre puce.
05:22 Donc on développe du code sur de l'ARM, sur du RISC-V, sur du RISC-86.
05:27 Et au moment de la compilation, on vient automatiquement identifier
05:30 tout ce qu'on peut offloader vers notre puce.
05:34 Aujourd'hui, on dispose de plusieurs plateformes de simulation.
05:41 Ça rejoint un peu ce que disait un petit peu Philippe auparavant.
05:44 On est obligé de valider tout le système, d'avoir ces plateformes-là.
05:48 On a une plateforme native.
05:52 On fait tourner le code sur des plateformes qui ne voient pas un peu notre architecture.
05:55 Donc ça constitue un petit peu une référence.
05:57 Après, on a des modèles du système qui sont plus des modèles high level.
06:02 C'est utilisé par des ingénieurs typiquement pour voir quel est le nombre de cycles
06:06 que ça va me prendre, comment je vais dimensionner mon système,
06:08 quelle est la taille de mémoire que je vais occuper.
06:11 Et puis des modèles type TLM2, système C.
06:14 Alors RTL, ça c'est plus pour nous, pour notre propre utilisation.
06:17 Modèle TLM, c'est plus pour l'intégration logicielle.
06:20 Donc les gens qui font l'intégration du système, on va leur donner ce modèle-là
06:24 pour pouvoir l'intégrer facilement et on va résoudre 99% des bugs logiciels
06:29 qu'il y a dans le système.
06:31 Mais on a aussi des solutions qui tournent aujourd'hui dans le cloud FPGA d'Amazon.
06:37 Ça permet aussi de voir les perfs en attendant les cartes PCIe board
06:42 et les serveurs à base de notre circuit.
06:45 Ce qui est important de voir sur ce flow de développement,
06:47 c'est que ce n'est pas un flow pour compiler sur un coeur.
06:50 C'est un flow pour compiler sur plusieurs coeurs.
06:53 Et ces coeurs-là peuvent être dans un même circuit intégré,
06:56 sur plusieurs serveurs, voire même sur plusieurs locations.
07:00 Et ça c'est un élément vraiment important pour le déploiement de ces LLM,
07:06 à très forte demande de capacité de calcul.
07:10 Donc voilà rapidement, je ne vais pas vous prendre un peu plus de temps,
07:14 mais c'était juste pour vous montrer rapidement ce qu'on fait
07:17 avec notre flow de développement.
07:19 Merci.