Hugging-Face-Modelle über Artifactory oder Proxy: HF_ENDPOINT, Gated-Modelle, 429, Xet

Wie Modell-Downloads über einen Firmen-Proxy laufen

Ein Unternehmen leitet Downloads von Hugging Face über Artifactory, indem es ein Remote-Repository für Hugging Face anlegt, das huggingface.co als Proxy anspricht und alles Abgerufene zwischenspeichert, und jeden Client über die Umgebungsvariable HF_ENDPOINT darauf zeigen lässt. Der Client meldet sich bei Artifactory an, Artifactory meldet sich mit einem Token der Organisation bei Hugging Face an, und der zweite Download eines Modells kommt aus dem eigenen Speicher des Unternehmens. Ein einfacher HTTPS-Proxy reicht den Verkehr nur durch und speichert nichts: Jeder Client lädt jede Datei selbst und meldet sich mit seinem eigenen Token bei Hugging Face an.

Dieser Artikel richtet sich an Unternehmen, deren GPU-Server am Netz hängen, deren IT aber einen kontrollierten Weg für Modelldateien will: mit Cache, einem Prüfpunkt und einer Stelle für die Verwaltung der Tokens. Haben die Server überhaupt keine Netzverbindung, ist das Vorgehen ein anderes; das behandelt unser Leitfaden zum Air-Gapped-LLM-Server. Was eine Modelldatei beim Laden auslösen kann und warum Safetensors und festgelegte Revisionen zählen, steht in GPU-Server absichern.

vLLM-Dokumentation („Using a proxy“, HF_ENDPOINT), JFrog-Dokumentation und Knowledge Base, Inhaltsverzeichnis der Dokumentation zu Sonatype Nexus Repository 3, Community-Artikel im Hugging-Face-Blog vom 8. Mai 2026; alles gelesen am 25. Oktober 2026.

Sonatypes Dokumentation zu Nexus Repository 3 führt ein Repository-Format Hugging Face mit Seiten zum Anlegen eines solchen Repositorys, zur Konfiguration von Hugging Face mit Nexus und zur CLI-Nutzung. Die Seiteninhalte wurden beim Lesen am 25. und 26. Oktober 2026 nicht angezeigt; Endpunkt-Format, Client-Einstellungen und Grenzen für Nexus beschreiben wir deshalb nicht, prüfen Sie sie in der aktuellen Dokumentation von Sonatype. Der Rest des Artikels verwendet Artifactory, dessen Dokumentation und Hugging Faces eigenen Artikel dazu wir lesen konnten.

Remote-, lokale und virtuelle Repositories in Artifactory

Artifactory kennt drei Repository-Typen für Hugging Face. Ein Remote-Repository ist der Proxy mit Cache; JFrogs Dokumentation schreibt, Artifactory „supports proxying remote Hugging Face registries through remote repositories“, und der Knowledge-Base-Artikel zu Gated-Modellen lässt es auf https://huggingface.co zeigen. Ein lokales Repository enthält eigene Modelle, etwa feinabgestimmte Gewichte oder eine freigegebene Kopie eines Basismodells. Ein virtuelles Repository fasst beides unter einer URL zusammen.

Der Artikel „Hugging Face on JFrog Artifactory: an enterprise guide (and what changes in June 2026)“ im Hugging-Face-Blog, ein Community-Artikel vom 8. Mai 2026, nennt zwei Grenzen, die man kennen sollte, bevor man auf ein virtuelles Repository setzt: Es verlangt alle Mitglieds-Repositories im neuen Layout, und es löst nur über snapshot_download auf, nicht über from_pretrained(). JFrogs CLI-Befehl jf hf deckt nur download und upload ab; andere hf-Befehle sind nicht abgebildet. Inferenz-Server, die mit einem Modellnamen starten und beim ersten Start herunterladen, lassen Sie auf das Remote-Repository zeigen, oder Sie laden den Snapshot vorab und liefern ihn aus einem lokalen Pfad aus.

