Gabriel de Marmiesse

372

Dev AI

Gabriel de Marmiesse

Les bests practices pour construire un modèle

La reproductibilité, c'est un truc que moi, j'ai l'impression que l'industrie a abandonné
Suivre IFTTD =>

Le D.E.V. de la semaine est Gabriel de Marmiesse, technical staff chez Kyutai. Dans cet épisode, il lève le voile sur le quotidien d’un dev AI : entre code non déterministe, gestion de fichiers de teraoctets et galères de GPU, rien n’est jamais simple. Gabriel partage comment la recherche et l’engineering s’opposent (et se complètent), pourquoi l’open source vit une crise de confiance à l’ère des LLM, et ce qui distingue fondamentalement le dev AI du dev classique. Il explique aussi comment son équipe tente de démocratiser l’audio, la trad en live, et les world models. On ressort avec les câbles qui chauffent, mais les idées claires !

Chapitrages

00:00:53 : Promesse de l'informatique

00:01:52 : Présentation de Gabriel

00:05:06 : Chez Kyutai, l'open source

00:09:48 : Naissance d'Invincible Voice

00:13:09 : Poids et déploiement des modèles

00:23:27 : L'histoire de l'IA moderne

00:30:37 : Écrire un modèle en code

00:34:29 : Pourquoi les résultats varient

00:39:35 : Du labo au produit

00:45:37 : Le casse-tête des GPU

00:52:08 : Comparer avec le web

00:54:24 : Les world models arrivent

00:59:41 : L'avenir des LLM

01:05:01 : Préférences et tabulations

Chaine de CPP: CppCon - YouTube

Cet épisode n'a pas encore été compilé !
Un épisode est généralement refactoré 3 ans après sa diffusion !

Un peu de patience ...
Pas d'extraits disponible :(
Bruno:
On nous a vendu l'informatique comme étant une science exacte. La promesse était simple, presque rassurante. La même entrée donne toujours la même sortie. 2 plus 2 font 4, c'était le cas hier, c'est le cas aujourd'hui et sans doute encore demain. Le développeur classique vit dans ce monde-là, un monde de tests unitaires, de codes déterministes où un bug finit toujours par se faire attraper. Et puis il y a l'autre développeur, celui qui manipule des fichiers qui pèsent des teraoctets, qui passe sa vie scotché à un GPU et dont le code, petit détail, ne donne jamais tout à fait deux fois la même réponse. Mais alors, qu'est-ce qui sépare vraiment le dev classique d'un dev AI ? Comment teste-t-on un code qui n'est pas déterministe ? Et surtout, peut-on encore coder sur le laptop qu'on a sous la main ? Ou est-ce qu'il faut maintenant vendre un rein pour s'offrir le bon GPU ? Pour répondre à ces questions déterminées, je ne reçois pas Karl Lagerfeld, mais il s'y connaît en modèle. Gabriel, bonjour.

Gabriel:
Bonjour Bruno.

Bruno:
Alors Gabriel, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?

Gabriel:
Oui, tout à fait. Du coup, je m'appelle Gabriel de Marmiès. Au niveau de mon parcours, j'ai fait une école d'ingénieur. Je me suis retrouvé dans un laboratoire d'intelligence artificielle qui s'appelle Valeo AI pour travailler sur la recherche dans les voitures autonomes. Puis ensuite, je suis passé par Safran AI, qui est une entreprise qui travaille dans la défense et dans le renseignement, qui vend des logiciels de renseignement à l'armée. Et ensuite je me suis retrouvé, j'ai fait un petit passage par Datadog et au final je me suis retrouvé du coup à Qtai actuellement où je travaille actuellement et je suis là-bas depuis un an et demi. J'ai beaucoup travaillé dans l'open source, j'ai fait vraiment beaucoup d'open source à la fois comme maintainer mais aussi comme contributeur, beaucoup sur différents projets. Il y avait Keras, il y avait Siton TensorFlow, là en ce moment je maintiens mon propre package qui s'appelle Python on Rails, j'ai pas mal contribué à la librairie standard de Mojo et là je suis très bien à Qtai parce que du coup Qtai mon travail c'est faire de l'open source donc au final c'était un petit peu le but de toute ma carrière c'était je fais de l'open source sur le côté gratuitement et puis maintenant je suis dans le bon labo parce que je fais ça en étant payé.

Bruno:
Alors attends juste parce que tu as glissé vite fait Python on Rails ?

Gabriel:
Python on Rails.

Bruno:
Ah ok parce que du coup j'ai cru que c'était faire du Ruby on Rails qui est un framework Ruby et du coup je me suis dit que tu étais peut-être en train d'essayer de porter le framework dans un environnement Python.

Gabriel:
Non pas du tout Python on Rails c'est la référence à Docker, et en fait c'est un client pour Docker c'est à dire que en fait à la base pour faire la petite parenthèse à la base il y avait un client pour contrôler Docker depuis Python qui était le Python SDK de Docker qui était fourni par l'entreprise Docker, seulement c'était on va dire il y avait pas mal de limitations et des limitations qui étaient en fait structurelles c'est à dire que c'était un client qui recodait tout ce que faisait le client Docker, et le client Docker est écrit en Go et en fait ce que contrairement à beaucoup d'autres clients dans beaucoup d'autres, setup ce client là est extrêmement complexe il fait vraiment des choses hyper complexe là récemment avec le nouveau docker build la complexité du client a complètement explosé ils font du multi-threading ils envoient des données ils en reçoivent en même temps enfin bref c'est une complexité folle, Et en fait, du coup, à cause de ça, les dernières features, par exemple, le nouveau Docker build n'était pas porté sur le client Python. Ils ne pouvaient pas parce que les maintainers disaient que c'était trop compliqué. On ne va pas s'embêter à réécrire un truc qu'on a écrit en Go.

Bruno:
Qui est aussi complexe.

Gabriel:
À le réécrire en Python infaisable. Et donc, du coup, j'ai réimplémenté un client qui est excessivement simple, qui appelle juste la CLI. Mais vu que c'est typé, vu que c'est très, très simple comme code base, vous avez votre VS Code qui vous dit ah bah là il y a tel argument dans telle fonction il est typé avec tel type bon bah voilà et du coup, c'est d'une simplicité crasse mais ça fait tellement bien le boulot que du coup je crois que c'est l'un des projets qui est le mieux réussi canon, bref c'est la petite parenthèse sur le petit projet Python on Wales.

Bruno:
Donc tu me dis que t'es chez Qtai aujourd'hui.

Gabriel:
Qui est un.

Bruno:
Labo où tu fais de l'open source mais vous faites quoi chez Qtai.

Gabriel:
? alors Qtai on va la phrase type qu'on va donner c'est que c'est un fonds de dotation à but non lucratif dont le but est de démocratiser l'intelligence artificielle et du coup si on sort de cette phrase un peu, technique un peu bateau pour donner un peu plus concrètement c'est on fait de la recherche qui est ouverte donc on publie tout ce qu'on fait, et quand je dis on publie c'est pas juste des papiers de recherche on donne aussi le code pour tous nos modèles Donc on sort les poids, on sort le code, on sort le papier et on s'efforce de répondre aux questions de toutes les personnes qui voudraient poser. On reçoit régulièrement des mails, des issues, etc. pour des gens qui essaieraient de reproduire nos modèles, qui essaieraient de refaire ce qu'on a fait ou d'intégrer ce qu'on a fait dans d'autres choses. Et donc du coup, on est un fonds de dotation et on a eu de généraux donateurs qui nous ont donné de l'argent pour aller faire de la recherche et aller publier. Afin que tout le monde puisse en servir, nos projets principaux, ça tournait beaucoup pour l'instant autour de l'audio, mais il n'y a pas que l'audio, en ce moment on fait pas mal de word models. Et parmi les projets je peux vous citer quelques projets qui ont eu pas mal de succès chez nous. Il y a eu le tout premier qui a fait parler de nous qui s'appelle Moshi, alors Moshi c'était la première IA conversationnelle qu'on appelle full duplex, donc qui était capable d'écouter et de parler en même temps c'était sorti même avant OpenAI, il faut le dire, OpenAI mode voix est sorti après Moshi. Et du coup voilà Moshi c'était une IA vous lui parlez et elle vous répondait mais tellement vite, que parfois il y avait des gens on avait l'impression qu'on les coupait tellement l'IA parce qu'en fait l'IA est capable de parler et d'écouter en même temps et du coup il y a beaucoup moins de latence typiquement que, quand vous parlez typiquement à un LLM vous avez un speech to texte qui va retranscrire ce que vous dites ensuite il y a un LLM qui va travailler et qui va lire votre question et ensuite il y a un text to speech qui va vous lire ce qu'a dit le LLM bon ça il y a une petite latence et du coup avec Moshi, Moshi est capable d'écouter et de parler en même temps donc en fait il processe un stream modules en entrée et en sortie en même temps et du coup il y a zéro latence du coup, limite il peut commencer à vous répondre avant même que vous ayez fini votre question, donc voilà ça c'est le plus gros projet qu'on a fait qui avait fait parler de nous à la base et ensuite il y a plein d'autres projets qui si vous êtes développeur peut-être vous seront utiles donc voilà je vais les citer les quelques-uns, qui peuvent vous intéresser il y a Ibiki par exemple qui est un outil qui fait penser un peu aux fonctionnalités sur les Airpods où vous parlez dans une langue et ça vous retranscrit dans une autre langue en live, donc voilà on a sorti les modèles en open source si c'est quelque chose qui vous intéresse donc voilà vous avez un flux audio en entrée et ça vous traduit en live ce que vous dites donc pareil en full duplex ça passe pas par du texte, on a des text to speech et des speech to text aussi attends.

