Hugging Face models via Artifactory or a proxy: HF_ENDPOINT, gated models, 429, Xet

How model downloads go through a company proxy

A company routes Hugging Face downloads through Artifactory by creating a remote Hugging Face repository that proxies huggingface.co and caches what it fetches, then pointing every client at it with the environment variable HF_ENDPOINT. The client authenticates to Artifactory, Artifactory authenticates to Hugging Face with an organisation token, and the second download of a model comes from the company's own storage. A plain HTTPS proxy passes the traffic through but caches nothing: each client still downloads every file itself and signs in to Hugging Face with its own token.

This article is for a company whose GPU servers are connected but whose IT wants one controlled path for model files, with a cache, an audit point and one place to manage tokens. If the servers have no network path at all, the procedure is different and our guide to the air-gapped LLM server covers it. What a model file can do when it is loaded, and why safetensors and pinned revisions matter, is in securing a GPU server.

vLLM documentation ("Using a proxy", HF_ENDPOINT), JFrog documentation and knowledge base, Sonatype Nexus Repository 3 documentation index, Hugging Face blog community article of 8 May 2026; all read 25 October 2026.

Sonatype's documentation for Nexus Repository 3 lists a Hugging Face repository format with pages on creating such a repository, configuring Hugging Face with Nexus and CLI usage. The page bodies did not render when we read them on 25 and 26 October 2026, so the endpoint format, the client settings and the limits for Nexus are not described here; check them in Sonatype's current documentation. The rest of this article uses Artifactory, whose documentation and Hugging Face's own article on it we could read.

Remote, local and virtual repositories in Artifactory

Artifactory knows three repository types for Hugging Face. A remote repository is the caching proxy: JFrog's documentation says Artifactory "supports proxying remote Hugging Face registries through remote repositories", and the knowledge base article on gated models has it point to https://huggingface.co. A local repository holds your own models, such as fine-tuned weights or an approved copy of a base model. A virtual repository combines both under one URL.

The Hugging Face blog article "Hugging Face on JFrog Artifactory: an enterprise guide (and what changes in June 2026)", a community article of 8 May 2026, adds two limits worth knowing before you design around a virtual repository: it needs all member repositories on the new layout, and it resolves only through snapshot_download, not through from_pretrained(). JFrog's CLI command jf hf covers download and upload only; other hf commands are not wrapped. For inference servers that start with a model name and download on first use, point them at the remote repository, or pre-fetch the snapshot and serve from a local path.

Client settings: HF_ENDPOINT, HF_TOKEN and timeouts

The endpoint format is the same in JFrog's knowledge base article 000006288 (last modified 22 July 2025) and in Hugging Face's article: HF_ENDPOINT is the Artifactory host followed by /artifactory/api/huggingfaceml/ and the repository name. Hugging Face's article says to set HF_TOKEN on the clients to an Artifactory token; Hugging Face's environment variable reference states that HF_TOKEN "will overwrite the token stored on the machine".

JFrog knowledge base 000006288 (timeouts, endpoint); Hugging Face blog community article, 8 May 2026 (HF_TOKEN as Artifactory token); huggingface_hub environment variable reference, docs v2.3.0 (defaults); all read 25 October 2026.

The timeouts matter on a cold cache. With the default of 10 seconds for the metadata call, Hugging Face's reference says the client "will default to the locally cached files" when the request times out, and a download that waits longer than 10 seconds for a response raises a TimeoutError. JFrog's article sets both to 86400 seconds.

vLLM's documentation states that "by default, vLLM loads models from Hugging Face (HF) Hub", that HF_HOME changes the download path, and that a self-hosted registry is used by pointing HF_ENDPOINT at it. So the same variables go into the environment of a vLLM container. Once the model is in the server's cache, setting HF_HUB_OFFLINE stops all HTTP calls to the Hub, which keeps a restart from depending on the proxy. Our article on GPU CI runners uses the same cache read-only in CI jobs.

Gated models through a proxy

Many current models are gated: Hugging Face's documentation on gated models states that "access requests are always granted to individual users rather than to entire organizations", that a request "can only be done from your browser", and that authors "can decide at any time to block your access to the model without prior notice". Downloading from a script needs a user token.

Through Artifactory, the account that counts is the one whose token sits in the remote repository's "Password / Access Token" field. JFrog's knowledge base describes the failure mode: a 404 on the first download means that account lacks access, and the fix is to log in to Hugging Face as that account, accept the model's terms in the browser, wait for approval if the author approves manually, and run the download again. Hugging Face's article puts the consequence plainly from its side: Artifactory cannot carry organisation-level permission for gated models such as Llama, Gemma and Mistral, so access is managed per account. It presents its own Model Gateway, in preview for some Enterprise Plus organisations, as the answer; that is the vendor's statement.

Two practical rules follow. Use a dedicated organisation-owned account for the upstream token, not a person's account that leaves with the person, as both JFrog's and Hugging Face's articles recommend. And accept a gated model's licence on that account only after the licence has been read for your use; our overview of LLM licences for commercial use covers the common ones.