Client-Einstellungen: HF_ENDPOINT, HF_TOKEN und Timeouts

Das Endpunkt-Format ist im JFrog-Knowledge-Base-Artikel 000006288 (zuletzt geändert am 22. Juli 2025) und im Artikel von Hugging Face dasselbe: HF_ENDPOINT ist der Artifactory-Host, gefolgt von /artifactory/api/huggingfaceml/ und dem Namen des Repositorys. Der Artikel von Hugging Face sagt, HF_TOKEN auf den Clients auf ein Artifactory-Token zu setzen; Hugging Faces Referenz der Umgebungsvariablen hält fest, dass HF_TOKEN „will overwrite the token stored on the machine“.

JFrog Knowledge Base 000006288 (Timeouts, Endpunkt); Community-Artikel im Hugging-Face-Blog, 8. Mai 2026 (HF_TOKEN als Artifactory-Token); Referenz der Umgebungsvariablen von huggingface_hub, Doku v2.3.0 (Standardwerte); alles gelesen am 25. Oktober 2026.

Bei einem kalten Cache sind die Timeouts wichtig. Mit dem Standard von 10 Sekunden für den Metadaten-Aufruf greift der Client laut Hugging Faces Referenz bei einer Zeitüberschreitung auf lokal zwischengespeicherte Dateien zurück („will default to the locally cached files“), und ein Download, der länger als 10 Sekunden auf eine Antwort wartet, löst einen TimeoutError aus. JFrogs Artikel setzt beide auf 86400 Sekunden.

vLLMs Dokumentation hält fest, „by default, vLLM loads models from Hugging Face (HF) Hub“, dass HF_HOME den Download-Pfad ändert und dass eine selbst gehostete Registry genutzt wird, indem man HF_ENDPOINT auf sie zeigen lässt. Dieselben Variablen gehören also in die Umgebung eines vLLM-Containers. Liegt das Modell im Cache des Servers, unterbindet HF_HUB_OFFLINE alle HTTP-Aufrufe zum Hub; ein Neustart hängt dann nicht mehr vom Proxy ab. Unser Artikel zu GPU-Runnern für CI bindet denselben Cache schreibgeschützt in CI-Jobs ein.

Gated-Modelle über einen Proxy

Viele aktuelle Modelle sind gated. Hugging Faces Dokumentation zu Gated-Modellen hält fest: „Access requests are always granted to individual users rather than to entire organizations“, eine Anfrage „can only be done from your browser“, und die Autoren „can decide at any time to block your access to the model without prior notice“. Für Downloads aus einem Skript braucht es ein Benutzer-Token.

Über Artifactory zählt das Konto, dessen Token im Feld „Password / Access Token“ des Remote-Repositorys steht. JFrogs Knowledge Base beschreibt den Fehlerfall: Ein 404 beim ersten Download heißt, dass dieses Konto keinen Zugriff hat; die Lösung ist, sich als dieses Konto bei Hugging Face anzumelden, die Bedingungen des Modells im Browser zu akzeptieren, bei manueller Freigabe durch den Autor zu warten und den Download zu wiederholen. Der Artikel von Hugging Face formuliert die Folge aus seiner Sicht deutlich: Artifactory kann Berechtigungen auf Organisationsebene für Gated-Modelle wie Llama, Gemma und Mistral nicht weitergeben, der Zugriff wird pro Konto verwaltet. Als Lösung stellt er das eigene Model Gateway vor, in der Vorschau für einige Enterprise-Plus-Organisationen; das ist die Aussage des Anbieters.

Daraus folgen zwei praktische Regeln. Verwenden Sie für das Upstream-Token ein eigenes Konto der Organisation, nicht das Konto einer Person, das mit ihrem Ausscheiden wegfällt, wie es die Artikel von JFrog und Hugging Face empfehlen. Und akzeptieren Sie die Lizenz eines Gated-Modells auf diesem Konto erst, wenn sie für Ihre Nutzung gelesen wurde; unser Überblick zu LLM-Lizenzen für kommerzielle Nutzung behandelt die üblichen.

