100 Millionen Token: Gedächtnis oder Trugbild?

Versuchen wir es einmal mit Bildern. Einhundert Millionen Token ist keine Zahl, die das menschliche Gehirn spontan visualisieren kann, also brauchen wir einen Anker. Ein Token entspricht in der Sprache der Sprachmodelle etwa drei Vierteln eines englischen Wortes. Zehntausend Token sind etwa fünfundsiebzig Textseiten. Eine Million Token steht für die gesamte *Recherche von Proust – jenes siebenbändige Werk, von dem fast jeder behauptet, es gelesen zu haben. Zehn Millionen Token decken das gesamte Werk von Shakespeare plus die Bibel plus einige mittelgroße Enzyklopädien ab. Einhundert Millionen Token entsprechen etwa einer kleinen Universitätsbibliothek, sagen wir sechzigtausend Romane durchschnittlicher Länge, die in einem einzigen aktiven Kontext geladen sind und gleichzeitig einem Sprachmodell zur Verfügung stehen, das Fragen beantwortet.*
Dies ist die zentrale Behauptung des Projekts Memory Sparse Attention (MSA), das vom Team von EverMind im März 2026 auf Zenodo veröffentlicht wurde und von einem GitHub-Repository begleitet wird, das derzeit über 3000 Sterne zählt. Die Aussage ist deutlich: Eine Architektur, die in der Lage ist, das kontextuelle Gedächtnis auf bis zu 100 Millionen Token zu skalieren und dabei weniger als 9 % Leistungsabfall im Vergleich zum Ausgangspunkt beizubehalten. Für diejenigen, die im Jahr 2026 mit Sprachmodellen arbeiten, wo die praktische Grenze der vollen Aufmerksamkeit noch immer zwischen 128.000 und einer Million Token liegt, bevor sich die Dinge ernsthaft verschlechtern, ist dies eine Zahl, die Aufmerksamkeit verdient. Sie verdient auch einige Fragen.
Der Flaschenhals, der alles ausbremst
Um zu verstehen, was MSA vorschlägt, muss man zunächst verstehen, warum das Problem überhaupt existiert. Transformer, die Architektur, auf der praktisch alle zeitgenössischen großen Sprachmodelle basieren, haben einen bekannten strukturellen Fehler: Die Aufmerksamkeit bei voller Dichte (full-density attention) skaliert quadratisch zur Länge des Kontexts. In der Praxis bedeutet dies, dass eine Verdoppelung des Kontexts die Rechenkosten nicht verdoppelt, sondern vervierfacht. Bei 128.000 Token ist die Situation bereits anspruchsvoll; bei einer Million wird sie prohibitiv; bei einhundert Millionen ist sie mit der Standardarchitektur schlicht unmöglich, unabhängig von der Anzahl der eingesetzten GPUs.
Existierende Lösungen lassen sich grob in drei Familien unterteilen, von denen keine zufriedenstellend ist. Die erste ist die Kompression latenter Zustände, wie in linearen oder hybriden Architekturen (Mamba, Jamba und ähnliche), die die Rechenkomplexität reduzieren, aber dazu neigen, Informationen schrittweise zu verlieren – wie eine Fotokopie einer Fotokopie einer Fotokopie. Die zweite ist der externe Speicher via RAG (Retrieval-Augmented Generation): Ein Korpus von Dokumenten wird außerhalb des aktiven Kontexts gehalten, und relevante Teile werden zum Zeitpunkt der Abfrage (Query) abgerufen. Das funktioniert und ist bereits überall im Einsatz, führt aber zu einer strukturellen Diskontinuität: Retrieval und Generierung sind zwei separate Systeme, die separat trainiert und optimiert werden. Diese Trennung hat ihren Preis in Bezug auf Kohärenz und Multi-Hop-Reasoning. Die dritte Familie ist die brachiale Erweiterung des Kontexts, die all die oben genannten quadratischen Probleme mit sich bringt.
MSA schlägt vor, einen vierten, bisher wenig erforschten Raum zu besetzen: einen end-to-end trainierten Sparse-Attention-Mechanismus, der das Retrieval direkt in die Transformer-Architektur integriert, ohne die differenzierbare Kette zu unterbrechen. Die Intuition ist brillant. Die Ausführung bedarf der Prüfung.
Das Gehirn mit zwei Geschwindigkeiten
Die MSA-Architektur ist – zumindest metaphorisch – von etwas Ähnlichem wie der neuropsychologischen Unterscheidung zwischen Arbeitsgedächtnis und Langzeitgedächtnis inspiriert. Das ist kein absolut neues konzeptionelles Konzept, aber die Art der Implementierung weist einige originelle Merkmale auf.
Der Ausgangspunkt ist die physische Trennung des Speichers. Wenn ein Dokument von MSA verarbeitet wird, erzeugt das Modell drei Arten von komprimierten Repräsentationen: Routing Keys (Kᵣ), Content Keys (K̄) und Content Values (V̄). Routing Keys sind stark komprimierte, leichte Vektoren, die nur eines tun sollen: schnell die Frage beantworten: „Ist dieses Dokument für die aktuelle Query relevant?“. Ihr Platz ist im VRAM der GPU, wo die Zugriffslatenz im Bereich von Mikrosekunden liegt. Der vollständige Inhalt, K̄/V̄-Keys und -Values, wird hingegen in den CPU-System-RAM ausgelagert, der viel reichhaltiger und kostengünstiger, aber langsamer ist. Erst wenn der Router entscheidet, dass ein Dokument relevant ist, wird dieser Inhalt vom RAM in den VRAM übertragen, um an der Aufmerksamkeitsberechnung teilzunehmen.
Dieses Schema, das das Team Memory Parallel nennt, ermöglicht es, die Routing-Phase auf mehreren GPUs parallel zu verteilen: Jede verwaltet einen Teil der Routing Keys, die Queries werden per Broadcast übertragen, die Relevanzwerte werden aggregiert, und nur die ausgewählten Top-k-Dokumente werden tatsächlich geladen. Das alles, so die Autoren, auf einer Konfiguration von nur zwei NVIDIA A800 GPUs.
Das zweite relevante Architekturelement ist die document-wise RoPE, eine Variante der rotativen Positionseinbettungen (RoPE), die in modernen Transformern verwendet werden. Das Problem bei Standard-RoPE in extrem langen Kontexten besteht darin, dass das Modell, das auf kurzen Sequenzen trainiert wurde, „nicht weiß“, wie es die sehr hohen Positionen interpretieren soll, die während der Inferenz in langen Kontexten auftreten, was zu einer Verschlechterung der Leistung führt. Die von MSA vorgeschlagene Lösung ist einfach: Der Positionszähler wird am Anfang jedes Dokuments auf Null zurückgesetzt. Jeder Text beginnt immer bei Position Null, unabhängig davon, wie viele Dokumente ihm im Speicher vorausgehen. Dies ermöglicht es einem Modell, das auf Sequenzen von 64.000 Token trainiert wurde, 100 Millionen Token zu extrapolieren, ohne jemals Positionen außerhalb der Verteilung zu sehen.
Die Wahl ist intelligent, bringt aber eine bemerkenswerte Konsequenz mit sich: Die Dokumente im Speicher werden aus positioneller Sicht in ihrer Reihenfolge ununterscheidbar. Das Modell weiß, was in jedem Dokument steht, hat aber kein positionelles Signal, das anzeigt, welches Dokument in der absoluten zeitlichen Abfolge „neuer“ oder „älter“ ist. Für Anwendungen, bei denen die chronologische Reihenfolge eine Rolle spielt, ist dies eine reale Einschränkung, die das Paper nur implizit einräumt.

