집 > 기사 > 백엔드 개발 > 내가 TabbyAPI를 만든 이유

내가 TabbyAPI를 만든 이유

PHPz원래의: 2024-07-17 15:03:47841검색

Unsplash의 Jason Leung 표지 사진

이 글은 제가 소프트웨어를 만든 이유와 향후 개선 사항에 대해 더 깊이 설명하는 많은 "내가 만든 이유" 게시물 중 첫 번째 게시물입니다.

오늘은 저의 가장 인기 있는 프로젝트인 TabbyAPI에 대해 집중적으로 살펴보겠습니다. TabbyAPI는 사용자가 ExllamaV2 라이브러리를 사용하여 대형 언어 모델(또는 LLM)과 상호 작용할 수 있게 하고 OpenAI API 사양을 준수할 수 있는 Python 기반 FastAPI 서버입니다.

이 단어들이 무엇을 의미하는지 확실하지 않다면 당신은 AI 공간에 있는 것이 아닙니다. 하지만 괜찮아요! 이 글은 AI 용어 전체를 여러분에게 던지지 않고 제 경험을 설명하기 위한 것입니다.

시작

2023년 11월 당시로 돌아가 보겠습니다. AI가 붐을 일으키고, 기업들이 좌우로 모델을 출시하고, 과대광고 열차는 끝이 없을 것 같았습니다. 마치 고대 시대를 말하는 것 같지만 그 당시에는 하루하루가 한 달 간의 혁신처럼 느껴졌습니다.

이러한 신기술의 맹공격 속에서 저는 보잘것없는 3090ti를 사용하여 이를 실행하는 데 집중했습니다. 예, 그래픽 카드의 24GB VRAM은 대부분의 AI 모델을 실행하기 위한 보급형 수준이므로 '보통'이라는 단어를 사용하는 것이 올바른 단어입니다. 현재로서는 모델의 양자화된 버전을 실행하는 것이 표준이었습니다. 양자화는 사용자가 소비자 GPU에서 이러한 대규모 모델을 실행할 수 있게 해주는 압축과 유사합니다.

제가 좋아하게 된 형식은 속도, 최적화 및 그래픽 카드에 최대한 많은 기능을 탑재하는 데 중점을 둔 형식인 exl2였습니다. 토큰은 소리의 속도로 생성되었습니다. 그래서 이 형식은 훌륭합니다! 무엇이 문제인가요?

문제는 모델을 실행하는 것입니다. Exl2는 ExllamaV2 라이브러리의 일부이지만 모델을 실행하려면 사용자에게 API 서버가 필요합니다. 유일한 옵션은 모든 로더를 Gradio webui에 번들로 묶은 프로그램인 TGW(text- Generation-webui)를 사용하는 것이었습니다. Gradio는 Python 개발을 위한 일반적인 "빌딩 블록" UI 프레임워크이며 AI 애플리케이션에 자주 사용됩니다. 이 설정은 한동안은 괜찮았지만 그렇지 않았습니다.

기본적으로 태비를 만든 가장 큰 이유는 귀찮음이었습니다. 하나의 모델을 로드하는 데 드는 작업량에 지쳤습니다. Gradio의 오버헤드와 TGW의 엄청난 양의 종속성은 말할 것도 없습니다. 개발자님을 존경하지만, 올인원 솔루션을 원하시는 많은 분들께는 TGW가 좋은 반면 저에게는 별로였습니다.

계획은…

Why I made TabbyAPI
Unsplash의 Glenn Carstens-Peters 사진

간단합니다. 내 컴퓨터에 설치할 수 있고 실행하는 데 많은 부하가 필요하지 않은 API 서버를 만듭니다. 쉬운 것 같지만 실제로 할 수 있을까요? AI 모델 이론에 대한 경험은 많지 않지만 백엔드 서버를 만들고 API 디자인을 이해한 경험은 많습니다.

그래서 도와줄 사람이 필요했는데 누구죠? ExllamaV2 뒤에 있는 사람인 Turboderp를 입력하세요. 그는 라이브러리를 만든 이후 모델 작동 방식에 대한 모든 것을 거의 알고 있는데, 이는 내 API 지식과 잘 어울립니다. 게다가 Python에 대한 경험 때문에 Splice라는 또 다른 관심 있는 사람이 합류했습니다. 우리 셋이 함께 TabbyAPI를 시작했습니다.

