Foto da capa de Jason Leung no Unsplash

Este é provavelmente o primeiro de muitos posts “por que fiz” que explica meu raciocínio para criar um software e me aprofundar em melhorias futuras.

Hoje, vou me concentrar em meu projeto mais popular, TabbyAPI. TabbyAPI é um servidor FastAPI baseado em python que permite aos usuários interagir com Large Language Models (ou LLMs) usando a biblioteca ExllamaV2 e segue a especificação da API OpenAI.

Se você não tem certeza do que alguma dessas palavras significa, você não está no espaço da IA. Mas tudo bem! Este artigo tem como objetivo explicar minhas experiências sem jogar em você toda a pia da cozinha de termos de IA.

O começo

Deixe-me voltar à época de novembro de 2023. A IA estava crescendo, as empresas lançavam modelos a torto e a direito e o trem do hype parecia não ter fim. Parece que estou falando de um período antigo, mas naquela época cada dia parecia um mês inteiro de inovação.

No ataque dessas novas tecnologias, eu estava focado em operá-las com meu insignificante 3090ti. Sim, insignificante é a palavra correta a ser usada, já que 24 GB de VRAM em uma placa gráfica é o nível básico para executar a maioria dos modelos de IA. Naquela época, executar versões quantizadas de modelos era a norma. A quantização é análoga à compactação, que permite aos usuários executar esses modelos massivos em GPUs de consumo.

O formato que aprendi a adorar foi o exl2, um formato que se concentrava na velocidade, na otimização e na obtenção do máximo possível em uma placa gráfica. e os tokens estavam sendo gerados na velocidade do som. Então esse formato é ótimo! Qual é o problema?

O problema é executar o modelo. Exl2 faz parte da biblioteca ExllamaV2, mas para executar um modelo, o usuário precisa de um servidor API. A única opção disponível era usar text-generation-webui (TGW), um programa que agrupava todos os carregadores existentes em um webui Gradio. Gradio é uma estrutura de UI de “bloco de construção” comum para desenvolvimento em Python e é frequentemente usada para aplicativos de IA. Essa configuração funcionou por um tempo, até que deixou de ser.

Essencialmente, o principal motivo para a criação do Tabby foi o aborrecimento. Fiquei cansado com a quantidade de trabalho envolvido para carregar um modelo. Sem mencionar a sobrecarga do Gradio e a grande quantidade de dependências do TGW. Eu respeito o desenvolvedor, mas embora o TGW seja bom para muitas pessoas que desejam uma solução completa, não foi bom para mim.

O plano…

Foto de Glenn Carstens-Peters no Unsplash

é simples. Crie um servidor API que possa ficar no meu computador e não exija muito trabalho para ser executado. Parece fácil, mas eu poderia realmente fazer isso? Não tenho muita experiência na teoria de modelos de IA, mas tenho muita experiência na criação de servidores back-end e no entendimento do design de APIs.

Portanto, eu precisava de alguém para ajudar, mas quem? Digite turboderp, a pessoa por trás do ExllamaV2. Ele sabe praticamente tudo por trás de como os modelos funcionam desde que criou a biblioteca, o que é uma ótima combinação com meu conhecimento de API. Além disso, outro interessado chamado Splice ingressou devido à sua experiência com Python. Juntos, nós três iniciamos o TabbyAPI.

Mas o plano era realmente tão simples? Bem, mais ou menos. Embora eu tivesse pessoas para o trabalho, meu conhecimento em Python e servidores API era basicamente zero. Acabei usando uma estrutura de servidor web chamada FastAPI que tornou minha vida muito mais fácil. Também é muito popular na comunidade python e está bem documentado.

Depois de usar FastAPI por alguns dias, fiquei viciado em escrever código de servidor web python. A documentação é muito boa, há muitos exemplos online e os desenvolvedores são receptivos a comentários. No geral, a comunidade é acolhedora e eu adoraria usar python para networking com mais frequência.

Depois de algumas semanas, senti que tudo estava pronto para uma implantação pública e decidi lançar tudo da melhor maneira que conheço. YOLO e envie tudo para o GitHub.

Problemas e mais problemas

Ao lançar um projeto de código aberto para o mundo, espere problemas… Muitos muitos problemas. As pessoas sempre têm casos de uso nos quais o utilitário não se enquadra. Como Tabby é um servidor backend, muitos desses casos surgiram. Para este post, mencionarei apenas algumas coisas que foram difíceis de lidar no início.

Um grande problema foi que lancei Tabby no meio do ciclo de hype do RAG. RAG significa “Geração Aumentada de Recuperação”, ou seja, utilização de documentos externos além do conhecimento do LLM na obtenção de uma resposta. O problema é que essas novas técnicas (como chamada de função) precisam de endpoints de API e formas de realizar tarefas completamente diferentes.

Além disso, há pouca ou nenhuma documentação sobre como esses recursos realmente funcionam no back-end. Até hoje não implementei a chamada de ferramenta do OpenAI porque não tenho ideia de como funciona. A falta de documentação é infelizmente comum no mundo da IA ​​e sufoca a capacidade dos desenvolvedores de implementar código em seus projetos sem muita coleta prévia de informações.

Outro problema que durou vários meses foi a geração multiusuário. Acontece que lidar com consultas distribuídas em um servidor não é um tópico fácil para um desenvolvedor trabalhar. FastAPI fornece suporte para esse tipo de carga de trabalho, mas Tabby foi escrito com código síncrono. Isso significou que eu tive que aprender programação assíncrona em Python (o que não é nada fácil).

