Hugging-Face-Cache auf dem Mac prüfen und bereinigen
AskClean-Team · Aktualisiert 2026-09-29
Ermittle den von der App verwendeten Cache. Prüfe ihn mit hf cache ls und zeige ein ausgewähltes Ziel zunächst mit hf cache rm --dry-run an. Behalte benötigte Offline-Modelle und eigene Arbeit. Lösche weder geteilte Blobs von Hand noch HF_HOME vollständig.
Speicherort und eigene Arbeit schützen
Üblich ist ~/.cache/huggingface/hub. HF_HUB_CACHE bestimmt den Repository-Cache; HF_HOME umfasst mehr. Ist HF_HOME nicht gesetzt, kann XDG_CACHE_HOME den Standard beeinflussen; cache_dir kann einen anderen Pfad wählen. Prüfe GUI, Terminal und notebook separat. HF_HOME kann Anmeldedaten enthalten und darf weder vollständig gelöscht noch veröffentlicht werden.
Eigene Checkpoints, Adapter, tokenizer-Änderungen, Konvertierungen, private Daten und Projekteinstellungen sind möglicherweise nicht erneut herunterladbar. Prüfe Backups: Manche Werkzeuge überspringen mit CACHEDIR.TAG markierte Caches. Behalte Inhalte ohne geklärte Wiederherstellung. Ein altes Zugriffsdatum allein macht ein Modell nicht entbehrlich.
Vollständige IDs und Warnungen anzeigen
Stoppe Apps, Downloads und Jobs, die den Cache nutzen. Führe hf cache ls --no-truncate und anschließend hf cache ls --revisions --no-truncate --show-warnings aus. Die geprüfte Version blendet detaillierte Warnungen standardmäßig aus. Verwende für einen eigenen Cache immer denselben --cache-dir. Kläre Lese- und Strukturprobleme, notiere Belegung und freien Speicher und veröffentliche keine privaten Repositorylisten.
Ziel und Vorschau genau prüfen
hf cache rm benötigt die vollständige CLI-ID. Bei Modellen bleibt model/ erhalten; ein Ordnername mit models-- ist kein Ersatz. Für eine Revision nutze den vollständigen hash und prüfe ihr Repository. Beginne mit --dry-run. Die Ausgabe ist eine Zielübersicht mit geschätzter Ersparnis, keine Einzeldateiliste. Ein Repositoryziel umfasst alle darin gecachten Revisionen.
Entferne --dry-run erst nach der Prüfung und behalte Ziel, Cachepfad und Bestätigungsabfrage bei. Ändert sich die Auswahl oder schlägt die Vorschau fehl, stoppe und untersuche die Ursache. Dateien werden direkt gelöscht, nicht in den Papierkorb verschoben. Wiederherstellung braucht ein Backup oder erneuten Downloadzugriff. Snapshots und teils auch Repositories teilen Blobs; überlasse Referenzen dem Cachemanager und addiere angezeigte Größen nicht einfach.
Prune und weitere Caches unterscheiden
hf cache prune --dry-run zeigt in der geprüften Version 2.0.0 abgekoppelte Revisionen und unvollständige Downloads. Ohne benannte Referenz kann ein Projekt eine Revision trotzdem fest vorgeben. Prüfe jeden Kandidaten und stoppe laufende Downloads. Beginne am besten mit einem einzelnen klaren Ziel.
Erzeugte Daten unter HF_DATASETS_CACHE unterscheiden sich von Hub-Downloads. Prüfe Xet-Transferdaten und local_dir-Ausgaben separat und behalte lokale Änderungen. Das Löschen von HF_HOME ersetzt diese Prüfung nicht.
Behaltene Modelle tatsächlich laden
Wiederhole die Messung, lade benötigte Modelle und Revisionen und führe eine kleine Aufgabe mit bekanntem Ergebnis aus. Ein erfolgreicher Python-Import reicht nicht. Teste Offline-Nutzung tatsächlich ohne Netzwerk. Stoppe bei Fehlern die Bereinigung und prüfe Umgebung, Pfad, Dateien, Zugriff und Platz vor der Wiederherstellung. Wiederholtes Löschen und Nachladen eines benötigten Modells spricht für eine andere Auswahl oder Kapazitätsplanung.
Bei einem externen Laufwerk prüfst du Platz, Rechte und symbolische Links. Kopiere Links samt Zielen, konfiguriere jede App und teste ihre Modelle, bevor du das Original entfernst. Das Laufwerk muss bei der Nutzung angeschlossen bleiben.
Was geprüft wurde
Am 2026-09-29 wurden mit huggingface_hub 2.0.0 temporäre synthetische Caches offline geprüft: Listen, vollständige IDs, Warnungen und dry-run funktionierten; Vorschauen änderten keine Dateien. Nach Entfernen einer alten Revision blieben aktuelle Revision und gemeinsame Daten erhalten. Echte Inferenz, Nutzer-Caches, repositoryübergreifende Blob-Bereinigung und Migration wurden nicht getestet. Daraus folgt keine feste Platzersparnis. Prüfe deine Version mit hf cache --help.
Vor dem Löschen prüfen
Prüfe Speicherort, Zweck und Wiederherstellung. Die Tabelle ist keine automatische Löschliste und verspricht keine feste Platzersparnis.
| Bereich | Prüfpunkt | Folgen und Bedingungen |
|---|---|---|
| Repository oder Revision | hf cache ls --revisions | Exakten Umfang und späteren Downloadzugriff prüfen. |
| Gemeinsame Daten | blob / snapshot | Referenzen durch den Cachemanager behandeln lassen; Größen nicht addieren. |
| Abgekoppelte Revision | hf cache prune --dry-run | Kann weiterhin exakt in einem Projekt festgelegt sein. |
| Erzeugte Dataset-Daten | HF_DATASETS_CACHE | Neuerzeugung braucht Quelldaten und Rechenzeit. |
| Eigene Modelle und Arbeit | checkpoint / adapter | Originale behalten und tatsächlichen Backupinhalt prüfen. |
| Hugging-Face-Home | HF_HOME | Kann Anmeldedaten enthalten; nicht vollständig löschen. |
FAQ
Ist eine detached Revision unbenutzt?
Nicht zwingend. Auch ohne benannte Referenz kann ein Projekt die genaue Revision benötigen. Prüfe die Abhängigkeiten zuerst.
Kann hf cache rm mein angepasstes Modell löschen?
Ja, wenn es im ausgewählten Cacheziel liegt. Nimm es aus dem Löschumfang und prüfe das Backup. Der Ordnername cache macht eigene Arbeit nicht entbehrlich.
Quellen