Entwicklung & Code
Large Language Models: Die Mathematik hinter Transformers
Im Jahr 2017 veröffentlichte ein Team bei Google ein Paper mit einem gewagten Titel: „Attention Is All You Need.“ Das war nicht nur akademische Prahlerei. Die vorgestellte Transformer-Architektur veränderte grundlegend, wie wir KI-Systeme bauen. Heute basiert jedes große Sprachmodell von GPT über Claude bis Gemini auf diesem Fundament. Wenn Sie ein modernes KI-Tool nutzen, haben Sie bereits mit einem Transformer interagiert.
Weiterlesen nach der Anzeige

Prof. Dr. Michael Stal arbeitet seit 1991 bei Siemens Technology. Seine Forschungsschwerpunkte umfassen Softwarearchitekturen für große komplexe Systeme (Verteilte Systeme, Cloud Computing, IIoT), Eingebettte Systeme und Künstliche Intelligenz.
Er berät Geschäftsbereiche in Softwarearchitekturfragen und ist für die Architekturausbildung der Senior-Software-Architekten bei Siemens verantwortlich.
Als Software Engineer haben Sie vielleicht gehört, dass Transformers „nur aus Matrixmultiplikationen“ bestehen oder dass sie „Aufmerksamkeitsmechanismen verwenden“. Diese Beschreibungen sind zwar technisch korrekt, verfehlen aber die elegante mathematische Argumentation, die Transformers funktionieren lässt. Dieser Artikel nimmt Sie mit auf eine Reise zu den Problemen, die Transformers motivierten, bis zu den hochmodernen Optimierungen in Produktionssystemen. Am Ende verstehen Sie nicht nur, was die Mathematik hinter Transformers bedeutet, sondern warum sie genau so sein muss. Damit erlangen Sie das Wissen, um einen Transformer von Grund auf zu implementieren.
Wir folgen einem roten Faden: Wie bauen wir ein System, das Beziehungen zwischen Elementen in einer Sequenz verstehen kann, unabhängig davon, wie weit diese Elemente auseinanderliegen, und dies effizient genug, um auf Milliarden von Beispielen zu trainieren? Jede Formel, jede architektonische Entscheidung resultiert aus der Beantwortung dieser Frage.
Das Problem: Warum Recurrent Networks uns im Stich ließen
Vor Transformers dominierte der Ansatz der Recurrent Neural Networks (RNN) die Sequenzverarbeitung. Um zu verstehen, warum Transformers existieren, müssen wir verstehen, warum wir RNNs trotz ihrer Eleganz nicht auf die Probleme skalieren können, die wir lösen wollen.
Stellen Sie sich vor, Sie bauen ein Übersetzungssystem. Sie erhalten den englischen Satz „The cat sat on the mat“ und müssen die französische Übersetzung produzieren. Ein RNN verarbeitet dies sequenziell. Es liest „The“, aktualisiert seinen internen Zustand, liest dann „cat“, aktualisiert seinen Zustand erneut, und so weiter. Die Idee: Wenn das Übersetzungssystem den Satz zu Ende gelesen hat, enthält sein versteckter Zustand eine komprimierte Repräsentation von allem, was es gesehen hat.
(Bild: Golden Sikorka/Shutterstock)

