Kategorie: KI-News

Du entwickelst einen automatischen Assistenten, der Software repariert, mit deinem Terminal kommuniziert und mehrfach nachdenkt, bevor er ein Werkzeug einsetzt. Zwei unterschiedliche Motoren stehen zur Wahl. Der eine ist klein, kompakt und läuft auf deinem Arbeitsrechner. Der andere ist ein Gigant, der nur auf teuren Spezial-GPUs funktioniert, aber ganze Code-Repositorien durchforsten kann. Genau diesen Größenvergleich zeigt die aktuellen Veröffentlichungen der Agentic-KI-Modelle Nanbeige 4.2-3B und Laguna S 2.1. Beide sind für agentische Arbeitslasten optimiert – Aufgaben, die mehrstufiges Denken, Werkzeugeinsatz und Interaktion mit externen Umgebungen erfordern. Die Umsetzung dieser Fähigkeiten könnte unterschiedlicher kaum sein.

Die Analyse zeigt die Stärken und Grenzen beider Architekturen. Nanbeige 4.2-3B ist ein kompaktes dichtes Modell mit etwa vier Milliarden Parametern, davon etwa drei Milliarden nicht zu den Einbettungen zählend. Laguna S 2.1 ist ein Mischung-von-Experten-Modell (MoE) mit 118 Milliarden Parametern, pro Token werden jedoch nur rund acht Milliarden aktiviert. Nanbeige durchläuft die gleichen Gewichte mehrfach. Laguna greift auf einen großen Expertenpool zu, wählt für jeden Schritt nur einen Bruchteil aus. Das ist nicht nur Skalierung, sondern ein grundlegend verschiedener Ansatz: zweimal rechnen mit wenig Speicher gegen einmal rechnen mit riesigem, sparsam genutztem Wissen.

Nanbeige 4.2-3B: Kompakter Kraftprotz mit Schleifenarchitektur

Die Architektur von Nanbeige hat sich grundlegend geändert. Statt einer einfachen Llama-Struktur setzt das Modell auf einen Looped Transformer. Es gibt 22 physische Decoder-Layer, die zweimal durchlaufen werden – die gleichen Gewichte werden im zweiten Durchlauf wiederverwendet. Rechnerisch entspricht das etwa 44 Layer-Ausführungen, ohne 44 unabhängige Layer speichern zu müssen. Das reduziert den Gewichtsspeicher, nicht aber die Rechenzeit für die Inferenz. Jeder Token läuft tatsächlich zweimal durch den Transformer-Stapel. Das Modell hat 48 Aufmerksamkeitsköpfe mit einer Dimension von 128 sowie acht Key/Value-Köpfe. Im Vergleich zu anderen Modellen dieser Größe sind das viele – Qwen 3.6 35B A3B hat nur zwei KV-Köpfe.

Diese Schleifenstruktur bringt Herausforderungen für den KV-Cache. Teilt die Implementierung nicht explizit den Cache-Zustand zwischen den Durchläufen, benötigt jede Schleife eigene Key/Value-Einträge. Die Standardkonfiguration von Nanbeige scheint diese gemeinsame Nutzung nicht zu aktivieren. Der KV-Cache verbraucht etwa 176 KiB pro gecachten Token und aktiver Sequenz. Bei 16.000 Tokens Kontextlänge wären das rund 2,75 GiB, bei maximalen 256.000 Tokens etwa 44 GiB – fast doppelt so viel wie ein Qwen 3.6 mit 27 Milliarden Parametern bei gleicher Länge. Das ist eine beachtliche Menge, die selbst für ein 3B-Modell die Hardwareanforderungen erhöht. Eine GPU mit 16 GB VRAM kann das Modell bei moderaten Kontextlängen und sorgfältigen Einstellungen noch ohne Quantisierung betreiben. Eine 24-GB-GPU bietet mehr Spielraum für längere Prompts und höhere Gleichzeitigkeit.

Der Autor schlägt für Looped Transformer eine eigene Namenskonvention vor – ähnlich wie bei kleinen MoE-Modellen mit der Anzahl aktiver Parameter (etwa 26B-A4B). Für Nanbeige wäre „3B-2P“ (zwei Durchläufe) passend. Wer ein 3B-Modell herunterlädt, erwartet nicht, dass es annähernd so langsam ist wie ein 6B-Modell. Bei der Veröffentlichung stellte das Entwicklerteam eine spezielle vLLM-Version sowie einen Chat-Template mit zwei Steuerungsmöglichkeiten bereit: enable_thinking bestimmt, ob die aktuelle Antwort eine explizite Denkphase enthält, und preserve_thinking legt fest, ob Denkinhalte aus früheren Assistentenantworten erhalten bleiben. Für normale Chats und Frage-Antwort-Aufgaben kann man die Denkspuren abschalten. Für mehrstufige Werkzeugnutzung, Büro-Workflows und Coding-Agenten empfehlen die Entwickler, diese Inhalte zu behalten. Der Autor zeigt sich skeptisch: Denkspuren können 50.000 Tokens oder mehr umfassen. Selbst eine einzige gespeicherte Denkspur kann beim nächsten Schritt die maximale Kontextlänge erreichen lassen.

Trotz dieser Einschränkungen zeigt die veröffentlichte Evaluierung, dass Nanbeige das deutlich größere Qwen 3.5-9B auf den meisten agentischen, Code- und Denkaufgaben übertrifft. Auch Gemma 4 12B wird auf Benchmarks wie GDPval, SWE-Bench Verified, SWE-Bench Pro und Terminal-Bench 2.0 geschlagen. Die Ergebnisse hängen stark von der erlaubten Denk-Budget, den Werkzeugdefinitionen, der Prompting-Strategie, der Gesprächsverwaltung, der Wiederholungspolitik und der maximalen Anzahl von Aktionen ab. Für ein Modell dieser Größe ist das beachtlich.

