Azure Blob StorageとRun:AI Model StreamerでLLMコールドスタートを最大6倍高速化する設定と注意点

Azure StorageでLLM推論基盤を運用している場合、今回のポイントは「モデルの重みをローカルディスクへ一度コピーしてからGPUへ読む」流れを見直せるようになったことです。Run:AI Model Streamerを使うと、Azure Blob Storage上のモデル重みをaz:// URIで参照し、CPUメモリ経由でGPUメモリへストリーミングできます。Microsoft公式ブログでは、vLLMの既定ローダーと比べてモデル読み込みが最大約6.1倍高速化したベンチマークが示されています。(Microsoft for Developers)

特に影響が大きいのは、Copilot風アプリ、社内LLM、RAG、マルチテナント推論、オートスケール前提のGPU基盤を運用しているチームです。この記事では、2026年5月20日時点で確認できる公式情報をもとに、Azure Blob StorageとRun:AI Model Streamerで何が変わるのか、管理者・開発者が確認すべき設定、移行時の注意点を実務目線で整理します。

Azure StorageのAI基盤向け更新で何が変わるのか

今回の更新は、Azure Blob Storageそのものに新しい管理画面機能が追加されたというより、Azure Blob Storageに置いたLLMのモデル重みを、vLLMやSGLangから直接ストリーミングして読み込める運用パターンが公式に紹介されたことが重要です。

従来の多くの推論環境では、コールドスタート時に次のような流れが発生します。

従来の流れ	何が問題になりやすいか
Azure Blob Storageからモデルファイルをローカルディスクへコピー	GPUは確保済みなのに推論に使えない時間が発生する
ローカルディスクからGPUメモリへ読み込み	ディスクI/Oがボトルネックになりやすい
読み込み完了後にレプリカがリクエスト受付を開始	トラフィック急増時にキューやタイムアウトが増える

Run:AI Model Streamerを使う構成では、モデル重みのローカルディスクへのステージングを避け、Azure Blob StorageからCPUメモリを経由してGPUメモリへ読み込みます。Microsoftの説明では、このディスク経由の余分なコピーを省くことで、コールドスタート時の待ち時間を短縮できるとされています。(Microsoft for Developers)

ここで誤解しないでおきたいのは、これは「推論そのものが6倍速くなる」という話ではない点です。高速化の対象は、主にモデル読み込み時間です。つまり、オートスケール、再起動、ローリングデプロイ、Spot VMの回収、モデル切り替えなどで発生する「GPUを確保したのにまだサービスできない時間」を短くするための技術です。

LLMのコールドスタートが問題になる理由

LLM推論基盤では、GPU料金だけでなく、コールドスタート中の待ち時間も大きなコストになります。GPUが割り当てられていても、モデルが読み込まれるまではリクエストを処理できません。

Microsoft公式ブログでは、従来構成ではコールドスタート時に「オブジェクトストレージからローカルディスクへモデル重みを取得し、その後GPUメモリへ読み込む」という順序になるため、GPUがその間アイドル状態になると説明しています。(Microsoft for Developers)

実務では、次のような場面で問題が表面化します。

発生シーン	起こりやすい影響
アクセス急増でレプリカを追加	追加レプリカが起動する前に既存レプリカへ負荷が集中する
ローリングデプロイ	各レプリカのモデル読み込み待ちで展開時間が伸びる
Spot VMの回収	代替ノードの準備に時間がかかり、処理能力が一時的に落ちる
複数モデルのオンデマンド切り替え	モデルスワップのたびに待ち時間が発生する
大規模モデルの初回起動	数十GBから数百GBの重み読み込みがボトルネックになる

特に、ユーザー向けチャットボットや業務アプリにLLMを組み込んでいる場合、数分の起動待ちはUXにもSLAにも影響します。リクエストが30秒から60秒程度でタイムアウトする構成では、コールドスタート中にエラーや再試行が増え、さらに負荷が高まることがあります。

ベンチマークでは最大約6.1倍の読み込み高速化

Microsoft公式ブログでは、Standard_ND96isr_H100_v5 VM、8基のNVIDIA H100 80GB、80Gbpsネットワーク、同一リージョンのPremium block blob storage accountという条件で、vLLMの既定ローダーとRun:AI Model Streamerを比較しています。(Microsoft for Developers)

