Open-Source-KI im April 2026: Sechs Modelle, eine Verschiebung

Innerhalb weniger Tage im April 2026 erschienen drei Open-Source-Modelle, die dasselbe Problem unterschiedlich lösen.

Die Ausgangslage ist dieselbe: Cloud-APIs werden teurer, Datenschutzanforderungen strenger, und die Abhängigkeit von wenigen US-Anbietern unbequemer. Die Schlussfolgerungen jedoch unterscheiden sich grundlegend: Googles Gemma 4 setzt auf maximale Fähigkeiten unter offener Lizenz, PrismMLs Bonsai 8B auf radikale Effizienz, und Alibabas Qwen3.6-Plus auf Enterprise-Tauglichkeit für Tools, Workflows und function calling.

Gemma 4: Wenn Open Source Gemini-Niveau erreicht

Google hat Gemma 4 am 2. April 2026 veröffentlicht – und dabei gleich zwei Dinge geändert, die zusammen mehr bedeuten als jedes einzelne.

Erstens die Fähigkeiten: Gemma 4 ist aus derselben Forschung entstanden wie Gemini 3. Alle Modellgrößen (E2B, E4B, 26B MoE, 31B Dense) verarbeiten Text und Bilder nativ, die größeren Varianten auch Audio. Kontextfenster bis 256K Tokens, Unterstützung für über 140 Sprachen, ausgelegte Eignung für agentenbasierte Workflows und Reasoning-Aufgaben. Das E2B-Modell läuft auf einem Raspberry Pi.

Zweitens die Lizenz: Nach Jahren eines restriktiven Custom-Lizenzmodells wechselt Google vollständig auf Apache 2.0 – dieselben Bedingungen wie Mistral, Qwen und Llama. Voll kommerziell nutzbar ohne Auflagen, keine Berichtspflichten, keine Nutzungsbeschränkungen.

Auf Google Cloud steht Gemma 4 über Vertex AI, Cloud Run (mit NVIDIA RTX PRO 6000 Blackwell GPUs), GKE und TPUs bereit. Besonders relevant: Gemma 4 ist in alle Sovereign-Cloud-Varianten von Google integriert – inklusive air-gapped Deployments für Behörden und regulierte Branchen. Wer Modelle lokal betreiben muss und gleichzeitig auf Gemini-nahes Niveau nicht verzichten will, bekommt damit eine ernsthafte Option – auch für Szenarien, in denen DSGVO-Konformität die Modellwahl bestimmt.

Bonsai 8B: 1 Gigabyte, 44 Tokens pro Sekunde

PrismML ist am 31. März 2026 aus dem Stealth-Modus herausgekommen – mit einem technischen Ansatz, der auf den ersten Blick wie ein Kompromiss wirkt, aber keiner ist.

Das Kernprinzip: Jedes Gewicht im Modell kennt nur drei Werte (-1, 0, +1). Keine Fließkommazahlen, keine teuren Multiplikationen. Multiplizieren mit 0 ist ein No-op, mit 1 eine Identität, mit -1 ein Vorzeichenwechsel. Das klingt trivial – bedeutet in der Praxis aber, dass das 8B-Modell von 16 GB auf 1,15 GB schrumpft und gleichzeitig 8-mal schneller läuft als ein Standard-16-Bit-Llama-3-Modell.

Die Zahlen: 136 Tokens pro Sekunde auf einem M4 Pro Mac, 44 Tokens pro Sekunde auf einem iPhone 17 Pro Max, 0,068 mWh pro Token (rund 5-mal effizienter als 16-Bit-Modelle). Alle drei Varianten (8B, 4B, 1.7B) sind unter Apache 2.0 auf HuggingFace verfügbar.

