Open-Weight-Modelle dominieren die KI-Debatte gerade so stark wie nie zuvor. Im Juli veröffentlichte r/LocalLLaMA einen umfangreichen Architektur-Überblick zu 23 Modellen zwischen 20B und 500B Parametern – ein Beleg dafür, wie schwindelerregend groß der Katalog in nur wenigen Monaten geworden ist.
Gleichzeitig entspinnt sich eine ganz andere Debatte über das Grundprinzip offener Modelle, nachdem Anthropics offizielle Haltung zu Open Weights veröffentlicht wurde und in der Community sowohl auf Kritik als auch auf Verteidigung stieß.
Die beiden Diskussionen hängen auf eine Weise zusammen, die selten ausgesprochen wird: Je mehr offene Modelle es gibt, desto wichtiger wird die Frage, wer dafür sorgt, dass sie verantwortungsvoll betrieben werden.
Bei der Modellübersicht zählt die Architektur, nicht nur die Größe
Der wertvollste Punkt aus dem Survey-Thread ist eigentlich nicht die Liste der Modelle selbst – es ist die Erkenntnis, dass Architektur mehr zählt als die Parameterzahl. Ein MoE-Modell mit 235B Parametern kann zur Inferenzzeit weniger aktive Parameter haben als ein dichtes 30B-Modell, was die meisten intuitiven Vorstellungen von "Größe" auf den Kopf stellt.
Ein wirklich brauchbarer Überblick sollte daher zwischen Architekturtypen unterscheiden, statt einfach nach der Anzahl der Nullen zu sortieren:
| Model | Architektur | Größe | Ungefährer VRAM-Bedarf* | Lizenz |
|---|---|---|---|---|
| Mistral Shieldstral | Dense Vision-/Text-Klassifikator | 3B | ~16 GB | Apache 2.0 |
| Gemma 4 9B | Dense Textgenerierung | 9B | ~20 GB | Gemma Terms |
| Gemma 4 27B/31B | Dense Textgenerierung | 27-31B | 60-80 GB | Gemma Terms |
| Kimi K3 | MoE-Generierung (2,8B aktiv) | ~40-80 GB** | Custom open | |
| Llama 4 Scout | MoE-Generierung (17B x 16 Experten) | ~40-80 GB** | Llama 4 license | |
| Llama 4 Maverick | MoE-Generierung (400B gesamt) | ~200 GB+** | Llama 4 license | |
| Qwen3-235B-A22B | MoE-Generierung (22B aktiv) | ~80-120 GB** | Qwen license | |
| GLM-5.2 | MoE-Generierung (744B gesamt, 1M Kontext) | ~200 GB+** | Custom open | |
| DeepSeek-V3.1 | MoE-Generierung (671B gesamt) | ~200 GB+** | DeepSeek license |
* Ungefährer VRAM-Bedarf bei FP16/Quantisierung; Kontextlänge und Inference-Engine beeinflussen den tatsächlichen Verbrauch erheblich. ** MoE-Modelle laden bei der Inferenz in der Regel nur die aktiven Experten; der Overhead variiert je nach Implementierung stark.
Ein weiterer Punkt aus der Community verdient Aufmerksamkeit: der Unterschied zwischen tatsächlich offenen Modellen und solchen, die sich nur offen nennen, ohne die Gewichte freizugeben – in der Community wird vorgeschlagen, Letztere mit [no weights] zu kennzeichnen. Wer ein Modell fürs Self-Hosting auswählt, sollte genau das zuerst prüfen: Lassen sich die Gewichte tatsächlich herunterladen?
Von der Modellwahl zur Frage der Verantwortung
Damit sind wir beim zweiten Debattenstrang – und hier verbirgt sich die interessanteste Beobachtung mitten in der Kritik an Anthropics Position: Man kann sich offiziell gegen ein Verbot aussprechen und gleichzeitig Anforderungen stellen, die ein solches Verbot in der Praxis unumgänglich machen. Diese Art von Regulierung wird schnell zu einem De-facto-Verbot durch tausend Schnitte statt durch ein einziges, dramatisches Nein.
Es gibt außerdem eine logische Spannung, die man im Blick behalten sollte: Wie lässt sich eine Anti-Distillation-Haltung mit dem eigenen Training auf gewaltigen Datenmengen vereinbaren? Diese Art von Inkonsistenz untergräbt das Vertrauen, unabhängig von der inhaltlichen Substanz.
Doch mitten in der Kritik steckt auch ein Punkt, den Self-Hoster ernst nehmen sollten: ein offenes Modell verfügt über null eingebaute Sicherheitsmechanismen. Missbrauch lässt sich einer herunterladbaren Gewichtsdatei nicht wegdesignen – die Verantwortung verschiebt sich also zwangsläufig zu demjenigen, der das Modell tatsächlich betreibt.
Und genau hier wird der Hosting-Standort plötzlich strategisch statt rein technisch: Wenn Cloud-Anbieter potenziell gezwungen werden können, bestimmte offene Modelle nicht auf ihrer Infrastruktur zuzulassen, dann wird wo Ihre Workload läuft ebenso wichtig wie worauf sie läuft.
Managed Self-Hosting als Mittelweg
Das führt die Fäden sauber zu einem Argument zusammen:
Open Weights schenken Freiheit – doch diese Freiheit kommt mit drei konkreten Anforderungen:
- Sie müssen selbst kontrollieren können, wo das Modell läuft (Jurisdiktion)
- Sie müssen den Zugriff auf Ein- und Ausgabe selbst verwalten
- Sie müssen Ihre eigenen Guardrails bauen, da kein Filter mitgeliefert wird
Das ist der Kern von Managed Self-Hosting bei Liviate Cloud: Sie behalten das Eigentum am Modell und dessen Daten, während Isolation, Egress-Kontrolle und Betrieb in einem professionellen, EU-gehosteten Rahmen liegen – so erhalten Sie die Freiheit der Offenheit, ohne das gesamte Risiko allein zu tragen.
Zwei Debatten dominieren gerade: Die eine dreht sich um die Wahl des Modells, die andere darum, ob Offenheit überhaupt sicher genug ist. An der Oberfläche haben sie wenig gemeinsam – doch sie treffen sich an einem Punkt: bei der Person oder dem Unternehmen, das das Modell tatsächlich verantwortungsvoll hosten muss.
Die Wahl des Modells ist nur der erste Schritt; die Architektur bestimmt die benötigte Hardware, der [no weights]-Test steckt den Rahmen dessen ab, was sich tatsächlich herunterladen lässt – und die Debatte über Verantwortung definiert, wie sicher das Umfeld rund um das Modell gestaltet sein muss.