Qwen-Image-2.1 GGUF: Was ein quantisierter Build Sie tatsächlich kostet

Es gibt kein offizielles GGUF von Qwen-Image-2.1. Jede .gguf-Datei, die diesen Namen trägt, wurde nachträglich von jemand anderem erzeugt, der den 7B-Diffusionstransformer des Anbieters nahm und dessen Gewichte mit geringerer Präzision neu kodierte — wobei GGUF das einteilige quantisierte Checkpoint-Format ist, das die lokalen Inferenz-Stacks lesen. Dieser eine Satz beantwortet die erste Frage, die ein Leser hat, und wirft die schwierigeren auf, die diese Seite klärt: was eine Quantisierung eines Bildmodells tatsächlich komprimiert, was die Datei standardmäßig nicht enthält, was die Stufen dich im Bild statt nur in der Laufzeit kosten, und was die Weitergabe einer solchen unter der Lizenz erfordert, mit der die Gewichte kamen.

Das Modell selbst ist die Tatsache, die diese Seite datiert, nicht die Nachrichten, die sie berichtet. Qwen-Image-2.1 wurde am 20. September 2026 auf Hugging Face und ModelScope veröffentlicht, und Community-Quantisierungen davon folgten am selben Tag – die Repositories von leejet, Abiray und RealRebelAI wurden alle am 20. September erstellt und das von unsloth am 21. September, was 23 Tage vor der Erstellung dieser Seite liegt. Nichts an dieser Zeitlinie muss hier wiederholt werden; was ein Leser, der „qwen image 2.1 gguf“ eingibt, will, ist die Bedienungsanleitung, und das ist sie.

Was ein GGUF dieses Modells ist und was es nicht ist

Das Erste, was man verinnerlichen muss, ist, dass die Datei ein Fragment ist. Qwen-Image-2.1 ist kein einzelnes Netzwerk; es ist ein Diffusion-Transformer plus ein Vision-Language-Textencoder plus ein Autoencoder. Die unter seinem Namen kursierenden Quantisierungen enthalten nur das Erstgenannte und sonst nichts, und die Repositories sagen das selbst. Unsloths Model Card für sein Qwen-Image-2.1 GGUF fasst es in einer Zeile zusammen: „Ein GGUF ist nur der Denoiser, es braucht also die VAE und den Qwen3-VL-Textencoder daneben.“

Ein GGUF-Download ist also der Transformer – 32 Single-Stream-DiT-Schichten, 7B Parameter in der Komponente zur visuellen Generierung – in reduzierter numerischer Präzision wiedergegeben. Der Textencoder und der VAE bleiben in ihren ursprünglichen Formaten oder werden separat quantisiert, von verschiedenen Personen, in verschiedenen Repositories. Das ist der strukturelle Unterschied zur Textmodell-Situation, die die meisten Leser im Kopf haben: Wenn man ein GGUF eines Chatmodells herunterlädt, hat man das Modell heruntergeladen. Hier hat man ein Drittel einer Pipeline heruntergeladen.

Nichts davon ist die Paketierung des Anbieters. Das Repository des Anbieters Qwen/Qwen-Image-2.1 ist ein Release im Diffusers-Layout — model_index.json, transformer/, text_encoder/, vae/, scheduler/, processor/ — und seine Dateiliste, gelesen am 13. Oktober 2026, enthält keine .ggufDatei jeglicher Art. Die Quantisierungen sind Community-Artefakte, die unter den Namen ihrer Autoren veröffentlicht wurden, und sie übernehmen die Lizenz des Anbieters, nicht aber dessen Billigung.

Warum sich Weisheiten zur Quantisierung von Textmodellen nicht übertragen lassen