Laguna S 2.1: Code-Riese mit Expertenmix

Ganz anders gelagert ist Laguna S 2.1, ein auf Code spezialisiertes MoE-Modell mit 118 Milliarden Parametern, pro Token werden etwa acht Milliarden aktiviert. Ein Routing-Mechanismus wählt während der Inferenz eine Teilmenge der Experten aus. So greift das Modell auf einen großen Pool gelernter Parameter zu, ohne jeden einzelnen für jeden Token auszuführen. Laguna besteht aus 48 Transformer-Layern. Zwölf nutzen globale Aufmerksamkeit, die restlichen 36 verwenden Sliding-Window-Aufmerksamkeit mit einem Fenster von 512 Tokens. Die globalen und lokalen Layer sind ungefähr im Verhältnis eins zu drei angeordnet. Globale Layer erlauben Informationsfluss über den gesamten Eingabekontext. Lokale Layer beschränken die Aufmerksamkeit auf nahe Tokens, reduzieren so Kosten für lange Kontexte und das KV-Cache-Wachstum.

Das Modell enthält 256 geroutete Experten und einen gemeinsamen Experten. Für jeden Token wählt der Router die Top Ten der gerouteten Experten zusätzlich zur gemeinsamen Berechnung. Laguna verwendet eine per-head softplus output gating – eine pro Kopf angewandte Softplus-Ausgangssteuerung. Jeder Aufmerksamkeitskopf bekommt seine eigene Lautstärkeregelung. Das Modell kann den Beitrag einzelner Köpfe reduzieren, beibehalten oder verstärken, bevor ihre Ergebnisse kombiniert werden. Die Softplus-Funktion hält diese Tore positiv, erlaubt Werte über eins, sodass nützliche Köpfe verstärkt werden können. Laguna setzt auf verschränktes Denken: Das Modell führt einen Gedankenschritt aus, tätigt einen Werkzeugaufruf, empfängt das Ergebnis und setzt seine Denkspur fort, bevor es die nächste Aktion wählt.

Für spekulative Dekodierung stellt Poolside ein DFlash-Draft-Modell bereit, das Kandidatentoken generiert, die das Hauptmodell parallel verifizieren kann – das beschleunigt die Ausgabe potenziell. Die Unterstützung für Laguna ist in vLLM ab Version 0.25.0 dokumentiert. Das Modell läuft auf einer einzelnen B300-GPU, die NVFP4- und INT4-Varianten verbrauchen weniger als 80 GB. Für die volle Kontextlänge bräuchte man eine 96-GB-GPU wie die RTX Pro 6000. Der KV-Cache für 256.000 Tokens wird auf etwa 24 GB geschätzt. Auch hier empfehlen die Entwickler, die vorherigen reasoning_content im Gesprächsverlauf zu behalten – das gleiche Problem wie bei Nanbeige, nur dass Laguna aufgrund seiner geringeren KV-Cache-Größe pro Token etwas nachsichtiger ist.

Laguna ist deutlich spezialisierter als Nanbeige. Sein primäres Ziel ist langfristiges Software-Engineering: Beheben von Bugs auf Repository-Ebene, Terminal-Interaktion, Shell-basierte Workflows, mehrsprachige Code-Pflege, Erkundung von Codebasen und Beantwortung von Fragen, die das Verständnis großer Software-Repositorien erfordern. Die spärliche Architektur und das auf Code fokussierte Training machen Laguna effektiv für Terminal-Interaktion, Repository-Level-Denken und mehrsprachiges Software-Engineering. Das Modell sieht auf dem Papier hervorragend aus. Das Feedback aus der Community ist bisher gemischt – was bei der Komplexität solcher Modelle nicht überrascht.

Zwei Lager, ein Ziel: Was bedeutet das in der Praxis?

Beide Modelle zielen auf denselben Einsatzbereich – agentische KI für Code und Workflows –, aber sie gehen unterschiedliche Wege. Nanbeige setzt auf Wiederholung: kleine, schlanke Gewichte, zweimal denken. Das spart Speicher, fordert Rechenzeit und erzeugt einen überraschend großen KV-Cache. Laguna setzt auf Auswahl: ein Heer von Experten, aber nur die relevanten abrufen. Das spart Rechenzeit, braucht enormen Gewichtsspeicher und eine leistungsfähige GPU, um die vielen Parameter zu laden.

Für dich als Anwender stellt sich die Frage: Hast du Hardware mit 96 GB VRAM und brauchst ein Modell, das über ganze Code-Repositorien hinweg denken kann? Dann ist Laguna die richtige Wahl. Arbeitest du auf einem Workstation-Rechner mit 24 GB und möchtest einen soliden Coding-Assistenten, der in den meisten Benchmarks größere Modelle schlägt? Dann ist Nanbeige spannend – aber du musst die Einschränkungen beim KV-Cache und die doppelte Durchlaufzeit akzeptieren. Der Autor kündigt an, beide Modelle in den nächsten Wochen selbst für agentisches Coding zu testen.

Agentic KI ist kein Einheitsbrei mehr. Du hast heute die Wahl zwischen einem flinken Schwergewicht und einem monumentalen Spezialisten. Die Kunst wird sein, das richtige Werkzeug für deine konkrete Aufgabe auszuwählen – und die Hardwarekosten im Auge zu behalten. Was nützt das mächtigste Modell, wenn die GPU für den nächsten Denkschritt keine Tokens mehr verarbeiten kann?

