--- title: "Verlustfreie LLM-Kompression vs. Q8 GGUF" canonical: https://wavect.io/de/blog/lossless-llm-weight-compression-production/ language: de description: "Ist verlustfreie LLM-Gewichtskompression produktionsreif? GLM-5.2-Evidenz, Q8 GGUF, BF16, Kosten, Runtime-Risiken und 14-Tage-Pilot." image: "https://wavect.io/img/general/bak/open_graph_preview.jpg" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 min Lesezeit · 22. Juli 2026 [**Weiter**](/de/blog/paid-pilot-vs-poc-vs-design-partner/) # Verlustfreie LLM-Gewichtskompression vs. 8-bit GGUF: Was ist produktionsreif? TL;DR Verlustfreie BF16-Gewichtskompression ist reversibel: Jedes Quellgewicht lässt sich Bit für Bit rekonstruieren, auch wenn die codierten Gewichte im VRAM liegen und erst im GPU-Kernel decodiert werden. Beim GLM-5.2-Experiment wurde eine Byte-Split-Repräsentation für alle 59.509 BF16-Tensoren mit 24,967 % Reduktion verifiziert. Die größere K15-Zahl von 30,168 % ist eine vollständige Größenrechnung, aber kein unabhängig serialisierter und decodierter GLM-Container; der A40-Speed stammt aus einem separaten Dense-Microbenchmark. Q8_0-GGUF ist quantisiert, nicht verlustfrei gegenüber BF16, bietet aber mehr Einsparung und reifere lokale Runtimes. Entscheide mit einem Drei-Lane-Pilot zu Exaktheit, Task-Qualität, Kapazität, Latenz, Durchsatz, Betrieb und Kosten pro erfolgreichem Task. Faktenstand 22. Juli 2026. **Die kurze Antwort:** Verlustfreie BF16-Gewichtskompression funktioniert, doch das neue GLM-5.2-Ergebnis ist kein produktionsreifes Serving-Release. Die stärkste Evidenz ist eine Byte-Split-Repräsentation, die alle 59.509 BF16-Tensoren Bit für Bit rekonstruierte und den Weight-Payload um 24,967 % reduzierte. Die größere K15-Reduktion von 30,168 % ist eine vollständig belastete Größenrechnung, kein serialisierter und auf GLM-Skala decodierter Container. Ein separater A40-Test maß einen dichten 12-bit-Pfad, nicht exaktes End-to-End-Serving von GLM-5.2. Ein Q8_0-GGUF ist ein anderer Trade-off. Es braucht meist weniger Speicher und profitiert vom reifen llama.cpp-Ökosystem, ist aber quantisiert. Die ursprünglichen BF16-Gewichte lassen sich daraus nicht Bit für Bit wiederherstellen. Wähle Q8, wenn gemessene Qualität genügt und Deployment-Effizienz gewinnt. Wähle verlustfreie Kompression, wenn exakte Gewichte eine harte Anforderung sind. Verlange dann eine unterstützte Runtime und Production-Evidenz, bevor du mit niedrigeren Serving-Kosten rechnest. ## Was bedeutet „verlustfrei“ bei LLM-Gewichten? **Verlustfreie LLM-Gewichtskompression bedeutet, dass die codierte Repräsentation jedes Quellgewicht exakt inklusive aller Bits des ursprünglichen BF16-Tensors wiederherstellen kann.** Es geht um reversible Codierung. Gewichte werden weder gerundet noch entfernt oder durch nahe Integer-Werte ersetzt. Das gilt auch im VRAM. Eine GPU kann codierte Gewichte speichern, die exakten BF16-Werte in Registern oder Shared Memory rekonstruieren und sofort für die Matrixmultiplikation nutzen. Der Speicherort entscheidet nicht über Verlustfreiheit. Entscheidend ist der Round-trip. 1. **Exakte Gewichte:** Die komprimierten Bytes rekonstruieren den Tensor Bit für Bit. 2. **Exaktes Modellverhalten:** Die komplette Runtime reproduziert Baseline-Outputs unter definierten deterministischen Bedingungen. Exakte Gewichte allein reichen nicht, wenn Kernel, Akkumulationsreihenfolge oder Sampling abweichen. 3. **Besseres Production-Serving:** Das integrierte System verbessert Kapazität, Latenz, Durchsatz oder Kosten im echten Traffic ohne untragbares Betriebsrisiko. ## Was beweist das GLM-5.2-Experiment wirklich? Brian Bells [Experiment zur verlustfreien BF16-Kompression](https://brianbell-x.github.io/weight-compression/) scannte alle 282 Shards des GLM-5.2-Checkpoints mit ungefähr 1,4 TiB Quelldaten. BF16 besteht aus einem Vorzeichenbit, acht Exponentenbits und sieben Mantissenbits. Trainierte Gewichte verwenden nur wenige Exponentenmuster sehr häufig. Das Experiment codiert häufige Vorzeichen-Exponenten-Symbole kurz und schreibt seltene Symbole in einen exakten Escape-Stream. | Claim | Ergebnis | Belegt | Offen | | --- | --- | --- | --- | | Exakte Byte-Split-Repräsentation | 12,005 bit pro BF16-Gewicht, 24,967 % Reduktion | Alle 59.509 BF16-Tensoren wurden aus Codebook, Indizes, Escapes und unverändertem Low Byte Bit für Bit rekonstruiert. | Kein integriertes Production-Serving. | | K15 Charged-Format Accounting | 11,173 bit pro Gewicht, 1.403,19 auf 979,87 GiB, 30,168 % Reduktion | Codebooks, Indizes, Escapes und Side Costs sind modellweit eingerechnet. | Kein physischer GLM-K15-Container wurde unabhängig serialisiert und decodiert. | | Dense A40 Prototype | 0,733-fache BF16-GEMV-Zeit | Ein dichter codierter Pfad kann in Registern rekonstruieren und einen speichergebundenen BF16-Microbenchmark schlagen. | Sparse Escape Correction war separat und nicht im Timing; kein End-to-End-GLM-Serving. | Das öffentliche [Reproduktionsprotokoll](https://github.com/brianbell-x/weight-compression/blob/main/src/REPRODUCE.md) trennt diese Evidenzklassen sauber. Es streamt Shards, löscht sie nach der Validierung und braucht für den Exaktheitstest keine GPU. Das ist wertvolle Research-Evidenz, aber kein Plug-and-play-Backend für vLLM, SGLang oder llama.cpp. ## Ist 8-bit GGUF verlustfrei? **Nein, Q8_0-GGUF ist gegenüber den BF16-Quellgewichten nicht verlustfrei.** GGUF ist ein Container und kann BF16, F16 sowie quantisierte Tensor-Typen enthalten. Das Format selbst ist nicht automatisch verlustbehaftet. Q8_0 ist es. Der [Quantisierungs-Workflow von llama.cpp](https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md) erzeugt Q-Varianten aus höherer Präzision und warnt vor zusätzlichem Qualitätsverlust durch Requantisierung. Q8_0 repräsentiert Blöcke mit int8-Werten plus Scale. Dequantisierung erzeugt brauchbare Näherungen, nicht die ursprünglichen BF16-Bitmuster. Auch die [GGUF-Dokumentation von Hugging Face](https://huggingface.co/docs/transformers/gguf) führt Q8_0 als quantisierten Typ und dequantisiert solche Checkpoints beim Laden in Transformers. Q8 kann trotzdem die richtige Production-Wahl sein. „In unserem Eval kein materieller Qualitätsverlust“ ist eine belastbare Aussage. „Bit-exakt verlustfrei“ ist eine andere Aussage und braucht einen reversiblen Nachweis. ## Wie ordnet sich das in bestehende Forschung ein? - [**ZipNN**](https://arxiv.org/abs/2411.05239) trennte komprimierbare Exponenten von kaum komprimierbaren Bits und meldete bei regulären BF16-Modellen ungefähr 33 % Speicherersparnis. Der stärkste Fit liegt bei Storage, Distribution und Checkpoint-Traffic. - [**DFloat11**](https://arxiv.org/abs/2504.11651) kombinierte variable Codes mit GPU-Decodierung und meldete rund 30 % kleinere BF16-Modelle mit exakt rekonstruierten Gewichten. - [**ZipServ**](https://arxiv.org/abs/2603.17435) verband ein Fixed-length-Format mit Fused Decompression-GEMM. Das Paper meldet bis zu 30 % kleinere Modelle, bis zu 2,21-fachen Kernel-Speed und durchschnittlich 1,22-fachen End-to-End-Speed gegenüber vLLM in den getesteten Systemen. - Ein [**ANS-System mit tiled On-the-fly-Decoding**](https://arxiv.org/abs/2606.15789) integrierte verlustfreie Kompression in SGLang und Multi-GPU-Serving. Das Preprint meldet größere mögliche Batches und bis zu 1,6-fachen Throughput in ausgewählten Workloads. - [**Cloudflare Unweight**](https://research.cloudflare.com/papers/unweight-2026.pdf) untersucht reconstructive Matmul auf Hopper-GPUs. Der Report bezeichnet die Ergebnisse als Zwischenstand und komprimiert ausgewählte MLP-Gewichte. Die relevante Frage lautet nicht mehr, ob BF16-Exponenten komprimierbar sind. Das ist belegt. Entscheidend ist, welcher Codec mit welchem Kernel und welcher Serving Engine deinen Workload auf unterstützter Hardware verbessert. ## Lossless oder Q8 GGUF: Was solltest du deployen? | Faktor | Raw BF16 | Lossless BF16 Codec | Q8 GGUF | | --- | --- | --- | --- | | Gewichtstreue | Referenz | Bit-exakt nach verifiziertem Decode | Quantisierte Näherung | | Größe | Am größten | Je nach Scope oft rund 20 % bis 33 % Reduktion in der Forschung | Ungefähr halber roher 16-bit-Weight-Payload vor Metadaten und Mixed Tensors, modellabhängig | | Runtime-Reife | Breite Unterstützung | Stark abhängig von Codec, GPU und Engine-Integration | Reifes lokales Ökosystem mit llama.cpp | | Bester aktueller Fit | Baseline, Training, qualitätssensitives Serving | Storage, Distribution, kapazitätsbegrenzte exakte Inference, kontrollierte Piloten | Consumer-Hardware und kostensensitive Inference nach Task-Eval | **Starte mit Q8**, wenn du ein praktisches lokales Deployment brauchst, llama.cpp das Modell unterstützt und ein repräsentatives Eval keine materielle Business-Einbuße zeigt. **Pilotiere verlustfreie Kompression**, wenn BF16 die freigegebene Referenz ist, Qualitätsregression teuer wäre und 20 % bis 30 % mehr effektive Accelerator-Kapazität den Hardwareplan verändert. Besonders interessant ist sie für Golden Baselines, sensible Reasoning-Workloads, Checkpoint-Distribution und gemessene Weight-Bandwidth-Bottlenecks. **Bleib bei raw BF16**, wenn Integrationsrisiko mehr kostet als der gesparte Speicher oder der gewählte Pfad Architektur, GPU-Generation, Batching, Tensor Parallelism oder Failure Tooling nicht unterstützt. ## Ist der GLM-5.2-Ansatz produktionsreif? **Nein.** Es ist ein glaubwürdiges und reproduzierbares Kompressionsergebnis mit separatem Kernel-Microbenchmark. Es ist keine GLM-5.2-Serving-Engine, kein physisches K15-Modellrelease und kein End-to-End-Production-Benchmark. 1. **Artefakt:** Serialisiere das echte Modell, validiere Hashes und decode jeden Tensor aus dem ausgelieferten Container. 2. **Runtime:** Integriere den exakten Decode in Serving Engine, Kernel, Tensor Parallelism, Batching und Modellarchitektur. 3. **Verhalten:** Vergleiche deterministische Outputs, wo möglich, und führe Task-Evals gegen raw BF16 aus. 4. **Performance:** Miss Time to First Token, Inter-token Latency, Throughput, Concurrency, Startup, Peak Memory und Energie für mehrere Context- und Batch-Größen. 5. **Betrieb:** Teste Crash Recovery, Korruptionserkennung, Rollback, Observability, Upgrades und Fallback zum unkomprimierten Artefakt. ## Wie rechnest du den kommerziellen Case? `monatlicher Nutzen = vermiedene Accelerator-Kosten + vermiedene Storage- und Transferkosten - zusätzlicher Compute - Engineering- und Betriebskosten` Eine Speicherreduktion schafft nur dann Wert, wenn sie eine GPU entfernt, ein sonst zu großes Modell ermöglicht, sichere Batch-Kapazität erhöht, Weight-Traffic genug senkt oder Distribution billiger macht. Ein 30 % kleineres Format mit Custom Kernels und mehr Latenz kann schlechter sein als ein reifes Q8-Deployment. Eine Reduktion um 20 %, die pro Replica einen Accelerator spart, kann hervorragend sein. Für API versus eigene Infrastruktur nutze unseren [Break-even-Rechner für lokale LLMs und APIs](/de/blog/local-models-vs-apis-break-even-eu-2026/). Für GLM-5.2-Streaming von NVMe auf kleiner Hardware lies unsere [Colibri-Analyse](/de/blog/colibri-glm-5-2-consumer-hardware/). Dieser Artikel bleibt bei Precision-Format und Production-Codec. ## Ein 14-Tage-Pilot für Production Readiness 1. **Entscheidung einfrieren:** Modellrevision, Tensor-Hashes, Codec-Commit, Engine-Build, Treiber, GPU, Prompts und Gates dokumentieren. 2. **Reversibilität beweisen:** Das ausgelieferte Artefakt decodieren, alle Tensoren Byte für Byte vergleichen und Korruption injizieren. 3. **Drei Lanes bauen:** Raw BF16, Lossless-Kandidat und glaubwürdigste quantisierte Alternative möglichst auf identischer Hardware testen. 4. **Reale Evals ausführen:** Echte Task-Verteilungen, lange Kontexte, Tools und Failure Cases nutzen. 5. **Serving-Shape testen:** Batch 1 und Ziel-Concurrency, warm und kalt, p50/p95, Tokens pro Sekunde, Peak Memory und Energie pro erfolgreichem Task messen. 6. **Betrieb üben:** Worker neu starten, Versionen rollen, Shard beschädigen, Node entfernen und Fallback oder Rollback beweisen. 7. **Economics entscheiden:** Gemessene Kapazität in Fleet-Größe und Monatskosten übersetzen, inklusive Ownership einer nicht standardisierten Runtime. ## Fragen an Vendor oder Research-Team - Welche Tensor-Dtypes und Modellarchitekturen werden exakt unterstützt? - Kommt die Prozentzahl aus einem serialisierten Artefakt inklusive Metadaten und Escapes? - Wurde jeder Tensor aus diesem Artefakt decodiert und mit den Quellbytes verglichen? - Enthält der Benchmark komplettes Modell, Escape-Pfad, Attention, KV Cache, Batching und Serving Engine? - Welche GPUs, Treiber, Batch-Größen und Context-Längen wurden getestet? - Was passiert bei Tensor-Korruption oder Decoder-Upgrade? - Ist ein Fallback auf Standard-BF16 ohne Service-Rebuild möglich? - Welches Production-System nutzt den Pfad bereits, bei welchem Traffic und welchen SLOs? ## Quellen und Claim-Grenzen GLM-5.2-Größen, Tensorzahl, Reduktionen und Reproduktionsgrenzen stammen aus dem [Projektbulletin](https://brianbell-x.github.io/weight-compression/) und den [Reproduktionsnotizen](https://github.com/brianbell-x/weight-compression/blob/main/src/REPRODUCE.md). Die Vergleiche verwenden die verlinkten Papers. GGUF-Aussagen basieren auf aktueller Hugging-Face- und llama.cpp-Dokumentation. Performance-Zahlen gehören zu den jeweiligen Autoren und Testsystemen. Wavect hat den 1,4-TiB-Scan oder die GPU-Benchmarks nicht reproduziert. Faktenstand 22. Juli 2026. ## Häufige Fragen ### Können Gewichte im VRAM verlustfrei komprimiert sein? Ja. Eine Runtime kann eine reversible codierte Repräsentation im VRAM halten, exakte BF16-Werte in Registern oder Shared Memory rekonstruieren und sofort verwenden. Der Nachweis ist ein Bit-exakter Round-trip. ### Ist Q8_0-GGUF verlustfrei? Nein. Q8_0 repräsentiert Blöcke mit 8-bit-Quantwerten und Scale. Die dequantisierten Werte nähern die Quelle an. GGUF kann auch BF16 oder F16 enthalten, aber ein Q8_0-Artefakt ist quantisiert. ### Garantiert verlustfreie Gewichtskompression identische Outputs? Nicht allein. Sie garantiert exakt rekonstruierte Gewichte. Andere Kernel, Akkumulationsreihenfolgen, Libraries oder Sampling können Outputs verändern. Prüfe Weight Parity und Runtime-Verhalten separat. ### Wie stark lässt sich ein BF16-LLM ohne geänderte Gewichte verkleinern? Aktuelle Systeme melden für ihren jeweiligen Scope oft ungefähr 20 % bis 33 %. Das GLM-5.2-Experiment decodierte eine modellweite Repräsentation mit 24,967 % Reduktion und berechnete separat K15 mit 30,168 %. ### Ist der GLM-5.2-K15-Codec produktionsreif? Nein. Die 30,168 % sind vollständiges modellweites Accounting, aber kein physischer GLM-K15-Container wurde unabhängig serialisiert und decodiert. Der A40-Wert ist ein separater Dense-Microbenchmark. ### Wann ist Lossless besser als Quantisierung? Wenn exakte BF16-Gewichte Pflicht sind und gemessene Speicher- oder Bandbreitenersparnis die Fleet Economics verändert. Quantisierung gewinnt, wenn Task-Evals ausreichende Qualität und die reifere Runtime bessere Kosten pro erfolgreichem Task zeigen. ## Fazit Verlustfreie BF16-Kompression ist kein Widerspruch und nicht dasselbe wie Q8-Quantisierung. Beim GLM-5.2-Scan müssen drei Ergebnisse getrennt bleiben: 24,967 % verifizierte Reduktion, 30,168 % K15-Größenrechnung und ein Dense-A40-Microbenchmark. Starte in Production mit der Anforderung. Wenn exakte BF16-Gewichte Pflicht sind, evaluiere eine integrierte Lossless-Runtime gegen raw BF16. Wenn Task-Qualität zählt, nimm Q8, FP8 und andere unterstützte Formate in denselben Pilot. Kaufe bessere Kosten pro erfolgreichem Task, nicht die dramatischste Headline. ## Das könnte dich auch interessieren.. [**Lokale LLMs vs. APIs: Break-even berechnen** Vergleiche Accelerator-Auslastung, API-Ausgaben, Engineering, Datenschutz und erfolgreiche Tasks vor dem Hardwarekauf.](/de/blog/local-models-vs-apis-break-even-eu-2026/) [**AI Enablement oder In-house AI Hire?** Vergleiche spezialisierte Delivery mit Fixkosten, Ownership und langfristiger interner AI-Kompetenz.](/de/compare/ai-enablement-vs-in-house-ai-hire/) Modelle und Infrastruktur ## In diesem Cluster weiterlesen [Mit dem Grundlagenartikel starten**LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen**](/de/blog/self-hosting-llms-eu-cost/) - [Versieht Claude Texte mit Wasserzeichen? API-Antwort 2026](/de/blog/claude-text-watermark-api-2026/) - [OpenKB Review: Knowledge Compiler vs. RAG](/de/blog/openkb-review-vs-rag/) - [Unsloth Desktop im Test: Private lokale KI-Workstation?](/de/blog/unsloth-desktop-local-ai-workstation-review/) - [NeMo Switchyard 0.2: Agenten-Routing ohne Training?](/de/blog/nemo-switchyard-model-router/) - [Firecrawl AnyDoc im Test: 14 Formate zu Markdown](/de/blog/firecrawl-anydoc-review/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 min Lesezeit · 22. Juli 2026 [**Weiter**](/de/blog/paid-pilot-vs-poc-vs-design-partner/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/lossless-llm-weight-compression-production/#webpage", "@type": "WebPage", "dateModified": "2026-07-22", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-22", "url": "https://wavect.io/de/blog/lossless-llm-weight-compression-production/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Verlustfreie BF16-Gewichtskompression ist reversibel: Jedes Quellgewicht lässt sich Bit für Bit rekonstruieren, auch wenn die codierten Gewichte im VRAM liegen und erst im GPU-Kernel decodiert werden. Beim GLM-5.2-Experiment wurde eine Byte-Split-Repräsentation für alle 59.509 BF16-Tensoren mit 24,967 % Reduktion verifiziert. Die größere K15-Zahl von 30,168 % ist eine vollständige Größenrechnung, aber kein unabhängig serialisierter und decodierter GLM-Container; der A40-Speed stammt aus einem separaten Dense-Microbenchmark. Q8_0-GGUF ist quantisiert, nicht verlustfrei gegenüber BF16, bietet aber mehr Einsparung und reifere lokale Runtimes. Entscheide mit einem Drei-Lane-Pilot zu Exaktheit, Task-Qualität, Kapazität, Latenz, Durchsatz, Betrieb und Kosten pro erfolgreichem Task. Faktenstand 22. Juli 2026.", "articleBody": " Blog-Übersicht/AI und Agents/Modelle und Infrastruktur Verlustfreie LLM-Gewichtskompression vs. 8-bit GGUF: Was ist produktionsreif? TL;DR Verlustfreie BF16-Gewichtskompression ist reversibel: Jedes Quellgewicht lässt sich Bit für Bit rekonstruieren, auch wenn die codierten Gewichte im VRAM liegen und erst im GPU-Kernel decodiert werden. Beim GLM-5.2-Experiment wurde eine Byte-Split-Repräsentation für alle 59.509 BF16-Tensoren mit 24,967 % Reduktion verifiziert. Die größere K15-Zahl von 30,168 % ist eine vollständige Größenrechnung, aber kein unabhängig serialisierter und decodierter GLM-Container; der A40-Speed stammt aus einem separaten Dense-Microbenchmark. Q8_0-GGUF ist quantisiert, nicht verlustfrei gegenüber BF16, bietet aber mehr Einsparung und reifere lokale Runtimes. Entscheide mit einem Drei-Lane-Pilot zu Exaktheit, Task-Qualität, Kapazität, Latenz, Durchsatz, Betrieb und Kosten pro erfolgreichem Task. Faktenstand 22. Juli 2026. Die kurze Antwort: Verlustfreie BF16-Gewichtskompression funktioniert, doch das neue GLM-5.2-Ergebnis ist kein produktionsreifes Serving-Release. Die stärkste Evidenz ist eine Byte-Split-Repräsentation, die alle 59.509 BF16-Tensoren Bit für Bit rekonstruierte und den Weight-Payload um 24,967 % reduzierte. Die größere K15-Reduktion von 30,168 % ist eine vollständig belastete Größenrechnung, kein serialisierter und auf GLM-Skala decodierter Container. Ein separater A40-Test maß einen dichten 12-bit-Pfad, nicht exaktes End-to-End-Serving von GLM-5.2. Ein Q8_0-GGUF ist ein anderer Trade-off. Es braucht meist weniger Speicher und profitiert vom reifen llama.cpp-Ökosystem, ist aber quantisiert. Die ursprünglichen BF16-Gewichte lassen sich daraus nicht Bit für Bit wiederherstellen. Wähle Q8, wenn gemessene Qualität genügt und Deployment-Effizienz gewinnt. Wähle verlustfreie Kompression, wenn exakte Gewichte eine harte Anforderung sind. Verlange dann eine unterstützte Runtime und Production-Evidenz, bevor du mit niedrigeren Serving-Kosten rechnest. Was bedeutet „verlustfrei“ bei LLM-Gewichten? Verlustfreie LLM-Gewichtskompression bedeutet, dass die codierte Repräsentation jedes Quellgewicht exakt inklusive aller Bits des ursprünglichen BF16-Tensors wiederherstellen kann. Es geht um reversible Codierung. Gewichte werden weder gerundet noch entfernt oder durch nahe Integer-Werte ersetzt. Das gilt auch im VRAM. Eine GPU kann codierte Gewichte speichern, die exakten BF16-Werte in Registern oder Shared Memory rekonstruieren und sofort für die Matrixmultiplikation nutzen. Der Speicherort entscheidet nicht über Verlustfreiheit. Entscheidend ist der Round-trip. Exakte Gewichte: Die komprimierten Bytes rekonstruieren den Tensor Bit für Bit. Exaktes Modellverhalten: Die komplette Runtime reproduziert Baseline-Outputs unter definierten deterministischen Bedingungen. Exakte Gewichte allein reichen nicht, wenn Kernel, Akkumulationsreihenfolge oder Sampling abweichen. Besseres Production-Serving: Das integrierte System verbessert Kapazität, Latenz, Durchsatz oder Kosten im echten Traffic ohne untragbares Betriebsrisiko. Was beweist das GLM-5.2-Experiment wirklich? Brian Bells Experiment zur verlustfreien BF16-Kompression scannte alle 282 Shards des GLM-5.2-Checkpoints mit ungefähr 1,4 TiB Quelldaten. BF16 besteht aus einem Vorzeichenbit, acht Exponentenbits und sieben Mantissenbits. Trainierte Gewichte verwenden nur wenige Exponentenmuster sehr häufig. Das Experiment codiert häufige Vorzeichen-Exponenten-Symbole kurz und schreibt seltene Symbole in einen exakten Escape-Stream. Evidenz zur GLM-5.2-Kompression, geprüft am 22. Juli 2026 ClaimErgebnisBelegtOffen Exakte Byte-Split-Repräsentation12,005 bit pro BF16-Gewicht, 24,967 % ReduktionAlle 59.509 BF16-Tensoren wurden aus Codebook, Indizes, Escapes und unverändertem Low Byte Bit für Bit rekonstruiert.Kein integriertes Production-Serving. K15 Charged-Format Accounting11,173 bit pro Gewicht, 1.403,19 auf 979,87 GiB, 30,168 % ReduktionCodebooks, Indizes, Escapes und Side Costs sind modellweit eingerechnet.Kein physischer GLM-K15-Container wurde unabhängig serialisiert und decodiert. Dense A40 Prototype0,733-fache BF16-GEMV-ZeitEin dichter codierter Pfad kann in Registern rekonstruieren und einen speichergebundenen BF16-Microbenchmark schlagen.Sparse Escape Correction war separat und nicht im Timing; kein End-to-End-GLM-Serving. Das öffentliche Reproduktionsprotokoll trennt diese Evidenzklassen sauber. Es streamt Shards, löscht sie nach der Validierung und braucht für den Exaktheitstest keine GPU. Das ist wertvolle Research-Evidenz, aber kein Plug-and-play-Backend für vLLM, SGLang oder llama.cpp. Ist 8-bit GGUF verlustfrei? Nein, Q8_0-GGUF ist gegenüber den BF16-Quellgewichten nicht verlustfrei. GGUF ist ein Container und kann BF16, F16 sowie quantisierte Tensor-Typen enthalten. Das Format selbst ist nicht automatisch verlustbehaftet. Q8_0 ist es. Der Quantisierungs-Workflow von llama.cpp erzeugt Q-Varianten aus höherer Präzision und warnt vor", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-22", "datePublished": "2026-07-22", "description": "Verlustfreie BF16-Gewichtskompression ist reversibel: Jedes Quellgewicht lässt sich Bit für Bit rekonstruieren, auch wenn die codierten Gewichte im VRAM liegen und erst im GPU-Kernel decodiert werden. Beim GLM-5.2-Experiment wurde eine Byte-Split-Repräsentation für alle 59.509 BF16-Tensoren mit 24,967 % Reduktion verifiziert. Die größere K15-Zahl von 30,168 % ist eine vollständige Größenrechnung, aber kein unabhängig serialisierter und decodierter GLM-Container; der A40-Speed stammt aus einem separaten Dense-Microbenchmark. Q8_0-GGUF ist quantisiert, nicht verlustfrei gegenüber BF16, bietet aber mehr Einsparung und reifere lokale Runtimes. Entscheide mit einem Drei-Lane-Pilot zu Exaktheit, Task-Qualität, Kapazität, Latenz, Durchsatz, Betrieb und Kosten pro erfolgreichem Task. Faktenstand 22. Juli 2026.", "headline": "Verlustfreie LLM-Kompression vs. 8-bit GGUF: Was ist produktionsreif?", "image": "https://wavect.io/img/blog/headers/header_lossless-llm-weight-compression-production.svg", "inLanguage": "de", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/lossless-llm-weight-compression-production/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/lossless-llm-weight-compression-production/", "wordCount": 1923 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/models-infrastructure/", "name": "Modelle und Infrastruktur", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/lossless-llm-weight-compression-production/", "name": "Verlustfreie LLM-Kompression vs. Q8 GGUF | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ja. Eine Runtime kann eine reversible codierte Repräsentation im VRAM halten, exakte BF16-Werte in Registern oder Shared Memory rekonstruieren und sofort verwenden. Der Nachweis ist ein Bit-exakter Round-trip." }, "name": "Können Gewichte im VRAM verlustfrei komprimiert sein?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Q8_0 repräsentiert Blöcke mit 8-bit-Quantwerten und Scale. Die dequantisierten Werte nähern die Quelle an. GGUF kann auch BF16 oder F16 enthalten, aber ein Q8_0-Artefakt ist quantisiert." }, "name": "Ist Q8_0-GGUF verlustfrei?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nicht allein. Sie garantiert exakt rekonstruierte Gewichte. Andere Kernel, Akkumulationsreihenfolgen, Libraries oder Sampling können Outputs verändern. Prüfe Weight Parity und Runtime-Verhalten separat." }, "name": "Garantiert verlustfreie Gewichtskompression identische Outputs?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Aktuelle Systeme melden für ihren jeweiligen Scope oft ungefähr 20 % bis 33 %. Das GLM-5.2-Experiment decodierte eine modellweite Repräsentation mit 24,967 % Reduktion und berechnete separat K15 mit 30,168 %." }, "name": "Wie stark lässt sich ein BF16-LLM ohne geänderte Gewichte verkleinern?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Die 30,168 % sind vollständiges modellweites Accounting, aber kein physischer GLM-K15-Container wurde unabhängig serialisiert und decodiert. Der A40-Wert ist ein separater Dense-Microbenchmark." }, "name": "Ist der GLM-5.2-K15-Codec produktionsreif?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Wenn exakte BF16-Gewichte Pflicht sind und gemessene Speicher- oder Bandbreitenersparnis die Fleet Economics verändert. Quantisierung gewinnt, wenn Task-Evals ausreichende Qualität und die reifere Runtime bessere Kosten pro erfolgreichem Task zeigen." }, "name": "Wann ist Lossless besser als Quantisierung?" } ] } ```