A pior parte é que os desenvolvedores de IA não gostam de python assíncrono, enquanto os servidores de rede o adotam. O que isso significa é que tive que aprender como me comunicar entre bibliotecas assíncronas e síncronas na forma de threading. Este é um mergulho ainda mais profundo na compreensão dos problemas de threading do Python e por que o modelo assíncrono existe em primeiro lugar. Abordarei tudo isso em outra postagem do blog, mas espero que isso explique a quantidade de aprendizado que tive que fazer no período de 2 a 3 meses enquanto lutava contra esses problemas.

Eventualmente, turbo e eu trabalhamos juntos para criar um gerador melhor na biblioteca ExllamaV2 que eliminou todos os problemas de multiusuário e bugs estranhos das bibliotecas de threading. Após 9 meses, é seguro dizer que Tabby é finalmente um programa estável para executar modelos.

Esgotamento

Foto de Annie Spratt no Unsplash

Durante todo o meu tempo de desenvolvimento de software, nunca tive um período de esgotamento. É difícil de acreditar, já que o esgotamento é uma coisa comum no mundo do software, mas sempre quis codificar algo nos últimos 6 anos. Programar é meu passatempo favorito e me ajuda a escapar do estresse do dia a dia.

No entanto, Tabby e a comunidade de IA em geral mudaram as coisas. No início, fiz muitos amigos e pessoas que compartilhavam interesses comuns em explorar o campo em expansão da IA. Minha comunidade costumava fazer chamadas de voz quase todos os dias e se concentrava em compartilhar projetos e ideias sobre o que há de novo no espaço. Tornou o desenvolvimento divertido e agradável, já que pude sair com pessoas que pensavam como eu e compartilhar novas ideias.

Infelizmente, essas chamadas de voz começaram a ter menos pessoas e aconteceram com menos frequência. Eu também estava sob muito estresse por terminar meu primeiro ano de faculdade de medicina. No mundo online, este foi um grande período de solidão para mim e desenvolver Tabby parecia um fardo para minha vida de estudante de medicina. Eventualmente, esses eventos culminaram em uma grande bola de frustração e cansaço. Para resolver isso, decidi fazer uma pausa indefinida na IA.

Durante minhas férias, passei um tempo longe de Tabby e passei mais tempo aproveitando minhas férias de verão. Na verdade, trabalhei em alguns projetos de aplicativos iOS mais antigos e passei um tempo com minha família. Hoje em dia, estou voltando a desenvolver o Tabby novamente. Aquelas chamadas de voz das quais eu costumava participar provavelmente não acontecerão por muito tempo devido ao fim do hype da IA. É uma pílula difícil de engolir, mas encontrei diferentes motivações para o desenvolvimento contínuo.

Lições que aprendi

Tabby foi o primeiro projeto de LLM que fiz. De alguma forma, tornou-se um nome popular na comunidade e fui jogado no fundo do poço da gestão. Sabendo disso, aqui estão algumas reflexões que aprendi com essa experiência.

Saiba a quem você deseja atender: qualquer pessoa pode usar um projeto de código aberto. Para Tabby, priorizo ​​​​recursos que beneficiarão a facilidade de uso do projeto, de meus amigos e de mim mesmo. Mantendo essa filosofia sob controle, poderei gerenciar minha agenda e saberei em quais recursos trabalhar.

Entenda seus limites: Burnout não é divertido. Não faça o que eu fiz e fique desanimado porque um usuário tem um problema pela enésima vez. Se os sentimentos de frustração, raiva ou tédio aparecerem, faça uma pausa. É bom relaxar de vez em quando.

Não se incline para todos: uma ideia pode parecer boa quando é apresentada pela primeira vez, mas as pessoas não entendem que o desenvolvedor precisa manter esse recurso depois. Se for um incômodo e não for muito usado, o recurso não será mantido e se tornará uma dívida tecnológica. Lembre-se de que estranhos aleatórios na internet sempre têm ideias. Cabe a você ou sua equipe decidir em quais deles investir recursos intelectuais.

Crie algo que você ame e goste: os desenvolvedores muitas vezes perdem o prazer em um projeto porque a manutenção pode ser problemática e levar muito tempo. Isto é especialmente verdadeiro se o desenvolvedor não usar mais o projeto ativamente. Descubra qual é a sua motivação e, se ela mudar, tudo bem.

Provavelmente irei elaborar sobre isso em outro artigo, já que este pode ser um tópico próprio, mas sinto que trabalhar no Tabby me deu mais insights sobre como quero que meus projetos funcionem. Além disso, meu conhecimento da comunidade de código aberto foi ampliado.

O que o futuro reserva

Agradeço a todas as pessoas que contribuem e dão sugestões diariamente para melhorar o TabbyAPI e o ExllamaV2. Todos ajudam a refinar e melhorar os programas para funcionarem melhor para uso geral. Sou uma pessoa e ajudar exige muito do meu prato.

No futuro próximo, vou reduzir o quanto estou trabalhando no Tabby. O projeto continua forte e muitos estão se comprometendo a melhorá-lo, mas minha saúde mental é mais importante e fazer pausas vai ajudar nisso.

Obrigado por ler esta retrospectiva. Se você quiser saber mais sobre mim e o que faço, visite kingbri.dev.

Site pessoal de Brian Dashore