Launch HN: Respan (YC W24) – プラグイン中心のオープンソースRust AIゲートウェイ
Launch HN: Respan (YC W24) – Open-source Rust AI gateway built around plugins (news.ycombinator.com)
要約
Respanは、プラグインを中心に構築されたオープンソースのRust製AIゲートウェイを発表しました。このゲートウェイは、プロバイダー、プロトコル、モダリティ、ゲートウェイ機能など、あらゆる要素をプラグインとして扱うことで、柔軟性と拡張性を高めています。開発者は、コアを変更せずに独自の機能を追加できるため、AIインフラストラクチャの構築が容易になります。
全文翻訳
皆さん、こんにちは。RespanのAndyです（https://www.respan.ai）。私たちはオープンソースのRust製AIゲートウェイを開発しています。これは疎結合なゲートウェイであり、異なるプロバイダー、プロトコル（MCP、音声）、モダリティ（画像、動画）、およびゲートウェイ機能（フォールバック、PII（個人識別情報）のマスキング、スマートルーティング）など、すべてがプラグインとなっています。
無数のプロバイダーや機能を一つのゲートウェイにパッケージ化するのではなく、Respanは小さなコアと公開インターフェースを提供し、チームはアプリケーションが必要とするAIインフラストラクチャを組み立てることができます。これにより、ユーザーはゲートウェイのコアを変更することなく、追加のプラグインとして独自の機能を作成できます。
ビデオデモはこちらです：https://www.youtube.com/watch?v=pVv2ibXiTXM
LLMゲートウェイは数え切れないほど存在し、そのほとんどが共通の問題を解決しています。それは、単一のエンドポイントから異なるプロバイダーを呼び出すことです。しかし、新機能の追加は非常に困難になることがあります。そのため、開発者は特定の問題を解決するために別のゲートウェイを構築することになるかもしれません。
私たちは2024年からLiteLLMに基づいてゲートウェイを開発しており、現在では数千の組織にサービスを提供しています。各組織は異なるAPIキー設定、ルーティング、および制限を必要とします。これをサポートするために、LiteLLMをラップし続け、機能を追加していきましたが、ある時点で、私たちのラッパーコードは10万行を超えました。
この1月、定期的なLiteLLMのアップグレードが断続的な接続エラーを引き起こし、ロールバックしなければなりませんでした。原因はまだ特定できていませんが、それ以来、LiteLLMを直接アップグレードすることはなくなり、代わりにアップストリームの修正を手動でバックポートしています。これらの経験から、LiteLLMをパッチし続けることは持続可能な長期的な解決策ではないと認識し、ゲートウェイ自体を再設計する必要がありました。
ゲートウェイを再設計するにあたり、既存の機能を壊すことなく機能を追加しやすくしたいと考えました。Nginxに触発され、AIゲートウェイはイベントのディスパッチのみを担当する非常に小さなコアを持つべきだと考えています。
私たちのゲートウェイでは、プロバイダー（OpenAI、Anthropic、Gemini）、プロトコル（チャット、リアルタイム音声、MCP）、モダリティ（画像、動画）、および信頼性とセキュリティのためのゲートウェイ機能（スマートルーティング、フォールバック、例示的なプラグインによるPIIマスキング）を含むすべてがプラグインであるべきだと信じています。さらに、開発者がコアに触れることなく、独自のプラグインを追加することでゲートウェイの機能を簡単に拡張できるようにしたいと考えています。プロバイダーの追加は、たとえ独自のプロバイダーであっても非常に簡単です。なぜなら、quirk（特殊な挙動）もプラグインであり、それらに魔法のようなものはないからです。プロバイダーは短いファイルであり、Mistralのものは22行です。Groqがトークン使用量を独自のフィールドに入れているような各quirkは、独自のテストを持っています。
Respan Gatewayは、ClaudeやGeminiモデルをOpenAI SDKから呼び出せる以上のことを行います。ツール、画像、および推論プロトコルを自動的に処理します。OpenAI Realtime APIに基づいたアプリケーションは、ゲートウェイを通じてGemini Liveも使用できますが、すべての機能が互換性があるわけではありません。シンプルなチャットアプリは、MCP自体を実装することなく、ゲートウェイで設定されたMCPツールを使用できます。
また、リクエストを共有構造に解析します。クライアントとプロバイダーが同じAPIを使用する場合、共有構造にフィールドがなくても、プロバイダー固有のフィールドをネイティブ形式で保持します。これにより、ゲートウェイはそれらをドロップするのではなく、書き戻すことができます。
仕組みは以下の通りです。
アダプターは、各HTTPまたはWebSocket接続を、それを認識する最初のクライアントフォーマットに渡します。フォーマットは、リクエストを型付けされた入力および出力イベントの双方向ストリームとして公開します。コアは登録順にプラグインを実行し、プラグインがプロバイダーを選択したり、ストリームをフィルタリングまたはラップしたり、追加の呼び出しを行ったり、レスポンスを返したり、リクエストを拒否したりできるようにします。その後、プロバイダーフォーマットがアップストリーム接続を開きます。
クライアントとプロバイダーが同じフォーマットを使用し、プラグインがペイロードを変更しない場合、元のバイトとプロトコル固有のフィールドは変更されずに通過できます。フォーマットが異なる場合、メッセージ、ツール呼び出し、結果、ストリーム、および使用量のために共有型を介して変換されます。このストリームモデルは、単発のHTTPリクエストと長期間の双方向セッションの両方を表すことができます。
ゲートウェイは、MITまたはApache-2.0ライセンスの下で、https://github.com/respanai/respan-gatewayでオープンソースとして公開されています。Respanのホスト型プラットフォームを使用する必要はなく、ローカルマシンで直接実行できます。ソースからビルドし、プロバイダーキーを追加し、サポートされているクライアントのベースURLをスワップしてください。クライアントが既に話しているAPIを引き続き使用できます。これはまだプレアルファ版です。
私たちは、ネイティブなオブザーバビリティと評価（evals）、および統合請求（billing）を備え、ゲートウェイをホストするホスト型プラットフォーム（https://www.respan.ai/pricing）で収益を得ています。
エージェント向けのルーティング、ツール、フィルタリング、オブザーバビリティ、またはセキュリティを構築している場合、それをプラグインとして見てみたいです。リポジトリのPLUGINS.mdには、プラグインの作成方法と、これまでに作成したプラグインへのリンクが記載されています。これをエコシステムに発展させることが、基本的に私たちのロードマップであり、皆様自身のプラグインの貢献を歓迎します。ご質問にお答えし、フィードバックをお待ちしております！