Tencent Hy4: ein Open-Weight-Modell mit 770B und was es für Ihr Unternehmen bedeutet

Die direkte Antwort: Am 28. August 2026 hat Tencent Hy4 preview als Open-Weight-Modell unter der Lizenz Apache 2.0 veröffentlicht, mit insgesamt 770 Milliarden Parametern, von denen nur 49 Milliarden pro Token aktiv sind, und einem Kontextfenster von bis zu einer Million Tokens. In der Praxis heißt das: Jedes Unternehmen kann das Modell herunterladen und auf der eigenen Infrastruktur betreiben, ohne Erlaubnis des Anbieters und ohne Gebühr pro Aufruf. Es heißt nicht, dass Sie es auf einem Server in Ihrem Büro betreiben können. Der Abstand zwischen diesen beiden Sätzen entscheidet, ob diese Nachricht Sie überhaupt betrifft.

Was tatsächlich angekündigt wurde

Vor jeder Analyse hilft es, veröffentlichte Fakten von Interpretation zu trennen. Was Tencent im offiziellen Repository des Modells veröffentlicht hat, umfasst:

  • Größe und Aktivierung: insgesamt 770 Milliarden Parameter, davon 49 Milliarden pro Token aktiv, in einer Mixture-of-Experts-Architektur.
  • Interner Aufbau: 78 Schichten, die erste dicht und die übrigen Mixture-of-Experts mit 256 gerouteten Experten plus einem geteilten Experten, wobei pro Token acht Experten ausgewählt werden.
  • Kontextfenster: eine Million Tokens, bei einer Vokabulargröße von 120.832.
  • Lizenz: Apache 2.0, eine permissive Lizenz, die kommerzielle Nutzung, Änderung und Weiterverbreitung erlaubt.
  • Quantisierte Variante: Neben dem Modell in voller Präzision ist eine FP8-Version verfügbar.
  • Inferenzbeschleunigung: eine integrierte Multi-Token-Prediction-Schicht, die spekulatives Decoding unterstützt.
  • Erklärter Schwerpunkt: Das Modell zielt auf Programmierung, Büroproduktivität, Spieleentwicklung und wissenschaftliche Forschung statt auf allgemeinen Chat.

Nicht angekündigt wurde, und das sollte man auch nicht annehmen, irgendein Versprechen der Überlegenheit gegenüber geschlossenen Modellen in Ihrem konkreten Fall. Veröffentlichte Vergleiche auf öffentlichen Benchmarks sagen nichts Verlässliches über die Leistung bei Ihren Dokumenten, der Sprache Ihrer Kunden und dem Kontext Ihrer Branche. Diese Antwort liefern nur interne Tests mit Ihren eigenen Daten.

Warum die Lizenz Apache 2.0 kein kleines juristisches Detail ist

Der Großteil der Diskussion über offene Modelle dreht sich um die Ausgabequalität, während der eigentliche Wert für Unternehmer in der Lizenzklausel liegt. Eine permissive Lizenz bedeutet drei praktische Dinge: Der Betrieb des Modells in Ihrer Infrastruktur braucht niemandes Zustimmung, das Modell mit Ihren Daten zu verändern und anzupassen ist erlaubt, und die Kontinuität Ihres Dienstes hängt nicht davon ab, dass ein Anbieter es weiter anbietet oder seine Preise stabil hält.

Dieser letzte Punkt ist der Kern der Sache. Ein Unternehmen, das seinen gesamten Kundenservice auf einer einzigen API aufgebaut hat, trägt ein stilles Risiko: Eine Preisänderung, eine abgekündigte Version oder eine geänderte Nutzungsrichtlinie kann es zurück auf Feld eins werfen. Ein Open-Weight-Modell beseitigt dieses Risiko nicht, aber es gibt Ihnen einen Ausweg: Die Kopie, die Sie heruntergeladen haben, bleibt Ihre.

Die Hardware-Rechnung, die die Schlagzeile meist auslässt

Hier wird aus Begeisterung eine Zahl. 770 Milliarden Parameter in FP8-Präzision bedeuten rund ein Byte pro Parameter, also mehr als 700 Gigabyte allein für die Modellgewichte, bevor irgendetwas anderes dazukommt. Rechnen Sie den Kontextspeicher hinzu, der mit der Gesprächslänge wächst, und ein Fenster von einer Million Tokens bedeutet im realen Einsatz erheblichen zusätzlichen Speicher; dann kommt noch Redundanz hinzu, damit der Dienst nicht ausfällt, wenn ein einzelner Knoten versagt.