Bruno:
Parce que du coup c'est en full duplex la traduction ça veut dire que si j'écoute quelqu'un me parler en turc en temps réel j'ai un audio en français.

Gabriel:
Alors qu'il a même pas fini sa phrase ça commence déjà à traduire.

Bruno:
C'est un truc de ouf, je savais pas parce que pour moi les Airpods t'avais une transcription écrite Alors.

Gabriel:
C'est une bonne question, je sais pas si les Airpods ils font par l'écrit mais en tout cas nous on a ce projet qui s'appelle Ibikis, ça vous intéresse, et quand vous commencez à parler il y a même pas besoin de forcément finir la phrase pour commencer à entendre la traduction, et dans mes souvenirs il y a le clonage de voix aussi, donc du coup ça vous fait la traduction avec votre propre voix, comme si c'était vous qui parliez dans une autre langue donc il y a du text to speech du speech to text qu'on fournit aussi, il y a des projets qui sont intéressants comme il y a par exemple Unmute qui est du coup un peu ce rappeur dont on parlait autour d'un LLM avec du coup nos outils de speech to text et text to speech où on fait toute la machinerie derrière pour que ça marche bien et que ça soit synchronisé et tout ça, et il y a le clonage de voix qui est disponible alors du coup on a des mots marrantes si vous voulez si sur le site web vous pouvez parler au général Charles de Gaulle avec la voix de l'époque voilà, ensuite dérivé de ce projet là il y a un projet qui s'appelle Invincible Voice qui avait pas mal fait parler de lui, en tout cas dans la presse française qui était du coup un peu un dérivé de ce truc là où c'est un projet pour aider les gens qui ont la maladie de Charcot donc la maladie de Charcot pour restituer c'est une maladie qui est terrible qui vous fait perdre l'usage de vos muscles progressivement, qui souvent amène un diagnostic fatal au bout de quelques années et ces personnes là perdent l'usage de la voix assez vite. Du coup, on s'est dit, est-ce qu'il y a moyen ? C'était Olivier Goua qui était venu nous parler. En fait, Olivier Goua qui est malade de Charcot et qui est porteur de plein de projets autour de cette maladie, qui est venu nous voir et qui a dit, j'ai quelques idées, est-ce qu'on peut voir ce qui est possible de faire ? Et en fait, du coup, nous, ce qu'on s'est dit, c'est qu'il y a moyen de faire un produit assez marrant. Alors, un produit, nous, on ne vend rien. Je dis ça comme ça, mais voilà. Un outil assez marrant où, en fait, quelqu'un va parler. Donc une personne valide va parler à la personne qui est malade du coup va y avoir, un outil de speech to text qui va retranscrire ce qui est dit qui va donner ça à un LLM et si le LLM connait suffisamment bien le malade le LLM pourrait suggérer des phrases complètes que le malade pourrait répondre donc on va faire l'exemple le plus bateau possible et imaginable, par exemple moi je vois Olivier je lui dis Olivier est-ce que tu veux qu'on aille au restaurant ce soir bon il va peut-être cliquer sur oui ou non sur l'interface ça va le lire à haute voix avec sa propre voix clonée, donc la voix d'avant qu'il ait la maladie, et après on peut lui dire qu'est-ce que tu voudras manger alors là il va peut-être il va y avoir le LLM qui va tourner qui normalement a assez d'informations pour répondre à la question et va proposer des réponses à Olivier et du coup il aura pas à taper lui-même en fait sur le clavier parce que ça serait trop long pour lui et du coup il va juste cliquer sur par exemple je mangerais bien des pâtes carbonara ce soir j'adore ça. Et du coup après il clique là-dessus et ça va le lire en haut de voie ce qui fait que, Au lieu d'avoir une personne, parce qu'en fait, il faut se restituer. Avant, comment ils faisaient, les gens qui avaient la maladie de Charcot, ils étaient obligés de taper lettre par lettre. Et du coup, tu posais une question, tu disais la moindre chose, tu étais obligé d'attendre une minute trente qu'ils tapent le message pour te répondre. Et c'est impossible d'avoir une conversation. Alors que là, sur des sujets, généralement des sujets qui sont bien connus pour le malade et qui sont assez bien documentés, en fait, tu peux presque avoir une conversation en temps réel. Et dans le cas d'Olivier, qui est un sacré rigolo, ça lui permet aussi de beaucoup de faire des blagues et c'est difficile de faire des blagues quand t'as une minute trente de délai mais lui il est assez marrant là dessus et du coup il aime bien blaguer.

Bruno:
Je l'ai vu effectivement sur des interviews je savais pas que c'était ça qui tournait derrière mais est-ce que ça veut dire que du coup si je reprends ce modèle là, il y a aussi moyen de faire un LLM qui est meilleur que moi même et que du coup je peux avoir un système qui répond à ma place des réponses que moi même j'aurais jamais imaginé, Si je prends le cas d'un entretien d'embauche, par exemple.

Gabriel:
Ah oui, tout à fait. Bon, après, il faut que la personne, elle voit que c'est pas toi qui répond et que c'est le même qui répond.

Bruno:
Mais tu vois, comme j'ai potentiellement une interface qui me propose trois réponses. En fait, on ne me voit pas taper sur le truc. On ne voit pas. Tu vois, ça peut être.

Gabriel:
Ah oui, tout à fait. Tout à fait. C'est une possibilité. Si jamais tu veux faire un essai, libre à toi. Je ne sais pas ce que ça va donner, mais tu peux essayer. Nous, c'était rigolo. quand on faisait le test avec Alex qui est un des fondateurs du labo et un de mes collègues, et qu'on testait Invincible Voice et je faisais genre je suis malade et lui il posait des questions il me faisait rire parce que du coup il était en mode alors est-ce que tu peux m'expliquer la mécanique quantique comment ça fonctionne les équations et du coup ça te proposait plein de réponses j'aurais jamais trouvé, mais c'était rigolo à faire pour les tests t'as.

Bruno:
Évoqué aussi tout à l'heure que tous les modèles que vous créez vous les mettez à disposition, et donc tu as évoqué le fait que vous mettez les poids à disposition, c'est-à-dire que effectivement, pour ceux qui ne le savent peut-être pas en tout cas de ce que j'ai compris, c'est qu'en fait tu ne vas pas forcément télécharger un binaire qui va s'exécuter comme une application standard, tu télécharges en gros un JSON que tu peux après avec des outils comme Ginkface et autres, tu peux répliquer en fait tous ces poids entre les différents neurones, la raison de neurones, pour répliquer le modèle que vous avez conçu, c'est ça à peu près le...

Gabriel:
Alors ça dépend beaucoup de comment c'est déployé. Il y a plein de façons de déployer les réseaux de neurones et ça va pas être la même chose si jamais tu fais une application pour un client par exemple, si tu fais une version cloud, si tu fais quelque chose pour des développeurs, ça va pas du tout être le même format en fait. Typiquement si je te donne un exemple, bon bah voilà tu parles un chat GPT, tu utilises une interface web et ton interface web du coup c'est des serveurs qui tournent quelque part et c'est comme ça qu'ils fournissent le service. Si tu voulais installer un LLM sur l'ordinateur de quelqu'un, Ben typiquement je pense que tu fournirais un énorme binaire en fait tu vois tu t'aurais sûrement un binaire qui serait très très gros ça dépend de la taille du modèle nous par exemple récemment on a réussi à sortir un modèle de text to speech qui était hyper petit qui fait 200 mégabytes tu vois alors ce qui semble beaucoup mais c'est très petit pour text to speech et du coup par exemple nous on le fournissait pour les développeurs donc du coup c'était pas sous forme de binaire on le fournissait sous forme de bah du coup il y a des poids donc là pour le coup c'est un gros, c'est un gros binaire sur internet où il y a juste des poids brut de décoffrage où c'est juste des floats une liste de floats et après on va fournir du code, qui lui a la structure du modèle on va dire là tu as un matrix multiply là tu as une addition là tu as une soustraction là tu multiplies par une constante voilà etc donc tu as tout un tas d'opérations comme ça et. Tout ce tas d'opérations il va utiliser des valeurs flottantes qui sont du coup récupérées de Hugging Face typiquement, où il y a ce gros blob avec tous ces floats qui se baladent dedans et voilà donc souvent ce que ton code il fait quand tu distribues ça à des développeurs, nous on faisait ça pour des développeurs pour le cas du Pocket TTS, la personne qui exécute notre code Python, la première fois que ça s'exécute, ça va aller télécharger le gros fichier de Hugging Face. Et en local et ensuite ça le relie à chaque fois qu'il y a besoin et votre code charge ce modèle là. Quand vous allez shipper des binaires, je pense que ça arrive assez fréquemment que ça soit en BD à l'intérieur. Si c'est vraiment trop gros, ça arrive, les modèles peuvent faire plusieurs terabytes. Si le modèle est vraiment trop gros, parfois c'est des trucs qui sont séparés du binaire. Qui va lui présupposer que vos poids sont ailleurs sur le file system.

Bruno:
Juste pour être sûr que j'ai bien compris toutes ces opérations que tu as décrites, les multiplexes, les divisions et compagnie.

Gabriel:
En

Bruno:
Gros ça c'est l'opération de chaque transformeur de ton réseau de neurones, qui va du coup peut-être aussi faire le lien d'un transformeur à un autre parce que forcément qui dit réseau dit lien et après les poids c'est le poids attribué, au transit de l'information d'un transformeur à un autre c'est ça ou.

