Kategorie: KI-News

Stell dir vor, du verwaltest Kundendaten, Kontobewegungen und Transaktionshistorien in einem Cloud Data Warehouse wie Snowflake oder BigQuery. Du willst Zusammenhänge verstehen: Welche Konten gehören zu derselben Person? Welche Transaktionen laufen über mehrere Schritte? Dafür wäre ein Knowledge Graph nützlich. Das Verschieben der Daten in eine separate Graphdatenbank wäre aufwendig, teuer und würde bestehende Governance-Regeln aufweichen. Bisher gab es ein Dilemma: entweder auf die Analyse von Beziehungen verzichten oder in komplexe ETL-Pipelines und eine zweite Datenhaltung investieren. Neo4j hat mit Virtual Graph eine Lösung vorgestellt, die diesen Konflikt auflöst – jetzt für alle Aura-Kunden in der öffentlichen Vorschau verfügbar.

Eine Bibliothek ohne Bücher umzustellen

Denk an eine riesige Bibliothek. Die Bücher stehen in den Regalen eines Data Warehouse. Du möchtest ein vernetztes Verzeichnis: welche Bücher thematisch verwandt sind, welche Autoren korrespondieren, welche Leser ähnliche Interessen haben. Normalerweise müsstest du alle Bücher umräumen. Virtual Graph funktioniert anders: Du erstellst ein Karteikartensystem – das Graphmodell –, das auf die vorhandenen Bücher verweist, ohne sie umzustellen. Bei einer Abfrage sucht das System im Karteikasten und holt die Informationen direkt aus den Regalen. Das ist die Idee der Zero-Copy-Architektur: Daten bleiben, wo sie sind, und du befragst sie als Graph.

Wie Virtual Graph funktioniert

Der Prozess beginnt mit der Verbindung zu einer Datenquelle. Virtual Graph unterstützt derzeit Snowflake, Databricks und Google BigQuery. Nach der Authentifizierung schlägt eine KI-gestützte Funktion ein Graphmodell vor: Sie analysiert Tabellen, erkennt, welche Spalten als Knoten (Entitäten) und welche als Beziehungen (Fremdschlüssel) infrage kommen, und weist Eigenschaften zu. Du prüfst und passt den Vorschlag an – die Kontrolle bleibt bei dir. Dann erstellst du den virtuellen Graphen. Von da an formulierst du Abfragen in Cypher. Im Hintergrund übersetzt eine deterministische Engine das Cypher in optimiertes SQL und führt es auf der Quelldatenbank aus. Die Übersetzung ist nicht KI-gesteuert, sondern regelbasiert. Dieselbe Abfrage liefert immer dasselbe SQL mit vorhersagbarer Leistung und Kosten. Die Ergebnisse kommen als Graph strukturiert über das Bolt-Protokoll zurück. Das System verhält sich wie eine normale Neo4j-Datenbank, sodass bestehende Tools und Clients direkt darauf zugreifen können.

Drei Komponenten, die zusammenwirken

Hinter Virtual Graph stecken drei Komponenten. Erstens das Graphdatenmodell, das du selbst definierst und bei Bedarf von der KI generieren lässt. Es gehört dir, du kannst es jederzeit bearbeiten. Zweitens die Cypher-to-SQL-Übersetzungsschicht, die die Abfragen auf die Quelle überträgt. Drittens eine Graph-Compute-Schicht, die Muster, Traversale und Pfade behandelt, die sich allein mit SQL nicht effizient abbilden lassen. Diese Schicht läuft auf Neo4j-Seite und ergänzt die Pushdown-Logik. Das Zusammenspiel erlaubt komplexe Graphabfragen wie mehrstufige Verkettungen („Welche Konten teilen sich einen wirtschaftlichen Eigentümer?“) korrekt zu beantworten, obwohl die Rohdaten in einem tabellarischen Warehouse liegen.

Wofür du Virtual Graph einsetzen solltest

