StudioForge 2.0：アカウント機能、スコープ付きAPIキー、そして安全なアップグレード方法

StudioForgeは、私が自作のPCでLM Studioに代わるものとして作成したGPU専用のモデルサーバーです（詳細な経緯は 元の解説記事 をご覧ください）。バージョン2.0では、誰がこのサーバーに接続できるかという点が変更されました。バージョン0.2.0では、あらゆるネットワークインターフェースで待ち受けを行い、接続可能な相手なら誰でも信頼していました。ただしエージェントツール用に任意のPINコードを設定することも可能でした。一方バージョン2.0では、特別な設定をしない限り、サーバーが動作しているマシン上のみで待ち受けを行うようになりました。そして接続を許可する場合には、すべての利用者にキーが必要となります。

GitHub上のソースコード

私自身も2026年10月19日にシステムをアップグレードしました。キーなしでStudioForgeを呼び出していたすべてのプログラムが数分以内に 401 エラーを返すようになりました。例えばメールツールやチャットアプリ、エージェントゲートウェイのメモリ検索機能、いくつかのスクリプトなどです。これらはいずれも不具合があったわけではなく、単にキーが設定されていなかっただけです。このページは、私が最初に読んでおくべきだった内容だと思います。

利用者にとっての変更点

分かりやすく言うと、3つのポイントがあります。

• デフォルトではプライベート状態になります。 ゲートウェイ（ポート1234）、コントロールパネル（8080）、リカバリ用ウォッチドッグ（1235）はすべて 127.0.0.1 にバインドされます。他のマシンからは一切アクセスできなくなります。
• 外部から利用可能にするにはログインが必要です。 これら3つのサービスがネットワークアドレスでリスニングしており、かつ所有者アカウントも管理者キーも存在しない場合、studioforge serve は終了コード4を返し、修正方法を教えてくれます。これにより、うっかり公開サーバーを運用してしまうことはなくなります。
• 各プログラムごとに固有のキーが割り当てられます。 キーとは sf-i-… のような文字列で、プログラムはこれを Authorization: Bearer <key> として送信します。各キーには名前やスコープ、任意の有効期限、1分間あたりのリクエスト数制限などが設定でき、他のキーに影響を与えずに特定のキーのみ無効化することも可能です。

すべてのホストを 0.0.0.0 に設定し、アカウントも存在しない状態で実施したテストにおける拒否結果は次の通りです：

error: Refusing to start: the gateway, the control panel, the watchdog would listen on a
non-loopback address (0.0.0.0, 0.0.0.0, 0.0.0.0) but no owner account or admin API key exists,
so anyone on the network could drive this server. Fix: run `studioforge setup` (creates the
owner account) or `studioforge keys create --name admin --scope admin`, then start again.

一つだけ注意すべき点があります。最初のキーを作成すると、同一マシン上のプログラムも含め全員に対して認証が有効になります。 ループバック専用のテストサーバーでキーを1つ作成したところ、同じマシンから curl を使って /v1/models にアクセスした際、応答コードが 200 から 401 へと即座に変化しました。StudioForgeのCLIやトレイ、パネルはそれぞれ独自のローカル管理者キー（local-cli）をデータディレクトリ内に所有者のみがアクセス可能な形で保持しているため、引き続き正常に動作します。それ以外のすべてのプログラムは以降、必ずキーが必要になります。

10分で完了する安全なアップグレード手順

これがダウンタイムを最小限に抑えるための手順です。CHANGELOGに記載されている移行手順に従っていますが、私自身が実際に実行した際の修正点が2箇所あります。

1. クライアント一覧を作成する。 サーバーに接続するすべてのチャットアプリ、エージェント、スクリプトなどです。確信が持てない場合は、設定ファイル内からサーバーのアドレスをgrepで探してみてください。この一覧作成こそが作業の全てです。
2. バックアップと事前確認を行う。 データディレクトリをコピーし、コードを更新します（git pullした後、READMEに記載されている手順に従ってご使用のプラットフォーム用のvenv環境に再インストール）。その後 studioforge migrate --dry-run を実行します。バージョン2.0.1ではデータベースがスキーマ10へ移行されるため、studioforge migrateは適用前に自動的にバックアップを行います。
3. サーバー起動用の認証情報を作成する。 studioforge setupを利用して初回設定を行うか（これによりオーナーアカウントが作成され、「my local network」を選ぶとHTTPSも有効化され管理者用キーも生成されます）、あるいは studioforge keys create --name admin --scope admin で直接キーを作成します。
4. 新しいサーバーを起動する前に、各クライアント用のキーを一括して作成する。

   studioforge keys create --name chat-app  --scope inference --rate-limit-rpm 120
   studioforge keys create --name dashboard --scope read
   studioforge keys create --name laptop    --scope admin --expires-in-days 30

   各トークンは一度だけ出力され、保存されることはありません。ですからすぐに該当するクライアントの設定ファイルへ貼り付けてください。
