Lese-Ansicht

Updates zu lokalen Sprachmodelle: MTP, APEX, Qwopus

Unser Buch Coding mit KI ist gerade erst erschienen, schon gibt es spannende Neuigkeiten rund um die Ausführung lokaler Modelle:

  • Multi-Token Prediction (MTP) ist ein ganz neues Feature in llama.cpp. Seit ein paar Tagen steht es auch in LM Studio zur Verfügung. Durch einen »Trick« (Details folgen gleich) kann mit MTP die Output-Token-Geschwindigkeit deutlich vergrößert werden: laut diversen Benchmarktests im Internet bis auf das Doppelte, in meinen Tests immerhin um ca. 60 bis 70 Prozent.
  • Adaptive Precision for EXpert Models (APEX) ist ein neues Verfahren zur besonders platzsparenden Quantisierung von MoE-Modellen. Der Platzbedarf sinkt je nach Qualitätsstufe auf die Hälfte gegenüber der herkömmlichen 4-Bit-Darstellungen (Q4_x_x).

  • Qwopus ist eine neue Variante zu den Qwen-Modellen, bei denen das Fine Tuning mit Claude Opus verbessert wurde.

Von Speculative Decoding zur Multi-Token Prediction

In Coding mit KI gehe ich kurz auf das Vorgängerkonzept zu MTP ein, auf Speculative Decoding: Dabei führt die Engine (z.B. llama.cpp) zwei Sprachmodelle. Das kleinere (schnellere) dient als Draft Model. Während der Token-Generierung macht das Draft Model Vorschläge für die folgenden Token. Das größere, qualitativ bessere Modell überprüft anschließend eine Sequenz mehrerer vorgeschlagener Token auf einmal. Im Idealfall wird die ganze Sequenz akzeptiert. Der Geschwindigkeitsvorteil ergibt sich durch die parallele Verifizierung eines ganzen Token-Blocks. Dazu sind weniger Speicher-Transfers vom VRAM in die GPU notwendig, als wenn jedes Token für sich generiert wird. (Die Token-Generierung wird durch zwei Faktoren limitiert: die Rechenleistung der GPU und die Speicherbandbreite vom VRAM in die GPU-Cores. Speculative Decoding setzt beim zweiten Punkt ein, der oft der limitierende Faktor ist.)

In der Praxis funktioniert das nur mäßig gut: Zum einen ist es schwierig, ein geeignetes Draft Model zu finden. Es muss aus der gleichen »Familie« stammen, aber deutlich kleiner sein, idealerweise etwa um den Faktor zehn. Zum anderen funktioniert Speculative Decoding für Dense Models besser als für Mixture of Experts Models (MoE). Das Problem bei MoE besteht darin, dass bei jedem Token andere »Experten« zum Einsatz kommen können, was den Geschwindigkeitsvorteil von Speculative Decoding teilweise zunichtemacht. Kleinere MoE-Modelle für den Draft-Einsatz haben zudem oft eine andere Experten-Aufteilung, was die Acceptance Rate verringert.

Multi-Token Prediction (MTP) greift die Idee des Speculative Decoding auf. Der entscheidende Unterschied besteht darin, dass ein Modell ausreicht. Ein in das Modell integrierter Layer ist dafür zuständig, rasch ein paar Tokens (üblicherweise 2 bis 4) vorherzusagen. Das Gesamtmodell überprüft dann alle Token auf einmal, was nur unwesentlich mehr Zeit kostet, als ein Token zu berechnen. MTP erspart damit das umständliche Handling mit zwei Modellen.

Speculative Decoding und Multi-Token Prediction sind mit keinerlei Qualitätsverlust verbunden! Es werden exakt die gleichen Ergebnisse erzielt, weil jede Token-Sequenz vollständig kontrolliert und bei Abweichungen verworfen wird. Werfen Sie diesbezüglich einen Blick in das Video von Donata Capitella, das diesen Umstand anschaulich erklärt.

Für den erzielten Geschwindigkeitsgewinn ist der Prozentsatz der akzeptierten Draft Tokens entscheidend. Dieser variiert je Aufgabenstellung: Bei kreativem Text ist die Akzeptanzrate nur mittelmäßig, bei Code hingegen deutlich höher — ganz einfach deswegen, weil Code strengen Regeln folgt und weniger Spielraum als menschliche Sprachen bietet.