モデル	サイズ	Run:AI Streamer	既定vLLM Loader	高速化
Meta-Llama-3.1-8B-Instruct	14.99GiB	3.61秒前後	15.48秒前後	約4.3倍
GPT-OSS-120B	60.8GiB	12.76秒前後	42.29秒前後	約3.3倍
Qwen3.5-122B-A10B	232.8GiB	37.14秒前後	225.57秒前後	約6.1倍

この結果だけを見ると「すぐ本番導入すべき」と感じるかもしれません。しかし、ベンチマークは特定のVM、ネットワーク、ストレージ、モデル形式での結果です。自社環境では、GPU VMのネットワーク帯域、Blob Storageの種類、リージョン、同時起動数、モデルファイルの分割状況、認証方式によって結果が変わります。

実務での判断基準は、単純な倍率ではなく次の3点です。

判断ポイント	確認すべき内容
現在のコールドスタート時間	モデル読み込みに何秒、コンテナ起動に何秒、ヘルスチェック完了に何秒か
GPUアイドル時間	GPUが割り当て済みなのに推論受付できない時間がどれくらいあるか
オートスケール周期との関係	レプリカ追加が次のスケール判断までに間に合うか

たとえば、現在のモデル読み込みが10秒程度で、サービス全体のボトルネックがプロンプト処理や外部API呼び出しにあるなら、効果は限定的です。一方、70B以上のモデルや複数GPU構成で、モデル読み込みに数分かかっている環境では、検証する価値が高い構成です。

対象になるサービスと技術スタック

今回の構成で中心になるのはAzure Blob Storageです。モデルファイルをBlobコンテナーに保存し、vLLMまたはSGLangからaz://<container>/<path>形式で参照します。Microsoft公式ブログでは、vLLMとSGLangの両方がAzure Blob Storageからの直接ストリーミングに対応すると説明されています。(Microsoft for Developers)

項目	内容
ストレージ	Azure Blob Storage
モデル形式	SafeTensors形式が前提
推論エンジン	vLLM、SGLang
URI形式	az://<container>/<path>
認証	DefaultAzureCredentialを利用
主な用途	LLM推論のコールドスタート短縮、オートスケール改善、GPUアイドル時間削減

vLLM公式ドキュメントでも、Azure Blob Storage上のモデルをAZURE_STORAGE_ACCOUNT_NAME=<account>とaz://<container>/<model-path>で指定し、--load-format runai_streamerを付けて起動する例が掲載されています。認証にはDefaultAzureCredentialが使われ、az login、マネージドID、環境変数などの方法に対応します。(vLLM)

SGLangのドキュメントでも、オブジェクトストレージの対応先としてAzure Blobのaz://some-azure-container/path/が示されています。(docs.sglang.io)

管理者が確認すべきAzure Blob Storage設定

Run:AI Model Streamerを導入する前に、Azure管理者はストレージ、認証、ネットワーク、監視を確認する必要があります。アプリ側のコマンドを変えるだけでは、本番運用で期待通りに動かないことがあります。

ストレージアカウントとコンテナーの配置

まず確認すべきは、GPUを実行するVM、AKS、Azure Machine Learningなどの計算リソースと、Azure Blob Storageのリージョンです。

Azure Blob Storageのパフォーマンスチェックリストでは、レイテンシ削減のために、ストレージアカウントをクライアントに近いリージョンに配置することが推奨されています。高トランザクションや低レイテンシが必要な場合はPremium block blob storage accountの検討も推奨されています。(Microsoft Learn)

実務では、次のように整理すると判断しやすくなります。

確認項目	推奨される考え方
GPUノードとBlobのリージョン	原則として同一リージョンに置く
本番と検証のストレージ	誤削除や権限混在を避けるため分離する
モデルごとの配置	モデル名、バージョン、量子化方式ごとにパスを分ける
Premium利用	大規模モデル、頻繁なスケールアウト、低レイテンシ要件がある場合に検証する

モデルファイルは、たとえば次のようなパス設計にしておくと、切り戻しやバージョン管理がしやすくなります。

az://llm-models/models/llama-3-1-8b-instruct/v1/
az://llm-models/models/llama-3-1-8b-instruct/v2/
az://llm-models/models/qwen-large/prod/
az://llm-models/models/qwen-large/canary/

