APEX-Quantifizierung: Ob lokale KI auf einem Drittel des VRAM fast in original Qualität läuft?
In der Welt der On-Premises-KI ist ein Problem präsent: Je stärker eine Modelldatei komprimiert wird, desto schlechter wird die Qualität. Doch ein neuer Quantifizierungsansatz namens APEX ermöglicht eine starke Komprimierung ohne die üblichen Qualitätsverluste – und das nicht nur im Labor. Zumindest laut den Verantwortlichen.
Für KMUs, die aktuell noch bei Cloud-Anbietern zu Hause sind oder lokal nur mit großen Modellen arbeiten, ist dieser Ansatz eine Alternative um: Lokale KI auf der eigenen Hardware wird deutlich günstiger zu hosten.
Die Ausgangslage und warum das relevant is für KMU
Problem #1: Cloud-KI-Aufrufe kosten Geld – und jedes Mal wenn jemand im Unternehmen die KI nutzt, wandern Daten in externe Rechenzentren. Viele KMUs akzeptieren diese Kosten stillschweigend, weil eine lokale Alternative "zu aufwendig" erscheint.
Problem #2: Selbst mit eigenem GPU-Server bleibt die VRAM-Frage: Moderne leistungsfähige Modelle wie das Qwen3.6-35B-A3B benötigen weit mehr als 64 GB an VRAM um mit 16 Bit Quantifizierung betrieben zu werden. Das hebt die notwendigen Budgets für Hardware in schmerzhafte Regionen. Viele IT-Leiter zögern daher, lokal zu starten – auch wenn sie den Cloud-Ausstieg vielleicht sogar anstreben. Zum Vergleich: Eine RTX PRO 6000 Blackwell mit 96 GB VRAM liegt in der Preisklasse von ca. 11.000 € (Netto).
Kurz gesagt: Die Kosten und die Komplexität von lokaler KI halten viele KMUs zurück. Der Flaschenhals? VRAM-Knappheit bei der Modell-Bereitstellung – und die Annahme, dass Quantifizierung (also das Komprimieren) immer mit Qualitätseinbusen einhergeht.
APEX ist keine gewöhnliche Quantisierung – es ist eher eine intelligente Verteilung
Worum geht's? Herkömmliche Quantifizierung (z.B. Q8_0, Q4_K_M) reduziert die Bit-Tiefe *uniform* auf alle Gewichtungen des Modells. So sparen Sie Speicher und Rechenzeit – aber opfern oft Qualität in den Bereichen des Modells, die am empfindlichsten für menschliche Ausgaben sind.
**APEX ist hier etwas anderes**: Es klassifiziert jeden Tensor nach dessen Rolle (Expert-Layer vs. Shared-Layer vs. Attention) und wendet ein *layer-weises Präzisions-Gradient* an: Die sensibelsten Randlagen bekommen mehr Bits, redundantere mittlere Lagen werden stärker komprimiert. Im Prinzip passt APEX die Auflösung der Daten nicht willkürlich an den Gesamt-Budget-Topf, sondern an die Wichtigkeit jedes Bereichs für das Gesamtergebnis an.
Die Konsequenz (so die Entwickler):
- Perplexität auf dem Niveau von Q8_0 Modellen, aber Speicherbedarf auf ca. dem Drittel des Original-F16-Modelles.
- In manchen Benchmarks (insbesondere MoE-Architekturen) ist APEX sogar besser als F16, weil die dreistufige Präzisionsverteilung einen Regularisierungseffekt auslöst – ähnlich wie bei neuronaler Optimierung mit leichtem Rauschen.
Wie wird ein original Modell APEX-Quantifiziert und auf Ollama ausgerollt?
Als erstes benötigen wir das original Modell im GGUF-Format 16 Bit, die zentrale Anlaufstelle für alle möglichen Modelle, Dataset, usw. ist die Webseite Huggingface . Dort erhalten Sie die meisten freien KI-Modelle zum Download. Wir schauen uns heute konkret das derzeit beste lokale KI-Modell (Ornith-1.0-35B) für Konsumer-Hardware an. Für die APEX Quantifizierung laden wir uns die BF16 Version des Modells herunter. ACHTUNG: Die Größe des Downloads beträgt 69,4 GB!
HINWEIS: Ornith-1.0-35B basiert auf dem Qwen3.6-35B-A3B Modell.
Als erstes installieren wir llama.cpp auf unserem Rechner. Das benötigen wir für die APEX-Quantifizierung. Ich persönlich baue mir llama.cpp meist gern aus den Quellen. Hier mal am Beispiel von CUDA gezeigt.
git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDA=ON cmake --build build --config Release sudo cmake --install build
Als nächstes Clonen wir das GitHub-Repository von APEX-Quant:
git clone https://github.com/mudler/apex-quant.git cd apex-quant
Jetzt müssen wir noch unser GGUF-Modell, in unserem Fall die Datei "Ornith-1.0-35B-BF16.gguf" in das apex-quant Verzeichnis kopieren und die Quantifizierung mit folgenden Befehl starten:
./scripts/quantize.sh --profile quality Ornith-1.0-35B-BF16.gguf ornith-1.0-35b-apex-quality.gguf
Konsolen Ausgabe zur APEX-Quantifizierung
Wenn alles gut geht befindet sich nun das APEX Quantifizierte Modell "ornith-1.0-35b-apex-quality.gguf" im Verzeichnis und könnten es über llama-cli ausführen oder wie folgt für Ollama verfügbar machen:
mkdir ornith-1.0-35b-apex-quality cp ornith-1.0-35b-apex-quality.gguf ornith-1.0-35b-apex-quality cd ornith-1.0-35b-apex-quality nano Modelfile
Der Inhalt der Modelfile-Datei (analog wie orig. Ollama Ornith Modelfile) ist folgender:
FROM ./ornith-1.0-35b-apex-quality.gguf
TEMPLATE {{ .Prompt }}
SYSTEM You are Ornith, an open-source agentic coding assistant. Think step by step in a reasoning block, then act. Use the provided tools when they help. Be concise, correct, and direct: write working code and explain only what is non-obvious.
PARAMETER stop <|im_end|>
PARAMETER temperature 0.6
PARAMETER top_k 20
PARAMETER top_p 0.95
PARAMETER num_ctx 65536Anschließend speichern und nano verlassen. Jetzt können wir das Modell über Ollama bereitstellen und ausführen:
ollama create ornith-1.0-35b-apex-quality -f Modelfile ollama run ornith-1.0-35b-apex-quality:latest --verbose
Auf meinem System mit 2 RTX 5060 TI (2x 16GB VRAM) erreiche ich ca. 100-104 Token/s.
total duration: 42.298628217s load duration: 253.491814ms prompt eval count: 472 token(s) prompt eval duration: 555.863ms prompt eval rate: 849.13 tokens/s eval count: 4301 token(s) eval duration: 41.288291s eval rate: 104.17 tokens/s
Praxis: Was sagt der Benchmark?
Das LocalAI-Team veröffentlichte Benchmarks gegen Unsloth Dynamic 2.0 (UD): [APEX übertrifft UD-Quantisierungen bei Perplexität, HellaSwag und Inferenzgeschwindigkeit –und ist dabei ca. 3x kleiner als F16 Modelle. In der Praxis heißt das:
| Modell-Archipetkture | Vergleichswert APEX vs. Q8_0 (laut Entwickler Paper) |
| **Perplexität (PPL)** | APEX erreicht annäherndes Level, teilweise übertrifft es sogar, bei deutlich weniger Speicherbedarf |
| **HellaSwag** | APEX übertrifft Unsloth UD und andere Quantisierungen, dadurch besser Performance in der Praxis |
| **Inferenz-Geschwindigkeit** | APEX ist durch intelligentes Verteilen Quantifizierung sogar schneller bei den antwortzeiten |
Aber Achtung: Wie immer bei Versprechungen wie "keinerlei Qualitätsverlust" müssen wir differenzieren. APEX komprimiert die Mittel-Layer im Modell ohne die kritische Randqualität zu reduzieren – das Gesamtresultat ist daher besser, weil die kritischen Ebenen ihre volle Auflösung behalten und redundante Anteile nur minimal beeinträchtigt werden.
Vergleichs Benchmarks von Ornith-1.0-35B und Qwen3.5-35B-A3B analog LokalAI-Team (ermittelt durch eigene Tests | 2x RTX 5060 Ti 16 GB)
| Model-Name | PPL | Benchmark | Model-Size |
| ornith-1.0-35b-apex-quality | 6,8573 | pp512_ts: 2076,48 | tg128_ts: 117,88 | 21,3 GB |
| ornith-1.0-35b-apex-i-quality | 6.8573 | pp512_ts: 2069.51 | tg128_ts: 118.40 | 21.3 GB |
| ornith-1.0-35b-apex-balanced | 6.8437 | pp512_ts: 2002.68 | tg128_ts: 118.62 | 23.6 GB |
| ornith-1.0-35b-apex-i-balanced | 6.8437 | pp512_ts: 2015.67 | tg128_ts: 118.52 | 23.6 GB |
| ornith-1.0-35b-Q4_K_M | 6,9385 | pp512_ts: 2225,43 | tg128_ts: 135,84 | 19,7 GB |
| ornith-1.0-35b-Q5_K_M | 6.8728 | pp512_ts: 2121,39 | tg128_ts: 126,59 | 23,0 GB |
| ornith-1.0-35b-Q6_K | 6,8381 | pp512_ts: 1869,04 | tg128_ts: 115,39 | 26,6 GB |
| ornith-1.0-35b-Q8_0 | 6,8363 | - | 34.4 GB |
| qwen3.6-35B-A3B-apex-quality | 6,7540 | pp512_ts: 2050,22 | tg128_ts: 118,03 | 21,9 GB |
| qwen3.6-35B-A3B-apex-i-quality | 6.7540 | pp512_ts: 2060,24 | tg128_ts: 118,67 | 21,9 GB |
| qwen3.6-35B-A3B-apex-balanced | 6.7310 | pp512_ts: 2018.81 | tg128_ts: 118.29 | 24.2 GB |
| qwen3.6-35B-A3B-apex-i-balanced | 6.7310 | pp512_ts: 2027.60 | tg128_ts: 118.96 | 24.2 GB |
| qwen3.6-35B-A3B-Q4_K_M | 6,8139 | pp512_ts: 2236,77 | tg128_ts: 135,09 | 20,2 GB |
| qwen3.6-35B-A3B-Q5_K_M | 6.8233 | pp512_ts: 2130.82 | tg128_ts: 126.02 | 23.6 GB |
| qwen3.6-35B-A3B-Q6_K | 6.7268 | pp512_ts: 1871.55 | tg128_ts: 116.03 | 27,2 GB |
| qwen3.6-35B-A3B-Q8_0 | 6.7198 | - | 35.2 GB |
Die auf https://github.com/localai-org/apex-quant beschriebene Perplexity auf Q8-Niveau konnten wir auf unserer Hardware bei APEX-Quality Quantifizierung nicht feststellen. Sie bewegt sich auf dem Niveau von Q6_K Modellen. Was grundsätzlich in Ordnung ist, da der VRAM-Bedarf im Vergleich dazu ca. 20 % geringer ist.
Was bedeutet das konkret für den praktischen Einsatz?
- Günstigere Hardware: Weniger VRAM pro Modell = niedrigere CAPEX beim Kauf eines GPU-Servers oder sogar der Wechsel auf günstigere Grafikkarten-Reihen.
- Schnittstelle Cloud-zu-On-Prem: Die Technologie macht lokale Modelle attraktiver, so dass Cloud-Vergleiche plötzlich weniger überzeugen – bei gleichen Resultaten aber deutlich besserer Kontrolle über Ihre Daten ermöglichen.
- Praktischer Einstiegspunkt: Wenn APEX-basierte Modelle für Ihren Anwendungsfall funktionieren (z.B. lokaler Chatbot für Mitarbeiterfragen oder bei KI-Agenten), können Sie ohne riesige IT-Budgets einen On-Premises KI-Proof-of-Concept starten.
Der "Eierlegende Wollmilchsau"-Effekt? Weniger Speicherkosten + schnellere Reaktionszeiten bei ähnlicher Qualität – und das alles auf Ihrer eigenen Hardware, mit vollem Schutz vor Datenabgabe an externe Dienstleister. Perfekt für KMU, die sich vom Cloud-Lock-in lösen wollen.
Fazit
APEX ist kein Hype – er zeigt konkret: Lokale KI wird durch intelligente adaptive Kompression immer realistischer und günstiger für professionelle Use-Cases. Wer jetzt schon auf lokaler Hardware experimentiert, hat einen klaren Vorteil. Und wer aktuell Cloud-KI nutzt, aber Bedenken bei Datenabflüsse oder API-Kosten hat: Die Technologie rund um das Thema Modell-Komprimierung entwichelt sich sehr schnell.
Was heißt das konkret für Sie? Wir helfen Ihnen gern herauszufinden, ob APEX auch für Ihren spezifischen Anwendungsfall die richtige Lösung ist. 👉 Oder nutzen Sie unseren kostenlosen Experten-Check als ersten Schritt.
FAQ: Häufige Fragen zu APEX-Quantifizierung
Kann ich APEX-basierte Modelle auch auf günstigerer Hardware betreiben oder brauche ich eine teure Datacenter-GPU?
APEX-Modelle sind komprimierte Modelle und kommen bei sehr hoher Qualität mit ca. 3x weniger VRAM aus. Daher kann ein APEX-Modell auf günstigerer Hardware betrieben werden als die unkomprimierte Modell-Version. Zum Beispiel Qwen3.6-35B-A3B-BF16 (RTX PRO 5000 Blackwell 72 GB VRAM - ca. 9k €) und Qwen3.6-35B-A3B-apex-quality (Radeon AI PRO R9700 32 VRAM - ca. 1,3k €).
Ist das Ergebnis auch qualitativ besser als ein Komprimieren auf Q6/Q5/Q4?
Ja, APEX reduziert in unwichtigeren Bereichen mehr und erhält die sensitiveren Schichten fast vollständig – im Gegensatz zur uniformen Quantifizierung, wo alles gleichmäßig komprimiert wird. Die eigenen Praxis-Benchmarks zeigen in Punkto Perplexität, dass sich APEX-Quantifizierung zwischen Q5 - Q6 und in Punkto VRAM-Bedarf zwischen Q4 - Q5 einordnet. Man bekommt quasi "Q5,5" Qualität zu "Q4,5" VRAM-Bedarf.
Kann ich das auch für mein bestehendes Modell umsetzen?
Auch wenn es aktuell vor allem für MoE-Modelle optimiert ist: Grundsätzlich werden die APEX-Methoden sukzessive auf weitere Architekturen erweitert. Kontaktieren Sie uns gerne – wir prüfen konkret Ihren Anwendungsfall und zeigen Ihnen eine passende Lösung inkl. On-Premises-Einrichtung oder Hybrid-Varianten zum bestehenden Cloud-Betrieb.
Go Back