Connect with us

Entwicklung & Code

Domain-driven Design: Beschreibungssprache ESDM legt das Modell neben den Code


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Domain-driven Design (DDD) und Event Sourcing leben von einem präzisen Vokabular. Aggregates, Bounded Contexts, Process Managers, Read Models, Context Mappings: Wer in diesen Begriffen denkt, hat ein gemeinsames Werkzeug, um über fachliche Systeme zu sprechen. Solange das Gespräch während eines Workshops live stattfindet, funktioniert das verlässlich. Das Modell ist konsistent, weil alle Beteiligten es gleichzeitig im Kopf tragen.

Weiterlesen nach der Anzeige


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Sobald der Workshop jedoch endet, beginnt das Problem. Das Modell verlässt den Raum nicht als gemeinsames Artefakt, sondern als Sammlung von Bruchstücken: ein paar Folien aus dem letzten Review, ein Whiteboard-Foto, eine README.md, verstreute Code-Kommentare, vielleicht ein Diagramm im Wiki. Jede dieser Quellen ist plausibel, aber keine ist autoritativ. In diesem Beitrag stelle ich die von meiner Firma the native web entwickelte Sprache ESDM (Event-Sourced Domain Modeling) vor und beschreibe, warum sie aus meiner Sicht die richtige Antwort auf dieses Problem ist.

Wohin Modelle verschwinden, sobald der Workshop endet

Das eigentliche Drama spielt sich in den Wochen nach dem Workshop ab. Ein Entwickler reicht eine Refactoring-Änderung ein, die einen Aggregatnamen umbenennt. Das Code Review winkt sie durch. Niemand denkt an die Folien, niemand öffnet das Wiki, niemand sucht das Whiteboard-Foto wieder heraus. Das Modell auf der Platte verändert sich, das Modell im Kopf der anderen bleibt unverändert, und der Drift beginnt.

Sechs Monate später kommt eine neue Kollegin ins Projekt. Sie liest die Folien aus dem Onboarding, weil das die einzige zusammenhängende Beschreibung ist, die sie findet. Was sie liest, stimmt nicht mehr mit der Realität überein. Ein Bounded Context heißt anders, ein Event existiert nicht mehr, ein ehemals Aggregat ist in zwei zerlegt worden. Die Folien sind kein Modell, sie sind ein Foto eines Modells aus einem bestimmten Monat.

In dieser Lage gibt es eigentlich nur drei mögliche Quellen der Wahrheit, und keine davon ist eine gute: Die Folien sind veraltet, das Wiki ist veraltet, und der Code beschreibt das Modell nicht, sondern führt es aus. Wer die fachliche Wahrheit wissen will, muss aus dem Code rückwärts rekonstruieren, was die ursprüngliche Idee einmal war. Das ist anstrengend, fehleranfällig und nicht skalierbar.

Weiterlesen nach der Anzeige

Der Kern des Problems ist, dass das Modell kein erstklassiges Artefakt ist. Es hat keinen festen Ort, kein verbindliches Format, keine prüfbaren Eigenschaften. Es ist nirgendwo zu Hause, also lebt es überall ein bisschen, und überall ein bisschen heißt im Zweifel nirgendwo richtig.

Was eine Modellierungssprache eigentlich leisten muss

Aus diesem Befund ergibt sich eine ziemlich genaue Anforderungsliste an eine Lösung. Das Modell muss versionierbar sein, also als Text vorliegen, den eine Versionsverwaltung sinnvoll diffen kann. Es muss neben dem Code im Repository leben, damit derselbe Pull-Request, der den Code ändert, auch das Modell einbezieht.

Es muss prüfbar sein, in dem Sinne, dass eine Maschine bestimmte strukturelle Aussagen über das Modell automatisch validieren kann. Ob jedes Aggregat seine Events benennt, ob jedes Event einen Erzeuger hat, ob jeder Context-Mapping-Verweis auf einen tatsächlich existierenden Bounded Context zeigt: Solche Fragen darf nicht der Lesende beantworten müssen, sondern die Werkzeugkette.

Es muss von Werkzeugen lesbar sein, also einer eindeutigen Grammatik folgen. Sobald das Format steht, lassen sich Validatoren, Generatoren, IDE-Integrationen und KI-gestützte Modellierungswerkzeuge dagegen bauen. Dieser Punkt klingt wie ein Nebensatz, ist aber der Hebel, der eine Sprache von einer Konvention unterscheidet.

Und es muss frei von Dialekten sein. Ein Format, das sich pro Team konfigurieren lässt, beschreibt am Ende keine gemeinsame Sprache, sondern eine Familie verwandter Privatsprachen. Der Wert eines geteilten Modells kollabiert, sobald jedes Projekt seine eigenen Regeln zuschneidet. Wer sich auf die Sprache verlassen können will, braucht eine Sprache, die nicht jede Stelle einzeln aushandelbar ist.

