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 はオールインワン ソリューションを求める多くの人にとっては良いものですが、私にとっては良くありませんでした。

計画は…

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 はついにモデルを実行するための安定したプログラムになったと言っても過言ではありません。

燃え尽き症候群

Unsplash の Annie Spratt による写真

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

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

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

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

私が学んだ教訓

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

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

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

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

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

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

将来はどうなるのか

TabbyAPI と ExllamaV2 の両方を改善するために毎日貢献し、提案をしてくれるすべての人々に感謝します。全員がプログラムを改良し、一般的に使用できるように改善するのに協力します。私は一人の人間なので、手伝うのはとても大変なことです。

当面は、タビーの仕事の量を減らすつもりです。プロジェクトはまだ順調に進んでおり、多くの人が改善に取り組んでいますが、私の精神的健康はより重要であり、休憩をとることがそれに役立ちます。

この回顧展を読んでいただきありがとうございます。私と私の仕事についてもっと知りたい場合は、kingbri.dev にアクセスしてください。

ブライアン・ダショアの個人ウェブサイト