1.xからの移行
2.0は完全な書き直しで、1.xをインプレース更新できず、データインポートツールもありません。並行デプロイして検証後にトラフィックを切り替えます。
2.0 を 1.x のデータディレクトリやデータベースに指し示さないでください。スキーマは完全に異なり、2.0は1.xのデータを読み取りも変換もできません。旧データディレクトリの再利用は起動失敗や破損の原因になります。
まず結論§
- インプレースアップグレードできない — 新しいイメージを取得するだけのインプレース更新はできません。
- データインポートツールがない — チャネル、キー、Groupは2.0で再設定します。
- 1.x は依然使える — メンテナンスは継続し、ドキュメントも1.4.x ドキュメントに残っています。急がなければ現行環境を維持できます。
やるべきことは：新しい2.0環境を立ち上げて設定・検証し、トラフィックを切り替えることです。古い環境はロールバック期間中はそのままにします。
2.0をインプレース更新できない理由§
2.0ではデータモデルを全面的に書き直しました。最も大きな変更は概念階層が1層から2層になったことです。1.xのGroupが担っていたアップストリーム設定とアプリ認可を、2.0ではGroup（アップストリーム向け）とAccessKey（アプリケーション向け）に分けています。
これは単にいくつかのフィールドを追加すれば対応できる差ではありません。古いデータには「どのアプリケーションを認可し、どのGroupを割り当てるべきか」を推測する情報がありません。したがって、誤った推測をする可能性のあるツールを提供するよりも、バージョン2.0で明確に設定してもらう方が良いです。設定は通常小規模で、一度だけ実行すれば十分です。
概念の対応§
| 1.x | 2.0 に対応 | 説明 |
|---|---|---|
| Group | Group + AccessKey | 1.x Groupは通常「1つのGroup」＋「1つのAccessKey」に分解されます |
| Group内のキー・プール | Groupの認証情報プール | 概念が一致すれば、直接再貼り付けでよい |
| チャネルタイプ | Groupのチャネルフィールド | 2.0 は独立のチャネルメニューなし。Groupの作成時に選択する項目です。 |
| 外向きのGroup名 | AccessKey | アプリケーション側では、Group名をパスに含めず、1つのキーだけを保持します |
2層か3層かは混同しやすいため、基本概念を参照してください。
リクエスト URL の変更§
これはアプリケーション側で唯一変更が必要なものです。1.xではGroup名をパスに含めましたが、2.0では不要です：
# 1.x：アドレスにGroup名を含む http://host:3001/proxy/あなたのGroup名/v1/chat/completions # 2.0：固定アドレス、どのGroupを使うかはAccessKeyとモデル名で決定 http://host:3001/v1/chat/completions
つまり2.0ではアプリケーションはベースURLとAccessKey1つだけで十分です。管理画面でGroupを追加・削除したりプロバイダーを変えたりしても、アプリケーションの変更は不要です。
並行デプロイ§
重要な点は二セットのインスタンスの4つの要素を完全に分離することで、どれか一つでも共用すると問題が発生する可能性があります：
- ポート — 2.0には新しいポートを割り当て、1.xが使用中のポートを使わないでください。
- データディレクトリ / Docker ボリューム — 必ず新規のものを使い、旧環境を再利用しないでください。
- データベース — 新しいデータベースを使います。同じ MySQL でもデータベースは分けてください。
- OAuth コールバックポート — サブスクリプションアカウントではコールバックポートを専用利用します。サブスクリプションアカウントを参照してください。
# 1.x そのまま実行、触らない # 2.0 別のディレクトリにクローン git clone --depth 1 --branch v2 \ https://github.com/tbphp/gpt-load.git gpt-load-v2 cd gpt-load-v2 cp .env.example .env # .env でポートを未使用のものに変更、例：3002 # PORT=3002 docker compose up -d
起動後はクイックスタート設定に従ってください： Group作成、鍵入力、モデル選択、AccessKey発行。
トラフィック切り替え前の検証§
各項目を確認してから本番トラフィックを切り替えます：
- 各Groupは正常に動作します — 実際のモデルで各Groupに1件ずつ送信し、1つだけをテストしないでください。
- モデル名が一致しています — 2.0ではモデルをGroup単位で定義します。アプリが要求するモデルが対応するGroupで公開されていることを確認します。
- プロトコルマッチ — AccessKeyでアプリケーションが使うプロトコルを有効にします。
- 監視を確認します。リクエストログでルーティングが想定どおりか確認します。監視とトラブルシューティングを参照してください。
- 本番用リストを一通り確認します — 特にキーのバックアップとネットワーク境界を確認します。セキュリティと本番運用を参照してください。
まず非クリティカルなアプリケーションを2.0に切り替え、しばらく運用して問題がないことを確認してから、残りを切り替えることを推奨します。
ロールバック§
並行デプロイの場合、ロールバックとはアプリのアドレスとキーを 1.x に戻すことであり、データ移行を戻す必要はありません。
トラフィックを切り替えた後、1.xの環境は少なくともさらに1～2週間維持します。2.0 が実負荷で安定し、接続先が旧インスタンスのままのアプリが残っていないことを確認してから停止を検討します。削除する前に、そのデータディレクトリをバックアップしてください。