KIberblick

Wenn Hugging Face verkauft wird, was dann?

Berichte über eine Verkaufssondierung bei 13 Milliarden Dollar. Was das für selbst gehostete Modelle heißt, und warum ein Fork hier leichter wäre.

Entwickler:inProjektleiter:inProduct OwnerQA / Tester:in
25. August 20266 Min. Lesezeit

Vorweg das Wichtigste: Es gibt keinen Deal. Business Insider hat am Wochenende berichtet, Hugging Face lote einen Verkauf aus, heise und TechCrunch haben es am 24.08.2026 aufgegriffen. Das Unternehmen hat sich nicht geäußert, ein Käufer ist nicht bekannt, eine Einigung gibt es nicht. Was es gibt, ist eine Zahl: mindestens 13 Milliarden Dollar.

Trotzdem lohnt sich die Frage, was ein Eigentümerwechsel bedeuten würde. Nicht weil er kommt, sondern weil die Antwort zeigt, wie abhängig das eigene Setup ist.

Die Zahlen dahinter

Die letzte öffentlich bekannte Finanzierungsrunde stammt von 2023: 235 Millionen Dollar bei einer Bewertung von 4,5 Milliarden, angeführt von Salesforce Ventures. Ein Nvidia-Angebot über 500 Millionen bei 7 Milliarden Bewertung hat Hugging Face laut heise Ende 2025 abgelehnt. Im Juni 2026 lag der Umsatz nach Angaben von CEO Clément Delangue erstmals bei einer hochgerechneten Jahresrate von über 100 Millionen Dollar, 2025 war das Unternehmen profitabel.

Von 4,5 auf 13 Milliarden bei rund 100 Millionen Umsatz: Das ist ein Vielfaches, das ein Käufer wieder hereinholen will. Genau darin liegt die Frage für alle, die auf der Plattform aufbauen.

Delangue selbst hat TechCrunch gegenüber die Haltung beschrieben, die dagegen spricht: "We're building a platform for the community, and they're trusting us with sharing their data and their models on the platform, so we have a long-term responsibility to them." Das ist ein Argument gegen einen Verkauf, aber es ist eine Absichtserklärung und keine Struktur.

Was ein Käufer überhaupt monetarisieren könnte

Hugging Face ist für Teams, die offene Modelle selbst betreiben, der zentrale Bezugspunkt. Gewichte, Datasets, Tokenizer, Spaces und ein guter Teil der Toolchain hängen an einer Plattform in einer Hand. Die Hebel, an denen ein neuer Eigentümer drehen könnte, sind absehbar: Durchsatzlimits für anonyme Downloads, Bezahlpflicht für private Repos, Gebühren für Datasets, Vorrang für eigene Modelle im Ranking, oder eine Lizenzänderung an den Bibliotheken.

Solche Schritte kennt man. Nur endeten sie in den letzten Jahren selten so, wie der Käufer sich das gedacht hatte.

Der Ausweg, den es in diesem Feld schon gibt

Wenn eine Plattform oder ein Werkzeug nachträglich monetarisiert wird, entsteht regelmäßig eine freie Alternative. Der klarste Fall ist Terraform. Nach der Lizenzänderung im August 2023 gründete sich innerhalb von Wochen OpenTofu, heute unter dem Dach der Linux Foundation. Im OpenTofu-Manifest steht der Anspruch, der jede solche Abspaltung antreibt: "Truly open source - under a well-known and widely-accepted license that companies can trust, that won't suddenly change in the future, and isn't subject to the whims of a single vendor."

Bei Hugging Face wäre eine solche Abspaltung technisch besser vorbereitet als damals bei Terraform, und das aus zwei Gründen.

Erstens gehört der Plattform der Inhalt nicht. Modellgewichte und Datasets liegen unter den Lizenzen ihrer Herausgeber, überwiegend Apache 2.0, MIT oder vergleichbar. Wer ein Modell spiegelt, verletzt nichts, er kopiert etwas, das ohnehin frei ist. Das unterscheidet den Fall grundlegend von einer Codebasis, deren Lizenz der Eigentümer selbst ändert.

Zweitens ist der Client darauf ausgelegt, mit einem anderen Hub zu sprechen. In der offiziellen Dokumentation zu parse_hf_uri() steht als Parameter ausdrücklich: "A custom Hub endpoint (e.g. a self-hosted or proxied Hub like 'https://hub.my-company.com' or 'http://localhost:8080/hf')". Die Bibliothek liest denselben Endpunkt aus der Umgebungsvariable HF_ENDPOINT. Ein anderer Hub ist also keine Umbauarbeit an eurem Code, sondern eine Konfigurationszeile.

Damit sind die Bausteine für eine freie Alternative vorhanden: freie Inhalte, ein offener Client und ein austauschbarer Endpunkt. Was fehlt, ist niemand, der es tut, solange es keinen Anlass gibt.

Warum es trotzdem kein Selbstläufer wäre

Ein Hub ist mehr als Dateiablage. Was ein Nachbau nicht einfach mitkopiert: die Auffindbarkeit über Millionen Repos, die Moderation, der Freigabeprozess für Modelle mit Nutzungsbedingungen, der Dataset-Viewer, Spaces, die gehostete Inferenz und der soziale Teil aus Diskussionen, Modellkarten und Reputationen. Dazu kommt, dass Hugging Face die Übertragung inzwischen über das eigene Xet-Backend abwickelt statt über schlichtes Git-LFS. Das ist schnell, aber es ist plattformeigen.

Eine Abspaltung würde also den freien Teil retten und den bequemen Teil verlieren. Genau so lief es bei den bekannten Fällen auch, und genau deshalb kommt sie erst, wenn der Schmerz größer ist als die Bequemlichkeit.

Was ihr heute tun könnt

Der praktische Punkt hat mit dem Verkauf wenig zu tun und lohnt sich unabhängig davon:

Vier Fragen für die Exit-Checkliste:

  1. Welche Modelle zieht euer Build zur Laufzeit vom Hub? Jeder from_pretrained()-Aufruf ohne lokalen Pfad ist eine Abhängigkeit von einer fremden Verfügbarkeit, nicht nur von einem fremden Eigentümer.
  2. Liegen Gewichte, Tokenizer und Konfiguration gespiegelt bei euch? Mit Commit-Hash, nicht nur mit Modellnamen. Ein Tag kann verschoben werden, ein Hash nicht.
  3. Kennt ihr die Lizenz jedes eingesetzten Modells? Bei einem Plattformwechsel ist das die Frage, die entscheidet, ob ihr die Kopie überhaupt behalten dürft. Gated Models mit Zustimmungspflicht sind hier der Sonderfall.
  4. Ist der Endpunkt konfigurierbar oder hart verdrahtet? Wenn HF_ENDPOINT in eurer Umgebung wirkt, ist der Wechsel eine Variable. Wenn irgendwo huggingface.co im Code steht, ist er ein Ticket.

Das ist derselbe Gedanke wie bei jedem Werkzeugwechsel, nur an einer Stelle, die viele Teams nie als Abhängigkeit gesehen haben. Wie sich ein Eigentümerwechsel sonst auf Modell- und Datenstrategie auswirkt, steht in Wenn dein Werkzeug den Besitzer wechselt.

Quellen4