Quelle: kaitchup.substack.com

Du gibst einem neuen Mitarbeiter ein detailliertes Handbuch mit vielen Regeln: „Schreibe keine langen Kommentare“, „Erstelle niemals Analyse-Dokumente“, „Wiederhole dich immer am Ende.“ Anfangs verhindert das grobe Fehler. Mit der Zeit wird der Mitarbeiter erfahrener – die Regeln bremsen ihn. Statt sich auf die Aufgabe zu konzentrieren, muss er widersprüchliche Anweisungen entwirren. Diesen Wendepunkt hat Anthropic mit den neuesten Claude-5-Modellen erreicht. Die Entwickler haben über 80 Prozent des System-Prompts von Claude Code gestrichen – die Leistung in den Code-Aufgaben blieb gleich. Das verändert die Regeln des Context Engineering.

Bisher galt: Je präziser die Regeln, desto besser die Ergebnisse. Die neue Generation – Claude Opus 5 und Claude Fable 5 – zeigt ein besseres Urteilsvermögen. Laut Anthropic behinderten zu viele Einschränkungen die Modelle. Im alten System-Prompt fanden sich Sätze wie: „Standardmäßig keine Kommentare schreiben. Niemals mehrzeilige Docstrings oder Kommentarblöcke – maximal eine kurze Zeile.“ Oder: „Keine Planungs- oder Analyse-Dokumente erstellen, es sei denn, der Nutzer bittet explizit darum.“ Diese Regeln sollten als Sicherheitsnetz dienen, widersprachen sich aber mit anderen Anweisungen aus Skills oder CLAUDE.md-Dateien. Das Modell musste abwägen, welcher Regel es folgen soll – ein Denkprozess, der unnötig Ressourcen verbrauchte und oft zu suboptimalen Ergebnissen führte.

Die Lösung ist einfach: Vertrauen. Anthropic ersetzte die Regeln durch eine einzige Leitlinie: „Schreibe Code, der sich wie der umliegende Code liest – passe Kommentardichte, Benennung und Stil an.“ Das Modell entscheidet selbst, wann ein mehrzeiliger Kommentar sinnvoll ist, weil es den Kontext versteht. Es funktioniert. Die Leistung in den Evaluierungen blieb stabil, während Flexibilität und Geschwindigkeit der Antworten zunahmen. Das Ergebnis einer bewussten Design-Entscheidung: Moderne KI braucht weniger Gängelung, mehr Rahmenbedingungen.

Die fünf Mythen des alten Context Engineerings

Anthropic räumt in seinem Blogbeitrag mit fünf verbreiteten Annahmen auf. Jede war für ältere Modelle sinnvoll, für die neuen Generationen ist sie kontraproduktiv.

1. Mythos: Gib Claude klare Regeln – Fakt: Lass Claude sein Urteilsvermögen nutzen. Früher musstest du explizit verbieten, dass das Modell Dateien löscht oder unnötige Dokumente erstellt. Heute versteht Claude, wann solche Handlungen angebracht sind. Ein Beispiel aus dem alten System-Prompt: „Erstelle keine Planungs-Dokumente, es sei denn, der Nutzer fragt danach.“ Der neue Prompt sagt einfach: „Arbeite aus dem Gesprächskontext, nicht aus Zwischendateien.“ Das Modell erkennt selbst, ob ein Planungsdokument hilfreich ist – und erstellt eines, ohne darauf warten zu müssen, dass der Nutzer es explizit verlangt.

2. Mythos: Gib Claude Beispiele für Tool-Nutzung – Fakt: Gestalte die Tools intuitiv. Früher galt: Füge ein oder zwei Beispiele hinzu, damit das Modell versteht, wie ein Tool funktioniert. Das führt dazu, dass Claude die Beispiele nachahmt, anstatt kreative Wege zu erkunden. Besser ist es, die Tool-Schnittstelle selbst ausdrucksstark zu gestalten, sodass keine Beispiele nötig sind. Ein Todo-Tool sollte Parameter wie „Status: ausstehend, in Bearbeitung, erledigt“ enthalten – das sagt dem Modell, wie es das Tool verwenden soll. Der Hinweis, dass immer nur ein Eintrag „in Bearbeitung“ sein sollte, definiert das Verhalten, ohne es zu erzwungen.

3. Mythos: Gib alle Informationen auf einmal – Fakt: Setze auf progressive Offenlegung. Früher packtest du alle Anleitungen ins System-Prompt: Code-Review-Prozesse, Verifikationsschritte, Formatierungsregeln. Das füllte den Kontext und war meist unnötig. Heute entscheiden Modelle selbst, wann sie welche Informationen brauchen. Anthropic hat die Verifikationsanleitung in einen separaten Skill ausgelagert, den Claude bei Bedarf lädt. Für deine Projekte gilt: Statt einer riesigen CLAUDE.md-Datei, die alles enthält, lege eine Baumstruktur an – eine Hauptdatei mit den wichtigsten Gotchas und separate Dateien für spezielle Themen (Verifikation, Deployment-Standards, Naming-Conventions). Claude findet den richtigen Zweig selbst.

