背景

Google Cloud Next Tokyoで、プロンプトを受け付けて、Self-Deployモデルの場合、Cold Startが課題になるため、Cloud Run Woker poolで受けて、非同期で処理させることセッションで聞きました。

Muse-Glimmer-30B

Denseモデル。パラメータ29.78B(約30B級)

https://developer.meta.com/ai/models/muse-glimmer

構成

フロントエンド、Next.js (AG-UI)、dispatherでCloud pubsubで受け取ったものを、vLLM推論させるCloud Run GPUに中立させて、Firestoreに結果を書き込んで、フロントに返すアーキテクチャ

Work poolのCloud Runは、idleにもスケール0に自動ではしてくれない。Pub/Subキュー深度連動で0〜N自動スケール(KEDAベースのGoogle製OSSツール)、手動でスケールなりする必要がある

検証時ハマった点

初回ロード時のコールドスタート。GKE Pod Snapshotでキャッシュを使えるが、初期ロードがネックになる。セッション中でもプロンプトは受け付けて、非同期でCloud Run GPUに推論させて、回答を返していました。GKE Pod Snapshotはノード以外にクラスタ内部にキャッシュ持っているので、ノードインスタンスが入れ替わってもキャッシュが消えることはない。

RTX Pro 6000クォータ緩和

自プロジェクトだとデフォルトクォータが0なので、緩和が必要。バースト用途はないので、2でクォータ緩和させました。

ネットワーク

Cloud Run公式ベストプラクティス(GPU推論向け)が、GCS FUSEは、VPC Driect Egress + Google Private Accessとなっている。

GoogleFuse steel問題

Muse-Gimmer-30Bのモデルデータだけで50GBになるので、イメージに焼き付けるのは現実的ではない。モデルデータはGCSに保存し、Cloud Run からマウトするのがユースケースの１つとなっている。GCSに保存されているModelデータを初期時読み込みますが、並列読み込みだと16-17分で通信が止まる(steel)でCloud Run Serviceタイムアウトでエラーになる。GCSのシーケンシャル読み込みが最適だが、8並列でモデルデータを読み込むと逆効果（–safetensors-load-strategy=prefetch）

Muse-Gimmer-30B parameter

Muse-Glimmer-30Bはチャネル形式の特殊出力フォーマットを使うモデルで、これらのパーサ指定なしでは生成内容そのものが壊れます

https://recipes.vllm.ai/meta-models/Muse-Glimmer-30B

--enable-auto-tool-choice
  --tool-call-parser=muse_glimmer
  --reasoning-parser=muse_glimmer
  --generation-config=auto

費用感

RTX Pro 6000　3.51時間(210.7分)　756.11円

まとめ

Cloud Run GPUの場合、コールドスタートは避けられないので、非同期で行うが推奨されそう。ある程度のモデルでしたら、Cloud Run GPUでも使用感問題ない認識。