github/cc-switch
1
0
Fork 0
mirror of https://github.com/farion1231/cc-switch.git synced 2026-04-21 03:40:31 +08:00
Code Issues Packages Projects Releases Wiki Activity
Files
3d33f299a8aa90bc92fc2a4bfad8ba2e42754530
cc-switch/docs/user-manual/ja/4-proxy/4.5-model-test.md
Jason bbed2a1fe1 docs: restructure user manual for i18n and add EN/JA translations 
Reorganize docs/user-manual/ from flat structure to language subdirectories
(zh/, en/, ja/) with shared assets/. Move existing Chinese docs into zh/,
fix image paths, add multilingual navigation README, and translate all 23
markdown files (~4500 lines each) to English and Japanese.
2026-03-03 08:40:52 +08:00

5.4 KiB
Raw Blame History

4.5 モデルテスト

機能説明

モデルテスト機能は、プロバイダーに設定されたモデルが使用可能かどうかを確認するために、実際の API リクエストを送信してテストします：

  • モデルが存在するか
  • API Key が有効か
  • エンドポイントが正常に応答するか
  • 応答レイテンシが正常か

設定を開く

設定 → 詳細 → モデルテスト

テストモデルの設定

各アプリのテスト用モデルを設定します：

アプリ 設定項目 デフォルト値 説明
Claude Claude モデル システムデフォルト Haiku シリーズの使用を推奨（低コスト・高速）
Codex Codex モデル システムデフォルト mini シリーズの使用を推奨
Gemini Gemini モデル システムデフォルト Flash シリーズの使用を推奨

モデル選択のアドバイス

テストモデルを選択する際の考慮事項：

  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 枠を消費します
  • テストには低コストのモデルの使用を推奨
  • テスト頻度は高すぎないように、枠の浪費を避けてください
  • プロバイダーごとにサポートするモデルが異なる場合があります
Reference in New Issue View Git Blame Copy Permalink