Virtual Graph ist nicht für jeden Workload gedacht. Neo4j unterscheidet klar zwischen Workloads, die Sekunden tolerieren, und solchen, die Millisekunden brauchen. Virtual Graph eignet sich für GraphRAG (Retrieval-Augmented Generation), bei dem KI-Agenten Kontext aus einem Knowledge Graph abrufen. Antwortzeiten im Sekundenbereich sind akzeptabel. Auch für Batch-Analysen, explorative Datenanalysen durch Data Scientists oder das Anreichern von Referenzdaten ist Virtual Graph ideal. Du nutzt die Rechenleistung deiner bestehenden Warehouse-Infrastruktur und bleibst innerhalb der Governance-Grenzen. Keine zusätzlichen Kosten für Datenbewegung, kein Aufbau einer zweiten Datenhaltung.

Wann du besser zum nativen Neo4j greifst

Für Workloads, die Millisekunden erfordern – wie Echtzeit-Betrugserkennung, Online-Identitätsauflösung oder kontinuierlich aktualisierte Graphen mit ACID-Transaktionen – bleibt das native Neo4j (AuraDB oder selbstverwaltet) die richtige Wahl. Virtual Graph ersetzt es nicht, sondern ergänzt es. Faustregel: Wenn dein KI-Agent in Sekunden denkt, reicht Virtual Graph. Wenn er in Millisekunden handeln muss, brauchst du einen nativen Graphen. Wenn ein Teil deiner Daten beide Anforderungen stellt, kannst du Teilmengen aus dem virtuellen Graphen in einen nativen materialisieren, ohne das Modell neu zu erstellen.

Was noch kommt: Roadmap und Preisgestaltung

Die öffentliche Vorschau ist erst der Anfang. Neo4j hat weitere Funktionen angekündigt: virtuelle Graphen in native Neo4j-Datenbanken materialisieren, föderierte Abfragen über mehrere Quellen hinweg in einer Cypher-Abfrage, Graph-Algorithmen auf virtuellen Graphen, Integration weiterer Datenquellen (operative Datenbanken, selbstverwaltete Neo4j-Installationen). Die öffentliche Vorschau ist kostenlos. Ab dem 1. September plant Neo4j die Abrechnung zu Preisen, die denen von AuraDB Pro entsprechen. Die allgemeine Verfügbarkeit soll kurz danach folgen. Du kannst Virtual Graph jetzt im Aura Console einrichten: Verbinde deine Snowflake-, Databricks- oder BigQuery-Zugangsdaten, lass dir ein Graphmodell generieren, passe es an, erstelle den Graphen und führe deine erste Cypher-Abfrage aus – alles in wenigen Minuten.

Einordnung: Pragmatischer Schritt für die Graph-Welt

Mit Virtual Graph bewegt sich Neo4j weg vom Dogma, dass alle Daten in die Graphdatenbank migriert werden müssen. Stattdessen wird die Graph-Abstraktion dorthin gebracht, wo die Daten bereits liegen. Das senkt die Einstiegshürde für Unternehmen, die in große Data Warehouses investiert haben. Die Architektur bleibt transparent und deterministisch – kein Blackbox-Verhalten. Für Entwickler und Architekten, die GraphRAG oder wissensbasierte KI-Systeme aufbauen, bietet Virtual Graph einen praktischen Weg, ohne die Dateninfrastruktur zu revolutionieren. Es füllt die Lücke zwischen starren Tabellen und flexiblem Graphen.

Quelle: neo4j.com

Sie bezahlen für einen KI-Dienst wie ChatGPT oder Claude einen Festpreis pro Monat oder nach Verbrauch. Hinter den Kulissen gibt es einen Schwarzmarkt von Wiederverkäufern. Sie bieten denselben Zugang zu einem Bruchteil des offiziellen Preises an. Das ist ein ausgewachsenes Ökosystem mit eigenen Preisvergleichsseiten, Affiliate-Programmen und täglichen Lotterien für API-Keys. Der Sicherheitsforscher Matt Lenhard von Vectoral hat dieses Netzwerk über Monate untersucht und seine Ergebnisse veröffentlicht.

