ローカルモデル用のモデルルーティング戦略

Tokiosでは各モデルに個別の公開名を割り当てて公開でき、リクエスト内の model フィールドを変更するだけでモデル間のルーティングが行える。エンドポイントや APIキーは変わらず、変更されるのは model の値のみだ。

ルーティングの仕組み

各デプロイには固有の公開名が存在する。Tokiosがリクエストを受信すると model フィールドを参照し、該当名を持つデプロイを特定した上でそのデプロイのアップストリームモデルIDに書き換え、コネクター経由で転送する。クライアント側の設定は一切変更不要で、変更されるのは model の値のみだ。

一つのコネクターで複数モデルを利用

一つのコネクターで複数のモデルを扱うことも可能だ。Routes 欄に各アップストリームモデルIDを記載し、Upstreams 欄でそれらを名付けたローカルアップストリームにマッピングする。

tokios-connector.json

{
  "Connector": {
    "ConnectorId": "con_...",
    "Token": "ct-...",
    "Routes": [
      { "Model": "gemma4:e4b",    "UpstreamId": "ollama" },
      { "Model": "qwen2.5-coder", "UpstreamId": "lmstudio" }
    ],
    "Upstreams": {
      "ollama":   { "BaseUrl": "http://127.0.0.1:11434/v1" },
      "lmstudio": { "BaseUrl": "http://127.0.0.1:1234/v1" }
    }
  }
}

その後コンソール上で各モデル用の デプロイ を登録し、それぞれに公開名を付与する（例：gemma-tunnel → gemma4:e4b、qwen-coder → qwen2.5-coder）。これらすべてが同一のコネクターを指すことになる。

別々に管理したい場合は、モデルごとに個別のコネクターを起動することも可能だ。その際もそれぞれに独自の ConnectorId/Token および Upstream を設定すればよい。どちらの方法でも問題なく利用でき、サーバー側では常にモデルIDのみがコネクター経由で送信される。

リクエスト内でのモデル切り替え

両方のデプロイが登録済みの状態で、モデルを切り替えるには model フィールドのみを変更すればよい。

# Use the Gemma model
curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "gemma-tunnel", "messages": [{"role": "user", "content": "Hello"}]}'

# Use the Qwen model
curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen-coder", "messages": [{"role": "user", "content": "Hello"}]}'

エンドポイントや認証用ヘッダー、その他すべてのパラメータは変更されません。Tokiosがリクエストの送信を担当します。

クライアント側を一切変更せずにバックエンドを入れ替えられる

クライアントは公開名前のみを参照するため、アップストリームモデルIDを変更せずにモデルを別のハードウェアやバックエンドへ移行できます。デプロイ設定（またはコネクターのアップストリーム情報）を新しいサーバーへ更新し、同じ公開名前を維持すれば既存のリクエストも問題なく処理されます。

ルーティング戦略について

複数のローカルモデルを運用する際、すべてのリクエストを同一モデルへ送信するとリソースが無駄になります。コーディング用リクエストには120B推論モデルは不要であり、単純な分類タスクにも70B大規模モデルは過剰です。ルーティング機能により各リクエストを最適なモデルへ振り分けられ、処理速度や品質、コストを最適化できます。すべての処理に1モデルを使用するとトレードオフが生じます。大規模モデルはあらゆるタスクに対応できますが応答が遅くVRAM消費量も多いです。小規模モデルは応答が速いものの複雑な推論には不向きです。ルーティング機能で両方のモデルを活用可能です。

速度: 単純なクエリは小規模かつ高速なモデルへ、複雑なタスクは大規模モデルへ振り分けられる
品質: コーディング関連のタスクは専用モデルへ、一般的な会話は汎用モデルへ送信される
コスト: 小規模モデルは消費電力やVRAM使用量が少なく、高負荷処理用のリソースを確保できる
耐障害性: プライマリモデルが混雑または停止してもバックアップモデルへリクエストが自動転送される

デプロイごとにモデルは一つのみ

最も簡易な方法です。各モデルを個別のTokiosデプロイとして登録し、クライアント側でmodelフィールドの値を変更することで呼び出すモデルを選択できます。

tokios-connector.json