Wir liefern KI-Server mit NVMe-Modellspeicher und richten die Modellbereitstellung so ein, dass sie über Ihren Proxy lädt; nennen Sie uns Ihren Repository-Manager und die benötigten Modelle, und unser Team antwortet mit einer Konfiguration.

Rate Limits von Hugging Face und HTTP 429 hinter einem Proxy

Hugging Faces Seite zu Rate Limits (gelesen am 25. Oktober 2026) zählt drei Bereiche, Hub-APIs, Resolver (jede URL mit /resolve/ im Pfad, über die Dateien heruntergeladen werden) und Webseiten, über „5-minute fixed windows“. Wer eine Grenze überschreitet, erhält „a 429 Too Many Requests HTTP error“ mit den Headern RateLimit und RateLimit-Policy. Anonymer Verkehr wird pro IP-Adresse begrenzt; für Organisationen gilt: „rate limits are applied individually to each member, not shared among members“.

Hugging-Face-Hub-Dokumentation „Rate limits“, Tabelle auf der Seite mit September 2025 datiert, gelesen am 25. Oktober 2026; Anfragen pro 5 Minuten; Werte für anonyme und Free-Nutzer „subject to change over time“. Enterprise Plus mit aktivierten „Higher Hub Rate Limits“: 100.000 / 500.000 / 10.000.

Ein Proxy ändert die Rechnung. Alle Entwickler, CI-Jobs und Server dahinter erreichen Hugging Face unter der einen Identität des Tokens im Remote-Repository, oder ohne Token unter einer IP-Adresse. Der Artikel von Hugging Face nennt das als Ursache für 429-Fehler hinter Artifactory und ergänzt, dass PRO-Konten einzelner Entwickler nicht helfen, weil der Proxy seine eigene Identität verwendet. Hugging Faces erster Rat auf der Seite zu Rate Limits ist, immer HF_TOKEN mitzugeben; außerdem lesen huggingface_hub 1.2.0 und neuer bei einem 429 den Header RateLimit und warten genau bis zum Zurücksetzen, bevor sie es erneut versuchen.

Unter der Grenze hält einen Proxy der Cache selbst: Ein einmal geladenes Modell liefert Artifactory jedem späteren Client aus. Lassen Sie den ersten Download eines neuen Modells von einem Job erledigen, nicht von zwanzig gleichzeitig startenden Servern, und halten Sie das Upstream-Token auf einem Konto, dessen Plan zum Verkehr passt.

Der Layout-Wechsel in Artifactory im Juni 2026

Der Artikel von Hugging Face und JFrogs Xet-Ankündigung beschreiben denselben Wechsel. Artifactorys ursprünglicher Pakettyp für Hugging Face stammt aus Version 7.77.x; Version 7.111.1 führte das Repository-Layout Machine Learning ein, das neue Repositories standardmäßig verwenden. Repositories, die vor 7.111.1 angelegt wurden, „must be migrated“ bis Juni 2026; danach gilt, mit den Worten von Hugging Face: „the legacy Hugging Face layout is deprecated“, und auf den vollen Funktionsumfang ist kein Verlass mehr. Die Migration läuft in der Administrationsoberfläche über „Upgrade Repository Layout“; laut JFrog braucht sie keine Ausfallzeit und keinen Verkehr zu huggingface.co.

Drei Punkte aus dem Artikel von Hugging Face zählen für die Planung, nachdem die Frist verstrichen ist. Die Rückkehr mit dem REST-Aufruf restore_layout löscht Pakete, die nach der Migration hinzukamen. Föderierte oder replizierte Standorte können die beiden Layouts nicht mischen: Jedes Mitglied muss 7.111.x oder neuer betreiben und migriert sein, bevor die Föderation wieder läuft. Und das Aufwärmen des Caches nach dem Wechsel erhöht die Zahl der Anfragen an den Hub, sodass Rate Limits in den Tagen danach öfter greifen. Hat Ihre Instanz noch ein Repository im alten Layout, planen Sie die Migration als Change mit einem Rückweg, der den Verlust neuer Schreibvorgänge in Kauf nimmt.

