Unsplash の Jason Leung によるカバー写真

これは、おそらく多くの「私が作った理由」投稿の最初のものであり、ソフトウェアを作成し、将来の改善についてさらに深く掘り下げた理由を説明しています。

今日は、私の最も人気のあるプロジェクト、TabbyAPI に焦点を当てます。 TabbyAPI は、ユーザーが ExllamaV2 ライブラリを使用して大規模言語モデル (LLM) と対話できるようにする Python ベースの FastAPI サーバーであり、OpenAI API 仕様に準拠しています。

これらの単語の意味がわからない場合は、あなたは AI の世界にいません。でも、大丈夫です！この記事は、AI 用語を丸投げすることなく、私の経験を説明することを目的としています。

始まり

2023 年 11 月の時代に戻りましょう。AI がブームとなり、企業はあちこちでモデルをリリースし、誇大広告は終わりがないかのように見えました。太古の時代のことを言っているようですが、当時は毎日が 1 か月分のイノベーションのように感じられました。

これらの新しいテクノロジーの猛攻撃の中で、私は小型の 3090ti でそれらを実行することに集中していました。はい、グラフィックスカードの 24 GB の VRAM はほとんどの AI モデルを実行するためのエントリーレベルであるため、「わずか」という表現が適切です。現時点では、モデルの量子化バージョンを実行するのが標準でした。量子化は圧縮に似ており、これによりユーザーはこれらの大規模なモデルをコンシューマ GPU で実行できるようになります。

私が大好きになった形式は exl2 でした。これは、速度、最適化、グラフィックスカードにできる限り多くの情報を取り込むことに重点を置いた形式です。そしてトークンは音速で生成されていました。ということで、このフォーマットは素晴らしいですね！何が問題ですか?

問題はモデルの実行です。 Exl2 は ExllamaV2 ライブラリの一部ですが、モデルを実行するには API サーバーが必要です。唯一の選択肢は、Text-Generation-Webui (TGW) を使用することでした。TGW は、すべてのローダーを Gradio Webui にバンドルするプログラムです。 Gradio は、Python 開発用の一般的な「ビルディングブロック」UI フレームワークであり、AI アプリケーションによく使用されます。この設定はしばらくはうまくいきましたが、そうではなくなりました。

本質的に、Tabby を作成した主な理由は煩わしさでした。 1つのモデルをロードするのに必要な作業量に疲れました。 Gradio からのオーバーヘッドや TGW からの膨大な量の依存関係は言うまでもありません。私は開発者を尊敬しますが、TGW はオールインワンソリューションを求める多くの人にとっては良いものですが、私にとっては良くありませんでした。

計画は…

Why I made TabbyAPI
Unsplash の Glenn Carstens-Peters による写真

はシンプルです。私のコンピューター上に設置でき、実行に大きな負荷を必要としない API サーバーを作成します。簡単そうに思えますが、実際にできるでしょうか？私は AI モデル理論の経験はあまりありませんが、バックエンドサーバーの作成と API 設計の理解には豊富な経験があります。

だから、誰かに助けてもらう必要があったんだけど、誰が？ ExllamaV2 の背後にいる人物、turboderp を入力します。彼はライブラリを作成して以来、モデルの動作の背後にあるすべてのことをほぼ知っており、それが私の API 知識と素晴らしい組み合わせです。さらに、Splice という名前のもう 1 人の興味のある人が、Python の経験から参加しました。私たち 3 人は一緒に TabbyAPI を始めました。

しかし、計画は本当にそんなに単純だったのでしょうか?そうですね。仕事に必要な人材は揃っていましたが、Python と API サーバーに関する私の知識は基本的にゼロでした。最終的に FastAPI と呼ばれる Web サーバーフレームワークを使用することになり、作業が大幅に楽になりました。これは Python コミュニティでも非常に人気があり、十分に文書化されています。

FastAPI を数日間使用した後、私は Python ウェブサーバーコードを書くことに夢中になりました。ドキュメントは非常に充実しており、オンラインには多くの例があり、開発者はフィードバックを歓迎します。全体的に、コミュニティは歓迎されているので、ネットワーキングに Python をもっと頻繁に使用したいと思っています。

数週間後、すべてを公開する準備ができたと感じ、私が知っている最善の方法ですべてをリリースすることにしました。 YOLO、すべてを GitHub にプッシュします。

問題とさらなる問題

オープンソースプロジェクトを世界にリリースするときは、問題が予想されます…たくさんの問題。ユーザーには、ユーティリティが当てはまらないユースケースが常にあります。 Tabby はバックエンドサーバーであるため、そのようなケースが多く発生しました。この投稿では、最初は対処するのが難しかったいくつかのことのみについて説明します。

大きな問題は、RAG の誇大広告サイクルの途中で Tabby をリリースしたことです。 RAG は「Retrieval Augmented Generation」の略で、応答を取得するときに LLM の知識に加えて外部ドキュメントを使用します。問題は、これらの新しい手法 (関数呼び出しなど) では、タスクを実行するためにまったく異なる API エンドポイントと方法が必要であるということでした。

