パフォーマンス
クライアント側での背景削除:対応ブラウザとパフォーマンス
端末上でモデルを動かすツールは、その端末の限界をそのまま受け継ぎます。必要なブラウザAPI、利用できる実行経路、そしてクリップの処理時間を左右する要素をまとめました。bgremover.ai自体はモデルを当社GPUサーバーで動かしていますが、クリップの縮小・合成・エンコードは引き続きブラウザが行います。
4バイト
デコード済み1ピクセルあたり
8.3MB
1080pの1フレーム
33MB
4Kの1フレーム
3
実行経路
1280px
当社へのアップロード(長辺)
ブラウザが備えるべきもの
クライアント側の背景削除ツールはWebページの中で動くため、必要な機能はすべてインストールではなくブラウザが提供しなければなりません。重要なのは4つで、どれか1つでも欠けた端末ではツールが動きません。
WebAssemblyはブラウザ自身のサンドボックス内でモデルを動かすため、クライアント側ツールでは映像が端末から出ません。一方bgremover.aiは、背景削除の仕組みで解説しているとおり、映像を当社GPUサーバーにアップロードします。推論の大半は行列演算なのでGPUが必要です。WebGLはグラフィックスAPIを通じて、WebGPUはコンピュートAPIを通じてGPUを利用します。
どちらもなければ、推論はCPUで行われます。完成したフレームをファイルにエンコードする手段も必要です。対応範囲の広いMediaRecorderか、より細かく制御できるWebCodecsです。4つ目の要件であるデコード済みフレーム用のメモリは、最も過小評価されています。
3つの実行経路
| 経路 | 処理する場所 | 速度 | 利用可能性 |
|---|---|---|---|
| WASM(SIMD使用) | CPU、1演算で複数の値 | 最も遅い | ほぼどこでも |
| WebGL | GPU、グラフィックスシェーダー経由 | 中程度 | どのGPUでも |
| WebGPU | GPU、コンピュートAPI経由 | 最も速い | 最も普及していない |
WebGLは設計ではなく回避策です。このAPIは三角形を描くために作られたもので、テクスチャを介してデータを動かすには時間がかかります。それでも実用上の標準であり続けています。WASMは処理をワーカーに移さない限りメインスレッドを奪い合い、BEN2はFP16 WebGPUが必要なので最近のデスクトップGPUに限られます。
これを決めるのは好みではなく利用可能性です。WebGPUだけを実装したツールは、動く環境では速く、それ以外ではまったく使えません。
初回の実行が遅い理由
-
モデルを一度ダウンロード
フレームを処理する前に行われます。
-
初期化とウォームアップ
そのあと最初のフレームが処理されます。
-
2回目以降はどちらも省略
キャッシュから読み込まれるので、残るのは初期化だけです。
そのため、クライアント側ツールはページの読み込み時ではなく、ユーザーの操作をきっかけにモデルを読み込むべきです。ページを開いた瞬間に数メガバイトのWebAssemblyが届くと、読みに来ただけの人にはページが壊れているように感じられます。
デコード済みフレームの計算
デコード済みの動画フレームは非圧縮のピクセルなので、メモリ使用量はほぼ解像度で決まります。
4バイト
1ピクセルあたり
8.3MB
1080pの1フレーム
33MB
4Kの1フレーム
5
作業中に保持するフレーム
これらの数値は計算によるもので、実測値ではありません。また、圧縮後のファイルサイズは目安になりません。全フレームを一度にデコードする必要はありませんが、処理の流れの中では作業用のフレームを保持します。デコード中のフレーム、セグメンテーション中のフレーム、そのマスク、合成結果、そしてエンコーダーのバッファです。
4Kで33 MBのフレームが数枚となると、タブのメモリ予算が問題になってきます。特にスマホではそうです。高解像度の長いクリップが失敗したり、タブが再読み込みされたりする場合は、長さではなく解像度を下げてください。縦横をそれぞれ半分にすれば、メモリは4分の1になります。
処理時間を決めるもの
ここで示すのは数値ではなく関係です。あるノートPCで測った時間は、スマホについては何も教えてくれません。
- フレーム数長さ×フレームレート。60 fpsは30 fpsの2倍です。
- 解像度デコード、合成、エンコードを左右します。推論は一定です。
- 実行経路同じマシンでもWebGPU、WebGL、WASM-SIMDで違います。
- 端末の種類デスクトップ、ノートPC、スマホのGPUは別物です。
- モデルの選択マッティングはMediaPipeよりフレームあたりのコストが高くなります。
- 発熱状態熱くなったスマホでGPU処理を続けると、性能が抑制されます。
処理時間の表はまだありません。実際のテストが必要です。デスクトップとノートPCで1080p 30 fpsを60秒、AndroidとiPhoneで30秒。でっち上げたベンチマークは、このページで唯一検証できない数値になってしまいます。
ブラウザ対応表
| 要件 | Chrome、Edge | Firefox | Safari | モバイル |
|---|---|---|---|---|
| WebAssembly | ✓ | ✓ | ✓ | ✓ |
| WebAssembly SIMD | ✓ | ✓ | ✓ | 未検証 |
| WebGL | ✓ | ✓ | ✓ | 未検証 |
| WebGPU | ✓ | 未検証 | 未検証 | 未検証 |
| MediaRecorder | ✓ | ✓ | 未検証 | 未検証 |
すべての環境に対応していると謳う前に、ここにブラウザごとの検証結果を載せるべきです。検証なしで言えるのは設計上のことです。クライアント側ツールに必要なのはWebAssemblyとGPUの経路であり、WebGPUではありません。bgremover.aiは、アップロードの準備と書き出しにWebCodecsを使うため、WebCodecsが必要です。
モバイルの実情
クライアント側ツールの場合、MediaPipeセルフィーセグメンテーションの軽さこそが、モバイルブラウザでの利用を可能にしています。メモリ要求が控えめな数メガバイトのモデルならスマホのタブに収まりますが、デスクトップGPU向けのモデルは収まりません。bgremover.aiはモデルをGPUサーバーで動かすことでこの問題を回避していますが、クリップのデコードとエンコードは引き続きスマホが行います。
| スマホでの比較 | bgremover.ai | FuzzPuppy |
|---|---|---|
| モバイルブラウザで動作 | はい | デスクトップのみ |
| モデル | 当社のAIモデル(GPUサーバー) | MODNetとBEN2 |
| アルファ付き書き出し | ✗ | アルファ付きMOV、グリーンバックのMP4 |
| WebGPUが必要 | ✗ | はい |
| 価格 | 無料 | 無料 |
ブラウザごとにテストするまで、すべてのモバイル環境に対応しているとは謳いません。モバイルはより難しい環境です。タブあたりのメモリが少なく、積極的に解放され、発熱による性能低下もあります。低解像度の短いクリップが確実な方法で、画像の背景削除で処理する静止画なら1フレーム分で済みます。
よくある質問
対応しているブラウザと端末は?
bgremover.aiには、アップロードの準備と書き出しに使うWebCodecsを備えた最新のブラウザが必要です。現行のデスクトップ版Chrome、Edge、Firefox、Safariが対応しています。モバイルブラウザも原則として同じ要件を満たしており、上の対応表は検証中です。
モバイルでも使えますか?
はい。モデルは当社GPUサーバーで動くため、スマホが行うのはアップロードの準備と書き出しだけです。タブのメモリが限られるので、短いクリップのほうが確実です。
背景削除に時間がかかるのはなぜ?
クリップは縮小されてアップロードされ、当社GPUサーバーで処理されたあと、ブラウザで合成・エンコードされます。最初の数秒が届いた時点で処理が始まりますが、混雑時は空いているGPUを少し待つことがあります。処理時間はフレーム数に比例します。
初回の実行が2回目より遅いのはなぜ?
クライアント側ツールでは、初回利用時にモデルをダウンロードしてブラウザがキャッシュするため、最初のクリップでダウンロードと初期化の時間がかかります。bgremover.aiではモデルは当社サーバーで動くため、最初のクリップで取得するのはページの動画ライブラリだけで、それもブラウザにキャッシュされます。
ブラウザのタブを開いたままにすべきなのはなぜ?
タブがクリップをアップロードし、当社サーバーからマスクを受け取り、書き出しファイルを組み立てているからです。タブを閉じると処理はキャンセルされ、別のタブから書き出しを引き継ぐことはできません。当社側で何を保持するかはプライバシーのページで説明しています。
長いクリップほど比例して時間がかかりますか?
おおむねそのとおりです。処理時間はフレーム数に比例し、長さが2倍になればフレーム数も2倍になるからです。フレームレートを上げても同じです。解像度を上げるとデコード・合成・エンコードのコストは増えますが、セグメンテーションのコストは増えません。