 | こんにちは Docker上でvLLM + llama.cppを使い、数週間かけてQwen 3.5 Visionで実験を回しています。いくつか分かったことがあります。 1. 長時間動画のOOMは、ほぼ常にこの3つのvLLMフラグです `--max-model-len`, `--max-num-batched-tokens`, `--max-num-seqs 1時間45分の動画で18k+の視覚トークンに到達し、推論を始める前に16kのデフォルトを簡単に超えてしまいます。アプリケーション側でチャンク化（≤300sのセグメント）し、チャンク間でKVキャッシュを解放すれば、ローカルのリソースが少なくても2パス目の要約で処理できます。 2. セグメントの重なりが重要 雑にチャンクすると境界でイベントが分断されます。たとえ2秒の重なりでも意味のある文脈が回復します。文脈予算に余裕があるなら10秒がより良いです。 3. 前処理が最も過小評価されているレバー 1 FPS + 高さ360pxに切ることで、1分40秒の動画を~7秒から~3.5秒の推論にまで短縮でき、許容できる精度が得られました。vLLMに任せず自分でやってください。推論エンジンにフルサイズの動画が投入されている可能性が高く、前処理時間のほうが多くの人が想定しているよりも総遅延に占める割合が大きいからです。 画像の場合：256pxがちょうど良い点でした（128pxだとモデルが猫を認識できませんでした）。 4. スタブル画像 vs ナイトリー `vllm/vllm-openai:latest`は、Blackwell向けにナイトリーが推奨されているにもかかわらず、私の実行ではナイトリービルドよりもレイテンシが低い結果でした。新しいほうが速いと決めつけず、手元のハードウェアで両方をテストしてください。 5. 構造化出力 — instructorを組み込む 4Bは、プロンプトの指示を明示しても、不正なJSONを生成することがあります。チャンク結果を下流のコードに渡しているなら、instructor + Pydanticのスキーマを使い、自動リトライを入れてください。 6. 並行処理による高速化は本物 2つの並列リクエスト → ~24%高速化。10の同時シーケンス → 注意（attention）バックエンドによりますが、~70–78%のスループット改善。 興味がある人のために、テストで使ったものをリポジトリに置きました。0.8B / 4B / 27B-FP8 などのDocker Compose設定、ベンチマーク結果、そしてコードを書かずに前処理とチャンクのパラメータをテストできるGradioアプリがあります。あとは `uv sync` して実行するだけです： github.com/lukaLLM/Qwen_3_5_Vision_Setup_Dockers 他にも何か「より多くの成果を絞り出す」方法を見つけた人や、面白いビジョンタスクを実行している人はいますか？ [リンク] [コメント] |
vLLM + llama.cpp 上での Qwen 3.5 Vision — 何週間かテストして分かった6つのこと（前処理の高速化、同時実行性）
Reddit r/LocalLLaMA / 2026/4/2
💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsTools & Practical UsageModels & Research
要点
- 著者は、Qwen 3.5 Vision の長尺動画実行が、`--max-model-len`、`--max-num-batched-tokens`、`--max-num-seqs` などの vLLM 設定によって OOM（メモリ不足）になりがちだと報告しており、動画を最大でも 300 秒以下のセグメントに分割し、各チャンク間で KV キャッシュを解放すること、さらに任意で 2 回目のパス要約を行うことを推奨している。
- セグメントのオーバーラップが結果に大きく効く点を強調しており、文脈の重要情報を取り戻すのに約 2 秒のオーバーラップでも効果があり、文脈予算に余裕がある場合は約 10 秒のオーバーラップのほうがより良いという。
- 実務上の最大の速度改善要因は前処理で、フレームレートを下げる（例：〜1 FPS）ことや画像解像度を抑える（例：高さ 〜360px、画像はおおむね 256px 程度）ことで、エンジンにフルサイズ動画をそのまま取り込ませる場合と比べて推論時間を大幅に削減できるとしている。
- レイテンシにはモデル／コンテナの選択が効く。著者は `vllm-openai:latest` が、手元の環境では nightly ビルドよりも良い場合があることを見つけたため、「新しいほど常に速い」と決めつけず、テストして確かめることを勧めている。
- 下流の統合では、たとえ 4B モデルでも JSON が不正になることがあるため、instructor + Pydantic のスキーマを組み合わせ、検証と自動リトライを行うことで、構造化出力を堅牢にすることを推奨している。
- 実運用では同時実行（concurrency）によってスループットが向上することを確認しており、例えば 2 つの並列リクエストで約 24% 高速化し、10 の同時シーケンスではスループットが約 70〜78% 増えるといった結果が示されている。また、前処理／チャンクングのパラメータをベンチマークするための Docker ベースのリポジトリと Gradio アプリも提供している。