Die Schlussfolgerung: Dies ist ein Rechenzentrumsmodell, kein Modell für den Büroserver. Es selbst zu hosten ist eine Entscheidung, die spezialisierte Hardware erfordert und ein Betriebsteam, das ein Modell über mehrere GPUs verteilen und Latenz und Auslastung überwachen kann. Das sind Fixkosten, die nicht sinken, wenn Ihre Nutzung zurückgeht, anders als bei einer API, bei der Sie für das zahlen, was Sie verbrauchen.

Die praktische Regel: Self-Hosting ist nur unter einer von zwei Bedingungen sinnvoll. Entweder haben Sie eine große, gleichmäßige Nutzung, durch die Fixkosten günstiger sind als variabler Verbrauch, oder Sie unterliegen einer regulatorischen oder vertraglichen Anforderung, die verhindert, dass Daten eine definierte Grenze verlassen. Außerhalb dieser beiden Bedingungen ist Self-Hosting meist eine emotionale und keine wirtschaftliche Entscheidung.

Was das Design technisch interessant macht

Die auffällige Zahl bei Hy4 ist nicht 770 Milliarden, sondern 49 Milliarden. Eine Mixture-of-Experts-Architektur bedeutet, dass das Modell eine enorme Kapazität hat, pro Token aber nur einen kleinen Teil von sich aktiviert, sodass Sie Qualität auf Flaggschiff-Niveau zu Rechenkosten erhalten, die eher einem mittelgroßen Modell entsprechen. Genau diese architektonische Richtung hat offene Modelle in den vergangenen zwei Jahren nah an geschlossene herangeführt.

Hinzu kommen ein Sparse-Attention-Mechanismus, der Sparsity-Indizes über Schichten hinweg wiederverwendet, und eine integrierte Multi-Token-Prediction-Schicht, die spekulatives Decoding ermöglicht und so die Generierungszeit verkürzt. In Geschäftssprache: Diese Details senken die Kosten pro Token und die Latenz, und diese beiden Faktoren entscheiden, ob eine Funktion für Tausende von Nutzern ausgerollt werden kann oder ein internes Experiment bleibt.

Drei praktische Wege für Ihr Unternehmen

  • Eine verwaltete API auf einem geschlossenen Modell: der schnellste Weg zum Start, ohne Betriebsaufwand und mit variablen Kosten, die mit der Nutzung wachsen. Der Standardweg für die ersten sechs Monate jedes Produkts.
  • Hy4 über einen Anbieter, der es für Sie hostet: Sie erhalten die Flexibilität der Lizenz und die Möglichkeit, zwischen Anbietern zu wechseln, ohne Hardware zu kaufen. Das ist der praktische Mittelweg, den viele übersehen.
  • Vollständiges Self-Hosting: maximale Kontrolle und maximale Kosten. Gerechtfertigt, wenn Sie einer strengen Anforderung an die Datenresidenz unterliegen oder ein großes, stabiles Betriebsvolumen haben.

Die Fragen, die die Entscheidung klären

Bevor Sie einen einzigen Riyal für diesen Weg ausgeben, beantworten Sie ehrlich vier Fragen. Welche Art von Daten wird durch das Modell laufen, und verhindert eine regulatorische oder vertragliche Pflicht, dass sie nach außen gehen? Wie hoch ist das erwartete monatliche Volumen in sechs Monaten, nicht in der ersten Woche? Haben Sie oder Ihr Technologiepartner eine echte Betriebsfähigkeit rund um die Uhr? Und haben Sie in Ihrer Anwendung eine Abstraktionsschicht gebaut, mit der Sie Modelle austauschen können, ohne das Produkt neu zu schreiben?

Wenn die Antwort auf die letzte Frage nein lautet, ist das Ihre Priorität vor jeder Diskussion darüber, welches Modell Sie nutzen. Der Unterschied zwischen einem flexiblen und einem gefangenen Unternehmen liegt nicht in der Wahl des richtigen Modells, sondern im Aufbau eines Systems, das die Wahl später zu vertretbaren Kosten änderbar hält. Lesen Sie unseren Artikel über eine lokale Cloud-Region und Datenresidenz, wenn die Datenresidenz Ihr Hauptgrund ist.

Wie wir das bei Origami handhaben

Wir bauen Kundenanwendungen so, dass das Modell eine austauschbare Komponente hinter einer einheitlichen internen Schnittstelle ist, und wir pflegen ein Evaluierungsset mit echten Kundenfällen, das wir gegen jedes Kandidatenmodell laufen lassen, bevor wir es einsetzen. Das macht aus Nachrichten wie der Veröffentlichung von Hy4 statt einer technischen Schlagzeile eine messbare Entscheidung: Evaluierungsset laufen lassen, Qualität, Kosten und Latenz vergleichen und dann auf Basis von Zahlen statt Eindrücken entscheiden.

Quellen