Was Bonsai für die Praxis interessant macht, ist nicht das Benchmark-Ergebnis, sondern das Kostenmodell: kein API-Pricing, kein Datentransfer, kein Vendor. Ein Modell, das lokal läuft und skaliert wie eine Anwendung – nicht wie ein Cloud-Dienst. Warum lokale KI gerade wieder so relevant wird, hat strukturelle Gründe, die über Kosten hinausgehen.

PrismML gibt zu, dass die aktuelle 8-fache Beschleunigung primär aus dem reduzierten Speicherverbrauch kommt, nicht aus spezialisierter Hardware. Mit Chips, die für ternäre Operationen optimiert sind, wäre laut dem Unternehmen ein weiterer Faktor 10 realistisch.

Qwen3.6-Plus: Agentic-Fokus aus China

Alibaba hat am 2. April 2026 Qwen3.6-Plus veröffentlicht – eine iterative Weiterentwicklung der Qwen3-Linie, die im April 2025 mit dem damals bemerkenswerten Ergebnis erschien, OpenAI o1 und DeepSeek R1 zu übertreffen.

Qwen3.6-Plus ist auf Unternehmenseinsatz und agentenbasierte Workflows ausgelegt: 1-Million-Token-Kontextfenster, Multimodalität, function calling und structured output als Kernfähigkeiten. In Coding-Benchmarks liegt das Modell auf dem Niveau von Claude 4.5 Opus.

Die praktische Bedeutung: Für Teams, die Agenten bauen, die große Codebases oder Dokumentenmengen verarbeiten müssen, ist das Kontextfenster oft der limitierende Faktor. Ein Modell, das 1 Million Tokens verarbeitet und unter Apache 2.0 lokal betrieben werden kann, ist für viele Enterprise-Anwendungsfälle relevant – insbesondere wo Daten das Unternehmen nicht verlassen dürfen.

DeepSeek V4: Zwei Varianten, eine Million Token

DeepSeek V4 erschien im April 2026 als Zwei-Varianten-Modell: V4-Pro und V4-Flash. V4-Pro kommt mit rund 1,6 Billionen Parametern gesamt, davon etwa 49 Milliarden aktiv bei der Inferenz – Mixture-of-Experts wie inzwischen üblich für diese Größenordnung. Das Besondere ist der Kontextrahmen: 1 Million Token in der Preview-Version, direkt vergleichbar mit Qwen3.6-Plus.

V4-Flash ist die kostenbewusstere Variante: rund 284 Milliarden Parameter gesamt, 13 Milliarden aktiv, deutlich schneller und günstiger zu betreiben. Für Unternehmen, die Token-intensive Agenten-Workflows betreiben, ist das ein relevanter Unterschied – nicht jede Anfrage braucht das volle V4-Pro-Niveau.

In Mathematik-, STEM- und Programmierbenchmarks liegt V4 unter den Top-Open-Source-Modellen, knapp hinter GLM-5. Die Kombination aus 1-Million-Token-Kontext und verfügbaren Gewichten macht es besonders für Teams attraktiv, die große Codebases vollständig im Kontext halten wollen – ohne proprietäre API-Kosten. Für Firmen, die über Router-Plattformen wie OpenRouter oder Atlas Cloud betreiben, ist V4-Flash dabei oft die sinnvollere Wahl.

Kimi K2.6: State-of-the-Art in Open-Source-Coding

Moonshot AIs Kimi K2.6 ist das Modell, das in Coding-Benchmarks am lautesten auffällt. Kimi-Dev-72B, ein spezialisiertes Coding-Submodell der Kimi-Familie, erreicht 60,4 Prozent auf SWE-bench Verified – State-of-the-Art unter Open-Source-Coding-Modellen. SWE-bench misst, wie gut ein Modell echte GitHub-Issues in realen Repositories lösen kann; 60,4 Prozent ist ein Wert, der auch gegen kommerzielle Frontiermodelle mithalten kann.

