Open-Weight LLMs: Die richtige Wahl treffen
Cloud-Modelle sind bequem. Sie sind auch teuer, abhängig von US-Providern und oft an Rate-Limits gebunden. In den letzten Wochen hat sich die Debatte verschärft. Frontier-Modelle mit offenen Gewichten erreichen inzwischen Qualität, die bis vor kurzem nur geschlossenen Cloud-APIs vorbehalten war.
Simon Willison spricht in Oxide and Friends von einer „Open Weight Revolution“. Er stellt die richtigen Fragen: Wer ist dafür, wer dagegen – und machen offene Modelle unsere Zukunft sicherer oder gefährlicher?
Ich habe deshalb in den letzten Monaten Open-Weight-Modelle auf eigener Hardware getestet. Ziel war nicht, die Cloud komplett zu ersetzen, sondern herauszufinden, wann das lokale Modell die bessere Wahl ist.
Die zentrale Erkenntnis: Nicht jedes Modell passt auf jede Hardware. Und Quantisierung ist ein bewusster Trade-off zwischen Qualität und Ressourcenverbrauch.
Zwei Achsen, die oft verwechselt werden
Bevor es in die Praxis geht, lohnt eine Begriffsklärung. Open-Weight und Frontier beschreiben die Zugänglichkeit eines Modells. Cloud und Local beschreiben, wo es läuft. Die beiden Achsen sind unabhängig, werden in Diskussionen aber ständig vermischt.
Open-Weight-Modelle stellen ihre Gewichte zum Download bereit. Wer sie hat, kann sie überall betreiben: auf eigener Hardware, auf gemieteten Cloud-GPUs, auf einem Rechenzentrum vor Ort. Frontier-Modelle sind die jeweils leistungsfähigste Klasse – bisher überwiegend geschlossen und nur über API erreichbar.
| Achse | Frontier | Open-Weight |
|---|---|---|
| Definition | Beste Klasse, aktueller Stand der Technik | Gewichte öffentlich downloadbar |
| Zugriff | meist API-only, Closed Weights | beliebig, lokal oder in der Cloud |
| Qualität | Spitze | hinkt Frontier oft 6-12 Monate hinterher |
| Kontrolle | Anbieter entscheidet über Version, Limits, Daten | Betreiber entscheidet über alles |
Dazu kommt die zweite Achse. Ein Modell in der Cloud zu nutzen, heißt noch lange nicht, dass es ein Cloud-Modell im Sinne von proprietär ist. Viele Anbieter verleihen Open-Weight-Modelle als Service. Umgekehrt kann man dasselbe Open-Weight-Modell on-premise betreiben und hat dann lokale Kontrolle ohne Cloud-Anbindung.
| Achse | Cloud | Local / On-Premise |
|---|---|---|
| Infrastruktur | gemietet, beim Anbieter | eigene Hardware |
| Daten | verlassen das eigene Netz | bleiben im eigenen Netz |
| Latenz | Netzwerk-Roundtrip | lokal, vorhersagbar |
| Kosten | nutzungsbasiert, laufend | einmalige Hardware, Strom, Wartung |
| Abhängigkeit | Provider, Rate-Limits, Roadmap | eigene Kompetenz, eigene Treiber |
Die Kombination, die mich interessiert: Open-Weight-Modelle auf eigener Hardware. Das verbindet die Freiheit offener Gewichte mit der Kontrolle lokaler Infrastruktur. Genau diese Kombination habe ich getestet.
Was ich getestet habe
Auf einem NVIDIA GB10 Grace Blackwell mit 128 GB RAM laufen bei mir produktiv unterschiedliche Modelle seit April 2026.
Das Arbeitspferd ist Qwen 3.6 35B-A3B mit FP8-Quantisierung, 256K Kontext auf vLLM.
Es ist stabil im 24/7-Einsatz als Agenten-Backend. Für Code-Aufgaben nutze ich Qwen 3 Coder Next, ebenfalls FP8, mit 131K Kontext. Gemma 4 26B-A4B mit 262K Kontext läuft für Instruction-Following-Aufgaben.
Offene Gewichte: Revolution oder Risiko?
Die aktuelle Diskussion um Open Weights dreht sich um zwei Lager.
Befürworter argumentieren: Transparenz, unabhängige Audits, weniger Abhängigkeit von wenigen Cloud-Anbietern.
Kritiker warnen: Wer die Gewichte hat, kann das Modell ohne Filter, ohne Überwachung und ohne Rückrufmöglichkeit nutzen.
Beide Seiten haben Argumente. Willison stellte im Podcast Oxide and Friends: The Open Weight Revolution with Simon Willison die richtige Gegenfrage: Machen geschlossene Modelle die Welt tatsächlich sicherer?
Der Hugging Face Security Incident vom Juli 2026 hat gezeigt, dass auch die Evaluierungs- und Vertriebsinfrastruktur der großen Anbieter angreifbar ist.
Sicherheit durch Geheimhaltung ist ein schwaches Konzept, wenn die Infrastruktur selbst Löcher hat.
Meine Position ist pragmatisch: Offene Gewichte verschieben die Kontrolle vom Anbieter zum Betreiber.
Wer selbst hostet, entscheidet über Quantisierung, Prompt-Filter, Netzwerk-Isolation und Auditing. Für Unternehmen, die ihre Daten nicht in fremde Clouds geben wollen, ist das ein konkreter Vorteil.
Gleichzeitig ist klar: Nicht jedes Open-Weight-Modell ist gleich. Manche kommen mit restriktiven Lizenzen, manche mit unklaren Trainingsdaten, manche sind für kommerzielle Nutzung ungeeignet.
Die Wahl eines passenden Modells ist auch eine Lizenz- und Compliance-Entscheidung.
Was funktioniert, was überrascht
Nach rund zweieinhalb Monaten Produktionseinsatz seit April 2026 haben sich ein paar Erkenntnisse gefestigt. FP8 ist mein neuer Standard: 50 Prozent Speicherreduktion bei unter fünf Prozent Qualitätsverlust.
Qwen 3.6 35B-A3B läuft dabei rund um die Uhr ohne Ausfälle. Für Agentic Use-Cases war die Context-Länge wichtiger als die Parameterzahl. 256K Kontext schlägt in meinen Tests ein größeres Modell, wenn es um mehrstufige Aufgaben geht – es ist deutlich responsiver, bei keinem spürbaren Qualitätsverlust. In Ausnahmefällen kam es bei Problemen, wenn Tasks lange (> 4h) liefen.
Zwei Dinge haben mich überrascht.
Erstens: Treiber-Support wiegt schwerer als Hardware-Specs. Auf Consumer-GPUs kam ich wegen eines fehlenden Vulkan-Treibers nur auf 8,7 Tokens pro Sekunde, statt der über 30, die die Hardware hergegeben hätte.
Zweitens: Ohne Observability findet man keine Bottlenecks. Erst die 379 vLLM-Metriken, die ich über Langfuse sammle, machten Performance-Engpässe sichtbar, die ich vorher nicht gesehen hatte.
Migration als dreistufiger Prozess
Für Entscheider empfehle ich eine Evaluation in drei Phasen.
- Zuerst misst man den aktuellen Cloud-Provider als Baseline (z. B. mit lightLLM als MITM Proxy) und richtet ähnliche Hardware ein.
- Dann folgt Pilot-Testing mit echten Workloads. In Phase zwei laufen identische Prompts parallel auf Cloud-Modell und lokalem Modell, um Qualität, Latenz und Kosten zu vergleichen.
- Phase drei ist die Go-Live-Entscheidung, die eine ROI-Rechnung, eine Fallback-Strategie und möglicherweise einen Hybrid-Ansatz braucht.
Ich persönlich setze heute auf einen Hybrid-Stack: Standard-Aufgaben laufen lokal, Edge-Cases und Tests gegen neue Modelle gehen noch in die Cloud. Eine bewusste Gewichtung nach Risiko und Kosten.
Was bleibt
- Open-Weight LLMs lohnen sich, wenn man sie richtig einsetzt.
- Sie geben Kontrolle über Daten und Kosten, entkoppeln sich von Anbieter-Roadmaps und ermöglichen tiefgehende Observability. Aber sie kosten Zeit, Know-how und Hardware.
- INT4 funktioniert nicht automatisch gut, Treiber können einen Strich durch die Rechnung machen, und größere Modelle sind oft ökonomisch unsinnig.
Die aktuelle Open-Weight-Revolution ändert die Ausgangslage. Frontier-Modelle mit offenen Gewichten sind keine Experimente mehr. Wer migrieren will, sollte mit einem realistischen Test-Setup starten. Als Startpunkt taugt das passende (ausreichende) Modell, nicht das größte.
Wie sieht es bei euch aus: Setzt ihr Open-Weight-Modelle produktiv ein, oder bleibt ihr bei der Cloud? Ich bin gespannt auf eure Erfahrungen mit Hardware, Quantisierung und Kosten – teilt sie gerne in den Kommentaren.
Quellen
- Oxide and Friends: The Open Weight Revolution with Simon Willison — Diskussion über offene Gewichte, Sicherheit und das Hugging Face Security Incident
- Hugging Face Blog: Security Incident July 2026
- OpenAI: Hugging Face model evaluation security incident