4. Mythos: Wiederhole dich – Fakt: Halte Tool-Beschreibungen einfach. Ältere Modelle beachteten Anweisungen am Ende des Kontextfensters stärker. Deshalb wiederholtest du dieselben Regeln an mehreren Stellen: im System-Prompt, in der Tool-Beschreibung, in der CLAUDE.md. Das war ein Workaround für eine Schwäche früherer Modelle. Heute reicht es, die Anweisung dort zu platzieren, wo sie hingehört: in der Tool-Beschreibung. Wiederholungen verwirren und kosten Kontext-Token, die du für wichtigere Informationen nutzen könntest.

5. Mythos: Speichere alles im Gedächtnis über CLAUDE.md – Fakt: Nutze Auto-Memory. Viele Benutzer haben manuell Notizen in ihre CLAUDE.md-Datei eingefügt. Claude 5 speichert automatisch relevante Informationen, die es während der Arbeit entdeckt – deine bevorzugte Art, Imports zu ordnen oder deine Lieblings-Bibliothek für Logging. Du musst nicht mehr aktiv daran denken, das festzuhalten. Das Modell erkennt selbst, was dir wichtig ist und hebt es für zukünftige Sitzungen auf.

Wie du diese Regeln in deiner eigenen Arbeit anwendest

Die Erkenntnisse von Anthropic lassen sich direkt auf deine Projekte übertragen – egal, ob du Claude Code, einen eigenen Agenten oder Prompts für die API optimierst. Der Schlüssel liegt im Loslassen alter Gewohnheiten. Statt immer mehr Regeln zu stapeln, vertraue deinem Modell. Gib eine klare, aber flexible Basis vor.

System-Prompt: Wenn du einen eigenen Agenten baust, ist das deine zentrale Stellschraube. Beschreibe, in welchem Produkt der Agent arbeitet und welche grundlegende Rolle er hat. Vermeide spezifische Verbote oder Gebote, die nicht für jeden Fall gelten. Ein guter System-Prompt sagt: „Du bist ein Code-Assistent, der in einem Python-Repository arbeitet. Hilf beim Schreiben, Refactoring und Testen.“ Mehr nicht.

CLAUDE.md: Halte sie leichtgewichtig. Maximal zwei bis drei Absätze. Beschreibe, worum es im Repository geht, aber verschwende keine Tokens für Offensichtliches – Dinge, die Claude aus der Dateistruktur erkennt. Investiere die Tokens lieber in echte Gotchas: „Achtung: Alle Typen sind in einer einzigen Datei models.py definiert“ – das ist nützlich, weil Claude sonst jede Datei durchsuchen würde. Nutze progressive Offenlegung, indem du aus der CLAUDE.md auf spezielle Skill-Dateien verweist: „Siehe .claude/skills/verification.md für detaillierte Testanweisungen.“

Skills: Denk an sie als schlanke Ratgeber, die nur geladen werden, wenn das Modell sie braucht. Vermeide Überregulierung. Ein Skill für Code-Review sollte nicht alle Regeln der Software-Engineering-Klassiker enthalten, sondern deine persönlichen Vorlieben: „Wir bevorzugen Early Returns statt verschachtelter Ifs“ oder „Jede neue Funktion muss einen passenden Test haben.“ Wenn ein Skill lang ist, teile ihn in mehrere Dateien auf – review-rules.md, test-guidelines.md und naming-conventions.md. Claude ruft sie bei Bedarf einzeln ab.

Referenzen: Statt einfacher Markdown-Pläne kannst du Claude reichhaltigere Referenzen geben. Ein Spezifikationsdokument muss nicht mehr nur Text sein; es kann eine HTML-Artifact mit interaktiven Elementen sein, oder besser: eine Testsuite, die genau definiert, was die Software können muss. Du kannst Claude auch Rubriken geben – eine Liste von Kriterien, anhand derer das Modell seine eigene Arbeit bewerten soll. Zum Beispiel: „Ein gutes API-Design ist einfach, konsistent und dokumentiert. Erstelle einen Verifier-Agenten, der jede neue Endpoint-Klasse mit dieser Rubrik prüft.“ Das ist mächtiger als eine statische Liste mit 20 Regeln.

Was das für die Zukunft der KI-Interaktion bedeutet

Dieser Wandel ist mehr als eine technische Optimierung. KI-Modelle sind an einem Punkt angekommen, an dem sie nicht mehr durch primitive Regeln gesteuert werden müssen, sondern durch ein feines Zusammenspiel aus Kontext, Zielvorgabe und Vertrauen. Das erinnert an die Entwicklung von Betriebssystemen: Früher mussten Programmierer genau wissen, wo im Speicher ihre Daten lagen; heute kümmern sich abstrakte Schichten darum. Ähnlich können wir jetzt die Aufgabe „Schreibe guten Code“ an Claude delegieren, ohne jede Zeile vorschreiben zu müssen.

Für Unternehmen bedeutet das: Weniger Aufwand beim Prompt-Engineering, mehr Fokus auf die Qualität des Feedbacks und der Daten, die dem Modell zur Verfügung stehen. Und für Entwickler: Es lohnt sich, alte Gewohnheiten zu hinterfragen. Vielleicht ist die umfangreiche CLAUDE.md, die du seit Monaten pflegst, eher eine Bremse als ein Turbo. Vielleicht reichen ein paar klare Sätze und das Vertrauen, dass Claude den Rest richtig macht.

Am Ende geht es darum, den richtigen Rahmen zu setzen – nicht mehr, nicht weniger. Wie ein erfahrener Handwerker, der seinem Gesellen die grundlegenden Prinzipien erklärt und ihn dann selbst die Lösung finden lässt. Die neuen Claude-5-Modelle sind bereit für diese Freiheit. Jetzt liegt es an uns, sie ihnen zu geben.