Memory Interleave: Reasoning oder intelligentes Retrieval?
Die dritte Säule der Architektur ist aus Sicht der Argumentation wahrscheinlich die interessanteste und wirft auch die schwierigsten Fragen auf. Sie nennt sich Memory Interleave und adressiert ein Problem, mit dem traditionelle RAG-Systeme schlecht umgehen: Multi-Hop-Fragen.
Eine Multi-Hop-Frage ist eine Frage, deren Beantwortung die Verknüpfung von Informationen erfordert, die in verschiedenen Dokumenten verstreut sind, wobei die Information in Dokument B notwendig ist, um zu verstehen, welcher Teil von Dokument C gesucht werden muss. „Wer war der Regisseur des Lieblingsfilms des Schriftstellers, der 1981 den Booker Prize gewann?“ ist ein banales Beispiel: Es sind mindestens drei Schritte erforderlich, und jeder Schritt hängt vom Ergebnis des vorherigen ab. Ein RAG-System, das Dokumente nur einmal vor der Generierung abruft, hat strukturell Schwierigkeiten mit dieser Art von Argumentation. Es kann fünf Dokumente abrufen in der Hoffnung, dass sie alles Notwendige enthalten, aber das ist ein Blindflug.
Memory Interleave schlägt stattdessen einen iterativen Zyklus vor: Das Modell wechselt zwischen Phasen des „generativen Retrievals“ (es erzeugt die Identifikatoren der Dokumente, die es lesen möchte), Phasen des tatsächlichen Abrufs dieser Dokumente und Phasen der partiellen Generierung, bis es genügend Evidenz für eine Antwort hat. Die Anzahl der pro Runde abgerufenen Dokumente wird dynamisch vom Modell selbst bestimmt, nicht durch einen festen Hyperparameter. Ablationsexperimente im Paper zeigen, dass das Entfernen von Memory Interleave zu einem durchschnittlichen Abfall von 5,3 Prozentpunkten bei den QA-Benchmarks führt – und allein bei HotpotQA, einem Datensatz, der speziell für zweistufiges Reasoning entwickelt wurde, um 19,2 Punkte.
Diese Zahlen sind überzeugend, aber hier stellt sich eine journalistisch relevante Frage, die das Paper nicht explizit beantwortet: Verbessert Memory Interleave das Reasoning des Modells oder einfach nur das Retrieval? Die Unterscheidung ist nicht akademischer Natur. Wenn der Effekt hauptsächlich darin besteht, dass das Modell dank der Iterationen nützlichere Informationen abruft, dann bleibt die zugrunde liegende Argumentationsfähigkeit die des Qwen3-4B-Backbones, und die Verbesserungen bei HotpotQA spiegeln ein intelligenteres Retrieval wider, keine überlegene Inferenzfähigkeit. Wenn der iterative Mechanismus es dem Modell hingegen ermöglicht, komplexere Argumentationsketten aufzubauen, als es mit allen bereits im Kontext vorhandenen Informationen könnte, dann haben wir es mit etwas strukturell Neuem zu tun.
Das Paper liefert keine Experimente, die klar zwischen diesen beiden Szenarien unterscheiden, und die Tatsache, dass MuSiQue – der Datensatz für Multi-Hop-Reasoning mit drei oder mehr Schritten – den niedrigsten absoluten Wert in der gesamten Tabelle aufweist (2,211 von 5), deutet darauf hin, dass die Gewinne mit zunehmender inferenzieller Komplexität abnehmen. Dies ist keine Kritik, sondern ein offenes Feld, das die künftige Forschung untersuchen muss.
Die Zahlen unter der Lupe
Kommen wir zu den Benchmarks, die gesonderte Aufmerksamkeit und einen kritischen Blick verdienen. Das im GitHub-Repository beschriebene Versuchssetup verwendet neun Question-Answering-Datensätze (MS MARCO, Natural Questions, DuReader, TriviaQA, NarrativeQA, PopQA, 2WikiMultiHopQA, HotpotQA, MuSiQue) mit Speicherbänken von 277.000 bis 10 Millionen Token sowie NIAH-Tests (Needle-in-a-Haystack, in der RULER-Version) bis zu einer Million Token. Das Backbone ist Qwen3-4B-Instruct, ein Modell mit vier Milliarden Parametern aus dem Jahr 2025.
Die Ergebnisse im Vergleich zu RAG auf demselben Backbone sind wahrhaft beeindruckend: MSA erreicht eine durchschnittliche Punktzahl von 3,760 von 5 gegenüber 3,242 für das beste RAG mit Reranker, was einer relativen Verbesserung von 11,5 % entspricht. Bei MS MARCO, dem Datensatz mit der größten Speicherbank (7,34 Millionen Token), vergrößert sich der Abstand deutlich: 4,141 gegenüber 3,032, was einem Vorteil von etwa 37 % entspricht. Bei HotpotQA übertrifft MSA RAG+Reranker um etwa 4 %. Bei NarrativeQA hingegen verliert es: RAG mit Reranker erreicht 3,638 gegenüber 3,395 für MSA – der einzige Datensatz von neun, bei dem MSA im Vergleich bei gleichem Backbone nicht am besten abschneidet.
Der Vergleich mit RAG-Systemen auf viel größeren Backbones (KaLMv2 mit Qwen3-235B und mit Llama-3.3-70B) fällt differenzierter aus. MSA mit 4B Parametern erreicht den besten absoluten Durchschnitt (3,760), verliert aber bei vier von neun Datensätzen gegenüber den stärksten Konfigurationen, und der durchschnittliche Vorteil gegenüber Qwen3-235B mit Reranker liegt bei 5 %. In der Praxis hält ein sechzigmal kleineres Modell mit einem 235-Milliarden-Parameter-Giganten Schritt, wenn der architektonische Vorteil im Speichermanagement groß genug ist, um den Skalierungsunterschied auszugleichen. Das ist ein bemerkenswertes Ergebnis, sollte aber ohne Übertreibung gelesen werden.
Zwei Aspekte des Versuchssetups sollten jedoch explizit benannt werden, da sie die Interpretation der Zahlen beeinflussen. Erstens: Der Bewertungsmaßstab für die QA-Benchmarks ist ein LLM-Richter, der Punkte von 0 bis 5 vergibt. Diese Art der Bewertung ist zwar zum Standard in diesem Bereich geworden, bringt aber eine intrinsische Variabilität mit sich, und die Tatsache, dass das Richtermodell im README nicht spezifiziert ist, sorgt für eine Undurchsichtigkeit, die in einem Peer-Review-Paper nicht akzeptabel wäre. Zweitens: Der wichtigste Skalierbarkeits-Benchmark, die 16K→100M Token-Kurve mit weniger als 9 % Degradation, wird nur an MS MARCO gemessen, einem einzigen Datensatz. Die Verallgemeinerbarkeit dieser Kurve auf andere Arten von Inhalten, Fragenverteilungen oder andere Sprachen als Englisch muss erst noch bewiesen werden.
An der NIAH-Front sind die Ergebnisse klarer und einfacher zu bewerten: MSA behält eine Genauigkeit von 94,84 % bei einer Million Token bei, während das unveränderte Backbone auf 24,69 % einbricht. Hybride lineare Aufmerksamkeitsmodelle (die direkteste Konkurrenz) zeigen bereits ab 128.000 bis 256.000 Token eine spürbare Verschlechterung. Dies ist das solideste Ergebnis des Papers, da der NIAH-Benchmark standardisiert ist, in der Community weit verbreitet ist und wenig Spielraum für interpretative Zweideutigkeiten lässt.
Zum Zeitpunkt der Erstellung dieses Artikels ist der Code öffentlich im GitHub-Repository verfügbar, mit Installationsanweisungen, dem MSA-4B-Modell, das direkt von Hugging Face heruntergeladen werden kann, und Benchmarks, die über Skripte replizierbar sind. Dies ist ein nicht triviales Zeichen von Reife: Es bedeutet, dass die Ergebnisse im Prinzip von jedem überprüft werden können, der über die entsprechende Hardware verfügt, und dass die Community damit beginnen kann, das System an eigenen Anwendungsfällen zu testen.