その上、これらの機能がバックエンドで実際にどのように動作するかについてのドキュメントはほとんどありません。 OpenAI のツール呼び出しがどのように機能するかわからないため、今日に至るまで私は実装していません。悲しいことに、AI の世界ではドキュメントの欠如が一般的であり、事前に十分な情報を収集しない限り、開発者がプロジェクトにコードを実装する能力が阻害されます。

数か月間続いたもう 1 つの問題は、マルチユーザーの生成でした。サーバー上で分散クエリを処理することは、開発者にとって簡単なテーマではないことがわかりました。 FastAPI はこのタイプのワークロードのサポートを提供しますが、Tabby は同期コードで作成されました。これは、Python で非同期プログラミングを学ばなければならないことを意味しました (これは、長期的には簡単ではありません)。

最悪の点は、ネットワークサーバーが非同期 Python を採用している一方で、AI 開発者が非同期 Python を好まないことです。これが意味するのは、スレッド形式で非同期ライブラリと同期ライブラリの間で通信する方法を学ばなければならなかったということです。これは、Python のスレッドの問題と、そもそも非同期モデルが存在する理由をさらに深く理解するものです。このすべてについては別のブログ投稿で説明しますが、これらの問題と闘いながら 2 ～ 3 か月の間に私がしなければならなかった学習量を説明できれば幸いです。

最終的に、turbo と私は協力して ExllamaV2 ライブラリでより良いジェネレーターを作成しました。これにより、スレッドライブラリからマルチユーザーの問題や奇妙なバグがすべて取り除かれました。 9 か月を経て、Tabby はついにモデルを実行するための安定したプログラムになったと言っても過言ではありません。

燃え尽き症候群

Why I made TabbyAPI
Unsplash の Annie Spratt による写真

ソフトウェア開発に携わってきた間、燃え尽き症候群になったことは一度もありません。ソフトウェアの世界ではバーンアウトはよくあることなので、信じられないかもしれませんが、私は過去 6 年間、常に何かコードを書きたいと思っていました。コーディングは私のお気に入りの娯楽で、一日のストレスから逃れるのに役立ちます。

しかし、Tabby と AI コミュニティ全体が状況を変えました。当初、私は多くの友人や、急成長する AI 分野の探索という共通の関心を持つ人々を作りました。私のコミュニティはほぼ毎日音声通話を行っており、その分野の最新情報についてのプロジェクトやアイデアを共有することに重点を置いていました。同じ考えを持つ人々と交流し、新しいアイデアを共有できるので、開発は楽しくて楽しいものになりました。

残念なことに、これらの音声通話は参加者が少なくなり、頻度も減りました。私も医学部の 1 年目を終えたので、大きなストレスにさらされていました。オンラインの世界では、これは私にとって大きな孤独の期間であり、タビーの開発は私の医学生生活に加えて負担のように感じられました。最終的に、これらの出来事はフラストレーションと疲労の大きな塊となって頂点に達しました。それを解決するために、私は AI から無期限にお休みすることにしました。

休暇中、私はタビーから離れて時間を過ごし、夏休みを満喫しました。実際、私はいくつかの古い iOS アプリプロジェクトに取り組み、家族と時間を過ごしました。現在、私は再び Tabby の開発に戻っています。私が以前参加していた音声通話は、AI の誇大宣伝が消え去ったため、おそらくしばらくは行われないでしょう。飲み込むのは難しい薬ですが、開発を続ける別の動機を見つけました。

私が学んだ教訓

Tabby は私がこれまでに作った最初の LLM プロジェクトでした。どういうわけかコミュニティ内で有名になり、私は経営陣の末端に放り込まれました。それを承知の上で、この経験から私が学んだ考えをいくつか紹介します。

誰に対応したいのかを把握する: オープンソースプロジェクトは誰でも使用できます。 Tabby の場合、私はプロジェクトの使いやすさ、友人、そして私自身に利益をもたらす機能を優先します。この哲学を常に意識することで、スケジュールを管理できるようになり、どの機能に取り組むべきかがわかります。

自分の限界を理解する: 燃え尽き症候群は楽しいものではありません。ユーザーが何度も問題を抱えているからといって、私と同じように自分を追い詰めないでください。フラストレーション、怒り、退屈などの感情が現れたら、休憩を取ってください。たまにはリラックスするのも良いですね

誰にとっても後ろ向きに曲がらないでください。アイデアは最初に提示されたときは良く見えても、開発者がその後この機能を維持する必要があることを人々は理解していません。面倒であまり使用されない場合、その機能は維持されず、技術的負債となります。インターネット上のランダムな見知らぬ人は常にアイデアを持っていることを忘れないでください。どの分野に知恵を注ぐかを決めるのは、あなたまたはあなたのチーム次第です。

好きなもの、楽しいものを作成する: 開発者は、メンテナンスが面倒で時間がかかるため、プロジェクトの楽しみを失うことがよくあります。これは、開発者がプロジェクトを積極的に使用しなくなった場合に特に当てはまります。自分のモチベーションが何なのかを考えて、それが変わっても大丈夫です。

これは独立したトピックになる可能性があるため、おそらく別の記事で詳しく説明しますが、Tabby に取り組むことで、自分のプロジェクトをどのように機能させたいかについてより多くの洞察が得られたと感じています。さらに、オープンソースコミュニティに関する知識も広がりました。