問題となる二つの要素
ストリーミング処理がバッファリングされてしまう
SSEを通じて送信されるLLMの生成結果は、トークンが生成されるたびに順次送られるべきだが、一部のリバースプロキシはウェブ通信の効率化のためデフォルトでレスポンスをバッファする。これはSSEにとって不適切な挙動であり、クライアントは待機した末に全レスポンスが一度に届くか、あるいはタイムアウトしてしまう。
バッファリングされた場合：クライアントは待機した後、全回答が一度に表示される。ストリーミングされた場合：トークンが生成されるたびに順次表示される。
リクエスト処理時間がタイムアウト値を超えてしまう
性能の低いハードウェア上で大規模モデルを動作させると、通常のウェブリクエストのタイムアウト値をはるかに超えて生成処理が続く場合がある。読み書きタイムアウトが固定されたプロキシやトンネルでは、モデルが処理を終える前に接続が切断され、クライアント側には生成結果ではなくゲートウェイエラーが表示される。実際にはモデルはまだ動作中なのだ。比較
上記の制限事項はすべて、各ベンダーが一般用途向けに定めた仕様に過ぎず、不具合ではありません。Cloudflare Tunnelやngrok、Tailscaleもそれぞれ本来の目的通りに機能しています。問題が顕在化するのは、長時間実行される可能性のあるLLM APIのストリーミング処理を行う場合のみです
Tokiosの役割
Tokiosは一般的な意味でTailscaleやCloudflare Tunnelの代替品ではありません。自宅サーバーへのSSH接続には引き続きTailscaleを、アクセス頻度の低いウェブアプリにはCloudflare Tunnelを利用してください。これらは本来の用途に最適なツールです。Tokiosは特定の用途、すなわちコーディングエージェントやAPIクライアントがご自身のハードウェア上で稼働する ストリーミングLLMエンドポイント に接続できるようにするための接続レイヤーです。SSEのバッファリングやプロキシタイムアウトの問題も回避できます Thetokios-connector dials out over a single outbound WebSocket, the same direction-flipping idea behind a tunnel — see How it works for the full request flow. From there, every request authenticates with an sk-tok-… API key scoped to specific deployments, rather than a raw port or hostname being reachable at all.
次の手順
クイックスタート
コネクターをペアリングし、モデルを登録した上で最初のストリーミングリクエストを送信してみよう。
Tokiosにおけるリクエストのルーティング方法
送信専用のアーキテクチャおよびリクエストフローの詳細を確認できる。
CloudflareのSSEバッファリング挙動や、エンタープライズプラン以外での約100～120秒に及ぶプロキシタイムアウトの詳細については TokiosとCloudflare Tunnelの比較 を参照されたい。そこではストリーミング推論に適したエッジ環境の条件や、起こり得る障害の種類も解説されている。