Contents
Cybersecurity
CISO-as-a-service consulting: posture, remediation roadmap, ongoing support.
Discover →
Linux Services & Systems
Domains, hosting, PEC, email infrastructure, network services and Linux systems. Open Source infrastructure support and management.
Discover →
Today, 3 September, NVIDIA announced it has agreed to acquire Hugging Face for 12,930,300,000 dollars. The announcement comes from two places: a post on NVIDIA’s blog and a message on X from Clément Delangue, cofounder and chief executive of Hugging Face, who speaks of “our intention to join forces”. As this piece is written the Hugging Face blog carries no post about the deal, so the acquired company’s voice is for now that of its founder on a social network.
This is not distant news for us. Hugging Face is where the weights of almost every model we write about come from, including yesterday’s GLM-5.3, and it is the same infrastructure breached in July by a collective of agents, a story we followed from the first account through to the METR investigation.
The platform in figures
The NVIDIA announcement quantifies what is being acquired.
| Developers, researchers and creators | more than 18 million |
| Models shared | more than 3 million |
| Datasets | 500,000 |
| Applications | 1 million |
| Companies using the platform | more than 200,000 |
In the same text NVIDIA states it is the largest contributor of open models and data on Hugging Face, with more than 500 models and more than 250 datasets published. The figure cuts both ways: it says the acquirer was already inside the ecosystem as a content supplier and it says whoever buys the platform is also the biggest among its public users.
The stated commitments
The announcement does not stop at generic intentions, and this is the part to read closely because it is what can later be checked.
Hugging Face “will remain an open platform for the entire AI ecosystem”. The sentence that matters most is this one: “NVIDIA compute will not be required to build on or deploy through Hugging Face”. Developers will choose the models, the frameworks, the clouds, the inference providers and the computing platforms they want.
Then comes the commitment to keep supporting “open source and open weight models from across the ecosystem, from every model builder”, together with multi-cloud and multi-accelerator development and deployment. Worth noting that NVIDIA uses the distinction between open source and open weights correctly, keeping them separate, which is more than many announcements manage.
On the corporate side: the founders and the team stay, the brand stays. NVIDIA also cites an open letter on the importance of open weights to the AI economy, which Jensen Huang says he coauthored with other industry leaders.
Where the dependency sits
Here it is worth being technical, because the argument about what “open” means turns on an implementation detail.
The open-weights ecosystem has a single default hub. That is not a figure of speech: it is a constant in the code. In huggingface_hub/constants.py, at line 67, you find _HF_DEFAULT_ENDPOINT = "https://huggingface.co". Anyone writing from_pretrained("org/model") with no further instruction is contacting that domain.
The way out exists and is two lines further down, at 69: ENDPOINT = os.getenv("HF_ENDPOINT", _HF_DEFAULT_ENDPOINT). The HF_ENDPOINT environment variable lets you point at a mirror or your own instance. It is the kind of detail nobody configures until they need it, and one worth knowing about after today.
The scale of the dependency shows in our own archive too. Out of 556 Italian pieces, 18 link to huggingface.co, for 58 occurrences of the domain counting both languages. They are all pieces explaining how to obtain and run a model. Every time we wrote “the weights are downloaded here”, the here was that.
There is also a part of the dependency a naive mirror does not copy. Yesterday, writing about GLM-5.3, we noted that the model card documents from day one a deployment path on Ascend NPU, with vLLM-Ascend, xLLM and SGLang. That line is not in the weights: it is in the repository README.md, along with the sampling parameters, the methodology footnotes and the links to serving recipes. The same holds for community quantisations, which are separate repositories with different authors. Anyone downloading only the safetensors files takes home the model and leaves behind the instructions for running it, which are often the part that costs the most time.
The Arm precedent
NVIDIA has attempted a large acquisition before and it did not go through, and it is useful to recall it with the exact dates.
In December 2021 the Federal Trade Commission sued to block the 40 billion dollar acquisition of Arm. On 7 February 2022 NVIDIA and SoftBank announced the termination of the agreement, with a reason stated in NVIDIA’s own release: “because of significant regulatory challenges preventing the consummation of the transaction, despite good faith efforts by the parties”.
The parallel needs handling with care, because the antitrust theory at stake is different. Arm was intellectual property underpinning the designs of NVIDIA’s direct competitors and the concern was control over an input to the chip supply chain. Hugging Face is not intellectual property on which accelerators are built: it is the distribution channel downstream. A 12.93 billion transaction with an acquirer of this size will still need clearance in several jurisdictions. In vertical transactions the remedies authorities ask for typically concern interoperability and non-discriminatory access.
What we think
The stated commitments are precise and that makes them checkable against technical things rather than against declarations. There are three of them and they are observable from the code: that HF_ENDPOINT keeps working against a mirror, that the hub API stays the one the libraries call today, that model cards keep accepting serving recipes for anyone’s accelerators. Those are the three surfaces a service that downloads weights depends on.
For anyone building on open weights the practical advice does not change as of today, and it is the same we gave looking at plugins resolved from a GitHub reference in DeepSeek Harness and at binaries installed with curl | bash in harness and sandbox. A model a production service runs on is a supply chain dependency and should be treated as one: a local copy of the weights that actually matter, a reference pinned to a specific revision rather than to the main branch, checksum verification. Anyone who already runs an internal registry for containers already has the place to put them.
For our own projects the consequence is direct and worth spelling out. On our artificial intelligence page we say we build private solutions with open-weight models such as Llama, Gemma, DeepSeek and Qwen, keeping data and control on-premise. All four come through the same hub. For air-gapped installations offline provisioning of the weights was already mandatory, so nothing changes there. It changes for everything else: an internal mirror stops being a build-time optimisation and becomes part of the delivery, together with the register of revisions used by each environment. Anyone shipping systems meant to stay in service for years has one more reason not to have a single point that start-up depends on.
The part that interests us most in the medium term is what happens to the word “open”. We have held the distinction between open source and open weights tight in every model piece, and it is not pedantry: yesterday we wrote that the GLM-5.3 licence is near-MIT except for one clause above 10 billion dollars, where that “near” was the point. With the platform that distributes the weights owned by a hardware vendor, a third thing joins the list to keep separate: the model’s licence, the openness of the code and the neutrality of the channel distributing them. These are properties independent of one another and from here on we will look at all three.