We supply AI servers with NVMe model stores and set up model serving that pulls through your proxy; tell us which repository manager you run and which models you need, and our team replies with a configuration.

Hugging Face rate limits and HTTP 429 behind a proxy

Hugging Face's rate-limit page (read 25 October 2026) counts three buckets, Hub APIs, resolvers (every URL with /resolve/ in its path, which is how files are downloaded) and web pages, over "5-minute fixed windows". Exceeding one returns "a 429 Too Many Requests HTTP error" with RateLimit and RateLimit-Policy headers. Anonymous traffic is limited per IP address; for organisations, "rate limits are applied individually to each member, not shared among members".

Hugging Face Hub documentation "Rate limits", table dated September 2025 on the page, read 25 October 2026; requests per 5 minutes; anonymous and free values "subject to change over time". Enterprise Plus with "Higher Hub Rate Limits" enabled: 100,000 / 500,000 / 10,000.

A proxy changes the arithmetic. Every developer, CI job and server behind it reaches Hugging Face under the one identity of the remote repository's token, or under one IP address if there is no token. Hugging Face's article names this as the cause of 429 errors behind Artifactory and adds that per-developer PRO accounts do not help, because the proxy uses its own identity. Hugging Face's first advice on its rate-limit page is to always pass HF_TOKEN, and it notes that huggingface_hub 1.2.0 and later read the RateLimit header on a 429 and wait exactly until the reset before retrying.

What keeps a proxy below the limit is the cache itself: a model pulled once is served from Artifactory to every later client. Schedule the first pull of a new model by one job, not by twenty servers starting at once, and keep the upstream token on an account whose plan matches the traffic.

The June 2026 layout change in Artifactory

Hugging Face's article and JFrog's Xet announcement describe the same change. Artifactory's original Hugging Face package type dates from version 7.77.x; version 7.111.1 introduced the Machine Learning repository layout, which new repositories use by default. Repositories created before 7.111.1 "must be migrated" by June 2026, after which, in Hugging Face's words, "the legacy Hugging Face layout is deprecated" and full functionality can no longer be relied on. The migration runs from the administration interface as "Upgrade Repository Layout"; JFrog writes that it needs no downtime and no traffic to huggingface.co.

Three points from Hugging Face's article matter for planning, now that the deadline has passed. Rolling back with the restore_layout REST call deletes packages added after the migration. Federated or replicated sites cannot mix the two layouts: every member must run 7.111.x or later and be migrated before federation resumes. And cache warming after the switch raises the request volume to the Hub, so rate limits bite more often in the days after. If your instance still has a repository in the legacy layout, plan the migration as a change with a rollback that accepts the loss of new writes.

Xet through Artifactory

The Hub now stores files with Xet: Hugging Face's environment variable reference states that "the Hugging Face Hub is fully powered by the Xet storage backend", and that hf-xet is used automatically when it is installed. How well a proxy handles Xet decides how much disk the cache takes.

JFrog's announcement of 24 June 2026 says Xet is supported on Hugging Face remote repositories in the Machine Learning layout, with local repositories to follow, enabled by "a single checkbox", and claims "up to 3.7x speed improvement in subsequent pulls". It notes that a file downloaded both through Git LFS and through Xet could be stored twice, mainly during the layout switch.

Hugging Face's community article of 8 May 2026, written before that announcement, describes Artifactory's Xet support as limited to remote repositories and not working with download redirection, reports that a 125 MB file took about 240 MB in the cache, and recommends HF_HUB_DISABLE_XET=1 on clients, which it says "roughly halves" the cache footprint. Neither is an independent measurement. On your instance, pull one model with Xet on and once with it off, compare the storage used, and keep the setting that gives the smaller cache at acceptable speed.

Revisions, checksums and what the cache holds

A proxy caches what clients ask for, so the request decides what the cache holds. Hugging Face's CLI downloads a fixed revision with --revision and filters files with --include and --exclude. That filter matters for large repositories: the Files page of gpt-oss-120b (read 25 October 2026) lists about 65 GB of safetensors in the root but 196 GB for the whole repository, which also holds original/ and metal/ folders. A full snapshot pulls all 196 GB through the proxy; a download limited with --include to the root safetensors, configuration and tokenizer files pulls about a third of that.

Pin revisions by full commit hash, not by branch, as our article on backing up an AI server explains, and check the cached files against the Hub's checksums with hf cache verify, which "exits with a non-zero status" on a mismatch. Disk for the model store on the GPU servers themselves is sized in NVMe for an LLM server. For an archive of several large models, the Artifactory side needs the same order of capacity, plus the doubled files Xet may leave during a migration.

What we supply

We supply AI servers built to order with NVMe model stores, assembled and tested before delivery, with the operating system, NVIDIA driver, CUDA and a container runtime installed on request, on one EU contract and invoice. Quantities and lead time are confirmed in writing with the quote. Setting up the models, their download path through your proxy, serving and retrieval is our Private AI/ML service.

FAQ