AI News HubLIVE
サイト内リライト6 分で読了

OGX: オープン生成AIスタックの紹介

OGX 1.0は、OpenAI APIを置き換えるオープンソースサーバーで、複数のモデルやインフラをサポートし、ビルトインRAG、MCPツール統合、マルチテナント、プロダクション対応の可観測性を備え、コード変更不要でベンダーロックインもありません。

ソースHacker News AI著者: franciscojarceo

2週間前、名称変更をお知らせしました。本日、それが完了したことをお伝えします。

OGX 1.0は、OpenAI APIをあなたが所有するものに置き換えるサーバーです。既存のOpenAI、Anthropic、GoogleのSDKをそれを指すように設定します。任意のインフラストラクチャ上で任意のモデルを実行できます。サーバーサイドのエージェントオーケストレーション、ビルトインRAG、MCPツール統合、マルチテナント、プロダクション対応の可観測性を即座に提供します。ベンダーロックインなし、コード変更不要。

これはベータ版ではありません。「注意事項ありのプロダクション対応」でもありません。これはv1です。

最短バージョン:

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8321/v1", api_key="any")
response = client.responses.create(
    model="gpt-4o",
    input="Q3の収益に関するすべてのドキュメントを見つけて、主要な傾向を要約してください。",
    tools=[
        {"type": "file_search", "vector_store_ids": ["vs_finance"]},
        {"type": "mcp", "server_label": "analytics", "server_url": "http://analytics:8000/sse"},
    ],
)

これは実際のエージェントワークフローです。サーバーはベクトルストアを検索し、MCPツールを呼び出し、結果を推論して回答を返します。1回のAPI呼び出し。コードはシンプルなまま。gpt-4oをclaude-sonnet-4-6やllama-3.3-70bに変更しても、他は何も変わりません。

ここに至るまで

OGXはLlama Stackと呼ばれるLlamaモデルを中心としたAPI標準化の取り組みとして始まりました。それは別のものに成長しました: すべての主要なフロンティアラボのネイティブAPIと通信するサーバーサイドのエージェントループです。その過程で、v1に反映された難しい選択をしました。

私たちは独自のAPIを廃止しました。ファインチューニングAPI、エージェントAPI、knowledge_searchツール、メタリファレンス命名、TGIとHuggingFaceプロバイダー。すべてなくなりました。それぞれが既存の業界標準に合わせるか、システムを簡素化するものに置き換えられました。エージェントAPIはResponses APIになりました。knowledge_searchはfile_searchになりました。OpenAIの用語を採用したのは、OpenAIが標準だからではなく、ほとんどの開発者がすでに知っているからです。開発者のいる場所に合わせることは、新しい名前を発明することに勝ります。

私たちはコンプライアンススコアを獲得しました。OGXはOpen Responses適合テストスイートで100%を通過します。OpenAI API適合スコアは91%以上です。これらは目標ではなく、すべてのコミットでテストされています。

私たちは困難なインフラストラクチャを提供しました。属性ベースのアクセス制御によるマルチテナント。リクエストごとのメトリクス、トークンスループット追跡、モデルレベルのレイテンシを備えた構造化可観測性。ゲートウェイファーストアーキテクチャにより、レート制限とCORSをインフラストラクチャレイヤーに委任します。これらはプロジェクトを製品から区別する機能です。

プロジェクトの全期間で239人のコントリビューター。23の推論プロバイダー。21のベクトルストアバックエンド。そして、ミッションに合わせて名前を変更するという決定により、1696のファイルに影響を与えた改名。

3つのSDK、1つのサーバー

ほとんどの「OpenAI互換」サーバーは/v1/chat/completionsを提供して終わりです。OGXは3つのAPIサーフェスをネイティブに実装しています:

  • OpenAI SDK: from openai import OpenAI
  • Anthropic SDK: from anthropic import Anthropic
  • Google GenAI SDK: from google import genai

3つすべてが同じ推論プロバイダーを叩きます。同じOGXサーバーが、OpenAI SDKを使用するチーム、Anthropic SDKを使用する別のチーム、Google SDKを使用する3番目のチームに同時にサービスを提供できます。同じGPU上で実行されている同じモデルに対して。

これにより、以前は溶接されていた2つの決定が切り離されます: チームが好むSDKと、デプロイするモデル。OllamaでAnthropic SDKを使用。vLLMでGoogle SDKを使用。BedrockでOpenAI SDKを使用。サーバーが変換します。コードは変わりません。

コーディングアシスタントも動作

OGXはアプリSDK専用ではありません。コーディングアシスタントも同じOGXサーバーに向けることができます:

  • Claude Code → Anthropic Messages API via OGX
  • Codex CLI → OpenAI Responses API via OGX

つまり、Claude Code、Codex CLI、OpenAI SDKアプリ、Anthropic SDKアプリはすべて1つのOGXデプロイメントと1つのプロバイダーレイヤーを共有できます。

参照: Claude Code統合とCodex CLI統合。

サーバーサイドのエージェントループ

Responses API以前は、エージェントを構築するにはクライアントサイドのオーケストレーションループを書く必要がありました。モデルを呼び出す。ツールが必要か確認する。ツールを実行する。結果を送り返す。繰り返す。すべてのアプリケーションがこれを再実装していました。すべての実装に独自のバグがありました。

OGXはそのループをサーバーに移します。質問とツールのセットを送信します。サーバーは内部で計画、ツール実行、統合を処理します。クライアントは最終的な回答を受け取ります。

