Microsoft’s Foundry Managed Compute now runs Hugging Face governance on Foundry Managed Compute as a first-class option: weights are pre-staged in Azure, runtimes are built and scanned by Microsoft, and every model in the catalog carries the same enterprise security, governance, observability, and billing as any other Foundry model, announced at Microsoft Build 2026.
Quick take
Choose Foundry Managed Compute when the requirement is Azure-native RBAC, audit, and a single bill across model types.
Choose Hugging Face Inference Providers when the priority is a single API across many external inference vendors with no added markup.
Choose a self-hosted Run:ai deployment when the workload needs direct GPU topology control and the team can own cluster operations.
Choose Ollama or Jan’s HF Router only for local development or single-machine prototyping, not production serving.
What Changed at Build 2026
The new catalog is curated from the Hugging Face ecosystem and refreshed weekly, and it deploys onto Foundry Managed Compute in one click rather than through a custom container pipeline.
The consistency claim is specific: pay-per-token, provisioned throughput, and Managed Compute share a single endpoint, the same SDKs, the same authentication, the same observability, and a single bill.
Quota is aligned to accelerator families such as the H100 family, and Microsoft states that allocation carries forward as new hardware generations come online, with Global deployments for broadest capacity and pricing versus Data Zone deployments for residency and sovereignty.
Supported runtimes include vLLM, SGLang, TensorRT-LLM, NIM, TEI, and llama.cpp, and Microsoft handles container updates, runtime upgrades, and security patches on those runtimes without requiring a redeploy of the model.
Microsoft frames the scale of what it is plugging into: Hugging Face as 15 million builders, 400,000 organizations, and over 3 million open models published, which is the justification for building a managed on-ramp rather than leaving enterprises to self-integrate.
Four Ways to Run Hugging Face Models in Production
Hugging Face’s own Inference Providers offer a single API across partner backends including Cerebras, Cohere, DeepInfra, Fal AI, Groq, and Together, with no extra markup on provider rates and a free tier plus additional credits for PRO and Team or Enterprise accounts; it is also positioned as a drop-in replacement for the OpenAI chat completions API.
Foundry Managed Compute is a managed GPU platform-as-a-service: you describe a model instance by parameter count, context length, and whether to optimize for latency or throughput, and Microsoft handles the GPU topology underneath.
A self-hosted path through NVIDIA Run:ai requires the Leader-Worker Set (LWS) component installed on the cluster, a Hugging Face token stored as a user credential, and a PVC-based data source for model caching; the tutorial example sets a 2 TB claim size for that PVC.
Local, single-machine tools sit at the other end: Ollama runs models free with a single command but has no built-in multi-tenancy, autoscaling, or access control, which the evidence describes explicitly as a development and edge tool rather than a production serving platform for a large user base. Jan’s HF Router reaches similar territory, requiring a Hugging Face token and billing to be set up before it fans requests out to providers like Replicate, Together AI, SambaNova, Fireworks, and Cohere.
The Decision Table: Governance, GPU Control, and Cost
The four paths differ less in what model they can ultimately run and more in who controls the GPU, who owns the audit trail, and how the bill is structured.
| Path | GPU control | Governance / audit | Cost structure |
|---|---|---|---|
| HF Inference Providers | Provider-managed, routed across multiple vendors | Standard Hugging Face account and organization controls | No markup on provider rates; free tier plus PRO/Team credits |
| Foundry Managed Compute | Microsoft-managed topology; you set parameter count, context length, latency/throughput target | Unified RBAC, content safety filters, private networking, Azure Policy integration | Single bill shared with pay-per-token and provisioned throughput tiers |
| Self-hosted via Run:ai | Full control, LWS-orchestrated across one or more accelerators | Admin-defined projects, access keys, and per-user credentials | Infrastructure and PVC storage cost, e.g. a 2 TB claim in the reference tutorial |
| Local (Ollama / Jan) | Single machine only, no fleet orchestration | No built-in multi-tenancy or access control | Free to run locally (Ollama), or token plus billing setup for routed access (Jan) |
The table is a starting filter, not a final answer: a team that needs Azure-native compliance tooling and a team that needs raw GPU control both touch Hugging Face’s model catalog, but they end up on opposite rows.
Switching Costs and Operational Risk
Foundry’s shared endpoint, SDK, authentication, and billing across its three deployment tiers is the concrete mechanism that lowers switching cost between pay-per-token experimentation and Managed Compute production, since the surrounding code does not change.
Hugging Face’s Inference Providers offer a comparable form of portability one layer up the stack: because the API is consistent across partner backends, swapping the underlying inference vendor does not require rewriting the integration.
The Run:ai path trades that portability for infrastructure ownership, and it carries its own first-run tax: a PVC is provisioned only once per claim, so the first workload launch is slower than subsequent ones that reuse the same cached data source.
Local tools have close to zero technical switching cost but also zero enterprise controls baked in, so moving a Jan or Ollama prototype into a governed environment means adding authentication, multi-tenancy, and audit logging from nothing rather than inheriting them.
What to Verify Before Committing
Before sizing a Data Zone commitment, confirm which specific jurisdictions it actually covers; the evidence separates Global deployments (broadest capacity and pricing) from Data Zone deployments (residency and sovereignty) without listing the exact regions.
Before locking in a multi-year Managed Compute plan, verify how today’s accelerator-family quota, such as an H100 family allocation, is expected to translate as Microsoft brings new hardware generations online.
Before scaling a self-hosted deployment past a single pilot node, confirm that LWS is installed and that the PVC access mode is set correctly, since a scope mismatch at the project or namespace level means the PVC does not replicate data across projects the way a team might assume.
Before wiring a Jan-style HF Router flow into anything customer-facing, confirm the Hugging Face token’s scope and that billing is actually active, since both are stated prerequisites rather than optional setup steps.
None of these four paths is a universal winner. The right one depends on whether the binding constraint is Azure-native compliance, vendor-neutral API access, direct GPU ownership, or zero-cost local iteration, and that constraint is what should drive the next infrastructure decision, not the model catalog itself.