ESDM legt das Modell neben den Code

ESDM, kurz für Event-Sourced Domain Modeling, ist genau die Sprache, die diesen Anforderungen entspricht. Die YAML-basierte Sprache mit eingebauter Werkzeugkette ist auch für den kommerziellen Einsatz kostenfrei. Modelle bestehen aus Dateien mit der Endung .esdm.yaml, jede Datei enthält ein oder mehrere Dokumente, jedes Dokument deklariert eine apiVersion und einen kind-Eintrag und beschreibt damit genau ein Element der Domäne.

Die Werkzeugkette ist ein einziges Binary, das auf macOS, Linux und Windows läuft. Das Schema, gegen das die Werkzeuge validieren, ist im Binary eingebettet, nicht aus dem Netz nachgeladen. Das macht ESDM vollständig offline-fähig: Es funktioniert in abgeschotteten Build-Umgebungen, in CI-Runnern ohne ausgehende Netzverbindung und auf dem Laptop im Zug.

Der Effekt dieses Aufbaus ist greifbar. Das Modell liegt nicht mehr in einem entfernten System, sondern direkt im Repository, in einem Verzeichnis neben dem Code. Wer den Code bearbeitet, sieht das Modell. Wer das Modell bearbeitet, sieht es im Diff des Pull Request. Niemand muss sich daran erinnern, dass es das Modell gibt; es liegt sichtbar im Verzeichnisbaum.

Genauso wichtig ist, was sich dadurch im Review-Verhalten verändert. Sobald das Modell Teil des Repositorys ist, wird es Teil des Code-Reviews. Eine Refactoring-Änderung, die einen Aggregatnamen umbenennt, muss die entsprechende .esdm.yaml-Datei in derselben Änderung mitbewegen, sonst meldet der Linter den Bruch. Der Drift wird nicht durch Disziplin verhindert, sondern durch die Werkzeugkette.

Vokabular und Erweiterungen

Inhaltlich deckt ESDM das Vokabular ab, mit dem Domain-driven Design und Event Sourcing operieren. Domains und Subdomains beschreiben den fachlichen Rahmen. Bounded Contexts grenzen Vokabularien voneinander ab. Aggregates, Dynamic Consistency Boundaries (DCBs) und Process Manager tragen die Konsistenzregeln. Events und Commands tragen die Fakten und die Absichten. Read Models und Queries beschreiben die Leseseite. Context Mappings beschreiben, wie Bounded Contexts sich aufeinander beziehen. Actors, Domain Services, Event Handler, Policies und External Systems schließen die Lücken, die in realen Systemen sonst implizit bleiben.

Damit deckt der Kern den Schreib- und Leseweg eines Event-getriebenen Systems ab, von der Absicht über das Faktum bis zur projizierten Sicht. Das Modell ist nicht ausführbar; es beschreibt das Was, nicht das Wie. Diese Trennung ist die Voraussetzung dafür, dass dasselbe Modell für unterschiedliche Implementierungen tragen kann, ohne sich an eine Laufzeit zu binden.

Über den Kern hinaus gibt es Erweiterungen, die Artefakte rund um das eigentliche Modellieren beschreiben. Die Domain-Storytelling-Erweiterung hält Entdeckungsgeschichten als eigene Dokumentenart fest, mit Akteurinnen und Akteuren, Arbeitsobjekten und den Aktivitäten, die sie verbinden. Die Given-When-Then-Erweiterung erfasst Verhaltensbeispiele, also vorausgehende Events, eine auslösende Handlung und die erwarteten Ausgänge.

Beide Erweiterungen folgen denselben Konventionen wie der Kern und werden von derselben Werkzeugkette validiert. Sie injizieren aber keine neuen Bausteine in den Kern, und ein Kerndokument validiert nie gegen ein Erweiterungsschema. Diese Asymmetrie ist bewusst: Sie hält den Kern schmal und erlaubt es trotzdem, die Oberfläche der Sprache mit der Zeit wachsen zu lassen, ohne den Bestand zu gefährden.

Die Versionierung des Schemas folgt derselben Disziplin, die Sie aus Kubernetes-API-Gruppen kennen. Jedes Dokument deklariert eine apiVersion, und diese Version bindet das Dokument an eine konkrete Schema-Generation. Non-breaking Changes erhöhen die Schema-Revision, ohne die apiVersion anzufassen; Breaking Changes wandern in eine neue Hauptversion, und alte Dokumente validieren weiter gegen das alte Schema. Stabilität ist die Voreinstellung, Wechsel sind eine bewusste Entscheidung.