Die Architektur: Mixture-of-Experts mit rund 1 Billion Parametern gesamt, davon etwa 32 Milliarden aktiv pro Anfrage, 256.000 Token Kontextfenster, multimodal. Der Kernfokus liegt auf komplexen Programmieraufgaben, Agenten-Workflows und Tool-Nutzung – erkennbar kein General-Purpose-Modell, sondern ein Engineering-Werkzeug.

Für Teams, die autonome Software-Workflows bauen – Agenten, die selbstständig Code-Reviews, Refactorings oder Bugfixes durchführen – ist Kimi K2.6 ein ernstzunehmender Kandidat. Günstiger als viele kommerzielle Frontiermodelle bei vergleichbarer Code-Qualität ist dabei kein Marketingversprechen, sondern ein messbarer Wert.

GLM-5: Zhipu AIs Frontiermodell

Zhipu AIs GLM-5 ist das größte Modell dieser Welle: rund 744 Milliarden Parameter gesamt, etwa 40 Milliarden aktiv, optimiert auf Token-Effizienz und langfristiges Reasoning. Das Kontextfenster liegt bei 200.000 Token – kleiner als DeepSeek V4 und Qwen3.6-Plus, aber ausreichend für die meisten Engineering-Workflows.

Ein Aspekt, der GLM-5 von den anderen unterscheidet: Es ist speziell für chinesisch produzierte Chips entwickelt worden. Für europäische Unternehmen zunächst keine Priorität – für Firmen mit eigener asiatischer Infrastruktur oder mit der Anforderung, unabhängig von NVIDIA-Hardware zu sein, ist es ein relevantes Detail.

In Benchmarks für Reasoning, Coding und Agenten liegt GLM-5 an der Spitze der Open-Weights-Modelle – teils sogar vor DeepSeek V4 bei STEM-Aufgaben. Als das ambitionierteste Release dieser Welle ist es zugleich das mit dem höchsten Infrastrukturbedarf im Betrieb.

Sechs Modelle, eine Verschiebung

Was diese sechs Releases gemeinsam haben, ist weniger das Technische als das Strategische: Alle reagieren auf denselben Sog weg von proprietären Cloud-APIs.

Gemma 4 Frontier-Fähigkeiten, Apache 2.0, Sovereign-Cloud-fähig – für alle, die nicht auf Gemini-Niveau verzichten wollen

Bonsai 8B 1 GB, läuft auf jedem Gerät, kein API-Pricing – für Anwendungen wo Latenz, Privacy oder Kosten entscheiden

Qwen3.6-Plus 1M-Token-Kontext, agentenoptimiert – für Workflows mit großen Dokumenten oder Codebases

DeepSeek V4 1M Token Kontext, Pro & Flash Varianten – für große Codebases und kostensensitive Agenten-Workflows

Kimi K2.6 60,4% SWE-bench, Coding-fokussiert – für autonome Software-Workflows und Code-Agenten

GLM-5 Frontier-Reasoning, 744B Parameter, Chip-Flexibilität – für komplexes Engineering-Reasoning auf eigener Infrastruktur

Die Frage ist nicht mehr, ob lokale Modelle stark genug sind – sondern welches Modell zu welchem Anwendungsfall passt.

Welches Modell für welchen Use Case?

Modell	Stärke	Schwäche	Ideal für
Gemma 4	Leistung, Multimodalität	Infrastruktur nötig	Enterprise, Compliance
Bonsai 8B	Effizienz, Größe	Qualität noch unklar	Edge, Mobile, Offline
Qwen3.6-Plus	Kontext, Agentic	Komplexität im Betrieb	Agenten, große Codebases
DeepSeek V4-Pro	1M Token Kontext, Open Weights	US-China-Kontext	Große Codebases, Compliance-Szenarien
Kimi K2.6	Coding (60,4 % SWE-bench)	Noch früh verfügbar	Autonome Software-Workflows
GLM-5	Frontier-Reasoning, Chip-Flexibilität	Größter Infrastrukturbedarf	Engineering-Reasoning, komplexe STEM