Xet über Artifactory

Der Hub speichert Dateien inzwischen mit Xet: Hugging Faces Referenz der Umgebungsvariablen hält fest, dass „the Hugging Face Hub is fully powered by the Xet storage backend“, und hf-xet wird automatisch verwendet, wenn es installiert ist. Wie gut ein Proxy mit Xet umgeht, entscheidet, wie viel Platz der Cache belegt.

JFrogs Ankündigung vom 24. Juni 2026 nennt Xet als unterstützt für Remote-Repositories für Hugging Face im Layout Machine Learning, lokale Repositories sollen folgen, eingeschaltet mit „a single checkbox“, und beansprucht „up to 3.7x speed improvement in subsequent pulls“. Sie vermerkt, dass eine Datei, die sowohl über Git LFS als auch über Xet geladen wurde, doppelt gespeichert sein kann, vor allem während des Layout-Wechsels.

Der Community-Artikel im Hugging-Face-Blog vom 8. Mai 2026, geschrieben vor dieser Ankündigung, beschreibt Artifactorys Xet-Unterstützung als auf Remote-Repositories beschränkt und nicht mit Download-Weiterleitung nutzbar, berichtet, dass eine Datei von 125 MB im Cache etwa 240 MB belegte, und empfiehlt HF_HUB_DISABLE_XET=1 auf den Clients, was den Platzbedarf des Caches laut Artikel „roughly halves“. Keine der beiden Angaben ist eine unabhängige Messung. Laden Sie auf Ihrer Instanz ein Modell einmal mit und einmal ohne Xet, vergleichen Sie den belegten Speicher und behalten Sie die Einstellung, die bei annehmbarer Geschwindigkeit den kleineren Cache ergibt.

Revisionen, Prüfsummen und was der Cache enthält

Ein Proxy speichert, was Clients anfragen; die Anfrage bestimmt also, was im Cache liegt. Hugging Faces CLI lädt mit --revision eine feste Revision und filtert Dateien mit --include und --exclude. Bei großen Repositories ist der Filter wichtig: Die Files-Seite von gpt-oss-120b (gelesen am 25. Oktober 2026) listet im Hauptverzeichnis etwa 65 GB Safetensors, für das ganze Repository aber 196 GB, weil es auch die Ordner original/ und metal/ enthält. Ein voller Snapshot zieht alle 196 GB durch den Proxy; ein Download, der mit --include auf die Safetensors im Hauptverzeichnis, die Konfiguration und den Tokenizer beschränkt ist, etwa ein Drittel davon.

Legen Sie Revisionen über den vollständigen Commit-Hash fest, nicht über einen Branch, wie unser Artikel zum Backup eines KI-Servers erklärt, und prüfen Sie die zwischengespeicherten Dateien mit hf cache verify gegen die Prüfsummen des Hubs; der Befehl „exits with a non-zero status“ bei einer Abweichung. Den Modellspeicher auf den GPU-Servern selbst dimensioniert unser Artikel NVMe für LLM-Server. Für ein Archiv mehrerer großer Modelle braucht die Artifactory-Seite eine Kapazität in derselben Größenordnung, dazu die doppelten Dateien, die Xet während einer Migration hinterlassen kann.

Was wir liefern

Wir liefern KI-Server nach Maß mit NVMe-Modellspeicher, vor der Lieferung montiert und getestet, auf Wunsch mit Betriebssystem, NVIDIA-Treiber, CUDA und Container-Laufzeit, mit einem EU-Vertrag und einer Rechnung. Mengen und Lieferzeit werden schriftlich mit dem Angebot bestätigt. Die Einrichtung der Modelle, ihres Download-Wegs über Ihren Proxy, der Bereitstellung und des Retrievals ist unser Service Private AI/ML.

FAQ