Der MTP-Kopf von Mellum2.1: 1,11x schneller bei einer Anfrage, 1,45x bei acht, und das Modell läuft in 8 Bit auf einer RTX 5080 mit 16 GB

Die Vorhersagen lagen 87 von 100 Mal richtig, und trotzdem schrieb das Modell nur 11 % schneller. Das haben wir gemessen, als wir den kleinen Rater eingeschaltet haben, den JetBrains mit Mellum2.1 ausliefert, seinem offenen Coding-Modell. Die Modellseite von JetBrains verspricht 1,4- bis 1,8-mal schnelleres Schreiben bei gleicher Ausgabe. Mit der von JetBrains empfohlenen Einstellung stieg eine einzelne Anfrage auf einer RTX A6000 mit 48 GB in unserer Cloud von 107 auf 119 Tokens (Wortstücke) pro Sekunde. Mit acht Anfragen gleichzeitig, direkt auf dem vLLM-Server gemessen, lag der Gewinn bei 1,45x, also innerhalb der Spanne von JetBrains; über unseren Endpoint bekommst du heute die 1,11x einer einzelnen Anfrage. Wenn du eigene GPUs betreibst: Der Rater hat sich bei acht gleichzeitigen Anfragen weit mehr gelohnt als bei einer. In einer komprimierten 8-Bit-Kopie, halb so groß wie die veröffentlichte, läuft das Modell außerdem auf einer echten RTX 5080 mit 16 GB.

Ein zusätzlicher Block rät das nächste Wort, und das Modell prüft jeden Tipp

Der Rater ist ein kleiner Zusatzteil des Modells, der das Wort nach dem gerade geschriebenen rät. Das volle Modell prüft dann den Tipp. Stimmt es zu, behält es zwei Wörter für ungefähr den Preis eines Schritts. Wenn nicht, verwirft es den Tipp und macht weiter. JetBrains nennt diesen Teil den Kopf (Head).

Stell dir eine Bandkollegin vor, die kurz vor dem Wechsel den nächsten Akkord ansagt. Meistens nickt der Bassist nur und spielt ihn, statt ihn selbst herauszuhören. Die Ansage kostet fast nichts. Das Nicken kostet trotzdem einen Schlag, und dieser Schlag entscheidet, wie viel Zeit die Band spart.

Das ist das Versprechen auf der Modellseite von JetBrains. Das Modell „verifies every drafted token, so the output is unchanged“, während das Schreiben 1,4- bis 1,8-mal schneller läuft und etwa 90 % der Tipps akzeptiert werden. Der Haken ist das Prüfen. Es kostet ebenfalls Zeit, und JetBrains sagt nicht, auf welcher GPU und mit wie vielen Anfragen diese Spanne gemessen wurde.

Mellum2.1 Thinking ist das offene Modell von JetBrains für Code und Reasoning. Es ist ein kleines Modell, bei dem nur 2,5B seiner 12B Parameter an jedem Wort arbeiten. JetBrains hat es im September veröffentlicht und geschrieben, der Draft-Kopf sei „coming soon“. Der Kopf kam am 30. Oktober als separater Download. Laut JetBrains ist das Modell selbst unverändert. Der Kopf bringt eine Datei mit 0,86 GB und eine Zeile Konfiguration mit.

Ein Flag war die einzige Änderung, auf zwei echten GPUs und mit fünf Prompts

Den Kopf schaltet ein zusätzliches Flag ein, und das war das Einzige, was wir zwischen den Läufen geändert haben. Wir haben das Modell mit vLLM 0.33 bereitgestellt, der Open-Source-Serving-Software, die JetBrains empfiehlt. Ohne das Flag ignoriert der Server den Kopf und fährt das Modell ohne ihn.

Die Haupt-GPU war eine RTX A6000 mit 48 GB in unserer Cloud, die das Modell in voller Größe fuhr, so wie es veröffentlicht ist. Wir haben dieselben fünf Prompts mit und ohne Kopf geschickt: die eigene „Finde den Bug“-Frage von JetBrains, eine Coding-Aufgabe, eine Matheaufgabe, eine Erklärung und einen Tool-Aufruf. Danach haben wir unsere Plattform umgangen und auf dem Server selbst gemessen, mit einer Anfrage und mit acht gleichzeitig, mit einem, zwei und drei Tipps pro Schritt. Eine zweite Maschine, eine echte RTX 5080 mit 16 GB, hat gezeigt, wie klein die GPU sein darf.

Die Grenzen, einmal zusammengefasst: Es sind unsere Prompts, nicht die Tests der Autoren, und kein Dokument war lang genug, um die volle Gesprächslänge des Modells von 131.072 Tokens zu füllen. Jede Einstellung lief einmal, mit kurzen Antworten, kleine Unterschiede sind also Rauschen. Wir haben bis zu acht gleichzeitige Anfragen getestet, nicht mehr. vLLM fährt Mellum über generischen Code, nicht über Code, der für dieses Modell geschrieben wurde, und eine native Version könnte diese Zahlen ändern. Die Ergebnisse für 32 GB und 24 GB stammen aus einer Begrenzung des Speichers der A6000, nicht von echten GPUs dieser Größe.

