L IA open source par Hugging Face Gen AI Nantes 1

Transcript

C'est parti ? C'est parti, ok, très bien. Bonsoir, ravi d'être ici. Ça faisait quelques années que je n'étais pas venu à Nantes. Et comme je disais en rigolant, à chaque fois que je viens, il pleut. Donc vraiment à chaque fois, j'ai vraiment pas de chance. Mais bon, c'est rien. Ça valait la peine, il y a une belle salle. Je m'appelle Julien, je travaille pour Hugging Face depuis un peu plus de deux ans et demi en tant que chief évangéliste, ce qui veut dire essentiellement que je travaille principalement avec les clients commerciaux, moins sur la partie open source. Je passe mon temps à expliquer à de grandes entreprises ou des scale-ups, de temps en temps le secteur public, pas forcément en France, mais on va rester positif ce soir. J'essaie de leur expliquer ce qui se passe autour de l'IA, de l'IA générative, des LLM, et Dieu sait que ça change à peu près tous les jours. Je leur explique pourquoi l'open source est, selon nous et selon nos clients, la meilleure façon d'avancer sur ces sujets. J'espère vous donner des exemples. Je travaille aussi beaucoup avec nos partenaires stratégiques, des partenaires cloud, des partenaires hardware. Je travaille donc pas mal avec eux sur les aspects produits, clients, et je voyage beaucoup. Aujourd'hui, j'étais en France, et c'était une très bonne occasion de venir vous voir. Je vais approcher le micro. Je vais parler plus fort. Non, ça va, je voulais pas vous casser les oreilles, mais ok, je vais monter le son. J'ai essayé de ne pas mettre trop de slides parce que je sais qu'on a envie de discuter de code. On va discuter de code, mais on a un public mixte ce soir, ce qui est très bien. Il y a certainement des gens pour qui c'est la première exposition à Hugging Face. D'ailleurs, qui est la première fois qu'on parle de Hugging Face ? Bon, allez-y, ce n'est pas grave. Il y a plein de choses que je ne sais pas. Soyez pas timides. On va commencer par quelques informations générales sur pourquoi on en est là, quel est mon rôle, ce qu'on fait, et quelqu'un m'a demandé tout à l'heure comment on gagne de l'argent. Je peux répondre à ça aussi, c'est important de payer mes notes de frais. Ensuite, on zoomera sur les grandes tendances actuelles, ce qui change en ce moment, en particulier tout ce qui est optimisation des modèles, accélération hardware, etc. Je vous montrerai quelques démos qui sont assez sympas. Tout a commencé par une nuit sans lune en juin 2017 avec la publication de ce papier que tous les data scientists et MLE de la salle ont lu. Il s'appelle "Attention is all you need" et introduit une nouvelle architecture de réseaux de neurones, le transformeur, basé sur un mécanisme appelé mécanisme d'attention. On laissera l'explication du mécanisme d'attention au meetup machine learning, puisque j'ai compris que vous avez de la théorie. Vous pouvez lire ce papier, il n'y a pas de problème. Vous faites comme moi, vous lisez l'intro, la conclusion, les benchmarks, et vous ignorez tous les maths qui sont au milieu. Si le papier a été publié, c'est que les maths sont correctes. Ignorer les maths ne sert à rien pour comprendre en quoi ce truc est révolutionnaire. Bref, ce nouveau mécanisme d'attention a pratiquement mis à la retraite toutes les autres architectures de deep learning. En l'espace de 4 à 5 ans, quand on dit "deep learning" aujourd'hui, on veut dire "transformers". Il reste très peu de cas d'usage de deep learning où les transformers ne se sont pas imposés, en particulier sur tout ce qui est vision artificielle en environnement embarqué, où les CNN sont très optimisés, petits, et fonctionnent bien dans des environnements contraints. Tout ce qui est traitement du langage naturel, très sincèrement, aujourd'hui, on parle de Transformers. Les LSTM, les RNN, sont partis à la casse. Et ils ont été mis à la casse par tous ces modèles dont vous avez sans doute entendu parler, comme BERT, BART, les GPT, Bloom, LLaMA, Mistral, il y en a tous les jours. C'est vraiment ça qui déclenche toute cette histoire. Il y avait du deep learning depuis 2015, et les entreprises commençaient à s'y mettre. Les transformers ont vraiment accéléré tout ça parce que la qualité de ces modèles est vraiment supérieure à tout ce qu'on avait avant. Google utilise depuis longtemps les transformers pour le search. De manière générale, tous les utilisateurs traditionnels de machine learning, les banques, les assurances, les sciences de la vie, enfin tous ceux qui ont de la data, du budget, et des équipes de machine learning, les ont adoptés depuis longtemps. Elon Musk s'en sert pour essayer de garder les Tesla sur la route, ce qui est une bonne chose. Aujourd'hui, c'est quelque chose qui est entré dans les mœurs, avec une adoption de masse sur la première génération de transformers, les modèles BERT, BART, Roberta, et autres. Si vous êtes dans une équipe de data science et machine learning, vous avez probablement ces modèles en production. C'est le nouveau XGBoost, on pourrait dire. Cela continue à avancer vite, et aujourd'hui, on est passé à l'IA générative. On a l'impression que l'IA générative remplace tout le reste, mais ce n'est pas vrai. Les modèles de 100 milliards de paramètres peuvent être surpassés par des BERT sur des tâches simples. Il faut garder la tête froide. L'IA générative est une étape supplémentaire, et les transformers d'origine étaient et sont toujours intéressants. Ces modèles se sont imposés encore plus rapidement. La génération de code, la génération d'images, Table Diffusion, Adobe, Amazon.com, ont lancé des fonctionnalités de résumé d'avis clients, de génération d'annonces pour les vendeurs, basées sur des modèles génératifs, comme ChatGPT. Des entreprises plus classiques, comme Bloomberg et Salesforce, commencent à entraîner des modèles et à les mettre à disposition de leurs clients. Ce qui est incroyable, c'est à quelle vitesse ces modèles ont été adoptés. Tout le monde n'avance pas à la même vitesse, tout le monde n'a pas les mêmes budgets, les mêmes intérêts, les mêmes équipes, mais on me demande souvent si tout ça est du hype, du bullshit. En partie, oui, on pourrait dire ça, mais nous travaillons avec des entreprises traditionnelles, pas des GAFA, pas des géants de la tech, des bonnes vieilles entreprises traditionnelles, avec des bons business, qui déploient ces modèles en production aujourd'hui. C'est réel, ce n'est pas pour vendre du papier. Hugging Face est une start-up créée par des Français en 2016, qui a itéré comme toutes les start-ups. Les premiers Transformers sont sortis fin 2017, début 2018, et tout le monde s'est dit que ces modèles étaient super, mais qu'ils étaient difficiles à utiliser. Les équipes à l'état de l'art chez Google ont des cerveaux énormes, écrivent des papiers de recherche avec plein d'équations, mais ne s'expliquent pas comment les modèles peuvent être utilisés, en particulier par des gens simples comme moi qui veulent faire trois lignes de Python. Le coup de génie des fondateurs de Hugging Face a été de se dire qu'on pouvait les utiliser en trois lignes de Python, et de commencer à créer des librairies pour ça. Aujourd'hui, Hugging Face héberge 570 000 modèles pré-entraînés, tous open source, tous contribués par la communauté. La communauté va de vous et moi. Il y a peut-être des gens dans la salle qui ont déjà poussé des modèles sur Hugging Face. Merci, on va continuer. De développeurs individuels jusqu'à Google, Meta, Microsoft, et tous les autres qui contribuent des modèles, on collectionne les modèles et les jeux de données. On continue à bâtir des librairies open source pour travailler avec tout ça. L'open source est magnifique et reste le cœur de la boîte. Nos clients apprécient l'open source, mais ils ont aussi besoin d'aller en production, ce qui signifie se déployer sur des clouds et une variété de plateformes hardware. On collabore donc avec toutes ces entreprises, et notre dernier tour de table fin août de l'année dernière a permis de faire rentrer ces entreprises au capital. Il n'y a pas beaucoup de start-ups, certainement pas créées par des Français, qui ont cette liste d'actionnaires. C'est assez rigolo, on est assez fiers de ça. Plus que la fierté que ça nous apporte, ça valide aussi le modèle de l'IA open source, d'autant plus que la plupart de ces entreprises font aussi des modèles fermés. Je trouve intéressant qu'elles aient envie de garder un œil sur le monde de l'IA open source. On est très content de les avoir et on est très content quand elles partagent des modèles. Elles devraient en partager plus d'ailleurs. La vision stratosphérique de Hugging Face, que les personnes dans la salle qui connaissent déjà un peu Hugging Face connaissent, est centrée sur les modèles et les datasets. Aujourd'hui, il y a 570 000 modèles et 120 000 datasets disponibles, téléchargeables en quelques secondes sur notre site, le Hub, huggingface.co. On a aussi une version pour les entreprises, le Hub Enterprise, qui apporte davantage de sécurité et de contrôle. Ces modèles sont combinés avec nos librairies open source, la plus connue s'appelle Transformers. On a aussi une librairie qui s'appelle Diffusers pour les modèles de type Stable Diffusion, génération d'image, de vidéo, etc. On a une librairie qui s'appelle Accelerate pour le training distribué. On en a toute une collection, que vous trouverez sur Github. En parallèle, on a créé nos propres services cloud, comme Spaces, que vous connaissez forcément même si vous ne l'avez pas remarqué. Si vous avez joué avec des démos de modèles sur des pages web, vous avez joué avec Spaces. Ce sont des petites applications Python poussées dans un repo Git chez nous, ce qui déclenche automatiquement la construction d'un container et le lancement de l'application. Cela permet d'avoir ces applications ML, IA, disponibles pour tout le monde, y compris de manière privée. Il y a un niveau d'usage gratuit et un niveau d'usage payant. On a aussi un service appelé Inference Endpoints, qui vous permet de déployer n'importe quel modèle en un clic sur AWS ou Azure. Google devrait arriver, on a signé le partenariat avec GCP il y a quelques semaines. C'est la façon la plus simple de déployer ces modèles. Bien sûr, tout ça est open source, donc vous pouvez faire ce que vous voulez. Vous pouvez télécharger le modèle, faire un container et le déployer sur votre cluster Kubernetes, et ça marche aussi. C'est le cœur du truc. En parallèle, on crée aussi des modèles. Dans les 570 000 modèles, il y en a très peu qui sont créés par nous, sauf quand on identifie un besoin. On a fait Bloom, un gros LLM concurrent de GPT-3, StarCoder, et maintenant StarCoder 2, un modèle de génération de code assez bon, IDFX, un modèle d'analyse de contenu visuel, etc. On continuera sûrement à le faire, mais on ne se définit pas comme modèle builder. On n'est pas un concurrent d'Anthropic, OpenAI, etc. Non, non. Mistral, c'est 5 modèles sur Hugging Face. On aimerait qu'il y en ait plus, mais ils sont passés du côté obscur de la force. C'est décevant, je suis un peu triste. On peut les ramener, ce n'est jamais perdu. On a aussi des applications, comme Hugging Chat, qui est notre chat complètement open source. Vous pouvez le tester sur hugging.chat, basé sur les meilleurs modèles open source du moment. Vous pouvez même choisir le modèle avec lequel vous voulez chatter. La user interface et le back end sont open source. Des clients m'ont même repris tous les morceaux et l'ont redéployé chez eux pour avoir un vrai bon chatbot complètement privé, sans envoyer les comptes rendus de réunion confidentiels aux gars de la côte ouest. On a des partenariats cloud pour intégrer nos outils dans des plateformes cloud, afin que si vous êtes client AWS, Microsoft, etc., vous puissiez entraîner et déployer les modèles sans réinventer la roue. On a aussi des partenariats hardware, car notre objectif est que vous ayez la meilleure performance possible, quelle que soit la plateforme que vous utilisez, aussi bien en termes d'entraînement que d'inférence. On travaille avec tous ces partenaires, et spécifiquement pour le hardware, on a une famille de librairies qui s'appelle Optimum, déclinée par partenaire, qui va vous permettre d'accélérer sur telle ou telle plateforme. Je vous montrerai ce qu'on fait sur CPU dans quelques minutes. On fait aussi du conseil et du service pour les entreprises. On a un programme qui s'appelle l'EAP. Si vous voulez travailler directement avec nous sur des projets d'IA open source et arriver vite et bien en production, on peut vous aider et on le fait au quotidien. Pour ceux qui n'ont jamais vu Hugging Face, voici un peu le Hello World. C'est un exemple de classification de texte qui illustre ce que j'ai raconté. On utilise les vrais Transformers, on prend un objet qui s'appelle le pipeline, qui est l'outil de prédiction. On applique ce pipeline à une tâche de Zero Shot Classification, c'est-à-dire la classification de texte avec des labels arbitrairement choisis. On met le nom du modèle sur le Hub, ici c'est Facebook, BART, Large, entraîné sur le dataset MNLI. Je prends un bout de texte sur Wikipédia et je l'applique à quelques labels arbitraires. Je passe les labels et la phrase au pipeline, et instantanément, on me dit que ce texte parle plutôt de finances, un peu de science, et pas trop du reste. Si vous avez besoin de prédire avec des modèles Hugging Face, c'est tout ce que vous avez besoin de savoir, et c'est vite vu. C'est pas plus compliqué que ça. Pour être très concret, comment je suis arrivé sur ce modèle ? Voilà le Hub, 570 000 modèles. Je vais recharger la page. 297, paf 323, ça n'arrête jamais. Ici, vous avez les modèles et les datasets. Si vous cherchez un modèle de résumé, vous voyez toutes les tâches : computer vision, NLP, audio, reinforcement learning, multimodal, etc. J'ai choisi summarization, je veux un modèle PyTorch, qui parle anglais, avec une licence sympa comme Apache ou MIT pour l'utiliser commercialement. Apache et MIT sont mieux, il y en a plus. En cinq secondes, j'ai une short list de modèles. Je tombe sur mon Facebook BART Large, qui a été entraîné sur CNN Daily Mail. On peut le tester directement avec le widget qui permet de tester le modèle. On a la description du modèle, un exemple d'utilisation, un article de recherche, un lien sur le dataset utilisé, et la liste des spaces basés sur ce modèle. On peut ouvrir un space ici. Celui-là est cassé, c'est un truc de la communauté. On va essayer un deuxième. Celui-là a l'air pas mal. On peut le tester, taper du texte, etc. Jouer avec les spaces est un bon moyen de trouver des idées d'application. Vous pouvez perdre votre journée. On a les métriques si le modèle a été formellement évalué sur différents datasets. Voilà comment tout le monde fait pour chercher des modèles et commencer à expérimenter. Vous pouvez télécharger le modèle ici, soit en utilisant Transformers, soit en clonant le repo directement pour travailler avec le modèle localement. Si vous êtes vraiment nouveau et voulez commencer à apprendre, voici les URLs. Vous aurez les slides, donc pas d'inquiétude. Si on prend un modèle plus compliqué, comme Stable Diffusion, c'est la même chose. On travaille avec la librairie Diffusers, on crée un pipeline, on charge un modèle de Stability AI, on le prompte, on sauve l'image, terminé. Vous n'avez pas besoin de comprendre Stable Diffusion ou PyTorch. C'est pas plus compliqué que ça. Vous exécutez ça dans n'importe quel environnement chez vous. La simplicité nous tient à cœur. L'open source est vraiment le côté état de l'art, le troisième pilier. On veut garder ces trois aspects : l'open source, les meilleurs modèles disponibles, et la simplicité. C'est la combinaison des trois qui ferme, selon nous, la puissance de notre offre. Ces modèles open source ont plein d'avantages. Ils sont accessibles, n'importe qui peut les télécharger et tester en quelques secondes. Ils sont bien documentés, vous savez ce que fait le modèle. Si vous chargez un Stable Diffusion, un BERT, ou un LLaMA, c'est exactement ça que vous chargez. Si vous n'êtes pas convaincu, vous pouvez lire le code de la librairie et vérifier que le modèle est bien ce qu'il prétend être. L'architecture est connue, les poids du modèle sont connus. Dans certains cas, on essaie de donner l'exemple en fournissant l'accès aux données d'entraînement. Vous avez aussi le papier de recherche. Ce n'est pas une black box, ce n'est pas une API. Vous savez avec quoi vous travaillez. Par conséquent, vous pouvez les déployer où vous voulez, chez vous, sans appels externes à des API tierces. Vos données resteront toujours sous votre contrôle administratif. Si vous réentraînez ou alignez le modèle, il devient votre modèle, que vous déployez chez vous, et personne d'autre ne le voit. Vous restez complètement privé, ce qui est essentiel. On a 570 000 modèles, ce qui vous laisse le choix. Vous pouvez changer quand vous voulez. Vous n'êtes pas soumis à des mises à jour de modèle à 2h du matin heure française qui vont casser tous vos prompts et vous garantir une mauvaise journée le lendemain. La flexibilité de l'open source vous donne le choix. Si vous voulez des services cloud managés, ils sont disponibles. Si vous voulez faire des containers, des VM, c'est possible. Vous avez le choix des armes. Vous pouvez trouver le sweet spot en termes de coût, que ce soit un très gros modèle qui coûte très cher ou un petit modèle aligné sur une tâche très fine. Vous avez le choix, ce que vous n'avez pas avec des API externes. La qualité du modèle, on le voit tous les jours avec les clients : des petits modèles de bonne qualité entraînés sur des données de bonne qualité vont toujours surperformer des gros modèles généralistes. 99% des clients qui nous contactent ont fait un POC avec, disons, OpenAI, et sont à peu près contents de la User Experience, mais dès qu'ils poussent sur leur domaine métier, ils ont des problèmes et les coûts ne sont pas viables. C'est la combinaison de l'optimisation du coût et de la capacité à concentrer le modèle sur un domaine précis qui est essentielle pour les entreprises. Si vous faites un chatbot bancaire, il doit répondre à des questions spécifiques et pas autre chose. C'est beaucoup plus facile à faire avec un petit modèle qu'on réentraîne plutôt qu'avec un énorme modèle sur lequel on essaie d'écrire des prompts de trois pages pour penser à tous les cas et éviter que le modèle parle de choses déplaisantes. Toutes ces discussions sur les modèles sont bien, mais fondamentalement, on s'en fout. Ce n'est pas très important. Ce que je passe ma vie à expliquer aux clients, c'est qu'on est obsédé par les modèles, et il faudrait être obsédé par les données. Si vous utilisez des modèles qui sont trop gros, vous perdez votre temps et vous brûlez votre budget. C'est comme si vous aviez une voiture V12 pour conduire les gamins à l'école ou aller acheter le pain. Vous pourriez aller à pied ou à vélo avec une petite voiture, ça ferait la même chose et serait beaucoup plus efficace. Je vois encore des clients qui disent : "Ah, on va prendre un modèle de 70 milliards de paramètres parce qu'il paraît que c'est mieux." Il paraît que c'est mieux pour quoi ? Je n'en sais rien. Vous voulez faire quoi ? La question centrale est de savoir quel est le cas d'usage, si vous avez besoin d'une adaptation au domaine, combien de latence et de débit vous avez besoin, etc. Il n'y a pas de "meilleur modèle" universel. Il faut le combattre. Sur des benchmarks, on peut dire que tel modèle est le meilleur, mais dans votre cas d'usage, en PME ou en entreprise, je ne peux pas vous dire si c'est le meilleur. Je peux vous dire que si vous testez ces cinq modèles, il y a des chances que l'un d'eux marche mieux que les cinq suivants, mais je ne peux pas vous dire lequel des cinq va marcher le mieux. Seul vous pouvez le déterminer en testant sur vos données et en faisant votre analyse de coûts et de performance. Les modèles sur étagère sont bien, c'est la solution par défaut, comme McDonald's, c'est bien, c'est bon, mais cinq minutes après, on a faim. Ce n'est pas forcément la bonne chose. La bonne solution, selon nous, est d'avoir des modèles de la bonne taille, la plus petite taille possible qui vous donne la performance métier que vous attendez. C'est celle qui va aussi vous coûter le moins cher en termes d'hébergement, en particulier de coût d'inférence, ce qui signifie que vous obtiendrez un retour sur investissement beaucoup plus vite. Plus vous êtes intelligent et que vous choisissez des modèles de la bonne taille, mieux c'est. Plutôt que de dépenser trop de temps et d'énergie sur les modèles, prenez les meilleurs du moment, les plus petits possibles, et passez du temps à construire des datasets de bonne qualité avec des données que personne d'autre n'a. Si vous construisez des datasets qui existent déjà sur le hub, vous perdez votre temps. Si vous avez des données propriétaires sur les vingt dernières années dans votre industrie, il y a des chances que cela ait une grande valeur. Les modèles d'il y a un an ne sont plus utilisés. Le meilleur modèle il y a un an, c'était l'AMA 2, avec 7 milliards de paramètres. Il y a au moins 3 ou 4 modèles, voire 7 ou 8, qui l'ont dépassé depuis. Si vous avez l'AMA 2 en production, vous êtes loin de l'état de l'art. Par contre, si vous avez des datasets d'il y a dix ans ou si vous en construisez maintenant, ils seront encore utilisés dans dix ans. Cet effort est un investissement à long terme. Les modèles sont jetables. Il faut se mettre ça dans la tête. Les data scientists ont plus de mal à l'accepter, mais les modèles n'ont pas d'importance. Ne tombez pas amoureux des modèles. Les datasets, en revanche, méritent votre amour. Les deux meilleurs jobs dans cette industrie sont Data Engineer et MLOps Engineer. Le rôle du Data Scientist mérite d'être revisité. Si on s'était vus il y a un an, je vous aurais dit que le fine-tuning était la solution. Depuis, une autre technique a émergé : le Retrieval Augmented Generation (RAG). Pour avoir l'air intelligent, il faut dire RAG. Cette technique utilise la requête (le prompt) pour aller chercher du contenu pertinent dans un data store. Les modèles d'embeddings sont importants car ils permettent d'embedder la requête et le contenu, puis de trouver les embeddings du contenu proches de ceux de la requête. Cette technique est plus facile à mettre en œuvre que le fine-tuning, beaucoup moins coûteuse, et elle a une conséquence importante : les connaissances générées viennent majoritairement de votre data store, pas du modèle. Si on est d'accord avec ça, on se dit que si on n'a pas vraiment besoin des connaissances du modèle, pourquoi continuer à utiliser des modèles de 13 milliards ou 70 milliards de paramètres ? La majorité des clients avec lesquels nous travaillons utilisent des modèles de 7 milliards de paramètres et commencent à comprendre cela. Des modèles comme Fi 2, de Microsoft, avec 2,7 milliards de paramètres, sont excellents. Je vais vous montrer Fi 2 en action en deux minutes, ainsi qu'un Tiny LLaMA de 1,1 milliard de paramètres, qui est également pas mal. Tout ce qu'on lui demande, c'est de raconter une histoire dans la langue de choix. En anglais, c'est toujours un peu plus simple, mais fondamentalement, il n'est pas nécessaire d'avoir des modèles entraînés pendant des siècles sur des recettes de cuisine et des poésies. Si vraiment c'est votre truc, les recettes de cuisine et les poésies sont dans votre RAG. Les histoires de contexte de 100 000 tokens, 500 000 tokens, 1 million de tokens, qui dit mieux ? Les influenceurs LinkedIn, vous voyez de qui je parle. C'est d'une stupidité sans nom. Germinal, par exemple, a 143 000 mots. 100 000 tokens, ce n'est pas 100 000 mots, c'est plutôt 70 000 à 80 000 mots, soit la moitié de Germinal. L'Étranger de Camus a 43 000 mots. Donc, passer un roman de 200 à 300 pages et poser une question, c'est ce qu'on appelle travailler avec des contextes de 100 000 tokens. Quel est le cas d'usage ? Je l'attends toujours. Même si parfois on a des documents qui ne sont pas dans le RAG et qu'on veut un résumé de Germinal, il est probablement sur Wikipédia. Cela n'a aucun sens, et aucun de nos clients ne le fait. Les influenceurs mettent des chiffres impressionnants mais ne pensent pas toujours à ce qu'ils écrivent, et ils ne mentionnent jamais la latence ni le coût de la requête. L'étape suivante est de customiser les modèles. Généralement, les clients commencent par le RAG, et certains s'arrêtent là, car cela leur suffit. D'autres se disent qu'ils veulent que le modèle comprenne mieux leurs politiques, leurs noms de produits, etc. Ils veulent l'entraîner davantage. Pendant longtemps, j'aurais dit fine-tuning, fine-tuning, fine-tuning, et je vous aurais parlé de coûts de 20 000 à 50 000 dollars pour fine-tuner un modèle de 7 ou 13 milliards de paramètres. Maintenant, je vous dirai 20 à 50 dollars. Le coût a considérablement baissé grâce à des techniques comme LoRa, Q LoRa, qui font partie des techniques de Parameter Efficient Fine Tuning (PEFT). On ne fine-tune qu'un millième du modèle, ce qui approche les performances d'un fine-tuning complet, mais à un coût de 20 à 50 dollars, sur des petits GPU disponibles partout. Il y a aussi une technique populaire en ce moment, le model merging, où on fait une moyenne arithmétique des poids de différents modèles. C'est amusant, mais je ne le conseillerais pas à un client aujourd'hui. L'avantage est que le coût de compute est zéro, donc il n'y a plus de coût de fine-tuning, mais c'est encore un peu expérimental. Je crois en cette technique, mais il faudra des outils plus solides. 2023 a été l'année des PoCs, et 2024 sera l'année de la production. Beaucoup de PoCs meurent avant de passer en production, parfois pour de bonnes raisons, mais souvent pour de mauvaises. La première mauvaise raison est le coût. On se dit que OpenAI est peu cher, à 0,000 par token, mais avec des prompts de 8000 tokens et plusieurs interactions, cela peut rapidement coûter 50 à 100 dollars par jour, soit 50 000 dollars par mois. Il faut se concentrer sur le coût-performance, pas juste sur la performance. Il n'a pas de sens d'avoir un chatbot qui génère 10 000 tokens à la vitesse de la lumière, car personne ne peut lire à cette vitesse. Il faut que cela aille assez vite, mais pas trop vite, car cela devient trop cher. Pour chaque projet, il faut déterminer la latence acceptable, le budget latence, le débit attendu, et le ROI. Mon préféré, et puis après, on va enchaîner sur les démos, est de s'arrêter avec l'obsession des GPU Nvidia. Il y a des concurrents, comme AMD, qui sortent des GPU comme le MI 300, qui commence à être disponible chez des fournisseurs cloud aux États-Unis et qui arrivera sur tous nos clouds préférés. Nous travaillons avec AMD, et cela marche parfaitement bien. Les GPU AMD sont compétitifs en performance et en prix, et ils sont excellents pour des modèles de 7 milliards de paramètres et moins. Le A10G, correspondant aux instances G5 sur AWS, est un très bon choix pour des modèles de 7 milliards et moins. Il est disponible en quantité, pas cher, et facile à scaler. L'inférence sur CPU n'est pas une hérésie. J'ai des clients qui font de l'inférence à grande échelle sur CPU. Sur des modèles anciens comme BERT, cela a déjà très bien fonctionné. Maintenant, on commence à avoir des LLM qui tournent bien sur des CPU Intel et AMD. Les démos sur les Macs M2 et M3 montrent que c'est une tendance importante. Tourner localement a de nombreux avantages : pas d'infrastructure centralisée, pas de cloud, la privacy est totale, et il n'y a plus de latence réseau. Vous pouvez faire de la génération de code dans l'avion, sans le WiFi de la SNCF, qui est une escroquerie. Pour les démos, je vais me concentrer sur le coût-performance, car c'est un point douloureux pour tout le monde. Il y a plusieurs façons d'attaquer ce problème, mais je vais zoomer sur l'accélération hardware et la quantisation. Torch 2, sorti récemment, a une fonction Torch Compile qui doit vous donner au moins 20 à 30% d'accélération, gratuitement, sur toutes les plateformes, CPU et GPU. C'est un gain simple et immédiat. AMD, qui arrive, a des GPU qui fonctionnent sans aucune modification avec les 590 000 modèles de Hugging Face. Le MI 300, concurrent du H100 de Nvidia, a même plus de RAM. Nous travaillons aussi sur les Radeon pour les PC. Intel, avec sa librairie Optimum Intel, accélère les modèles sur toutes les plateformes Intel, des serveurs aux PC et aux mobiles. Les outils comme Neural Compressor et OpenVINO permettent de faire de la quantisation facilement. Par exemple, quantifier un modèle de 16 bits à 4 bits le rend quatre fois plus petit et plus rapide, sans dégrader la qualité. Je vais vous montrer deux démos. La première est un modèle Phi 2 de Microsoft, quantifié à 4 bits, qui tourne sur un laptop à 1200 dollars avec un CPU Intel. La vitesse de génération est correcte, et la qualité de la réponse est très bonne. La deuxième démo est un déploiement cloud sur l'accélérateur Inferentia 2 d'AWS. Nous avons un modèle Zephyr, un modèle de Mistral réentraîné, que nous déployons sur une instance Inferentia 2. Le code est simple, et cela fonctionne bien. Nous travaillons bien avec AWS, et nous espérons que Azure et Google suivront pour avoir le même niveau d'intégration. On peut aussi faire du streaming avec SageMaker. On peut envoyer la requête à notre endpoint SageMaker, et puis streamer la réponse. Il y a un peu de code, un peu de plomberie pour faire ça proprement avec un itérateur, lire ce qui est disponible bout par bout, etc. C'est un bout de code que j'ai volé dans un blog AWS, je vous mettrai le lien dans les slides. Donc, maintenant, je vais juste reconfigurer mon endpoint en disant : "Maintenant, tu ne m'envoies pas tout le pavé d'un coup, maintenant, je voudrais que tu stream." La désérialisation n'est plus juste un gros bout de JSON en un coup, ça va être une désérialisation de stream. Je suis obligé de changer ça, et puis de lui dire : "Maintenant, stream true." Je vais réinvoquer mon endpoint avec la même question, et là, je vais streamer. Il faut que je descende un peu, sinon on ne va pas le voir, ça va assez vite. Voilà, on va le refaire, il faudrait que ça aille plus lentement. Il n'y a plus rien à lire, il faut que je refasse la requête. Voilà, allez, va pas trop vite, il stream, vous l'avez vu. Voilà, donc tout ça, vous pouvez l'implémenter. Implémenter votre application, votre chatbot, ce que vous voulez, en ayant une maîtrise complète de la chaîne. Ce n'est pas un truc très compliqué. Les modèles sont là, vous pouvez commencer à les utiliser directement. L'infra est là. Les services managés avec lesquels on s'intègre rendent les choses assez simples. Il n'y a pas de conteneur, pas besoin de se cogner des heures de setup de PyTorch, etc. Tout ça, on l'a fait. On pense qu'on le fait plutôt bien, qu'on optimise plutôt bien. Donc, vous pouvez en profiter. L'étape d'après, c'est de mettre une petite couche d'appli là-dessus. Ce n'est pas dur, et de commencer à tester. Bâtir vos propres solutions, ce n'est pas un effort surhumain. Entraîner le modèle, etc. On parle pas de milliers de lignes de code, et là, on n'est pas loin d'avoir un truc qui est déjà pas mal. Il faudrait faire une petite page web, un truc sympa, mais ça c'est complètement hors de mes compétences, mais vous trouverez quelqu'un pour faire ça, et vous aurez une appli sur votre infra complètement privée, scalable, et qui ne vous coûte pas cher. Donc, pour résumer, les modèles Hugging Face, quand je dis les modèles Hugging Face, je parle vraiment des modèles hébergés par Hugging Face, les 570 mille et quelques, ils viennent certainement pas tous de nous, ils viennent de la communauté, donc merci à la communauté de nous faire confiance. Ces modèles sont vraiment les standards aujourd'hui. C'est ce que tout le monde utilise. Ne vous laissez pas embobiner par le baratin du "meilleur modèle" ; ça n'existe pas dans l'absolu. Même si on disait que le meilleur modèle est celui qui est en haut du leaderboard pour une taille donnée, il sera remplacé dans quelques semaines. Il faut avoir l'état d'esprit et l'outillage OPS pour être capable de tester rapidement les nouveaux modèles. Il y a un nouveau modèle en haut du leaderboard, on le déploie, on l'évalue, il est bien, il est vraiment mieux, il est un peu mieux, on garde celui qu'on a. Peut-être que deux mois après, il y en a un qui est vraiment, vraiment mieux, et là, vous avez envie de changer. Il ne faut pas que ce soit un drame, il faut que ce soit facile, financièrement, techniquement, etc. L'outillage, l'agilité de l'outillage est important. Il ne faut pas que tout devienne un projet de six semaines. Il n'y a pas de modèle qui domine tous les autres. Chaque use case doit être regardé avec des yeux neufs. Je pense qu'il pourrait y avoir dans la salle des gens qui ont des cas d'usage similaires, de résumé de texte ou de chatbot, etc. Comme ce qu'on a vu tout à l'heure qui a l'air bien. Mais peut-être que vous partiriez de la même shortlist de 4 ou 5 modèles, mais peut-être que vous ne déploieriez pas exactement de la même façon, peut-être pas la même taille, peut-être qu'il y en a un qui ferait du RAG et l'autre qui ferait autre chose. Les solutions universelles, c'est l'option par défaut quand on n'arrive pas à se mettre d'accord, mais il y a mieux à faire. Chez nos clients, là où ils ont vraiment des gros succès, c'est en prenant le plus petit modèle qui fait le job en termes d'expérience utilisateur et en le combinant avec des données de bonne qualité, soit avec du RAG, soit avec du fine-tuning, et parfois les deux. C'est là qu'on atteint des modèles de bonne qualité métier et à un coût-performance qui vous permet de les laisser en production sans les débrancher au bout de quinze jours. Comme on l'a vu, mon focus du jour, intéressez-vous vite à l'accélération des modèles. Que ce soit sur le hardware, en disant quel GPU on prend, quel truc on prend, est-ce qu'on regarde les TPU sur Google, est-ce qu'on regarde Inferentia sur AWS, etc. Est-ce qu'on quantise, qu'est-ce qu'on fait ? Compile, il y a plein d'options. Je vous renvoie à mes deep dive parce que franchement, ça c'est des discussions qui pourraient durer des heures. Mais c'est ça qui va résoudre l'équation économique. Il y a la première partie de l'équation économique, c'est être obsédé par les petits modèles. L'autre partie de l'équation économique, c'est maintenant qu'on a un modèle qu'on aime, comment on le shrink au maximum et comment on le fait tourner sur des petites plateformes. Je suis convaincu que l'année 2024 sera l'année du laptop. Si on se revoit dans neuf mois, on aura plein de solutions qui tourneront bien en local. Un GitHub Copilot, aucune raison qu'il ne tourne pas en local aujourd'hui. La seule raison, à mon avis, pour finir sur une note un peu de mauvais esprit, c'est qu'ils n'ont pas encore trouvé un moyen de vous faire payer 20 dollars par mois localement. Le jour où ils résoudront ça, vous l'aurez localement, peut-être qu'ils vous feront payer 30 parce qu'ils vous diront que c'est encore mieux, c'est safe maintenant. Dans tous les cas, le futur est grand ouvert, et le futur c'est l'open source. Comptez sur nous pour continuer à le défendre. Merci beaucoup de m'avoir invité.