Quelle: claude.com

Stell dir vor, du sitzt in einem grossen Büro und wartest auf eine wichtige Nachricht. Du könntest alle fünf Minuten bei der Zentrale anrufen und fragen: „Ist was Neues da?“ Das wäre ineffizient und würde nerven. Besser wäre ein System, bei dem die Zentrale dich sofort benachrichtigt. Das leistet Postgres mit LISTEN und NOTIFY – direkt in der Datenbank.

Seit Jahren kursiert das Gerücht, dass Postgres LISTEN/NOTIFY nicht für grössere Systeme tauge. Zu viele Verbindungen, zu viel Overhead, zu langsam. Moderne PostgreSQL-Versionen haben die interne Mechanik verbessert. Mit der richtigen Architektur kannst du Tausende von gleichzeitigen Listenern betreiben, ohne dass die Datenbank überlastet wird.

LISTEN und NOTIFY sind ein eingebautes Pub/Sub-System. Ein Client abonniert mit LISTEN einen Kanal. Ein anderer Client – oder ein Trigger, eine Funktion – sendet mit NOTIFY eine Nachricht. PostgreSQL leitet diese asynchron an alle lauschenden Verbindungen weiter. Kein Polling, keine zusätzliche Middleware, nur die Datenbank.

Der Vorteil gegenüber Polling: sofortige Reaktion und geringere Datenbanklast. Statt alle paar Sekunden eine SELECT-Abfrage auszuführen, wartest du auf ein Ereignis. Das schont CPU, Netzwerk und Speicher. Besonders bei vielen Nutzern spart das Ressourcen.

Warum zweifeln viele an der Skalierbarkeit? Der Grund liegt in der Vergangenheit. Ältere Postgres-Versionen hatten Probleme mit vielen LISTEN-Verbindungen. Jede lauschende Verbindung erzeugte Overhead im Shared Memory und im WAL. NOTIFY-Nachrichten konnten nur innerhalb einer Transaktion gesendet werden und kamen erst nach Commit an. Das führte zu Verzögerungen.

Seit PostgreSQL 9.4 hat sich die Situation verbessert. Asynchrone Notifications und optimierte Queue-Strukturen steigern die Leistung. Heute lassen sich zehntausend gleichzeitige LISTEN-Verbindungen betreiben, ohne dass die Datenbank aus dem Takt gerät. Es gibt Grenzen – Shared Memory oder CPU – aber sie liegen höher als oft angenommen.

Ein oft übersehener Faktor ist die Art der Verbindungen. Bei einem Connection Pool wie PgBouncer musst du aufpassen: Viele Pooler leiten LISTEN/NOTIFY nicht korrekt weiter, weil sie Verbindungen mischen. Die Lösung: ein dedizierter Pool-Modus (z. B. Session-Pooling) oder direkte Verbindungen für Listener. Auch kannst du Notifications in einer zentralen Worker-Webanwendung bündeln und per WebSocket verteilen. Das entlastet die Datenbank und skaliert horizontal.

Die Nachrichten ersetzen keinen vollwertigen Message Broker. Sie sind maximal 8000 Bytes gross und nicht persistent. Bei einem Datenbank-Crash gehen nicht zugestellte Nachrichten verloren. Für viele Anwendungsfälle ist das akzeptabel: Cache-Invalidierung, Echtzeit-Updates für Dashboards, einfache Job-Benachrichtigungen oder das Triggern von Hintergrundarbeitern.

Ein Beispiel: Eine KI-gestützte Empfehlungsplattform. Wenn ein Benutzer neue Daten eingibt, soll sofort ein Modell neu trainiert werden. Statt jede Minute einen Cron-Job laufen zu lassen, löst du beim Einfügen einen NOTIFY aus. Der Worker, der das Modell trainiert, lauscht auf diesem Kanal und startet die Berechnung. Das spart Zeit und Rechenleistung.

Postgres ist das Rückgrat vieler KI-Systeme. Datenänderungen sofort zu kommunizieren, ist ein wichtiger Baustein für reaktive Architekturen. Machine-Learning-Pipelines, Echtzeit-Analysen und personalisierte Empfehlungen nutzen diese schlanke, datenbankintegrierte Kommunikation.

Die PostgreSQL-Dokumentation listet LISTEN/NOTIFY als produktionsreif. Viele Unternehmen setzen es erfolgreich ein. Wichtig ist, die Erwartungen richtig zu setzen: Es ist kein Ersatz für Kafka oder RabbitMQ, wenn du hohen Durchsatz, Persistenz und komplexe Routing-Logik brauchst. Für den typischen Anwendungsfall einer einzelnen Datenbank als Single Source of Truth ist es oft die einfachste und performanteste Lösung.

Ein konkretes Beispiel: Ein SaaS-Anbieter für Projektmanagement benachrichtigt mit LISTEN/NOTIFY alle Clients, wenn ein Teammitglied eine Aufgabe aktualisiert. Früher kam eine teure Polling-Lösung zum Einsatz – zehn Abfragen pro Sekunde pro Benutzer. Nach der Umstellung sank die Datenbanklast um 90 %. Die Benutzer erleben keine Verzögerung, der Betrieb läuft stabil mit mehreren tausend gleichzeitigen Verbindungen.

Beachte einige Best Practices: Verwende aussagekräftige Kanalnamen, die die Applikationslogik widerspiegeln. Halte die Nutzlast klein – besser eine ID versenden und die Daten separat laden. NOTIFY wird nur innerhalb einer Transaktion gesendet; erst nach Commit werden Benachrichtigungen ausgeliefert. Das verhindert falsche Benachrichtigungen über Rollbacks hinweg.