Eine Anfrage: 1,11x mit der Einstellung von JetBrains, 1,31x mit zwei Tipps

Mit der Einstellung von JetBrains, einem Tipp pro Schritt, stieg eine einzelne Anfrage auf der A6000 von 106,8 auf 118,9 Tokens pro Sekunde. Das sind 1,11x, deutlich unter der versprochenen Untergrenze von 1,4x.

Im Alltag heißt das: Eine Coding-Antwort von etwa 600 Tokens brauchte über unseren Endpoint 5,9 Sekunden ohne Kopf und 4,9 Sekunden mit ihm. Bei einer langen Antwort sparst du eine Sekunde. In einem Chatfenster merkst du das nicht, und ein Agent, der fünfzig solcher Aufrufe macht, spart weniger als eine Minute.

Die Tipps waren nicht das Problem. Laut den eigenen Zählern von vLLM wurden 87,2 % davon akzeptiert, nah an den 90 % von JetBrains. Das Modell rät gut, und das Prüfen frisst den Großteil des Gewinns. Unsere beste Erklärung, nicht gemessen: vLLM hat noch keinen optimierten Code für Mellum. Und ein Modell, das pro Wort so leicht ist, ist so schnell, dass das Prüfen ungefähr so viel kostet, wie es spart.

Zwei Tipps pro Schritt schnitten besser ab: 140,2 Tokens pro Sekunde, 1,31x. Nur zwei von drei trafen (66,6 %), aber jeder Treffer sparte zwei Schritte. Drei Tipps: Etwa die Hälfte traf (48,6 %), 124,8 Tokens pro Sekunde. Bei einer Anfrage gewannen zwei Tipps. Die vLLM-Dokumentation empfiehlt, mit einem Tipp anzufangen. Probier einen und zwei mit deinem eigenen Traffic aus.

Acht Anfragen gleichzeitig: 1,45x, innerhalb der Spanne von JetBrains

Mit acht Anfragen gleichzeitig auf der A6000 war dieselbe Arbeit in etwa zwei Dritteln der Zeit fertig: 607,3 Tokens pro Sekunde gegen 418,4, also 1,45x, direkt auf dem vLLM-Server gemessen; über unseren Endpoint bekommst du heute die 1,11x einer einzelnen Anfrage. Das widerspricht dem üblichen Muster, nach dem Speculative Decoding weniger bringt, je mehr Anfragen sich stapeln; wir haben es einmal gemessen und können es nicht erklären.

Mit einem, zwei und drei Tipps lagen acht gleichzeitige Anfragen zwischen 1,39x und 1,66x, es lohnt sich also bei jeder dieser Einstellungen. Zwischen zwei und drei Tipps gab es keinen klaren Gewinner.

Der Kopf kostet weniger als ein Gigabyte Gewichte, bezahlt mit Platz für Gespräche

Der Kopf braucht auf der A6000 weniger als ein Gigabyte (0,80 GiB) zusätzlich. vLLM hält den gesamten Speicherverbrauch der GPU fest, also zeigen sich die Kosten an anderer Stelle.

Der Server führt einen Notizblock über jedes laufende Gespräch, damit er es nicht bei jedem Wort neu lesen muss. Der Speicher, den das Modell nicht braucht, geht an diesen Notizblock. Mit eingeschaltetem Kopf schrumpfte der Notizblock der A6000 von 1.122.580 Tokens auf 1.027.634, etwa 8,5 % weniger. Das reicht immer noch für fast acht Gespräche in der vollen Modelllänge von 131.072 Tokens. Auf einer 48-GB-GPU ist der Kopf nahezu gratis.

Auf einer 16-GB-GPU ist er das nicht. Auf der RTX 5080 aus dem nächsten Abschnitt ging der Notizblock von 52.400 Tokens auf 29.019 zurück: Platz für drei volle Gespräche mit 16.384 Tokens wurde zu Platz für eines. Diese Zahl solltest du abwägen, bevor du den Kopf auf einer kleinen GPU einschaltest.

Welche GPU: 16 GB haben gereicht, auf einer echten RTX 5080 mit 8-Bit-Gewichten

Die kleinste GPU, die funktioniert hat, war eine echte RTX 5080 mit 16 GB. Wir haben vLLM eine komprimierte Kopie laden lassen, halb so groß wie die veröffentlichte (8 Bit), mit Gesprächen von bis zu 16.384 Tokens. Sie schrieb 217,2 Tokens pro Sekunde ohne Kopf, 288,7 mit einem Tipp (1,33x) und 291,2 mit zwei. In der Spitze nutzte sie 97 % ihres Speichers und lieferte jede Antwort richtig. Das schlägt die A6000 in voller Größe. Wahrscheinliche Gründe, nicht gemessen: Sie ist eine neuere GPU, und kleinere Gewichte bedeuten weniger zu lesen pro Wort.