Gabriel:
Alors, oui vite fait je serais pas du tout offensé si tu me dis que je dis de la merde moi je.

Bruno:
Suis un incompétent notoire.

Gabriel:
J'ai aucun problème avec ça on.

Bruno:
Est là pour apprendre donc j'ai aucun soucis avec le fait que je dise de n'importe quoi.

Gabriel:
Alors en fait c'est un sujet qui est assez complexe donc du coup ça va être compliqué de vulgariser même moi je vais avoir du mal je pense, alors on peut imaginer ça si on imagine de manière très basique sans forcément parler de transformant etc il faut imaginer ça comme une succession d'opérations de matrices alors les matrices pour ceux qui ne voient pas forcément c'est juste des tableaux de valeur, des tableaux de flottants alors nous on bosse avec beaucoup de flottants donc c'est souvent des tableaux de flottes 32 ou flottes 16 parfois même, donc voilà vous avez imaginons un cube en 3 dimensions avec des flottes 16 dedans vous imaginez qui arrive en input, ça peut être des integers mais bon généralement quand ça arrive on est arrivé dans un LLM c'est typiquement des mots qui ont été transformés en un integer donc chaque integer correspond à peu près à un mot donc vous arrivez avec votre matrice de mots là comme ça avec des integers, et vous commencez à faire des opérations dessus alors donc il peut y avoir des opérations ça va être par exemple une multiplication de matrice. Vous prenez une matrice avec une autre matrice et vous multipliez toutes les valeurs entre elles pour faire simple, et donc ça typiquement cette multiplication de patrice par exemple l'input il va bien falloir la multiplier avec quelque chose, donc ça c'est typiquement vos poids c'est des valeurs qui sont constantes qui seront toujours les mêmes et toutes les inputs seront toujours multipliées par les mêmes valeurs, et donc après par exemple imaginons ça dépend de la forme qu'il y a de votre réseau mais donc là vous obtenez un autre tensor du coup puisque vous avez fait votre matrix multiply et après vous vous dites bon bah maintenant je vais faire une addition et donc c'est pareil, il faut l'additionner à quelque chose et donc du coup ça va être les poids, ce qu'on appelle les poids du réseau et donc du coup il y aura une seconde matrice, qui sera dans la liste des poids du réseau et vous allez prendre cette seconde matrice et hop vous additionnez à celle que vous venez d'obtenir et vous continuez comme ça comme ça et alors du coup si vous tracez un petit peu la liste d'opération bah, parfois ça fait des branches donc du coup c'est rigolo parfois ça peut ressembler à un réseau parfois c'est très linéaire ça arrive que parfois vous ayez des réseaux qui soient une opération les unes après les autres alors là du coup ça ressemble pas trop à un réseau mais en fait à la base ça s'appelait les réseaux de neurones, Parce que les matrices multiply, si jamais vous les voyez d'un point de vue purement très basique, sans le tableau, en fait, vous pouvez imaginer ça comme des neurones qui sont interconnectés les uns aux autres et ça fait des multiplications. Mais c'est une vision qui date d'une époque où il y avait très peu de neurones. Maintenant, on bosse avec des modèles qui font des terabytes. Donc les gens ils sont plus au niveau du quelques neurones ils sont au niveau de, le transformer qui fait je sais pas combien de dizaines de gigabyte et qui fait son truc donc voilà c'est pour ça que maintenant on parle beaucoup moins de réseaux de neurones parce qu'on est abstrait de plus en plus haut dans la chaîne et on parle plutôt d'IA du communement parce.

Bruno:
Que c'est à dire qu'aujourd'hui quand tu conçois un modèle en fait tu agences un ensemble de modèles d'une certaine manière.

Gabriel:
Les.

Bruno:
Uns avec les autres.

Gabriel:
Ouais ça peut être des sous modèles tu peux imaginer ça comme des sous modèles et typiquement le transformer C'est une architecture, donc ça va être une suite de multiplication, de soustraction, de matrix multiply, de softmax, de choses comme ça. Enfin, d'opérations sur des matrices qui sont agencées d'une certaine manière. Et c'est souvent ce bloc-là qui va être répété. Les uns après les autres et typiquement tu les enchaînes et après à la fin tu vas récupérer bah ça va te sortir, la probabilité de chaque mot en fait donc dans le cas des LLM c'est t'as donné du texte et on va te dire bah du coup on va dire en fait le LLM c'est très simple on lui donne du texte en entrée on lui dit bah du coup c'est quoi le prochain mot allez devine, et en fait on s'est aperçu que si on forçait une machine à faire ça très très fort elle se mettait à devenir très intelligente enfin elle donne.

Bruno:
L'impression en tout cas d'être très.

Gabriel:
Intelligente Ah ouais elle donne l'impression après bon qu'est ce que l'intelligence bon là on va rentrer dans des débats sans fin mais c'est voilà en tout cas elle elle peut faire des choses utiles on va dire ça c'est certain mais.

Bruno:
Donc donc toi.

Gabriel:
T'es développeur.

Bruno:
AI c'est ton titre ton job title c'est quoi ton job title.

Gabriel:
Alors techniquement c'est technical staff et alors à Qtai alors en fait c'est un petit peu un problème parce qu'à Qtai tout le monde s'appelle technical staff même les gens qui sont chercheurs donc du coup c'est un peu étrange, je vais juste dire développeur c'est juste que chacun a une spécialité différente moi il se trouve que je suis spécialisé dans l'IA mais voilà c'est comme tu as des développeurs qui sont spécialisés dans le bas niveau dans le C++, dans l'MBD voilà moi c'est juste ma spécialité c'est l'IA.

Bruno:
Parce que du coup dans cette conception d'un modèle donc de ce que moi je comprends ce fichier de poids les poids en fait c'est des choses qui sont déterminées au moment de l'entraînement où en fait tu fais passer un test des millions de fois à une IA où elle a juste de manière un peu random, ses poids jusqu'au moment de trouver un résultat qui passe mais donc toi ton boulot c'est sur l'agencement de toutes ces opérations en fait en gros ?

Gabriel:
Alors souvent la manière dont ça se fait c'est que du coup il y a les chercheurs qui eux vont entraîner le modèle c'est souvent ce qui se passe, donc du coup eux ils vont trouver les bons poids pour faire simple et la bonne architecture, donc ils vont avoir une code base d'entraînement qui est absolument imbuvable pour n'importe quel autre développeur classique donc voilà si vous avez l'habitude de bosser, je sais pas si vous êtes développeur cloud ou whatever et là vous vous mettez à regarder la code base d'un chercheur souvent c'est c'est un peu rude la première fois voilà donc.

Bruno:
Il y a aucune bonne pratique il n'y a pas de.

Gabriel:
Mais oui mais en fait c'est pas ce qu'on leur demande donc il n'y a aucun blâme à donner c'est eux pour eux c'est ce qui leur permet d'aller le plus vite et j'ai même envie de dire maintenant avec les outils comme CloudCode et ben les chercheurs c'est les premiers à ne plus regarder leur code base en fait parce qu'ils se disent mais moi je m'en fiche de toute manière mon code. Je veux tester quatre versions de mon modèle en une heure. Si le code il est immonde, je m'en fiche. Tant que ça marche à la fin, s'il marche, je donne le code à Gabriel et après il se débrouille. Et je m'en fiche en fait de si le code il est propre. De toute manière, j'ai 9 chances sur 10 pour que le code finisse à la poubelle après. Donc, qu'il soit propre ou pas, ça m'est égal. Et donc, du coup, ils ont une code base où ils vont faire leurs entraînements avec ça. Typiquement, donc ils vont avoir 1 million de branches possibles. Alors, si je mets telle opération, après celle-là. Et donc ils vont tester plein de variations du modèle en.

Bruno:
Fait moi c'est ça qui me fait poser question parce que on parle d'un les LLM actuel.

Gabriel:
Tu

Bruno:
L'as dit il peut faire plusieurs teraoctets c'est à dire qu'on parle de plusieurs millions ou milliards de transformers en fait en gros de neurones qui sont connectés.

Gabriel:
J'imagine.

Bruno:
Qu'il n'y a pas un être humain qui dit alors là je vais mettre un neurone ici.

Gabriel:
Et puis après il va faire telle.

Bruno:
Opération et puis après il va faire telle opération on ne peut pas le faire à la main ça.