Ein weiterer Punkt: LISTEN und NOTIFY sind flüchtig. Verliert ein Client die Verbindung, bevor die Nachricht ankommt, ist sie weg. Für kritische Daten solltest du einen separaten, persistenten Mechanismus vorsehen. Für die meisten Echtzeit-Features ist das akzeptabel – ähnlich wie UDP: schnell, aber nicht garantiert.

PostgreSQL 17 bringt weitere Optimierungen für den Async-Notify-Pfad. Wer bisher gezögert hat, kann es jetzt ausprobieren. Es skaliert gut und vereinfacht die Architektur.

Letztlich geht es darum, die richtigen Werkzeuge zu wählen. Postgres LISTEN/NOTIFY ist eines dieser Werkzeuge, das in vielen Situationen eine elegante Lösung bietet. Es ist solide Technik, die seit Jahrzehnten gereift ist.

Quelle: dbos.dev

Stell dir vor, du lernst Klavierspielen, indem du einem Meisterpianisten stundenlang zuhörst – nicht, indem du seine Noten stiehlst, sondern indem du seine Technik analysierst und sie auf deine eigene Art nachahmst. In der Welt der Künstlichen Intelligenz heißt so etwas Model Distillation. Es ist eine gängige Methode, um große, rechenintensive KI-Modelle kompakter und effizienter zu machen. Und genau diese Technik steht derzeit im Zentrum eines politischen Eklats zwischen den USA und China.

Das US-Finanzministerium hat chinesischen KI-Unternehmen mit Sanktionen gedroht. Grund: Der Vorwurf, das chinesische Startup Moonshot habe das US-amerikanische Modell „Fable“ von Anthropic in großem Stil „destilliert“ – und dabei nicht nur legitime Optimierung betrieben, sondern geistiges Eigentum verletzt. Finanzminister Scott Bessent ließ auf X verlauten: „Open Source ist keine Freiwild-Jagd auf amerikanisches IP. Wenn chinesische Firmen verdeckte, industrielle Destillationsangriffe durchführen, die die Grenze zum IP-Diebstahl überschreiten, stehen Sanktionen und Eintragungen auf die Entity List auf dem Tisch.“ Damit eskalierte er eine Debatte, die bereits seit Tagen in Washington brodelt.

Doch was genau ist passiert? Moonshot veröffentlichte vor Kurzem ein Open-Weight-Modell namens Kimi K3. Dessen Fähigkeiten überraschen Fachleute – sie liegen auf einem Niveau, das man eher von Milliardengräbern wie GPT-4 oder Claude erwarten würde. Der Haken: Moonshot soll dafür kein eigenes, teures Training durchgeführt haben, sondern die Fähigkeiten von Anthropics Fable-Modell abgeschaut haben – mittels großangelegter Distillation. Der Chef der Wissenschafts- und Technologiepolitik des Weißen Hauses, Michael Kratsios, behauptet sogar, Moonshot habe dafür Nvidia GB300-Server in Thailand genutzt – Server, die eigentlich unter US-Exportkontrollen fallen und nicht an chinesische Firmen verkauft werden dürfen.

Model Distillation ist im Grunde ein Schüler-Lehrer-Prinzip. Ein großes, leistungsfähiges „Lehrer“-Modell generiert Unmengen an Antworten auf Trainingseingaben. Ein kleineres „Schüler“-Modell lernt dann, diese Antworten nachzuahmen, ohne dass es die gesamte Komplexität des Lehrers selbst lernen muss. So entstehen schlanke, schnelle Modelle für Smartphones oder Edge-Geräte. Das ist völlig legitim. Die Grenze zum Diebstahl wird überschritten, wenn jemand systematisch das Lehrer-Modell abfragt, um es praktisch zu kopieren – ohne Lizenz, ohne Transparenz, ohne Gegenleistung. Genau das wirft die US-Regierung Moonshot vor.

Das Problem: Der Vorwurf ist juristisch und technisch schwer zu beweisen. Fable ist erst seit dem 1. Juli 2024 öffentlich verfügbar. Einige Experten bezweifeln, dass Kimi K3 allein durch Destillation aus Fable so extrem schnell so gut werden konnte. Moonshot selbst schweigt bisher. Aber der Fall ist symptomatisch für einen grundlegenden Wandel in der KI-Industrie: Bisher dominieren US-Unternehmen die Spitze – mit Modellen, die Milliarden kosten und enorme Rechenzentren brauchen. Nun tauchen chinesische Open-Source-Modelle auf, die fast genauso gut sind, aber viel günstiger. Das untergräbt das Geschäftsmodell der US-Labore und stellt die Frage: Kann man mit Open-Source-KI überhaupt noch Geld verdienen, wenn Konkurrenten das Wissen einfach absaugen?

Die politische Reaktion in Washington ist entsprechend scharf. Es gibt Stimmen – wie die des ehemaligen KI-Beraters im Weißen Haus und jetzigen OpenAI-Kopfes Dean Ball –, die fordern, chinesische Open-Weight-Modelle in den USA komplett zu verbieten oder stark einzuschränken. Das Argument: Um die nationale Sicherheit zu schützen und den technologischen Vorsprung zu wahren, müsse man verhindern, dass US-Firmen und -Forschung auf Modellen aufbauen, die möglicherweise gestohlenes geistiges Eigentum enthalten. Eine Art digitaler Eiserner Vorhang für KI-Gewichte.