Der Linter hält das Modell sauber

Im Zentrum der Werkzeugkette steht der Linter. Er liest die .esdm.yaml-Dateien unter einem Verzeichnis, parst sie gegen das eingebettete Schema, prüft eine feste Liste struktureller und modellierender Regeln und meldet jede Verletzung als Diagnose mit Datei, Zeile und Spalte. Eine saubere Modellierung erzeugt keine Ausgabe und verlässt das Werkzeug mit Statuscode 0.

Der feste Regelkatalog ist eine bewusste Entscheidung. Es gibt keine Projektkonfigurationsdatei, keine Severity-Schalter, kein Abschalten einzelner Regeln. Eine Regel gilt oder sie gilt nicht; diese Entscheidung trifft die Werkzeugkette, nicht das Repository. Der Preis dafür ist, dass eine Regel gelegentlich strenger wirkt, als die konkrete Situation zu verlangen scheint. Der Gewinn ist, dass jedes ESDM-Modell, egal von welchem Team, dieselben Eigenschaften garantiert. Eine Sprache mit Schaltern beschreibt am Ende viele Sprachen mit demselben Namen, und der Wert des gemeinsamen Modells geht verloren.

Diagnosen sind Orte, keine Stack Traces. Jede Meldung verweist auf eine Datei, eine Zeile und eine Spalte und beschreibt das Problem in einem kurzen Satz, der das Vokabular der Modellierenden spricht, nicht das der Werkzeugkette. Es gibt keine Fehlernummern, die in einer Tabelle nachgeschlagen werden müssten, und keine internen Aufrufketten, die nach außen sichtbar wären.

Die volle Wirkung entfaltet der Linter, sobald er in der Continuous-Integration-Pipeline läuft. Ein Pull Request, der ein Aggregat umbenennt, ohne das Modell mitzuziehen, scheitert am CI-Schritt und wird nicht gemergt. Ein neues Event ohne Erzeuger oder ohne Konsumenten scheitert genauso. Der Drift, der vorher durch Disziplin verhindert werden musste, wird durch eine kurze, präzise Diagnose verhindert.

Konsistent mit ESDM

Konkret zahlt sich diese Architektur in mehreren Szenarien aus. Im Event-Storming-Workshop oder in der Domain-Storytelling-Sitzung gibt ESDM den Entdeckungen einen Ort, an dem sie überleben. Statt nach dem Workshop Fotos zu archivieren, schreibt man die Events, Commands, Akteurinnen und Akteure und Bounded Contexts in .esdm.yaml-Dateien und bekommt sofort Rückmeldung, ob das Modell intern konsistent ist. Ein Aggregat, das keine Events besitzt, ein Command, das niemand publiziert, ein Process Manager ohne Auslöser: Solche Lücken zeigt der Linter, bevor sie sich als unausgesprochene Annahmen verfestigen.

Bei einem bestehenden System, dessen Modell nur in den Köpfen der Beteiligten existiert, lässt sich ESDM als nachträgliches Beschreibungswerkzeug einsetzen. Beginnen Sie mit den Konsistenzeinheiten: jedes Aggregat, jeden Process Manager, jede Dynamic Consistency Boundary (DCB), jedes Read Model. Listen Sie die Events auf, die jeweils publiziert werden, und die Commands, die akzeptiert werden. Die Übung selbst legt Lücken frei, und am Ende steht ein Modell, das mit dem Code mitwachsen kann, statt ihm hinterherzulaufen.

Sobald das Modell vorliegt, wird es zum natürlichen Gesprächsformat mit fachlichen Stakeholderinnen und Stakeholdern. Der view-Befehl rendert das Modell als hierarchische Übersicht, von der Domäne über die Subdomains und Bounded Contexts bis hinunter zu den Konsistenzeinheiten und ihren Events und Commands. Diese Übersicht ist auf Knopfdruck verfügbar und entspricht garantiert dem Quellzustand. Domänenexpertinnen und Domänenexperten lesen darin dieselben Begriffe, die sie selbst verwenden, und können ohne Umweg über Implementierungsdetails Rückmeldung geben.

In Systemen mit mehreren Teams und gemeinsamen Bounded Contexts macht ESDM die Verträge zwischen den Teams explizit. Ein Context Mapping beschreibt die Beziehung zwischen zwei Bounded Contexts, ein teamübergreifender Event-Verweis ist eine geprüfte Tatsache und keine Vermutung. Was zwischen zwei Teams einmal vereinbart und im Modell festgehalten ist, prüft die Werkzeugkette danach automatisch. Die fachliche Annahme ist nicht mehr nur eine geteilte Erinnerung, sondern eine prüfbare Aussage.

