AngelSlim von Tencent: ein Kompressionsbaukasten mit sehr breitem Anspruch

Welches Problem AngelSlim adressiert und für wen es gedacht ist

Große Modelle lassen sich selten unverändert dort betreiben, wo sie gebraucht werden. AngelSlim setzt genau an dieser Stelle an: Das Repository versammelt Verfahren, die Gewichte kleiner, schneller oder speichereffizienter machen. Die Themenliste des Projekts nennt Quantisierung, spekulative Dekodierung, LLM-Kompression sowie die Modellfamilien Qwen, DeepSeek, Hunyuan, Eagle, Diffusion, VLM und Audio. Die Zielgruppe sind damit nicht Endanwender, sondern Teams, die ein vorhandenes Modell auf eine bestimmte Hardware oder ein Latenzziel bringen müssen und dafür Trainings- oder Kalibrierläufe in Kauf nehmen.

Der Anspruch ist ausdrücklich breit. Die README beschreibt das Projekt als zugänglicher, umfassender und effizienter als vergleichbare Werkzeuge. Ein Blick auf die Liste der Änderungen zeigt, was das praktisch bedeutet: In derselben Versionsreihe tauchen FP8-Static für Hunyuan-MT-7B, NVFP4-Gewichte für Qwen3-32B, ein 1,25-Bit-Kernel für llama.cpp, eine ternäre Quantisierung namens TEQUILA und ein Trainingsframework für spekulative Dekodierung auf. Wer ein einzelnes Problem lösen will, bekommt hier also sehr viel mehr mitgeliefert, als er angefragt hat.

Der Aufbau: Konfigurationen, Skripte und getrennte Zweige

Aus der Repository-Struktur lässt sich ablesen, wie das Projekt organisiert ist. Es gibt ein Verzeichnis configs/ mit Unterordnern wie configs/flux und configs/seed_oss, daneben ein Verzeichnis scripts/ptq. Quantisierung läuft demnach über Konfigurationsdateien, die pro Modell hinterlegt sind, und über Skripte, die diese Konfigurationen ausführen. Wer ein neues Modell komprimieren will, kopiert also nicht einen universellen Befehl, sondern sucht die passende Konfiguration oder legt eine eigene an.

Auffällig ist, dass nicht alle Verfahren im Hauptzweig liegen. Die ternäre Quantisierung TEQUILA verweist auf den Zweig tequila/TernaryQuant, der 1,25-Bit-Ansatz Sherry auf den Zweig sherry/Sherry. Das ist ein Hinweis darauf, dass einzelne Algorithmen als eigenständige Entwicklungslinien geführt werden, mit jeweils eigener Dokumentation. Für die Praxis heißt das: Wer Sherry oder TEQUILA einsetzen will, muss den Zweig wechseln oder den Code von dort übernehmen, und darf nicht erwarten, dass ein Checkout von main alles enthält.

Quantisierung: von FP8 bis 1,25 Bit

Der größte Teil der Änderungsliste dreht sich um Quantisierung. Genannt werden FP8-Static, SmoothQuant, W4A8-FP8, NVFP4, INT4 sowie 2-Bit- und 1,25-Bit-Varianten. Die Bandbreite ist beachtlich, und sie ist nicht theoretisch: Zu mehreren Verfahren veröffentlicht das Projekt fertige Gewichte, etwa Qwen3-32B-NVFP4, Qwen3-235B-A22B-NVFP4, Hy-MT1.5-1.8B-2bit und Hy-MT1.5-1.8B-1.25bit. Wer diese Modelle direkt herunterlädt, spart sich den Kalibrierlauf komplett.

Ein eigener Zweig namens DAQ wird als Quantisierungsalgorithmus beschrieben, der Wissen erhält, wenn die Parameteränderung während des Post-Trainings klein bleibt. Das ist eine inhaltliche Aussage über den Anwendungsfall: DAQ richtet sich an Modelle, die nachtrainiert wurden, nicht an solche, die unverändert aus dem Vortraining kommen. Wer diese Unterscheidung nicht trifft, wählt unter Umständen das falsche Verfahren. Die Dokumentation zu DAQ liegt unter docs/source/features/quantization/daq.md, also abseits der allgemeinen PTQ-Skripte.

