OpenFoundry

OpenFoundry

OpenFoundry (Arthur Chi, Tyler Lehman) · コーディング

OpenFoundryは、他社のAPIを借りる代わりに自社クラウドでオープンモデルを探し、ファインチューニングし、動かすためのオープンソースAIデプロイ基盤だ。

OpenFoundry の画面プレビュー

OpenFoundry について

About

OpenFoundryとは

OpenFoundryを手がけるのはサンフランシスコの2人組で、2024年にArthur ChiとTyler Lehmanが立ち上げ、50万ドルの資金を得ている。問題意識は正しい。オープンモデルは無料で落とせるのに、動かす段になると面倒になる。オープンソースAIのデプロイは、多くの現場で手作業のまま止まっている。公式サイトは、用途に合うモデルを見つけ、数クリックでチューニングし、自社クラウドへ送り出すまでを約束した。ホスティング型APIが裏に隠している作業は、まさにその部分だ。

いま実際に入手できるのはModel Managerで、MITライセンスで公開されたPython製のコマンドラインツールである。Hugging Faceのモデル、SageMakerのカタログにあるモデル、あるいは手元の重みを受け取り、自社のAWSアカウントにSageMakerエンドポイントを立てる。設定はコマンド2つとキー1つで済み、Hugging FaceからAWSへの道のりは研究作業ではなくなる。

週末を投じる前に2点だけ押さえておきたい。デプロイ先はAWSのみで、リポジトリの最終コミットは2024年5月だ。openfoundry.aiは現在Overheardへ転送され、これは同じ創業者による別製品である。成果物はコードだと捉え、ホスティング版は停止状態と見たほうがいい。

使い始める

  1. AWSアカウントを作り、SageMakerのアクセスキーを発行する。
  2. model_managerリポジトリを複製し、bash setup.shを実行してキーを貼り、リージョンを確認する。既定はus-east-1だ。
  3. Llama 2のようにアクセス制限のあるモデルを配備するなら、スクリプトが生成する.envにHUGGING_FACE_HUB_KEYを書き足す。
  4. python3 model_manager.pyを走らせ、重みの取得元を選ぶ。Hugging Face、SageMaker、自前のS3パスかローカルフォルダのいずれかだ。小さいモデルなら2分ほどでエンドポイントが立つ。
  5. エンドポイントはスクリプト、ローカルのFastAPIサーバー、SageMaker APIのどれからでも叩ける。/configsに出力されるYAMLを残しておけば、次の配備はコマンド1つで終わる。

AIツール情報

OpenFoundryの料金、対応プラットフォーム、性能を簡単に確認できます。

無料プランはい
有料プランN/A (hosted platform in early access, cloud costs go to your own AWS account)
プラットフォームWeb (early access), Python CLI for macOS, Linux, Windows
開発元OpenFoundry (Arthur Chi, Tyler Lehman)
カテゴリコーディング
リリース日Mar 2024
最終更新May 2024
サイト訪問数N/A
サイト世界ランキング9M
API提供状況N/A

こんな人におすすめ

このツールが最も力を発揮するユーザー、タスク、シーン。

ユーザー

  • 小さなチームのMLエンジニア
  • 個人開発者
  • データを外に出せないチーム

タスク

  • 試作を有料APIから移す
  • 社内向けの埋め込み検索を立てる
  • オープンモデルを選ぶ

シーン

  • データを自社のAWSアカウントから出すなという顧客向けの、文書検索デモ。
  • セキュリティチームがログを見られるVPC内で、Llama 2のような制限付きモデルを動かす。
  • CIからの反復配備

主な機能

決める前にモデルを選ぶ

当初の売りは探索から始まった。用途を書き、オープンモデルを比べ、1つをチューニングする。その流れはホスティング版にあり、いまは新規利用を受け付けていない。コードに残ったのは配備側なので、モデルはHugging Faceで選び、名前をCLIに渡すことになる。

重みの入手元は3つ

Hugging Faceからはgoogle-bert/bert-base-uncasedのような完全なモデル名を貼って配備する。SageMakerのカタログからはフレームワーク別に選べる。自前の成果物はS3パスかローカルフォルダを渡せば、ツールがアップロードする。面白いのは自前の重みで、手作業で進めるとはここで詰まる。

YAML設定とCIからの配備

配備のたびに、モデルとエンドポイントを書いたYAMLが出力される。--deployに渡せば同じ構成がもう一度立ち上がる。手作業だった処理が、マージ時にCIが回す工程に変わる。オープンモデルをデプロイする作業が一度きりの実験でなくなるのは、この仕組みのおかげだ。

自分で書かなくていいクエリサーバー

uvicorn server:appでFastAPIのサービスが起動し、エンドポイント情報用と推論用の2つのルートが使える。temperature、top_k、top_p、最大トークン数、繰り返しペナルティを渡せるので、クライアントライブラリを繋ぐ前にモデルを試せる。対象はテキストモデルだけだ。

自社クラウド、自社の請求、自社のデータ

エンドポイントは自社のAWSアカウントとSageMakerの割当の上で動く。通信がOpenFoundryのサーバーを通ることはなく、調達やデータ所在の確認は早い段階で片付く。その代わり、トラフィックがなくてもメーターは回り続ける。

MITライセンスと読めるコード

ツール全体がMITライセンスで、GitHubのスターは約350。フォークして自社のネットワーク規則に合わせて配備経路を書き換えることも、FastAPIのラッパーを自前サービスへ移すこともできる。アカウント登録も、席あたりの課金も、営業の電話もない。

メリットとデメリット

メリット

  • MITライセンスのコードを読み、フォークし、提供元が更新を止めても動かし続けられる。
  • Hugging Faceのモデル名から稼働中のエンドポイントまで数分で届き、多くのチームが手書きするTerraformとECSの設定を省ける。
  • 重みも推論も自社のAWSアカウントに残る。試作とセキュリティ審査を通る案件の違いはここで決まる。
  • YAMLと`--deploy`があるので反復配備をスクリプト化でき、GitHub Actionsからも回せる。
  • FastAPIのクエリ層が最初から付いており、案件ごとに同じラッパーを書かずに済む。

デメリット

  • AWS専用。AzureとGCPはロードマップ上にあり、マルチクラウドの現場はフォークするか待つしかない。
  • 内蔵のクエリ経路はテキストモデル専用で、画像・音声・マルチモーダルは自前クライアントが要る。
  • エンドポイントは削除するまで時間単位で課金され、自動スケーリングはツールから切り替えられない。消し忘れたエンドポイントは本当に金を食う。
  • リポジトリは2024年5月から止まり、公式サイトも別の場所を指す。採用するのは保守のないプロジェクトで、サポート付きの製品ではない。

よくある質問

無料だ。Model ManagerはMITライセンスで配布され、ホスティング版に公開価格はなかった。実際の出費はAWSの請求で、稼働中のエンドポイントの裏にあるSageMakerインスタンス代が乗る。