Der Markt funktioniert wie ein Schwarzmarkt für Konzerttickets. Dieselben Plätze werden mehrfach verkauft, die Künstler zahlen drauf, niemand merkt, dass die Tickets gestohlen sind. Offizieller Preis: 100 Euro. Der Wiederverkäufer bietet es für 10 Euro an. Er hat einen Zugang gefunden, den er unendlich oft kopieren kann.

Was ist ein Relay?

Der Kern dieses Marktes ist der sogenannte Relay – zu Deutsch „Transferstation“. Ein Relay leitet Traffic zu den offiziellen KI-Modellen der großen US-Anbieter (OpenAI, Anthropic, Google) weiter, aber zu einem starken Rabatt. Ein Beispiel aus Lenhards Recherche: Ein Anbieter listete ein Paket, das offiziell 3.333 Dollar wert wäre, für umgerechnet 425 chinesische Yuan – das entspricht etwa 0,13 Dollar Nutzung pro ausgegebenem Dollar. Bis zu 97,8 Prozent Rabatt.

Technisch betreiben die Anbieter eine Proxy-Software. Sie sammeln Hunderte oder Tausende API-Keys – gestohlen, über Testkonten generiert oder mit kompromittierten Kreditkarten finanziert – und bündeln sie zu einem Pool. Jede Anfrage wird durch einen dieser Keys geleitet. Der Relay zieht eine Gebühr ab, meist weit unter dem offiziellen Preis.

Die vier Schichten des Marktes

Der gesamte Markt ist in vier Ebenen organisiert, die Lenhard beschreibt. Ganz oben stehen die Karten- und Account-Händler (卡商 und 号商). Sie verkaufen virtuelle Kreditkarten, die die Prüfungen der US-Anbieter bestehen, und liefern in großen Mengen registrierte Accounts.

Darunter die Account-Pools (账号池). Diese Dienste aggregieren Dutzende oder Hunderte von Accounts, verwalten Authentifizierungstokens, überwachen Rate-Limits, wechseln bei Sperrungen automatisch auf den nächsten Account und stellen eine einheitliche API-Schnittstelle bereit. Die Pools sind nicht auf die großen Labs beschränkt: Auch Konsumentenprodukte wie Kiro oder antigravity werden systematisch rückentwickelt, um deren Modellzugänge zu nutzen.

Die dritte Schicht sind die Relays selbst, die Transferstationen. Sie verpacken die API des Pools in ein chinesischsprachiges Produkt, kümmern sich um Abrechnung, Rechnungsstellung und Kundenservice per WeChat-Gruppen. Der Wettbewerb findet fast nur über den Preis statt.

Ganz unten stehen die Endnutzer: chinesische Entwickler, kleine Startups und mittelständische SaaS-Unternehmen, die günstige Inferenz suchen. Und größere kommerzielle Käufer, die die Infrastruktur für Model-Destillation nutzen – das Trainieren eigener Modelle auf Basis der Ausgaben der Frontier-Modelle. In der Praxis sind die Grenzen fließend: Viele Betreiber führen sowohl Pool als auch Relay, in den Foren werden die Begriffe oft synonym verwendet.

Die Software dahinter

Die meisten Relays basieren auf zwei Open-Source-Projekten: one-api und new-api. Das sind OpenAI-kompatible Gateways. Ein Betreiber installiert das Panel, fügt Kanäle (渠道) hinzu – jeder Kanal repräsentiert einen Anbieter plus einen Pool von API-Keys – und stellt einen Endpunkt zur Verfügung, der exakt der OpenAI-API entspricht. Käufer müssen nur ihr bestehendes SDK auf die URL des Relays umstellen.