Schließlich passt ESDM erstaunlich gut zu Workflows mit KI-Unterstützung. Das YAML ist schlicht genug, dass große Sprachmodelle es direkt lesen und schreiben, und das fixierte Schema und das benannte Vokabular geben dem Modell genau die Leitplanken, die es braucht, um etwas Kohärentes zu produzieren. Ein Modell aus einem Domänengespräch zu skizzieren oder aus einem Code-Bestand Kandidaten für Aggregates und Events zu extrahieren, sind Aufgaben, die sich mit dem ESDM-Vokabular zuverlässiger und überprüfbarer lösen lassen, als wenn das Modell in Prosa beschrieben wird.

Was ESDM bewusst nicht ist

Genauso wichtig wie die Beschreibung dessen, was ESDM ist, ist auch die Abgrenzung zu dem, was es nicht ist. ESDM ist kein Eventstore. Es speichert und liest keine Ereignisse, es legt nichts in eine Datenbank ab. ESDM beschreibt lediglich, welche Events es überhaupt geben soll.

ESDM ist auch kein Framework. Es schreibt keinen Programmierstil vor, keine Klassenhierarchie, keine Annotationen, keinen bestimmten Aufbau eines Service. Welche Sprache, welches Framework, welche Bibliothek Sie für die tatsächliche Implementierung verwenden, bleibt vollständig Ihnen überlassen. ESDM mischt sich in diese Entscheidungen nicht ein.

ESDM ist kein Codegenerator und keine Laufzeitumgebung. Es erzeugt aus dem Modell keine Klassen, keine Migrationen, keine API-Endpunkte. Es führt nichts aus. Diese Entscheidung ist keine Lücke, sondern Programm: Eine Modellierungssprache, die zugleich generieren oder ausführen will, zwingt mich zu Laufzeitentscheidungen, und eine Laufzeit, die zugleich modelliert, vergräbt das Modell unter Implementierungsdetails.

ESDM hält die beiden Seiten getrennt. Es ist eine deskriptive Schicht, die neben dem Code lebt und das Modell ehrlich hält, und es ist genau das, nichts darüber hinaus. Diese Sparsamkeit ist die Voraussetzung dafür, dass ESDM sich frei mit dem kombinieren lässt, was Sie tatsächlich in Produktion betreiben.

Lesen Sie auch


(rme)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Model-Schau: TurboQuant, Gemma und DeepSeek v4


In den letzten Wochen passierte in kurzer Zeit wieder enorm viel in der Welt der großen Sprachmodelle. Neben der neu eingeführten TurboQuant-Methode hat Google mit Gemma 4 eine weitere Serie von Sprachmodellen mit offenen Gewichten veröffentlicht. Deutlich später kam das lang erwartete DeepSeek v4 zumindest in einer Vorabversion auf den Markt.

Weiterlesen nach der Anzeige




Prof. Dr. Christian Winkler beschäftigt sich speziell mit der automatisierten Analyse natürlichsprachiger Texte (NLP). Als Professor an der TH Nürnberg konzentriert er sich bei seiner Forschung auf die Optimierung der User Experience.

Derweil macht Anthropic ein großes Geheimnis um sein Sprachmodell Mythos, und Qwen veröffentlicht ein inkrementelles Update zu seiner erfolgreichen Qwen3.5-Serie.

Neuer Algorithmus TurboQuant

Viele feierten das Folgende als Revolution, mit der große Modelle endlich auch auf kleineren und erschwinglichen Grafikkarten laufen können: Google hat mit TurboQuant eine neue Quantisierungsmethode erfunden, die fast keine Qualitätseinbußen mit sich bringt.

Was man dabei leicht übersehen kann: Google hat den Algorithmus auf den Key-Value-Cache ausgerichtet, der in der Inferenzphase der LLMs sehr viel Speicher erfordert, denn die dazu notwendigen Daten wachsen quadratisch mit der Kontextlänge. Und der Algorithmus selbst ist auch nicht ganz neu.

Den Key-Value-Cache kann TurboQuant nahezu verlustfrei komprimieren: Wo man vorher sechzehn Bit brauchte, sind nur noch vier Bit – oder in Ausnahmefällen sogar nur drei Bit – notwendig. Das spart viel Platz und erlaubt größere Kontextlängen. Der Algorithmus nutzt dafür eine trickreiche Rotation der Vektoren, um sie verlustärmer zu komprimieren.

