Ampere A2クラスタでの量子化GGUF大規模言語モデルの実行

コンピューティング・インフラストラクチャの不足が原因で、地域的なAIの格差が拡大しています。最新の大規模言語モデル(LLM)では、効果的にトレーニングするために、多数の専門的で高性能なGPUが必要です。各サーバーが6桁の価格を持ち、グローバル・サプライチェーンが圧迫される可能性があるため、これらの必須リソースには多くのユーザーがアクセスできません。増大するAIの分裂に対するソリューションを探る中で、GPUのボトルネックの有望な代替手段であるAmpere A2プロセッサが登場しました。可能性に配慮して、Ampere A2クラスタ上に完全に構築されたLLM実装を設計しました。結果は顕著でした。最先端のGPUアレイの原動力とは一致しませんが、これらのシステムは、1時間当たり1ペニーで実用的な検索拡張生成(RAG)アプリケーションに電力を供給できます。

アーキテクチャ

このArmベースのアーキテクチャは、従来のAIインフラストラクチャ・コストのほんの一部で実行され、優れた価値でLLM実装を提供します。このアーキテクチャは、AIを使い始めるための予算に優しいアプローチに使用します。

OCIパブリック・ロード・バランサは前面に位置し、受信トラフィックをコンピュート・インスタンスのプールに分散します。Ampere A2ノードのインスタンス・プールがあります。各ノードは、Ubuntuを実行している2コアのArmベースのコンピュート・インスタンスです。ノードはOCIインスタンス・プールで管理されるため、トラフィックの増加に伴って水平方向に簡単にスケーリングできます。インターネット・ゲートウェイを使用すると、必要に応じてロード・バランサとバックエンド・インスタンスの両方へのパブリック・アクセスが可能になります。

各Ampere A2コンピュート・インスタンスは、llama.cppを使用してローカルに提供されるUbuntu 22.04 (Arm)、定量化されたGPT生成統合フォーマット(GGUF) LLM (TinyLlamaやPhi-2など)、NGINXを介して提供される単純なHTML/JSランディング・ページ、およびUIからのプロンプトを処理し、モデル出力をページにストリーミングするllama-cpp-pythonにワイヤリングされたPythonベースのバックエンドを実行します。

プール内の各コンピュートノードは、軽量で完全に自己完結するように設計されています。起動時に、LLMを最初から処理するために必要なものをすべてインストールして実行するcloud-initスクリプトを使用してブートストラップします。ノードは、次のように構成されます。

  • インストールの依存関係: build-essential、cmake、git、NGINX、python3-pipなどの依存関係が自動的にインストールされます。llama-cpp-pythonは、完全なARM64互換性を確保するためにソースからコンパイルされます。
  • ビルド: ノードは、最新バージョンのllama.cppをGitHubからプルし、最適化されたCPU推論のためにOpenBLASを使用してビルドしますが、GPUまたは推論APIに対する外部ランタイム依存性はありません。
  • モデルのダウンロード: 定量化されたGGUFモデル(TinyLlamaなど)は、Hugging Faceから直接フェッチされ、modelsディレクトリに配置されます。
  • ランディング・ページの提供: 最小限のHTML/JavaScript UIは、ポート80のNGINXを介して提供されます。UIを使用すると、ユーザーはブラウザからプロンプトを送信し、LLM応答を直接表示できます。
  • Pythonを介した推論の処理: 小さいPythonバックエンドは、llama-cpp-pythonを使用してローカル・モデルと対話します。ユーザーが質問を送信したときに、ランディング・ページがPOSTリクエストを送信する/generateエンドポイントを公開します。
  • 起動時に開始: すべてがsystemdサービスにラップされるため、インスタンスの再起動または障害時に推論が自動的に再起動します。手動による操作は必要ありません。

次の図は、このリファレンス・アーキテクチャを示しています。



Gen-ai-ampere-gguf-llm-arch.zip

アーキテクチャには次のコンポーネントがあります。

  • リージョン

    OCIリージョンとは、可用性ドメインをホストする1つ以上のデータ・センターを含む、ローカライズされた地理的領域のことです。リージョンは他のリージョンから独立しており、長距離の場合は複数の国または大陸にまたがる領域を分離できます。

  • 可用性ドメイン

    可用性ドメインは、リージョン内の独立したスタンドアロン・データ・センターです。各可用性ドメイン内の物理リソースは、他の可用性ドメイン内のリソースから分離されているため、フォルト・トレランスが提供されます。可用性ドメインどうしは、電力や冷却、内部可用性ドメイン・ネットワークなどのインフラを共有しません。そのため、ある可用性ドメインでの障害が、リージョン内の他の可用性ドメインに影響することはありません。

  • フォルト・ドメイン

    フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各可用性ドメインには、独立した電源とハードウェアを備えた3つのフォルト・ドメインがあります。複数のフォルト・ドメインにリソースを分散すると、アプリケーションは、フォルト・ドメイン内の物理サーバー障害、システム・メンテナンスおよび電源障害を許容できます。

  • 仮想クラウド・ネットワーク(VCN)およびサブネット

    VCNは、OCIリージョンで設定した、カスタマイズ可能なソフトウェア定義ネットワークです。従来のデータ・センター・ネットワークと同様に、VCNsではネットワーク環境を制御できます。VCNには、VCNの作成後に変更できる重複しない複数のクラスレス・ドメイン間ルーティング(CIDR)ブロックを複数含むことができます。VCNをサブネットにセグメント化して、そのスコープをリージョンまたは可用性ドメインに設定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックにもプライベートにもできます。

  • ロード・バランサー

    Oracle Cloud Infrastructure Load Balancingは、単一のエントリ・ポイントから複数のサーバーへの自動トラフィック分散を提供します。

  • インターネット・ゲートウェイ

    インターネット・ゲートウェイでは、VCNのパブリック・サブネットとパブリック・インターネット間のトラフィックが許可されます。

  • インスタンス・プール

    インスタンス・プールは、同じインスタンス構成から作成され、グループとして管理されるリージョン内のインスタンスのグループです。

考慮事項

このアーキテクチャを実装する前に、次の点を考慮してください。

  • Ampere A2コンピュート・インスタンスのコスト

    各ノードは、2 OCPUと16GBのRAMでAmpere A2を実行します。このOCPUの価格は現在、OCPU当たり$0.01/時間です。月額料金は$14.40まで、1ノードは常にオンになります。

  • ロード・バランサ・コスト

    パブリック・ロード・バランサ(小型シェイプ)の価格は、現在、1時間当たり約$0.029です。月額料金は約21ドル。別のAmpereインスタンスでカスタム・ロード・バランサを設定することで、コストをさらに削減できます。

  • 保管コスト

    各ノードには、OS、llama.cpp、および約5-6GBのモデルが格納されます。デフォルトのブート・ボリュームは約50GBです。毎月最初の200GBは無料です。

詳細の参照

Oracle Cloud InfrastructureのAmpere A2クラスタでのGGUF LLMの実行についてさらに学習します。

次の追加のリソースを確認します。

確認

  • 作成者: Badr Tharwat