100 Millionen Token auf 2×A800: Zu welchem Preis?
„Fast lineare Komplexität“ ist eine der am häufigsten missbrauchten Phrasen im Vokabular der Transformer-Forschung und erfordert fast immer eine Übersetzung. Im Fall von MSA bezieht sich die formale Komplexität von O(L) auf die Routing- und Sparse-Attention-Phase, verbirgt aber eine Reihe konkreter Kosten, die ein seriöser Artikel nicht ignorieren kann.
Der erste Kostenfaktor ist die Fetch-Latenz aus dem CPU-Speicher. Wenn der Router entscheidet, welche Dokumente geladen werden sollen, müssen diese Daten über den PCIe-Bus, der eine typische Bandbreite von 16-32 GB/s hat, vom System-RAM in den VRAM der GPU übertragen werden. Bei einhundert Millionen Token können die zu übertragenden Datenmengen pro Query trotz aggressiver KV-Cache-Kompression im Gigabyte-Bereich liegen. Das Paper nennt keine expliziten End-to-End-Latenzzahlen für einzelne Queries, was ein wichtiges Versäumnis für jeden ist, der die Produktionsreife beurteilen möchte.
Der zweite Kostenfaktor ist die Offline-Encoding-Phase. Bevor MSA Fragen zu einem Korpus beantworten kann, muss es alle Dokumente in diesem Korpus verarbeiten, um die Repräsentationen K̄, V̄ und Kᵣ zu erzeugen. Dies ist ein einmaliger Aufwand für statische Korpora, wird aber zu einem wiederkehrenden Problem für Korpora, die sich häufig aktualisieren, wie z. B. Gesprächshistorien in einer Agenten-Anwendung oder Echtzeit-Datenfeeds in Unternehmen. Das Paper beschreibt dies als Offline-Encoding, was darauf hindeutet, dass die Architektur primär für relativ stabile Korpora gedacht ist.
Der dritte Kostenfaktor ist der persistente Speicher. Ein Korpus von 100 Millionen Token benötigt selbst bei aggressiver Kompression erhebliche Mengen an System-RAM. Ohne spezifische Zahlen im Paper zu den tatsächlichen Kompressionsraten und den resultierenden Größen des komprimierten KV-Caches ist es schwierig, die genauen Infrastrukturkosten abzuschätzen, aber für einen Unternehmenseinsatz auf realen Korpora bewegen wir uns wahrscheinlich im Bereich von Hunderten von Gigabyte RAM. Nicht unmöglich, aber auch nicht trivial.
Dies führt zur zentralen Frage, die es verdient, explizit formuliert zu werden: Löst MSA den Flaschenhals des Speichers oder verlagert es die Komplexität lediglich auf Storage, Retrieval und Orchestrierung? Die ehrliche Antwort ist, dass beides gleichzeitig wahr ist. MSA lindert das Problem der quadratischen Komplexität der Aufmerksamkeit auf echte Weise, indem es das Retrieval differenzierbar integriert und bei praktisch allen getesteten Benchmarks bessere Ergebnisse als RAG erzielt. Aber es eliminiert die infrastrukturelle Komplexität nicht: Es verteilt sie auf verschiedene Komponenten, von denen einige (der CPU-GPU-Transfer, das RAM-Management, das Offline-Encoding) im verfügbaren öffentlichen Material noch nicht gut dokumentiert sind. Für ein Forschungsteam ist es ein echter Fortschritt. Für ein Engineering-Team, das das System in die Produktion bringen muss, bleiben Fragen offen.
EverMind: Memory as a Service
Es lohnt sich zu verstehen, wer hinter MSA steht, denn die Einordnung des Projekts ändert sich je nach Kontext erheblich. EverMind ist ein Startup mit Sitz in Singapur, das mit dem erklärten Ziel gegründet wurde, Langzeitgedächtnis-Infrastruktur für KI-Agenten aufzubauen. Sein Hauptprodukt ist EverOS, ein Speichermanagementsystem für Agenten, das verschiedene Techniken, einschließlich MSA, in eine breitere Plattform integriert. Das Team veröffentlichte Ende März 2026 Ergebnisse zu vier Memory-Benchmarks (LoCoMo, LongMemEval, PersonaMem und einem proprietären Evaluierungsframework) und beanspruchte für sich State-of-the-Art-Leistungen.
Die Flugbahn ist die eines Startups, das das baut, was im Jargon der Branche „Memory-as-a-Service“ genannt wird: eine Abstraktionsschicht, die sich zwischen Basis-Sprachmodelle und Anwendungen schiebt und die Persistenz, den Abruf und die Organisation der Erinnerungen des Agenten im Zeitverlauf verwaltet. Das ist eine schlüssige industrielle Positionierung, und MSA ist die technische Basis dafür.
Die Tatsache, dass das Paper auf arXiv und nicht an einem zweitrangigen Ort veröffentlicht wurde und der Code bereits öffentlich auf GitHub verfügbar ist – mit dem MSA-4B-Modell zum direkten Download von Hugging Face und per Skript ausführbaren Benchmarks –, ist ein ernstzunehmendes Zeichen von Reife. Die Ergebnisse sind prinzipiell von jedem mit entsprechender Hardware überprüfbar, und die Community kann damit beginnen, das System an eigenen Anwendungsfällen zu testen. Die Forschung wird öffentlich kommuniziert und die technischen Assets sind offen: Für ein Startup in der Frühphase ist das nicht die Norm und ein Element, das in der Gesamtbewertung des Projekts positiv ins Gewicht fällt.
Die dreizehn Autoren des Papers (darunter Chen Yu, Chen Runkai, Yi Sheng und andere, mit Lidong Bing und Tianqiao Chen als Senior-Figuren) stellen ein Team von glaubwürdiger Größe und Profil für die beschriebene Art von Arbeit dar. Es gibt derzeit keine unabhängigen Bewertungen der Ergebnisse durch dritte Forschungsgruppen, was für ein Paper von vor wenigen Monaten normal ist, aber man sollte es im Hinterkopf behalten, wenn man die prozentualen Verbesserungen liest.