Bei jeder Anfrage zieht das System einen Key aus dem Pool, leitet die Anfrage an den Originalanbieter weiter, gibt die Antwort zurück und zieht dem Nutzer Kontingent ab – bepreist nach Nutzung multipliziert mit einem Faktor (倍率). Das Panel verwaltet Benutzer, Tokens, Preisstufen, Logs und Abrechnung. new-api ist ein aktiver Fork von one-api und bringt Funktionen für Selbstbedienungszahlung, Aufladung sowie Bild-, Video- und Audiomodelle mit. Unter den beobachteten Relays kommt one-api etwa viermal häufiger vor als new-api – das originale Basisprojekt ist weiter verbreitet, auch wenn new-api speziell für den Verkauf gebaut wurde.

Die Software an sich ist nicht illegal. Viele Unternehmen hosten one-api oder new-api auf eigenen Servern, um ihre Accounts hinter einem Gateway mit Team-Kontingenten und Ausgabenkontrolle zu bündeln. Missbrauch beginnt, wenn die Kanäle mit gestohlenen, geleakten oder gepoolten Schlüsseln bestückt werden und der Betreiber diesen Zugang gegen die Nutzungsbedingungen der Anbieter weiterverkauft.

Die Methoden der Abuser

Lenhard nennt mehrere Techniken zur Beschaffung von Keys. Free-Trial-Abuse: automatisierte Massenerstellung von Konten für kostenloses Guthaben. Chargeback-Angriffe: Betrüger lassen Kreditkartenzahlungen nach der Nutzungsperiode zurückbuchen oder verwenden gestohlene Karten. Prepaid-Karten: Konten werden mit Prepaid-Karten aufgeladen, die ein begrenztes Limit haben – der Schaden des Anbieters bleibt begrenzt, aber der Relay kann trotzdem Gewinn machen.

Eine weitere Methode ist der „Open Inference“-Missbrauch: Jeder Support-Chatbot ohne strenge Guardrails ist ein Einstiegspunkt. Angreifer leiten Traffic durch den Chatbot und nutzen so die dahinterliegende KI. Dann gibt es „Denial of Wallet“: Eine Menge gleichzeitiger Anfragen, die nicht den Dienst stören, sondern das Kontingent des Anbieters verbrennen – aus Bosheit oder Konkurrenzgründen, ohne finanziellen Gewinn.

Die Käufer und das Ausmaß

Die Hauptabnehmer lassen sich in drei Gruppen einteilen: Entwickler, die günstige Tokens benötigen; Startups, die Geoblocking umgehen wollen – viele US-Modelle sind in China nicht offiziell verfügbar; und Unternehmen, die Model-Destillation betreiben. In einem chinesischen Forum (V2EX) diskutieren Nutzer darüber, wie sie mit destillierten Modellen Millionen verdient haben. „Wenn du schnelle Inferenz bra

Quelle: vectoral.com

Du arbeitest an einem Softwareprojekt, das über Jahre gewachsen ist. Irgendwann liest du einen Kommentar im Code, der verspricht, dass eine bestimmte Variable nie null sein darf – aber du traust dem Kommentar nicht mehr. Du hast schon zu oft erlebt, dass solche stillen Versprechen durch Refactoring gebrochen wurden, ohne dass es jemand bemerkt hat. Am Ende stehst du vor undefiniertem Verhalten, das sich schwer reproduzieren lässt.

In einer idealen Welt stünden solche Invarianten nicht in Kommentaren, sondern im Typsystem der Programmiersprache. Genau das ermöglichen abhängig typisierte Sprachen wie Lean oder Rocq (früher Coq). Du kannst Bedingungen wie „dieses Array ist mindestens n Bytes lang“ oder „diese Zahl ist eine Primzahl“ formal spezifizieren. Der Compiler prüft automatisch, ob dein Code diese Bedingungen einhält. Das klingt nützlich, hat aber einen hohen Preis: den manuellen Beweisaufwand.