Die gängige Lehrmeinung zu GGUF stammt von Sprachmodellen, wo sie ungefähr lautet: Q8_0 ist praktisch verlustfrei, Q4_K_M ist der optimale Kompromiss, alles unterhalb von Q3 ist ein Kompromiss, und die Qualität wird als Perplexität oder KL-Divergenz gegenüber einer Referenz mit voller Genauigkeit gemessen. Fast nichts davon lässt sich auf ein Bildmodell übertragen, und es lohnt sich, die Gründe dafür präzise zu benennen.

Für einen Diffusion Transformer gibt es keine Perplexität. Das Modell gibt keine Token-Verteilung aus, die man bewerten kann; es gibt ein Latent aus, das ein VAE in Pixel dekodiert. Die Metriken, die es auf dieser Seite des Zauns gibt – LPIPS, SSIM gegenüber einem Referenz-Render – erfordern denselben Seed, denselben Prompt und dieselben Sampler-Einstellungen auf beiden Seiten des Vergleichs, und sie messen weiterhin perzeptuelle Distanz statt Korrektheit. Die Frage „Wie viel kostet mich Q4_K_M?“ hat also keine einzelne veröffentlichte Zahl, wie es bei einem Textmodell der Fall ist, und wer eine nennt, nennt eine einzelne Messung auf einem Seed.

Zweitens, und mit größeren Konsequenzen: Bei einem Bildmodell ist die durchschnittliche Bitbreite weniger wichtig als welche Tensoren ihre Bits verloren haben. Die Attention-Projektionen und die MLP-Pfade, die die Bildstruktur tragen, verschlechtern sich sichtbar, wenn sie gerundet werden, während kleine Normalisierungs- und Modulationstensoren fast alles tolerieren. Eine Konvertierung, die bei jedem Tensor ein einheitliches Ziel trifft, kann daher schlechter aussehen als eine Konvertierung mit demselben nominellen Label, die die empfindlichen Schichten schützt — was genau das ist, was die Leute, die diese Arbeit machen, herausgefunden haben. RealRebelAI, die die explizitesten Quantisierungsnotizen veröffentlichen, die wir finden konnten, stellt fest, dass "eine standardmäßige generische Q4_K_M-Konvertierung einen sichtbaren Qualitätsverlust in der Feinstruktur und Anatomie im Vergleich zum Referenz-INT8-Modell zeigte", und dass die eigenen Builds die Attention Q/K/V/Out innerhalb einer Q4_K_M-Datei auf Q8_0 halten, um das wiederherzustellen. Das Label im Dateinamen ist die Basisquantisierung, nicht die Richtlinie.

Drittens ist die Art des Versagens eine grundlegend andere. Bei der Textquantisierung äußert sich die Verschlechterung überwiegend als Flüssigkeit, und sie verläuft allmählich – ein etwas schlechterer Satz ist immer noch ein Satz. Die Bildquantisierung auf den unteren Stufen versagt auf offensichtliche und manchmal unbrauchbare Weise: Hände und Anatomie, feine Texturen, kleine Typografie und – die leicht zu übersehen ist, weil sie überhaupt kein Pixelartefakt ist – die Prompt-Treue. Wenn ein Build die Hälfte einer langen Anweisung nicht mehr befolgt, handelt es sich um Quantisierungskosten, und sie werden in einem direkten Vergleich zweier guter Renderings nicht auftauchen.

Die Leiter, in Dateien statt in Adjektiven

Dateigrößen sind der eine Teil davon, der harte Tatsachen statt Einschätzungen darstellt, weil jedes Repository seine eigene Auflistung veröffentlicht. Am 13. Oktober 2026 gelesen, weichen die beiden meistheruntergeladenen Community-Quantisierungen leicht voneinander ab, was für sich genommen aufschlussreich ist.

• Unsloth Dynamic 2.0 (12 Dateien): F16 14,23 GB, Q8_0 7,64 GB, Q6_K_XL 6,72 GB, Q6_K 6,27 GB, Q5_K_M 5,39 GB, Q5_K_S 4,50 GB, Q4_K_M 4,20 GB, Q4_K_S 3,91 GB, Q3_K_XL 3,61 GB, Q3_K_M 3,17 GB, Q3_K_S 2,72 GB, Q2_K 2,47 GB.

