LightSeek Foundation が開発する、LLM 本番運用向けのオープンソース推論ゲートウェイ。vLLM・SGLang・TensorRT-LLM といった自前で動かす推論エンジンと、OpenAI・Anthropic・Gemini などのクラウド API を、ひとつの OpenAI 互換エンドポイントの背後にまとめる。アプリ側は「OpenAI の API を呼ぶ」書き方のまま、裏側でどのモデル・どのサーバーに振り分けるかをゲートウェイ側で制御できるのが基本の発想だ。本体は Rust で書かれており、KV キャッシュの状態を見たルーティングやサーキットブレーカーによる自動フェイルオーバー、Prometheus メトリクスでの可観測性を備える。ライセンスは Apache 2.0 で、pip・Cargo・Docker・Helm から導入できる。
主な特徴
- 単一の OpenAI 互換エンドポイント: 自前推論エンジン（HTTP / gRPC）とクラウドプロバイダーを同じ入口に束ねる。アプリのコードを書き換えずにバックエンドを差し替えたり、複数を併用したりできる
- キャッシュを意識したルーティング: vLLM・SGLang・TensorRT-LLM などのワーカーが保持する KV キャッシュの状態を追跡し、同じ文脈のリクエストを同じワーカーへ寄せて GPU 利用効率を上げる。ルーティングポリシーはキャッシュ考慮のほか、least-load、power-of-two、コンシステントハッシュ、ラウンドロビンなど複数から選べる
- トラフィック制御と自動フェイルオーバー: レートリミット、ロードバランシング、サーキットブレーカーを備える。あるバックエンドが不調になったときに切り離し、別の経路へ流すといった運用ができる
- 可観測性: 90 種類以上の Prometheus メトリクス、OpenTelemetry トレーシング、構造化 JSON ログを出力する。どのモデルにどれだけ流れているか、遅延がどこで発生しているかを外部の監視基盤から追える
- マルチテナントとエンタープライズ機能: API キー認証と OIDC 認証、テナント分離、優先度つきの受付制御、WebAssembly プラグインによる拡張に対応する
- MCP ツール実行に対応: Model Context Protocol のツール探索・実行を stdio / SSE / HTTP 経由で扱え、承認ポリシーを設定できる
- Kubernetes ネイティブ: ラベルセレクタによる Pod の自動ディスカバリに対応し、クラスタ内でワーカーが増減しても追従する
料金
| プラン | 料金 | 主な特徴 |
|---|---|---|
| オープンソース版 | $0（Apache 2.0） | 全機能を自己ホストで利用可能。pip / Cargo / Docker / Helm で導入 |
公式サイトおよび公式ドキュメントには、商用版・エンタープライズ版・有償サポートに関する記載は確認できなかった。実際のコストは、ゲートウェイを動かすサーバーと、その先で使う GPU インスタンスやクラウド API の従量課金が中心になる。
料金は2026年8月時点の情報です。最新の料金は公式サイトをご確認ください。
メリット・デメリット
✅ メリット
- OpenAI 互換のため、既存アプリのエンドポイント設定を変えるだけで導入を始められる
- 自前ホストのモデルとクラウド API を同じ入口で扱えるので、コスト最適化や段階的な内製化の受け皿になる
- KV キャッシュを考慮したルーティングにより、素朴なラウンドロビンよりも GPU の利用効率を上げやすい
- Prometheus / OpenTelemetry に素直に出力するので、既存の監視スタックへ組み込みやすい
- Apache 2.0 のオープンソースで、ベンダーロックインを避けられる
⚠️ デメリット
- インフラ部品であり、単体では何も生成しない。推論エンジンやクラウド API を別途用意する前提になる
- 導入・運用には Kubernetes やロードバランシング、メトリクス監視の知識が要る。個人が 1 台のマシンでモデルを試す用途にはやや重い
- SaaS 型のゲートウェイと違い、ゲートウェイ自身の冗長化・アップデート・障害対応を自分たちで担う必要がある
- 2026 年 2 月公開と比較的新しく、長期運用の事例やノウハウの蓄積はこれから
類似サービスとの比較
| 比較項目 | SMG | LiteLLM | Portkey | Envoy AI Gateway |
|---|---|---|---|---|
| 提供形態 | オープンソース（自己ホスト） | オープンソース + クラウド版 | SaaS 中心（OSS 版あり） | オープンソース（自己ホスト） |
| 実装 | Rust | Python | ─ | Go / Envoy |
| 主な強み | 自前推論エンジンのキャッシュ考慮ルーティング | 対応プロバイダー数の多さ・導入の手軽さ | ガードレール・分析などの運用機能 | Envoy 基盤との統合 |
| 自前エンジン連携 | vLLM / SGLang / TensorRT-LLM / MLX などに対応 | OpenAI 互換サーバー経由 | 主にクラウド API 向け | OpenAI 互換サーバー経由 |
| 想定規模 | GPU クラスタを持つ本番運用 | 小〜中規模、プロトタイプにも | チーム〜企業 | 既存 Envoy 利用組織 |
こんな人におすすめ
- 自社の GPU で vLLM や SGLang を動かしており、その前段に本格的なルーティング層を置きたいチーム
- クラウド API と自前ホストのモデルを併用し、コストや負荷に応じて振り分けたいプロダクト開発者
- LLM の利用状況をメトリクスとして可視化し、SRE と同じ運用フローに乗せたいインフラ担当者
- マルチテナントで LLM 基盤を社内提供し、テナントごとの認証や優先度制御が必要な組織
- ベンダーロックインを避け、Apache 2.0 のオープンソースで基盤を組みたい企業
まとめ
SMG は、LLM の推論トラフィックを扱う「ネットワーク機器」に近い性格のソフトウェアである。単体では何も生成しないが、自前推論エンジンとクラウド API が入り混じる本番環境で、どこへどう流すかを一箇所で決められるようにする。KV キャッシュを見たルーティングや豊富な Prometheus メトリクスは、GPU コストと遅延の両方を気にする規模になってから効いてくる。まずは pip か Docker で 1 ノード分を立ち上げ、既存アプリのエンドポイントを向け替えて挙動を確かめるところから始めるとよい。逆に、個人が単一のモデルを試すだけであれば、この層はまだ必要ない。