Google zeigt in dem Blogbeitrag zu TurboQuant, dass die Quantisierung des KV-Cache die Perplexität, also die Unsicherheit des Modells, kaum erhöht. Damit sollten auch im täglichen Gebrauch der Sprachmodelle kaum Unterschiede auftreten. Tatsächlich erschien die erste Abhandlung zu TurboQuant bereits im April 2025, aber es gab bisher keine brauchbaren Implementierungen, und es fehlten vor allem die Testfälle.

Weiterlesen nach der Anzeige

Inzwischen unterstützen viele Softwarepakete wie llama.cpp oder transformers von Hugging Face den TurboQuant-Cache. Teilweise muss man noch etwas basteln und zusätzliche Pakete installieren, aber die Speichereinsparungen sind deutlich messbar. Auch für das MLX-Framework von Apple gibt es die ersten Implementierungen.

Spannend wird, wofür sich TurboQuant jenseits des KV-Cache eignet. Google spricht von Vektordatenbanken, aber dafür gibt es bereits andere effektive Quantisierungsmethoden. Ob sich die Gewichte der Sprachmodelle mit TurboQuant so quantisieren lassen, dass sie auch in der Inferenz effektiv funktionieren, muss sich zeigen.

Neue Gemma-Modelle mit offenen Gewichten

Google war nicht nur methodisch aktiv, sondern hat auch neue Modelle mit offenen Gewichten veröffentlicht. Die lang erwartete Gemma-4-Serie enthält viele Neuerungen und steht in Größen von effektiv 2, 4 und echten 31 Milliarden Parametern zur Verfügung, dazu kommt noch ein MoE-Modell (Mixture of Experts) mit 26 Milliarden Parametern, von denen jeweils 4 Milliarden aktiv sind. Google trickst hier etwas, denn die Zahl der effektiven Parameter ist deutlich geringer als die der tatsächlich im Speicher benötigten. So hat das kleinere Modell nicht zwei, sondern etwa fünf Milliarden Parameter, das größere statt vier in Wahrheit acht Milliarden.

Alle Gemma-4-Modelle sind multimodal und für agentische Aufgaben optimiert, außerdem können sie Bilder interpretieren. Was man heute fast schon als Standard annimmt, ist bei Weitem nicht immer so, wie der Blick auf DeepSeek v4 gleich zeigen wird. Auch Reasoning beherrschen die Gemma-4-Modelle. Um zu viele Token in der Antwort zu vermeiden, lässt sich die Reasoning-Intensität einstellen.

Wie viele andere Anbieter dreht auch Google an der Attention, um Speicherplatz und Rechenzeit zu sparen. Der hybride Attention-Mechanismus in Gemma 4 nutzt abwechselnd Layer mit voller Attention und solche mit Sliding Window Attention, bei der das Modell immer nur ein bestimmtes Fenster von Token verwendet.

Mit Gemma 4 ist Google zweifellos ein großer Wurf gelungen. Besonders bei den offenen Modellen in der Größenordnung von 30 bis 40 Milliarden Parametern war bisher Alibabas Qwen3.5 der unangefochtene Platzhirsch. So eindeutig ist die Lage nun nicht mehr, denn Gemma 4 kann hier definitiv punkten.

Lang erwartet: DeepSeek v4

Über ein Jahr ist seit der Veröffentlichung von DeepSeek-R1 im Januar 2025 vergangen. So lange hat die Community auf DeepSeek v4 gewartet. Nach einigen verfrühten Falschmeldungen über das Release ist das Modell endlich als Preview erschienen. Das Warten hat sich gelohnt, denn DeepSeek hat mit v4 gleich zwei Modelle veröffentlicht, die durch einen aufwendigen Trainingsprozess (Pre-Training mit 32 Billionen Token, aufwendiges mehrstufiges Post-Training) entstanden. Eines ist mit 1,6 Billionen Parametern sehr groß: Die Größe hat sich im Vergleich zum Vorgänger mehr als verdoppelt, auch wenn hier „nur“ 49 Milliarden aktiv sind. Flankiert wird dieses Pro-Modell von einem Flash-Modell mit lediglich 284 Milliarden Parametern, von denen 13 Milliarden aktiv sind. Das ist immer noch sehr groß, man kann es aber auf leistungsfähigen PCs mit genügend Arbeitsspeicher ausführen. Besonders eignen sich die (derzeit nicht erhältlichen) Mac-Studio-Rechner.

DeepSeek hat erneut an der Attention gebastelt. Nachdem das Vorgängermodell die Multi-Head Latent Attention brachte, kombiniert DeepSeek v4 gleich zwei neue Attention-Mechanismen. Die Details zu Compressed Sparse Attention (CSA) und Heavily Compressed Attention (HCA) bleiben aktuell noch etwas im Dunkeln, aber DeepSeek soll damit im Vergleich zum Vorgängermodell nur 27 Prozent der Gleitkommaoperationen bei der Single-Token-Inferenz benötigen. Der KV-Cache schrumpft sogar um 90 Prozent. Es wäre spannend zu untersuchen, ob sich das auch noch mit TurboQuant kombinieren lässt.