그런데 계획이 그렇게 간단했을까요? 글쎄요. 일할 사람은 있었지만 Python 및 API 서버에 대한 지식은 기본적으로 0이었습니다. 결국 FastAPI라는 웹 서버 프레임워크를 사용하게 되었고 덕분에 내 삶이 훨씬 쉬워졌습니다. Python 커뮤니티에서도 매우 인기가 높으며 문서화도 잘 되어 있습니다.

며칠 동안 FastAPI를 사용한 후 Python 웹서버 코드 작성에 푹 빠졌습니다. 문서는 매우 훌륭하고 온라인에 많은 예제가 있으며 개발자는 피드백을 잘 받아들입니다. 전반적으로 커뮤니티는 환영적이며 네트워킹을 위해 Python을 더 자주 사용하고 싶습니다.

몇 주 후에 모든 것이 공개 배포될 준비가 되었다고 느꼈고 제가 아는 최선의 방법으로 모든 것을 릴리스하기로 결정했습니다. YOLO를 실행하고 모든 것을 GitHub에 푸시하세요.

이슈 및 추가 이슈

오픈소스 프로젝트를 세상에 공개할 때 이슈를 기대하세요… 이슈가 많습니다. 사람들은 항상 유틸리티가 적합하지 않은 사용 사례를 가지고 있습니다. Tabby는 백엔드 서버이기 때문에 이러한 경우가 많이 나타났습니다. 이번 포스팅에서는 처음에 다루기 어려웠던 몇 가지 사항만 언급하겠습니다.

큰 문제점은 RAG 과대광고 주기 중간에 Tabby를 출시했다는 것입니다. RAG는 "Retrieval Augmented Generation"을 의미합니다. 즉, 응답을 받을 때 LLM의 지식 외에 외부 문서를 사용하는 것입니다. 문제는 이러한 새로운 기술(예: 함수 호출)에는 작업을 수행하기 위해 완전히 다른 API 엔드포인트와 방법이 필요하다는 것입니다.

게다가 이러한 기능이 백엔드에서 실제로 어떻게 작동하는지에 대한 문서가 거의 또는 전혀 없습니다. 현재까지는 OpenAI의 도구 호출이 어떻게 작동하는지 모르기 때문에 구현하지 않았습니다. 안타깝게도 AI 세계에서는 문서화 부족이 흔한 일이며, 이로 인해 개발자가 사전에 많은 정보를 수집하지 않고 프로젝트에서 코드를 구현하는 능력이 저하됩니다.

몇 달 동안 지속된 또 다른 문제는 다중 사용자 생성이었습니다. 서버에서 분산 쿼리를 처리하는 것은 개발자가 작업하기 쉬운 주제가 아닌 것으로 나타났습니다. FastAPI는 이러한 유형의 작업 부하를 지원하지만 Tabby는 동기 코드로 작성되었습니다. 이는 Python으로 비동기 프로그래밍을 배워야 한다는 것을 의미했습니다(장기적으로는 쉽지 않습니다).

가장 나쁜 점은 AI 개발자는 비동기 Python을 좋아하지 않지만 네트워킹 서버에서는 이를 수용한다는 것입니다. 이것이 의미하는 바는 스레딩 형태로 비동기 라이브러리와 동기 라이브러리 사이에서 통신하는 방법을 배워야 했다는 것입니다. 이는 Python의 스레딩 문제와 비동기 모델이 애초에 존재하는 이유를 이해하는 데 대한 더욱 심층적인 내용입니다. 이 모든 내용은 다른 블로그 게시물에서 다루겠지만, 이것이 제가 이러한 문제와 싸우면서 2~3개월 동안 해야 했던 학습의 양을 설명해주기를 바랍니다.

결국 터보와 저는 함께 작업하여 스레딩 라이브러리의 모든 다중 사용자 문제와 이상한 버그를 제거하는 ExllamaV2 라이브러리에서 더 나은 생성기를 만들었습니다. 9개월이 지난 지금, 드디어 Tabby가 모델을 운영할 수 있는 안정적인 프로그램이 되었다고 해도 과언이 아닙니다.

번아웃

Why I made TabbyAPI
Unsplash의 Annie Spratt 사진

저는 소프트웨어를 개발하는 동안 단 한 번도 번아웃 기간을 가져본 적이 없습니다. 소프트웨어 세계에서는 번아웃이 흔한 일이기 때문에 믿기 어렵습니다. 하지만 저는 지난 6년 동안 항상 무언가를 코딩하고 싶었습니다. 코딩은 제가 가장 좋아하는 취미이며 하루의 스트레스를 해소하는 데 도움이 됩니다.