• leejet / stable-diffusion.cpp (7 Dateien): Q8_0 7,69 GB, Q6_K 6,00 GB, Q5_0 5,07 GB, Q4_K 4,20 GB, Q4_0 4,20 GB, Q3_K 3,27 GB, Q2_K 2,56 GB.

• Abiray (6 Dateien): Q8_0 7,59 GB, Q6_K 5,88 GB, Q5_K_M 5,01 GB, Q4_K_M 4,19 GB, Q4_K_S 4,06 GB, Q3_K_M 3,19 GB.

• RealRebelAI veröffentlicht eine Mixed-Precision-Leiter mit einem -HQv3-Suffix statt einfacher Stufen und dokumentiert die Präzision pro Modul in einer Tabelle; die Basis-Quantisierungen reichen von Q2_K bis Q8_0.

Die Streuung ist real. Q8_0 reicht über drei Anbieter hinweg von 7,59 bis 7,69 GB, und Q6_K reicht von 5,88 bis 6,27 GB — eine Lücke von 0,4 GB für denselben nominellen Wert, was die Mixed-Precision-Richtlinie ist, die sich in Bytes niederschlägt. Wer zwei Builds nur anhand des Dateinamens vergleicht, vergleicht Etiketten, nicht Artefakte.

Als Maßstab für die andere Seite: Der Referenz-F16-Transformer ist 14,23 GB groß, und die eigene bfloat16-Diffusionskomponente des Anbieters im Comfy-Org-Repack ist 14,23 GB. Ein GGUF der Q4-Klasse bedeutet also eine ungefähre 3,4-fache Reduktion beim Transformer und überhaupt keine Reduktion beim Text-Encoder, es sei denn, man quantisiert diesen separat.

Was jede Sprosse kostet, sofern eine Quelle dies angibt

Fast niemand veröffentlicht für dieses Modell gemessene Qualitätskosten pro Stufe, und das Ehrliche wäre, die drei Arten von Behauptungen, die im Umlauf sind, auseinanderzuhalten.

• Speicherhinweise, von der Community gemeldet.Abirays Repository ordnet jeder Datei ein empfohlenes VRAM-Profil zu: Q8_0 7,59 GB bei „12 GB+ (nahezu verlustfreie Wiedergabetreue)“, Q6_K 5,88 GB bei 10–12 GB, Q5_K_M 5,01 GB bei 8–10 GB, Q4_K_M 4,19 GB und Q4_K_S 4,06 GB bei 6–8 GB sowie Q3_K_M 3,19 GB bei 4–6 GB für „extremes Budget / minimaler VRAM“. Dabei handelt es sich um die eigene Faustregel des Herausgebers, nicht um eine Herstellerspezifikation und nicht um einen Benchmark, den wir reproduzieren konnten; zudem beschreiben sie nur die Transformer-Datei, sodass der Spielraum, den man für den Text-Encoder benötigt, noch obendrauf kommt.

• Ein gemessener Vergleich, vom Quantisierer berichtet und mit nur einem Seed. Unsloth veröffentlicht ein Zahlenpaar für die Encoder-Seite der Pipeline: seinen Dynamic-2.0-4-Bit-Textencoder gegenüber einem einheitlichen Q4_K_M-Encoder, beide bei einem gemeinsamen Seed, während Denoiser und VAE festgehalten wurden, bei LPIPS 0,029 und SSIM 0,959, in 5,15 GB gegenüber 5,03 GB und 36,5 s gegenüber 39,0 s. Es ist eine einzelne Messung von der Partei, die die Datei verkauft, auf einem einzigen Seed, und es ist der einzige veröffentlichte quantitative Vergleich zweier Quantisierungsstrategien für dieses Modell, den wir finden konnten.