Der Autor des zugrundeliegenden Textes kennt diese Problematik aus eigener Erfahrung. Er beschreibt, wie er ganze Tage damit verbringen kann, relativ einfache Eigenschaften zu beweisen. Das Beweisen selbst macht Spaß, ist interaktiv und herausfordernd, aber es kostet enorm viel Zeit. Besonders frustrierend ist es, wenn man nach stundenlanger Arbeit feststellt, dass die zu beweisende Aussage schlichtweg falsch ist. Diese Erfahrung teilt er mit vielen anderen in der Welt der abhängigen Typen.

Ein bekanntes Beispiel ist das seL4-Projekt, ein formal verifizierter Mikrokernel. Die Entwickler berichteten, dass sie etwa zehnmal so viel Zeit für das Schreiben von Beweisen aufgewendet haben wie für das eigentliche Design und die Implementierung. Am Ende hatten sie mehr als zwanzigmal so viele Zeilen Beweiscode wie C-Code. Diese Kosten haben abhängig typisierte Sprachen zu einer extremen Nische gemacht. Nun bahnt sich eine Veränderung an, und sie kommt von einer unerwarteten Seite: Large Language Models (LLMs).

Stell dir vor, du baust ein komplexes Uhrwerk. Bisher musstest du jedes Zahnrad einzeln mit der Hand feilen und prüfen, ob es perfekt in das nächste greift. Das ist mühsam und fehleranfällig. Jetzt kommt ein automatischer Assistent, der die Passgenauigkeit für dich überprüft – so schnell, dass du kaum noch selbst Hand anlegen musst. Genau das versprechen LLMs in Kombination mit einem Konzept namens Beweisirrelevanz. Bei vielen Beweisen kommt es nur darauf an, dass ein Beweis existiert, nicht wie er im Detail aussieht. Ein LLM kann solche Beweise oft automatisch generieren, ohne dass du dich um die Struktur kümmern musst.

Der Autor hat das getestet und einen Zstandard-Dekompression in Lean geschrieben. Zstandard ist ein modernes Kompressionsverfahren, das gzip als Standard ablöst. Es basiert auf der LZ77-Struktur, nutzt aber eine ausgefeiltere Entropiecodierung namens FSE (Finite State Entropy). Der Autor erklärt, wie FSE funktioniert: eine Zustandsmaschine mit mehr Zuständen als Symbolen. Häufige Symbole bekommen mehrere Zustände zugewiesen, sodass sie im Durchschnitt weniger Bits benötigen. Die Feinheit liegt darin, dass der Encoder nicht nur ein Symbol auswählt, sondern auch entscheiden kann, in welchem Zustand er landet – diese Wahl trägt Information in die Zukunft. Dadurch können echte Bruchteile von Bits codiert werden, was Huffman-Codierung nicht kann.

Die eigentliche Pointe: Der Autor implementierte diesen komplexen Algorithmus in Lean, ohne sich durch einen Berg manueller Beweise kämpfen zu müssen. Stattdessen ließ er die Beweise weitgehend von einem LLM generieren. Das funktionierte erstaunlich gut. Man muss noch aufpassen, dass der Typchecker nicht überlastet wird, aber die Automatisierung reduziert den Aufwand drastisch. Abhängige Typen mit KI-Unterstützung werden deutlich praktikabler.

Für Entwickler, die hohe Zuverlässigkeit brauchen – in der Luftfahrt, Medizintechnik oder bei Kryptobibliotheken – könnten abhängig typisierte Sprachen bald eine echte Alternative sein. Statt wochenlanger manueller Verifikation könnte KI-gestützte Beweisautomation zum Einsatz kommen. Die Technologie steht noch am Anfang, aber die Richtung ist klar: Die Hürden, die abhängige Typen bisher umgeben haben, sinken.

Du musst nicht sofort in Lean einsteigen. Aber du solltest beobachten, wie sich diese Werkzeuge entwickeln. Wenn LLMs zuverlässig Beweise generieren können, wandern formale Methoden aus der Nische in den Mainstream. Dann wirst du dich vielleicht wundern, warum du je darauf vertraut hast, dass ein Kommentar im Code die Wahrheit sagt.

Quelle: imperialviolet.org

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