サーバーが処理すること:

  • ビルトインRAG via file_search。ドキュメントをアップロードし、ベクトルストアを作成すると、サーバーが自動的に検索、取得、応答を接地します。外部RAGパイプラインは不要。
  • MCP統合。任意のMCPサーバーに接続すると、エージェントがそのツールを発見して使用します。サーバーサイドのツールオーケストレーションにより、クライアントコードはツールスキーマを知る必要がありません。
  • マルチステップ推論。サーバーはツール呼び出しをチェーンします。シングルショット推論だけでなく、数十行のクライアントコードを必要とする複雑なワークフローが1回のAPI呼び出しで完了します。
  • 会話状態。クライアントサイドの状態管理なしで、インタラクション間の永続的なコンテキスト。
  • 推論出力。思考のトレースを公開するモデルは、応答の一部として返します。回答だけでなく、推論も表示されます。

どこでも実行、同じAPI

OGXはプラガブルなプロバイダーアーキテクチャを持っています。ローカルでOllamaを使用して開発し、本番ではvLLMにデプロイし、必要に応じてマネージドサービスに接続します。APIは変わりません。

  • 商用API: OpenAI、Anthropic、Google (Gemini + Vertex AI)、Azure OpenAI
  • セルフホスト推論: Ollama、vLLM、llama.cpp
  • クラウドプラットフォーム: AWS Bedrock、Databricks、NVIDIA NIM、IBM WatsonX、Oracle OCI
  • 特化型: Fireworks、Together、Groq、Cerebras、SambaNova、RunPod
  • ベクトルストア: FAISS、SQLite-vec、Qdrant、Milvus、Chroma、PGVector、Elasticsearch、Infinispanなど
  • ファイル処理: MarkItDown、Docling、pypdf。PDF、Word文書、テキストファイルをアップロードすると、OGXがベクトルストア用の埋め込みに変換します。
  • ガードレール: builtin responsesプロバイダーでmoderation_endpointを設定し、Responsesリクエストでextra_body={"guardrails": True}を渡します。OGXは生成中にモデレーションサービスをインラインで呼び出し、違反がフラグされた場合は安全でないコンテンツをブロックします。

設定はYAMLで、環境変数の置換をサポートします。条件付きプロバイダーアクティベーションにより、設定で20のプロバイダーを宣言しても、資格情報が存在するものだけが起動します。環境変数を変更するだけで、コードを変更せずに開発から本番に切り替えられます。

プロダクションインフラ、プロトタイプではない

v1は、OGXを実際に実行する際に重要な機能を提供します:

  • マルチテナント。ファイル、ベクトルストア、会話、応答に対する属性ベースのアクセス制御。テナント分離はストレージレイヤーに組み込まれています。複数のチームや顧客向けに1つのOGXサーバーを実行。
  • 可観測性。リクエスト数、レイテンシヒストグラム、エラー率、トークンスループット、モデルレベルのパフォーマンスメトリクス。すべてOpenTelemetryを介して公開。Prometheus、Grafana、Jaeger、または運用チームが既に使用しているものに接続。
  • ゲートウェイファーストアーキテクチャ。OGXはレート制限、CORS、TLS終端をインフラストラクチャゲートウェイ（Envoy、Kong、Istioなど）に委任します。サーバーは推論ルーティング、エージェントオーケストレーション、API変換に集中。
  • 構造化ログ。すべてのログ行はstructlogを介して構造化キー・バリュー形式。解析、インデックス化、アラート設定可能。ログファイルに対する正規表現は不要。
  • バックグラウンドタスク。長時間実行される応答をキューに入れ、必要に応じてキャンセル可能。プロダクションワークロードには、ファイア・アンド・フォーゲットだけでなく、ジョブ制御が必要。

60秒で開始

uvx --from 'ogx[starter]' ogx run starter

その後、任意のOpenAIクライアントをhttp://localhost:8321/v1にポイントして開始。

プロダクションデプロイメントについては、ディストリビューションドキュメントを参照してください。ディストリビューションは特定の環境向けの事前設定済み構成です: NVIDIA NIM、IBM WatsonX、Oracle OCI、または独自のものを構築可能。

今後の展望

v1は基盤であり、終着点ではありません。以下が私たちの方向性です:

  • より深いマルチSDKカバレッジ。AnthropicとGoogle APIのサポートを基本推論を超えて、完全なツール呼び出しとエージェント機能に拡大。
  • ライブラリモード。レイテンシに敏感なアプリケーション向けに、OGXをインプロセスで埋め込み、HTTPレイヤーを不要に。
  • より多くのエージェントパターン。よりリッチなオーケストレーションのプリミティブ、より良い会話管理、より多くのビルトインツール。
  • パフォーマンス。より高速な推論ルーティング、より効率的なエージェントループ、プロバイダー間のより良いリソース利用。

これは始まり

OGXは1つのモデルファミリーを中心としたAPI仕様のセットとして始まりました。それは、すべてのフロンティアラボのAPIと通信し、任意のインフラ上で任意のモデルを実行し、エージェントオーケストレーションの難しい部分を処理するサーバーになりました。

v1は、私たちが自信を持ってナンバリングできることを意味します。APIは安定しています。プロバイダーエコシステムは成熟しています。プロダクションインフラは本物です。239人のコントリビューターがコードを提供すると信じていました。

OGXを試す適切なタイミングを待っていたなら、今です。

はじめる | ドキュメント | GitHub | Discord

— OGXチーム