概要
SIE はオープンソースの推論サーバーおよび本番クラスターであり、統一された OpenAI 互換 API を通じて、検索、ドキュメント変換、構造化出力、コンテンツセーフティ、エージェントループなどのモデルサービスを提供します。100 以上の事前設定済みモデルのオンデマンドロードをサポートし、Kubernetes の本番デプロイメント設定も提供しています。
README プレビュー
\n\n\n \n \n\n\nSIE: Superlinked Inference Engine\n\nSelf-hosted inference for agents. Every open model your agents call, served from one cluster in your cloud.\n\n\n Docs |\n Quickstart |\n API Reference |\n Models\n\n\n[](LICENSE)\n[](https://pypi.org/project/sie-sdk/)\n[](https://github.com/superlinked/sie/stargazers)\n\n⭐ _Help us reach more developers and grow the SIE community. Star this repo!_\n\n\n\n## About\n\nSIE is an open-source inference engine that runs the models behind every agent task through one API: search and retrieval, document-to-markdown conversion, structured output, content safety, and the agent loop itself. It replaces the patchwork of a separate model server per task with one system that serves 100+ models, loading each on demand.\n\n- OpenAI-compatible API for drop-in migration: `/v1/embeddings`, `/v1/chat/completions`, `/v1/completions`, `/v1/responses`\n- Pre-configured model catalog: Stella, SPLADE, Qwen3, GLiNER, SigLIP, and more; embedding and retrieval models benchmarked on MTEB\n- Serves multiple models simultaneously with on-demand loading and LRU eviction\n- Ships Kubernetes and Helm deployment configs for the load-balancing gateway, KEDA autoscaling, and Grafana dashboards\n- Integrates with LangChain, LlamaIndex, Haystack, DSPy, CrewAI, Chroma, Qdrant, Weaviate, and LanceDB\n\n## Development\n\nInstall [mise](https://mise.jdx.dev/getting-started.html), then bootstrap the\nversioned Python, Rust, Node.js, and Helm toolchains from the repository root:\n\n```bash\n./tools/init.sh\n```\n\nThe common development checks and local server are available as mise tasks:\n\n```bash\nmise run test\nmise run lint\nmise run typecheck\nmise run serve\nmise run rust-check\nmise run rust-test\nmise run gateway-test\nmise run server-sidecar-test\n```\n\nThe Python workspace uses the committed root lock. Package membership is\nexplicit in `pyproject.toml`; a package joins the workspace only in the same\nchange that adds its complete source.
FAQ (5)
トラブル対応長さの異なる30秒を超える音声の同時文字起こしで発生するWhisperのHTTP 500エラーを修正する方法
これは、sie-serverが長尺のWhisperリクエストをバッチ処理する一方で、Transformersのpipelineのcollateが[128, 18110]や[128, 18593]のようなフレーム数の異なるlog-melテンソルを処理できないために発生します。transformers 4.57.6を使用したsie-server 0.9.0で、30秒を超える2つの録音が同じバッチ内で処理される場合に影響します。
即時の回避策：サーバー設定でWhisperのpipeline_batch_sizeを1に設定し、サーバーを再起動してください。これにより各録音が個別に処理され、失敗するcollateパスを回避できます。30秒以下のクリップは影響を受けません。
恒久的な修正：packages/sie_server/src/sie_server/adapters/whisper/adapter.pyで、短尺グループにはbatch_size=self._pipeline_batch_sizeを維持しつつ、長尺グループはbatch_size=1で、pipeline呼び出しごとに1件の録音として実行します。Transformersを直接使用する場合は、長さの異なる複数のアイテムを1つのバッチで渡すのではなく、長尺の音声アイテムごとにpipelineを個別に呼び出してください。
修正後、再生時間の異なる30秒を超える2つの録音は、1回のextract()呼び出しで文字起こし結果を返し、同時実行数4/8でもHTTP 500なしで完了するはずです。測定された長尺のスループットは実質的に変わりません。batch_size=1で同時実行数4の場合は約21.9音声秒/秒であるのに対し、デフォルト設定で同時実行数1の場合は22.3です。
トラブル対応X-Forwarded-Host を介して sie_mcp の OAuth issuer と token_endpoint がなりすまされる問題を修正するにはどうすればよいですか？
PR #292（コミット f5c4451）を含む sie_mcp リリースにアップグレードしてください。即時の回避策として、公開オリジンを明示的に固定し、X-Forwarded-Host と X-Forwarded-Proto が無視されるようにしてください：
export SIE_MCP_PUBLIC_URL=https://mcp.your-domain.exampleHelm の場合は、次のように設定してください：
mcpEdge:
publicUrl: "https://mcp.your-domain.example"
oauthEnabled: true修正後、SIE_MCP_PUBLIC_URL が未設定の場合、リクエストオリジンの導出はループバックホストまたは SIE_MCP_ALLOWED_HOSTS にリストされたホストに対してのみ許可されます。信頼されていないホストには、OAuth メタデータルートから HTTP 503 が返され、WWW-Authenticate チャレンジは送信されません。更新された Helm チャートでは、mcpEdge.publicUrl が空でエッジ Ingress が有効な場合、SIE_MCP_PUBLIC_URL=https://<mcpEdge.ingress.host> が自動的にレンダリングされます。リバースプロキシまたはロードバランサーが X-Forwarded-Host を上書き/サニタイズすることを確認し、それらのヘッダーが信頼できる場合を除き、ingress-nginx の use-forwarded-headers を有効にしないでください。
トラブル対応なぜDockerイメージのビルドでは、uv.lockでピン留めされたバージョンとは異なる依存関係がインストールされるのですか？
これは、イメージビルダーが resolve-deps を実行して各バンドルの範囲指定の依存関係指定子（例：gliner>=0.2.26,<1）をrequirementsファイルに書き出し、その後 pip install --target=/app/bundle-libs -r を実行したために発生しました。このコマンドはビルド時に範囲を最新のPyPIリリースへと解決し、CIがテストの基準としている uv.lock にピン留めされたバージョンを覆い隠していました。そのため、同じコミットの2つのビルドが異なるバージョンを同梱する可能性がありました。PR #653 と #802 で修正されました：バンドルイメージはビルド中に範囲を解決しなくなりました。代わりに、チェックインされたターゲットごとのロックファイルから、保存済みの依存関係クロージャーをインストールします。チェックインされた15個のターゲットロックは、リリース済みの11個のLinux amd64イメージすべてに加え、サポートされている4つのCPU arm64の組み合わせをカバーしています。明示的かつ文書化されたバンドル例外が適用される場合（例：transformers 5バンドル）を除き、パッケージはルートの uv.lock のピンを保持します。CIは古くなった、あるいは不整合のあるロックを拒否し、イメージビルドはインストールされた /app/bundle-libs のインベントリ（解決済みの pip freeze）を検証して保持するため、デプロイされたどのバージョンでも監査できます。これらの修正を含むリリースにアップグレードすると、ビルドが再現可能になります：同じコミットを2回ビルドしても、同一のバージョンがインストールされるようになりました。
トラブル対応アップグレード中に keda-apply Helm フックが exit 137 で OOMKilled される問題を修正するにはどうすればよいですか？
これは、keda-apply フックのメモリ制限が 256Mi にハードコードされているため、chart 0.7.2 で発生します。アップグレードでは既存の ScaledObject リソースを JSON として取得し、jq で処理するため、新規インストールよりも多くのメモリを使用します。設定可能なフックリソースを追加し、デフォルトの制限を 1Gi に引き上げる PR #268 を含む chart バージョンにアップグレードしてください。その後、例えば次のように設定します：
hooks:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 200m
memory: 1Gihelm upgrade <release> <chart> -f values.yaml で値を適用します。設定可能なリソースは、keda-apply、keda-cleanup、および KEDA ready フック Jobs に適用されます。古い chart での一時的な回避策として、upgrade.disableHooks: true を設定できますが、これは ScaledObject の reconciliation とヘルスチェックをスキップするため、推奨されません。Helm の post-renderers を使用してフック Jobs にパッチを適用することはできません。
トラブル対応シングルノードの /v1/embeddings レスポンスで、不正確またはラベル付けされていない prompt_tokens を修正するにはどうすればよいですか？
修正 fix(server): report measured embedding token usage（issue #566 の修正）を含むリリースにアップグレードしてください。シングルノードの OpenAI 互換ルートでは、サーバーがパイプラインのタイミング/使用量をそのまま渡すようになり、usage.prompt_tokens と usage.total_tokens は、利用可能な場合にワーカーの正確なトークン化後のカウントを使用します。測定されたカウントが存在しない場合は、OpenAI クライアントが usage オブジェクトを期待するため、以前の文字数推定（len(input) / 4、最小値 1）にフォールバックします。レスポンスには usage.sie_token_source も含まれ、測定されたカウントの場合は worker、フォールバックの場合は character_estimate に設定されます。アップグレード前の回避策として、正確なカウントを取得するにはネイティブの POST /v1/encode/{model} エンドポイントを使用するか、サービスをゲートウェイの背後に配置してください。ゲートウェイはすでに sie_token_source を worker または character_estimate として報告しています。