• Qualitative Fehlerlisten, von der Community gemeldet. RealRebelAI benennt, was eine Quantisierung mit niedrigerer Bitbreite noch beeinträchtigen kann – „feine Details, Hände und Anatomie, Typografie, Prompt-Treue, Bearbeitungstreue, Texturkonsistenz" – und rät, eine Stufe höherzugehen, wenn eine Verschlechterung sichtbar ist. Es stellt unmissverständlich fest, dass Q3_K_M und Q2_K für speicherbeschränkte Systeme gedacht sind und „trotz der geschützten hochpräzisen Schichten weiterhin einen zunehmenden Qualitätsverlust aufweisen können".

Was nicht veröffentlicht wird, ist ebenso wichtig wie das, was veröffentlicht wird. Es gibt überhaupt keine Herstelleraussage zur Quantisierungsqualität von Qwen-Image-2.1, keinen unabhängigen Benchmark irgendeines GGUF-Builds und keine Durchsatztabelle auf benannter Consumer-Hardware von irgendjemandem, den wir finden konnten. Die Richtung des Speicher-Kompromisses ist sicher und die Richtung des Geschwindigkeits-Kompromisses ist weitgehend sicher; das Ausmaß der Kosten für die Wiedergabetreue ist öffentlich nicht belegt, und diese Seite wird es nicht für Sie schätzen.

Was führt es tatsächlich aus?

Die Runtime-Situation ist ungewöhnlich stabil für ein so neues Format, was ein echter Vorteil gegenüber der üblichen GGUF-Situation ist.

• stable-diffusion.cpp — die Referenzimplementierung für GGUF von Bildmodellen. Die News-Liste des Projekts verzeichnet Day-0-Unterstützung für Qwen-Image-2.1 am 20. September 2026 und dokumentiert eine eigene Seite für das Modell. Die Kommandozeile nimmt das quantisierte Diffusionsmodell direkt entgegen: --diffusion-model qwen-image-2.1-Q4_K_M.gguf --vae qwen_image_2.1_vae_bf16.safetensors --llm Qwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf, mit --steps 20 --cfg-scale 6.0 --sampling-method euler im eigenen Beispiel des Herausgebers.

• ComfyUI, über einen benutzerdefinierten Node. Dies ist der Weg, den die meisten Leser nehmen werden, und er hat eine Feinheit, die man kennen sollte, bevor man irgendetwas installiert. Das Repository, auf das die meisten Quantisierer verweisen, ist city96/ComfyUI-GGUF; der Autor von stable-diffusion.cpp veröffentlicht seinen eigenen Fork, leejet/ComfyUI-GGUF, und sein README enthält die ausdrückliche Anweisung, ihn zu bevorzugen, mit der angegebenen Begründung, dass „das city96-Repository offenbar nicht mehr aktiv gepflegt wird.“ Das ist eine Behauptung einer Partei über eine andere, und sie ist datiert; die Commit-Historie von city96/ComfyUI-GGUF zeigt tatsächlich seine jüngste Aktivität im Januar 2026. ComfyUIs eigene offizielle Dokumentationsseite für Qwen-Image-2.1 listet nur .safetensors-Gewichte und erwähnt GGUF überhaupt nicht, daher ist der benutzerdefinierte Node nicht optional und nicht vom Anbieter abgesegnet. Beide Loader legen die Datei in ComfyUI/models/diffusion_models/ ab und machen sie über einen GGUF-Diffusionsmodell-Loader zugänglich.

• llama.cpp / ggml — kein Sampler für dieses Modell, sondern der Ursprung des Formats und die Toolchain, die diese Dateien erzeugt. Sowohl die leejet- als auch die Abiray-Repositories nennen es ausdrücklich als Quelle. Wenn du eine Stufe willst, die noch niemand veröffentlicht hat, dann konvertierst du damit.