5. サーバーを起動し、各クライアントに対して実際のリクエストを送ってテストする。 401 invalid_api_key が返る場合はそのクライアントにはまだキーが設定されていないことになります。また 403 permission_denied の場合は、そのキーのスコープが要求された操作を行うには不十分であることを意味します。
6. 最後に古い認証情報を無効化する。 すべてのクライアントがそれぞれのキーで正常に動作するようになったら、studioforge keys revoke legacy を実行し、server.api_key を消去した上でMCP PINも無効化します。下記の PINに関する注意点 もご参照ください。単にPINのみを消去しても効果はありません。
7. studioforge doctor を実行し、残っている問題がないか確認する。

すでに server.api_key を利用していた場合でも、アップグレード自体は何も壊しません。古いキーは legacy という名前の管理者用キーとしてキーテーブル内に複製され、引き続き使用可能です。私の環境では共有キーは存在せずPINのみだったため、すべてのクライアントが一斉に動作不能になりました。もし手順5より先に手順4を行っていれば、ほとんどの問題を回避できたはずです。

パネル：サインイン、設定、キーの作成

ここに掲載しているスクリーンショットは、NVIDIA GPUが搭載されていないマシン上で Podman を使って実行した 2.0.1 の試用版から取得したものです（詳細は 下記 をご覧ください）。そのため、表示されている2枚のカードはシミュレートされたものであり、キー自体も実際には無効な状態です。

現在このパネルにはサインインページが用意されています。オーナーのユーザー名とパスワードを使用するか、ユーザー名を空欄のまま管理者用キーを貼り付けてください。read用または inference用のキーではログインできません。

/setup にある設定ガイドでは、8つの手順が説明されています。具体的にはオーナーアカウントの作成、ハードウェアの確認、エンジンの設定、モデルライブラリの導入、スタート用モデルの選択、テストチャットの実行、クライアント用コード例の確認、そしてサーバーにアクセス可能な範囲の指定です。どの手順も省略することも可能です。最後の手順では「このコンピュータのみ」または「ローカルネットワーク上で HTTPS を通じて」のいずれかを選択します。

キーの管理は ユーザー＆キー から行います。どのプログラムで利用するか分かるような名前を付け、スコープを選択し、必要に応じて有効期限やリクエスト制限も設定できます。

生成されたトークンは一度だけ表示されます。このスクリーンショットでは隠してありますが、実際のサーバー上ではこのダイアログ内でのみ確認できる仕組みとなっています。

一覧表には各キーのスコープ、先頭数文字、最終利用日時、有効期限、リクエスト制限、現在の状態が記載されています。その下には監査ログもあり、作成または無効化されたキー、サインイン履歴、管理者による変更内容などが記録されており、実行者やアクセス元情報も確認できます。ただし機密情報は一切記録されません。

スコープ：read、inference、admin

スコープ	できること	付与対象
read	ステータスやモデル一覧、/metrics、読み取り専用のMCPツールなどを閲覧可能。ただしPOST操作はできません。	ダッシュボードや監視システム
inference	読み取りに加えて、チャット機能（/v1/chat/completions、/v1/messages、/v1/responses）の利用、モデルのロード・アンロード・テスト、自身用のGPUリソースの確保や解放も可能です。	チャットアプリ、エージェント、スクリプト、その他のGPUを利用するプログラム
admin	設定変更、再起動、エンジンのインストールや更新、ダウンロード・削除処理、キーの管理、アカウント設定、監査ログの確認、破壊的な操作を伴うMCPツールの利用など、システム全体の管理が可能です。	管理者ご自身

