Type this on a fresh node inside a segmented network and watch it hang:

The call is not broken. The box has no route to huggingface.co, and the library’s default behavior is to contact the Hub to check for a newer revision before it loads anything. In a connected lab you never notice the round trip. Behind an air gap it is the first wall you hit, and it is the right place to start, because every enterprise concern in this finale is a variation on one fact: the Hub is a remote artifact registry, and you are about to run without it.

If you have ever stood up an internal mirror for OS packages, or pointed a build farm at a pull-through Docker cache instead of Docker Hub, you already hold the mental model. A model repo is an artifact with a name, a revision, and a set of files. Getting it on-prem is a mirroring problem. Keeping the runtime from leaking out to the internet is a configuration problem. Neither is a machine-learning problem, and that is the good news for the person reading this.

There are exactly two things to get right. First, pull the artifact onto a host that can reach the Hub, verify it, and move it across the boundary into internal storage. Second, configure every node on the dark side so the runtime serves from that local copy and never tries to call out. Keep those two jobs separate and the rest is plumbing you have built a dozen times.

Use the official CLI. Note that huggingface-cli is deprecated in favor of hf; old scripts that call huggingface-cli download still work, but write new automation against hf. Pull to a flat local directory so you can package and move it. Pin a revision. In a connected lab nobody pins, and that is fine until two nodes quietly load two different commits of the same name and you spend an afternoon proving it.

For reproducibility, replace main with the actual commit hash from the model’s revision history once you have chosen one. That hash is your immutable tag. It is the difference between can you redeploy exactly what passed review and roughly the same model, probably. Before anything leaves this host, scan it and confirm the weights are safetensors rather than pickle. That check is the topic of Part 7, and the registry-side controls are Part 15. The gap is exactly where you enforce both, because it is the one chokepoint every model must pass through.

On the dark side, the contract is simple: never let the library reach out. Set HF_HUB_OFFLINE=1 and load from the local path. This both removes the dependency on a route you do not have and skips the revision-check round trip, which means faster cold starts as a side benefit.

If you run a pull-through proxy on the connected edge instead of sneaker-netting folders, point clients at it with HF_ENDPOINT rather than going fully offline. Same idea as an internal package mirror. The trade-off table below covers the variables that matter in production.

For one engineer with a personal token, the free tier is fine. The moment a shared proxy, a CI fleet or a hundred developers sit behind one Hub identity, two things go wrong that you will recognize instantly. You hit rate limits, and you have no audit trail. Both are identity problems, and both are what the paid tiers exist to solve.

The Hub enforces limits over rolling windows, tied to the authenticated identity making the request. A human is bursty and small. A proxy where every training run, every Kubernetes pod cold-start and every cache revalidation funnels through one token looks, from the Hub’s side, like one account making thousands of requests. The bucket fills and resolve calls start returning HTTP 429. Per-developer upgrades do nothing, because only the proxy identity’s tier counts. The fix is to issue that token from an organization on a paid plan, and on Enterprise Plus to add IP allowlisting for the highest limits.

Beyond limits, the Enterprise Hub replaces the personal-token failure mode with identity an enterprise can manage. SSO over SAML or OIDC, with Managed SSO on Enterprise Plus making your IdP the only path in. SCIM provisioning so access disappears when someone leaves. Token approval policies so a new fine-grained token cannot be used against the org until an admin signs off. Audit logs that attribute every membership change, repo action and token approval. Resource groups for per-team scoping, and storage regions for EU data residency. If you have run an internal registry with RBAC, none of this is new vocabulary. It is the same control plane, applied to models instead of images, which is the through-line of the Harbor series.

Worked example

Gated models like Llama, Gemma and Mistral require each user to accept a license before downloading. With fifty engineers, that is fifty individual click-throughs and fifty support tickets when someone is blocked. On the org tier, you accept once at the organization level and the model becomes available to every member through the internal path. One acceptance, one audit record, fifty unblocked engineers. That is the difference between governance you administer and governance that administers you.

Many shops do not want a bespoke model mirror. They already run JFrog Artifactory for Docker, PyPI, npm and Maven, and they want models on the same plane. Artifactory can proxy the Hub, cache models, scan them with Xray and bundle them into release artifacts. For modest usage that is a clean fit, and you point clients at it with the same HF_ENDPOINT mechanism shown above.

Two things to plan for. First, there is a forced migration: legacy Hugging Face repositories in Artifactory must move to the newer Machine Learning repository layout, and the cutover is one-way for practical purposes, with federated topologies needing a coordinated window. If you run this, inventory your repos and schedule it deliberately. Second, watch storage. Artifactory’s implementation of the Xet content-addressed protocol mimics the API surface but does not deliver real global deduplication, so each model can be cached both as a flat file and as byte-range slices, roughly doubling the footprint.

My take: a universal artifact manager and a Hub-native organization are complements, not rivals. Let Artifactory be the perimeter that scans and bundles every artifact your company ingests. Let an Enterprise organization own identity, rate limits and gated-model access on the Hub side. Use the proxy for what it is good at, and do not expect it to be Hugging Face.

Mirroring gets the weights on-prem. Serving turns them into a running endpoint, and here the series converges. Once a safetensors model sits in internal storage, you have two production paths, and the choice is an infrastructure decision, not a research one.

The Hub-native road is Text Generation Inference. It is a container you pull, point at the local model directory, and run; it is the fastest way from a mirrored model to a stable endpoint, and it stays inside the toolchain this series has used throughout. The production walk-through is Part 12, and the build-versus-buy decision among hosted inference and self-hosting is Part 11.

The NVIDIA road converts the same weights into an engine tuned for your specific GPUs, through TensorRT-LLM and the NIM packaging. You trade a build step and some flexibility for throughput on the cards you have. When the GPU stack is the center of gravity, follow the NVIDIA AI series. When the question is running all of this on VMware Cloud Foundation with proper isolation and scheduling, that is the Private AI series. The concepts underneath, quantization and fine-tuning and RAG as ideas, live in the GenAI series.

My recommendation, with the three-part honesty this series promises: default to TGI, because it gets you to a running, observable endpoint with the least moving parts and keeps you on one toolchain. Do not reach for the TensorRT-LLM conversion path when your traffic is light or your model mix changes weekly, because the build step and engine rebuilds cost you more than they return at low volume. Validate first that your GPUs and driver stack match the engine you intend to build, and that quantization (covered in Part 13) fits the model on the cards before you commit a serving design around it.

Sixteen parts in, here is the build I would own. A connected staging host with an org-issued, approved token that pulls and pins models. A scan-and-verify gate at the boundary that rejects pickle and unsigned artifacts. Managed internal storage holding the mirror, mounted read-only on the fleet. Serving nodes running with HF_HUB_OFFLINE=1, fronted by TGI for most models and a converted engine only where throughput justifies it. Identity, audit and gated-access on the Hub side through an Enterprise organization, and a universal artifact manager as the perimeter if you already run one. Every box in that diagram is a thing you have built before for some other artifact type. Models are just the newest artifact to cross your gap.

That is the real conclusion of this whole series. The Hugging Face stack is not a foreign country to the infrastructure engineer. It is a registry, a set of clients, a serving layer and a governance plane, mapped onto skills you already have. You were never behind. You were early.

Your move: take the one model your team most wants on-prem, run the hf download and offline-load pair from this post on a test node, and time the cold start. That single loop, pull then serve offline, is the whole platform in miniature.