• Unsloth Desktop — vom unsloth-Repository als unterstütztes Frontend neben stable-diffusion.cpp genannt.

Eine Laufzeitumgebung lädt es auffälligerweise nicht: Diffusers. Der Quickstart des Anbieters selbst ist eine QwenImage21Pipeline über das bfloat16-safetensors-Repository, und in dieser Pipeline gibt es keinen GGUF-Pfad. Wenn Sie Diffusers wollen, sind Sie nicht die Zielgruppe für eine quantisierte Datei; wenn Sie eine quantisierte Datei wollen, landen Sie bei stable-diffusion.cpp oder einem ComfyUI-Graph.

Der Teil, der Menschen tatsächlich blockiert

Jeder Fehlerbericht zu diesem Format lässt sich auf dieselbe Sache zurückführen: Die GGUF ist der Transformer, also muss der Rest der Pipeline von Hand zusammengesetzt werden, in den richtigen Formaten, aus den richtigen Repositories. Drei Komponenten sind relevant, und eine davon enthält eine Falle.

• Der Text-Encoder. Qwen-Image-2.1 konditioniert auf Qwen3-VL 8B, und dieser Encoder ist bei voller Präzision größer als der Transformer — 17,53 GB in bfloat16 im Comfy-Org-Repack, gegenüber 14,23 GB für das Diffusionsmodell. Quantisierte Alternativen gibt es mit 9,35 GB (int8) und 6,31 GB (w4a8) im selben Repack sowie unabhängig davon als GGUF: Der Anbieter veröffentlicht ein First-Party-Qwen/Qwen3-VL-8B-Instruct-GGUF mit F16 bei 16,39 GB, Q8_0 bei 8,71 GB und Q4_K_M bei 5,03 GB. Beachten Sie, dass dieses Encoder-GGUF ein Artefakt des Anbieters ist, anders als das Transformer-GGUF, neben dem es liegt — die beiden Hälften Ihrer Pipeline stammen von unterschiedlichen Herausgebern mit unterschiedlicher Provenienz.

• Der VAE. Eine einzelne Datei, qwen_image_2.1_vae_bf16.safetensors, 0,68 GB im Comfy-Org-Repack. Sie ist klein, und sie ist die Komponente, von der die Leute am häufigsten annehmen, sie sei austauschbar – und das ist sie nicht: Die Dokumentation von stable-diffusion.cpp gibt an, dass die früheren VAE-Gewichte von Qwen Image und Wan 2.2 nicht mit den VAE-Gewichten von Qwen Image 2.1 austauschbar sind. Wird die falsche gewählt, lädt der Graph und erzeugt das falsche Bild.

• Der Vision-Projektor, wenn Sie bearbeiten möchten. Text-zu-Bild ist die einfache Hälfte. Für die Bildbearbeitung benötigt der Encoder einen separaten multimodalen Projektor: Die stable-diffusion.cpp-Dokumentation weist die Leser an, außerdem mmproj-Qwen3VL-8B-Instruct-F16.gguf (1,16 GB) aus dem Encoder-Repository herunterzuladen und es mit --llm_vision zu übergeben und -r einmal pro Referenzbild zu wiederholen. Ein reines Transformer-GGUF plus ein Text-Encoder ist eine Text-zu-Bild-Pipeline und nichts weiter.

Zwei weitere Uploads sind erwähnenswert. Das Release bringt außerdem zwei Encoder zur Prompt-Umschreibung mit — Qwen-Image-2.1-PE-T2I und Qwen-Image-2.1-PE-I2I, beides feinabgestimmte 9B-Modelle —, die der Hersteller empfiehlt, dem Bildmodell vorzuschalten, und auch diese werden quantisiert: Ein GGUF-Build des T2I-Rewriters aus dem LightX2V-Projekt erschien am 12. Oktober 2026 auf Hugging Face, zusammen mit mehreren Community-Builds. Und der Alpha-Kanal, eines der charakteristischeren Merkmale dieses Modells, übersteht die Quantisierung, aber nicht jedes Containerformat: Das Diffusionsmodell entscheidet die Transparenz anhand des Prompts statt über einen Schalter, und das Alpha bleibt nur in der .png und .webp Ausgabe erhalten.

