LLM テクノロジーが主流で採用されるようになり、エコシステムが成熟し始めるにつれて、組織は LLM テクノロジーの使用の限界とコストを認識し始めています。多くの企業は、もともとLLM テクノロジーの適用に熱心でしたが、集中型の取り組みを放棄し、代わりに ChatGPT や Claude などのサービスをワークフローに組み込む分散型の取り組みを奨励する戦略を追求しています。
この現象にはいくつかの理由があります。 LLM の専門知識の欠如、MLOps 要件、特殊な GPU インフラストラクチャへの依存はすべて、大規模な AI イニシアチブを実装する際の障壁となっています。ただし、このうち最も厄介な問題は GPU への依存です。
この記事では、GPU への依存によってもたらされる具体的な問題について説明し、潜在的な解決策を探り、この分野に取り組んでいる先駆的な企業の 1 つによる興味深い例を見ていきます。
GPT-4、Llama 2、Claude など、一般に入手可能な高性能モデルのほとんどは、高度に特殊化された GPU インフラストラクチャに依存しています。市販されている最大のモデルの 1 つである GPT-4 は、8 つの A100 GPU のクラスター上で実行されることで有名です。 Llama 2 の 70B モデルははるかに小型ですが、適切な速度で実行するには少なくとも A40 GPU が必要です。
このレベルの GPU 要件では、これらのモデルをローカルで実行する可能性は実質的になくなります。A100 GPU は、売り手を見つけることができたとしても、25,000 ドル近くかかります。 GPU を入手したら、サーバーをセットアップして保守するための専門的なスキルが必要です。 LLM テクノロジーを実験するためにそのような出費を惜しまない組織はほとんどありません。
この問題を解決するために、いくつかの新興企業やクラウド プロバイダーが広範な PaaS サービスを開発しました。過去の記事やプロジェクトで使用した Replicate などの一部のサービスでは、ユーザーが GPU サーバーをレンタルし、使用したコンピューティング時間に対して料金を支払うことができます。 OpenAI や Anthropic などの他のプロバイダーは、モデルをトークンごとの API として提供し、インフラストラクチャの複雑さをさらに抽象化します。ただし、これらのサービスではデータを外部ネットワークに送信する必要があるため、プライバシーを重視する組織にとっては、これらのサービスの使用は簡単ではありません。さらに、これらのサービスの多くは、GPU の使用量が可用性を上回るため、需要の急増時に不足に悩まされ、本番環境に不可欠なワークロードにとっては信頼性の低いオプションになります。
さらに、GPU 時間は、どのように課金されるかに関係なく、大規模なコンピューティング タスクでは高価です。結局のところ、これらの GPU を所有および運用する企業は、投資に対する収益を必要としています。実験的なユースケースではこれらのコストはほとんど無視できますが、商業的なユースケースでは多くの場合、大規模なコンテキストの埋め込み、微調整、またはマルチショットのサンプルが必要になります。これらのコストは、特に大規模なデータセットを持つ組織や、米国の大企業ほどの資金力がない組織にとっては、導入に対する大きな障壁となります。
前回の記事では、GPU への依存を減らすための 1 つの戦略としてパラメーター圧縮について検討しました。今日の記事では、量子化と呼ばれる別のエキサイティングなテクニックを検討します。
ただし、調査に入る前に、まず量子化について少し学習しておくとよいでしょう。
このセクションでは、量子化の基本について簡単に説明します。ただし、強力な LLM をコンピュータ上でローカルに実行する方法を探しているだけの場合は、このセクションを一旦スキップして、後で戻ってきても問題ありません。今日私たちが使用するテクノロジである LLMWare は、背後にあるC/C++ 実装の核心に触れることなく、量子化モデルを使い始めることができるいくつかの素晴らしいツールを構築しました。
量子化は、精度の低い数値型を使用することで、LLM の実行に必要な計算量とメモリ要件を削減しようとする手法です。 Llama、Falcon、Alpaca などの多くの人気のあるオープンソース モデルは、基礎となるフレームワークとして PyTorch を使用します。デフォルトでは、PyTorch モデルは 32 ビット浮動小数点を使用します。これは、1 つのパラメーターが GPU メモリ内で 32 ビットを占有することを意味します。量子化の目的は、これらのパラメータを 16 ビット浮動小数点、8 ビット整数、さらには 4 ビット整数に置き換えることです。量子化が成功すると、計算速度が大幅に向上し、メモリ使用量が削減されます。つまり、大規模なモデルがローエンドの GPU、組み込みグラフィック チップ、さらには CPU でも実行可能になります。このアイデアはしばらく前から存在していました。技術が成熟するにつれて、PyTorch 自体は 16 ビット浮動小数点とモデル コンパイルのサポートを追加しましたが、PyTorch フレームワークでの初期の設計決定のため、進歩は遅れています。
この時点で、これによってモデルの精度が大幅に低下するのではないか、と疑問に思うのは当然です。簡単に言うと「はい」ですが、それは不注意に行った場合に限ります。すべての最適化には固有のトレードオフが伴いますが、いくつかの特殊なテクニックを使用することで、研究者は高度に量子化されたモデルから信じられないほど安定したパフォーマンスを引き出すことができました。極端な技術的な詳細には立ち入りませんが、現在使用されている最も一般的な戦略の大まかな流れを見てみましょう。さらに詳しく知りたい場合は、HuggingFace のガイドを参照してください。
校正された量子化
量子化プロセス中に、モデルに対してキャリブレーション データセットが実行されます。各パラメータの値が記録され、その範囲はパラメータがどのように量子化されるかを決定するために使用されます。キャリブレーション データセットがモデルが遭遇する入力を代表していると仮定すると、結果として得られるモデルの精度が向上します。
量子化対応
調整された量子化はトレーニング後に行われますが、量子化対応トレーニングはトレーニング中にモデルの最適化を試みます。モデルのトレーニング中に、アクティベーションは「偽の量子化」を経て、量子化プロセスによって発生する可能性のあるエラーをシミュレートします。その後、モデルはエラーに適応できるようになり、潜在的な歪みに特に適応できるより堅牢なモデルが得られます。
PyTorch の量子化と最適化はフレームワーク設計によって長い間ブロックされてきましたが、最近の 2 つのオープンソース テクノロジによってこれらの障壁が打ち破られ、量子化テクノロジが一般の人々にとってはるかにアクセスしやすくなりました。以下で簡単に説明しましょう。
ラマ.cpp
Llama.cpp は、Llama モデルを C/C++ に移植するための Georgi Gerganov によるプロジェクトです。これにより、PyTorch によってもたらされた複雑さが解消され、ネイティブ実装により量子化を直接実装できるようになりました。したがって、結果のモデルは最大 4 ビットの整数量子化で実行でき、パラメータ数の多い Llama モデルを特殊な GPU なしで実行できます。
その後、このプロジェクトはコミュニティによって拡張され、Falcon や Mistral などの人気のあるモデルを含む一連のオープンソース モデルが含まれるようになりました。
GGUF
GGUF は、モデル情報を保存および転送するための Llama.cpp のファイル形式です。量子化モデルはこの形式で保存されるため、エンドユーザーがロードして実行できます。 GGUF は GGML の後継形式であり、迅速な開発を可能にしながら、さらなる拡張性、下位互換性、安定性を提供することで GGML を改善することを目的としています。
ユニバーサル ファイル形式の開発により、オープンソース コミュニティが Llama.cpp を拡張して他のモデルを最適化する扉が開かれ、TheBloke や LLMWare などのイノベーターはここ数カ月間、人気のオープンソース モデルを小型化するために取り組んできました。
今日の例では、LLMWare によって提供されるオープンソース ライブラリと量子化モデルを使用します。LLMWare は、特殊な RAG ワークフローを迅速に構築するための便利なツールを提供します。
LLMWare は、法律および金融業界に特化した生成 AI 企業で、量子化コミュニティに積極的に参加しています。以前にも書いたように、彼らはプライバシーを重視する分野に重点を置いているため、小型化技術の実験や革新を行う自然な候補者となっています。
以前、契約レビューや財務分析などの特殊なタスクのために 10 ~ 30 億のパラメーター モデルから驚異的なパフォーマンスを絞り出す、RAG に最適化された BLING モデルについて書きました。このようなパラメーター数を持つほとんどのオープンソース モデルは、トイ プロブレムにのみ役立つ傾向がありますが、LLMWare は、これらのモデルを、対象を絞ったタスク向けにトレーニングすることで、実稼働環境に対応したパフォーマンスを生み出すことができます。これらの小型モデルは外部 GPU なしで実行できるため、プライバシーとスケーラビリティが向上します。
Dragon は、BLING のより強力なバージョンと考えることができる LLM のコレクションです。 Dragon の本来の目的は、同じ命令微調整テクニックを使用してより高いパラメーターのモデルをトレーニングし、より多くのパフォーマンスを必要とし、ローエンド GPU にアクセスできるオプションをユーザーに提供することでした。
パラメーター数が追加されたことで、より大きなコンテキスト ウィンドウを利用してより複雑な出力を生成できる、より強力なモデルが作成されました。しかし、ユーザーには、GPU が組み込まれたラップトップや GPU が接続されたクラウド コンピューティング コンテナーなど、より特殊なハードウェアが必要でした。ただし、それでも、希少な A40 または A100 GPU へのアクセスを待つ必要がある非常に大きなモデルよりは改善されています。
上記を考慮すると、量子化が LLMWare の一連の AI ツールに大幅な効果をもたらした理由は簡単にわかります。量子化を使用すると、ユーザーは BLING モデルと同じ環境で Dragon 層モデルを実行できるため、汎用コンピューター上でより強力な分析が可能になります。
先月にわたって、LLMWare はいくつかの Dragon モデルの量子化バージョンを公開しました。今日は、法的分析 RAG 問題を使用して Llama 上に構築された LLMWare の Dragon モデルを評価し、同様の BLING モデルと比較します。興味のある人は他のモデルを調べることもできます。この記事の執筆時点では、Mistral ベースのモデルと Yi ベースのモデルが LLMWare から入手可能です。さらに、 LLMWare は、 ctransformers ライブラリとの緊密な統合により、Llama.cpp モデルでの推論の実行を容易にし、gguf モデルを PyTorch ベースのモデルとシームレスに交換できるようにしました。
この実験では M1 チップを搭載した Macbook Air を使用します。これは、この演習では広く入手可能なハードウェアのみを使用することを意味します。
前回の記事では、法律検索に重点を置いた RAG アプリケーションを構築したことを思い出してください。私たちはベクトル検索を使用していくつかの大規模な法律を迅速に検索し、適格オポチュニティゾーンパートナーシップ権益に関する質問に関連するセクションを見つけて、BLING モデルを通じて質問を実行しました。今日の記事では、LLMWare の量子化された Dragon モデルで同じ質問を実行し、BLING モデルよりもパフォーマンスが優れているかどうかを判断します。
モデルの比較に重点を置き、必要な事前知識の量を減らすために、多くの PDF 解析とベクトル検索を手動で実行します。これには、モデルにとって問題を人為的に難しくするという追加の利点があります。LLMWare のデフォルトの埋め込み検索では、ソース マテリアルが約 1000 トークンに分割されますが、解析を手動で処理することで、コンテキストを約 3000 トークンまで増やすことができます。これは、Dragon モデルと BLING モデルの違いを明確に示すのに役立ちます。
ただし、LLMWare に関する前回の記事のセットアップ手順に従えば、LLMWare のツールを活用したい場合は、残りの LLMWare エコシステムと簡単に統合できるはずです。実際、BLING モデルの名前をこの記事の量子化された Dragon モデルに置き換えるだけで、すべてがシームレスに実行されるはずです。
さっそく始めましょう!
まず、必要な依存関係をインポートしましょう。
import sklearn import sklearn.metrics # for cosine similarity from llmware.prompts import Prompt import time import os from openai import OpenAI from PyPDF2 import PdfReader client = OpenAI() # the library now loads the key automatically as an environment variable.
これで PDF をロードできるようになりました。前の例では、いくつかの大きな法律をロードしましたが、今日は、2017 年減税および雇用法の PDF バージョンにのみ焦点を当てます。
reader = PdfReader([path to PDF of tax cuts and jobs act])
これで、各ページの埋め込みを生成できるようになりました。
embeddings = [] for pg in reader.pages: text = pg.extract_text() embeddings.append(client.embeddings.create( input=text, model="text-embedding-ada-002" ).data[0].embedding)
これから尋ねる質問の埋め込みも生成しましょう。
question = 'What is a qualified opportunity zone partnership interest?' q_embed = client.embeddings.create( input=question, model="text-embedding-ada-002" ).data[0].embedding
埋め込みを使用して、ベクトル検索を実行できます。検索スペースが小さいため、これを手動で行うことができます。
cos_sim = [(idx, sklearn.metrics.pairwise.cosine_similarity([e], [q_embed])[0][0]) for idx, e in enumerate(embeddings)]
ここで、最も関連性の高いページを取得できます (結果を確認したい場合は、インデックス 132 またはページ 133 です)。
most_relevant = sorted(cos_sim, key=lambda x: x[1], reverse=True)[0][0]
そしてこれで、最も重要なステップに到達しました。量子化された Llama Dragon モデルを使用して LLMWare Prompter オブジェクトをインスタンス化します。 Prompter クラスは、プロンプト エンジニアリングを処理し、プロンプトが Dragon のトレーニング データの構造と一致していることを確認するため、ここで重要です。プロンプト クラスは、llamacpp バインディングも自動的に処理するため、量子化された Dragon モデルを他のモデルとまったく同じように使用できます。
model_name = "llmware/dragon-llama-7b-gguf" prompter = Prompt().load_model(model_name) response = prompter.prompt_main(question, context='\n\n'.join([reader.pages[132].extract_text()]), prompt_name="default_with_context", temperature=0.3)
少し待つと、関数呼び出しが返されるのが表示されます。次に結果を出力します。
print(response['llm_response'])
そして、次のようなものが表示されるはずです。
• A capital or profits interest acquired by the qualified opportunity fund after December 31, 2017, from the partnership solely in exchange for cash; •As of the time such interest was acquired, the partnership was a qualified opportunity zone business (or, in the case of a new partnership, it was being organized for purposes of being a qualified opportunity zone business); •During substantially all of the qualified opportunity fund's holding period for such interest, the partnership qualified as a qualified opportunity zone business.
これはなかなか良い答えですね!
比較のために、同じ問題に対して BLING モデルがどのように実行されるかを見てみましょう。予想される問題の 1 つは、コンテキスト サイズが大きいため、パラメータが低いモデルを「圧倒」し、有益性の低い答えが得られる可能性があることです。以前の実験では、剪断ラマ 2.7b がこの問題に対して最も優れたパフォーマンスを発揮したものの 1 つであったため、それを BLING モデルの代表として使用することにしました。
model_name_2 = "llmware/bling-sheared-llama-2.7b-0.1" prompter2 = Prompt().load_model(model_name_2) response = prompter2.prompt_main(question, context='\n\n'.join([reader.pages[132].extract_text()]), prompt_name="default_with_context", temperature=0.3)
いくつかの処理を行うと、次のように表示されるはずです。
A qualified opportunity zone partnership interest is a capital or profits interest in a domestic partnership if such interest is acquired by the qualified opportunity fund after December 31, 2017, from the partnership solely in exchange for cash.
応答は依然として良好ですが、Dragon モデルでキャプチャされた詳細の一部が失われています。具体的には、この回答には保有期間要件と新しいビジネスケースが含まれていません。これは、より大きなコンテキストを処理する際の低パラメータのモデルの難しさに関する私たちの予想と一致しています。興味のある読者は、さらに低いパラメーター モデルを使用したり、特定のコンテキストのサイズを増やしたりして、この実験を拡張できます。効果がますます顕著になり、その後、モデルは短く不明瞭な応答を返します。
この実験から、量子化された Dragon モデルは、モデルの精度を著しく損なうことなく、意図されたユースケースにおいて低パラメータのモデルよりも優れたパフォーマンスを発揮できることが明らかになるはずです。
これにより、量子化モデルを使用して実際のユースケースを解決し、その過程でのパフォーマンス特性について学びました。
今日、私たちは LLM 量子化というエキサイティングな分野を調査し、LLMWare のような企業がこれらの開発をどのように活用して自社の特殊な言語モデルを強化しているかを調べました。以前にも主張したように、小型化は AI テクノロジーの普及への最も有望な道の 1 つです。 AI 分野のイノベーターは、専門化、微調整、量子化を組み合わせることで、現実世界の問題を解決するスケーラブルでパフォーマンスの高いモデルを作成できます。
LLMWare の RAG フレームワークはGithubにあり、DRAGON モデルと BLING モデルは LLMWare のHugging Face リポジトリにあります。
ところで、私は言語 AI と小型化を使用して発展途上国の教育に革命を起こそうとするエキサイティングなプロジェクトに取り組んでいます。私たちは世界中の素晴らしい活動家や教育者と協力し、世界的なデジタル格差を埋めるために取り組んでいます。私のプロジェクトについてもっと知りたい場合、または単に LLM 分野のエキサイティングな開発について話したい場合は、 GithubまたはLinkedInでお気軽にご連絡ください。