Gabriel:
Ah ouais c'est clair bah en fait c'était je peux essayer de refaire un petit peu l'histoire de l'AI telle qu'on la connait de nos jours peut-être ça donnera un petit peu ça permettra aux gens de comprendre un petit peu mieux ce qui se passe en gros, on va imaginer à la préhistoire de l'AI que faisaient les gens à la préhistoire de l'AI et bien il y avait des gens comme Yann Lequin qui bossait sur, juste des algorithmes très simples où vous vous dites ah ouais si je prends une matrice je la multiplie avec celle-là et ensuite j'additionne un autre truc Sous-titrage ST' 501, Est-ce qu'il y a moyen que le résultat que ça me donne, je puisse le comparer à une valeur réelle que moi je voudrais que ça soit ? Donc imaginons, je te donne des pixels qui représentent un chiffre, par exemple, et je demande au modèle, est-ce que ça fait 1, 2, 3, 4, 5, 6, 7, 8 ou 9 ? Et là, le modèle, il va te dire, ça fait un 3, par exemple, et toi, tu voulais que ça dise 5. Et là, du coup, la question qui se posait à l'époque, c'est est-ce qu'il y a moyen de dire, c'est faux, ajuste tes poids automatiquement. Mais c'était à une époque où les opérations étaient simplissimes, ils faisaient des trucs, ils faisaient des matrix multiplies sur 16 par 16 valeurs c'est vraiment une échelle hyper simple et donc du coup ils avaient trouvé ce qu'ils appellent la backpropagation c'est un algorithme qui globalement te dit, si tu t'es trompé comment te réajuster pour que tu te trompes pas la première fois pour faire simple, et tu donnais énormément de valeurs, et ça c'était la base c'était que tu donnais énormément d'exemples au modèle et lui il se trompait beaucoup et il réajustait un petit peu à chaque fois ses poids jusqu'à ce qu'il trouve les bonnes valeurs qui font que du coup il ne se trompe plus trop. Donc ça c'est la base de l'apprentissage et ça c'est l'algorithme qui a donné naissance à tout, mais à l'époque on n'avait pas le moyen de scaler on va dire et donc on faisait souvent des opérations très très simples donc voilà on faisait des additions avec des matrices qui faisaient du 16 float par 16 float donc voilà on faisait des choses très très basiques. Et en fait ce qui s'est passé C'est là où la révolution a commencé, Il y avait un benchmark qui s'appelait ImageNet. ImageNet, c'était quelqu'un qui avait assemblé un benchmark et qui avait dit, moi, je veux améliorer la computer vision. Je veux que les ordinateurs soient capables de dire, par exemple, quelle est la race du chien. Est-ce que c'est un lion ? Est-ce que c'est un éléphant ? Est-ce que c'est une fusée ? Est-ce que c'est une voiture ? Et donc, lui, ce gars-là, il a mis au point un dataset qui s'appelle ImageNet et il a dit, moi, je vais faire un benchmark, je vais faire tourner tous les ans et on va voir si il y a différentes équipes qui arrivent qui vont essayer de... Voilà, on va leur donner à manger une image à chaque fois ils vont nous dire ce que c'est et à chaque fois les performances étaient catastrophiques parce que les gars ils faisaient souvent des règles des trucs basés sur des règles alors si ça a une tête comme ça et que ça a des yeux comme ça ça va être un lion mais bref c'était une complexité il y a genre un million d'images dans le dataset bref c'est une complexité folle et donc du coup ça marchait pas très bien je crois que les meilleurs résultats c'était de l'ordre de 50% de réussite quelque chose comme ça et du coup ça. Il y a un gars qui arrivait un jour et qui a dit « écoutez, moi j'ai tenté un truc, j'ai pris cette règle-là, vous faites des multiplications de matrices avec la bague propagation, etc. pour réajuster. » Alors je sais que du coup, maintenant, ça fait beaucoup d'opérations à faire, les matrices multiplies sont énormes, c'est vraiment compliqué, etc. Et les CPU classiques ne peuvent pas le faire. J'ai eu l'idée un peu farfelue de le mettre du coup sur un GPU pour que ça aille plus vite, parce que les GPU sont très forts en multiplication de matrices. Et vos additions, sous-strictions de matrix c'est vraiment très fort pour ça, et il a dit du coup j'ai fait de la, backpropagation avec ça, avant on avait essayé qu'avec des images en noir et blanc de 16 pixels par 16 pixels et bon maintenant moi j'ai essayé ça avec des images énormes de 256 pixels par 256 pixels et du coup les...

Bruno:
Et en couleur.

Gabriel:
Et le mec il a fait ça et il a eu je crois 85% sur le benchmark et alors là c'est le moment où, le barrage est tombé c'est le moment où tout le monde a dit ok d'accord en fait c'est ça qui marche et donc du coup c'est là où c'est parti, là tout le monde s'est dit ok on va entraîner des modèles avec du coup ce système de backpropagation sur des GPU, pour tout plein de tâches possibles et imaginables mais ça c'était pas ce qu'on appelait l'IA générative c'était l'IA qu'on va appeler, discriminative, c'est à dire que vous allez lui donner une image par exemple et vous allez lui dire c'est quelle catégorie Il va vous donner une des catégories. Il ne va pas vous dire, il ne va pas vous générer une image, par exemple. Ce n'est pas son boulot. L'IA générative, ça arrivait bien plus tard. Et donc, du coup, on avait l'IA discriminative et ça a été très utilisé pendant très longtemps. Et donc, c'est-à-dire que jusqu'à 2012 à peu près, jusqu'à 2017-2018, en gros, c'était ça qui était dominant. Et en fait, les gens, c'est ce qui permettait, par exemple, sur Google Photos, vous tapiez, je ne sais pas. Crêpes, images de crêpes. et vous retrouviez dans vos photos personnelles toutes les photos de crêpes que vous aviez prises bon ça c'est un truc qui existait du coup depuis je sais pas 2014-2015 mais à l'époque on avait du mal à faire l'IA générative et l'IA générative, ça a vraiment démarré le moment où ça a vraiment tout cassé c'était 2017-2018 avec un papier qui s'appelle Attention is all you need, et c'était un papier de Google et en fait ce qui s'est passé c'est que les gars ils ont dit on va faire de la traduction avec un truc qui s'appelle les transformers. Et ils se sont dit en fait on a trouvé un truc très marrant et pour faire de la traduction ils se sont dit on va prendre du texte, on va entraîner un modèle à prendre du texte en input dans une langue, on va lui dire on va lui mettre un mot du style, traduit en italien par exemple et ensuite on lui laisse continuer le texte pour voir ce qu'il donne, et en fait on l'a entraîné à faire ça et du coup à traduire je sais pas français, anglais, des choses comme ça et juste prédire les prochains mots en fait c'était juste dans une séquence de texte qui était toujours une langue puis il prédit pour telle langue et hop il arrive à faire la traduction, Et en fait, les gars à l'époque, c'était pas forcément rendu compte du truc, mais en fait, c'était la base des LLM qu'ils avaient trouvés, les gars. Et c'était pas juste pour faire de la traduction, ça marche pour quasiment tout. Et à ce moment-là, il y a le premier gros usage commercial, ça a été OpenAI, qui s'est servi de ça et qui a lancé le premier service commercial et a dit, en fait, les gars, vous vous rendez pas compte, mais si on fait cette technique-là, il n'y a pas que de la traduction qu'on peut faire, on peut tout faire. Genre vraiment, on peut faire des IA généralistes qui répondent aux questions. Et donc c'est là que ça a commencé, Vraiment cette explosion de l'IA générative, on va dire. En tout cas d'un point de vue commercial, c'est l'IA que nous connaissons maintenant tous. Donc ça c'est un petit peu pour l'histoire, et donc comme c'est une succession d'additions, soustractions, de matrices, de multiplications, c'est ce système de backpropagation qui ajuste les poids, et l'IA s'entraîne jusqu'à ce qu'elle arrive à trouver les bonnes valeurs des bons floats qui vont bien, et hop ça vous donne un bon résultat et après vous gardez ça et vous le modifiez jamais et hop vous shippez ça en prod et c'est bon et après vous donnez ça au client.

Bruno:
Je vois mais donc toi en tant que dans la conception d'un modèle je comprends la notion d'entraînement on va déterminer les poids mais comment de manière très concrète comment est-ce qu'on détermine l'agencement des opérations ça.

Gabriel:
C'est très dur et c'est beaucoup beaucoup de tests et d'essayer de se planter et d'essayer une autre.

Bruno:
Architecture et de se planter ça je comprends qu'effectivement on teste des choses et on voit si ça marche ou pas mais ma question c'est comment on fait, techniquement pour dire telle opération dans le code à quoi ça ressemble en fait, comment je fais.

Gabriel:
Alors c'est une bonne question en gros si jamais pour les gens qui veulent se lancer, il faut le plus simple c'est de commencer avec un librairie qui s'appelle PyTorch du coup ça se fait beaucoup en Python c'est très très majoritairement Python l'IA donc voilà vous allez prendre votre meilleur package PyTorch et vous allez faire un import PyTorch et là vous allez définir, des opérations à faire en utilisant par exemple vous créez un Torch Tensor donc vous créez votre Tensor vous mettez des floats à l'intérieur par exemple des integers vous en créez un deuxième et typiquement vous allez donc vous avez une variable A qui contient votre premier Tensor une variable B qui contient votre deuxième Tensor et d'ailleurs vous allez faire A fois B Sous-titrage ST' 501, Et vous allez faire comme ça, une suite d'opérations que vous allez définir et donc si c'est un modèle qui existe déjà, au lieu de votre tensor B que vous aurez créé avec vous-même des floats, vous allez prendre un tensor qui était déjà créé dans un fichier en fait, qu'on vous a donné. Et donc voilà, vous allez définir votre suite d'opérations comme ça, juste vraiment A plus B, A multiplié par B, A divisé par B, voilà. Et donc vous prenez vos petites suites d'opérations et à la fin vous obtenez un résultat et vous dites, par exemple à la fin ça va être un integer qui va représenter c'est quoi le mot en sortie. Et là vous avez un petit dictionnaire qui vous dit pour tel chiffre, tel nombre ça correspond à tel mot dans votre dictionnaire. Et hop vous aurez tel mot à la fin. donc voilà c'est du PyTorch et généralement c'est du Python et tu vas juste définir avec la librairie, torch.convolution, torch.matrix.multiply torch.softmax enfin voilà toute une suite d'opérations mathématiques à faire.