避けたいのは、latestのような曖昧なパスだけで本番運用することです。障害時に「どの重みを読み込んだのか」が追跡しづらくなります。

認証はマネージドIDとRBACを基本にする

Run:AI Model StreamerのAzure Blob Storageアクセスでは、DefaultAzureCredentialが使われます。Microsoft公式ブログでは、az login、マネージドID、AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_CLIENT_SECRETなどの環境変数に対応し、AKS、Azure ML、VMのマネージドIDで利用できると説明されています。(Microsoft for Developers)

本番環境では、接続文字列やアカウントキーをコンテナに埋め込むのではなく、マネージドIDを使う構成を基本にしてください。Microsoft Learnでも、Blob StorageへのアクセスではMicrosoft Entra IDとマネージドIDを使う認可が推奨され、BlobデータへのアクセスにはAzure RBACのデータロール割り当てが必要と説明されています。(Microsoft Learn)

読み取りだけであれば、通常は推論実行主体にStorage Blob Data Readerを付与するのが最小権限に近い選択です。モデルをアップロードするCI/CDや管理者には、必要に応じてStorage Blob Data Contributorを付与します。

対象	推奨ロール例	理由
推論サーバーのマネージドID	Storage Blob Data Reader	モデル重みの読み取りだけに限定できる
モデルアップロード用CI/CD	Storage Blob Data Contributor	モデルの追加・更新・削除が必要な場合
運用管理者	必要最小限の管理ロールとデータロール	管理権限とデータアクセス権限を混同しない

注意したいのは、OwnerやContributorなどの管理ロールだけでは、Microsoft Entra ID経由のBlobデータ読み取り権限にならない場合があることです。Blobデータを読むには、データアクセス用のAzure RBACロールを明示的に割り当てる必要があります。(Microsoft Learn)

ネットワーク制限とファイアウォールを確認する

ストレージアカウントでネットワーク制限を有効にしている場合、権限が正しくても403エラーになることがあります。特に、AKS、Azure ML、VM、NAT Gateway、Private Endpointを組み合わせている環境では、実際にBlobへ出ていく経路を確認してください。

確認すべき項目は次の通りです。

項目	確認内容
Storage firewall	GPUノードまたはVNetからアクセスできるか
Private Endpoint	DNS解決がプライベートIPを向いているか
Managed Identity	実行環境で有効化されているか
RBAC伝播	ロール付与直後にテストして失敗していないか
ログ	Storageのメトリック、失敗リクエスト、認証エラーを確認できるか

Azure RBACのロール割り当ては反映に時間がかかる場合があります。Microsoft Learnでは、Azureロール割り当ての伝播に時間がかかることがあると説明されています。(Microsoft Learn) 本番切り替え直前に権限を付けるのではなく、事前に割り当てて疎通テストを済ませておくべきです。

開発者が確認すべき実装ポイント

開発者側で重要なのは、モデル形式、起動コマンド、チューニングパラメーター、失敗時の切り戻しです。

SafeTensors形式のモデルを用意する

Microsoft公式ブログでは、ストリーミング前提としてAzure Blob StorageコンテナーにSafeTensors形式のモデル重みが必要であり、.safetensorsファイルが含まれていることを確認するよう説明されています。(Microsoft for Developers)

Hugging Faceなどから取得したモデルでも、古い形式や独自形式の重みだけでは使えない可能性があります。移行前に、次の観点でモデルを棚卸ししてください。

確認項目	見るポイント
ファイル形式	.safetensorsが存在するか
tokenizer/config	メタデータやトークナイザー設定が揃っているか
モデルサイズ	GPUメモリ、CPUメモリ、ネットワーク帯域に収まるか
ライセンス	商用利用、社内利用、再配布条件を満たすか
バージョン	本番で使う重みを固定できるか

単にファイルをBlobへ置くだけでなく、推論エンジンが期待するディレクトリ構造を保ったままアップロードすることが重要です。

vLLMでAzure Blob Storageから読み込む

vLLMでは、Run:AI対応のオプション依存関係をインストールし、--load-format runai_streamerを指定します。vLLM公式ドキュメントにも、Azure Blob Storageのモデルをaz://で指定する例が掲載されています。(vLLM)

uv pip install vllm[runai]

export AZURE_STORAGE_ACCOUNT_NAME="<your_account_name>"

