LLMの推論速度はGPUの性能だけで決まるわけではありません。大規模にモデルを配信する現場では、トークナイズやツール呼び出しといったCPU処理がボトルネックになり、高価なGPUが待機状態に陥るケースがあります。

この記事でわかること：

  • LLM配信でCPU処理がボトルネックになる理由
  • Shepherd Model Gateway（SMG）の仕組みと主要機能
  • 導入方法と対応バックエンド

LLM配信におけるCPU処理のボトルネック

GitHub - lightseekorg/smg: Engine-agnostic LLM gateway in Rust. Full OpenAI & Anthropic API compatibility across SGLang, vLLM, TRT-LLM, OpenAI, Gemini & more. Industry-first gRPC pipeline, KV cache-aware routing, chat history, tokenization caching, Responses API, embeddings, WASM plugins, MCP, and multi-tenant auth.
Engine-agnostic LLM gateway in Rust. Full OpenAI & Anthropic API compatibility across SGLang, vLLM, TRT-LLM, OpenAI,…
GitHub

vLLMやSGLangなどの推論エンジンは、内部でRustやC++製のトークナイザライブラリを使っています。しかし、それらの呼び出しはPythonを経由するため、GIL（Global Interpreter Lock）の制約を受けます。小規模な配信では問題になりませんが、大規模なprefill-decode分離構成やエキスパート並列処理では事情が異なります。GPUが高速に処理を終えても、CPU側のトークナイズがシングルスレッドで詰まり、数十万ドル相当のGPUがアイドル状態で入力を待つことになります。

LightSeek Foundationが開発したShepherd Model Gateway（SMG）は、この問題に対する解答です。GPUが不要なCPU処理をすべてRust製のゲートウェイ層に移し、推論エンジンとはgRPCで通信します。PythonのGILから完全に解放された設計です。

SMGのアーキテクチャ

SMGの設計原則は明快です。GPUにはテンソル演算だけを担当させ、それ以外はすべて専用のゲートウェイ層で処理します。具体的に移管される処理は以下のとおりです。

  • トークナイズ・デトークナイズ: Rustでネイティブ実行し、L0（完全一致）とL1（プレフィックス対応）の2段キャッシュで高速化
  • 推論結果のパース: ストリーミング中にリアルタイムで推論ブロックやファンクションコールを抽出。DeepSeek-R1、Qwen3、Llama-4など15以上のモデルファミリーに対応
  • マルチモーダル前処理: Hugging Faceの画像プロセッサをPythonからRustに書き直し、前処理済みテンソルをgRPCで直接転送
  • MCPツール実行: 認証対応のコネクションプール、並行バッチ実行、自動再接続を備えたMCPオーケストレーション

gRPCプロトコルはsmg-grpc-protoとしてPyPIで公開されており、vLLM（PR #36169）やNVIDIA TensorRT-LLMにも採用されています。ゲートウェイとエンジンのインターフェースが明確に分離されているため、片方だけを独立してアップグレードできます。

8種類のルーティングポリシー

SMGはリクエストの振り分けに8つのポリシーを用意しています。中でも注目はcache-awareルーティングです。各推論エンジンのKVキャッシュ状態をリアルタイムで監視し、プレフィックスの再利用率が最も高いワーカーにリクエストを送ります。

PyTorch公式ブログで公開されたベンチマーク結果では、Llamaの8レプリカ構成でTTFT（最初のトークンまでの時間）の平均が23%、p99が28%短縮されました。また、prefill-decode分離構成ではTTFTが20〜30%改善しています。

gRPC vs HTTPのベンチマーク

SMGのgRPCパイプラインがHTTPと比べてどの程度有利かを、NVIDIA H100上でGenAI-Perfを使って検証した結果がPyTorch公式ブログで報告されています。8モデル、2ランタイム、5トラフィックシナリオ、9段階の同時接続数で合計1,082の比較ポイントを測定しています。

同時接続数1ではgRPCとHTTPの差はほぼ誤差範囲です。しかし同時接続数256では、gRPCが約8%高いスループットを記録しました。HTTP/JSONのシリアライズコストはプロンプト長に比例して増加するため、長いコンテキストほどgRPCの優位性が際立ちます。入力7,800トークンのシナリオでは全モデル平均で12.2%のスループット向上が確認されています。

最も劇的な結果はLlama-3.3-70B-FP8です。FP8量子化によりGPUが高速化した分、HTTPのシリアライズがボトルネックとして顕在化し、gRPCは最大3.5倍の出力スループット（1,150 tok/s vs 327 tok/s）を達成しました。

対応バックエンドとAPI

SMGは1つのゲートウェイから複数のバックエンドに同時にルーティングできます。セルフホスト型はvLLM、SGLang、TensorRT-LLM、Ollamaに対応し、クラウドプロバイダーはOpenAI、Anthropic、Google Gemini、AWS Bedrock、Azure OpenAIをサポートします。

API面では、OpenAI Chat/Completions、Responses API、Anthropic Messages API、Gemini Interactions API、Realtime API（WebSocket/WebRTC）の5つをネイティブ実装しています。単なる変換レイヤーではなく、各プロトコルの仕様に忠実な実装です。たとえばAnthropic Messages APIではthinkingブロックをエンドツーエンドで保持します。

導入方法

インストールは3通りから選べます。

docker pull lightseekorg/smg:latest
pip install smg
cargo install smg

起動は1行で完了します。

smg --worker-urls http://localhost:8000

複数ワーカーでcache-awareルーティングを使う場合は以下のとおりです。

smg --worker-urls http://gpu1:8000 http://gpu2:8000 --policy cache_aware

リクエストはOpenAI互換のエンドポイントに送るだけです。Python 3.8〜3.14、Linux/Windows/macOS、x86/ARMに対応しています。ライセンスはApache 2.0です。

本番環境での採用実績

SMGはすでにGoogle Cloud Platform、Oracle Cloud Infrastructure、Alibaba Cloud、TogetherAIの本番環境で稼働しています。スタートアップからハイパースケーラーまで、幅広い規模で採用されています。

まとめ

LLM推論の高速化というとGPUやモデルの最適化に注目が集まりがちですが、SMGはその手前のCPU処理に切り込んだプロジェクトです。NVIDIA DynamoやKubernetesネイティブのllm-dとは異なるレイヤーで動作するため、これらと組み合わせて使えます。大規模なLLM配信基盤を構築・運用している方にとって、検討する価値のあるツールです。