Bruno:
Donc t'évoquais tout à l'heure que en fait aujourd'hui on a des modèles qui ont des, milliards de paramètres et de tensor partout et donc en fait ce qu'on fait pour construire un modèle c'est qu'on prend des sous-modèles, et donc en fait si tu veux j'imagine qu'un sous-modèle est lui-même peut-être constitué de sous-sous-modèle parce qu'il y a forcément un moment où quelqu'un va dire, bah là moi j'ai 4000 tensor et je les organise comme ça et du coup ça me permet d'avoir tel truc et tu les agences ensemble les uns avec les autres petit à petit quoi.

Gabriel:
Voilà et ça c'est le chercheur qui décide qui s'est farci d'essayer toutes les architectures possibles et imaginables jusqu'à ce que ça marche, et qui s'appuie sur le travail de dizaines d'autres chercheurs qui se sont passés avant lui et qui ont testé des trucs et 9 fois sur 10 ça marchait pas et voilà ils ont testé, testé, testé et même parfois en plus l'entraînement est un process, qui n'est absolument pas déterministe donc du coup parfois il y a des gens qui ont sorti des papiers en disant bah nous notre technique elle marche trop bien notre nouvelle architecture, notre suite d'opération elle marche dans toutes les situations et après toi tu réessaye et ça marche pas du tout enfin bref du coup c'est un travail qui est, extrêmement, pour les chercheurs c'est un travail qui est très dur parce que Parce que en fait parfois tu as l'impression que tu as trouvé une bonne architecture et puis en fait tu changes un micro paramètre et là ça marche plus. Donc, ça a été beaucoup de die and retry, pour donner l'analogie dans le jeu vidéo, jusqu'à ce qu'à la fin, tu trouves le truc qui marche.

Bruno:
Qu'est-ce qui fait que certains chercheurs peuvent trouver l'architecture qui fonctionne chez eux, et quand tu essaies de la répliquer, ça ne marche pas ? C'est le dataset d'entraînement qui change ? Comment ça se fait que ce ne soit pas réplicable ?

Gabriel:
Alors, il y a plusieurs choses qui vont changer ça. Je vais dire les plus grosses c'est quoi ? Les plus grosses il y a l'initialisation du modèle c'est à dire que, en fait cette back propagation dont on avait parlé au début qui est la technique qui permet d'ajuster les poids, va juste faire varier un petit peu vos poids jusqu'à ce que ça fonctionne mais il y a bien un moment quand vous avez commencé l'entraînement de votre modèle vous avez défini ce que c'était les poids à la base une suite de flottants, qui va bien alors à la base on sait souvent. On initialisait de manière aléatoire c'est à dire on tirait sur une distribution normale des valeurs et on initialisait comme ça et du coup qui dit valeur aléatoire dit une seed à la base pour dire comment faire votre tirage aléatoire, et par exemple il y a plein de gens du coup quand ils faisaient des entraînements ils mettaient une seed très précise pour générer l'état initial d'une modèle d'une certaine manière ils trouvaient une architecture trop bien ils disaient ah ouais regardez mon architecture et ma méthode d'entraînement elle marche trop trop bien, franchement vous devriez essayer c'est trop stylé et puis il suffit que la personne elle arrive elle fasse la même chose elle change l'acide du coup l'initialisation des poids sont pas exactement les mêmes et là ça marche plus du tout et du coup c'est extrêmement frustrant parce que tu te dis mais en fait mon architecture c'est pas ça qui a fait que ça a eu un bon résultat ce qui a fait un bon résultat c'est la chance tu vois et ça c'est un des exemples parmi tant d'autres un autre exemple c'est quand tu fais tourner des opérations sur gpu, le GPU ne garantit pas l'ordre des opérations. Et du coup, quand tu fais, par exemple, je vais te donner une opération très simple, mais si on additionne un millier de float 32, par exemple, sur un GPU, le GPU ne te garantit absolument pas l'ordre dans lequel sont additionnés les floats. Du coup, tu peux avoir plusieurs résultats différents quand tu fais plusieurs fois la même opération. Et là, tu comprends bien qu'en fait, la reproductibilité dans le monde de l'IA, c'est une affaire sans frein.

Bruno:
D'accord, donc en fait.

Gabriel:
On

Bruno:
Critique beaucoup l'LLM en disant que le résultat du LLM n'est pas déterministe mais la création elle-même du LLM n'est pas.

Gabriel:
Déterministe complète elle est carrément pas déterministe et du coup c'est extrêmement dur même d'un point de vue des chercheurs de leur demander de refaire deux fois le même entraînement et ça cause, beaucoup de problèmes dans la communauté des chercheurs qui est la reproductibilité des expériences parce que du coup tu sors un papier de recherche, tu dis ma technique elle est trop bien et là il n'y a personne qui arrive à refaire la même chose Et du coup c'est très problématique, C'est un problème qui est toujours d'actualité Qu'on n'a jamais vraiment résolu Qui est qu'en fait il y a trop d'aléatoires Il suffit que tu te trompes par exemple Ne serait-ce que dans le dataset La manière dont tu lis ton dataset, Souvent quand tu fais des entraînements Maintenant il y a plusieurs machines en parallèle qui travaillent Il suffit que les machines ne lisent pas les données dans le même ordre Et alors là c'est pareil C'est plus le même résultat Souvent c'est des entraînements qui durent, plusieurs jours, voire plusieurs semaines, voire plusieurs mois. Donc t'imagines sur plusieurs mois, il suffit que tu te rendes compte à la toute fin que ça fait plus la même chose. Alors là, c'est fini. Bref, en fait, la reproductivité, c'est un truc que moi, j'ai l'impression que l'industrie a abandonné. C'est très clairement dans le monde de l'IA, on a dit bon, les gars, c'est trop dur. On va faire ce qu'on peut. On fait le minimum syndical pour vérifier que nos résultats sont à peu près corrects. Mais on va pas pousser trop loin la chose parce que c'est trop de travail.

Bruno:
Oui parce qu'effectivement quand tu dis que comme tu n'as pas une garantie de l'ordre dans lequel les opérations sont faites, comme vous travaillez qu'avec des floats, pour essayer de comprendre d'où vient le problème c'est que tu as un arrondi qui est fait c'est ça sur ton opération et quand tu ne sais pas dans quelle ordre sont faites les opérations ton arrondi n'a pas toujours lieu au même moment et donc cette micro-valeur peut potentiellement avoir un effet boule de neige et aller très loin.

Gabriel:
C'est ça le problème, c'est en fait quand vous additionnez des floats vous avez zéro garantie les floats ça peut pas prendre toutes les valeurs possibles de l'univers il y a des valeurs que ça peut pas prendre et donc, IEEE ça dit bon bah voilà faut que ça se comporte à peu près comme ça et ça fait des arrondis quand vous faites des divisions, des multiplications avec des floats les pauvres float ils font de leur mieux ils font avec les valeurs qu'ils peuvent représenter ils.

Bruno:
Sont codés au mieux sur 32 bits.

Gabriel:
Voilà ou 16 bits il y en a parfois dans le monde de l'IA ils s'amusent à faire du 4 bits même avec des floats des trucs complètement farfelus. Du coup, ils ne peuvent pas représenter toutes les valeurs. Donc voilà, ils font de leur mieux. Il y a des imprécisions. Et dans le monde de l'IA, on a accepté que pour certaines industries, c'est inacceptable, très clairement, des imprécisions et de la non reproducibilité. Dans le monde de l'IA, on a accepté que c'était, on a dit que c'est acceptable pour la valeur que ça produit. Et donc, du coup, on a accepté qu'il y a plein de choses qui n'étaient pas vraiment reproductibles. Donc, voilà.

Bruno:
Tu nous as dit aussi que les chercheurs, ils vont concevoir leur modèle, faire leur entraînement. Et puis, quand ils ont un résultat qui est satisfaisant, ils donnent leur code à Gabriel. qui va s'en occuper donc du coup toi ton travail c'est quoi ? Dans quelle mesure tu transformes ce code ?