{
  "Connector": {
    "Routes": [
      { "Model": "qwen3-coder", "UpstreamId": "ollama" },
      { "Model": "gemma-tunnel", "UpstreamId": "ollama" }
    ],
    "Upstreams": {
      "ollama": { "BaseUrl": "http://127.0.0.1:11434/v1" }
    }
  }
}

クライアント側から適切な model 値を含むリクエストを送信します：

# Code task → code model
curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen3-coder", "messages": [{"role": "user", "content": "Write a Python function to sort a list"}]}'

# General chat → general model
curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "gemma-tunnel", "messages": [{"role": "user", "content": "Summarize this article"}]}'

利用シーン：2から3までの各モデルを運用しており、アプリケーション側で呼び出すモデルを制御できる場合です。これが最も一般的な導入パターンとなります。

タスクベースのルーティング

タスクの種類に応じてルーティングします。例えばコーディング関連のリクエストはコーディング専用モデルへ、一般的なチャットは汎用モデルへ、推論処理は高機能モデルへ送信します。クライアントまたはミドルウェア層がリクエスト内容を確認した上で適切なデプロイ先を選択します。

タスクの種類	推奨されるモデルクラス	具体的なデプロイ例	理由
コード生成やリファクタリング	コーディング専用モデル	vLLM上でのQwen3-Coder-30Bの利用	コーディング向けに特化して訓練されており、構文や論理構造の処理能力に優れています
一般的なチャットや要約処理	MoE（35B～122B）	Atlas上でのQwen3.5-35B-A3Bの実行	高いスループットを実現し、各トークンあたり3B個のパラメータが有効化される
複雑な推論や数学的問題の処理に適している	高密度な構造を持つ70B以上のモデル	Qwen3-32B or 70B on vLLM	複数ステップにわたる推論においてより高い品質を発揮する
ツール呼び出しやエージェント処理に対応	ツール利用が可能なモデル	vLLM上で動作するGLM-4.5-Air	関数呼び出し機能を強力にサポートする
ビジョン処理およびマルチモーダル機能	マルチモーダルモデル	vLLM上で動作する Qwen3-VL	画像入力をネイティブに処理可能

最も簡単な実装方法はアプリケーションコード内で行うことです。リクエストの種類を確認し、適切なデプロイ名を選択してください：

def select_model(task_type: str) -> str:
    routing = {
        "code": "qwen3-coder",
        "chat": "gemma-tunnel",
        "reasoning": "glm-4-chat",
        "vision": "qwen3-vl",
    }
    return routing.get(task_type, "gemma-tunnel")

より高度なルーティングが必要な場合は、リクエスト内容を解析し設定可能なルールに基づいて適切なバックエンドへ転送する LiteLLMや OpenRouterといったゲートウェイを利用できます。

ゲートウェイレベルでのルーティング

クライアントと Tokiosの間にルーティングプロキシを配置します。このプロキシがリクエストの属性や負荷状況、カスタムルールに基づいて使用すべき Tokiosデプロイを決定します。LiteLLMは複数の Tokiosデプロイの前段に配置でき、モデルエイリアスに基づいてルーティングを行うことも可能です：

litellm_config.yaml

model_list:
  - model_name: gpt-4  # alias
    litellm_params:
      model: openai/qwen3-coder  # Tokios deployment
      api_base: https://api.tokios.com/v1
      api_key: sk-tok-YOUR_KEY
  - model_name: gpt-4
    litellm_params:
      model: openai/gemma-tunnel  # fallback
      api_base: https://api.tokios.com/v1
      api_key: sk-tok-YOUR_KEY

router_settings:
  routing_strategy: simple-shuffle
  num_retries: 2

クライアントはエイリアス gpt-4を使って LiteLLMプロキシへリクエストを送信し、プロキシが事前に設定した Tokiosデプロイへ転送します。OpenRouterでは複数のプロバイダー間でのモデルフォールバックや負荷分散も可能です。ご自身の Tokiosエンドポイントをカスタムプロバイダーとして追加し、OpenRouterダッシュボードでルーティングルールを設定してください。

フォールバックチェーン

プライマリモデルを設定し、さらに 1個以上のフォールバックモデルも指定します。プライマリモデルが利用中、オフライン状態、またはエラーを返した場合、リクエストはチェーン内の次のモデルへと転送されます。

import requests

FALLBACK_MODELS = ["qwen3-coder", "gemma-tunnel", "qwen3-32b"]

