短い回答: アプリケーション内でリクエストをルーティングし、選択したモデルを呼び出すために単一の CometAPI キーと OpenAI 互換のベース URL https://api.cometapi.com/v1 を使用します。反復的で検証が容易な作業は低コスト層へ、遅延に敏感な顧客対応は高速層へ、曖昧または高影響の作業は高精度層へ送ります。これらのラベルは普遍的なモデルランキングではなく自社の方針として保持し、すべての層を同一のテストセットで計測してください。
このガイドでは、コンパクトな Python 例、境界付きフォールバック、再試行および不受理出力を計上するコストモデルを用いて、その三層ルーターを構築します。例では CometAPI カタログの現行モデル ID を使用しますが、ルーティングロジックは分離されているため、アプリケーションを書き換えずにモデルを置き換えられます。
LLM ルーティングとは？
LLM ルーティングとは、各リクエストを、そのタスク、遅延目標、品質要件、予算に最も適したモデルまたはサービス層に送るプロセスです。
タスク別に LLM リクエストをどのようにルーティングすべきか？
2026年8月20日時点で、以下のモデル ID とカタログの料金フィールドが公開 CometAPI Models API から利用可能でした。下記の推定消費者料金は、CometAPI pricing guide に従い、カタログの現在の ratio 値をベースラインの入力・出力価格へ適用したものです。本番利用前に、アカウントに表示される最終レートを確認してください。
| ルート | 用途 | 例示モデル | 推定 USD / 100万トークン | 最初のフォールバック |
|---|---|---|---|---|
| 低コスト | タグ付け、抽出、重複排除 | deepseek-v4-flash | $0.176 入力 / $0.528 出力 | 高速 |
| 高速 | 顧客返信、要約、ライブアシスタント | gemini-3.7-flash | $0.60 入力 / $3.00 出力 | 低コスト、次に高精度 |
| 高精度 | ポリシー審査、複雑な推論、重大な下書き | claude-opus-5 | $4.00 入力 / $20.00 出力 | 高速 |
「高速」はレイテンシ目標があること、「高精度」はより厳しい品質目標があることを意味します。どちらのラベルも、あるモデルが常に最速または最も正確であることを証明するものではありません。マッピングを固定化する前に、自社トラフィックで p50/p95 レイテンシ、タスク合格率、受理出力あたりのコストをベンチマークしてください。
LLM ルーター向けに CometAPI をどのように設定する？
CometAPI の API キー、Python 3.10 以降、OpenAI Python パッケージが必要です。キーはソースコードではなくサーバー側に保管してください。
pip install openaiexport COMETAPI_KEY="your-key-here"
この例では POST /v1/chat/completions を使用します。CometAPI はこれを複数プロバイダ共通のインターフェースとして文書化していますが、パラメータの挙動はモデルにより異なる場合があります。プロバイダ固有フィールドを追加する前に、最新のモデル項目と Chat Completions reference を確認してください。
LLM ルーターを構築するために必要なものは？
安定したタスクをサービス層へマッピングする。 単純なアプリケーション信号で足りる場合に、すべてのリクエストを別の LLM に分類させないでください。サポートタグは予測可能な低コスト層の作業です。ライブ返信は遅延に敏感です。ポリシー審査は最も厳しい品質ゲートに値します。
出力を検証する。 HTTP ステータスが成功でも、結果が利用可能とは限りません。タスク固有のバリデータをルーターに渡します。分類バリデータは許可ラベルを確認でき、顧客返信バリデータは長さや禁止事項を強制でき、構造化ワークフローは JSON スキーマで検証できます。
フォールバックは狭く。 タイムアウト、408、429、一時的な 5xx、あるいは限定的な品質ゲート失敗の後で、承認済みの次のルートを試してください。不正な入力、無効なキー、未サポートのパラメータを隠すために他モデルを使わないでください。
Python で LLM ルーターをどう作る？
import osimport timefrom openai import APIError, OpenAIclient = OpenAI( api_key=os.environ["COMETAPI_KEY"], base_url="https://api.cometapi.com/v1", max_retries=0, timeout=20,)MODELS = { "cheap": "deepseek-v4-flash", "fast": "gemini-3.7-flash", "accurate": "claude-opus-5",}# Put the preferred tier first; later tiers are fallbacks.ROUTES = { "tag": ["cheap", "fast", "accurate"], "reply": ["fast", "cheap", "accurate"], "policy_review": ["accurate", "fast", "cheap"],}def retryable(error): status = getattr(error, "status_code", None) return status is None or status in {408, 429} or (status and status >= 500)def route(task, prompt, validate=lambda text: True): attempts = [] for tier in ROUTES.get(task, ROUTES["reply"]): model = MODELS[tier] started = time.perf_counter() try: response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], max_tokens=400, ) text = response.choices[0].message.content or "" attempts.append({ "tier": tier, "model": model, "latency_ms": round((time.perf_counter() - started) * 1000), "accepted": validate(text), }) if attempts[-1]["accepted"]: return { "text": text, "route": tier, "model": model, "usage": response.usage.model_dump() if response.usage else None, "attempts": attempts, } except APIError as error: attempts.append({"tier": tier, "model": model, "status": error.status_code}) if not retryable(error): raise raise RuntimeError(f"No route passed: {attempts}")if __name__ == "__main__": result = route( "reply", "Reply to a customer asking when their refund will arrive. Do not promise a date.", validate=lambda text: 30 <= len(text) <= 600 and "guarantee" not in text.lower(), ) print(result)
フォールバック前に再試行をどのように制限するか？
SDK の再試行は 0 に設定し、各モデル呼び出しを明示的な制限でラップします。以下のヘルパーは、再試行可能な API 失敗のみ 1 回再試行し、その後は例外を送出して外側のルートが次の承認済み層へ進めるようにします。
MAX_ATTEMPTS_PER_MODEL = 2def call_model(model, prompt): for attempt in range(1, MAX_ATTEMPTS_PER_MODEL + 1): try: return client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], max_tokens=400, ) except APIError as error: if not retryable(error) or attempt == MAX_ATTEMPTS_PER_MODEL: raise time.sleep(min(0.5 * (2 ** (attempt - 1)), 2.0))
route() では、client.chat.completions.create(...) の直接呼び出しを call_model(model, prompt) に置き換えます。三層の場合、1 リクエストが停止するまでに最大 6 回のプロバイダ呼び出しで済みます。品質検証の失敗でも、同じ出力を再試行するのではなく層ごとに 1 回ずつエスカレートします。
python3 llm_task_router.py で実行します。後でプロバイダやモデル世代を変更するには、MODELS を更新します。タスク方針とレスポンス契約は 1 か所にまとまったままです。
この例は、選択したモデル間で共有されるパラメータのみを使用しています。モデルの互換性を確認したうえで、アダプタ層を通じてモデル固有のトークン制御を追加してください。
LLM ルーティング方針をどうテストする？
まず、決定的な方針が意図した一次ルートを選ぶことを確認します。これはルーティングの期待であり、プロバイダの性能結果ではありません。
| テストリクエスト | Task 値 | 期待される一次ルート |
|---|---|---|
| 1つのサポートカテゴリを割り当てる | tag | 低コスト |
| 顧客向けの返信文を下書きする | reply | 高速 |
| 曖昧な返金ポリシーをレビューする | policy_review | 高精度 |
本番環境でのスモークテストが成功すると、回答に加えて選択された層、モデル ID、トークン使用量、すべての試行が返ってきます。実際のトークンおよびレイテンシ値は変動します。
{ "text": "...", "route": "fast", "model": "gemini-3.7-flash", "usage": { "prompt_tokens": "measured value", "completion_tokens": "measured value" }, "attempts": [ { "tier": "fast", "model": "gemini-3.7-flash", "latency_ms": "measured value", "accepted": true } ]}
現実的な比較を行うには、同じラベル付きリクエストを三つのモデルすべてで実行します。タスク合格率、p50/p95 レイテンシ、エラー率、入力・出力トークン、フォールバック率、人手レビュー率を記録します。重要になるのは通常、API 呼び出しあたりのコストではなく、受理された出力あたりのコストです。
マルチモデル・ルーティングのコストはどれくらいか？
公正な比較のために同一のワークロード形状を使用します。総トークン数 100万、うち 80万が入力トークン、20万が出力トークンと仮定します。2026年8月20日に確認したカタログ由来のレートを用いると次のとおりです。
| ルート | 計算式 | 推定コスト |
|---|---|---|
| 低コスト | 0.8 × $0.176 + 0.2 × $0.528 | $0.25 |
| 高速 | 0.8 × $0.60 + 0.2 × $3.00 | $1.08 |
| 高精度 | 0.8 × $4.00 + 0.2 × $20.00 | $7.20 |
トラフィックが 60% 低コスト、30% 高速、10% 高精度の場合、想定される混合トークンコストは約 $1.19/100万トークン です。同じ比率をすべて高精度ルートに送ると、これらの前提では約 $7.20 になります。これは価格計算であり、混合方針が品質目標を満たすことの証明ではありません。
再試行や不受理は結果を変えます。一度限りの再試行率が 5% であれば、$1.19 の見積りはおよそ $1.25 に上がります。低コスト出力が検証に失敗して、要求全体が高精度層で再実行された場合は、両方の呼び出しを計上します。見かけ上安価なモデルがレビューや再生成コストを隠さないよう、受理出力を追跡してください。
よくある LLM ルーティングの失敗は？
| シグナル | 対処 |
|---|---|
| 400 または不正なリクエスト | ペイロードを修正。フォールバックしない。 |
| 401 | API キーを再読込またはローテーション。再試行しない。 |
| 403 | モデルアクセスと未サポートフィールドを確認。 |
| 429 | ジッター付きでバックオフし、同時実行を削減。方針が許せば承認済みフォールバックを使用。 |
| 一時的な 5xx またはタイムアウト | 次の互換ルートを試し、リクエスト ID を保持。 |
| 品質ゲート失敗 | 一度エスカレートし、理由を記録し、設定済みルートリストで停止。 |
error and retry guide は、レート制限や一時的なプラットフォーム障害にはバックオフ付きで再試行し、誤形成リクエストや認証失敗は修正すべきと推奨しています。fallback guide も同様に、モデルフォールバックは順序付けされ明示的であるべきとしています。
アプリケーション・ルーティング vs. CometAPI Auto: どちらを使うべきか？
制御と再現性が重要な場合はアプリケーション・ルーティングを使用。 タスクが安定しており、固定のモデル ID、層ごとの予算、カスタム検証、監査可能なフォールバック順序が必要な場合は、意思決定をコード内に保持します。この方法は、同じモデルマップをリリース間で比較しやすいという利点もあります。
ルーティング保守の削減を優先するなら CometAPI Auto を使用。 model=auto はバランスの取れたデフォルト、model=auto-high は品質優先です。CometAPI はリクエスト特性と現在のルーティングプールから適格モデルを動的に選定します。そのため基盤モデルは変動し得ます。これは、すべての実行で同一モデルやモデル固有パラメータが必要な場合には Auto が不向きであることを意味します。
本番で LLM ルーティングをどう運用する？
モデルレジストリを更新。 デプロイ時または起動時に GET https://api.cometapi.com/api/models を呼び、設定済み ID や必須エンドポイントが欠けていればリリースを失敗させます。モデル ID、価格、能力は変わり得ます。
プロバイダ固有オプションをルーターから排除。 共通の Chat Completions サーフェスがあっても、すべてのパラメータが同一とは限りません。例えば logprobs、推論制御、複数候補のサポートに差があり得ます。これらの差異はテスト済みアダプタに閉じ込めます。
トラフィックと出力を制限。 アプリケーションから出る前に同時実行を抑制し、429 にはジッター付き指数バックオフを使用し、出力トークン上限を設定します。CometAPI の rate-limit guide も同様のアプリケーション側制御を推奨しています。
意思決定を記録。 タスク種別、方針バージョン、選択層、モデル ID、レイテンシ、トークン使用量、検証結果、再試行回数、フォールバック理由、コスト見積りを記録します。秘密情報や不要な顧客コンテンツは記録しないでください。
証拠をもってルートを昇格。 タスクごとにラベル付き評価セットを保持します。マッピング変更は段階的に展開し、前方針と比較し、迅速なロールバック経路を維持します。
よくある質問
CometAPI は自動的にどのモデルが低コスト・高速・高精度かを決めますか？
このチュートリアルでは、その方針をアプリケーションコードに保持します。CometAPI は共有キー、ベース URL、モデルカタログ、Chat Completions インターフェース、ドキュメント化されたフォールバック用ビルディングブロックを提供します。各層の定義と、どのモデルがテストを通過したかは、あなたのチームが決めます。
1 つの CometAPI キーで異なるプロバイダのモデルを呼び出せますか？
はい。OpenAI 互換のテキストルートでは、https://api.cometapi.com/v1 を使用し、model 値を変更します。デプロイ前に最新のカタログを確認してください。
すべてのリクエストを最も安いモデルに送らないのはなぜですか？
最も低いトークン単価でも、出力が検証に失敗したり、再試行が必要になったり、人手レビューを生むと高くつくことがあります。受理結果あたりのコストを比較し、重要度の高いタスクはより厳格な品質ゲートの背後に置きましょう。
品質失敗はフォールバックを引き起こすべきですか？
機械検出可能で、かつエスカレーションが限定される場合に限ります。スキーマエラー、必須項目の欠落、禁止された約束などは一度のエスカレーションを正当化できます。漠然とした不満は無制限の再試行ループではなく、評価データにすべきです。
モデルマップはどのくらいの頻度で変更すべきですか？
最新のカタログデータと再現可能な評価がより良いトレードオフを示したときに変更します。カタログに新しい名前が現れただけでモデルをローテーションしないでください。
後から OpenAI のモデルを追加できますか？
はい。現行の OpenAI 互換モデル ID を MODELS に追加し、同じリクエストとレスポンス契約でテストし、ルート順に配置します。クライアント、キー、ベース URL は変更不要です。
LLM ルーティング方針を保守しやすく保つには？
最も簡単なマルチプロバイダ・ルーターは自律的なブラックボックスではありません。短くバージョン管理されたタスク方針であり、共有 API アクセス、最新のモデルメタデータ、品質バリデータ、狭いフォールバック連鎖に支えられたものです。CometAPI は接続作業を 1 つのキーと 1 つの OpenAI 互換ベース URL にまで縮減します。コスト、レイテンシ、品質の意思決定はアプリケーション側で制御し続けてください。