JetBrains' Mellum2.1-12B-A2.5B-Thinking ist ein Coding- und Reasoning-Modell mit frei verfügbaren Gewichten unter Apache 2.0. Die Veröffentlichung im Oktober 2026 aktualisiert das Post-Training; laut JetBrains bleibt die Architektur gegenüber Mellum2 unverändert. Dieser Artikel untersucht diese bereits veröffentlichte Architektur anhand des tatsächlichen 2.1-Checkpoints. Reinforcement Learning wird dabei nicht als neuer Attention-Mechanismus dargestellt.12
Technisch interessant ist die Kombination aus Top-8-Routing unter 64 Experten, vier KV-Heads und drei lokalen Attention-Schichten pro globaler Schicht. Die Positionsskalierung für langen Kontext betrifft nur die globalen Schichten. Diese Entscheidungen reduzieren unterschiedliche Teile der Inferenzkosten. Keine davon macht das gesamte Modell zu einer Speicherbelegung von 2,5 Milliarden Parametern.
Die untersuchten Artefakte
Der am 11. Oktober 2026 geprüfte BF16-Checkpoint hat Revision 92ddae9fc7665e9f801d141d2e5a6b2caf2460c4; seine letzte Änderung stammt vom 7. Oktober. Die Konfiguration deklariert MellumForCausalLM, keine generische Qwen-Klasse. Als Implementierungsreferenzen dienen Transformers 5.10.2, Commit 0dad7b822255a0ae261ec45ae937371e859ffd1a, und vLLM 0.31.0, Commit db9527a46873454610df6dbedf79a36d6bf1a7f6.3456
Das offizielle GGUF-Repository enthält unter Revision 20b439426f1e997ba575eaccaf4856ac0f76f5d5 bereits Dateien für BF16, Q8_0, Q6_K, Q4_K_M und MXFP4_MOE. Dieser Artefaktbestand ist aktueller als die BF16-Model-Card und der Ankündigungsbeitrag, die GGUF noch als bevorstehend beschreiben. Der MTP-Kopf wird weiterhin separat angekündigt: Im geprüften BF16-Gewichtsindex stehen keine MTP-Tensoren. Gewöhnliche Inferenz mit diesem Checkpoint enthält deshalb nicht die beworbene Beschleunigung durch Speculative Decoding.728
| Komponente | Wert im Checkpoint |
|---|---|
| Decoder | 28 Schichten; Residualbreite 2.304; RMSNorm-Epsilon 10⁻⁶ |
| Attention | 32 Query-Heads; vier KV-Heads; Head-Breite 128; QK-Normalisierung |
| Lokal/global | 21 Sliding-Window-Schichten, Fenster 1.024; sieben Full-Attention-Schichten |
| Feed-Forward | 64 geroutete Experten pro Schicht; acht ausgewählt; Zwischenbreite 896; kein Shared Expert |
| Vokabular | 98.304; getrenntes Input-Embedding und getrennte Output-Projektion |
| Positionslimit | 131.072; globaler YaRN-Faktor 16 ausgehend von 8.192 Referenz-Tokens |
Diese Werte stammen aus der fixierten Konfiguration und der Implementierung. Jede veröffentlichte Schicht hat mlp_layer_types="sparse". Das Feld intermediate_size=7168 beschreibt eine mögliche dichte MLP, keinen zusätzlichen dichten Zweig dieses Checkpoints.45
Den gewöhnlichen Ablauf vom Token zur Ausgabe erklärt wie LLMs funktionieren. Mellum behält die kausale Next-Token-Generierung bei; die Unterschiede liegen innerhalb der Attention und des Feed-Forward-Schritts.
Ein Block mit konkreten Dimensionen
Der eingehende Residualzustand sei für Batch-Größe und die in diesem Aufruf verarbeiteten Tokens. Ein Block führt zunächst RMSNorm, Attention und eine Residualaddition aus. Darauf folgen eine zweite RMSNorm, das dünnbesetzte Feed-Forward-Netz und eine weitere Residualaddition. Query- und Key-Vektoren erhalten außerdem RMSNorm über ihre 128 Merkmale pro Head, bevor die rotierende Positionskodierung angewendet wird.5
Die Query-Projektion ist breiter als der Residualzustand. Die Head-Breite ist ausdrücklich als 128 konfiguriert. Sie als zu berechnen würde falsche Gewichtsformen, Rotary-Frequenzen und Cache-Budgets ergeben.
| Tensor | Form vor der Attention |
|---|---|
| Q-Projektion | [B, T, 4096] → [B, 32, T, 128] |
| K-Projektion | [B, T, 512] → [B, 4, T, 128] |
| V-Projektion | [B, T, 512] → [B, 4, T, 128] |
| Attention-Ergebnis | [B, T, 4096] → Output-Projektion → [B, T, 2304] |
Bei Grouped-Query Attention verwendet jede Gruppe von acht Query-Heads einen KV-Head. Jede Query bildet weiterhin eine eigene Attention-Verteilung; geteilt werden Keys und Values, nicht die Query-Ergebnisse. Die Eager-Referenz vervielfacht KV-Heads für die Berechnung. Ein optimierter GQA-Kernel kann sie direkt wiederverwenden. Der persistente Cache benötigt nur vier Heads.5
Für einen Query-Head an Position hat Attention die folgende gewöhnliche Form. wählt dessen KV-Gruppe. ist für sichtbare Positionen null und sonst negativ unendlich. Mit Rotary transformierte Q und K sind durch eine Tilde markiert.
Lokale Arbeit mit regelmäßigem globalem Zugriff
Bei Zählung ab null verwenden die Schichten 3, 7, 11, 15, 19, 23 und 27 volle kausale Attention. Die anderen 21 Schichten verwenden ein gleitendes kausales Fenster. In der Transformers-Referenz sieht eine lokale Query an Position Keys mit : höchstens 1.024 Positionen einschließlich der eigenen.49
An Position 20.000 sieht eine lokale Schicht beispielsweise direkt die Positionen 18.977 bis 20.000. Die folgende globale Schicht kann direkt auf die gesamte vorherige Sequenz zugreifen. Lokale Schichten können außerdem Informationen weitertragen, die bereits in benachbarte Hidden States eingeflossen sind. Das Fenster löscht also nicht grundsätzlich jeden Einfluss älteren Textes. Uneingeschränkter direkter Zugriff ist dennoch nur in sieben Schichten möglich. Die gelernte Berechnung unterscheidet sich damit von einem Modell mit 28 Full-Attention-Schichten.
Für einen langen Prefill der Länge lassen sich die erlaubten Query-Key-Paare pro Head ohne Padding zählen. Eine volle kausale Schicht hat Paare. Eine lokale Schicht hat , näherungsweise , wenn deutlich größer als das Fenster ist. Daraus folgt für den hybriden Stack die asymptotische Anzahl:
Dies ist eine Herleitung der Operationsanzahl, keine Laufzeitmessung. Die Attention-Arbeit sinkt nur, wenn der gewählte Kernel das lokale Fenster ausnutzt. Projektionen, Experten, Scheduling und Speichertransfers kosten weiterhin Zeit. Ein Eager-Pfad, der dichte maskierte Score-Matrizen materialisiert, muss die rechnerische Einsparung nicht umsetzen.
Warum nur globale Schichten YaRN verwenden
RoPE rotiert Paare von Q/K-Merkmalen abhängig von der Tokenposition. Bei 64 Merkmalspaaren und Basis lauten die gewöhnlichen inversen Frequenzen für . Dieselben orthogonalen Rotationen auf Q und K bewirken, dass ihr positioneller Zusammenhang von der relativen Entfernung abhängt:
Diese Identität erklärt die Unterscheidung zwischen lokal und global. Eine lokale Schicht sieht auch spät in einer langen Sequenz relative Abstände von höchstens 1.023. Größere absolute Tokenindizes erfordern für diese Schicht allein noch keine neue Verteilung relativer Abstände. Eine globale Schicht muss dagegen Positionen mit bis zu 131.071 Tokens Abstand vergleichen. Mellums Long-Context-Training behält deshalb gewöhnliches RoPE in lokalen Schichten bei und verwendet YaRN nur in globalen Schichten.104
Eine einheitliche Positionsinterpolation würde jede inverse Frequenz durch 16 teilen. Das streckt den nutzbaren Positionsbereich, verändert aber auch Rotationen für kurze Abstände in jedem Merkmalspaar. YaRN mischt stattdessen unskalierte und interpolierte Frequenzen: Schnell rotierende Paare behalten ihre ursprünglichen Frequenzen, langsame Paare werden gestreckt und ein Übergangsband verbindet beide Bereiche.11
Die Grenzen 18 und 35 ergeben sich aus dem Floor/Ceil-Korrekturbereich der Implementierung mit Ursprungslänge 8.192 sowie beta_fast=32 und beta_slow=1. Er bestimmt Merkmalspaarindizes anhand der Zahl ihrer Rotationen über den ursprünglichen Kontext: . Bei den Indizes 0–18 bleibt die globale Frequenz unverändert, bei 35–63 wird sie durch 16 geteilt. Die dazwischenliegenden Paare werden gemischt.11
Der Checkpoint legt außerdem einen Attention-Faktor fest. Die Implementierung multipliziert Sinus und Kosinus in globalen Schichten mit . Dadurch werden sowohl rotierte Q als auch K skaliert, sodass ihr Skalarprodukt vor Softmax den Faktor erhält. Lokale Schichten verwenden Faktor eins. Nur die Frequenzrampe nachzubilden und diesen Amplitudenfaktor wegzulassen verändert die Inferenz.4511
Die Begründung des Reports und die Rotationsidentität sprechen dafür, die lokale Geometrie zu erhalten. Sie beweisen weder den Erfolg bei jeder Long-Context-Aufgabe noch eine allgemeine Überlegenheit des Verfahrens. Der YaRN-Vergleich im ursprünglichen Report dokumentiert außerdem ein Problem mit der QA-Prompt-Formatierung in seiner RULER-Auswertung. Diese Erweiterungsexperimente betreffen das Mellum2-Training, keine neue Messung am veröffentlichten 2.1-Checkpoint.10
Acht Experten beschreiben die Berechnung
Für jeden normalisierten Tokenvektor projiziert der Router auf 64 Logits, berechnet Softmax in float32, wählt die acht größten Wahrscheinlichkeiten und normiert diese Teilmenge erneut. Jeder gewählte Experte verwendet eine SiLU-gesteuerte MLP mit Zwischenbreite 896. Ihr Ergebnis wird gewichtet und zum 2.304-dimensionalen Ergebnis des Tokens addiert.5
Jeder Experte hat drei Matrizen mit zusammen Gewichten. Über 28 Schichten enthalten alle 64 Experten rund 11,10 Milliarden Gewichte. Die acht gewählten Experten tragen rund 1,39 Milliarden Gewichte zum Berechnungspfad eines Tokens bei. Attention, Router, Embeddings und Output-Projektion kommen hinzu. Dies sind hergeleitete Matrixgrößen. „2.5B active“ ist eine gerundete Modellangabe, keine garantierte Geschwindigkeitsgleichheit mit einem dichten Modell.
Die veröffentlichten Tensor-Metadaten nennen insgesamt 12.149.923.072 BF16-Parameter. Bei zwei Bytes pro Parameter sind das etwa 22,63 GiB, vor Cache und Laufzeitspeicher. Nicht gewählte Experten bleiben gespeichert, sofern das Deployment sie nicht ausdrücklich auslagert oder verteilt. Verschiedene Tokens eines Batches können zusammen wesentlich mehr als acht Experten aktivieren. vLLM führt das Modell über seine Fused-MoE-Implementierung aus. Die Python-Schleife der Referenz beschreibt die Semantik, nicht den Ausführungsplan des GPU-Kernels.312
Ein konkretes Budget für den hybriden KV-Cache
Für eine Anfrage, eine Schicht und eine gespeicherte Position benötigen BF16-K und -V zusammen Bytes. GQA reduziert dies bereits um den Faktor acht gegenüber 32 separat gespeicherten KV-Heads. Sliding Attention begrenzt anschließend die benötigten Positionen in 21 Schichten. Die sieben globalen Schichten wachsen weiterhin mit der Sequenzlänge.4
Mit einem lokalen Arbeitsfenster von 1.024 Positionen ergibt sich die folgende logische K/V-Datenmenge. Vorausgesetzt sind ein ungeshardetes Modell, BF16-Cache, keine Prefix-Wiederverwendung und eine Runtime, die nur die benötigte lokale Historie vorhält. Die aktuelle Position ist eingeschlossen, Allocator-Overhead nicht.
| Sequenzlänge | Alle 28 Schichten voll, GQA | Hybrid lokal/global, GQA |
|---|---|---|
| 8.192 | 0,4375 GiB | 0,15039 GiB |
| 32.768 | 1,7500 GiB | 0,47852 GiB |
| 131.072 | 7,0000 GiB | 1,79102 GiB |
Am konfigurierten Maximum ist die hybride Datenmenge 74,41 % kleiner als bei einer hypothetischen vollständig globalen Variante mit denselben Heads. Dies ist ein berechneter Speichervergleich, keine gemessene VRAM-Reduktion und kein Vergleich mit einem separat trainierten Modell. Die sieben globalen Caches enthalten weiterhin 1,75 GiB; lokale Schichten ergänzen etwa 0,041 GiB. Eine Multiplikation mit der Zahl unabhängiger Anfragen schätzt deren logische Datenmenge, nicht den gesamten Server-VRAM.
Der dynamische Transformers-Cache hält die letzten 1.023 lokalen Positionen für den nächsten Aufruf vor und verbindet sie für Attention mit den neuen Tokens. Seine Update-Funktion gibt die größeren konkatenierten Tensoren zurück. Die gespeicherten Ausschnitte können deren zugrunde liegende Speicherbelegung teilen. Gerade ein großer Prefill oder Chunk kann deshalb physisch mehr Speicher belegen, als die Form des behaltenen Tensors vermuten lässt. Paged Allocation, temporäre Puffer und statische Caches können weiteren Platz beanspruchen. Eine lokale Attention-Maske allein belegt weder Eviction noch tatsächlichen Speicherverbrauch.13
Schon das idealisierte Budget bei maximalem Kontext beträgt 22,63 + 1,79 ≈ 24,42 GiB allein für BF16-Gewichte und KV. Aktivierungen, Scratch-Speicher und Serving-Reservierungen kommen hinzu. Deshalb passt ein Modell mit „2.5B active“ nicht automatisch bequem in ein 24-GiB-Budget. Details zu Allocation und Parallelität erklären die KV-Cache-Speicherrechnung und der Artikel zur Quantisierung.
Den veröffentlichten Pfad betreiben
Die fixierte vLLM-Implementierung wählt rope_parameters[layer_type] und übergibt das schichtspezifische Fenster an Attention. Sie berücksichtigt auch die explizite Head-Breite 128. Eine Runtime, die nur die Expertengewichte lädt, aber dieselbe globale RoPE-Konfiguration auf alle Schichten anwendet, bildet diesen Checkpoint nicht korrekt nach.6
Mit bereits installiertem vLLM 0.31.0 startet der folgende Aufruf das fixierte BF16-Modell mit einem bewusst kleineren Limit von 32.768 Tokens. Die Parser-Flags folgen der Model-Card. Sie trennen die Reasoning-Ausgabe und parsen Tool-Aufrufe, führen aber keine Tools aus. Das Kontextlimit sollte erst nach Prüfung des Speicherbudgets und des Workloads erhöht werden.2
vllm serve JetBrains/Mellum2.1-12B-A2.5B-Thinking \
--revision 92ddae9fc7665e9f801d141d2e5a6b2caf2460c4 \
--dtype bfloat16 \
--max-model-len 32768 \
--reasoning-parser qwen3 \
--enable-auto-tool-choice \
--tool-call-parser hermesDieser Aufruf ist ein anhand der Quellen geprüftes Konfigurationsbeispiel, kein unabhängig ausgeführter GPU-Test. Zu prüfen sind die Unterstützung des gemischten Fenstermusters durch das gewählte Attention-Backend und die tatsächlichen Cache-Reservierungen. Bei Tensorparallelität mit mehr als vier Ranks kann die vLLM-Implementierung KV-Heads replizieren. Der Gesamtspeicher folgt dann keiner einfachen Division durch die Rank-Zahl.6
GGUF reduziert die Gewichtsspeicherung unabhängig vom Attention-Design. Die offizielle Q4_K_M-Datei ist mit 8,1 GB angegeben. Das ist eine Dateigröße, nicht der gesamte Arbeitsspeicherbedarf. Ihre veröffentlichten Quantisierungsvergleiche verwenden Wikitext-2 mit 512 Tokens Kontext. Diese Logit-Vergleiche belegen weder agentische Coding-Genauigkeit noch Qualität bei 128K. Quantisierte Gewichte implizieren außerdem nicht automatisch einen quantisierten KV-Cache.7
Mellum2.1 zeigt an einem veröffentlichten Modell, wie dünnbesetzte Feed-Forward-Berechnung und günstigere lokale Attention kombiniert werden können, während regelmäßiger globaler Zugriff erhalten bleibt. Schichtspezifisches YaRN passt die Positionsgeometrie des globalen Pfads an. Ob diese Balance zu einem Coding-Service passt, hängt von Aufgaben, Anfragelängen, Quantisierung und Runtime ab. Architektur und Parameterzahlen allein belegen weder Durchsatz noch Antwortqualität.
Primärquellen
Footnotes
-
JetBrains, Mellum2.1 Gets to Work, October 2026; checked 2026-10-11. Explicitly distinguishes post-training changes from unchanged architecture. ↩
-
JetBrains, Mellum2.1 Thinking model card, pinned revision. ↩ ↩2 ↩3
-
Hugging Face, JetBrains checkpoint metadata at the inspected revision, BF16 tensor count; checked 2026-10-11. ↩ ↩2
-
Hugging Face Transformers 5.10.2, Mellum implementation:
MellumAttention,MellumRotaryEmbedding,MellumTopKRouter,MellumExperts,MellumDecoderLayer. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 -
vLLM 0.31.0, Mellum implementation, per-layer rotary/window configuration and tensor-parallel KV-head allocation. ↩ ↩2 ↩3
-
JetBrains, official GGUF model card and files, pinned revision; card lists sizes and quantization measurement conditions. ↩ ↩2
-
JetBrains, released weight index. ↩
-
Transformers 5.10.2, mask implementation,
sliding_window_overlay,sliding_window_causal_mask_function. ↩ -
Kojic et al., Mellum 2 Technical Report, 2026-05-29, especially Sections 2.2, 4.1 and C.1. Describes the inherited architecture and limits of its original extension evaluation. ↩ ↩2
-
Transformers 5.10.2, YaRN implementation,
_compute_yarn_parameters. ↩ ↩2 ↩3 -
vLLM 0.31.0, Qwen3 MoE implementation reused by Mellum,
Qwen3MoeSparseMoeBlockandFusedMoEFactory. ↩ -
Transformers 5.10.2, cache implementation,
DynamicSlidingWindowLayer.updateandDynamicCache. ↩