github/cc-switch
1
0
Fork 0
mirror of https://github.com/farion1231/cc-switch.git synced 2026-06-14 10:46:51 +08:00
Code Issues Packages Projects Releases Wiki Activity
Files
21e2d68d76e08bee1b626cd1fd4d7419fbeb73e6
cc-switch/docs/user-manual/ja/4-proxy/4.5-model-test.md
T
Jason a058ebeafc docs(user-manual): update to v3.13.0 across en/zh/ja 
Refresh the user manual to cover the v3.13.0 feature set so users can
discover and correctly use new functionality without cross-referencing
the release notes. All three language versions are updated
line-by-line symmetric.

Highlights:

- Lightweight Mode: tray-only running state added in 1.5-settings,
  with a comparison table against "Minimize to tray" and a new OAuth
  Auth Center (Beta) section
- Quota & Balance display restructured in 2.5-usage-query: split into
  auto-query (Claude/Codex/Gemini official, Copilot, Codex OAuth) vs
  manual-enable (Token Plan, third-party balances). Explains why
  manual enabling is required: the same API URL may expose both
  plan-quota and balance query modes
- Codex OAuth reverse proxy: full usage guide in 2.1-add with two
  entry points (Add Provider panel / OAuth Auth Center), Device Code
  login flow, token auto-refresh, multi-account management, quota
  display, common failures, and risk notice
- Full URL Endpoint Mode: new advanced option in 2.1-add
- Per-app tray submenus: 2.2-switch refactored to reflect the 5-app
  submenu structure and cross-link to Lightweight Mode
- Skills workflow: remove obsolete "automatic update not supported"
  section in 3.3-skills, add SHA-256 update detection, single/batch
  update, storage location switch, and skills.sh registry search
- Directory picker for Claude terminal resume in 3.4-sessions
- Usage stats in 4.4-usage: document the new CLI session log source
  (no proxy required) and per-app filtering for Claude/Codex/Gemini;
  note CNY->USD pricing corrections and MiniMax quota fixes
- Stream Check coverage extended to OpenCode/OpenClaw in 4.5-model-test
- New FAQs in 5.2-questions: quota visibility (auto vs manual),
  Codex OAuth risks and login flow, deep link wake in Lightweight Mode
- v3.13.0 highlights navigation block added to top-level README and
  each per-language README; version bumped to v3.13.0 / 2026-04-08
2026-04-09 16:49:14 +08:00

6.5 KiB
Raw Blame History

4.5 モデルテスト

機能説明

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

  • モデルが存在するか
  • API Key が有効か
  • エンドポイントが正常に応答するか
  • 応答レイテンシが正常か
  • ストリーミングレスポンスの初回トークン時間（TTFB）

v3.13.0 より、Stream Check の対応範囲が 5 つのアプリ全対応（Claude / Codex / Gemini / OpenCode / OpenClaw）に拡張され、OpenClaw の全プロトコルバリアント（openai-completions など）も含まれます。OpenCode は npm パッケージマッピングで自動識別、OpenClaw はカスタム auth-header 検出、Bedrock エラーメッセージ、baseURL フォールバックなどのエッジケースにも対応しています。

設定を開く

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

テストモデルの設定

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

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