vllm serve az://<your-container>/models/llama-3.1-8b \
  --load-format runai_streamer

複数GPUで使う場合は、分散ストリーミングと並列度の調整を検討します。

vllm serve az://<your-container>/models/llama-3.1-405b \
  --load-format runai_streamer \
  --tensor-parallel-size 8 \
  --model-loader-extra-config '{"distributed": true, "concurrency": 32}'

concurrencyは並列読み込みの度合いに関係します。Microsoft公式ブログでは、32や場合によって64に上げると高スループットNICをより活用できる場合があると説明されています。(Microsoft for Developers) ただし、値を上げれば必ず速くなるわけではありません。ストレージ側のスロットリング、CPUメモリ、ネットワーク、同時起動するレプリカ数も合わせて観察する必要があります。

SGLangでAzure Blob Storageから読み込む

SGLangでも、Run:AI対応の依存関係を入れ、--model-pathにaz://を指定します。Microsoft公式ブログでは、SGLangはメタデータファイルをローカルキャッシュにダウンロードし、モデル重みをAzure Blob StorageからGPUメモリへオンデマンドにストリーミングする2段階のアプローチだと説明されています。(Microsoft for Developers)

uv pip install "sglang[runai]" --prerelease=allow

export AZURE_STORAGE_ACCOUNT_NAME="<your_account_name>"

python -m sglang.launch_server \
  --model-path az://<your-container>/models/llama-3.1-8b \
  --load-format runai_streamer \
  --served-model-name llama-3.1-8b

複数GPU構成では、次のように--tpと追加設定を組み合わせます。

python -m sglang.launch_server \
  --model-path az://<your-container>/models/llama-3.1-405b \
  --load-format runai_streamer \
  --tp 8 \
  --model-loader-extra-config '{"distributed": true, "concurrency": 32}'

SGLangのドキュメントでは、Azure Blobを含むオブジェクトストレージURIがサポート対象として示されています。(docs.sglang.io) ただし、バージョンやインストール方法は変わる可能性があるため、導入時は必ず利用中のSGLangドキュメントとリリースノートを確認してください。

チューニングで見るべき設定

Run:AI Model Streamerには、読み込み性能やCPUメモリ使用量に関わる設定があります。Microsoft公式ブログでは、RUNAI_STREAMER_CONCURRENCYとRUNAI_STREAMER_MEMORY_LIMITが紹介されています。(Microsoft for Developers)

設定	役割	実務での見方
concurrency	並列I/O数、読み込みスレッド数を調整	ネットワーク帯域を使い切れていない場合に上げて検証
distributed	分散ストリーミングを有効化	複数GPU、テンソル並列構成で検証
memory_limit / RUNAI_STREAMER_MEMORY_LIMIT	CPUメモリバッファの上限を制御	CPUメモリ不足やOOMを防ぐために調整
AZURE_STORAGE_ACCOUNT_NAME	Azure Storageアカウント名を指定	az:// URIにはアカウント名を含めないため必須

Run:AI Model Streamerのドキュメントでは、RUNAI_STREAMER_CONCURRENCYで並列スレッド数を制御できると説明されています。また、CPUメモリバッファはRUNAI_STREAMER_MEMORY_LIMITで制御でき、最小値や特定バイト数を指定する方法も示されています。(GitHub)

実務では、最初から高い値にするのではなく、次のように段階的に検証します。

ステップ	実施内容
まず既定値で測る	現在のローダー、Run:AI Streamer既定値の読み込み時間を比較
concurrencyを上げる	8、16、32、64などで読み込み時間とエラー率を見る
CPUメモリを見る	コンテナやPodのメモリ上限に近づいていないか確認
同時起動で測る	1レプリカだけでなく、スケールアウト時の同時読み込みを再現
Storageメトリックを見る	スロットリング、レイテンシ、エラー、帯域使用率を確認

単体テストで速くても、10レプリカが同時にモデルを読み込むとBlob Storage、ネットワーク、NAT、Private Endpoint、ノード側CPUメモリのいずれかが詰まることがあります。本番に近い同時起動テストを必ず行ってください。

移行前に確認すべきチェックリスト

既存のLLM推論基盤からRun:AI Model Streamer構成へ移行する場合は、いきなり本番のローダーを置き換えず、段階的に検証します。

