メモリ不足：GPU を変える前に、何が妨げになっているかを見つけましょう。

1. 再実行する前にメッセージと状況を保存する

キューにタスクを追加するのはやめましょう。エラーの正確な文言、関係するファイルや質問、まとめて処理した件数、到達した段階を記録します。モデルを読み込んでいたのか、計算が進んでいたのか、それとも出力を書き込んでいたのか。設定はメモに、すでに完了した結果はそれぞれのフォルダに保管しておきましょう。

画面が固まった、あるいは説明もなくアプリが閉じただけでは、原因を特定するには不十分です。ログがある場合は確認しましょう。接続の不具合、不正な入力、メモリの飽和は、画面上では似た症状を引き起こすことがあります。ソフトウェアが何も示していない場合は「原因不明」と書き留め、憶測で診断するのではなく最小限のテストを用意しましょう。

2. GPUメモリ、システムメモリ、ディスク容量を区別する

GPUメモリはカード上での計算に使われる要素のためのものです。サーバーのRAMとストレージは別の用途に応えます。BriefGPUのGPU一覧に表示される容量は、実際に利用できるRAMやディスクを表すものではありません。メッセージに示されたリソースと、ご自身の環境の情報を確認してください。

Pythonでは、MemoryErrorはメモリ確保の失敗を指します。この名前だけではVRAM不足を意味しません。ENOSPCというコードは、対象のデバイスに空き容量がないことを表します。これらの手がかりは調査の方向を示しますが、どの操作で起きたかを特定するには、やはりアプリのログが必要です。

3. 1つの入力と1つのアクティブなジョブに戻る

まず、ご自身が起動した処理を確認しましょう。プレビュー、古いセッション、別のツールがまだ動いていることがあります。不要になったタスクは状態を保存したうえで、きちんと終了させましょう。心当たりのないプロセスは終了させず、診断の数分を稼ぐために環境全体を再起動したりしないでください。

失敗した入力を、品質を落とさずに単独でやり直します。単独では通るのにグループでは失敗するなら、同時処理数が手がかりになります。たとえば4枚のグループを2枚に、必要なら1枚に減らします。フォルダ内のファイル数は同じままで、同時に処理する量だけが変わります。

メモリのピークを抑えるために、逐次処理を用意しているツールもあります。Diffusersは特に、画像バッチのデコード分割について記載しています。この機能は使用するパイプラインによって異なるため、他のモデル向けに見つけた設定を有効にする前に、そのパイプラインのオプションを確認してください。

4. 求められる結果を損なわずに負荷を下げる

単一の入力で失敗する場合は、その次元や長さを確認してください。画像の場合、2,048 × 2,048から1,024 × 1,024に下げるとピクセル数は4分の1になります。ただし、総メモリが4分の1になるわけではありません。モデルやその他の要素にはそれぞれの必要量があるためです。削減が許容されるのは、出力が必要なディテールを保っている場合だけです。

アシスタントの場合、提供された文書、質問、生成された回答を区別してください。生成キャッシュはコンテキストが長いとより多くのメモリを消費することがあります。正確な仕組みはモデルによって異なります。より短いリクエストや一度に1つのクエリを試してください。回答が含まれる箇所を削除して、問題が解決したと結論づけないでください。

元の入力を常に保管してください。試行するバリアントには名前を付け、何が変わるのかを書き留めます。ツールがタイル分割や一部要素のRAMへの転送に対応している場合は、そのドキュメントを確認し、つなぎ目、品質、実際にかかった時間をチェックしてください。VRAMを節約するオプションは、制約を別の場所へ移すだけかもしれません。

5. 予約メモリと有効メモリを混同しない

PyTorchでは、アロケータが予約したメモリとテンソルが使用しているメモリは別々の指標です。未使用のキャッシュをクリアしても、まだ有効なテンソルは解放されません。つまり、クリーンアップコマンドを使っても、大きすぎる負荷が適合する負荷になるわけではありません。

アプリケーションをきれいに再起動すると改善する場合は、その後で同じ小さなケースをもう一度実行し、結果を記録してください。再起動後の成功だけでは、メモリリークが修正された証拠にはなりません。同じ処理を繰り返すたびに使用量が増える場合は、その観察を保管し、再起動を重ねる前にソフトウェアのドキュメントやサポートに相談してください。

例：12枚の画像フォルダで問題を切り分ける

以下は説明用のシナリオで、ハードウェアの測定値ではありません。あるフリーランスが12枚の画像を用意し、そのうち2枚は大きなサイズと細かい文字を含んでいます。4枚ずつのグループ処理が失敗します。彼女はメッセージを保存し、大きな画像の1枚を元の品質で単独で試します。表は、想定される観察結果をどう解釈するかを示しています。

このシナリオでは、彼女は2枚の大きな画像を一緒に試し、さらにいくつかの通常の画像を確認した後にのみ、2枚ずつのグループを採用します。エクスポートしたファイルの文字と輪郭を確認します。この結果を、すべての画像サイズ、すべてのモデル、他のソフトウェアに一般化することはしません。

別の性能が正当な選択肢になる場合

GPUメモリ不足が特定され、必須のケースが単独で失敗し、品質に見合う縮小では足りない場合に、別のカードを比較してください。ソフトウェア、バージョン、パラメータ、該当する入力を保管しておきましょう。この記録があれば次の試行を比較できます。ただし、追加で何GBあれば十分か正確に推測できるわけではありません。

モデルの読み込み時のエラーも、グループを縮小する意義を限定的にする場合があります。最初の入力の前にすでに負荷の大部分が存在するからです。精度や量子化のオプションは実行条件を変え、時に結果も変えるため、別途試行が必要です。バッチを増やしても、複数のカードのメモリが自動的に統合されるわけではありません。

使える診断結果で締めくくる

出力メモは5つの要素でまとまります。メッセージと段階、疑われるリソース、保持した入力、通ったか失敗した設定、実施した品質確認です。不明な点も書き加えます。小さなケースがまったく動かない場合は、バッチ全体の繰り返しをやめ、これらの情報を添えて助けを求めます。

ディスクを空けるために唯一の原本を削除したり、複数のパラメータをまとめて下げたり、部分的な出力を成功とみなしたりしないでください。有効な結果を保存する時間を確保しましょう。診断は不確実性を減らすためのもので、延々と続く設定作業にする必要はありません。