DeepSeek trickst noch weiter an der Architektur und führt die sogenannten Manifold-Constrained Hyper-Connections (mHC) ein, bei denen bestimmte Verbindungen zwischen den Layern stärker ausgeprägt sind, um die Stabilität in der Vorwärtspropagation zu erhöhen. Ähnlich wie Moonshot bei Kimi nutzt DeepSeek nun auch den Muon-Optimizer statt des sonst gebräuchlichen AdamW, um die Gewichte im Trainingsprozess noch schneller zu optimieren. Dass diese neuerdings gemischt als FP4 und FP8 abgespeichert sind, spart zusätzlich viel Speicher. Das große Modell benötigt nur wenige Byte mehr als das v3.2-Modell, und das Flash-Modell kommt sogar mit 158 GByte aus, was für ein Modell mit 284 Milliarden Parametern sonst nur über starke Post-Training-Quantisierung möglich ist.

Erstaunlicherweise ist DeepSeek v4 kein multimodales Modell, sondern kann ausschließlich mit Text umgehen. Vielleicht legt DeepSeek bis zum endgültigen Release hier noch nach, es gibt aber leider bisher auch keine Prognosen, wann es so weit sein könnte. DeepSeek hält sich mit weiteren Informationen ohnehin ungewohnt bedeckt, Details über Training und Architektur stehen noch nicht öffentlich bereit.

Spannend ist der Vergleich zwischen dem kleinen und großen (oder besser zwischen dem riesigen und dem gigantischen) Modell. Das kleinere Flash-Modell erzeugt wohl ähnlich gute Resultate, wenn man ihm mehr Reasoning zugesteht. Man tauscht somit die Zahl der Parameter gegen die Länge der Antwort bei Logikfragen. Wie gut das funktioniert, muss ein ausführlicher Test noch zeigen. Bei Wissensfragen ist das kleinere Modell erwartungsgemäß unterlegen.

DeepSeek v4 unterstützt drei unterschiedliche Thinking-Modi, von abgeschaltetem Reasoning bis zu sehr intensivem. Im Performance-Vergleich zu v3.2 sind die Fortschritte moderat. Erstaunlich ist allerdings, dass das Flash-Modell fast so gut funktioniert wie v3.2 mit immerhin doppelt so vielen Parametern (in früher deutlich höherer Genauigkeit, DeepSeek v3 hat noch überall FP8 benutzt).

DeepSeek v4 ist ein interessantes Modell, aber enttäuschend ist, dass der Hersteller entgegen seiner sonstigen Gepflogenheiten deutlich weniger technische Details veröffentlicht hat. Hoffentlich erscheint ein Artikel dazu zum endgültigen Release.

Was sonst noch war

Anthropic findet sich ebenfalls in den Schlagzeilen, allerdings nicht nur positiv. Im März geriet dem Unternehmen der Sourcecode zu Claude aus den Händen. Unabhängig davon forscht Anthropic an immer leistungsfähigeren Modellen – so leistungsfähig, dass die damit (automatisch) zu entdeckenden Sicherheitslücken gefährlich werden können. Daher wurde Mythos nicht öffentlich zur Verfügung gestellt, war aber wohl doch für Unbefugte zugänglich. Wie leistungsfähig das Modell tatsächlich ist, zeigt sich unter anderem darin, dass es über 270 Lücken in Firefox aufgedeckt hat. Gut möglich, dass sich daraus eine völlig neue Richtung in der Cybersecurity entwickelt.

Auch die chinesischen Anbieter jenseits von DeepSeek schlafen nicht. Qwen hat ein kleineres Update für einige der Qwen3.5-Modelle veröffentlicht. Qwen3.6 steht als Max Preview nur via API zur Verfügung, kleinere Modelle wie das MoE mit 35 Milliarden Parametern, von denen drei Milliarden aktiv sind, und das dichte mit 27 Milliarden Parametern stehen ebenfalls offen zur Verfügung. Besonders letzteres Modell zeigt sich als extrem leistungsfähig und schlägt deutlich größere Modelle. Wie gut das funktioniert, müssen genauere Analysen zeigen.

Qwen3.5 nutzt bei der Hybrid-Attention sogenannte Mamba-Layer. Für die State-Space-Modelle gibt es nun mit Mamba-3 eine neue Architektur. Möglicherweise lassen sich dadurch in den entsprechenden Layern weitere Verbesserungen erzielen, so dass sich längere Kontexte abbilden lassen. Leistungsfähige Modelle mit dieser Architektur gibt es allerdings noch nicht.