그러나 Tabby와 AI 커뮤니티 전반은 상황을 변화시켰습니다. 처음에는 급성장하고 있는 AI 분야를 탐구하면서 공통 관심사를 공유하는 많은 친구와 사람들을 사귀었습니다. 우리 커뮤니티는 거의 매일 음성 통화에 참여했으며 공간의 새로운 기능에 대한 프로젝트와 아이디어를 공유하는 데 중점을 두었습니다. 같은 생각을 가진 사람들과 어울리고 새로운 아이디어를 공유할 수 있어서 개발이 재미있고 즐거웠습니다.

안타깝게도 음성 통화의 인원이 줄어들기 시작했고 빈도도 줄어들었습니다. 저도 의과대학 1학년을 마치면서 스트레스를 많이 받았어요. 온라인 세계에서 이것은 나에게 엄청난 외로움의 기간이었고 Tabby를 개발하는 것은 내 의대 생활에 더해 부담처럼 느껴졌습니다. 결국 이러한 사건은 좌절감과 피로감이라는 큰 공으로 끝났습니다. 이를 해결하기 위해 AI를 무기한 중단하기로 했습니다.

쉬는 동안 태비와 떨어져 지내며 여름방학을 즐기며 더 많은 시간을 보냈습니다. 실제로 저는 오래된 iOS 앱 프로젝트에 참여했고 가족과 함께 시간을 보냈습니다. 요즘에는 다시 Tabby를 개발하는 중입니다. 내가 참여했던 음성 통화는 아마도 AI 과대 광고의 퇴색으로 인해 오랫동안 일어나지 않을 것입니다. 삼키기 힘든 알약이지만 계속해서 발전할 수 있는 다양한 동기를 찾았습니다.

내가 배운 교훈

Tabby는 제가 만든 첫 번째 LLM 프로젝트였습니다. 어쩌다보니 커뮤니티 내에서 유명세를 타게 되었고, 저는 경영의 깊숙한 수렁에 빠지게 되었습니다. 그런 점을 알고 이번 경험을 통해 제가 배운 몇 가지 생각은 다음과 같습니다.

누구에게 서비스를 제공할지 파악하세요. 누구나 오픈 소스 프로젝트를 사용할 수 있습니다. Tabby의 경우 프로젝트의 사용 편의성, 친구, 나 자신에게 도움이 되는 기능을 우선시합니다. 이 철학을 잘 지키면 일정을 관리할 수 있고, 어떤 기능을 작업해야 할지 알 수 있어요.

자신의 한계를 이해하세요. 번아웃은 재미가 없습니다. 내가 한 일을 하지 말고 사용자에게 여러 번 문제가 발생했기 때문에 스스로를 지치게 하지 마세요. 좌절감, 분노, 지루함 등의 감정이 나타나면 휴식을 취하십시오. 가끔씩 쉬어가는 것도 좋아요.

모든 사람을 위해 뒤로 물러서지 마십시오. 아이디어가 처음 제시되었을 때는 좋아 보일 수 있지만 사람들은 개발자가 나중에 이 기능을 유지해야 한다는 것을 이해하지 못합니다. 고통스럽고 많이 사용되지 않으면 해당 기능은 유지되지 않고 기술 부채가 될 것입니다. 인터넷상의 무작위 낯선 사람들은 항상 아이디어를 가지고 있다는 것을 기억하십시오. 어느 부분에 두뇌 능력을 투입할지 결정하는 것은 귀하 또는 귀하의 팀에 달려 있습니다.

좋아하고 즐기는 것을 만드십시오. 개발자는 유지 관리가 번거롭고 시간이 오래 걸릴 수 있기 때문에 프로젝트에 대한 즐거움을 잃는 경우가 많습니다. 개발자가 더 이상 프로젝트를 적극적으로 사용하지 않는 경우 특히 그렇습니다. 당신의 동기가 무엇인지 파악하고, 그것이 바뀌더라도 괜찮습니다.

자체 주제가 될 수 있으므로 이에 대해 다른 기사에서 자세히 설명하겠지만 Tabby 작업을 통해 내 프로젝트가 어떻게 진행되기를 원하는지에 대해 더 많은 통찰력을 얻을 수 있다고 생각합니다. 게다가 오픈소스 커뮤니티에 대한 지식도 넓어졌습니다.