分類	チェック項目	失敗しやすいポイント
モデル	.safetensors形式で保存されているか	.binのみで構成されている
配置	Blobコンテナーとパスが整理されているか	バージョン不明のモデルを上書きする
認証	マネージドIDにBlobデータロールがあるか	管理ロールだけ付けてデータ読み取りできない
ネットワーク	GPU実行環境からBlobへ到達できるか	Private EndpointのDNS設定漏れ
起動設定	AZURE_STORAGE_ACCOUNT_NAMEが設定されているか	az://にアカウント名を含めようとする
性能	既存ローダーとの比較を取ったか	体感だけで速い・遅いを判断する
切り戻し	従来ローダーへ戻す手順があるか	障害時に起動方法を戻せない
監視	読み込み時間、403、503、メモリ使用量を見ているか	推論レイテンシだけ監視している

移行時のおすすめは、まず小さいモデルで疎通を確認し、次に本番に近い大規模モデルで読み込み時間を比較する流れです。最後に、同時スケールアウト、ローリングデプロイ、ノード再起動を再現して、運用イベント時の挙動を見ます。

本番展開で注意すべき落とし穴

コールドスタートだけ速くしても全体の起動時間は短くならない場合がある

Run:AI Model Streamerが短縮するのは主にモデル重みの読み込みです。コンテナイメージのPull、Python依存関係の初期化、GPUドライバーやランタイム初期化、ヘルスチェック待ち、ロードバランサー登録に時間がかかっている場合、全体の改善幅は限定されます。

そのため、計測は次のように分けて行います。

計測対象	例
コンテナ起動時間	Pod作成からプロセス開始まで
モデル読み込み時間	serveコマンド開始からモデルロード完了まで
ヘルスチェック完了時間	Readyになるまで
初回リクエスト成功時間	実際に推論APIが成功するまで

モデル読み込みだけを見て「37秒で起動した」と判断すると、実際のユーザー受付開始までの時間を見誤ります。

Blob Storageの性能は無限ではない

Azure Blob Storageは大規模なオブジェクトストレージですが、アカウント、パーティション、ネットワーク、アクセスパターンには性能目標があります。Microsoft Learnでは、Blob Storageのスケーラビリティとパフォーマンス目標はワークロード、アクセスパターン、オブジェクトサイズなどに依存し、限界に近づくと503や500が返る可能性があると説明されています。(Microsoft Learn)

大量のGPUレプリカが同じモデルを同時に読む環境では、次のような設計を検討します。

課題	対策例
同時起動で帯域が詰まる	スケールアウトのバーストを制御する
複数リージョンから読む	リージョンごとにモデルを複製する
本番と検証が同じBlobを読む	ストレージアカウントやコンテナーを分ける
503やタイムアウトが出る	並列度を下げる、リトライ、バックオフ、Premium検証

「Blobに置けばどこからでも高速に読める」と単純化せず、GPU基盤と同じリージョンに置く、監視する、同時起動を制御する、という基本を押さえる必要があります。

concurrencyを上げすぎると逆効果になることがある

concurrencyを上げると、読み込みが速くなる可能性があります。しかし、CPUメモリ、NIC、ストレージアカウント、Private Endpoint、NAT、Pod数などの制約にぶつかると、レイテンシ悪化やエラー増加につながります。

本番では、最速値ではなく安定して再現できる値を採用してください。ベンチマークで一度だけ速かった設定より、5回、10回実行してばらつきが小さい設定のほうが運用には向いています。

モデルの上書き運用は避ける

Blob上の同じパスに新しいモデルを上書きすると、起動中のレプリカと新規レプリカで読み込む内容が揺れる可能性があります。モデル更新は、原則としてバージョン付きパスにアップロードし、推論サーバーの設定を切り替える方式が安全です。

悪い例:
az://llm-models/models/chat-model/latest/

良い例:
az://llm-models/models/chat-model/2026-05-20/
az://llm-models/models/chat-model/2026-06-01/

切り戻しが必要になった場合も、旧バージョンのパスへ戻すだけで済みます。

どの環境で導入効果が大きいか

Run:AI Model Streamerは、すべてのAzure Storage利用者に必要な機能ではありません。導入効果が大きいのは、LLM推論で「モデル読み込み」が明確なボトルネックになっている環境です。