Die Firma Tesslate hat basierend auf Qwen3.5-9B ein Modell mit von Claude Opus generierten Daten auf Coding-Aufgaben feingetuned. Daraus entstand das OmniCoder-Modell, das sich äußerst gut für Coding-Aufgaben eignet und dabei das Basismodell in allen Dimensionen schlägt. Dabei ist es klein genug, um in einer quantisierten Version lokal zu laufen.

Moonshot hat mit Kimi K2.6 nachgelegt. Das Modell fokussiert sich besonders auf Coding- und agentische Aufgaben, die es in Schwärmen aus bis zu 300 Agenten erledigen kann. Wie gewohnt ist das Modell mit einer Billion Parametern sehr groß und lässt sich nur mit Mühe auf bezahlbarer Hardware ausführen.

Von MiniMax gibt es eine neue Version 2.7 des MoE-Modells. Bemerkenswert daran ist, dass das Modell für sein eigenes Update zum Einsatz kam. Dabei hat es seinen Speicher aktualisiert, mehrere Dutzend Skills für Reinforcement Learning „erfunden“ und autonom seinen eigenen Optimierungsprozess verbessert. Dabei behauptet MiniMax AI, dass es bis zu 30 Prozent Performanceverbesserung erreicht hat. Es wird spannend zu beobachten, ob andere Anbieter einen ähnlichen Weg gehen und allein dadurch ihre Modelle verbessern können.

Da die Modelle immer größer werden, erforschen Anbieter neben dem allgegenwärtigen Attention-Mechanismus auch neue Quantisierungsverfahren. Ein interessanter Kandidat ist die JANG-Quantisierung, die dynamisch die optimale Quantisierungsstufe auswählt und dadurch enorm Platz spart. Aktuell ist die Software allerdings nur auf Macs verfügbar. Dort ist es dann möglich, ein Modell mit 397 Milliarden Parametern mit 128 GB RAM zu betreiben. Meine eigenen Tests haben gezeigt, dass das erstaunlich gut funktioniert und mit MLX Studio auch relativ einfach zu installieren ist. Die dazu passenden Python-Tools sind allerdings nicht immer ganz up to date.

Open AI hat GPT-5.5 öffentlich bereitgestellt. Es glänzt insbesondere beim Coding mit neuen Bestwerten und kann auch mehrstufige Aufgaben gut erledigen. Im Gegensatz zu GPT 5.4 kommt es auch mit Fremdsprachen offenbar besser zurecht, denn der erste Satz des vorherigen Blogartikels klang auf Deutsch zumindest merkwürdig: „Heute veröffentlichen wir GPT‑5.4 in ChatGPT (als GPT‑5.4 Thinking), der API und Codex.“

Auch wenn bei den Sprachmodellen das meiste in China und den USA passiert, gibt es Neuigkeiten aus dem Rest der Welt, darunter aus Europa. So planen Cohere aus Kanada und das deutsche Unternehmen Aleph Alpha einen Zusammenschluss. Gemeinsam wollen sie einen Sprachmodell-Champion schaffen. Vor einer ganzen Weile waren die Cohere-Modelle ganz vorn mit dabei, sind aber in der Zwischenzeit fast unbedeutend. Vielleicht braucht es einen Restart, der möglicherweise durch die Fusion gelingt.

Clevere Mechanismen und Optimierungen

Was für ein Frühling! Bei den Sprachmodellen kann man große Fortschritte beobachten. Wenn man die Ideen der letzten Wochen wie clevere Attention-Mechanismen, verbesserte Quantisierung und optimiertes Training zusammennimmt, kann man davon ausgehen, dass in der nächsten Zeit deutlich bessere Modelle und weitere Neuerungen auf uns warten.

Besonders spannend dabei ist, dass die Wachstumskurve beim Speicherbedarf abflacht. Das lässt darauf hoffen, dass sich zumindest einige dieser Modelle künftig auf leistungsfähiger eigener Hardware souverän nutzen lassen.


(rme)



Source link

Weiterlesen

Entwicklung & Code

Daemon Tools: Mit Malware verseuchte Downloads


Wer seit dem 8. April die Daemon Tools Lite von der Herstellerwebseite heruntergeladen hat, hat damit Schadsoftware auf den Rechner verfrachtet. Die Installer sind mit den offiziellen digitalen Zertifikaten signiert und wirken zunächst unscheinbar. Anscheinend handelt es sich um eine Supply-Chain-Attacke.

Weiterlesen nach der Anzeige