Eleganter Proof-of-Concept oder fertiges System?
Das ist die Frage, die sich jeder ehrliche Artikel über diese Art von Forschung stellen muss, und die Antwort ist hier zwiespältig. MSA ist im jetzigen Zustand ein überzeugend beschriebenes System mit glaubwürdigen Benchmark-Ergebnissen auf einem Testset, das breit genug ist, um nicht als Cherry Picking (Rosinenpickerei) abgetan werden zu können, und mit einer Architektur, die eine kohärente und gut begründete interne Logik besitzt. Es ist kein leeres Versprechen.
Gleichzeitig ist es wahrscheinlich im ingenieurtechnischen Sinne noch kein produktionsreifes System. Die Skalierbarkeits-Benchmarks für 100 Millionen Token werden an nur einem Datensatz (MS MARCO) demonstriert, und die tatsächliche Verschlechterung bei anderen Arten von Inhalten in diesem Maßstab ist unbekannt. Die Leistung bei NarrativeQA – dem Datensatz mit den längsten Geschichten und dem stärksten kontextuellen Verständnis – ist der einzige Fall, in dem MSA gegen RAG mit Reranker verliert, was darauf hindeutet, dass dichte narrative Inhalte ein Schwachpunkt sein könnten. Die End-to-End-Query-Latenz, die Kosten für das Encoding des Korpus und die Anforderungen an den System-RAM werden nicht mit der für eine ingenieurtechnische Bewertung erforderlichen Präzision kommuniziert.
Es stellt sich auch eine subtilere Frage nach der Portabilität. Alle Ergebnisse wurden auf Qwen3-4B erzielt, einem spezifischen Backbone mit spezifischen Eigenschaften. MSA erfordert das End-to-End-Training des Routers und des Sparse-Attention-Mechanismus: Es ist nichts, was man einfach wie ein Plugin auf ein beliebiges vortrainiertes Modell aufsteckt. Das Paper beschreibt ein Training auf 158,95 Milliarden Token mit einem zusätzlichen Routing-Loss, gefolgt von zwei Phasen des Supervised Fine-Tuning mit Curricula von 8.000 bis 64.000 Token. Diesen Prozess auf einem anderen Backbone (Llama, Mistral, Gemma) zu wiederholen, würde erhebliche Ressourcen und Zeit erfordern, und es ist nicht garantiert, dass sich die Ergebnisse identisch übertragen lassen.
Disco Elysium, das narrative Rollenspiel von ZA/UM, baut sein Gedächtnissystem auf Fragmenten, Wispern und Erinnerungen auf, die der Protagonist iterativ und oft unzuverlässig abruft, um eine größere Geschichte zu rekonstruieren. MSA macht in gewisser Weise etwas Ähnliches: Es ruft verstreute Fragmente aus einer riesigen Bibliothek ab, setzt sie iterativ zusammen und versucht, eine kohärente Argumentation aufzubauen. Der Unterschied ist, dass im Spiel das Scheitern des Retrievals Teil der Erzählung ist; in einem Produktionssystem ist es ein Bug. Wie oft MSA daran scheitert, die richtigen Fragmente abzurufen, und mit welchen Konsequenzen, ist genau die Art von Frage, die nur der öffentliche Code und unabhängige Experimente beantworten können.
MSA verdient Aufmerksamkeit, Studium und direktes Experimentieren. Die Frage, ob es den Flaschenhals des Speichers wirklich löst oder ihn lediglich auf Infrastruktur, Storage und Orchestrierung verlagert, hat noch keine endgültige Antwort und wird sie wahrscheinlich erst haben, wenn jemand außerhalb von EverMind das System an einem realen Anwendungsfall zerlegt und wieder zusammengesetzt hat. In der Zwischenzeit ist es eine der interessantesten Architekturen, die dieses Jahr im Bereich des Speichers für Sprachmodelle erschienen sind, und das GitHub-Repository ist es bereits wert, beobachtet zu werden.