Leider ist auch MTP mit Nachteilen verbunden:

  • Das Modell muss für MTP konzipiert sein. MTP muss schon beim Training berücksichtigt werden. Das Modell benötigt einen zusätzlichen Layer für die Token Prediction. Aktuell gibt es nur eine einzige »freie« Modellfamilie mit MTP, nämlich Qwen 3.6 und dessen Variante Qwopus. Gemma-4-Modelle sollten demnächst folgen. In Zukunft wird MTP wohl zu einem Standard-Feature für freie Modelle.
  • Natürlich muss auch die Software MTP unterstützen. Weil viele Programme intern llama.cpp verwenden, wird MTP rasch weite Verbreitung finden.

  • Schließlich teilt sich MTP einen Nachteil mit Speculative Decoding: Es funktioniert bei herkömmlichen Dense-Modellen besser als bei MoE-Modellen (Mixture of Experts). Die ohnedies schon schnellen MoE-Modelle werden also nur geringfügig schneller oder, wie bei einigen meiner Tests, sogar langsamer. Bei den Dense-Modellen ist dagegen eine spürbare Verbesserung zu bemerken. Bei meinen Tests ca. +65%, bei einigen Benchmarks im Internet bis zu +100%, also eine Verdoppelung der Output-Token-Rate.

  • MTP ändert nichts an der Input-Verarbeitung (dem Prompt Processing, pp). Schneller wird nur der Output (die Token Generation, tg).

Dense versus Mixture of Experts (MoE): MoE ist schneller, kann aber qualitativ bei gleicher Modellgröße nicht ganz mithalten. Während bei Dense-Modellen immer alle Parameter aktiv sind, nutzen MoE-Modelle nur wenige, stets wechselnde »Experten«, also Subsets mit viel weniger Parametern. Das spart Zeit, aber kein »Experte« ist so gut wie das volle Modell. Dementsprechend sinkt die Qualität der Antworten, nicht massiv, aber spürbar.)

Praktische Erfahrungen

Ich habe MTP mit LM Studio 0.4.14 auf meinem Framework Desktop ausprobiert (AMD Ryzen Max 395 CPU/GPU). Mein Mini-Benchmarktests lautete: »Explain Python dictionaries«. Die getesteten Modelle denken über diese Frage eine Weile nach und produzieren dann einen mehrseitigen, qualitativ sehr hochwertigen Text mit eingebauten Code-Schnipseln.

LM Studio mit dem Modell Qwen 3.6 und Multi-Token Prediction (MTP)

Ich habe alle Tests mit einem Kontextfenster von 128.000 Token ausgeführt. Bei den MTP-Modellen habe ich die Einstellung MTP Max Tokens = 3 verwendet, also immer drei Tokens auf einmal erzeugt. Alle getesteten Modelle weisen eine 4-Bit-Quantisierung auf (Ausnahme: das APEX-Modell, siehe unten). Als Backend kommt llama.cpp mit Vulkan zum Einsatz.

                                                            Draft Token 
Modell                     MoE   APEX  MTP   Output (tg)    Acceptance
-----------------          ----  ----  ----  ------------   ------------------
qwen-3.6-27b               nein  nein  nein  12,3 Token/s
qwen-3.6-27b-mtp           nein  nein  ja    20,1 Token/s   66,3 %
qwopus-3.6-27b-v2-mtp      nein  nein  ja    19,0 Token/s   63,7 %

qwen-3.6-35b-a3b           ja    nein  nein  69,7 Token/s
qwen-3.6-35b-a3b-mtp       ja    nein  ja    67,1 Token/s   66,6 %
qwen-3.6-35b-a3b-apex-mtp  ja    ja    ja    71,5 Token/s   63,3 %
qwopus-3.6-35b-a3b-mtp     ja    nein  ja    74,2 Token/s   68,2 %

Professionellere Benchmark-Tests hat Donata Capitella durchgeführt (siehe die ersten zwei Links in den Übersicht der Quellen am Ende des Artikels). Interessanterweise ist dort auch bei MoE-Modellen ein spürbarer Geschwindigkeitszuwachs von etwa 30% zu sehen, den ich bei meinen Tests aber nicht nachvollziehen kann.

Qwopus-Modelle

Die neuen Qwopus-Modelle basieren auf Qwen-Modellen, erhalten aber ein zusätzliches Fine-Tuning mit Claude Opus. Dieses soll den Nachdenkprozess beschleunigen und eine bessere Antwortqualität mit sich bringen. Die erste Versprechung trifft definitiv zu, aber ich bin nicht in der Lage, die Qualität des Modells im Detail zu beurteilen. Subjektiv hatte ich den Eindruck, dass die Unterschiede zu den Qwen-Originalen gering sind.