Die Speicherplanung rund um die GGUF selbst ist ein Bereich, in dem die Laufzeitdokumentation wirklich konkret wird, was selten ist. stable-diffusion.cpp verwendet die schrittunabhängigen Schlüssel und Werte für Text und Referenzbild als Präfix-Cache wieder und veröffentlicht, was das pro Bedingung für das 32-Schichten-Modell bei einem 4096-Token-Präfix kostet: 4 GiB bei FP32, 2 GiB bei FP16, 1,0625 GiB bei q8_0, 0,5625 GiB bei q4_0. Das Quantisieren des Caches ist ein zweiter, separater Kompromiss gegenüber dem Quantisieren der Gewichte, es ist standardmäßig deaktiviert, und quantisierter Cache-Speicher führt zu einem zusätzlichen Rundungsfehler, den die Dokumentation benennt, statt ihn zu verbergen.

Die Lizenz, die die Quantisierung erbt

Dies ist der Abschnitt, den die meisten GGUF-Seiten überspringen, und für dieses Modell ist er derjenige, der verändert, was Sie tun können.

Die Basisgewichte werden nicht unter einer permissiven Lizenz verbreitet. Das Qwen/Qwen-Image-2.1Repository trägt Lizenz: other mit Lizenzname: qwen-research, und bei der LICENSE-Datei handelt es sich um die Qwen Research License Agreement, Veröffentlichungsdatum 20. September 2026. Vollständig gelesen am 13. Oktober 2026, ist ihre maßgebliche Gewährung eine nicht ausschließliche, weltweite, nicht übertragbare, lizenzgebührenfreie Lizenz, die Materialien „AUSSCHLIESSLICH FÜR NICHT-KOMMERZIELLE ZWECKE" zu nutzen, zu reproduzieren, zu verbreiten, zu kopieren, abgeleitete Werke davon zu erstellen und Änderungen daran vorzunehmen, wobei „Non-Commercial" innerhalb der Vereinbarung als „nur für Forschungs- oder Evaluierungszwecke" definiert ist und die kommerzielle Nutzung auf eine separate Lizenz verwiesen wird, die per E-Mail an die in der Vereinbarung genannte Adresse beantragt wird.

Ein quantisierter Checkpoint ist ein abgeleitetes Werk jener Materialien, was bedeutet, dass die Weiterverbreitung einer GGUF eine Weiterverbreitung unter dieser Vereinbarung ist und jede daran geknüpfte Bedingung übernimmt. Drei davon sind konkret:

• Sie müssen die Vereinbarung weitergeben. Abschnitt 3(a) verlangt, dass Sie jedem, der die Materialien oder ein abgeleitetes Werk erhält, eine Kopie der Lizenz aushändigen. Ein GGUF-Repository mit einem Lizenz-Tag und ohne Vereinbarungstext ist nicht konform, unabhängig von seiner Download-Zahl.

• Sie müssen kennzeichnen, was Sie geändert haben. Abschnitt 3(b) verlangt, dass geänderte Dateien gut sichtbare Hinweise tragen, die besagen, dass sie geändert wurden. Eine neu kodierte Gewichtsdatei ist eine geänderte Datei.

• Sie müssen den Attributionshinweis wörtlich mitführen. Abschnitt 3(c) verlangt, dass der Hinweistext – "Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved." – in einer "Notice"-Textdatei beibehalten wird, die zusammen mit den Kopien verteilt wird.