Doch dieser Schritt wäre ein tiefer Eingriff in die Open-Source-Kultur, die die KI-Entwicklung enorm beschleunigt hat. Wissenschaftler, Startups und Entwickler weltweit profitieren von frei verfügbaren Modellen. Ein Verbot chinesischer Open-Weight-Modelle könnte die globale KI-Landschaft fragmentieren. China baut derzeit sein eigenes Ökosystem auf – mit eigenen Modellen, eigenen Chips (trotz Exportbeschränkungen) und eigener Infrastruktur. Die USA laufen Gefahr, sich von diesem Ökosystem abzukoppeln.

Was bedeutet das konkret für dich als Tech-Beobachter oder vielleicht als jemand, der selbst mit KI arbeitet? Erstens: Die Zeiten, in denen Open-Source-KI ein unpolitisches Spielzeug war, sind vorbei. Jedes Modell, das du aus China herunterlädst, könnte unter politischen Druck geraten. Zweitens: Der Vorwurf der Destillation wird in Zukunft wohl öfter kommen – als Wettbewerbsinstrument. Große Unternehmen werden versuchen, kleinere Konkurrenten mit IP-Klagen zu stoppen, selbst wenn die Methode eigentlich legitim ist. Drittens: Die Kosten für KI-Entwicklung könnten durch Exportkontrollen und Sanktionen weiter steigen – was den Vorsprung der großen US-Labore zementiert, aber Innovation in Schwellenländern erstickt.

Am Ende geht es nicht nur um Moonshot und Fable. Es geht um die grundlegende Frage: Wem gehört das Wissen, das eine KI generiert? Und wie verhindert man, dass offene Technologien zur Waffe im geopolitischen Machtkampf werden? Die Antworten darauf werden die kommenden Jahre prägen – und auch deinen nächsten KI-Assistenten, ob er nun aus San Francisco oder Peking kommt.

Bleibt abzuwarten, ob die USA tatsächlich Sanktionen verhängen. Das Finanzministerium hat sich alle Optionen offen gehalten. Klar ist: Die Ära des naiven Technologie-Optimismus ist vorbei. KI ist zum Schlachtfeld geworden – und Distillation ist eine der schärfsten Waffen. Halte deine Modelle gut bewacht. Oder stelle dich darauf ein, dass dein nächstes „Open-Source“-Update plötzlich unter Embargo fällt.

Quelle: techcrunch.com

Zwei Automodelle: ein Sportwagen mit verschweißter Motorhaube – nur der Hersteller kennt den Innenraum. Das andere rollt mit offenem Motorraum vor. Jeder kann die Bauteile studieren, nachbauen und umrüsten. Dieselbe Grundsatzfrage spaltet die KI-Branche: offene oder geschlossene Modelle? Ein chinesisches KI-Modell namens Kimi K3 hat die Diskussion neu entfacht. In den USA sorgt es für Aufregung.

Moonshot AI präsentierte letzte Woche sein Modell Kimi K3. In mehreren Benchmarks schlug es die bisherigen Spitzenreiter – zu einem Bruchteil der Kosten. Viele Beobachter sagen: Kimi K3 kann mit führenden US-Modellen von OpenAI, Anthropic und Google mithalten. Es verbraucht weniger Rechenleistung und Geld. In den USA löste das eine neue Panikwelle aus: Wird China die USA im KI-Wettlauf überholen? Gleichzeitig tauchten Vorwürfe auf, chinesische Modelle seien auf Basis amerikanischer Arbeit trainiert worden – ein Vorgang namens „Destillation“.

Die strategische Kluft: Open Source gegen Closed Source

Der Kern des Konflikts ist eine tiefe strategische Kluft. China setzt fast durchgängig auf Open-Source- oder Open-Weight-Modelle. Die trainierten Parameter der KI – das erlernte Wissen – werden öffentlich zugänglich gemacht. Entwickler weltweit können die Modelle herunterladen, prüfen, anpassen und einbauen. Die USA hingegen halten an geschlossenen Modellen fest. Die Parameter bleiben geheim, der Zugang erfolgt nur über kostenpflichtige APIs oder Lizenzen. Die Hersteller behalten die Kontrolle über Sicherheit, Zugriff und Preisgestaltung.

Diese unterschiedlichen Philosophien prallen nun aufeinander. Einige US-KI-Führungskräfte lassen sich von Chinas Bekenntnis zu offenen Modellen inspirieren. Andere sehen darin eine Gefahr für die nationale Sicherheit und ihr Geschäftsmodell. Die Frage ist nicht nur technischer oder wirtschaftlicher Natur, sondern auch politisch aufgeladen.

Die Reaktionen: Von Panik bis Regulatory Capture

Dean Ball, ehemaliger leitender KI-Berater von US-Präsident Donald Trump, heute Leiter der Strategieabteilung bei OpenAI, löste eine Debatte auf X aus. Er schrieb, er sei überrascht, dass der chinesische Staat trotz potenzieller Risiken die Veröffentlichung solcher Modelle als Open Source zulasse. Balls Begriff vom „KI-Kommunismus“ zielt darauf ab, dass offene Modelle angeblich Investitionen abschrecken und die Entwicklung bremsen. Seine Prognose war brisanter: Die Trump-Regierung werde erkennen, dass ihre beste Strategie darin bestehe, regulatorische Risiken rund um die Nutzung offener chinesischer Modelle zu schaffen. Mit anderen Worten: Durch Angst, Unsicherheit und Zweifel im Regulierungsprozess sollen amerikanische Unternehmen von chinesischen Open-Source-Modellen abgehalten werden. Ball betonte später, dies sei nur eine Prognose, keine Empfehlung – und er unterstütze Open Source, bis KI zu gefährlich werde. Ein „trauriger Tag“ sei das.