ルールはコードによって定義されており、慣例ではありません（api/auth.py:required_scope）。パス接頭辞に基づいて照合が行われ、分類されていない状態変更系のルートには必ずadminスコープが必要となるため、新規ルートも自動的に保護されます。キーが送信されるたびにスコープの検証が行われ、たとえスコープが不要なサーバーであっても例外ではありません。例えばread用のキーでは、ループバック専用のサーバー上でもPOST操作が許可されません。テスト用インスタンスで確認したところ、inference用キーを使用すると/v1/modelsには200が返され、一方/api/keysでは403が返されることが確認できました。

エージェントにもキーが付与されますが、所有者用のパスワードは一切渡されません。管理画面の「インテグレーション」ページでは、OpenClawやOpenAI・AnthropicのPython SDK、DisPatch、curl、そしてClaude用の--mcp-configファイルにそのまま貼り付けられる設定例が表示されます。まずドロップダウンから適切なキーを選択してください。プレースホルダーが選択されている状態では、curl用の設定例からAuthorizationヘッダーが省略されているため、そのまま貼り付けると401エラーが発生します。

オーナーアカウント、古い共有キー、およびPIN

2.0では3種類の認証情報が存在しますが、そのうち2つは近々使用不可になる予定です。

• オーナーアカウントを使ってパネルにログインします。パスワードは10文字以上でなければならず、argon2idアルゴリズムでハッシュ化されます。オプションの keyring エクストラがインストールされている場合はそのハッシュ値がOSのキーリングに保存され、そうでなければオーナー専用のファイルに記録されます。データベースには保存されないため、データベースをコピーしてもログイン情報は引き継がれません。
• server.api_key（廃止予定）は依然として管理者用認証情報としてどこでも機能します。このキーは legacy という名前で表示され、keys revoke legacy を実行すると実際に無効化されます。
• mcp.pin（廃止予定）は8桁の管理者用認証情報で、MCPエンドポイント専用です。キーが設定されていないサーバー上では、遠隔からの呼び出しに対して設定変更用のHTTPルートが開放されたままとなるため、古いペアリングも引き続き機能します。ただし、何らかのスコープ付きキーが存在するとその機能は停止します。

PINに関する注意点。 更新履歴には「server.api_key および mcp.pin をクリアすること」と記載されています。ただし、mcp.pin: null のみを設定した場合、次回起動時に新しいランダムなPINが生成されて再び保存されます。これは mcp.pin_required が依然として true となっているためです。実際にそうなるのを確認しました。完全に廃止するには、両方を設定する必要があります。

mcp:
  pin: null
  pin_required: false

同様の仕組みにより、新しく2.0.1をインストールした場合も初回起動時にPINが生成され、その後 studioforge doctor によって廃止予定のものとして報告されます。問題はありませんが、この挙動に驚かないようにしてください。

バインド設定、HTTPS、およびブラウザについて

• バインド規則。 server.host、gui.host、watchdog.hostのデフォルト値は 127.0.0.1 です。古いバージョンで作成された設定ファイルでは 0.0.0.0 が明示的に指定されているため、新しいデフォルト値に変更されてもその設定は変わりません。この場合、認証情報を追加しない限り接続が拒否されます。
• HTTPS。 server.tls.modeという一つの設定項目で3つのリスナーすべてを制御します。off、self_signed（データディレクトリ内に生成される証明書で、そのSHA-256フィンガープリントがパネル上に表示されるためクライアント側で固定化可能）、または cert（ご自身で用意した証明書ファイル）のいずれかを選べます。ネットワークバインドを行いつつTLSを無効にしている場合、doctorは鍵情報が平文のままネットワーク上を送信される危険性について警告します。ただし、リバースプロキシや tailscale serve を前段に設置すれば問題ありません。
• ブラウザ。 server.cors_originsのデフォルト値は現在空になっています（以前は ["*"] でした）。ブラウザ以外のクライアントには影響ありません。MCPエンドポイント側でも独自にOriginチェックが行われます。つまり、Originヘッダーを含むリクエストはループバックページまたは事前に登録されたオリジンからのものでなければならず、*という設定値も有効とはみなされません。これにより、不審なウェブページがユーザーのブラウザを介して管理ツールにアクセスすることを防いでいます。
• ブルートフォース攻撃対策。 誤った認証情報が入力された場合、各クライアントアドレスごとに3回まで試行が許可されます。その後は5分間まで待機時間が倍増し、API・パネル・ウォッチドッグそれぞれでこの制限が適用されます。