Gabriel:
Alors moi j'ai un travail qui est assez complémentaire de celui des chercheurs en fait les chercheurs ne sont pas des gens qui ont l'habitude de shipper du software ni même des produits, donc si vous vous baladez sur si vous avez l'occasion de vous balader sur GitHub, et que vous cherchez différents projets, c'est pas très compliqué de voir si le projet a été fait par un chercheur ou un ingénieur. Si c'est fait par un chercheur typiquement il va vous dire ah bah si vous voulez essayer mon travail vous allez git clone le repo et ensuite voici la liste des dix instructions à suivre pour installer le truc et le faire fonctionner. Alors vous allez vous dire waouh. Généralement si c'est un ingénieur qui a fait le truc vous allez sur le repo il y aura marqué pour essayer mon repo vous faites pip install cette wheel là enfin ce truc là et hop ça marche voilà donc c'est souvent la plus grosse différence. Les chercheurs se battent souvent avec des dépendances qui sont horribles à installer et quand on se dit horrible c'est vraiment horrible parce que du coup ils vont utiliser des projets qui sont faits par d'autres chercheurs qui eux-mêmes n'ont pas très bien packagé leur truc, donc ça devient insupportable le packaging dans le monde de l'IA c'est un sujet dont on pourra parler mais c'est vraiment, c'est une bête à part voilà, Et donc, du coup, mon travail, voilà, c'est d'essayer de faire en sorte qu'il y ait une sorte de filtre entre ce que font les chercheurs et ce qui est ensuite visible par le grand public. De façon à ce que ça ne soit pas trop dur pour d'autres personnes de récupérer nos projets et de les utiliser dans des produits, dans plein de choses. Donc, par quoi ça passe ? Il y a plusieurs sujets qui sont intéressants. Il y a déjà la démo. Donc, ça, c'est l'un des trucs les plus importants. c'est en fait il y a des gens qui veulent tester notre truc et ils sont pas dev donc ça c'est le plus basique c'est on se dit bon bah il faut qu'ils aillent sur qtai.org et qu'ils aillent sur ce bouton et là ils peuvent essayer notre texte to speech par exemple donc il faut que ça fonctionne, ça demande zéro installation juste tu vas sur le site web et ça marche donc ça c'est une facette de mon travail, et c'est assez important les démos si ça fonctionne tu prouves quand même au monde que ton truc il fonctionne donc c'est pas rien. Ensuite t'as le côté Sortir le code et les poids Bon les poids c'est assez simple Tu vas mettre tes poids sur Hugging Face Et puis t'en parles plus. Pour le code c'est généralement le truc Qui demande un peu plus de travail Où en gros ce qui va se passer c'est que Le chercheur va me donner sa code base d'entraînement Souvent Parfois ils ont eu la bonté d'aller un peu Parfois, on va dire élaguer le code pour me laisser que ce qu'eux ils utilisent pour de vrai, parce qu'en fait il faut comprendre que les cause base d'entraînement ça va être des trucs énormes avec plein de variations possibles d'architecture et souvent ils en utilisent qu'une seule à la fin qui marche bien, bon parfois ils ont la gentillesse de me laisser juste la version qui marche bien mais bon sinon et s'ils me laissent pas ça bon c'est mon travail d'aller élaguer ça tu as des techniques pour faire ça c'est assez rigolo tu peux par exemple, une technique si tu as une code base de plusieurs millions de code tu veux savoir exactement quelles sont les lignes de code exécutées tu peux utiliser des outils de coverage, et alors c'est très bête parce que les gens ils utilisent ça souvent pour des unit tests mais du coup le chercheur il te dit bah voilà si tu veux faire tourner mon modèle tu tapes telle commande et toi tu te dis ouais bon bah sur les 5 millions de code t'en as peut-être genre que, 1000 qui seront utilisées c'est quoi les 1000 utilisées parce que tu vas pas te farcir d'aller trouver toutes les branches une par une pour savoir bah tu utilises un outil de coverage et ça va te dire exactement par où est passé, le truc et tu récupères que ces lignes de code là donc ça ça peut être une technique t'as d'autres techniques qui peuvent être utilisées, mais voilà et après une fois que t'as la codebase qui va bien ça va être packager ça sous une forme sympa c'est à dire faire une wheel, donc les wheels c'est ce truc qu'on peut pip installer avec Python. Donc c'est pour que ça fonctionne bien avec le package manager, la shipper sur PyPy, nettoyer la codebase pour que ça soit compréhensible et faire des, instructions d'installation qui sont relativement simples et il y a aussi un travail qui est pas non négligeable c'est d'essayer de sortir toutes les dépendances qui sont un peu farfelues parce que du coup les chercheurs ils ont l'habitude de dépendre de travaux d'autres chercheurs qui sont pas facile à installer et pour des gens puissent récupérer facilement notre travail on n'a pas envie de leur forcer à faire des scripts d'installation de 20 lignes de code pour installer une librairie obscure dont ils ont besoin juste pour notre projet on a envie quitte à écrire plus de lignes de code nous, alors fournir un truc un peu clé en main qui s'installera partout quoi donc voilà nous on essaye de. Policher ça, le mettre dans un beau papier cadeau magnifique avec un joli ruban. Voilà, un truc qui fait envie, tu vois. Un truc que tu te dis, quand tu vas sur le repo, tu te dis, ah ça, j'ai envie de l'installer, ça, ça va être facile. Et pas un truc où tu vois un Redmi qui fait genre 40 lignes pour t'expliquer comment installer le machin, tu vois. Donc voilà. Et après, si la code base est aussi très propre, ça, ça aide énormément. Parce que les gens n'hésitent pas à réimplémenter ton travail dans d'autres langages. Par exemple, il y a un projet qu'on a fait récemment qui s'appelle Pocket ETS. Qui était un TTS qui fonctionne sur CPU, très léger. Et du coup, la codebase était très lisible, avait très peu de dépendance. Il y a énormément de gens qui l'ont réécrit dans plein de langages différents. Donc en C++, en C, en Java, en Swift, qui l'ont mis sur l'iPhone, qui l'ont mis sur des casques de VR, qui l'ont mis dans des modes, dans des jeux vidéo. Et ça, c'est des trucs que tu peux faire que si la codebase est très simple et les gens, ils arrivent à la réécrire pour leur framework, leur langage de programmation. Donc t'as un travail à cet endroit là qui est de rendre la chose la plus simple possible la plus visible possible pour que ça soit très facile pour des humains ou maintenant des LLM de comprendre ce qui se passe et de refaire ça dans d'autres frameworks de langage passionnant.

Bruno:
Est-ce que du coup t'es aussi obligé de travailler dans un contexte plutôt orienté GPU que CPU ?

Gabriel:
Tout à fait, alors en fait ça va être très orienté pour les, en fait dans mon cas ça va être les démos, pour les gens qui sont plus proches de la prod, du coup ça va être la prod, ça va être comment tu fournis un service qui marche avec une IA derrière qui fonctionne et ça malheureusement si tu veux une IA qui arrive à te sortir des mots, des billes, je dirais qui n'est pas lent à la vitesse d'une tortue qui écrirait elle-même et qui serait un peu malade et qui écrirait très lentement si tu as envie d'aller un peu plus vite que ça il va te falloir un GPU malheureusement on n'a pas le choix, et donc énormément de modèles en IA sont quasiment obligés d'avoir un GPU parce que sinon ça serait beaucoup trop lent ça serait trop insupportable et je ne suis même pas sûr que d'un point de vue électricité ça soit même très rentable de le faire fonctionner sur CPU c'est souvent, même beaucoup plus rentable de les faire fonctionner sur GPU d'un point de vue électricité. Et donc du coup ouais t'es obligé d'utiliser un GPU alors utiliser un GPU c'est pas trivial c'est pas un truc qui a été forcément très bien supporté même encore aujourd'hui c'est pas mieux porté c'est pas force class on va dire, je te donne un exemple, Docker c'est un truc qui est utilisé depuis très longtemps par beaucoup de devs, Ça a mis des années avant de supporter de pouvoir accéder au GPU depuis un container. Et je prends un autre exemple, le Windows Subsystem for Linux, qui est un truc qui est pas mal utilisé par des gens qui bossent sous Windows, qui est un peu une machine virtuelle Linux. Eh bien, ils ont mis, pareil, je pense qu'ils ont mis peut-être 7 ou 8 ans avant de donner accès au GPU. Donc, pendant très longtemps, c'était, vous pouvez faire fonctionner tous vos programmes Linux dessus, mais CPU only. Et en fait le GPU c'est vrai que c'est difficile à supporter la stack est pas mature c'est toujours un truc qu'on supporte après, et en fait tu sens le pain des pauvres ingénieurs qui sont obligés de déployer en production quand tu vois les trucs comme Anthropik où ils utilisent des dizaines voire des centaines de milliers de GPU pour servir leur prod et qu'ils consomment des terawatts, et que tu vois que tous les outils qu'ils utilisent, les GPU c'est un peu supporté sur le côté c'est un peu on vous a donné accès au CPU, déjà vous devriez être content le GPU on verra plus tard. Et c'est souvent des choses comme ça Kubernetes par exemple pendant très longtemps ça supportait pas les GPU Docker Swarm non plus, Docker Compose non plus c'est toujours un peu plus dur que la normale il y a une petite barrière à l'entrée qui est toujours un peu rude, et même dans l'écosystème Biton qui est l'écosystème qui supporte le mieux l'IA tous les chercheurs peuvent être là-dedans même là-dedans le GPU c'est quelque chose qui est pas très bien supporté je vais te donner un exemple très concret voilà, En gros, quand tu veux installer un package Python, tu vas faire un pip install. Et le package installer, il est très intelligent. Il va aller regarder sur ton registri, voir ce qui est disponible comme package. Il va interroger ton CPU pour savoir c'est quoi l'architecture. Par exemple, si c'est du ARM ou du AMD64, par exemple. Et il va aller voir le registri, il va lui donner cette information pour que le registri télécharge le bon package qui est pour son architecture de CPU. Afin que s'il y a du binaire compilé dedans ça fonctionne et donc Package Manager est très content et il a fait son travail etc et puis ensuite il y a Gabriel qui arrive et Gabriel il est sur par exemple un GPU AMD il fait pip install de son package et là il s'aperçoit que le package qui a été téléchargé il supporte que les GPU Nvidia, et là Gabriel il se dit bon ben moi il me faut le package AMD du coup, et là c'est problématique parce que ben en fait le Package Manager il supporte pas ça donc je suis obligé de lui dire non je veux cet autre package qui est spécialement pour l'umd et alors il y a tout un tas de magouilles qui sont mis en place pour justement permettre ce genre de système où tu vas dépendre d'un truc comme par exemple les gens ils vont dire bah on dépend du package torch qui est le package le plus utilisé pour faire du deep learning. Et Torch, il a tout un tas de magouilles pour dire, les gens, ils ont le droit de dépendre de ce package. Nous, il n'y a qu'une seule wheel qui ne supporte qu'un seul GPU, mais on va se débrouiller pour donner des channels alternatives que vous pourrez spécifier pour pouvoir aller chercher différents types de wheels pour les différents GPU que vous avez. Et c'est une magouille sans fin vraiment c'est une souffrance permanente, et il y a eu des projets qui se sont lancés mais qui n'ont jamais vraiment abouti pour que les package managers soient conscients des différents types d'accélérateurs qu'il y a sur ta machine télécharger les bons paquets automatiquement mais ça n'a jamais vraiment abouti de nos jours, je te donne l'exemple le plus basique tu te mets sur, tu te mets t'es sur Linux tu n'as pas de GPU par exemple tu fais pip install PyTorch PyTorch va allègrement te télécharger 8Go de dépendance avec tous les outils Nvidia dedans, Alors que tu n'as pas de GPU NVIDIA, tu es juste sur du CPU. Et il va te dire, ben non, parce que par défaut, moi sur du Linux, je télécharge tout pour NVIDIA, il n'y a pas de problème. Et ouais, c'est fatigant, tu vois. Et tu vas te mettre sur... Tu vas prendre du Linux, tu vas avoir un GPU AMD, tu fais pip install PyTorch. Pareil, toute la stack NVIDIA qui fait 8Go. Et en fait, par défaut, il y a très peu de choses qui marchent, on va dire. Même quand tu es sur du NVIDIA, en fonction de ton driver, il va te dire tu vas faire pip install PyTorch c'est PyTorch il va te dire ah oui je me suis installé avec Kuda 13.1 et toi tu vas dire bah ouais mais Kuda 13.1 mon driver il supporte pas, ah bah le package manager il va te dire écoute c'est pas mon problème tu te débrouilles, et du coup tu vas aller chercher la version de PyTorch qui fonctionne avec ton driver très spécifique etc et le package manager il se dédouane de tout en fait, c'est très très dur de bosser avec ça mais.