Spekulative Dekodierung und spärliche Attention

Neben der Quantisierung führt AngelSlim mehrere Beschleunigungsverfahren. Eagle3 wird laut Änderungsliste für LLMs, VLMs und Audiomodelle unterstützt, mit Trainings- und Deployment-Anleitung. D-Cut wird als adaptive Pruning-Methode für die Verifikationstiefe beschrieben. DFlare kombiniert Block-Diffusion mit schichtweiser Fusion. Stem wiederum ist kein Dekodierverfahren, sondern greift die Prefill-Phase langer Kontexte an, indem es dynamisch die Top-k-Schlüsselblöcke für block-sparse Attention auswählt.

Bemerkenswert ist die Trennung zwischen AngelSlim und AngelSpec. Das Trainingsframework für spekulative Dekodierung liegt in einem eigenen Repository, Tencent/AngelSpec, mit eigener Dokumentation unter angelspec.readthedocs.io. Die Änderungsliste nennt für DFly eine durchschnittliche Beschleunigung von bis zu 2,40x gegenüber autoregressiver Dekodierung und für D-Cut bis zu 15,7 Prozent mehr Durchsatz bei hoher Nebenläufigkeit. Diese Zahlen stammen aus der Projektankündigung, nicht aus einer unabhängigen Messung. Wer sie als Planungsgrundlage nutzt, sollte die genannten Bedingungen (Modell Hy3-A21B, hohe Nebenläufigkeit) genau prüfen.

Inbetriebnahme: was in der README tatsächlich steht

Die README ist an dieser Stelle zurückhaltend. Sie nennt die Dokumentationsseite angelslim.readthedocs.io, eine technische Report-Referenz, Hugging-Face- und ModelScope-Organisationen sowie Chat-Kanäle. Konkrete Installationsbefehle, Konfigurationsschlüssel oder ein Beispielaufruf für die Quantisierung stehen im vorliegenden Auszug nicht. Wer wissen will, wie ein PTQ-Lauf gestartet wird, muss die Dokumentation oder das Verzeichnis scripts/ptq öffnen.

Was sich belegen lässt, sind die Pfade: Konfigurationen liegen unter configs/ mit modellspezifischen Unterordnern, Quantisierungsskripte unter scripts/ptq, und einzelne Verfahren haben eigene Dokumentationsdateien wie docs/source/features/quantization/daq.md oder docs/source/features/qad/mcore_qad.md. Ein Beispiel für einen veröffentlichten Anwendungsfall ist die GGUF-Variante von Hy4-preview, die laut Ankündigung von 1,5 TB auf 214 GiB komprimiert wurde und mit Prima.cpp auf einem Laptop mit RTX 4090 plus einem Server mit vier A4000 lief. Die dabei genannte Rate von 1,02 Tokens pro Sekunde zeigt zugleich, dass extreme Kompression nicht automatisch niedrige Latenz bedeutet.

Wo AngelSlim nicht passt

Die Breite des Projekts ist zugleich seine größte Einschränkung. Wer ein Modell komprimieren will, das nicht in der Liste der unterstützten Familien auftaucht, findet keine allgemeine Anleitung, sondern muss eine eigene Konfiguration schreiben und die Skripte anpassen. Die README nennt Unterstützung für Qwen3, DeepSeek-R1/V3, Kimi-K2, GLM-4.6, Hunyuan, FLUX und Seed-OSS. Alles außerhalb dieser Aufzählung ist ungetestetes Neuland.

Ein zweiter Punkt ist die Verteilung über Zweige und Repositories. Sherry liegt unter sherry/Sherry, TEQUILA unter tequila/TernaryQuant, das Training für spekulative Dekodierung unter Tencent/AngelSpec. Wer diese Trennung nicht kennt, sucht im Hauptzweig nach Code, der dort nicht liegt. Drittens ist die Lizenzangabe NOASSERTION. Das bedeutet, dass die automatische Erkennung keine Standardlizenz identifizieren konnte. Vor einer kommerziellen Nutzung ist das zu klären, und zwar am Original-Repository, nicht anhand dieser Beschreibung. Eine rechtliche Einschätzung kann hier nicht gegeben werden.

