Ollamaコミュニティ、2モデル同時ロード時のクラッシュを報告　Qwen3-VLの画像エンコード段階でGPU割り当てエラー

Ollamaコミュニティは10月6日、複数モデルの推論に関する障害を報告した。別の大型モデルがロードされた状態で qwen3-vl:8b が画像を処理すると、基盤の llama-server が約45秒の間に3回連続でクラッシュし、4回目の起動で同じリクエストを正常に完了した。確認時点でissueは未解決のままで、関連する修正は記載されていない。元の報告

この事例の環境はOllama 0.33.3、Arch Linux、各24 GBのVRAMを搭載したRTX 3090 2基。先にロードされた27Bモデルは、それぞれ約12 GBと16 GBのVRAMを使用していた。その後、画像を含むQwen3-VLのリクエストによって2つ目の推論プロセスが起動した。2回の失敗はアドレス0の読み取りによるセグメンテーション違反として記録され、もう1回ではCUDAのリソース割り当て失敗が明示された。スタックトレースは clip_encode を経由し、最終的に ggml_gallocr_alloc_graph に至っており、調査対象を画像エンコード計算グラフの割り当て段階に絞る手がかりとなっている。エラーログとスタックトレース

報告者は、VRAMの逼迫によってバッファーの割り当てに失敗し、その後のコードがヌルポインターをデリファレンスした可能性を推測している。しかし、投稿者は障害が発生した命令を逆アセンブルしておらず、これは検証待ちの仮説にとどまる。同じリクエストが再起動後に成功したことも、根本原因の証明にはならず、ほかの実行環境要因を排除するものでもない。現在の証拠は単一環境から得られたものであり、すべてのQwen3-VL環境で発生する不具合として一般化することはできない。事例の制約

技術面で注目すべき点は、複数モデルのスケジューリングが画像エンコード中のリソース需要にも対応できるかどうかだ。Ollamaの公式ドキュメントによると、新しいモデルをロードするためのメモリが不足している場合、リクエストはキューに入り、既存モデルがアンロードされるまで待機する。また、GPUにモデルを同時ロードするには、利用可能なVRAMの条件を満たす必要がある。このドキュメントは期待される動作を比較する材料にはなるが、本件がスケジューリング規則に違反していることや、不具合の箇所を確認するものではない。公式の並行処理に関する説明

テキストモデルとビジョンモデルを運用するエンジニアは、まず単一モデルと2モデルの各条件を比較し、画像サイズ、コンテキスト設定、GPUごとのVRAM使用量を記録するとよい。また、OLLAMA_MAX_LOADED_MODELS で同時ロード数を制限し、問題を切り分ける実験も考えられる。これらは事例を踏まえた調査の方向性であり、検証済みの修正ではない。今後は、メンテナーが再現できるか、割り当て失敗時に安全にエラーを返せるか、後続バージョンで明確な修正が提供されるかに注目したい。設定ドキュメント