SIEでAIエージェントを構築するときのコンテナ動物園を排除する方法

ローカルまたはオープンソースのニューラルネットワークで自律エージェントを構築することは、急速にインフラの頭痛の種になりつつあります。複数の意思決定ステップを含むRAGシステムを組み立てている場合、複数の狭い目的のシステムを同時に実行する必要があります。検索用のベクトルモデル、別のリランカー、PDFの複雑なグラフィックを解析するツール、セキュリティ分類器、生成LLMが必要です。

結果として、開発環境はすぐにdocker-composeファイルのゴミ捨て場になります。1つのコンテナがvLLM用にメモリを占有し、別のコンテナがText Embeddings Inferenceを起動し、3番目のコンテナがGLiNERによる偏執的なエンティティ抽出のためだけにPyTorchを立ち上げます。これらのインスタンスを常に稼働させておくことは、GPU請求書を膨大にする確実な方法です。

Superlinkedのエンジニアも同じ問題にぶつかり、SIE（Superlinked Inference Engine）をリリースしました。これは、すべてのエージェントタスク処理を一元化する推論サーバーです。

内部動作の仕組み

SIEは異なるアプローチを取ります。5つの独立した推論サーバーを実行する代わりに、標準的なOpenAIエンドポイント（/v1/embeddingsや/v1/chat/completionsなど）に応答する1つのクラスターをデプロイします。

主な特徴は、LRU（Least Recently Used）エビクションアルゴリズムによるオンデマンドの動的モデルローディングです。エージェントがユーザーアップロードされたスキャンの解析にOCRを必要とするとき、SIEはドキュメント認識モデルをGPUメモリにロードします。解析ステージが完了してシステムが対話に移行すると、めったに使わないモデルはメモリを解放して生成ネットワークに回します。

カタログには、箱から出してすぐに使える100以上の事前設定済みセットアップが含まれています。 인기のあるオプションには、BGE-M3、ColBERTv2、SPLADE-v3、GLiNER、Docling、Qwen3、Granite Guardianのようなプロンプトインジェクション保護モデルが含まれています。

ローカルマシンでのクイックスタート

最初の概要には、標準のPythonパッケージで十分です。CPUまたはApple Siliconでテストインスタンスを2つのコマンドで起動できます：

pip install "sie-server[local]"
sie-server serve

NVIDIA GPUで重いワークロードを実行する予定がある場合は、最初からDockerを選択してください。開発者は、競合するシステム依存関係のため、意図的にサービスを分離されたコンテナに分割しています。OCRモデルには最新のtransformersライブラリが必要なため отдельныйタグとして出荷されます。

ベクトル検索の場合、ベースコンテナを起動するには次のようにします：

docker run --gpus all -p 8080:8080 \
  -v sie-hf-cache:/app/.cache/huggingface \
  ghcr.io/superlinked/sie-server:latest-cuda12-default

動作確認は標準のcurl呼び出しで行えます：

curl http://localhost:8080/v1/embeddings \
  -H 'Content-Type: application/json' \
  -d '{"model": "sentence-transformers/all-MiniLM-L6-v2", "input": "Привет, мир"}'

最初のリクエスト時に、サーバーはHugging Faceから重みを自動的にダウンロードしローカルキャッシュに保存するため、後続のクエリはダウンロード遅延なしで実行されます。

Python SDKでのコーディング

サーバーでの作業 위해、著者はPythonとTypeScript用のライブラリを書きました。SDKは分類や名前付きエンティティ抽出などの特定のタスクの呼び出しを処理します。

1つのクライアント内でテキストのベクトル化、結果のリランキング、エンティティ抽出を行う例：

from sie_sdk import SIEClient
from sie_sdk.types import Item

client = SIEClient("http://localhost:8080")

# Получаем эмбеддинг
embedding = client.encode("sentence-transformers/all-MiniLM-L6-v2", Item(text="Привет мир"))

# Считаем релевантность документов
scores = client.score(
    "cross-encoder/ms-marco-MiniLM-L-6-v2",
    Item(text="Что такое машинное обучение?"),
    [Item(text="ML обучается на данных."), Item(text="Сегодня солнечная погода.")],
)

# Извлекаем сущности через GLiNER
entities = client.extract(
    "urchade/gliner_multi-v2.1",
    Item(text="Тим Кук руководит компанией Apple в Купертино."),
    labels=["person", "organization", "location"],
)

構文はシンプルです。HTTPエンドポイント用の独自のラッパーを書いたり、各マイナーなモデルにサードパーティのライブラリをインポートしたりする必要はありません。

本番対応

同様の多くのオープンソースプロジェクトは、ローカル使用用の精巧なREADMEの段階で足踏みしています。SIEの場合、著者はすぐにKubernetesへのデプロイ用のインフラツールを発表しました。

リポジトリと組織内の関連プロジェクトには以下が含まれています：

• クイックインストール用のHelmチャート sie-cluster。
• AWS（EKS）、Google Cloud（GKE）、Azure（AKS）用のTerraformモジュール。
• KEDAによるゼロへのポッド自動スケーリング設定。
• メトリクス収集用のロードバランサーとGrafanaダッシュボード。

ポッドをゼロにスケールダウンできる機能は、社内部サービスに便利です。従業員が夜間にエージェントを使用していない場合、クラウドGPUは単にアイドル状態になりません。

注意点

すべてのタスク用の単一推論サーバーというコンセプトは素晴らしいですが、完璧なソリューションはありません。

主な落とし前は、コールドスタートレイテンシです。モデルがLRUエビクションによりGPUメモリから追い出されたとき、次のリクエストはディスクから重みをリロードするのを待つ必要があります。比較的遅いストレージでは、エージェントの応答に数秒の遅延が追加されます。

2番目の詳細はDockerイメージの分離に関連しています。パイプラインがLightOnOCRベースのOCRとSGLangでの高速LLM推論を同時に必要とする場合、環境が異なるため、2つの異なるSIEコンテナを起動する必要があります。

試す価値はあるか？

SIEは、独自のハードウェアまたはプライベートクラウドでパイプラインを構築しているチームにとって優れた候補です。1つのRAGシステムだけで5つの異なるコンテナで支えられたインフラを維持することに疲れているなら、このプロジェクトは多くの時間を節約します。

アーキテクチャがシンプルで、複雑なドキュメント処理やリランキングステージなしの1つの会話モデルだけで構成されているなら、SIEに切り替える意味はありません。そのシナリオでは、通常のvLLMまたはOllamaで十分です。