Bruno:
Du coup est-ce qu'entre le côté non déterministe de ton métier toutes.

Gabriel:
Ces galères.

Bruno:
Sur le GPU et tout ce que ça engendre notamment autour du package manager est-ce que.

Gabriel:
Du coup.

Bruno:
Tu t'aimerais parfois d'être plutôt un dev web.

Gabriel:
En mode React.

Bruno:
Plus accessible ou il y a quand même des avantages dans ton.

Gabriel:
Domaine, en fait moi j'ai aussi fait dev web pendant l'époque j'étais back-end aussi, ça a d'autres problèmes t'as d'autres problèmes t'es dev web t'as d'autres problèmes je vais pas dire un travail est plus dur que l'autre, Par exemple, moi je te donne l'exemple le plus basique, tes dev web, comment tu testes que ton microservice fonctionne ? C'est infernal, genre si tu as une dizaine de services, tu vas jamais les faire tourner sur ton laptop. Si tu dépends d'une base de données et que tu te dis qu'il y a une situation qui marche pas mais c'est qu'à partir du moment où tu as une dizaine de milliers d'utilisateurs, tu vas pas faire un unit test avec une base de données remplie de 10 000 utilisateurs et tester de faire des trucs dessus. Il y a des problèmes dans tous les domaines.

Bruno:
On a tous effectivement chacun nos contraintes.

Gabriel:
Voilà, on a tous nos problèmes. C'est vrai qu'il y a des situations où c'est vrai que quand ça arrive, on est content. Typiquement, je parlais de Pocket ETS qui était notre ETS qui fonctionnait sur TPU. Quand il y a le chercheur qui m'a dit « Écoute, moi je t'ai sorti un modèle et en plus il est assez petit. Et du coup, il devrait fonctionner sur CPU. » Je me suis dit « Mais mec, tu ne te rends pas compte ? Tu m'as refait ma semaine, voire mon mois là en fait. tu vas m'économiser mais tellement de jours de travail, tu te rends pas compte et la simplicité d'utilisation et je pense que c'est un des énormes succès c'est pour ça qu'il y a eu un énorme succès aussi dans ce truc là c'est que en fait c'était mille fois plus simple d'installation et d'utilisation que, les modèles où t'es obligé d'avoir un GPU pour faire tourner, les gens ils ont pu mettre ça sur des casques de VR ils pouvaient faire tourner ça en même temps que leur jeu vidéo tu vois, et l'installation était hyper simple parce que en fait les CPU sont super bien supportés de nos jours, vraiment tu compiles un binaire, tu le chippes, tu le compiles pour les différentes architectures que tu veux, ARM, AMD, 64 et puis c'est fini, tu chippes ça et ça marche quasiment partout sur tous les Linux quoi. Très très bien supporté aujourd'hui donc ça a eu beaucoup de succès grâce à ça et moi ça m'a énormément simplifié mon boulot et c'est vrai que bon malheureusement il y a très peu de modèles qui fonctionnent qui sont assez petits pour marcher sur CPU mais c'est vrai que quand ça arrive, t'es content j'imagine.

Bruno:
Pour terminer tu nous as parlé de Qtai de.

Gabriel:
Votre mission.

Bruno:
De comment dire pas de vulgarisation mais.

Gabriel:
De démocratisation.

Bruno:
De l'IA c'est quoi un peu les gros chantiers sur lesquels vous travaillez en ce moment c'est quoi.

Gabriel:
L'avenir de.

Bruno:
L'IA et des LLM.

Gabriel:
C'est une très bonne question, on peut traiter ça différemment, déjà la première question sur quoi on travaille, alors on a fait beaucoup d'audio jusqu'à présent maintenant on commence à plus se diriger vers les world models, qui est un sujet passionnant, qui est très complexe mais qui est passionnant.

Bruno:
Donc ça les world models c'est notamment le projet de Yann Lequin, qu'on voit partout.

Gabriel:
Tout à fait, exactement. C'est un peu le flagship. Yann Lequin, c'est notre chevalier qui est à la tête de l'armée et qui est là en mode, moi je vais y aller et suivez-moi derrière. Mais nous aussi, on compte sortir notre épingle du jeu et sortir des trucs cools.

Bruno:
Qu'est-ce qui change entre un réseau de neurones traditionnel ou un LLM traditionnel, et de tout ce que tu nous as expliqué tout à l'heure versus un world model ?

Gabriel:
C'est une bonne question. En fait, les world models sont des réseaux de neurones. En fait, ça va être différent d'un LLM classique dans le sens où le world model, son travail va être un petit peu différent. Son travail va être, tu lui donnes une situation, tu lui donnes un état du monde, pour faire simple, de manière très abstraite, tu lui donnes un état du monde et lui, son boulot, déjà, ça va être de... De faire une représentation interne de ce monde. Donc ça peut être une simulation. Le cas le plus classique c'est les vidéos. En gros tu vas lui donner une vidéo et tu vas lui dire. Essaye de savoir c'est quoi la prochaine image. Et donc il va avoir une représentation interne du monde et après tu vas lui donner des actions. Pour le guider donc par exemple tu vas lui dire ça fait quoi si tu tournes la caméra à droite par exemple et donc le world model il va avoir sa petite représentation interne et il va se dire ok qu'est-ce qu'il se passe si là le point de vue on le change et on le met plus vers la droite, et du coup il va te donner c'est quoi sa nouvelle représentation du monde à ce moment là du coup le cas d'usage les plus classique qu'on voit tous les jours du world model ça va être pour prédire la prochaine image avec un jeu vidéo, et du coup c'est assez rigolo parce que ça peut te permettre de faire, accroche toi, des jeux vidéo qui sont entièrement générés par IA ce qui donne des choses très rigolotes donc du coup t'es avec ta manette de Xbox et t'as le, tu vois une image comme si tu jouais un jeu vidéo et tu peux jouer un jeu vidéo mais c'est pas le vrai jeu vidéo qui tourne derrière c'est un modèle qui essaye de prédire c'est quoi la prochaine image tu vois.

Bruno:
J'avais vu ça il y a déjà je pense c'était il y a bien deux ans quelqu'un qui avait généré Doom.

Gabriel:
Avec des LLM.

Bruno:
Et donc c'était la frame d'après qui était déterminée et du coup tu avais un jeu potentiellement infini parce que tu pouvais jouer.

Gabriel:
À la deuxième Eternam exactement et il y a beaucoup de projets que vous pouvez tester en ligne je crois qu'il y a, Dream de Google enfin bref il y a pas mal de projets comme ça et du coup effectivement ça te donne l'impression d'un jeu vidéo infini du coup parce que tu peux aller aussi loin que tu veux l'IA elle va essayer de deviner ok c'est quoi la suite elle va essayer de trouver un truc, et voilà donc du coup nous on s'entraîne principalement là dessus on a un partenariat avec General Intuition du coup. Là dessus et on essaye de voilà on a des données et on essaye du coup de bosser sur les jeux vidéo parce que c'est ce qui est le on va dire le truc où t'as le plus de données en fait ok, des gens comme Yann Lequin vont avoir tendance à voir ça plus d'un point de vue théorique c'est à dire qu'ils vont dire ok, Bah en fait on a Le world model c'est pas juste La génération de vidéos Yannick un il croise dur comme fer, Pour lui c'est un simulateur C'est un simulateur Donc en fait il va te dire bah ça peut te permettre De faire de la simulation de matériaux Simulation de tout ce que tu veux La météo voilà mais tout et n'importe quoi Et donc ça inclut du coup La génération de vidéos tu vois ça inclut là dedans Mais pour lui y'a pas que ça tu vois, Mais après c'est parce que lui Il a une vision très théorique. Lui quand il fait des travaux C'est souvent des choses qui sont très long terme Des choses où il dit S'il y a un produit qui en sort ça sera que dans 20 ans Des choses comme ça Et du coup c'est pour ça qu'il travaille à un niveau Beaucoup plus fondamental sur les world models, Typiquement Mais oui nous on bosse avec les jeux vidéo On bosse pas mal avec l'audio On bosse avec l'image Donc du coup on fait beaucoup de modèles Qui sont capables de voir En même temps qu'ils font autre chose, Typiquement on avait réussi à incorporer Du coup on avait Moshi qui était notre IA vocal Et on avait réussi à faire en sorte que, Moshi puisse voir Et comprendre ce qu'il y a sur des images Et du coup Tu lui donnes une image à Moshi Et tu peux discuter en temps réel De l'image qu'il a vue Tu lui diras qu'est-ce que tu vois sur cette image etc, Donc voilà, on bosse pas mal sur le multimodal. Donc on essaye de sortir un peu que juste de l'audio. On essaye d'aller un petit peu vers les world models, l'image, différentes choses comme ça.

