概要
Cloudflare Tunnel（cloudflared）はユーザーのマシンからCloudflareのエッジネットワークへ外向き接続を確立します。これはリバースプロキシとして機能し、外部からのリクエストはまずCloudflareに到達し、そこからトンネル経由でローカルサーバーへ転送されます。TLS処理はエッジ側で行われ、ルーター側で受信用ポートを開く必要はありません。
LLM利用時にはcloudflaredをローカルのOllamaまたはvLLMのポートに指定し、DNSレコードを設定すれば、llm.example.comのような公開URLからモデルにアクセス可能になります。機能的には問題ありませんが、Cloudflareのプロキシレイヤーにはストリーミング推論トラフィックに影響を与える制約が存在します。
Tokiosも同様に外向き接続のみを利用しますが、LLM向けのAPIゲートウェイが前面に配置されています。SSEストリーミングもネイティブにサポートされ、生成処理の長さに関わらずプロキシタイムアウトは発生せず、ユーザーごとのAPIキー管理機能も備わっています。
比較表
Cloudflareが優れている点
- 無料プランあり。 Cloudflare Tunnelは標準プランでも無料で利用可能です。単一のサービスを公開したい個人開発者にとって費用は$0程度です。
- 広大なエッジネットワーク。 Cloudflareは世界中に300以上のデータセンターを運営しています。ほぼどこからでもエッジまでの遅延はごく少なく済みます。
- DDoS対策機能。 Cloudflareのネットワークはデフォルトで大量攻撃を吸収します。ご自身の自宅IPアドレスは一切外部に漏れません。
- カスタムドメイン。 自分のトンネルに
llm.yourdomain.comを指定します。Tokiosではapi.tokios.comが使用されるため、カスタムホスト名は設定できません。 - あらゆるHTTPサービスに対応。 WebアプリやAPI、静的サイトなど、背後にある内容を問わずCloudflare Tunnelは問題なく動作します。モデルと共にWebダッシュボードも公開したい場合でも、単一のトンネルで両方を扱えます。
Tokiosが優れている点
- ネイティブなSSEストリーミング機能。バッファリングもヘッダー設定も不要です。生成されたトークンがそのままクライアントへ配信されるため、このトラフィックパターン向けに設計されています。
- 生成時間に制限がない。Cloudflareの読み取りタイムアウトは約100～120秒であり、長時間を要する生成処理を妨げます。一般向けハードウェア上で4,000個ものトークンを生成する大規模モデルは容易にこの制限を超えてしまいますが、Tokiosにはそのような上限は存在しません。
- 組み込みのAPIキー機能。各ユーザーごとに特定のデプロイ先に限定された
sk-tok-…形式のキーが用意されています。Cloudflareを利用する場合は認証機能を自前で構築する必要があり、Cloudflare Accessやミドルウェア、別途用意したAPIゲートウェイが必要です。 - プロトコル変換機能。ゲートウェイレベルでOpenAIおよびAnthropicのAPI規格に対応しています。Cloudflareは生のポート情報をそのまま転送します。
- 2分で完了するセットアップです。インストール用コマンドを実行し、ダッシュボードで承認を行い、APIキーを作成するだけです。一方でCloudflare Tunnelの場合はDNSレコードの作成や
cloudflared種類の設定ファイル、さらに任意でCloudflare Accessポリシーの設定も必要となります。
SSEにおけるバッファリング問題
Cloudflareのプロキシはデフォルトでレスポンス内容をバッファします。これは通常のウェブトラフィックにおいては適切な挙動であり、ページ全体のレスポンス速度向上にも寄与します。しかしSSEストリーミングにおいては不適切な挙動となります。クライアントはトークンを待ち続けているにもかかわらず、最終的に全レスポンスが一度に送信されるか、あるいはタイムアウトが発生してしまうのです。 Cloudflareのドキュメントによれば、プロキシ経由のHTTP通信はオリジン側がContent-Type: text/event-streamヘッダーを送信しない限りバッファされる仕様となっています。一部のLLMバックエンドはこのヘッダーを設定しますが、そうでないものも存在します。また設定されていても中間プロキシや誤設定されたバックエンドによってヘッダーが削除されるケースもあります。その結果、一見正常に動作しているように見えるストリーミングエンドポイントでも、実際には全トークンが最後に一括で送信されるため、ストリーミングの本来の目的が損なわれてしまいます。
TokiosのゲートウェイはLLM向けに最適化されており、ストリーミング処理を認識してバックエンド側のヘッダー設定に関係なく各トークンを即座にクライアントへ送信します。
タイムアウト問題
Cloudflareのプロキシは非エンタープライズプランにおいて約100～120秒という読み取りタイムアウトを適用しています。max_tokens値が大きくコンテキストウィンドウも広い場合や、一般向けハードウェア上で動作する低速なモデルではこの時間を超える生成処理が発生する可能性があります。そうなった場合、クライアント側では524エラーが発生します。モデル自体はまだ動作中だったにもかかわらず、プロキシ側が接続を強制終了してしまうのです。
エンタープライズプランを利用すればこのタイムアウトを延長できますが、本来無料プランで利用可能な機能であるにもかかわらずコストが大幅に増加することになります。
Tokiosではリクエストの実行時間に上限は設けられていません。5分かけて実行される生成処理も問題なく完了します。
Cloudflare Tunnelを選ぶべきケース
- 既にCloudflareエコシステムを利用中。 ドメインのDNS管理もCloudflareで行っており、他のサービスにもCloudflare Accessを活用している場合、新たにトンネルを追加するだけで済みます。
- LLMとWebアプリを同時に公開したい。 ダッシュボードやデモ用UI、モデルAPIなどをすべて一つのカスタムドメイン経由のトンネルで公開可能です。
- カスタムドメインが必要。
llm.yourdomain.comはブランドイメージの構築や既存インフラとの連携に不可欠です。 - 汎用的なリバースプロキシが必要。 LLM API以外のサービスも公開したい場合に適しています。
Tokiosを選ぶべきケース
- LLM専用の利用が目的。 主な目的は信頼性の高いストリーミング機能付きのモデルAPIを公開することであり、一般的なWebサービス運用ではありません。
- 確実なストリーミングが必要。 SSEトークンはリアルタイムで届く必要があり、プロキシのタイムアウトによってバッファリングされたり切り捨てられたりしてはいけません。
- APIキーが必要。 複数のユーザーやエージェントがそれぞれ適切な権限を持つ認証情報を利用する必要がある場合に適しています。
- Want minimal setup. 2 minutes vs 30+ minutes of DNS, config, and Access policy setup.
トンネルとストリーミング機能
SSEのバッファリング処理やプロキシのタイムアウトが、なぜLLMのストリーミング機能を破綻させるのかについて詳しく解説します。
Tokiosを利用すべき場面とは
Tokiosが適切な選択肢となる場合とそうでない場合について、率直に解説したガイドです。