開発者、8GB VRAMでのEmbed、Rerank、およびZero-Shotモデルの提供に関するアーキテクチャのアドバイスを求める

問題の概要

開発者は、FastAPI経由で単一のDockerコンテナ内で実行されるローカルコーディングエージェント向けの統合ナレッジグラフ/RAGサービスを構築しています。システムは当初Windows（WSL）上では正常に動作していましたが、ネイティブLinux環境に移行したところ、ストレステスト下で深刻なメモリ制限問題が明らかになりました。

ハードウェアとモデルの制約

ハードウェア：

• 8GB VRAM（ノートPCGPU）
• 〜16GB システムRAM（Dockerの制限にすぐに達し、モデルが読み込まれると通常〜6GBしか空きがない）

モデルスタック：

• 埋め込み：nomic-ai/nomic-embed-text-v2-moe
• 再ランキング：BAAI/bge-reranker-base
• 分類：MoritzLaurer/ModernBERT-large-zeroshot-v2.0（テキストペアを4つの関係：依存関係、拡張、矛盾、無関係に分類するために使用）

技術的課題

開発者は、これらのモデルにコードチャンクと自然言語テキストを入力しており、可変長の長いシーケンスを処理する必要があるため、テキストを積極的に切り詰めることができません。

遭遇した具体的な問題：

• レイテンシー対OOM： torch.cuda.empty_cache()を使用してGPUをクリーンに保つと、ドライバーの同期によりリクエストごとに18〜20秒のレイテンシースパイクが発生します。これを削除すると、同時リクエストが発生した際にGPUが即座にOOMになります。
• システムRAMの爆発的増加（Linux Exit 137）： Hugging Faceのpipeline("zero-shot-classification")を使用すると、CPU RAMが大幅に肥大化しました。切り詰めを行わない場合、パイプラインはGPUに送信する前にメモリ内で巨大な組み合わせ行列を生成し、Linuxカーネルがコンテナを即座に強制終了させます。
• VRAMの急増： cudnn.benchmark = Trueがすべてのユニークなシーケンス長に対してワークスペースをキャッシュしていたため、ストレステスト中に数秒で3GBの空きVRAMが枯渇しました。

現在の実装

開発者は以下の回避策を備えた純粋なPython/FastAPIセットアップを構築しています：

• HFパイプラインを回避し、ModernBERT用の手動NLI推論ループを作成
• asyncio.Lock()を使用して強制的に逐次実行（一度に1つのモデルのみがGPUにアクセス）
• FastAPIのバックグラウンドタスクを介した確定的な解放（del inputs + gc.collect()）の使用

このアプローチは改善されていますが、3分間のストレステスト下では依然として不安定です。

コミュニティへの質問

開発者は以下の点についてアドバイスを求めています：

• モデルの代替案： 8GBの制約内に収まり、Zero-Shot NLIと再ランキングで高い精度を維持する、より小型で高速なモデル
• 事前構築済みアーキテクチャ： 以前はinfinity_embを検討しましたが、モデルの二重読み込みなしにカスタム4方向NLI分類ロジックを統合するのに苦労しました。TEI（Text Generation Inference）、TensorRT、またはエンコーダモデルに最適化された他のソリューションを検討中
• 提供戦略： 3つのトランスフォーマーモデルを単一のコンシューマーGPU上でホストし、互いのメモリを踏み合わないようにするための標準的な設計パターン