ローカルLLMのルーティングにおいて、TokiosとLiteLLMの比較

​

概要

LiteLLMはオープンソースのPythonベースのプロキシおよびAPIゲートウェイです。LLMバックエンドの前段に配置され、OpenAI、Anthropic、Azure、Bedrock、100その他のプロバイダーのAPI間の翻訳を行います。仮想APIキーや予算管理、負荷分散、可観測性機能も備えており、強力なルーティングおよびコスト管理レイヤーとして機能します。 主な違いは LiteLLMはプロキシであってトンネルではない という点です。呼び出し元とバックエンド間のAPIトラフィックを管理しますが、ローカルモデルをインターネットからアクセス可能にするためのネットワーク問題は解決しません。リモートアクセスには別途TailscaleやCloudflare、Tokiosといったトンネル機能が必要です。 Tokiosはトンネル機能、APIゲートウェイ、各ユーザー用のキー管理、管理用ダッシュボードを 1マネージドサービスとして一体化して提供します。モデルを外部からアクセス可能にするためのネットワークレイヤーと、認証やストリーミング、プロトコル変換を行うAPIレイヤーの両方を扱います。

​

比較表

​

LiteLLMが優れている点

• オープンソース。 完全なソースコードが公開されており、自社環境にてホスティング可能。外部ベンダーへの依存も不要。コードの監査や改変も自由に行える。
• 100以上のプロバイダー。 OpenAI、Anthropic、Azure OpenAI、AWS Bedrock、Google Vertex、Together AIなど多数のサービスを、統一されたOpenAI形式のAPI経由で利用可能。
• 高度なルーティング機能。 重み付けによる負荷分散、レイテンシーに基づくルーティング、プロバイダー障害時の自動フォールバック、レート制限がかかっているモデル向けのクールダウン処理も備える。
• 細かな予算管理。 仮想キー単位、チーム単位、プロジェクト単位で支出上限を設定可能。モデル別・ユーザー別・日別のコストも追跡できる。この点においてLiteLLMははるかに洗練されている。
• 充実した可視化機能。 Langfuse、Datadog、Prometheus、Helicone、およびカスタムコールバックとのネイティブ連携が可能。各リクエストの詳細ログ、トークン数、レイテンシー情報も記録される。
• コストの正確な割り当て。 どのチームがどのモデルにいくら費やしたかを正確に把握できる。複数のクラウドプロバイダーを利用している組織にとって不可欠な機能だ。

​

Tokiosが優れている点

• トンネル機能も内蔵 LiteLLMではローカルモデルをインターネットから利用可能にするため別途ネットワークレイヤーが必要だ。Tokiosには送信用トンネルが標準搭載されており、cloudflaredやTailscale、nginx設定も不要だ。
• 管理型サービス Dockerコンテナの実行やKubernetesでのデプロイ、Python環境の維持も不要。Tokiosはコネクター用バイナリとウェブダッシュボードのみで構成される。
• 組み込みダッシュボード コネクターやデプロイ、APIキーの管理を単一UIから行える。LiteLLMの管理画面は別途設定と構成が求められる。
• ゲートウェイでのプロトコル変換 トンネルエンドポイントでOpenAIおよびAnthropic形式をサポート。LiteLLMはOpenAI形式へ正規化するが、呼び出し側に対してはAnthropicプロトコルを送信しない。
• ローカルモデル利用時の利便性 「自宅のOllamaをAPIキー付きで外部から利用可能にしたい」という目的であれば、Tokiosの設定はわずか2分で済む。LiteLLMの場合はDockerデプロイや設定ファイル作成、別途トンネル設定も必要だ。

​

ネットワーク面での差異

これが根本的な違いだ。LiteLLMはプロキシレイヤーであり、呼び出し側とバックエンドが同一ネットワーク内（または到達可能なネットワーク内）に存在する場合にのみ機能する。自宅サーバーがCGNAT環境下で運用されている場合、LiteLLM単体ではインターネットからのアクセスを実現できない。以下が必要となる：

1. LiteLLMプロキシを公開利用可能にするためのトンネル（Cloudflare Tunnel、Tailscale Funnel、またはTokios）
2. ルーティングやキー管理、利用制限を処理するためのトンネル内LiteLLM
3. LiteLLMの背後に配置されるLLMバックエンド群

合計で3段階の設定・維持作業が必要となる。Tokiosでは1段階と2段階の作業を単一の管理型サービスに集約しているが、LiteLLMが持つ複数プロバイダー対応のルーティング機能は代替できない。

​

両者を併用する方法

複雑な構成においては互いに補完し合う関係にあります：

• LiteLLM はローカルネットワーク上で動作し、複数のバックエンド（ローカルの vLLM、クラウド上の OpenAI、Azure フォールバック）へのルーティングやコスト管理、負荷分散を実現します。
• Tokios は公開向けのトンネルエンドポイントおよび APIキーを提供するため、外部ユーザーやコーディングエージェントが別途トンネル設定を行うことなく LiteLLM プロキシにアクセス可能になります。

このアーキテクチャでは、Tokiosコネクターはバックエンドに直接接続するのではなく、お客様のLiteLLMプロキシを指します。呼び出し側が api.tokios.com に sk-tok-… というAPIキーを送信すると、Tokiosがお客様のマシンへ接続し、そこからLiteLLMが複数のプロバイダー間のルーティング処理を行います。

​

LiteLLM を選ぶべきケース

• 複数クラウドプロバイダー間のルーティングが必要な場合。OpenAI、Anthropic、Azure、ローカルモデル間でフォールバックや負荷分散を実現したい場合です。
• 高度なコスト管理が求められる場合。チーム単位の予算管理やプロジェクトごとの支出制限、詳細なコスト帰属の把握が重要なケースです。
• DevOps 運用能力がある場合。Docker や Kubernetes を用いたデプロイや設定ファイル管理、監視体制の構築が可能な場合です。
• プロバイダーの多様性が必要です。 複数のLLMプロバイダーを統合し、一元化されたAPIインターフェースを実現したいとお考えでしょう。5種類以上のプロバイダーを利用する予定です。

​

Tokios を選ぶべきケース

• ローカルモデルに公開用 API エンドポイントが必要な場合。自社のハードウェア上にあるモデルを認証機能付きで世界中から利用可能にしたいという目的がある場合です。
• 管理されたサービスをご希望ですか。 インフラの運用やコンテナのオーケストレーション、Python環境の管理などは一切不要です。
• トンネル機能・プロキシ・認証キーを一つにまとめたい。 一つのツールでネットワーク接続、認証処理、ストリーミングまでを実現できます — 複数の3個別レイヤーを使う必要はありません。
• シンプルなローカルバックエンドの構築が必要。 OllamaやvLLMの下で動作する一つまたは二つのローカルモデルで十分 — 複数プロバイダーを組み合わせたルーティングメッシュは不要です。