WindowsでのHugging Faceキャッシュ: 調査、クリーンアップ、移動
Hugging Faceのダウンロードは、複数のモデルリビジョン、データセット、中断されたダウンロードによってWindowsドライブを圧迫する可能性があります。まずは、ダウンロードを行った環境のキャッシュツールから始めてください。任意のblobsフォルダを削除すると、そのファイルをまだ共有しているリビジョンが破損する可能性があり、HF_HOME全体を削除すると認証状態も失われる可能性があります。
アプリケーションが実際に使用するキャッシュを特定する
通常のHubキャッシュは%USERPROFILE%\.cache\huggingface\hubですが、アプリケーションは別のアカウント、環境変数、明示的なキャッシュディレクトリを使用する場合があります。環境変数のリファレンスでは、HF_HOME、HF_HUB_CACHE、HF_XET_CACHEを区別しています。HF_HOMEはモデルキャッシュより広範で、保存された認証トークンも含みます。
AIアプリケーションが使用するターミナルまたはPython環境を開き、インストールされているコマンドを検査します:
hf cache --help
hf cache ls
hf cache ls --revisions
これらはインベントリ用のコマンドです。hfまたはサブコマンドが利用できない場合は、その環境のhuggingface_hubバージョンと、ツールがサポートするアップグレード方法を確認してください。無関係なグローバルPythonインストールをアップグレードして、アプリのプライベート環境が変わると思い込まないでください。
別の場所に構成されたHubキャッシュの場合は、実際のパスを--cache-dirで指定します。デフォルトの場所の一覧表示は、より大きなカスタム場所が空であることを証明するものではありません。
合計を信用する前にコマンドとパスを確認する
PowerShellでは、これらの確認でどの実行ファイルが呼び出されているか、現在のプロセスのパス上書きが表示されます。認証トークンは表示されません:
Get-Command hf | Select-Object Source
$env:HF_HOME
$env:HF_HUB_CACHE
$env:HF_XET_CACHE
空行は、その変数がこのPowerShellプロセスで設定されていないことを意味します。デスクトップのランチャー、仮想環境、サービスが上書きを使用していないことの証明にはなりません。これらの読み取り結果を、ダウンロードを実行したアプリケーションと比較してください。特に複数のPythonインストールが存在する場合は重要です。
カスタムキャッシュの例では、一覧表示とプレビューの両方でその明示的なパスを使用します:
hf cache ls --cache-dir "D:\AI\huggingface\hub" --revisions
hf cache rm model/OWNER/REPOSITORY --cache-dir "D:\AI\huggingface\hub" --dry-run
パスとリポジトリIDは、PC上で見つかった値に置き換えてください。インストール済みのコマンドがオプションを拒否する場合は、作業を止めてヘルプを読んでください。構文エラーを手動でのフォルダー削除に結び付けないでください。新しく入力したパスでエントリがゼロ件と表示されても、実際のキャッシュが空である証明にはなりません。
Windowsで複数のリビジョンのコストが高くなる理由を理解する
Hugging Faceのキャッシュの説明では、共有blobとリビジョンスナップショットについて説明しています。シンボリックリンクをサポートしないWindowsでは、ファイルがスナップショットに直接保存されることがあるため、同じファイルが複数のリビジョンにわたって複数回スペースを占有する可能性があります。
ポリシーが許す場合、開発者モードを有効にすると、より効率的なシンボリックリンク動作が可能になります。シンボリックリンクの警告を非表示にしても、シンボリックリンクが有効になるわけでも、古いダウンロードが遡って重複排除されるわけでもありません。そのメッセージを消すためだけに、AIアプリケーション全体を管理者として実行しないでください。
また、Hubキャッシュと、アプリケーション独自のフォルダにコピーされたモデルファイルを区別してください。キャッシュコマンドは、PC上のすべての.safetensorsやGGUFファイルを一覧表示するものではありません。
共有モデルファイルを二重に数えるのを避ける
現在のキャッシュのドキュメントでは、リビジョン間だけでなく、対象となるXetダウンロードについてはリポジトリ間でも共有されると説明されています。リポジトリの報告サイズは論理的な値である一方、キャッシュ全体の物理サイズでは共有ファイルが一度だけ数えられる場合があります。したがって、各リポジトリのサイズを合計すると、それらを削除して回収できる量を過大に見積もる可能性があります。
これは、2つのモデル名が同じくらいの大きさに見える場合に重要です。ダウンロード方法とファイルシステムによって、異なる重みを含む場合もあれば、ファイルを共有している場合や別々のコピーを持っている場合もあります。一覧表示されたすべてのギガバイトが独立していると仮定せず、互換性のあるキャッシュツールに削除計画を計算させてください。
同じドキュメントは、古いクライアントがすべて新しい共有ストアを正しく管理できるわけではないと警告しています。キャッシュが、削除に使用しようとしているツールより新しいライブラリで作成された場合は、クリーンアップの前にアプリケーションの対応バージョンを確認してください。既存の環境を維持するか、互換性のある保守されたツールを意図的に使用してください。アプリケーションの固定された依存関係を盲目的に更新しないでください。
Hubキャッシュは1つの場所にすぎません。Xetデータ、データセット処理の出力、ローカルのモデルディレクトリに明示的にダウンロードされたファイルは、別の場所にある場合があります。Hubのプレビューがディスク使用量のごく一部しか示していない場合は、Hubの削除をより強引にするのではなく、それらの他の所有者を特定してください。
既知の1つのリポジトリの削除をプレビューする
対象のキャッシュを使用しているダウンロード、トレーニング、推論を停止します。不要になったリポジトリを特定し、復旧が重要である場合は、その正確なリビジョンが再度入手可能であることを確認します。ゲート付きアクセス、上流でのファイル削除、オフライン使用により、名目上ダウンロード可能なモデルが置き換え困難になる場合があります。
現在のCLIガイドはプレビューをサポートしています:
hf cache rm model/OWNER/REPOSITORY --dry-run
model/OWNER/REPOSITORYは、一覧表示の正確なIDに置き換えてください。影響を受けるリビジョンとサイズを確認します。その確認の後にのみ、--dry-runを付けずに同じコマンドを実行し、確認に応答します。これは削除であり、ごみ箱への移動ではありません。
参照されていないキャッシュ素材のクリーンアップには、インストールされているツールの計画を別途プレビューします:
hf cache prune --dry-run
参照されていないリビジョンでも、そのコミットに固定されたスクリプトによって必要とされる場合があります。プルーンを受け入れる前に、それらのプロジェクトを確認してください。その確認を回避するために、無条件の確認フラグを使用しないでください。
プルーンの計画を実際のプロジェクトと照合する
キャッシュ内のブランチやタグの参照は、プロジェクトが必要とするものの完全な一覧ではありません。スクリプトが、キャッシュされたブランチの先端ではなくなった正確なリビジョンハッシュを指定している場合があります。プルーンを受け入れる前に、稼働中のプロジェクトの設定でモデルIDと固定されたリビジョンを検索し、オフライン作業や再現可能な作業に必要なものはコピーを保管してください。
現在のCLIドキュメントでは、中断された.incompleteのダウンロードもプルーンの動作に含まれます。計画を確認する前に、そのダウンロードを所有する処理を完了させるか停止させてください。中断されたダウンロードによって残された部分的なファイルは、別の実行中のプロセスがまだ書き込み中のファイルとは異なります。
確認済みの削除を1回行った後、同じ明示的なキャッシュパスで一覧表示を再実行し、同じドライブの空き容量を比較してください。その後、小規模で代表的なワークロードを実行します。すぐに大きなモデルを再びダウンロードする場合は、そのワークロードが依然として削除したデータを必要としています。クリーンアップを繰り返しても、ディスク使用量と引き換えにダウンロード時間が増えるだけです。
移動する場合、認証状態の移転を意図していない限り、その状態を操作に含めないでください。HF_HUB_CACHEだけを別のドライブに向ける方が、HF_HOME全体を移動するより限定的です。変更する前に古い値を記録し、所有するアプリを再起動して、次回の実際のダウンロードがどこに現れるか確認してください。アプリが古いディレクトリを使い続ける場合は、どちらかのコピーを削除する前に、その明示的なキャッシュパスを調べてください。
場所を混同せずに今後のダウンロードを移動する
Hubキャッシュを別のドライブに配置するには、それを所有するアプリケーションに対してHF_HUB_CACHEを構成し、そのアプリケーションを完全に再起動します。ライブラリがインポートされる前に、環境の変更が反映されている必要があります。アプリ固有のcache_dirが別の場所を指している場合があるため、次のダウンロードの実際の保存先を確認してください。
変数を変更しても、古いファイルは移動されません。新しい場所をテストし、必要なローカル専用素材を保存するまで、古いキャッシュを保持してください。古いディレクトリがまだ大きい場合は、キャッシュツールとそのパスを使用して明示的に確認してください。
クリーンアップ後、重要なワークロードを1つテストし、同じボリュームの空き容量を比較します。Ollamaの別個のモデルストアについては、Ollama移行ガイドを使用してください。AIに関する共通のブランディングは、ツールが1つのキャッシュや1つの安全な削除コマンドを共有していることを意味するものではありません。