Bruno:
Passionnant.

Gabriel:
Et après, je vais essayer de répondre à ta deuxième question qui était du coup, c'est quoi la suite dans le monde de l'IA ? Je dirais déjà, c'est des LLM qui sont de plus en plus puissants et s'incorporent partout. On voit de plus en plus des LLM qui font des choses bien plus complexes que ce qu'on imaginait. Notamment, en ce moment, vous pouvez voir plusieurs annonces qui sont liées aux maths, où les IA vont faire des maths à la place des matheux. Et sur des sujets que les humains n'auraient jamais trouvé. Vous allez voir de plus en plus de LLM qui sont poussés à bout pour faire de l'optimisation de software, je pense. Ça, énormément. Nous, on le fait à l'intérieur de Kutai, ça nous arrive. Tu prends un kernel GPU par exemple, ou même un kernel CPU, une fonction CPU, une fonction GPU, que tu veux accélérer à fond les ballons, tu donnes un GPU à CloudCode, tu lui donnes ta code base et tu lui dis allez vas-y, fais-toi plaisir, essaye tout ce que tu veux, rends-moi le truc le plus rapide possible, tu lui donnes un peu la stratégie, tu regardes l'assembleur, tu utilises les outils de perf, etc. Et il va mouliner pendant des heures. Et à la fin, il va te faire gagner 10-20%. Et peut-être 10-20% que toi, t'aurais jamais réussi à récupérer. Et donc voilà. Ça, à mon avis, on va beaucoup voir. Et dans le monde de la recherche. Nous, ce qu'on voit dans notre labo, c'est qu'à partir du moment où on a donné Cloud Code aux chercheurs, il n'y en a plus beaucoup qui regardaient le code. On va être sincère. Il y en avait, ils n'ouvraient plus leurs IDE. Genre Vescode, il n'était même plus ouvert. Et si tu demandes à Cloud Code de faire plein d'expériences, Tu lui donnes plein d'idées que tu veux tester. Et où toi, ça t'aurait demandé, peut-être une heure à implémenter. Claude Code, il va te le faire de manière bâclée. Mais au moins, il te le fera. Et tu vas pouvoir tester des dizaines et des dizaines et des dizaines de variations comme ça. Tu parlais de qui décide de l'architecture. Qui décide de... Est-ce que tu mets une addition avant une multiplication ou je ne sais quoi ? Et bien là, tu vois tous ces trucs qu'on se disait. On va tester, on va voir ce que ça donne. Maintenant, c'est les agents d'IA qui font ça pour nous.

Bruno:
Et qui en testent des milliers à la suite.

Gabriel:
Voilà. et qui font ça à la suite pendant qu'on dort pendant qu'on est réveillé pendant qu'on fait autre chose, et c'est eux qui se farcissent tous les trucs pénibles et nous on leur donne les idées générales et eux ils creusent et donc je pense que ça on va voir énormément, et je pense qu'aussi bon là ça va être le petit côté péjoratif je pense qu'on va voir beaucoup de slop comme on dit. Des des choses où les LLM on va leur dire bah vas-y réécris-moi une librairie par exemple il y a beaucoup de gens qui l'utilisent pour réécrire dans d'autres langages des librairies, Et ça je pense qu'on va voir beaucoup aussi, il va y avoir à mon avis une petite crise de, moi c'est ma prédiction, je fais un peu mon prophète là, je pense qu'on va avoir une crise de la confiance un peu dans l'open source que je vois venir, alors que moi je suis très pro LLM, ça typiquement vraiment moi il y a aucun problème, pour moi chacun est responsable de son code et je m'offiche de savoir comment tu l'as écrit tant qu'il, mais ce que je vois dans l'open source c'est beaucoup de gens qui ouvrent des issues ou des pull requests qui sont générés par des LLM et dont les gens ne vérifient pas la qualité et ça s'apaise pour les pauvres maintainers qui utilisent leur temps libre pour contribuer à la communauté c'est très pesant Linux Trouvard récemment disait, moi ma mailing list pour les problèmes de sécurité de Linux elle est imbuvable je peux plus la regarder. Donc voilà on a des nouveaux challenges dans le monde de l'open source, et ça va être très compliqué je pense qu'il va y avoir même bientôt des librairies entières qui vont être écrites uniquement par IA et donc tu tombes dessus et tu vas te dire est-ce que je peux lui faire confiance ou pas est-ce qu'il y a un humain derrière qui va prendre le blâme si jamais sa librairie fonctionne pas du tout, est-ce que c'est maintenu est-ce que le fait qu'il y ait eu 10 000 commits dans la semaine me dit que la librairie va être maintenue ou est-ce que c'est juste quelqu'un qui a fait ça rapidement et en fait il se dit demain ça me gonfle et je ne m'en tiens plus et.

Bruno:
Puis on demandera à une IA de faire un audit du code et donc en fait il y aura un code généré par une IA qui sera audité par une IA et on sera.

Gabriel:
Voilà tout à fait il va y avoir une sorte de crise de confiance je pense et il va y avoir sûrement une sorte de, Des personnes qui vont se détacher, où on va se dire, lui, c'est un développeur auquel on peut avoir confiance. Ça, c'est une organisation qui a la qualité à cœur. Et donc, je pense, il va y avoir des choses comme ça. On va se dire, en fait, la librairie, elle a été faite par telle personne. Et telle personne, on sait qu'elle code bien. Ça va être des choses comme ça, je pense, qui vont sortir. Parce que je vois trop de gens dire, moi, j'ai fait une librairie ce week-end. Elle fait ça, elle fait ça. Et en fait, ça marche pas du tout il va falloir, quand le code devient pas cher à écrire il va falloir, dire est-ce que du coup la personne qui écrit beaucoup de codes c'est la personne qui est motivée et qui a ça à coeur c'est plus forcément le cas.

Bruno:
Top merci beaucoup Gabriel pour.

Gabriel:
Toute cette.

Bruno:
Discussion j'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast.

Gabriel:
La

Bruno:
Première c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes.

Gabriel:
Oui tout à fait mon contenu préféré après j'ai très biaisé c'est les vidéos de CP Picon voilà, mais c'est hyper c'est hyper déjà à regarder mais bon moi je préconise c'est pour les gens qui aiment la perf voilà parce qu'en fait la communauté C++ c'est des gens qui vont te dire là tu vois j'ai changé cette ligne et j'ai gagné deux cycles sur le CPU c'est un truc de dingue, voilà c'est des gens comme ça et, c'est des gens que j'aime bien en fait C'est des gens qui sont un peu obsédés par la perf J'aime beaucoup Du coup c'est très rigolo parce que c'est très luminaire parfois Les talks quand tu les écoutes Mais c'est toujours des choses extrêmement pointues, et vraiment c'est une mine d'or d'informations tous les gens qui présentent à chaque fois sont des gens très très forts et ouais non vraiment j'aime beaucoup mais c'est très orienté c'est pour les gens qui aiment la perf.

Bruno:
Très bien ça plaira très.

Gabriel:
Certainement aux.

Bruno:
Éditrices de DCTD dernière question Gabriel qui est la plus importante est-ce que tu es plutôt espace ou tabulation.

Gabriel:
? alors moi j'ai une opinion très tranchée sur le sujet, et je suis désolé mais il n'y a pas d'autres avis possibles ça va être 4 espaces et c'est tout et ce n'est pas négociable, voilà j'ai été éduqué dans le Python et le Python c'est 4 espaces et je suis désolé mais mon cerveau ne peut plus rire autre chose c'est fini donc que, nous dans nos équipes ce n'est plus votre agent de code qui décide ce n'est pas votre formateur c'est 4 espaces et c'est tout et c'est non négociable.

Bruno:
Très bien c'est noté merci beaucoup Gabriel.

Gabriel:
Et merci.

Bruno:
À tous d'avoir suivi cet épisode j'espère que comme moi parce que je me posais vraiment cette question de comment on fait pour écrire un LLM au sens, je voulais vraiment savoir qu'est-ce qu'on tape, donc là vous avez vous aussi la réponse si vous vous posiez la question, si vous ne vous posiez pas la question Gabriel nous a quand même appris énormément de choses sur l'histoire de tous ces LLM et de comment est-ce qu'on les fabrique, c'était effectivement passionnant. Et si vous avez du coup envie de vous y mettre, n'hésitez pas à essayer comme il ne nous a donné pas de conseils, commencez avec PyTorch et puis après vous vous débrouillez avec les problématiques de GPU et de vos librairies Python, ce n'est plus mon sujet moi je vous remercie comme toujours de partager ce podcast autour de vous. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine et d'ici là, codez bien.