GPUの共有：リースとテナント

もし他のプログラムがそのボックス上でGPUを利用している場合（画像生成ツールや音声処理サーバー、ベンチマークプログラムなど）、まずそのプログラムがGPUに対してリースを取得します。そうなるとStudioForgeは、そのリースが解放されるか、タイムアウトによって無効になるまで、そのGPUにモデルをロードしません。2.0ではテナントレジストリも追加され、これにより各プログラムは自身の存在を通知できるようになり、配置状況ページ上で現在の稼働状態も確認できるようになります。またdevices: "auto"という設定もあり、これを使えば特定のGPU名を指定せずに、空きメモリが十分にある任意のGPUを利用することが可能です。StudioForgeは各テナントの情報を表示でき、あるテナントに対してGPUの初期化や使用終了を依頼することもできますが、実際にプログラムを起動したり停止したりすることはありません。

2.0.1での修正は重要です。2.0.0ではテナント用のルート処理にadminキーが必要でしたため、適切なinferenceキーを持つ音声処理サーバーや画像生成ツールがリースを取得しようとした際に403エラーが発生していました。2.0.1ではこれらはinference用のルートとなり、各リースはそれを取得したキーと紐付けられるようになりました。つまり別のinferenceキーではそのリースを解放できません（私自身が試してみたところ、「lease … was not created by this API key」というメッセージと共に403 permission_deniedエラーが返されました）。一方でadminキーであれば引き続き解放可能です。

テナント名を設定する際に覚えておくべき点として、リースとテナントはファミリーという単位で紐付けられます。このファミリーとは、テナント名の中で最初の-までの部分を指します。例えばspeech-demoという名前で登録した場合、その自身のspeech-demo用のリースは表示されません（この場合のファミリー名はspeechとなります）。一方でspeechという名前で登録すれば、そのリースが正しく表示されます。したがってテナント名にはハイフンを含めない方が良いでしょう。このプロトコル自体についてはリポジトリ内のdocs/TENANTS.mdに詳細が記載されています。

sfctl 2.0.1、リモート制御用ツール

sfctlは、別のマシンからStudioForgeサーバーを操作するための小さなクライアントであり、エージェント用のMCPブリッジとしても機能します。現在では認証キーが必要となっています。このツールはPyPIには存在しません（そのREADMEにある uv tool install studioforge-companion も失敗します）。そのため、ソースコードをクローンしてインストールする必要があります。

git clone https://github.com/LaserLloyd/StudioForge.git
uv tool install ./StudioForge/packages/studioforge-companion
sfctl servers add rig http://192.0.2.10:1234 --api-key sf-i-your-key --use
sfctl status

設定ファイルは ~/.config/studioforge/companion.toml に保存され、キーが含まれているため所有者のみが読み書きできるようになっています。代わりに環境変数 SF_API_KEY を使用することも可能です。ゲートウェイがポート1234で動作していない場合は、--watchdog-url を指定してください。なぜなら、ウォッチドッグのアドレスはゲートウェイのアドレスから導出されるからです。私のテスト用インスタンスでは、inference というキーを使用しています。

$ sfctl status
┏━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━┳━━━━━━━━━━┓
┃ GPU ┃ Name                           ┃ Total    ┃ Used ┃ Free     ┃
┡━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━╇━━━━━━━━━━┩
│ 0   │ Demo GPU 0 (simulated) (sm_86) │ 24.0 GiB │ 0 B  │ 24.0 GiB │
│ 1   │ Demo GPU 1 (simulated) (sm_86) │ 24.0 GiB │ 0 B  │ 24.0 GiB │
└─────┴────────────────────────────────┴──────────┴──────┴──────────┘
no models loaded

$ sfctl leases add --devices 1 --holder image-render --reason "a render job outside StudioForge"
lease 933d9554c0c6 holds GPU 1 for image-render
release it with: sfctl leases release 933d9554c0c6

（表示範囲に収めるため、Util列やTemp列、サーバーテーブルは省略してあります。）

Doctor機能とサポートバンドル

studioforge doctorは、ポートやGPU、エンジン、ディスク、ファイル権限、証明書、マイグレーション、認証設定などをチェックし、問題ごとに修正方法を出力します。--strictオプションを使用すると警告があった場合にも非ゼロの終了コードを返すため、監視用途にも適しています。これはデモ用コンテナで、オーナーアカウントを用いてネットワーク上で待ち受けており、TLSは無効になっています：

