トラブルシューティング
タイムアウト、SAHI のパフォーマンス、OOM エラーを含む、一般的な Batch Processing の問題をトラブルシュートします。
このページでは、バッチ処理に関する既知の問題、制限事項、回避策を一覧表示しています。ここに記載されていない問題が発生した場合は、以下を通じてご報告ください。 サポート窓口.
既知の制限事項
環境変数やローカルストレージへのアクセスを必要とする一部のWorkflowブロック（File Sink や Environment Secret Store など）はブロックされ、実行されません。
このサービスは、次を定義するWorkflowでのみ動作します。 単一の 入力画像パラメータ。
技術的詳細
データはData Stagingに、 7日間の有効期限.
各バッチ処理ジョブは複数のステージを含みます（通常は
処理およびエクスポート）。各ステージは出力バッチを作成します。おすすめはエクスポートステージ出力を使用することです。これは転送効率のために圧縮されるためです。実行中のジョブは
処理ステージで、UIとCLIの両方を使って中止できます。中止された、または失敗したジョブは再開できます。
このサービスはデータを自動的にシャーディングし、並列で処理します：
マシン数はデータ量に基づいて自動的に拡張されます（特定のワークロードではスループットが1時間あたり50万～100万画像に達することがあります）。
各マシンは、データのチャンクを処理する複数のワーカーを実行します。これは設定可能で、速度とコストのバランスを取るよう調整すべきです。
画像ジョブでは、1つのシャード内で失敗する画像が多すぎると、そのシャードは中止され、ジョブの残りは続行されます。このしきい値はジョブごとに設定できます（以下を参照 シャードごとの画像失敗許容率 ）。
ジョブのタイムアウト
問題
次の 処理タイムアウト時間 が、ジョブのサイズや複雑さに対して低すぎる場合、バッチジョブは早期に終了します。
詳細
タイムアウト設定（UI）または --max-runtime-seconds （CLI）は、 すべての並列ワーカーにおけるマシンの累積最大実行時間.
合計計算時間： 上限が2時間で、ジョブが2台のマシンを起動する場合、それぞれ最大1時間実行できます（2台 × 1時間 = 合計2時間）。
チャンクごとに分割： ジョブは並列処理を可能にするために処理チャンクに分割されます。タイムアウトはチャンク間で分配されます。短いタイムアウトでチャンク数が多いと、チャンクごとの時間が不足する可能性があります。
マシンの種類が重要です： 複雑なWorkflowをCPUで実行すると、処理時間が大幅に増加します。必要に応じてGPUを使用してください。
推奨事項
大規模データセットや複数ステージのWorkflowでは、十分に長いタイムアウト（例：4～6時間）から始めてください。
今後のタイムアウト設定の参考にするため、実際のジョブ実行時間を監視してください。
より高速な処理のために、チャンク数を減らすか、動画フレームのサブサンプリングを使用することを検討してください。
SAHIを使用するWorkflowの実行時間が長すぎる
問題
SAHIを使用するジョブは、特に高解像度入力やインスタンスセグメンテーションの場合、予想よりかなり長くかかることがあります。
原因と推奨事項
スライス数が多すぎる： SAHIは検出のために画像をより小さなスライスに分割します。デフォルト設定と高解像度入力では、画像ごとに数十から数百回の推論が必要になることがあります。
Image Slicerブロックの設定を確認してください。Workflowの前段にあるResize Imageブロックを使って、スライス数を減らすか、入力を縮小してください。
SAHIの代わりに、より大きなモデル入力サイズを検討してください： より大きな入力寸法でモデルを学習させることで、SAHIを完全に不要にできる場合があります。まずは小さなサンプルでテストしてください。
インスタンスセグメンテーションのボトルネック： SAHIをインスタンスセグメンテーションと組み合わせると、Detections Stitchブロック（特にNMSあり）が大きなボトルネックになることがあります。1フレームのステッチだけで数十秒かかることがあります。
SAHIを使用する動画ジョブ： FPSのサブサンプリングでフレームをスキップしてください：
UIでは、 動画FPSサブサンプリング ドロップダウンを使用してください。
CLIでは、
--max-video-fpsフラグを使用してください。
メモリ不足（OOM）エラー
問題
Workflowが利用可能なRAMまたはVRAMより多くを消費すると、OOMエラーによりジョブは失敗します。
一般的な原因
SAHI + インスタンスセグメンテーション： この組み合わせは非常にメモリを消費します。SAHIは推論呼び出しを増やし、インスタンスセグメンテーションは大きな出力（マスク、スコア）を生成するため、クラッシュにつながることがよくあります。
マシンごとのワーカー数が多すぎる： 複数ワーカーは軽量なWorkflowではコストと速度を最適化しますが、重いWorkflow（複数の大規模モデル、複雑な後処理）では利用可能なメモリを超えます。
推奨事項
大規模モデル、SAHI、高解像度入力を含むWorkflowでは、マシンごとのワーカー数を少なくしてください（例：1または2）。
次を下げてください マシンごとのワーカー数 高度なオプションの下にある値。
モデルにより高いメモリ帯域幅が必要な場合は、CPUからGPUに切り替えてください。
大規模バッチを実行する前に、小さなデータセットでWorkflowをテストしてください。
入力解像度を下げるか、不要なブロックを削除してWorkflowを簡素化してください。
シャードごとの画像失敗許容率
仕組み
画像バッチジョブは、並列実行されるシャードに分割されます。各シャードは、処理中に失敗した画像の数を追跡します。1つのシャード内の失敗率がしきい値を超えると、そのシャードは中止されます。ジョブの残りは影響を受けずに続行されます。
デフォルトでは、プラットフォームは固定の失敗しきい値を適用します。これをジョブごとに上書きするには、次を設定します。 maxImageFailureRate をジョブ作成リクエスト本文に指定します。値は 0.0 および 1.0:
0.0は、許容ゼロを意味します（最初の失敗でシャードを中止します）。1.0は、何枚の画像が失敗してもシャードが中止されないことを意味します。このフィールドを省略するか、
nullに設定すると、プラットフォームのデフォルトを使用します。
このパラメータは画像ジョブにのみ適用されます。動画ジョブではサポートされていません。
API経由での設定
次を含めて maxImageFailureRate ジョブ作成ペイロードに：
この値は、失敗または中止されたジョブを再開するときに、再開パラメータのオーバーライドに含めることで上書きすることもできます。
最終更新
役に立ちましたか？