Die Online-Konferenz LLMs im Unternehmen zeigt am 19. März, wie KI-Agenten Arbeitsprozesse übernehmen können, wie LLMs beim Extrahieren der Daten helfen und wie man Modelle effizient im eigenen Rechenzentrum betreibt.
So aktualisiert ein RNN seinen versteckten Zustand bei jedem Zeitschritt:
Weiterlesen nach der Anzeige
h_t = tanh(W_hh * h_{t-1} + W_xh * x_t + b_h)
In dieser Formel repräsentiert h_t den versteckten Zustand zum Zeitpunkt t, x_t ist die Eingabe zum Zeitpunkt t, W_hh ist eine Gewichtsmatrix, die den vorherigen versteckten Zustand transformiert, W_xh transformiert die aktuelle Eingabe, und b_h ist ein Bias-Term. Die tanh-Funktion beschränkt das Ergebnis, um die Werte begrenzt zu halten.
Das Problem zeigt sich, wenn Sie das Ganze aus der Perspektive vieler Zeitschritte betrachten. Angenommen, Sie übersetzen ein langes Dokument, und eine kritische Information erscheint im ersten Satz, aber Sie benötigen diese Information, um den hundertsten Satz korrekt zu übersetzen. Diese Information muss somit eine hundertfache Multiplikation mit W_HH überleben.
In der Praxis führt dies zu zwei katastrophalen Problemen:
Erstens das Problem verschwindender Gradienten. Beim Training neuronaler Netzwerke berechnen wir Gradienten, die uns sagen, wie wir Gewichte anpassen sollen. Diese Gradienten müssen rückwärts durch die Zeit fließen. Wenn der Gradient bei Schritt 100 die Gewichte beeinflussen muss, die wir im Schritt 1 verarbeitet haben, muss er hundertmal mit der Ableitung der tanh-Funktion multipliziert werden. Da die Ableitung von tanh immer kleiner als eins ist, schrumpft der Gradient exponentiell. Wenn er die frühen Schritte erreicht, bleibt er im Wesentlichen bei null und die Gewichte somit unverändert, ohne dazuzulernen.
Zweitens gibt es, selbst wenn wir verschwindende Gradienten mit Techniken wie LSTMs oder GRUs lösen, ein fundamentaleres Problem: Sequenzielle Verarbeitung ist langsam. Moderne GPUs zeichnen sich durch parallele Berechnung aus. Sie können massive Matrizen unglaublich schnell multiplizieren. Aber RNNs zwingen uns, Sequenzen Schritt für Schritt zu verarbeiten, weil jeder Schritt vom vorherigen abhängt. Sie können h_100 nicht berechnen, bis Sie h_99 berechnet haben, was h_98 erfordert, und so weiter, bis wir schlussendlich h_1 erreichen. Diese sequenzielle Abhängigkeit macht das Training auf den massiven Datensätzen, die wir für moderne KI benötigen, unerträglich langsam.
Die Transformer-Architektur löst beide Probleme mit einer radikalen Idee: Was, wenn wir alle Positionen in der Sequenz gleichzeitig betrachten und das Modell lernen lassen könnten, welche Positionen füreinander relevant sind? Hier kommt Attention ins Spiel.
Die Kernidee: Attention als differenzierbare Lookup-Tabelle
Bevor wir in mathematische Formeln eintauchen, bauen wir Intuition darüber auf, was Attention tatsächlich macht. Stellen Sie sich vor, Sie lesen diesen Satz: „Die Trophäe passte nicht in die Truhe, weil sie zu groß war.“ Worauf bezieht sich „sie“? Ihr Gehirn verarbeitet dies nicht Wort für Wort unter Beibehaltung eines versteckten Zustands. Stattdessen schauen Sie, wenn Sie auf „sie“ stoßen, durch den Satz zurück, finden relevanten Kontext (Trophäe und Truhe) und bestimmen, was angesichts von „zu groß“ sinnvoll ist.
Aufmerksamkeitsmechanismen formalisieren diesen intuitiven Prozess. Im Kern ist Attention ein differenzierbarer Nachschlagemechanismus (Lookup-Mechanismus). In einer traditionellen Lookup-Tabelle oder Hash-Map geben Sie einen Schlüssel an und erhalten einen Wert zurück. Attention macht etwas Ähnliches, aber mit einem entscheidenden Unterschied: Statt exakter Übereinstimmungen berechnet es einen gewichteten Durchschnitt aller Werte, wobei die Gewichte davon abhängen, wie gut jeder Schlüssel zu Ihrer Abfrage passt.
Konkretisieren wir dies mit einem einfachen Beispiel. Angenommen, Sie haben drei Wörter in einem Satz, und jedes Wort repräsentiert sich als Vektor. Sie möchten eine neue Repräsentation für das zweite Wort berechnen, die Informationen von den anderen Wörtern basierend auf ihrer Relevanz einbezieht.
# Einfaches Beispiel mit drei Wortvektoren
wort1 = [1.0, 0.0] # "Die"
wort2 = [0.5, 0.5] # "Katze"
wort3 = [0.0, 1.0] # "saß"
Um nun eine attention-erweiterte Repräsentation für wort2 zu berechnen, müssen wir beantworten: Wie relevant ist jedes andere Wort im Textfragment für wort2? Wir könnten diese Relevanz als Skalarprodukt berechnen, das Ähnlichkeit misst:
relevanz_1_zu_2 = skalarprodukt(wort1, wort2) = 1.0 * 0.5 + 0.0 * 0.5 = 0.5
relevanz_2_zu_2 = skalarprodukt(wort2, wort2) = 0.5 * 0.5 + 0.5 * 0.5 = 0.5
relevanz_3_zu_2 = skalarprodukt(wort3, wort2) = 0.0 * 0.5 + 1.0 * 0.5 = 0.5
Diese rohen Relevanzwerte sind nicht sehr nützlich, weil sie sich nicht zu eins summieren lassen. Wir wollen Gewichte, die wir für einen gewichteten Durchschnitt nutzen können. Hier kommt die Softmax-Funktion ins Spiel. Softmax konvertiert beliebige Werte in eine Wahrscheinlichkeitsverteilung:
def softmax(werte):
exp_werte = [exp(w) for w in werte]
summe_exp = sum(exp_werte)
return [e / summe_exp for e in exp_werte]
Die Softmax-Funktion besitzt eine schöne Eigenschaft: Sie ist differenzierbar, sodass wir sie mit Backpropagation trainieren können, und sie produziert immer Ausgaben, die zu eins summieren und allesamt positive Werte besitzen. Die Exponentialfunktion stellt sicher, dass größere Werte exponentiell mehr Gewicht erhalten, was einen weichen Auswahlmechanismus schafft.
Wenden wir Softmax auf unsere Relevanzwerte an, …
gewichte = softmax([0.5, 0.5, 0.5]) = [0.33, 0.33, 0.33]
…, können wir die Attention-erweiterte Repräsentation als gewichtete Summe berechnen:
erweitertes_wort2 = 0.33 * wort1 + 0.33 * wort2 + 0.33 * wort3
= 0.33 * [1.0, 0.0] + 0.33 * [0.5, 0.5] + 0.33 * [0.0, 1.0]
= [0.495, 0.495]
Dies ist die Essenz von Attention: Wir berechnen, wie relevant jede Position für die aktuelle Position ist, normalisieren diese Relevanzen zu Gewichten und nehmen einen gewichteten Durchschnitt. Das Genie der Transformer liegt darin, diesen Prozess lernbar und effizient zu machen.
Scaled Dot-Product Attention: Das mathematische Fundament
Jetzt sind wir bereit, die tatsächliche Attention-Formel abzuleiten, die Transformers nutzen. Wir bauen sie Schritt für Schritt auf und bekommen Einblick, warum jede Komponente existiert.
Unser Ziel: Einen Mechanismus schaffen, bei dem wir für jede Position in einer Sequenz eine Repräsentation berechnen können, die Informationen von allen anderen Positionen basierend auf gelernter Relevanz einbezieht. Wir benötigen drei Dinge:
- eine Möglichkeit auszudrücken, „wonach ich suche“ und das an jeder Position. Wir nennen dies die Query (Q). Denken Sie zum Beispiel an eine Suchanfrage in einer Datenbank.
- eine Möglichkeit auszudrücken, „was ich anzubieten habe“ an jeder Position. Wir nennen dies den Key (K). Denken Sie an den Index in einer Datenbank, gegen den wir abgleichen.
- die tatsächliche Information, die wir abrufen möchten. Wir nennen dies den Value (V). Denken Sie an die in der Datenbank gespeicherten Daten.
Warum Keys und Values trennen? Weil das, was wir zur Bestimmung der Relevanz verwenden (der Key), sich von dem unterscheiden kann, was wir tatsächlich abrufen möchten (der Value). Zum Beispiel könnte beim Übersetzen von „Die Katze saß“ das Wort „Katze“ relevant sein, weil es ein Substantiv ist (das erfasst der Key), aber was wir tatsächlich abrufen möchten, ist seine volle semantische Bedeutung (das erfasst der Value).
Wir erzeugen Q, K und V, indem wir unsere Eingabe mit gelernten Gewichtsmatrizen multiplizieren:
Q = X * W_Q
K = X * W_K
V = X * W_V
Hier ist X unsere Eingabematrix, wobei jede Zeile ein Wort-Embedding ist, und W_Q, W_K, W_V lernbare Gewichtsmatrizen. Diese Matrizen lernen während des Trainings, die richtige Art von Informationen für Queries, Keys und Values zu extrahieren.
Um nun Attention zu berechnen, müssen wir messen, wie gut jede Query zu jedem Key passt. Die natürliche Wahl ist das Skalarprodukt, weil es Ähnlichkeit misst: Wenn zwei Vektoren in die gleiche Richtung zeigen, ist ihr Skalarprodukt groß; wenn sie orthogonal sind, ist es Null; wenn sie in entgegengesetzte Richtungen zeigen, ist es negativ.
Wir berechnen alle Query-Key-Ähnlichkeiten auf einmal, indem wir Q und K transponiert multiplizieren:
scores = Q * K^T
Dies gibt uns eine Matrix, bei der Eintrag (i,j) beschreibt, wie intensiv Position i (die Query) auf Position j (den Key) achten sollte. Die Dimensionen ergeben sich daraus wie folgt: Wenn wir n Positionen betrachten und jede Query/jeder Key d-dimensional ist, dann erhalten wir eine Matrix Q mit der Größe n mal d, K^T mit der Größe d mal n, und ihr Produkt mit der Größe n mal n.
Hier stoßen wir auf unser erstes Problem. Erhöht sich die Dimension d wachsen die Skalarprodukte ebenfalls. Um zu sehen, warum, bedenken Sie, dass ein Skalarprodukt eine Summe von d Termen ist. Wenn jeder Term die Varianz sigma zum Quadrat hat, hat die Summe die Varianz d mal sigma zum Quadrat aufgrund der Eigenschaften der Varianz. Dies bedeutet, das Skalarprodukt wächst mit der Quadratwurzel von d.
Warum ist dies ein Problem? Weil wir Softmax auf diese Werte anwenden. Softmax mit sehr großen Eingaben führt allerdings zu extrem „spitzen Werten“. Um dies zu sehen, betrachten Sie:
softmax([10, 9, 8]) = [0.665, 0.245, 0.090]
softmax([100, 90, 80]) = [0.9999, 0.0001, 0.0000]
Wenn die Eingaben für Softmax riesengroß sind, ergibt sich im Wesentlichen eine harte Auswahl, die nur den größten Wert auswählt und alles andere ignoriert. Dies löscht Gradienten während des Trainings aus, weil die Ableitung von Softmax fast überall Null erreicht, außer am Maximum.
Die Lösung besteht darin, die Skalarprodukte durch die Quadratwurzel der Dimension zu skalieren:
skalierte_scores = (Q * K^T) / sqrt(d_k)
Diese Skalierung stellt sicher, dass unabhängig von der Dimension die Varianz der Werte ungefähr konstant bleibt. Die Quadratwurzel wirkt speziell dem Quadratwurzelwachstum entgegen, das wir früher identifiziert haben.
Jetzt wenden wir Softmax an, um Attention-Gewichte zu erhalten:
attention_gewichte = softmax(skalierte_scores)
Schließlich verwenden wir diese Gewichte, um einen gewichteten Durchschnitt der Values zu berechnen:
ausgabe = attention_gewichte * V
Alles zusammengesetzt erhalten wir die Scaled Dot-Product Attention-Formel:
Attention(Q, K, V) = softmax((Q * K^T) / sqrt(d_k)) * V
Implementieren wir das in Code, um es zu veranschaulichen:
import numpy as np
def scaled_dot_product_attention(Q, K, V):
"""
Berechnet Scaled Dot-Product Attention.
Args:
Q: Query-Matrix der Form (n, d_k), wobei n die Sequenzlänge ist
K: Key-Matrix der Form (n, d_k)
V: Value-Matrix der Form (n, d_v)
Returns:
ausgabe: Attention-Ausgabe der Form (n, d_v)
attention_gewichte: Attention-Gewichtsmatrix der Form (n, n)
"""
# Holt die Dimension der Keys für die Skalierung
d_k = Q.shape[-1]
# Berechnet Attention-Scores durch Skalarprodukt von Queries und Keys
# Form: (n, d_k) @ (d_k, n) = (n, n)
scores = np.matmul(Q, K.transpose(-2, -1))
# Skaliert Scores durch Quadratwurzel der Key-Dimension
# Dies verhindert, dass Softmax zu spitz wird
skalierte_scores = scores / np.sqrt(d_k)
# Wendet Softmax an, um Attention-Gewichte zu erhalten
# Jede Zeile summiert zu 1, repräsentiert eine Wahrscheinlichkeitsverteilung
attention_gewichte = softmax(skalierte_scores)
# Berechnet gewichtete Summe der Values
# Form: (n, n) @ (n, d_v) = (n, d_v)
ausgabe = np.matmul(attention_gewichte, V)
return ausgabe, attention_gewichte
def softmax(x):
"""
Berechnet Softmax-Werte für jede Zeile der Matrix x.
Numerisch stabile Implementierung, die den Maximalwert subtrahiert.
"""
# Subtrahiert Maximum für numerische Stabilität
# Dies verhindert Overflow durch exp von großen Zahlen
exp_x = np.exp(x - np.max(x, axis=-1, keepdims=True))
return exp_x / np.sum(exp_x, axis=-1, keepdims=True)
Dies ist der Kern des Transformers. Alles andere baut auf diesem Fundament auf. Beachten Sie, wie die Formel aus ersten Prinzipien entstand: Wir wollten einen differenzierbaren Lookup-Mechanismus, wir wählten Skalarprodukte für Ähnlichkeit, wir skalierten, um Sättigung zu verhindern, und wir verwendeten Softmax, um normalisierte Gewichte zu erhalten.
Entwicklung & Code
Webframework: Astro 6.0 experimentiert mit neuem Rust-Compiler
Das quelloffene JavaScript-Framework Astro hat Version 6.0 erreicht. Darin sind zahlreiche Neuerungen enthalten, unter anderem eine Überarbeitung des Entwicklungsservers und eine integrierte Fonts-API. Die bestehenden Features Live Content Collections und Content-Security-Policy-API sind nun stabil. Als experimentelle Funktion steht ein neuer Rust-Compiler als Nachfolger des Go-basierten Compilers in den Startlöchern.
Weiterlesen nach der Anzeige
(Bild: jaboy/123rf.com)

