Photo de couverture par Jason Leung sur Unsplash

C'est probablement le premier d'une longue série d'articles « pourquoi j'ai créé » qui explique mon raisonnement pour créer un logiciel et approfondir mes améliorations futures.

Aujourd'hui, je vais me concentrer sur mon projet le plus populaire, TabbyAPI. TabbyAPI est un serveur FastAPI basé sur Python qui permet aux utilisateurs d'interagir avec des modèles de langage étendus (ou LLM) à l'aide de la bibliothèque ExllamaV2 et adhère à la spécification API OpenAI.

Si vous n'êtes pas sûr de la signification de l'un de ces mots, vous n'êtes pas dans l'espace de l'IA. Mais ça va ! Cet article est destiné à expliquer mes expériences sans vous jeter tout l'évier de la cuisine des termes de l'IA.

Le début

Permettez-moi de revenir à l'époque de novembre 2023. L'IA était en plein essor, les entreprises publiaient des modèles à gauche et à droite, et le train à la mode semblait n'avoir aucune fin. Il semble que je parle d’une période qui se situe dans l’Antiquité, mais à l’époque, chaque jour ressemblait à un mois entier d’innovation.

Face à l'assaut de ces nouvelles technologies, je me concentrais sur leur fonctionnement avec mon dérisoire 3090ti. Oui, dérisoire est le mot correct à utiliser puisque 24 Go de VRAM dans une carte graphique constituent le niveau d’entrée pour exécuter la plupart des modèles d’IA. À cette époque, l’exécution de versions quantifiées de modèles était la norme. La quantification est analogue à la compression qui permet aux utilisateurs d'exécuter ces modèles massifs sur des GPU grand public.

Le format que j'ai appris à aimer était exl2, un format axé sur la vitesse, l'optimisation et l'obtention du plus grand nombre possible sur une carte graphique. et les jetons étaient générés à la vitesse du son. Alors ce format est génial ! Quel est le problème ?

Le problème concerne l'exécution du modèle. Exl2 fait partie de la bibliothèque ExllamaV2, mais pour exécuter un modèle, un utilisateur a besoin d'un serveur API. La seule option disponible consistait à utiliser Text-Generation-Webui (TGW), un programme qui regroupait tous les chargeurs disponibles dans un webui Gradio. Gradio est un framework d'interface utilisateur « élément de base » commun pour le développement Python et est souvent utilisé pour les applications d'IA. Cette configuration a été bonne pendant un certain temps, jusqu'à ce qu'elle ne le soit plus.

Essentiellement, la principale raison de la création de Tabby était la gêne. J'étais fatigué par la quantité de travail nécessaire pour charger un modèle. Sans parler des frais généraux de Gradio et du grand nombre de dépendances de TGW. Je respecte le développeur, mais même si TGW convient à de nombreuses personnes souhaitant une solution tout-en-un, ce n'était pas bon pour moi.

Le plan…

Photo de Glenn Carstens-Peters sur Unsplash

est simple. Créez un serveur API qui peut s'installer sur mon ordinateur et ne nécessite pas beaucoup de volume pour fonctionner. Cela semble facile, mais puis-je réellement le faire ? Je n'ai pas beaucoup d'expérience en théorie des modèles d'IA, mais j'ai beaucoup d'expérience dans la création de serveurs backend et dans la compréhension de la conception d'API.

Par conséquent, j'avais besoin de quelqu'un pour m'aider, mais qui ? Entrez turboderp, la personne derrière ExllamaV2. Il sait à peu près tout sur le fonctionnement des modèles depuis qu'il a créé la bibliothèque, ce qui constitue un excellent complément à mes connaissances en API. De plus, une autre personne intéressée nommée Splice nous a rejoint en raison de son expérience avec Python. Ensemble, nous avons lancé TabbyAPI tous les trois.

Mais le plan était-il vraiment aussi simple ? Eh bien, en quelque sorte. Même si j'avais les personnes pour le poste, mes connaissances en Python et en serveurs API étaient pratiquement nulles. J'ai fini par utiliser un framework de serveur Web appelé FastAPI qui m'a rendu la vie beaucoup plus facile. Il est également très populaire dans la communauté Python et bien documenté.

