ローカルモデルとバックエンドを選択する

初めてのデプロイ登録を行う際や、複数のローカルモデルを比較したい際に本ガイドをご利用ください。Tokios はモデルを自動選択しません。各ローカルモデルにクライアント側から呼び出せる安定したデプロイ名を付与するだけです。

モデルとバックエンドを選択したら、Tokiosで初回デプロイを登録しましょう。これは 1 認証が必要なエンドポイントで、https://api.tokios.com において利用可能です。所要時間はおよそ 5 分です。

まずはワークフローから始めましょう

ワークフロー	最適化対象	最初に確認すべき点
コーディングエージェント	指示の遵守、リポジトリの論理的解析、ストリーミングの安定性	エージェントに小規模なプロジェクトの検査や修正を依頼してみましょう
チャットアプリケーション	低遅延かつ役立つ応答の実現	短いプロンプトを送信し、最初のトークンが返ってくるまでの時間を比較する
SDKを用いた実験の実施	APIの互換性および応答の予測可能性の確保	Run the same request from `curl` and your SDK
共通のローカルエンドポイントの利用	安定性と分かりやすいデプロイ名の設定	Register one deployment per model and test `/v1/models`

TokiosはOpenAI互換のチャット補完APIを提供するバックエンドへリクエストを転送します。既に利用中のバックエンドから始めてください。ゼロから選定する場合は、ご使用のOSおよびハードウェアに最適な最もシンプルなオプションを選ぶことを推奨します。

バックエンド	多くの場合、以下のような場面で役立ちます…	Tokiosのデフォルトのアップストリームベース
Ollama	CLI中心のローカルモデル環境を手早くセットアップしたい場合	`http://127.0.0.1:11434/v1`
LM Studio	デスクトップアプリや視覚的なモデル管理機能を好む場合	`http://127.0.0.1:1234/v1`
llama.cpp	GGUF形式のモデルを直接実行したい場合	`http://127.0.0.1:8080/v1`
vLLM	GPUを活用したサーバー向けランタイムが必要な場合	`http://127.0.0.1:8000/v1`

現在利用可能なセットアップ例については、バックエンドをご覧ください。

バックエンド側で提供されるモデルIDは、クライアント側が使用する名称と一致する必要はありません。各Tokiosのデプロイには、その役割を表す短い公開用名前を付けてください。

アップストリームモデルID	デプロイ名	この仕組みが役立つ理由
`qwen2.5-coder`	`coder-local`	コーディングエージェントは一つの安定したモデル設定を維持できる
`gemma4:e4b`	`chat-local`	チャットクライアント側はバックエンドIDを把握する必要がない
`mistral-small`	`fast-draft`	名前を通じてそのモデルの用途を明示できる
`muse-glimmer:30b-q4_K_M`	`agent-local`	後から量子化タグを変更してもエージェントクライアント側は同じ名前を使い続けられる

デプロイ名は安定的に保つべきです。後々モデルを別のバックエンドやマシンへ移行する際も、すべてのクライアント側を書き換えるのではなくデプロイやコネクターのルート設定を更新してください。

一度に一つの要素だけを変更しましょう。二つのデプロイを比較する際はプロンプトやクライアント、バックエンド設定、ハードウェアを同一に保ち、処理速度と回答の質の両方を記録してください。

指標	使用方法について
最初のトークンが生成されるまでの時間	リクエストから出力が得られるまでの速さを測定する指標です
Tokens per second	出力が始まってからの生成速度を測定します
タスク全体に要した時間	コーディングエージェントや複数ステップからなるワークフローにおいて最も重要な指標です
生成結果の品質	モデルが実際に期待通りの作業を達成したかどうかを示します
安定性	バックエンドの再起動やタイムアウト、ストリーミング処理の失敗などを検知します

再現性の高いテストフローを実施するには、デプロイ環境のベンチマークをご利用ください