Noch konkreter:

Wenn du heute GPT oder Claude ersetzen willst → Gemma 4
Wenn du Infrastrukturkosten eliminieren willst → Bonsai 8B
Wenn du ernsthaft Agenten baust → Qwen3.6-Plus oder Kimi K2.6
Wenn du maximale Kontexttiefe brauchst → DeepSeek V4-Pro
Wenn du Frontier-Reasoning lokal brauchst → GLM-5

Wo die Modelle (noch) nicht mithalten

Alle drei Releases klingen fast zu gut. Was der Kontext ausblendet:

Gemma 4 setzt GPU- oder TPU-Infrastruktur voraus. Das E2B-Modell läuft auf einem Raspberry Pi – die größeren Varianten nicht. Fine-Tuning und Betrieb bleiben komplex, Sovereign-Cloud-Deployments erfordern Setup-Aufwand.

Bonsai 8B ist seit wenigen Wochen verfügbar. Unabhängige Benchmarks fehlen noch, die Qualität bei komplexem Reasoning ist unklar, und das Modell hat vermutlich Limits bei anspruchsvollen Coding-Aufgaben oder langen Kontexten. Die Zahlen stammen bisher ausschließlich von PrismML selbst.

Qwen3.6-Plus ist infrastrukturell schwergewichtig – 1 Million Token Kontext ist eindrucksvoll, aber der Betrieb erfordert entsprechende RAM- und GPU-Ressourcen. Agenten-Setups sind kein Plug-and-Play. Und je nach Deployment-Kontext ist die Compliance-Einschätzung für europäische Branchen ein Thema, das gesondert bewertet werden muss.

Was das wirklich kostet

Der Wechsel von API zu Self-Hosted ist kein kostenfreier Schritt – nur ein anderer Kostenpunkt.

Gemma 4 (self-hosted): GPU-Betrieb liegt je nach Modellgröße und Last bei mehreren hundert Euro pro Monat aufwärts. Dazu kommen Ops-Aufwand und initiales Setup. Über Google Cloud lässt sich das abfedern – aber dann ist der Vendor wieder im Spiel.

Bonsai 8B: Infrastrukturkosten praktisch null auf vorhandener Hardware. Das Modell läuft auf dem Gerät, das bereits da ist – ob Mac, Server oder Mobilgerät. Der Kostenvorteil gegenüber API-Pricing ist bei mittlerem Volumen sofort spürbar.

Qwen3.6-Plus: Kein API-Pricing, aber hoher Ressourcenbedarf im Betrieb. RAM und GPU für 1-Million-Token-Kontext sind nicht trivial. Das Modell rechnet sich erst bei hohem Anfragevolumen oder besonders sensiblen Daten, die das Unternehmen nicht verlassen dürfen.

Was sich gerade wirklich verschiebt

Das Interessante ist nicht, dass Open-Source-Modelle besser werden – das war absehbar. Was sich strukturell ändert, ist grundlegender:

Compute wandert zurück zum Nutzer. Frontier-fähige Modelle laufen auf Geräten, die man bereits besitzt. Das verschiebt die Verhandlungsposition gegenüber Cloud-Anbietern.

Modelle werden austauschbar. Wer auf Apache-2.0-Modellen aufbaut, ist nicht an einen Anbieter gebunden. Der Lock-in verschiebt sich – von der Modellwahl zur Infrastruktur und zum eigenen Daten-Setup.

Der Wettbewerb findet nicht mehr nur zwischen Modellen statt, sondern zwischen Betriebsmodellen: API-as-a-Service gegen Self-Hosted gegen Edge-Deployment. Gemma 4, Bonsai 8B und Qwen3.6-Plus sind drei verschiedene Antworten auf dieselbe Frage: Wie viel Kontrolle willst du, und was bist du bereit dafür zu betreiben?