Après avoir utilisé FastAPI pendant quelques jours, j'étais accro à l'écriture de code de serveur Web Python. La documentation est très bonne, il existe de nombreux exemples en ligne et les développeurs sont réceptifs aux retours. Dans l’ensemble, la communauté est accueillante et j’aimerais utiliser Python pour le réseautage plus souvent.

Après quelques semaines, j'ai senti que tout était prêt pour un déploiement public et j'ai décidé de tout publier de la meilleure façon que je connaisse. YOLO et transférez tout sur GitHub.

Des problèmes et encore des problèmes

Lorsque vous lancez un projet open source dans le monde, attendez-vous à des problèmes… Beaucoup beaucoup de problèmes. Les gens ont toujours des cas d’utilisation dans lesquels l’utilitaire ne rentre pas. Étant donné que Tabby est un serveur backend, bon nombre de ces cas sont apparus. Pour cet article, je ne mentionnerai que quelques points qui m’ont été difficiles à gérer au début.

Un gros problème était que j'ai sorti Tabby au milieu du cycle de battage médiatique de RAG. RAG signifie « Retrieval Augmented Generation », ou utilisation de documents externes en plus des connaissances du LLM pour obtenir une réponse. Le problème était que ces nouvelles techniques (telles que l'appel de fonction) nécessitent des points de terminaison d'API et des moyens d'accomplir des tâches complètement différents.

En plus de cela, il existe peu ou pas de documentation sur la manière dont ces fonctionnalités fonctionnent réellement sur le backend. À ce jour, je n’ai pas implémenté l’appel d’outil d’OpenAI car je n’ai aucune idée de son fonctionnement. Le manque de documentation est malheureusement courant dans le monde de l'IA et étouffe la capacité des développeurs à implémenter du code dans leurs projets sans collecter beaucoup d'informations au préalable.

Un autre problème qui a duré plusieurs mois était la génération multi-utilisateurs. Il s’avère que la gestion des requêtes distribuées sur un serveur n’est pas un sujet facile à traiter pour un développeur. FastAPI prend en charge ce type de charge de travail, mais Tabby a été écrit avec du code synchrone. Cela signifiait que j'ai dû apprendre la programmation asynchrone en Python (ce qui n'est pas facile, loin de là).

Le pire, c'est que les développeurs d'IA n'aiment pas le python asynchrone alors que les serveurs réseau l'adoptent. Cela signifie que j'ai dû apprendre à communiquer entre des bibliothèques asynchrones et synchrones sous forme de threading. Il s’agit d’une plongée encore plus approfondie dans la compréhension des problèmes de threading de Python et de la raison pour laquelle le modèle asynchrone existe en premier lieu. Je reviendrai sur tout cela dans un autre article de blog, mais j'espère que cela explique la quantité d'apprentissage que j'ai dû faire en l'espace de 2 à 3 mois pour lutter contre ces problèmes.

Finalement, turbo et moi avons travaillé ensemble pour créer un meilleur générateur dans la bibliothèque ExllamaV2 qui a supprimé tous les problèmes multi-utilisateurs et les bugs étranges des bibliothèques de threads. Après 9 mois, on peut dire sans se tromper que Tabby est enfin un programme stable avec lequel exécuter des modèles.

Épuisement professionnel

Photo par Annie Spratt sur Unsplash

Pendant toute ma période de développement de logiciels, je n'ai jamais eu de période d'épuisement professionnel. C'est difficile à croire puisque l'épuisement professionnel est une chose courante dans le monde du logiciel, mais j'ai toujours voulu coder quelque chose au cours des 6 dernières années. Le codage est mon passe-temps préféré et m'aide à échapper au stress de la journée.

Cependant, Tabby et la communauté de l'IA en général ont changé les choses. Au début, je me suis fait beaucoup d’amis et de personnes partageant des intérêts communs dans l’exploration du domaine en plein essor de l’IA. Ma communauté avait l'habitude de participer à des appels vocaux presque tous les jours et se concentrait sur le partage de projets et d'idées sur les nouveautés dans l'espace. Cela a rendu le développement amusant et agréable puisque j'ai pu passer du temps avec des personnes partageant les mêmes idées et partager de nouvelles idées.

