2.0 の既知の制限とバージョン戦略
デプロイ、アップグレード、本番トラフィック切り替えの前に、2.0 の実行境界、互換性、リリースチャネルをまとめて確認します。
デプロイとデータ§
2.0 が正しさを保証するのは単一アプリケーションインスタンスだけです。スケジューリング、クールダウン、レート制限、アフィニティなどの状態はインスタンス間で共有されず、外部データベースを使っても水平スケールはできません。
ワークロードの分離や容量拡大が必要な場合は、同じ設定の前にロードバランサー配下のインスタンスを増やすのではなく、業務境界ごとに独立デプロイへ分割してください。
2.0 は 1.x のデータを開く、インポートする、変換することができません。両バージョンは別々のデータベース、データディレクトリ、ポート、Docker ボリュームを使う必要があります。
2.0 を並行デプロイして再設定・検証し、その後トラフィックを切り替えてください。ロールバック期間が終わるまで元の 1.x インスタンスを保持します。
バージョンアップに必要な Schema マイグレーションは起動時に自動実行されます。ただし SQLite、MySQL、PostgreSQL を切り替える際、GPT-Load は既存の設定やデータをコピーしません。
ドライバーを変更する場合は新しいデータベースで再設定・検証し、トラフィックを切り替えてください。自動 Schema マイグレーションとは別の話です。
コストとソフト制限§
コストは上流が返す token 使用量とモデル価格から計算します。使用量や価格がないリクエストは完全に計算できず、価格変更後も過去分は再計算しません。
これらの数値は運用分析と異常保護向けで、財務照合には適しません。
ゲートウェイはリクエスト完了後に推定コストを上限へ加算します。大きな単一リクエストや、すでに許可された並行リクエストはしきい値を超える可能性があり、未価格または使用量がないリクエストは加算されません。
厳密な予算管理には、プロバイダーの請求アラート、予算、ハードクォータも利用してください。
Responses のステートフルリソース§
previous_response_id、conversation、その他のリソース ID は通常、作成時の上流認証情報に依存します。現在のアフィニティはこれらの ID を読まず、後続リクエストが元の認証情報へ戻る保証はありません。
ステートフルリソースを確実に使うには、Group の認証情報を一つにするか、異なる認証情報間で同じリソースを共有できることを上流で確認してください。
暗号化キー§
ENCRYPTION_KEY を交換または紛失すると、既存のチャネル認証情報を復号できません。新旧二つのマスターキーで既存データを再暗号化する手順は現在ありません。
データベースと暗号化キーは必ず一緒にバックアップしてください。復元時は、まずバックアップに一致するアプリケーションバージョンとキーを使います。
バージョンとイメージタグ§
| タグ | 意味 | 利用場面 |
|---|---|---|
| 2.0.0-rc.3 | Git tag の v 接頭辞を除いた完全バージョンタグ | バージョン固定時に使用します。本番ではイメージダイジェストも固定できます |
| 2 | 2.x の追従チャネルです。GA 前は検証済みの 2.0 Beta と RC、GA 後は安定版 2.x のみを追跡します | リリースゲートを通過した新バージョンを受け入れる場合に使用します |
| 2.0-beta | 厳密な形式の 2.0 Beta のみを追跡し、RC は追跡しません | Beta チャネルに留まりたい場合だけ使用します |
| 2.0-rc | この追従タグは存在しません。RC は完全タグを使い、GA 前は 2 も更新される場合があります | 設定しないでください |
| latest | 1.x のままで、2.x を表しません | 2.x のデプロイには使わないでください |
データベースマイグレーションは一方向です。ロールバックにはイメージタグの変更だけでなく、アップグレード前のデータベースと対応するキーの復元が必要です。
メンテナンスポリシー§
- GA 前の 2.0 はプレリリースのセキュリティサポート候補です。リリース準備状況は実際の Release と成果物で判断します。
- 1.4.x はメンテナンス状態で、セキュリティ修正と重大な不具合修正のみを受け付け、新機能は追加しません。
- 現在、1.4.x の EOL 日付や 2.0.x の固定サポート期間は公開されていません。今後は正式なリリース案内に従ってください。