Die Reaktionen ließen nicht lange warten. David Sacks, Trumps erster „KI- und Krypto-Zar“ und heute Co-Vorsitzender eines Wissenschaftsberatergremiums, bezeichnete Balls Idee als „Instrumentalisierung regulierter Unsicherheit“ und nannte sie „völlig inakzeptabel“. Auf X schrieb Sacks, die führenden geschlossenen Labore – OpenAI und Anthropic – bildeten ein Duopol bei den Einnahmen aus KI-Modellen. Sie wollten die Regierung dazu bringen, ihre Open-Source-Konkurrenz auszuschalten. „Sie haben ihre Karten auf den Tisch gelegt. Es ist an der Zeit, dass der Rest des Silicon Valley – die große Mehrheit, die Wert auf offenen Wettbewerb legt – dasselbe tut.“ Sein Co-Moderator Chamath Palihapitiya pflichtete bei: „Die Zukunft gehört Open Source. Wir müssen uns darauf einlassen und weitermachen.“

Kostenvorteil und die Frage der Fairness

Die Debatte dreht sich nicht nur um Ideologie, sondern auch um wirtschaftliche Vorteile. Analysten betonen, dass chinesische KI-Unternehmen wie Moonshot AI oder Deepseek ihre Modelle zu deutlich niedrigeren Kosten trainieren und betreiben können. Ein Analyst von Citrini Research, auf X unter dem Namen Jukan, widersprach Balls Warnung vor einer chinesischen Übernahme. Open-Source-Modelle allein verschafften keinem Unternehmen eine dominierende Position. Der wahre Vorteil liege in den proprietären Abläufen – etwa bei der Effizienz der Inferenzberechnung – nicht nur in der Offenheit der Gewichte. „Chinesischen Unternehmen mag es zwar an Rechenkapazität mangeln, um den gesamten Inferenzbedarf selbst zu decken, aber sie verkaufen nicht mit Verlust und holen ihre Trainingskosten wieder herein“, schrieb Jukan.

Softwareentwickler Suhail Doshi wies darauf hin, dass amerikanische KI-Labore ihre Produkte mit „Daten der Menschheit trainiert haben, ohne dafür zu zahlen“. Jede Lobbyarbeit oder Gesetzgebung, die im Namen der Destillation ein Verbot von Open-Weight-Modellen fordere, sei „völliger Bullshit“. Es handle sich um einen Kampf gegen zukünftige amerikanische Innovationen. Doshi spricht ein heikles Thema an: Viele KI-Modelle wurden auf öffentlich zugänglichen Daten trainiert, die von Milliarden Menschen im Internet erzeugt wurden. Dass nun gerade die Unternehmen, die diese Daten kostenlos genutzt haben, andere daran hindern wollen, ähnliche Modelle zu bauen, wirft Fragen nach Fairness und Monopolbildung auf.

Was bedeutet das für die Zukunft der KI-Entwicklung?

Die Diskussion um Kimi K3 zeigt einen Wendepunkt. Die US-Regierung muss eine Position finden. Soll sie offene Modelle fördern, um Innovation und Wettbewerb zu stärken? Oder soll sie die heimischen Closed-Source-Unternehmen schützen, auch wenn das langfristig den technologischen Fortschritt bremsen könnte? Dean Balls Vorstoß, regulatorische Verwirrung zu schüren, klingt für viele nach einem klassischen Fall von „Regulatory Capture“ – wenn Regulierungsbehörden im Sinne der Industrie handeln, statt im öffentlichen Interesse. Das wäre gefährlich. Es könnte Innovationen abwürgen, die von kleinen Start-ups und der Open-Source-Community ausgehen. Auf der anderen Seite stehen berechtigte Sicherheitsbedenken: Offene Modelle könnten von böswilligen Akteuren genutzt werden, um Desinformation zu verbreiten, Schadsoftware zu entwickeln oder andere Risiken zu schaffen. Ein ausgewogener Ansatz ist nötig, der die Vorteile der Offenheit wahrt, ohne die Gesellschaft unkontrollierten Risiken auszusetzen.

Für Entwickler und Unternehmen, die KI-Anwendungen bauen, ist die Lage klar: Open-Weight-Modelle wie Kimi K3 bieten eine kostengünstige und flexible Alternative zu teuren APIs geschlossener Anbieter. Sie ermöglichen es, eigene Modelle zu verfeinern, in sensiblen Umgebungen lokal zu hosten und unabhängig von Preisentscheidungen großer Konzerne zu sein. Sie erfordern aber auch mehr technisches Know-how und Eigenverantwortung. Die Frage ist nicht, ob Open Source oder Closed Source gewinnen wird – sondern wie beide Ansätze koexistieren und reguliert werden. Die Debatte um Kimi K3 ist ein Vorgeschmack auf die kommenden Jahre des KI-Wettrennens.

Der Hype um Kimi K3 spiegelt fundamentale Verschiebungen in der globalen KI-Landschaft wider. China hat gezeigt, dass es nicht nur kopieren, sondern auch effizienter bauen kann. Die USA müssen sich entscheiden, ob sie Mauern hochziehen oder die Tore öffnen – und welche Rolle die Politik dabei spielen soll. Informiert bleiben, kritisch hinterfragen. Die beste Strategie gegen Angst ist Wissen.

Quelle: businessinsider.de