Malheureusement, ces appels vocaux ont commencé à toucher moins de monde et à se produire moins souvent. J'étais également très stressé à cause de la fin de ma première année de médecine. Dans le monde en ligne, ce fut une énorme période de solitude pour moi et développer Tabby me semblait être un fardeau en plus de ma vie d'étudiant en médecine. Finalement, ces événements ont abouti à une grande boule de frustration et de fatigue. Pour le résoudre, j'ai décidé de prendre une pause indéfinie avec l'IA.

Pendant mes vacances, j'ai passé du temps loin de Tabby et j'ai passé plus de temps à profiter de mes vacances d'été. En fait, j'ai travaillé sur d'anciens projets d'applications iOS et passé du temps avec ma famille. Aujourd’hui, je me remets au développement de Tabby. Les appels vocaux auxquels je participais ne se produiront probablement pas avant longtemps en raison de la disparition du battage médiatique sur l’IA. C’est une pilule difficile à avaler, mais j’ai trouvé différentes motivations pour poursuivre mon développement.

Leçons que j'ai apprises

Tabby a été le premier projet LLM que j'ai jamais réalisé. D’une manière ou d’une autre, c’est devenu un nom populaire au sein de la communauté et j’ai été plongé dans le grand bain de la gestion. Sachant cela, voici quelques réflexions que j'ai apprises de cette expérience.

Sachez à qui vous souhaitez vous adresser : tout le monde peut utiliser un projet open source. Pour Tabby, je donne la priorité aux fonctionnalités qui bénéficieront à la facilité d'utilisation du projet, à mes amis et à moi-même. En gardant cette philosophie sous contrôle, je peux gérer mon emploi du temps et je saurai sur quelles fonctionnalités travailler.

Comprenez vos limites : le burnout n’est pas amusant. Ne faites pas ce que j’ai fait et ne vous dévalorisez pas parce qu’un utilisateur a un problème pour la énième fois. Si des sentiments de frustration, de colère ou d’ennui apparaissent, faites une pause. Ça fait du bien de se détendre de temps en temps.

Ne vous mettez pas en quatre pour tout le monde : une idée peut paraître bonne lorsqu'elle est présentée pour la première fois, mais les gens ne comprennent pas que le développeur doit maintenir cette fonctionnalité par la suite. Si c’est pénible et peu utilisé, la fonctionnalité ne sera pas maintenue et deviendra une dette technologique. N'oubliez pas que les inconnus sur Internet ont toujours des idées. C'est à vous ou à votre équipe de décider dans lesquels consacrer votre intelligence.

Créez quelque chose que vous aimez et appréciez : les développeurs perdent souvent le plaisir d'un projet car la maintenance peut être difficile et prendre beaucoup de temps. Cela est particulièrement vrai si le développeur n'utilise plus activement le projet. Déterminez quelle est votre motivation, et si elle change, ce n'est pas grave.

Je développerai probablement cela dans un autre article car cela peut être son propre sujet, mais je pense que travailler sur Tabby m'a donné plus d'informations sur la façon dont je veux que mes projets fonctionnent. De plus, mes connaissances de la communauté open source ont été élargies.

Ce que l'avenir nous réserve

Je remercie toutes les personnes qui contribuent et donnent des suggestions quotidiennement pour améliorer à la fois TabbyAPI et ExllamaV2. Tout le monde contribue à affiner et à améliorer les programmes pour mieux fonctionner pour un usage général. Je suis une seule personne et aider m'enlève beaucoup de mon assiette.

Dans un avenir prévisible, je vais réduire mon travail sur Tabby. Le projet est toujours en cours et beaucoup s'engagent à l'améliorer, mais ma santé mentale est plus importante et prendre des pauses m'y aidera.

Merci d'avoir lu cette rétrospective. Si vous souhaitez en savoir plus sur moi et ce que je fais, veuillez visiter kingbri.dev.

Site personnel de Brian Dashore