Die Virenanalysten von Kaspersky sind auf die infizierten Installer gestoßen. In ihrer Untersuchung führen sie aus, dass die Installer seit dem 8. April 2026 trojanisiert wurden – und das bis jetzt zu den aktuellen Downloads anhält. Anfang Mai sind die IT-Forscher darauf gestoßen und konnten dann die älteren infizierten Installer identifizieren. Betroffen sind demnach die Installer der Daemon Tools und Daemon Tools Lite von Version 12.5.0.2421 bis hin zu 12.5.0.2434. Eine Analyse der Fassung 12.5.0.233b des Lite-Installers auf VirusTotal bestätigt mit einer heuristischen Erkennung von Kaspersky (HEUR:Trojan.Win64.Agent.gen) den Befall der aktuell auf der offiziellen Webseite der Daemon Tools herunterladbaren Dateien (Achtung, zum Meldungszeitpunkt noch trojanisierte Downloads!). Kaspersky hat den Hersteller der Daemon Tools, AVB Disc Soft, kontaktiert, jedoch bislang offensichtlich erfolglos.

Die IT-Forscher ordnen aufgrund der Malware-Analyse die Angreifer als aus China stammend ein. Die Telemetrie der Kaspersky-Sensoren zeigt demnach, dass Individuen und Organisationen aus mehr als 100 Ländern die Software zum Hantieren mit Disk-Abbildern wie ISO-Images in infizierter Fassung installiert haben. Von allen betroffenen Maschinen habe jedoch lediglich ein Dutzend weitere Malware-Stufen nachgeladen. Die gehörten zu Einzelhandel, Wissenschaft, Behörden und Fertigungsindustrie. Das sei ein Hinweis auf gezielte Angriffe. Die Opfer stammen aus Russland, Brasilien, Türkei, Spanien, Deutschland, Frankreich, Italien und China.

Weitergehende Details

Interessierte finden in der Kaspersky-Analyse tiefergehende Details zu Malware und infizierten Dateien. Die Schadsoftware sammelt unter anderem Informationen, darunter Hardwaredaten wie MAC-Adressen oder über laufende Prozesse und installierte Software. Eine minimalistische Backdoor bringt sie ebenfalls mit. Am Ende listet Kaspersky eine längere Liste an Hinweisen auf Infektionen (Indicators of Compromise, IOC).

In jüngster Zeit kommt es vermehrt zu Angriffen, bei denen die bösartigen Akteure Schadcode in sonst vertrauenswürdige Software einschleusen. Ende vergangenen Jahres hatte es etwa den mächtigen Texteditor Notepad++ getroffen. Auch die Webseite CPUID, die die populären Tools CPU-Z und HWMonitor beheimatet, hatte Mitte April Malware verteilt.


(dmk)



Source link

Weiterlesen

Entwicklung & Code

Software Testing: Sicherheitstests für KI-Systeme


In dieser Episode sprechen Richard Seidl und Jan Jürjens über Sicherheitstests in KI‑Systemen. Die beiden beleuchten Herausforderungen rund um selbstlernende Software, diskutieren typische Angriffsflächen und wie sich manipulierte Trainingsdaten oft schwer erkennen lassen. Jan Jürjens gibt Einblicke in praktische Schutzmechanismen und betont die Wichtigkeit intensiver Tests, etwa durch Penetrationstests und Filter für sensible Anfragen.

Weiterlesen nach der Anzeige

Jan Jürjens verfügt über mehr als 25 Jahre praktische Erfahrung mit Softwaresicherheit. Erstes Buch (2005) ins Chinesische übersetzt. Aktuell: Director Research Projects (Fraunhofer ISST); Professor & Leiter, Institut Softwaretechnik (Uni Koblenz). Vorher: Professor für Software Engineering (TU Dortmund), Senior Member/Research Fellow (Robinson College, Uni Cambridge), Royal Society Industrial Fellow (Microsoft Research Cambridge), Postdoc (TU München), PhD Informatik (Uni Oxford) in Softwaresicherheit, Dipl.-Math. (Uni Bremen).


Roboter mit Schild, KI und Security als Schrift

Roboter mit Schild, KI und Security als Schrift

(Bild: erstellt mit KI durch iX)

Am 11. Mai zeigt die Online-Konferenz „KI und Security“ von iX und dpunkt.verlag, wie man sich gegen Angriffe auf KI-Anwendungen schützt und wie KI-Tools bei sicherer Softwareentwicklung helfen.

Software-Testing im Gespräch

Bei diesem Format dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Sicherheitstests für KI-Systeme – Jan Jürjens“.


(mdo)



Source link

Weiterlesen

Beliebt