def chat_with_fallback(prompt: str) -> str:
    for model in FALLBACK_MODELS:
        try:
            response = requests.post(
                "https://api.tokios.com/v1/chat/completions",
                headers={
                    "Authorization": "Bearer sk-tok-YOUR_KEY",
                    "Content-Type": "application/json"
                },
                json={"model": model, "messages": [{"role": "user", "content": prompt}]},
                timeout=30
            )
            response.raise_for_status()
            return response.json()["choices"][0]["message"]["content"]
        except (requests.RequestException, KeyError):
            continue
    raise RuntimeError("All models failed")

Tokiosのコネクターは自身のステータスをゲートウェイへ報告します。コネクターがオフラインになると、そのコネクター経由でデプロイされたモデルへのリクエストは全て 503を返します。アプリケーション側でこの状況を検知し別のデプロイへ再試行することも可能ですし、LiteLLMのようなゲートウェイを利用して自動的にフォールバック処理を行わせることもできます。

コストに基づくルーティング

頻度が高く単純なリクエストはより小規模で低コストなモデルへ振り分け、大規模モデルは必要なタスク専用に確保します。

リクエストの種類	ルーティング先	理由
分類や情報抽出処理	MoE with 3–4B active params	高速かつトークン単位の計算負荷が低い
短文の要約処理	7Bから14B個のパラメータを持つ密結合型モデルまたはMoEモデル	十分な品質を維持しつつ応答速度も速い
複雑な推論処理が可能	32Bベースの高密度構成または 122BのMoE構成	複数ステップからなるタスクでも高い品質を実現
コード生成機能	コード作成に特化したモデル	指定されたトークン数内でより良い出力が得られる

この戦略により総計算量と消費電力が削減される。VRAMや電力に制限がある一般向けハードウェア上で運用する際に非常に有益だ。

判断基準表

戦略	複雑さの度合い	最適な用途	いつ利用すべきか
デプロイごとにモデルは一つのみ	低	始め方、2から3までのモデル	アプリケーションコード側で呼び出すモデルを自由に指定可能
タスクベースのルーティング	中	コーディング・チャット・推論	タスクの種類ごとに異なるモデルが必要な場合
ゲートウェイレベルでのルーティング	高	複数クライアントが共通インフラを利用する場合	クライアント側のコードを変更せずに一元管理されたルーティングルールを実現したい
フォールバックチェーン	中程度	高い可用性	主要なモデルがオフライン状態になったり、同時処理可能数の上限に達したりする可能性がある
コストに基づくルーティング	中程度	大量かつ多様なワークロード	単純なタスクをより小規模なモデルへ割り当てることで計算コストを抑えたい

これらの戦略は互いに排他的なものではない。実際の運用では、タスク種別に応じたルーティング（コード生成タスク→コード生成用モデル）と、ゲートウェイプロキシの背後で実施されるフォールバックチェーン（主要モデル→バックアップモデル）を組み合わせるケースが多い

次に行うべきこと

ローカルで利用可能なモデルを選択する

各モデルやバックエンドを比較し、どのデプロイを登録すべきかを決定してください。

ご利用のデプロイのベンチマークを実施しましょう。

実際のワークロード下でルーティング設定が適切かを確認するため、スループットやレイテンシを測定してください。

ハードウェアと互換性

サービングとランタイム接続

クライアント接続

比較

ローカルモデル用のモデルルーティング戦略

ルーティングの仕組み

一つのコネクターで複数モデルを利用

リクエスト内でのモデル切り替え

クライアント側を一切変更せずにバックエンドを入れ替えられる

ルーティング戦略について

判断基準表

次に行うべきこと

ローカルで利用可能なモデルを選択する

ご利用のデプロイのベンチマークを実施しましょう。

​ルーティングの仕組み

​一つのコネクターで複数モデルを利用

​リクエスト内でのモデル切り替え

​クライアント側を一切変更せずにバックエンドを入れ替えられる

​ルーティング戦略について

​判断基準表

​次に行うべきこと

ローカルで利用可能なモデルを選択する

ご利用のデプロイのベンチマークを実施しましょう。

ルーティングの仕組み

一つのコネクターで複数モデルを利用

リクエスト内でのモデル切り替え

クライアント側を一切変更せずにバックエンドを入れ替えられる

ルーティング戦略について

判断基準表

次に行うべきこと