[ok  ] GPU: 2 GPU(s) via fake: Demo GPU 0 (simulated) (24 GiB), Demo GPU 1 (simulated) (24 GiB).
[WARN] Engine: No llama.cpp engine is installed.
        fix: Run `studioforge setup` or `studioforge engine --update` to install and smoke-test one.
[ok  ] Permissions: The data directory is writable and credential files are owner-only.
[ok  ] Migrations: The database is at schema 10 (current).
[info] Authentication: The server listens on the network and requires an API key or an account.
[WARN] Authentication: The network listeners use plain HTTP, so keys and passwords cross the network in the clear.
        fix: Set server.tls.mode to self_signed (or cert), or front the server with a TLS reverse proxy / `tailscale serve`.
[info] Authentication: mcp.pin is set. It is deprecated and grants admin on the MCP endpoints.

9 ok, 3 info, 2 warnings, 0 failures.

server.api_keyがまだ設定されたままのループバックテストサーバー上では、同じコマンドで「server.api_keyが設定されています。現在は（管理者キーとして『legacy』として）機能していますが、今後は使用できなくなります」という警告が出ました。修正方法としては、スコープ付きのキーを作成し、クライアント側を移行させた上でlegacyキーを無効化する必要があります。

studioforge support-bundleは、バグ報告用の小さなZIPファイルを生成します。その中には機密情報が伏せられた設定内容、Doctorの出力結果、バージョン情報、GPU一覧、ログの末尾部分などが含まれます。私の環境ではファイルサイズは6 KiBで、PINコードは[REDACTED]と表示されていました。またengine.pinned_tag、つまりllama.cppのビルド番号も伏せられていましたが、これはバグ報告には有用であり秘密情報でもないため、手動で追加する必要があります。このコマンド自体にも「共有する前に確認すること」と記載されており、まさにその通りです。

コンテナ内で実行する方法

2.0版では、CUDAやROCm、Vulkan用のバリアントが含まれたDockerfile、非rootユーザー、読み取り専用のルートファイルシステム、名前付きボリューム、そしてDockerおよびPodman用のコンポーズファイルが同梱されています。新規のボリュームを使用してコンテナを初めて起動する際、SF_OWNER_PASSWORDまたはボリューム上に保存されている自動生成されたパスワードを使ってオーナーアカウントが作成されます。これは、公開されたポートがコンテナ内部から見て「ループバック範囲外」とみなされるためです。SF_BINDを設定しない限り、ポートは 127.0.0.1 に公開されます。

現在、イメージはレジストリ上には存在しません（今日は ghcr.io/laserlloyd/studioforge の取得が拒否されています）。そのため、まずご自身でイメージをビルドする必要があります。READMEに各プラットフォーム向けの正確なコマンドが記載されています。私はこれらのスクリーンショット用にPodmanを使ってVulkan用イメージをビルドしましたが、サイズは568 MBで、すべての機能が無効化された状態で読み取り専用として動作しました。実際にモデルを処理できたのはNVIDIA用イメージのみです。AMD用およびVulkan用イメージは起動して /health に応答はしますが、AMDやIntel製のハードウェア上では実行されていません。各イメージのサイズ、GPU関連のフラグ設定、アップグレード時の互換性テスト、そしてスタック全体のバックアップ方法などについては Docker内のすべてのモジュール に記載されていますので、ここでは繰り返しません。

2.0で新しくなった点

• 変更なしで利用できるクライアントが増えた： LM StudioのネイティブREST APIである /api/v1、Anthropic互換の /v1/messages（x-api-key とベアラートークンの両方が利用可能）、そしてステートレスなOpenAI用の /v1/responses が利用可能になりました。
• 修正方法が記載されたエラーメッセージ： 76種類のエラーコードがあり、それぞれのエラー内容には fix フィールドと docs フィールドが含まれています。例えば、キーを持たないクライアントが受け取る 401 エラーでは、キーを生成するためのコマンド名も示されています。
• NVIDIA以外の環境にも対応： ROCm、Vulkan、Metal向けのGPU検出機能や、アーカイブのチェックサムを確認するバックエンド認識型のエンジンインストーラーが搭載されました。ただし実際にはAMDやApple製ハードウェア上ではなく、記録された検出結果を用いてテストされています。また、llvmpipeのようなソフトウェアベースのVulkanデバイスは使用できません。これは、CPU上でモデルを実行することをStudioForgeが意図的に防ぐためです。
• より大きな設定パネル： 概要、モデル、サービング、エンジン、配置、統合機能、ユーザーとキー、更新情報、ログとメトリクス、診断機能、高度な設定という11のセクションに加え、3つの新しいテーマも追加されました。
• セマンティックバージョニング： 2.0.0というバージョンは、従来のカレンダーバージョンである1.26-09-23に対応しており、アップデーターも両方のバージョン体系を正しく処理します。

