mirror of
https://github.com/farion1231/cc-switch.git
synced 2026-07-29 09:37:37 +08:00
Jason
04af87bc7b
Backfill the empty [Unreleased] CHANGELOG section with the Codex Chat Completions feature (Chat-to-Responses bridge, 23 third-party presets, model mapping table, Stream Check routing, error-envelope conversion, "custom" history bucket) plus the community fixes landed since v3.15.0. Update the zh/en/ja user manual: split the Codex preset tables by upstream protocol (native Responses vs Chat Completions), add a "Codex Local Routing and Model Mapping" section covering the Needs Local Routing toggle and the model catalog, and note Chat-format probing in the Stream Check guide. Manual wording matches the live UI strings.
164 lines
7.0 KiB
Markdown
164 lines
7.0 KiB
Markdown
# 4.5 モデルテスト
|
||
|
||
## 機能説明
|
||
|
||
モデルテスト機能（**Stream Check** とも呼ばれる）は、プロバイダーに設定されたモデルが使用可能かどうかを確認するために、実際の API リクエストを送信してテストします：
|
||
|
||
- モデルが存在するか
|
||
- API Key が有効か
|
||
- エンドポイントが正常に応答するか
|
||
- 応答レイテンシが正常か
|
||
- ストリーミングレスポンスの初回トークン時間（TTFB）
|
||
|
||
v3.13.0 より、Stream Check の対応範囲が **Claude / Codex / Gemini / OpenCode / OpenClaw** に拡張され、OpenClaw の全プロトコルバリアント（`openai-completions` など）も含まれます。OpenCode は npm パッケージマッピングで自動識別、OpenClaw はカスタム `auth-header` 検出、Bedrock エラーメッセージ、`baseURL` フォールバックなどのエッジケースにも対応しています。
|
||
|
||
Chat Completions プロトコルを使用する Codex 第三者プロバイダー（DeepSeek、Kimi、MiniMax など）の場合、Stream Check は `/responses` ではなく `/chat/completions` エンドポイントをプローブし、実際のプロキシ転送パスと URL フォールバック順序を一致させます（origin-only アドレスは `/v1/...` を優先）。これにより、使用可能なプロバイダーが誤って利用不可と判定されることを防ぎます。
|
||
|
||
## 設定を開く
|
||
|
||
設定 → 詳細 → モデルテスト
|
||
|
||
## テストモデルの設定
|
||
|
||
各アプリのテスト用モデルを設定します：
|
||
|
||
| アプリ | 設定項目 | デフォルト値 | 説明 |
|
||
| ---------- | ---------------- | ------------------ | ------------------------------------------------------- |
|
||
| Claude | Claude モデル | システムデフォルト | Haiku シリーズの使用を推奨（低コスト・高速） |
|
||
| Codex | Codex モデル | システムデフォルト | mini シリーズの使用を推奨 |
|
||
| Gemini | Gemini モデル | システムデフォルト | Flash シリーズの使用を推奨 |
|
||
| OpenCode | OpenCode モデル | システムデフォルト | v3.13.0 で追加、npm パッケージマッピングで自動検出 |
|
||
| OpenClaw | OpenClaw モデル | システムデフォルト | v3.13.0 で追加、全プロトコルバリアントとカスタム auth-header に対応 |
|
||
|
||
### モデル選択のアドバイス
|
||
|
||
テストモデルを選択する際の考慮事項：
|
||
|
||
1. **コスト**：低価格のモデルを選択（例：Haiku、Mini、Flash）
|
||
2. **速度**：応答が速いモデルを選択
|
||
3. **可用性**：プロバイダーがサポートしているモデルを選択
|
||
|
||
## テストパラメータの設定
|
||
|
||
### タイムアウト時間
|
||
|
||
| パラメータ | 説明 | デフォルト値 | 範囲 |
|
||
|------|------|--------|------|
|
||
| タイムアウト時間 | 1 回のリクエストのタイムアウト | 45 秒 | 10-120 秒 |
|
||
|
||
短すぎると誤判定の可能性があり、長すぎると障害検出が遅れます。
|
||
|
||
### リトライ回数
|
||
|
||
| パラメータ | 説明 | デフォルト値 | 範囲 |
|
||
|------|------|--------|------|
|
||
| 最大リトライ | 失敗時のリトライ回数 | 2 回 | 0-5 回 |
|
||
|
||
ネットワークが不安定な場合はリトライ回数を増やすことを推奨します。
|
||
|
||
### デグレード閾値
|
||
|
||
| パラメータ | 説明 | デフォルト値 | 範囲 |
|
||
|------|------|--------|------|
|
||
| デグレード閾値 | この時間を超えるとデグレードとマーク | 6000ms | 1000-30000ms |
|
||
|
||
閾値を超えたプロバイダーは「デグレード」状態としてマークされますが、引き続き使用可能です。
|
||
|
||
## モデルテストの実行
|
||
|
||
### 手動テスト
|
||
|
||
プロバイダーカードの「テスト」ボタンをクリックします：
|
||
|
||
1. 設定されたエンドポイントにテストリクエストを送信
|
||
2. 設定されたテストモデルを使用
|
||
3. レスポンスまたはタイムアウトを待機
|
||
4. テスト結果を表示
|
||
|
||
### テスト内容
|
||
|
||
テストリクエストは：
|
||
- 短い prompt（例："Hi"）を送信
|
||
- 最大出力 Token を制限（通常 10-50）
|
||
- ストリームレスポンスで初バイト時間を検出
|
||
|
||
## テスト結果
|
||
|
||
### ヘルスステータス
|
||
|
||
| ステータス | アイコン | 説明 |
|
||
|------|------|------|
|
||
| 健康 | 緑 | レスポンス正常、レイテンシが閾値内 |
|
||
| デグレード | 黄 | レスポンス正常だが、レイテンシが閾値超過 |
|
||
| 利用不可 | 赤 | リクエスト失敗またはタイムアウト |
|
||
|
||
### 結果情報
|
||
|
||
テスト完了後に表示：
|
||
- 応答レイテンシ（ミリ秒）
|
||
- 初バイト時間（TTFB）
|
||
- エラー情報（失敗した場合）
|
||
|
||
## フェイルオーバーとの連携
|
||
|
||
モデルテストはフェイルオーバー機能と連携して使用します：
|
||
|
||
### ヘルスチェック
|
||
|
||
プロキシサービスを有効にすると、システムはフェイルオーバーキュー内のプロバイダーに対して定期的にヘルスチェックを実行します：
|
||
|
||
1. 設定されたテストモデルでリクエストを送信
|
||
2. レスポンスに基づいてヘルスステータスを更新
|
||
3. 不健康なプロバイダーは一時的にスキップ
|
||
|
||
### サーキットブレーカーからの復旧
|
||
|
||
プロバイダーがサーキットブレーカー状態から復旧する際：
|
||
|
||
1. モデルテストで可用性を確認
|
||
2. テスト合格後、正常状態に復旧
|
||
3. テスト不合格の場合、サーキットブレーカーを継続
|
||
|
||
## よくある質問
|
||
|
||
### テストは失敗するが実際には使用可能
|
||
|
||
**考えられる原因**：
|
||
- テストモデルと実際に使用するモデルが異なる
|
||
- プロバイダーが設定されたテストモデルをサポートしていない
|
||
|
||
**解決方法**：
|
||
- テストモデルをプロバイダーがサポートするモデルに変更
|
||
- プロバイダーのモデルリストを確認
|
||
|
||
### レイテンシが高すぎる
|
||
|
||
**考えられる原因**：
|
||
- ネットワークレイテンシ
|
||
- プロバイダーのサーバー負荷が高い
|
||
- モデルの応答が遅い
|
||
|
||
**解決方法**：
|
||
- より高速なテストモデルを使用
|
||
- デグレード閾値を調整
|
||
- ミラーエンドポイントの使用を検討
|
||
|
||
### 頻繁にタイムアウトする
|
||
|
||
**考えられる原因**：
|
||
- タイムアウト時間の設定が短すぎる
|
||
- ネットワークが不安定
|
||
- プロバイダーのサービスが不安定
|
||
|
||
**解決方法**：
|
||
- タイムアウト時間を延長
|
||
- リトライ回数を増加
|
||
- ネットワーク接続を確認
|
||
|
||
## 注意事項
|
||
|
||
- モデルテストは少量の API 枠を消費します
|
||
- テストには低コストのモデルの使用を推奨
|
||
- テスト頻度は高すぎないように、枠の浪費を避けてください
|
||
- プロバイダーごとにサポートするモデルが異なる場合があります
|