環境	導入優先度	理由
70B以上など大規模モデルを使う推論基盤	高	モデル重みの読み込み時間が長くなりやすい
オートスケールでGPUレプリカを増減する環境	高	追加レプリカの立ち上がりを早める価値が大きい
ローリングデプロイが長時間化している環境	高	各レプリカの待ち時間短縮が展開時間に効く
小規模モデルを常時1台で動かす環境	中〜低	コールドスタート頻度が低いと効果が限定的
CPU推論中心の環境	低	GPUメモリへの高速ロードの恩恵が小さい
既にローカルNVMeへ事前配置している環境	要検証	運用コスト削減と速度のどちらを優先するかで判断

特に、夜間や週末にGPUを縮退し、アクセス時に再びスケールアウトするような構成では、GPUアイドル時間の削減がコストに直結します。逆に、常に固定台数で稼働し、再起動が少ない環境では、導入メリットより運用変更のコストが大きくなる可能性があります。

管理者と開発者の役割分担

この構成は、ストレージ管理者だけでも、アプリ開発者だけでも完結しません。責任範囲を分けて進めると、移行時のトラブルを減らせます。

役割	主な確認事項
Azure管理者	Storageアカウント、RBAC、マネージドID、ネットワーク、監視
MLOps担当	モデルのアップロード、バージョン管理、検証環境、本番切り替え
アプリ開発者	vLLM/SGLangの起動設定、ローダー変更、ヘルスチェック
SRE/インフラ担当	オートスケール、ローリングデプロイ、障害時の切り戻し
セキュリティ担当	最小権限、アカウントキー不使用、監査ログ、モデルアクセス制御

実務では、最初に「モデル読み込み時間を何秒以内にしたいか」を決めておくと、検証が進めやすくなります。たとえば「233GiB級モデルを1分以内にReadyへ近づける」「ローリングデプロイ時間を半分にする」「アクセス急増時のGPUアイドル時間を削る」といった目標です。

導入手順の実践例

以下は、既存のvLLM構成を前提にした移行の流れです。

手順	作業	確認ポイント
1	既存のモデル読み込み時間を測る	現在のボトルネックを数値化する
2	SafeTensorsモデルをBlobへアップロード	ディレクトリ構造を保つ
3	推論環境のマネージドIDにBlob読み取り権限を付与	Storage Blob Data Readerを最小範囲で割り当てる
4	AZURE_STORAGE_ACCOUNT_NAMEを設定	Pod、VM、ジョブ定義に環境変数を追加
5	--load-format runai_streamerで起動	小規模モデルで疎通を確認
6	大規模モデルで読み込み時間を比較	既定ローダーとの差を見る
7	concurrencyとdistributedを調整	帯域、メモリ、エラー率を監視
8	カナリア展開	一部レプリカだけ新方式にする
9	本番展開	切り戻し手順を残したまま段階的に拡大

この順序で進めると、「起動コマンドは正しいが認証で失敗する」「単体では速いが同時起動で遅い」「メモリ制限で落ちる」といった問題を早い段階で切り分けられます。

まとめ：まずはモデル読み込み時間とGPUアイドル時間を測る

Azure Blob StorageとRun:AI Model Streamerの組み合わせは、LLM推論のコールドスタート対策として有力な選択肢です。従来のようにモデル重みをローカルディスクへコピーしてからGPUへ読むのではなく、Azure Blob Storageから直接ストリーミングすることで、特に大規模モデルの起動時間短縮が期待できます。

ただし、導入前に見るべきポイントは明確です。

まず確認すること	理由
現在のモデル読み込み時間	本当にローダーがボトルネックか判断するため
モデル形式	SafeTensorsでなければ利用できない可能性があるため
Blob Storageの配置	リージョンやネットワークが性能に影響するため
認証とRBAC	マネージドIDとデータロールが必要なため
同時起動時の挙動	本番のオートスケールでは単体性能だけでは足りないため
切り戻し方法	新ローダーで障害が出た場合に戻せるようにするため

次に取るべき行動は、既存環境で「コンテナ起動」「モデル読み込み」「Ready到達」「初回推論成功」までの時間を分解して測ることです。そのうえで、Azure Blob Storage上のSafeTensorsモデルを使い、vLLMまたはSGLangでRun:AI Model Streamerを小さく検証してください。読み込み時間が大きく短縮し、同時起動でも安定するなら、本番展開に進む価値があります。