Zwei weitere Regeln binden die Person, die die Quantisierung durchführt, und alle, die auf dem Ergebnis aufbauen. Wenn Sie ein KI-Modell unter Verwendung der Materialien oder ihrer Ausgaben trainieren, feinabstimmen oder verbessern und es dann verbreiten, müssen Sie in der Produktdokumentation deutlich sichtbar „Built with Qwen“ oder „Improved using Qwen“ angeben. Und Sie dürfen „Qwen“ nicht als primären Namen oder Bezeichner eines abgeleiteten Werks verwenden, wobei eine beschreibende Verwendung wie „fine-tuned from Qwen Image“ zulässig ist. Es gilt chinesisches Recht, mit ausschließlicher Zuständigkeit bei den Volksgerichten von Hangzhou.

Das praktische Fazit ist eine Zeile, und es lohnt sich, es klar auszusprechen, weil das Format es verdeckt: Die Quantisierung der Gewichte ändert nichts an der Lizenz. Jedes für diese Seite untersuchte Repository trägt license_name: qwen-research und verlinkt zurück auf die LICENSE-Datei des Anbieters, und die Downloadzahl einer GGUF-Datei ist keine Gewährung kommerzieller Rechte. Im Gegensatz dazu war die frühere Qwen-Bild-Reihe permissiv – die Modellkarten für Qwen-Image, Qwen-Image-Edit, Qwen-Image-Edit-2511 und Qwen-Image-2512 lauteten am 13. Oktober 2026 allesamt apache-2.0 – und Qwen-Image-2.1 ist der Bruch in diesem Muster. Wenn eine kommerzielle Pipeline das Ziel ist, ist die Lizenz das Erste, was man lesen sollte, und nicht das Letzte.

Wo dich das hinstellt

Als Entscheidung formuliert, nicht als Zusammenfassung: Wenn Ihre Grafikkarte den 14,23 GB großen Transformer plus einen 17,53 GB großen Encoder plus das VAE nicht aufnehmen kann, ist ein GGUF-Build die einzige Möglichkeit, Qwen-Image-2.1 überhaupt auszuführen, und die ehrliche Erwartung ist, dass eine mittlere Quantisierung Ihnen den Lauf erkauft und Sie etwas bei feinen Details, Händen, kleinem Text und Instruction-Following kostet — ohne dass eine veröffentlichte Messung Ihnen sagt, wie viel. Wenn Ihre Grafikkarte das schafft, ist der safetensors-Weg derjenige, den der Anbieter dokumentiert, und derjenige mit einer definierten Referenz.

Zwei Leser brauchen jeweils einen Satz an anderer Stelle auf dieser Website. Wenn Sie eigentlich einen Community-Build mit entfernten Sicherheitsfiltern wollen statt einer Diskussion des Formats, dann ist das eine andere Seite, und die unzensierten Builds werden dort behandelt. Und wenn Ihr eigentliches Ziel ein funktionierender Node-Graph ist statt einer Datei, die Sie von Hand zusammenbauen müssen, dann führt die ComfyUI-Seite Sie durch die gesamte Pipeline – Loader für Loader.

Was offen bleibt, ist das, was das Ökosystem nicht veröffentlicht hat: ein kontrollierter Vergleich dieser Stufen auf einem festen Seed, mit demselben Prompt und demselben Sampler, auf Hardware, die jemand namentlich nennt. RealRebelAIs Hinweis, dass ein generisches Q4_K_M sichtbar gegenüber einer INT8-Referenz abfiel, während ein Mixed-Precision-Build unter demselben Label dies nicht tat, ist das, was in der Öffentlichkeit dieser Antwort am nächsten kommt, und es ist der eigene A/B-Test eines einzelnen Anbieters. Bis jemand den Vergleich veröffentlicht, ist die Stufe, die du wählen solltest, die höchste, die dein Speicher zulässt, und das Label im Dateinamen ist eine schwächere Garantie als die dahinterstehende Tensor-Policy.