Zum Denkprozess: Beim Prompt »write a Sudoku solver in Python« denkt qwen-3.6-27b-mtp ca. 1:30 Minuten nach, qwopus-3.6-27b-v2-mtp aber ca. nur 1:00 Minuten. (Die Denkzeit hat eine relativ starke Varianz, weswegen hier genaue Angaben sinnlos sind.) Die resultierende Antwort samt Code ist mehr oder weniger gleichwertig (Backtracking-Algorithmus).

APEX Quantisierung

Die Verkleinerung von Modellen bei möglichst geringen Qualitätsverlust ist zu einer eigenen KI-Disziplin geworden. Die Grundidee besteht darin, Milliarden von Parametern (also eigentlich Fließkommazahlen) mit möglichst wenigen Bits darzustellen, ohne dass die Qualität der Ergebnisse allzu sehr leidet.

Der geringere Platzbedarf von Modellen ist insbesondere dann wichtig, wenn der Speicher (VRAM) limitiert ist. Mit einer geschickten Quantisierung läuft ein Modell vielleicht gerade noch auf einer GPU mit 16 GiB VRAM.

Vor ein paar Monaten machte Google mit dem neuen Turbo-Quant-Verfahren Furore. Bei der Recherche für diesen Artikel bin ich nun auf das neue Verfahren Adaptive Precision for EXpert Models (APEX) gestoßen. Das von Local AI entwickelte Verfahren ist speziell für MoE-Modelle optimiert und kompatibel zu aktuellen llama.cpp-Versionen. Die Grundidee besteht darin, dass für jede Parametergruppe eine andere, für den Wertebereich und die Wichtigkeit angepasste Quantisierung verwendet wird. Insofern ist eine klare Bit-Angabe (4 Bit pro Parameter) unmöglich. Technische Details und Benchmarks finden Sie auf der GitHub-Projektseite. Local AI arbeitet daran, Modelle lokal auf Smartphones auszuführen; da ist die möglichst platzsparende Darstellung natürlich wichtig.

Konkret sind APEX-Modelle zum Teil wirklich erheblich kleiner als vergleichbare Modelle mit Q4-Quantisierung, wie sie bei der lokalen Ausführung von Modellen üblich ist. Die folgende Tabelle zeigt lauter Qwen-3.6-Modelle mit jeweils 35 Milliarden Parameter. Das APEX-MTP-Modell benötigt nur halb so viel Platz wie das MTP-Modell mit einer herkömmlichen Q4-Quantisierung.

Überblick der heruntergeladenen Modelle in LM Studio

Leider verrät die Huggingface-Seite des Modells nicht, welche Variante der APEX-Quantisierung verwendet wurde. Es existieren verschiedene Qualitätsstufen, z.B. Quality, Balanced, Compact und Mini. Ich würde vermuten, das Modell ist eher bei Mini als bei Quality angesiedelt.

Modell                      Quantisierung   Größe (Disk)
------------------------    -------------   ------------
qwen-3.6-35b-a3b            Q4_K_M          22,0 GB
qwen-3.6-35b-a3b-mtp        Q4_K_S          23,0 GB
qwen-3.6-35b-a3b-apex-mtp   APEX            11,7 GB (!)

Bei der Ausführung des Modells waren für mich keine nennenswerten Unterschiede erkennbar, weder in der Geschwindigkeit noch qualitativ. Aber nochmals: Das sind subjektive Feststellungen anhand einiger Tests, keine objektiven Benchmark-Tests. Dazu fehlt mir ganz einfach die Zeit.

Quellen/Links

Ausgewählte Modelle mit MTP und/oder APEX

Technisch/Wissenschaftliche Grundlagen

  •  

Weichenstellung für Jahrzehnte: Europa definiert digitale Souveränität neu – OSBA warnt vor Verwässerung

Die deutsch-französische „Taskforce für die Digitale Souveränität Europas", ins Leben gerufen beim Gipfel zur Europäischen Digitalen Souveränität am 18. November 2025 in Berlin, erarbeitet derzeit eine verbindliche Definition digitaler Souveränität. Diese soll künftig die Grundlage für deutsche und europäische Gesetzgebung sowie für Förder- und Beschaffungsprozesse bilden.

Quelle

  •  

Euro-Office ab 9. Juni verfügbar

Gestern hat die Nextcloud GmbH bei einer Round Table-Veranstaltung über die Pläne der Brancheninitiative zur Entwicklung und Verfügbarkeit der souveränen Office-Suite Euro-Office informiert.

  •  

Restack: a new European consortium for a digital Europe

Restack: a new European consortium for a digital Europe

Recent geopolitical events have highlighted Europe's need for a resilient, homegrown technology ecosystem free from critical dependencies. The new Horizon Europe project Restack aims to accomplish it. The FSFE is a partner of the Restack consortium, providing legal and licensing support for potentially over 200 Free Software projects and assisting their growth into part of a wider European digital commons.

