トラブルシューティング
タイムアウト、SAHI のパフォーマンス、OOM エラーなど、一般的な Batch Processing の問題を解決します。
このページでは、Batch Processing に関する既知の問題、制限、および回避策を一覧表示しています。ここに記載されていない問題が発生した場合は、以下の方法でご報告ください。 サポートチャネル.
既知の制限事項
環境変数とローカルストレージへのアクセスを必要とする一部の Workflow ブロック（File Sink や Environment Secret Store など）はブロックされ、実行されません。
このサービスは、 単一の 入力画像パラメータを定義する Workflows でのみ動作します。
技術的詳細
データは Data Staging に 7日間の有効期限.
各バッチ処理ジョブには複数のステージが含まれます（通常は
processingとexport）。各ステージは出力バッチを作成します。exportstage outputs の使用を推奨します。転送効率のために圧縮されているためです。の実行中ジョブは
processingstage は UI と CLI の両方から中断できます。中断された、または失敗したジョブは再起動できます。
このサービスは自動的にデータをシャーディングし、並列で処理します。
マシン数はデータ量に応じて自動的にスケールします（特定のワークロードではスループットが 500k〜1M 画像/時に達することがあります）。
各マシンは、データのチャンクを処理する複数の worker を実行します。これは設定可能で、速度とコストのバランスを取るよう調整する必要があります。
ジョブがタイムアウトする
問題
Batch ジョブは、 Processing Timeout Hours がジョブのサイズや複雑さに対して低すぎる場合に、途中で終了します。
詳細
タイムアウト設定（UI）または --max-runtime-seconds （CLI）は、 すべての並列 worker におけるマシン稼働時間の最大累計を定義します.
総計算時間: 上限が 2 時間で、ジョブが 2 台のマシンを起動した場合、各マシンは最大 1 時間実行できます（2 台 × 1 時間 = 合計 2 時間）。
チャンクごとに分割: ジョブは並列処理を可能にするため、処理チャンクに分割されます。タイムアウトはチャンク間で分割されるため、タイムアウトが短くチャンク数が多いと、各チャンクに割り当てられる時間が足りなくなる場合があります。
マシンタイプが重要です: 複雑な Workflows を CPU 上で実行すると、処理時間が大幅に増加します。適切な場合は GPU を使用してください。
推奨事項
大きなデータセットや複数ステージの Workflows では、余裕のあるタイムアウト（例: 4〜6時間）から始めてください。
今後のタイムアウト設定の参考にするため、実際のジョブ実行時間を監視してください。
チャンク数を減らすか、動画フレームのサブサンプリングを使用して、処理を高速化することを検討してください。
SAHI を使う Workflow が長時間実行される
問題
SAHI を使用するジョブ、特に高解像度入力や instance segmentation を伴う場合は、想定よりかなり長くかかることがあります。
原因と推奨事項
スライス数が多すぎる: SAHI は検出のために画像をより小さなスライスに分割します。デフォルト設定で高解像度入力を使うと、画像ごとに数十回から数百回の推論が発生する場合があります。
Image Slicer ブロックの設定を確認してください。スライス数を減らすか、Workflow の前段で Resize Image ブロックを使って入力を縮小してください。
SAHI の代わりにより大きいモデル入力サイズを検討してください: より大きな入力サイズでモデルを学習させると、SAHI が不要になる場合があります。まずは小さなサンプルでテストしてください。
instance segmentation のボトルネック: SAHI を instance segmentation と併用すると、Detections Stitch ブロック（特に NMS あり）が大きなボトルネックになることがあります。1 フレームの stitching に数十秒かかることもあります。
SAHI を使う動画ジョブ: FPS のサブサンプリングを使ってフレームをスキップします:
UI では、 Video FPS sub-sampling のドロップダウンを使用します。
CLI では、
--max-video-fpsフラグを使用します。
メモリ不足（OOM）エラー
問題
Workflow が使用可能な RAM または VRAM を超えて消費すると、OOM エラーによりジョブが失敗します。
一般的な原因
SAHI + instance segmentation: この組み合わせは非常にメモリ消費が大きいです。SAHI は推論呼び出し回数を増やし、instance segmentation は大きな出力（マスク、スコア）を生成するため、クラッシュにつながることがよくあります。
1 台のマシンあたりの worker が多すぎる: 複数の worker は軽量な Workflows ではコストと速度を最適化しますが、重い Workflows（複数の大規模モデル、複雑な後処理）は使用可能なメモリを超えてしまいます。
推奨事項
大きなモデル、SAHI、または高解像度入力を使う Workflows では、1 台のマシンあたりの worker 数を少なくしてください（例: 1 または 2）。
を下げてください Workers Per Machine Advanced Options の下にある値。
モデルにより高いメモリ帯域が必要な場合は、CPU から GPU に切り替えてください。
大きなバッチを実行する前に、まず小さなデータセットで Workflow をテストしてください。
入力解像度を下げるか、不要なブロックを削除して Workflow を簡素化してください。
Last updated
Was this helpful?