Transformersコミュニティが画像前処理の性能低下を報告、Linuxで複数画像リクエストの遅延が約2割増加

Transformersコミュニティは10月28日、Linux CPUでQwen3-VLに複数画像を入力した際、5.18.0と5.19.0が5.17.0より遅くなるという性能低下を報告した。報告者はバージョン二分探索で「不要な画像コピーを省く」正規化変更を特定し、その変更だけをロールバックすると遅延が回復したとしている。テスト出力は一致しており、現時点では性能上の問題が示されている。元の報告

テストではXeon Platinum 8488Cと8つのPyTorchスレッドを使用し、毎回512×512の画像30枚を入力した。報告者がvLLMのマルチモーダル処理経路で測定したところ、前処理時間は84.9ミリ秒から104.4ミリ秒に増加し、ロールバック後は86.1ミリ秒に低下した。これは特定の入力と環境における処理段階の測定値であり、モデルのエンドツーエンドのスループットがそのまま約2割低下したことを意味するものではない。テスト構成と結果

注目すべき点は、コピーを1回省いてもパイプライン全体が速くなるとは限らないことだ。報告者はマイナーページフォールトの増加を観察し、インプレース正規化によってglibcの割り当てと解放の順序が変わり、その結果、後続の浮動小数点画像バッファーが新たにマップされたメモリを取得する頻度が増え、初回アクセス時のページ処理コストが上昇した可能性を推測している。アロケーターのしきい値を調整すると両バージョンの速度が近づき、この推測を裏付ける結果となった。ただし報告者は、割り当て順序を完全には追跡できていないとも明記している。メモリ動作の分析

Hugging Faceのドキュメントによると、画像プロセッサーはリサイズ、正規化、テンソル変換を担う。torchvisionバックエンドは、テンソル以外の入力を受け取る場合、デフォルトでCPU上で実行される。そのため、エンジニアリングチームがマルチモーダルサービスの遅延を調査する際は、前処理とGPU推論を分けて測定し、バックエンド、画像の枚数、メモリ割り当て環境も記録する必要がある。画像プロセッサーのドキュメント

確認時点でこのIssueはオープンのままで、メンテナーによる確認や修正へのリンクはない。同じ正規化経路を共有するほかの画像・動画プロセッサーにも影響するかどうかは、まだ検証が必要だ。今後は異なるアロケーター設定での再現性や修正案を確認すべきであり、glibcパラメーターの調整を一般的な解決策とみなすのは時期尚早だ。