私がどのようにテストしたか、そして試さなかったこと

私が使用したマシンにはNVIDIA製のGPUが搭載されていませんので、モデルを読み込むことができませんでした。StudioForgeではテスト用に擬似GPUバックエンドが用意されており（SF_GPU_PROBE=fake、そして SF_FAKE_GPUS 内に記載されたGPUリストを使用）、パネルやキー、アカウント、リース情報、テナント情報、ドクター機能、サポートバンドルなどもすべてこの環境上で動作します。文中で「試してみた」と記述されている部分や出力結果はすべてバージョン2.0.1上で実行されたものです。一度はリポジトリのコピーを一時ディレクトリ内で実行し、もう一度はPodmanコンテナ内で実行しました。どちらもループバックポートを使用しており、ヘッダ情報のみが含まれ重みデータのないデモ用モデルファイルを利用しています。パネル上に表示されるモデルのサイズや量子化設定は実際の値ですが、モデル本体は存在しません。

ここでは試さなかった事項としては、モデルの読み込みや配信、self_signed モードでのTLS設定、Windowsのトレイ機能、そしてバージョン1.26用のデータディレクトリからのアップグレードなどがあります（同一ボリューム上でのアップグレードについては Docker関連の記事 に記載されています）。冒頭にあるアップグレードに関する教訓は、一時的なテスト環境ではなく私の実際のマシンで得られたものです。

まだ改善が必要な点

• まだリリースされていません。 2.0.1はmainブランチ上にありますが、タグも付いておらず、GitHubでのリリース記録も、PyPIパッケージも、公開済みのイメージも存在しません。そのため、自己更新機能も何も更新できない状態です。
• 誤解を招く警告メッセージ。 所有者アカウントはあるもののserver.api_keyが設定されていないネットワーク接続されたサーバーにおいても、「APIキーなしでもサーバーにアクセス可能：LAN上の誰でもモデルを読み込んだり削除したりできる」という内容が概要ページの設定チェックリストに表示されます。しかし実際にはそうではなく、ユーザー＆キーページや実際のリクエスト処理の結果からも認証が必須であることがわかります。このチェックリストは古い共有キーのみを確認しているだけなのです。
• コンテナエンジンに関する説明が文書間で異なります。 READMEでは14GBサイズの-cuda-develイメージを使い、初回起動時にllama.cppをコンパイルすると記載されています。一方でコンテナガイドでは、容量が小さい-cudaイメージを使えば事前にビルド済みのエンジンがダウンロードされると説明されています。私の環境にはNVIDIA製品がなかったためどちらを選ぶべきか判断できませんでした。両文書の内容が一致するまではREADMEに従うことをお勧めします。
• 他者による監査が行われていません。 セキュリティモデルについてはリポジトリ内のdocs/SECURITY.mdに記載されています。ただし、同一マシン上の管理者や、管理していないネットワーク上での平文HTTP通信などに対しては防御できない点も明記されています。StudioForgeを共有ネットワーク上で利用する前に必ずこの文書をお読みください。

入手方法

git clone https://github.com/LaserLloyd/StudioForge.git

その後、ご使用のプラットフォームに合わせてREADMEの手順に従ってください。 元の記事 に掲載されている古いzipファイルはバージョン0.2.0であり、ここで説明している機能は一切含まれていません。ライセンスはMITです。

関連情報： StudioForge：GPU専用のLLMサーバー（設計思想や各種測定値、MCPツールについて）、 Docker内で動作するすべてのモジュール（スタック全体をコンテナ化する方法）、そして DisPatch（キーを使ってこのサーバーに接続するチャットアプリ）です。