Europe urgently needs to regain the capabilities to run its own digital infrastructure. The “cloud-first” strategy that has dominated in the past decade has shown itself to be an unsustainable long-term strategy in light of geopolitical stressors. Despite this need for digital sovereignty, funding for European projects such as the Next Generation Internet Zero (NGI0) programme was cut. As a result, the FSFE’s ability to provide legal and licensing support for Free Software projects that have the potential to improve the internet as a platform would have come to a halt in 2027. In light of this setback, the FSFE and our fellow NGI0 consortium partners have been searching for an alternative to provide similar support for Free Software projects.

These efforts proved successful in February 2026, when the proposal for Restack, spearheaded by our consortium partner the NLnet Foundation, was approved. Operating under Horizon Europe, this new 10M€ initiative will enable the consortium partners to continue strengthening the European ecosystem of contributors to the digital commons with financial and practical support.

The Open Internet Stack framework is a cascade funding programme designed to retain the strength of the NGI Zero approach: nurturing bottom-up innovation by providing small- and medium-sized grants to creators of free and open technologies, including Free Software, Open Hardware, and Open Data related projects. It will also provide a pipeline of tailored support to strengthen the quality and maturity of these projects. The main novelty within Restack is that a significant amount of targeted effort will be added to wrap the resulting innovation catalogue into a coherent stack.

Restack aims to support projects that can help accomplish the following goals:

  • Strengthening the “Free and Open” technology ecosystem, based on sovereignty and privacy;
  • Improving the resilience of the internet;
  • Addressing and reducing the environmental impact of digital technology; and
  • Improving transparency in the technological supply chain.

The hope is that, by supporting the growth of such European projects, Restack will contribute to a healthy Free Software and technological environment that supports collaboration and transparency. Such an environment can also strengthen privacy and security for different groups, ranging from consumers to vulnerable communities such as minorities and journalists. Additionally, we hope that this project can help develop economic incentives that encourage collaborative strategies and community engagement.

As Restack is currently still in its early stages, more information about how Free Software projects can apply for funding and technical support will be shared in the coming weeks.

Next Generation Internet and the FSFE

Since 2018, the FSFE has been a consortium member of the Next Generation Internet (NGI), supported by the European Commission's DG CNECT. The NGI has the mission to re-imagine and re-engineer the internet in order to shape a value-centric, human, and inclusive society for all.

The FSFE's team provides guidance to successful grantee projects on legal and licensing issues, and helps them become REUSE compliant. Through individual assessments and direct assistance, we aim to promote the display of unambiguous, human-readable, and machine-readable licence and copyright information. Other consortium partners provide support on issues that can improve each grantee software project, such as security, accessibility, and translations, among others. A similar workflow is expected to be enacted for software projects that are supported under Restack as well.

Support FSFE

  •  

Hilft oder schadet die große Vielfalt an Linux Distributionen?

Linux steht für Freiheit und Vielfalt an Linux Distributionen. Doch die wachsende Zahl an Distributionen wirft eine alte Frage neu auf. Hilft diese Auswahl wirklich jedem oder entsteht ein Effekt, der eher bremst als befreit. Viele Nutzer lieben die große Auswahl, doch andere fühlen sich schnell allein gelassen oder gar überfordert. Neue Distros erscheinen fast […]

Der Beitrag Hilft oder schadet die große Vielfalt an Linux Distributionen? erschien zuerst auf fosstopia.

  •  

Bayern plant eigenen souveränen Arbeitsplatz für die Verwaltung

Bayern startet ein neues Projekt für mehr digitale Unabhängigkeit. Das Digitalministerium entwickelt einen souveränen Arbeitsplatz, der langfristig proprietäre Lösungen ersetzen soll. Die Initiative folgt dem Beschluss der Ministerpräsidentenkonferenz, die bis 2027 sichere Alternativen fordert. Digitalminister Fabian Mehring betont die Bedeutung digitaler Souveränität für Staat und Verwaltung. Er sieht die öffentliche IT als kritische Infrastruktur, die […]

Der Beitrag Bayern plant eigenen souveränen Arbeitsplatz für die Verwaltung erschien zuerst auf fosstopia.

  •  

Thunderbird 151.0.1 veröffentlicht

Die MZLA Technologies Corporation hat mit Thunderbird 151.0.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 151.0.1

Mit Thunderbird 151.0.1 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit ein Problem beim Weiterleiten von Exchange-Nachrichten.

Der Beitrag Thunderbird 151.0.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

  •  
❌