Alternativen und der Unterschied im Ansatz

Der naheliegendste Vergleich ist llama.cpp mit seinen GGUF-Quantisierungen. Der Unterschied liegt weniger im Ergebnis als im Weg dorthin: llama.cpp ist ein Inferenzprojekt, das Quantisierung als Teil des Ausführungsformats behandelt. Wer dort quantisieren will, konvertiert ein Modell in das GGUF-Format und wählt eine der vorhandenen Quantisierungsstufen. AngelSlim geht den umgekehrten Weg. Es ist ein Kompressionswerkzeug, das Gewichte erzeugt, die anschließend in verschiedenen Runtimes laufen, und es bietet dafür Verfahren wie SmoothQuant, DAQ oder NVFP4, die in llama.cpp nicht als Auswahl stehen. Dass AngelSlim einen Kernel für 1,25-Bit-Modelle als Pull Request an llama.cpp beigesteuert hat (PR #22836), zeigt, dass die beiden Projekte eher aufeinander aufbauen als konkurrieren.

Ein zweiter Vergleichspunkt ist der Umgang mit spekulativer Dekodierung. AngelSlim trainiert eigene Drafter-Modelle und veröffentlicht deren Gewichte, etwa für Hy3-A21B. Wer nur eine Inferenzbibliothek mit vorgefertigter spekulativer Dekodierung sucht, findet dort fertige Integrationen, muss aber auf die vom Projekt trainierten Drafter verzichten. Die Wahl hängt davon ab, ob man Trainingsaufwand investieren kann oder nicht.

Pflegeaufwand, Versionen und was vor dem Einsatz zu prüfen ist

Die Versionshistorie ist unregelmäßig. Zwischen v0.2.0 (November 2025) und v0.3.0 (Januar 2026) liegen rund zwei Monate, zwischen v0.3.0 und v0.5.0 (Juni 2026) etwa fünf. Die Änderungsliste dagegen wird im Wochenrhythmus ergänzt, mit Einträgen fast jeden Monat. Das deutet darauf hin, dass neue Verfahren und Modellunterstützung häufiger außerhalb formeller Releases landen als innerhalb. Wer auf reproduzierbare Stände angewiesen ist, sollte deshalb auf Tags statt auf den Hauptzweig setzen und die Dokumentation passend zur Version lesen.

Ein weiterer Kostenfaktor ist die Dokumentationssprache. Die README verlinkt an mehreren Stellen auf chinesische Fassungen der Dokumentationsseiten, etwa unter angelslim.readthedocs.io/zh-cn/latest/features/sparse_attention/stem.html. Wer des Chinesischen nicht mächtig ist, muss prüfen, ob die englische Fassung denselben Stand hat. Für die Lizenz gilt: NOASSERTION ist keine Lizenz, sondern das Fehlen einer erkannten Lizenz. Die Bedingungen für Weitergabe und kommerzielle Nutzung sind aus dem vorliegenden Material nicht ableitbar und müssen vor jeder Veröffentlichung komprimierter Gewichte geklärt werden.

Redaktionelles Fazit

Wer Modelle der im Repository genannten Familien (Qwen3, DeepSeek-R1/V3, Hunyuan, GLM-4.6, Kimi-K2, FLUX, Seed-OSS) komprimieren will und bereit ist, sich durch mehrere Dokumentationsseiten und Skriptverzeichnisse zu arbeiten, findet hier fertige Konfigurationen und veröffentlichte Gewichte. Wer ein einziges, klar abgegrenztes Verfahren mit einer einzigen Anleitung sucht, ist hier falsch, weil das Repository Quantisierung, Distillation und spekulative Dekodierung parallel führt. Vor dem ersten produktiven Einsatz ist die Lizenzangabe NOASSERTION zu klären, und es ist zu prüfen, welcher der Zweige sherry, tequila oder main den benötigten Code enthält. Der nächste konkrete Schritt ist, die Modellliste in configs/ gegen die eigene Zielarchitektur abzugleichen, bevor Trainings- oder Kalibrierlaufzeiten eingeplant werden.

Offizielle Quellen

1. Issues
2. Project website
3. README
4. Releases
5. Tencent/AngelSlim on GitHub