Du brauchst keine 48 GB; das war nur unsere Haupt-Test-GPU. In voller Größe startete das Modell mit der 24-GB-Begrenzung nicht: Die Gewichte allein belegen 23,47 GiB und lassen keinen Platz für den Notizblock.

Gleiche Antworten in der Qualität, nicht Byte für Byte

Jeder Lauf lieferte richtige Antworten, mit Kopf und ohne. Das Modell fand den Bug im Beispiel von JetBrains jedes Mal. Seine Funktion zum Zusammenführen von Intervallen bestand unsere vier Prüfungen in allen 13 Ausgaben, die wir getestet haben. Die Matheaufgabe beantwortete es in jedem Lauf mit 400. Seine Tool-Aufrufe kamen korrekt formatiert zurück.

„Output is unchanged“ galt nicht Byte für Byte. Mit der Anweisung, immer das wahrscheinlichste Wort zu wählen, lieferten zwei Läufe desselben Prompts auf demselben Server Antworten mit 369 und 810 Tokens. Das passierte auch ohne Kopf (380 und 829). Die vLLM-Dokumentation sagt das auch: Die Rundung der GPU und die Zahl der gemeinsam laufenden Anfragen können die genauen Wörter ändern. Wenn deine Tests die Modellausgabe Byte für Byte vergleichen, brechen sie mit oder ohne Kopf. Vergleich stattdessen das Ergebnis.

Auf InferenceKey: Eine Einstellung schaltet den Kopf um, und eine kalte GPU war in 8 Minuten bereit

Eine Einstellung im SDK-Beispiel schaltet den Kopf ein oder aus, und der Server startet in 101 Sekunden neu. Eine kalte Maschine brauchte 488,9 Sekunden, etwa 8 Minuten, von unserer Anfrage bis zur Antwortbereitschaft. Etwa vier dieser Minuten gingen für die Installation von vLLM 0.33 drauf und drei dafür, dass vLLM seine Engine aufwärmt.

Wir haben vLLM 0.33.0 in unserem Standard-Setup gewählt und den Befehl von JetBrains wie in unserem Test ausgeführt. Nichts musste gebaut oder gepatcht werden. Die RTX 5080 brauchte 20 Minuten, das meiste davon für langsame Paket-Downloads auf dieser Maschine.

Das Problem, auf das du stoßen wirst: Unsere Plattform gibt jedem Modell immer nur eine Anfrage auf einmal weiter. Acht Anfragen über unseren Endpoint stehen Schlange, deshalb wurde der Gewinn von 1,45x oben auf dem Server selbst gemessen, nicht über die Plattform. Über unseren Endpoint bekommst du heute den Gewinn einer einzelnen Anfrage. Status: offen auf unserer Seite.

Dieser Lauf nutzte eine lokale Kopie der Plattform mit demselben Worker, nicht den gehosteten Dienst.

Solltest du ihn einschalten? Ja auf einer geteilten GPU, und teste zwei Tipps

• Eine GPU, die sich ein Team oder mehrere Agents teilen: Schalte ihn ein; über InferenceKey siehst du den Gewinn, sobald der Worker parallele Anfragen schickt (offen auf unserer Seite).
• Ein Entwickler, eine Anfrage nach der anderen: Stell zwei Tipps pro Schritt ein und miss nach.
• Eine 16-GB-GPU: Nutze 8-Bit-Gewichte und rechne mit weniger Platz für parallele Gespräche. Belegt auf einer neueren RTX 5080; ältere 16-GB-GPUs können beim Laden scheitern.
• Eine 24-GB-GPU: 8-Bit-Gewichte funktionierten unter einer emulierten 24-GB-Begrenzung.
• Tests, die die Ausgabe Byte für Byte vergleichen: Vergleich Ergebnisse, nicht Bytes.

Um den Kopf auf deiner eigenen GPU ein- und auszuschalten, führ python main.py und danach MELLUM_MTP=0 python main.py aus dem Mellum2.1-MTP-SDK-Beispiel aus. Es braucht einen privaten NVIDIA-Worker mit 48 GB (32 GB bestanden nur unter einer emulierten Begrenzung) oder 16 GB mit MELLUM_FP8=1 MELLUM_CONTEXT=16384, dazu ein SDK-Token und einen API-Key. Über unseren Endpoint zeigt es den Gewinn einer einzelnen Anfrage, und am Ende löscht es das Deployment.

vllm serve JetBrains/Mellum2.1-12B-A2.5B-Thinking-MTP \
  --max-model-len 131072 --gpu-memory-utilization 0.90 --max-num-seqs 16 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice --tool-call-parser hermes \
  --speculative-config '{"method": "mtp", "num_speculative_tokens": 1}'