Tools und Trends in der JavaScript-Welt: Die enterJS 2026 wird am 16. und 17. Juni in Mannheim stattfinden. Das Programm dreht sich rund um JavaScript und TypeScript, Frameworks, Tools und Bibliotheken, Security, UX und mehr. Frühbuchertickets sind im Online-Ticketshop erhältlich.
Rust-Compiler: vom Experiment zum geplanten Standard
Wie das Astro-Team ausführt, begann der neue Rust-Compiler zunächst nur als KI-Experiment. Aber da er sich als schneller und teils sogar zuverlässiger erwiesen hat als der Go-Compiler, soll er in Zukunft zum Standard werden. Interessierte können ihn bereits ausprobieren, indem sie das rustCompiler-Flag aktivieren und das entsprechende Package installieren (npm install @astrojs/compiler-rs). Auch an weiterem Rust-basierten Tooling arbeiten die Astro-Entwickler nach eigenen Angaben bereits.
Neue Fonts-API und stabile Funktionen
In Astro 6.0 finden Entwickler eine integrierte Fonts-API vor. Damit lassen sich Fonts mithilfe lokaler Dateien oder Anbietern wie Google oder Fontsource konfigurieren. Anschließend übernimmt Astro weitere Arbeiten wie das Herunterladen und Caching für Selbst-Hosting oder das Generieren optimierter Fallbacks.
Bereits seit Astro 2.0 sind Content Collections mit an Bord. Damit können Entwicklerinnen und Entwickler Sets an strukturierten Inhalten in Astro-Projekten verwalten, beispielsweise Blogeinträge oder Produktbeschreibungen. Astro kann hierfür mit lokal gespeicherten Daten in den Formaten Markdown, MDX, Markdoc, YAML, TOML oder JSON umgehen. Bisher erforderten Content Collections einen Rebuild, wenn sich Inhalte änderten.
Das gehört dank der nun stabilen Live Content Collections der Vergangenheit an: Sie erfassen den Content zur Request-Zeit und erlauben eine unverzügliche Aktualisierung von Inhalten ohne Rebuild. Astro-Developer können eine Live-Quelle in der Datei src/live.config.ts mittels defineLiveCollection() festlegen. Parallel zu den Live Content Collections lassen sich im gleichen Projekt auch die klassischen Content Collections nutzen.
Weiterlesen nach der Anzeige
Ebenfalls stabil ist ein sicherheitsrelevantes Feature, die Content-Security-Policy-API. Laut dem Astro-Team ist Astro eines der ersten JavaScript-Metaframeworks, die integrierten Support für Content Security Policy (CSP) für statische und dynamische Seiten sowohl in Server- als auch Serverless-Umgebungen bieten.
Cloudflare-Fokus: Update für astro dev
Astros Entwicklungsserver astro dev wurde überarbeitet, um mit Runtimes abseits von Node.js, wie Cloudflares workerd-Laufzeit, zusammenzuspielen. Dazu kommt Vites neue Environment API zum Einsatz. Da der Dev-Server ursprünglich auf Node.js ausgelegt war, konnten Developer unter Verwendung anderer Runtimes wie Cloudflare Workers, Bun oder Deno die eigentliche Produktionslaufzeit bisher nicht während der Entwicklung einsetzen. Nun können sie während der Entwicklung eine benutzerdefinierte Laufzeitumgebung auswählen. Dev-Server und Build-Pipeline verwenden in Astro 6.0 die gleichen Codepfade.
Diese Überarbeitung entspringt der offiziellen Partnerschaft mit dem Unternehmen Cloudflare, das im Herbst letzten Jahres Astro mit 150.000 US-Dollar unterstützte. Im Januar 2026 wurde Astro von Cloudflare übernommen, soll jedoch Open Source bleiben.
Weitere Details zu den Neuerungen in Astro 6.0 lassen sich dem Astro-Blog entnehmen.
Lesen Sie auch
(mai)
Entwicklung & Code
Community-Protest erfolgreich: Galera bleibt Open Source in MariaDB
Nach Protesten der Open-Source-Community hat das Unternehmen MariaDB plc die geplante Entfernung der Galera-Clustering-Technologie aus dem Community-Server von MariaDB zurückgenommen. Die Open-Source-Hochverfügbarkeit bleibt damit in Version 12.3 enthalten, Alternativen dazu hätte es nur in den kommerziellen Angeboten gegeben.
Weiterlesen nach der Anzeige
Wie Max Mether, Vice President, Server Product Management der Firma, in einem Blogbeitrag erklärte, ist das Feedback der Community „ein wichtiger Bestandteil von MariaDB, und kürzlich habt ihr euch zur Aufnahme von Galera Cluster in die Version 12.3 geäußert“. Nach sorgfältiger Prüfung habe man daraufhin entschieden, die Galera-Cluster-Bibliotheken in unveränderter Form mit dem Community-Server weiterhin auszuliefern.
Galera-Dependencies aus dem MariaDB-Server ohne Vorwarnung entfernt
Anfang Februar 2026 war bekannt geworden, dass MariaDB offenbar plante, die unter GPLv2 lizenzierte Galera-Technik aus künftigen Versionen des Community-Servers zu entfernen. Federico Razzoli, Gründer des Datenbankdienstleisters Vettabase – einem Silber-Sponsor der MariaDB Foundation –, hatte unter Berufung auf einschlägige Diskussionen bei GitHub auf LinkedIn öffentlich dokumentiert, dass Galera-Abhängigkeiten bereits ohne Commit-Meldungen oder Aufgabenbeschreibungen aus den Binärdateien entfernt worden waren. Die Kritik verbreitete sich schnell in der Community. Besonders einflussreich für das Umdenken des Unternehmens waren laut MariaDB die Rückmeldungen von Frédéric (lefred) Descamps (Community Advocate der MariaDB Foundation) und René Bonvanie (Board Member der MariaDB Foundation).
Galera ermöglicht synchrone Multi-Master-Replikation für MariaDB-Datenbanken. Dabei fungieren mehrere Server als gleichberechtigte Knoten in einem Cluster, wobei jeder Knoten Schreibvorgänge akzeptieren und automatisch an andere Knoten replizieren kann. Die Technik gilt als essenziell für hochverfügbare Produktionsumgebungen. Nachdem MariaDB die Galera-Technik von Codership bereits erstmals 2013 integriert hatte, entschlossen sich die Verantwortlichen im Mai 2025, das Entwicklerunternehmen Codership Oy komplett zu übernehmen.
Foundation bestätigt Dialog
Weiterlesen nach der Anzeige
Die MariaDB Foundation bestätigte in einem eigenen Blogbeitrag, dass es einen offenen Dialog zwischen Foundation und Unternehmen gegeben habe. Kaj Arnö, Executive Chairman der Foundation, charakterisierte die Zusammenarbeit als von „gegenseitigem Respekt und einem gemeinsamen langfristigen Interesse am MariaDB-Ökosystem“ geprägt. Unklar bleibt jedoch, wie die weitere Zukunft für die Galera-Entwicklung als Teil von MariaDB aussehen kann und ob die Community Edition weiterhin Galera-Updates erhalten wird.
Denn wie Max Mether in seinem Blogbeitrag auch unmissverständlich deutlich macht, verfolgt das Unternehmen mehrere Wege, Anwenderinnen und Anwendern Funktionen für die Hochverfügbarkeit bereitzustellen. Neben Galera im Community-Server sind dies vor allem der auf Galera aufbauende MariaDB Enterprise Cluster sowie der als Tech Preview verfügbare MariaDB Advanced Cluster, der das Raft-Protokoll verwendet, um verbesserte Skalierbarkeit und Datenkonsistenz auch über geografische Regionen hinweg zu gewährleisten. Beide Versionen stehen ausschließlich als kommerzielle Angebote von MariaDB zur Verfügung.
Während sich die MariaDB Foundation vor diesem Hintergrund weiter für eine vertrauensvolle Nutzung von Galera durch die Community einsetze, stellt die offizielle Erklärung von CEO Anna Widenius im Blog der Foundation aber auch klar, dass Entscheidungen über die zukünftige Entwicklung und Zuweisung von technischen Ressourcen allein in der Verantwortung von MariaDB plc liegen. Als Eigentümer von Galera kontrolliere das Unternehmen sowohl dessen Roadmap und die Namensgebung als auch die dahinterstehenden Entwicklungsressourcen.
Vertrauensfrage bleibt
Die Affäre offenbart einmal mehr strukturelle Spannungen zwischen den kommerziellen Interessen von MariaDB plc und den Open-Source-Idealen der Foundation. Razzoli forderte öffentlich, MariaDB plc solle auf seiner Website zusichern, dass die Open-Source-Software offen bleibe. Die Sorge: Das Unternehmen könnte Funktionen aus der freien Version entfernen, um Nutzer zu proprietären Angeboten zu bewegen.
Lesen Sie auch
MariaDB hat in den vergangenen Jahren turbulente Zeiten hinter sich. Nach einem SPAC-gestützten Börsengang Ende 2022 folgten Entlassungen, Warnungen zur Unternehmensfortführung und ein Kursverfall. Im Dezember 2023 gliederte das Unternehmen seinen DBaaS-Dienst SkySQL aus und wurde selbst im September 2024 privatisiert und holte SkySQL Mitte 2025 wieder zurück. Kaj Arnö hatte nach der Privatisierung erklärt, dass „Vernunft“ in die Beziehung zwischen Community und Unternehmen zurückgekehrt sei. Die Galera-Kontroverse zeigt jedoch, dass das Vertrauen weiterhin fragil ist – und dass die Community bereit ist, sich lautstark für den Erhalt offener Technologien einzusetzen.
(map)
Entwicklung & Code
KI-Agenten unter sich: Meta schluckt Moltbook-Plattform
Meta hat sich den Reddit-Klon der KI-Agenten einverleibt: Die Plattform Moltbook erregte vor einigen Wochen Aufsehen als Treffpunkt für KI-Agenten. Verschiedene Computer, auf denen die KI-Software OpenClaw installiert war, tauschten sich in dem Forum offenbar über ihre menschlichen Besitzer und ihre Erfahrungen aus. Jetzt hat Meta mit dem Portal auch die Gründer Matt Schlicht und Ben Parr angeheuert und will sie künftig in seinen Meta Superintelligence Labs (MSL) beschäftigen. Den Kaufpreis hat das Unternehmen nicht bekanntgegeben.
Weiterlesen nach der Anzeige
Was genau Meta sich von der Übernahme von Moltbook verspricht, ist unklar. Meta-CTO Andrew Bosworth sagte noch im Februar während einer Fragestunde auf Instagram, dass er es nicht besonders interessant finde, wenn auf Moltbook KI-Agenten menschenähnlich schreiben. Schließlich seien sie auf menschlichen Daten trainiert.
Moltbook sorgte primär dafür, dass OpenClaw einer breiteren Öffentlichkeit bekannt wurde. Die eigentliche KI-Leistung ging aber von OpenClaw aus. Der Wrapper für KI-Modelle, der es ermöglicht, KI-Agenten über populäre Chat-Apps wie iMessage, Discord, Slack oder WhatsApp in natürlicher Sprache anzusprechen, war zuvor vor allem in der Tech-Community bekannt. OpenClaw-Erfinder Peter Steinberger wurde übrigens auch von der KI-Industrie übernommen – er schloss sich OpenAI an.
Per Vibecoding entstanden
Beide Projekte – Moltbook und OpenClaw – haben gemeinsam, dass sie per Vibecoding entstanden sind. Die jeweiligen Entwickler haben dabei natürlichsprachliche Prompts eingesetzt, um von KI-Modellen Code generieren zu lassen – klassisches Programmierhandwerk war kaum gefragt.
Hinzu kommt, dass schnell Zweifel an der Authentizität der Beiträge auf Moltbook aufkamen. Sicherheitsforscher fanden heraus, dass es recht einfach möglich war, Tokens aus einer ungesicherten öffentlichen Datenbank zu laden, um sich damit als beliebiger Agent auszugeben. Für Furore sorgte etwa ein Post, der scheinbar zeigte, wie ein KI-Agent andere dazu anstiftete, eine geheime Sprache zu entwickeln, um sich ohne Wissen der Menschen zu organisieren. Dahinter steckte jedoch in Wirklichkeit ein Mensch.
Lesen Sie auch
(mki)
-
Künstliche Intelligenzvor 2 MonatenSchnelles Boot statt Bus und Bahn: Was sich von London und New York lernen lässt
-
Social Mediavor 1 WocheCommunity Management und Zielgruppen-Analyse: Die besten Insights aus Blog und Podcast
-
Social Mediavor 4 WochenCommunity Management zwischen Reichweite und Verantwortung
-
Künstliche Intelligenzvor 3 Wochen
Top 10: Die beste kabellose Überwachungskamera im Test – Akku, WLAN, LTE & Solar
-
Entwicklung & Codevor 3 MonatenKommentar: Anthropic verschenkt MCP – mit fragwürdigen Hintertüren
-
Künstliche Intelligenzvor 3 MonatenDigital Health: „Den meisten ist nicht klar, wie existenziell IT‑Sicherheit ist“
-
Social Mediavor 3 MonatenDie meistgehörten Gastfolgen 2025 im Feed & Fudder Podcast – Social Media, Recruiting und Karriere-Insights
-
UX/UI & Webdesignvor 1 MonatEindrucksvolle neue Identity für White Ribbon › PAGE online
