Qwen-Image-2.1 GGUF: Ile tak naprawdę kosztuje Cię skwantyzowana wersja

Nie istnieje oficjalny plik GGUF Qwen-Image-2.1. Każdy .ggufnoszący tę nazwę powstał już po fakcie, stworzony przez kogoś innego, przez wzięcie 7B transformera dyfuzyjnego dostawcy i ponowne zakodowanie jego wag w niższej precyzji — GGUF to jednoplikowy format skwantyzowanego checkpointu, który odczytują lokalne stosy wnioskowania. To jedno zdanie odpowiada na pierwsze pytanie, jakie ma czytelnik, i rodzi trudniejsze, które rozstrzyga ta strona: co właściwie kompresuje kwantyzacja modelu obrazowego, czego plikowi brakuje od razu po wyjęciu z pudełka, ile kosztują cię poszczególne poziomy w samym obrazie, a nie tylko w czasie, oraz czego wymaga redystrybucja takiego pliku na mocy licencji, z jaką przyszły te wagi.

To sam model jest faktem, który wyznacza datę tej strony, a nie doniesienia, które ona przekazuje. Qwen-Image-2.1 pojawił się na Hugging Face i ModelScope 20 września 2026 r., a tworzone przez społeczność kwantyzacje tego modelu pojawiły się tego samego dnia — repozytoria leejet, Abiray i RealRebelAI powstały 20 września, a repozytorium unsloth 21 września, czyli 23 dni przed napisaniem tej strony. Nie ma potrzeby powtarzać tu niczego o tej osi czasu; czytelnik wpisujący „qwen image 2.1 gguf” chce instrukcji obsługi — i to właśnie ona.

Czym jest GGUF tego modelu, a czym nie jest

Pierwszą rzeczą do przyswojenia jest to, że ten plik to fragment. Qwen-Image-2.1 nie jest jedną siecią; to transformer dyfuzyjny plus enkoder tekstu językowo-wizyjnego plus autoenkoder. Kwantyzacje krążące pod jego nazwą zawierają pierwszy z tych elementów i nic poza tym, a same repozytoria tak twierdzą. Karta Unsloth dla swojego Qwen-Image-2.1 GGUF ujmuje to w jednej linii: „GGUF to tylko denoiser, więc potrzebuje obok siebie VAE i enkodera tekstu Qwen3-VL”.

Zatem pobranie GGUF to transformer — 32 warstwy DiT z pojedynczym strumieniem, 7 mld parametrów w komponencie generowania wizualnego — ponownie zapisany z obniżoną precyzją numeryczną. Koder tekstu i VAE pozostają w swoich oryginalnych formatach albo są kwantyzowane osobno, przez różne osoby, w różnych repozytoriach. To strukturalna różnica względem sytuacji z modelami tekstowymi, którą większość czytelników ma w głowie: kiedy pobierasz GGUF modelu czatu, pobrałeś model. Tutaj pobrałeś jedną trzecią potoku.

Nic z tego nie jest pakowaniem dostawcy. Repozytorium dostawcy Qwen/Qwen-Image-2.1 jest wydaniem w układzie Diffusers — model_index.json, transformer/, text_encoder/, vae/, scheduler/, processor/ — a jego lista plików, odczytana 13 października 2026 r., nie zawiera żadnego pliku .gguf jakiegokolwiek rodzaju. Kwantyzacje to artefakty społeczności, publikowane pod nazwiskami ich autorów, i dziedziczą licencję dostawcy, a nie poparcie dostawcy.

Dlaczego mądrość dotycząca kwantyzacji modeli tekstowych się nie przenosi

Powszechnie przyjęta wiedza o GGUF pochodzi z modeli językowych, gdzie w przybliżeniu wygląda to tak: Q8_0 jest praktycznie bezstratny, Q4_K_M to złoty środek, cokolwiek poniżej Q3 to kompromis, a jakość mierzy się za pomocą perplexji lub dywergencji KL względem referencji pełnej precyzji. Prawie nic z tego nie przenosi się na model obrazu, a powody są warte precyzyjnego wyjaśnienia.

Nie istnieje perplexity dla transformatora dyfuzyjnego. Model nie emituje rozkładu tokenów, który można ocenić; emituje reprezentację utajoną, którą VAE dekoduje do pikseli. Metryki istniejące po tej stronie płotu — LPIPS, SSIM względem referencyjnego renderu — wymagają tego samego ziarna losowości, tego samego promptu i tych samych ustawień samplera po obu stronach porównania, a mimo to mierzą raczej odległość percepcyjną niż poprawność. Zatem pytanie „ile kosztuje mnie Q4_K_M?” nie ma jednej opublikowanej liczby tak jak w przypadku modelu tekstowego, a każdy, kto taką liczbę podaje, podaje wynik jednego pomiaru na jednym ziarnie losowości.

Po drugie, i co ma większe konsekwencje: w modelu obrazu średnia szerokość bitowa ma mniejsze znaczenie niż to, które tensory utraciły swoje bity. Projekcje attention i ścieżki MLP, które przenoszą strukturę obrazu, ulegają widocznej degradacji po zaokrągleniu, podczas gdy małe tensory normalizacji i modulacji tolerują niemal wszystko. Konwersja osiągająca jednolity cel we wszystkich tensorach może zatem wyglądać gorzej niż konwersja o tej samej nominalnej etykiecie, która chroni wrażliwe warstwy — co jest dokładnie tym, co stwierdzili ludzie wykonujący tę pracę. RealRebelAI, publikując najbardziej jednoznaczne notatki o kwantyzacji, jakie udało nam się znaleźć, stwierdza, że „standardowa, ogólna konwersja Q4_K_M wykazywała widoczną utratę jakości w drobnej strukturze i anatomii w porównaniu z referencyjnym modelem INT8”, i że jej własne kompilacje utrzymują attention Q/K/V/Out na poziomie Q8_0 wewnątrz pliku Q4_K_M, aby ją odzyskać. Etykieta w nazwie pliku to kwantyzacja bazowa, a nie polityka.

Po trzecie, tryb awarii ma inny charakter. Kwantyzacja tekstu pogarsza przede wszystkim płynność i degraduje łagodnie — nieco gorsze zdanie wciąż jest zdaniem. Kwantyzacja obrazu na niskich poziomach zawodzi w sposób oczywisty, a czasem prowadzi do nieużywalności: dłonie i anatomia, drobne tekstury, mała typografia oraz — co łatwo przeoczyć, bo to wcale nie jest artefakt pikselowy — zgodność z promptem. Jeśli dany build przestaje wykonywać połowę długiej instrukcji, jest to koszt kwantyzacji i nie ujawni się w zestawieniu obok siebie dwóch dobrych renderów.

Drabina — w plikach, a nie w przymiotnikach.

Rozmiary plików to jedyna część tego, która jest twardym faktem, a nie oceną, ponieważ każde repozytorium publikuje własne zestawienie. Według odczytu z 13 października 2026 r. dwie najczęściej pobierane kwantyzacje społecznościowe nieznacznie się od siebie różnią, co samo w sobie jest wymowne.

• Unsloth Dynamic 2.0 (12 plików): 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 plików): 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 plików): 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 publikuje drabinkę mieszanej precyzji z sufiksem -HQv3 zamiast zwykłych poziomów i dokumentuje precyzję poszczególnych modułów w tabeli; podstawowe kwantyzacje obejmują zakres od Q2_K do Q8_0.

Rozrzut jest realny. Q8_0 obejmuje od 7,59 do 7,69 GB w przypadku trzech wydawców, a Q6_K obejmuje od 5,88 do 6,27 GB — różnica 0,4 GB przy tym samym nominalnym poziomie, co jest polityką mieszanej precyzji ujawniającą się w bajtach. Kto porównuje dwie kompilacje wyłącznie po nazwie pliku, ten porównuje etykiety, a nie artefakty.

Dla porównania po drugiej stronie: referencyjny transformer F16 ma 14,23 GB, a własny komponent dyfuzyjny bfloat16 dostawcy w repacku Comfy-Org ma 14,23 GB. Zatem GGUF klasy Q4 to w przybliżeniu redukcja o 3,4× w przypadku transformera i żadna redukcja w przypadku enkodera tekstu, chyba że skwantujesz go osobno.

Ile kosztuje każdy szczebel, tam gdzie źródło to podaje

Prawie nikt nie publikuje zmierzonego kosztu jakości na poziom dla tego modelu, a uczciwym podejściem jest rozdzielenie trzech rodzajów twierdzeń krążących w obiegu.

• Wskazówki dotyczące pamięci, raportowane przez społeczność. Repozytorium Abiray łączy każdy plik z zalecanym profilem VRAM: Q8_0 7,59 GB przy "12 GB+ (wierność niemal bezstratna)", Q6_K 5,88 GB przy 10–12 GB, Q5_K_M 5,01 GB przy 8–10 GB, Q4_K_M 4,19 GB i Q4_K_S 4,06 GB przy 6–8 GB, oraz Q3_K_M 3,19 GB przy 4–6 GB dla "ekstremalnie niskiego budżetu / minimalnej ilości VRAM". To orientacyjna zasada samego wydawcy, a nie specyfikacja producenta ani benchmark, który moglibyśmy odtworzyć; wytyczne te opisują też wyłącznie plik transformera, więc zapas potrzebny na enkoder tekstu trzeba doliczyć dodatkowo.

• Pomiarowe porównanie, raportowane przez kwantyzator i z pojedynczym ziarnem losowania. Unsloth publikuje jedną parę liczb dla strony enkodera w potoku: swój 4-bitowy enkoder tekstu Dynamic 2.0 w porównaniu z jednolitym enkoderem Q4_K_M, oba przy wspólnym ziarnie losowania, przy ustalonym denoiserze i VAE, przy LPIPS 0,029 i SSIM 0,959, w 5,15 GB versus 5,03 GB oraz 36,5 s versus 39,0 s. To jeden pomiar wykonany przez stronę sprzedającą plik, na jednym ziarnie losowania, i jedyne opublikowane porównanie ilościowe dwóch polityk kwantyzacji dla tego modelu, jakie udało nam się znaleźć.

• Jakościowe listy niepowodzeń, zgłaszane przez społeczność. RealRebelAI wymienia, na co kwantyzacja o niższej liczbie bitów wciąż może wpływać — „drobne szczegóły, dłonie i anatomia, typografia, zgodność z promptem, wierność edycji, spójność tekstur” — i radzi przejść o szczebel wyżej, gdy degradacja jest widoczna. Wyraźnie stwierdza, że Q3_K_M i Q2_K są przeznaczone dla systemów z ograniczoną pamięcią i „mogą nadal wykazywać rosnącą utratę jakości pomimo chronionych warstw wysokiej precyzji”.

To, co nie zostało opublikowane, jest równie ważne jak to, co zostało. Nie ma żadnego oświadczenia producenta na temat jakości kwantyzacji dla Qwen-Image-2.1, żadnego niezależnego testu porównawczego jakiejkolwiek kompilacji GGUF ani tabeli przepustowości na nazwanym sprzęcie konsumenckim od kogokolwiek, kogo udało nam się znaleźć. Kierunek kompromisu w zakresie pamięci jest pewny, a kierunek kompromisu w zakresie szybkości jest zasadniczo pewny; skala kosztu wierności nie została publicznie ustalona, a ta strona nie oszacuje jej za Ciebie.

Co tak naprawdę tym steruje?

Sytuacja ze środowiskiem uruchomieniowym jest wyjątkowo ustabilizowana jak na format tak świeży, co stanowi prawdziwą zaletę w porównaniu z typową sytuacją z GGUF.

• stable-diffusion.cpp — referencyjna implementacja dla modeli graficznych w formacie GGUF. W jego wykazie nowości projektowych odnotowano wsparcie Day-0 dla Qwen-Image-2.1 w dniu 20 września 2026 r. oraz udokumentowano osobną stronę poświęconą temu modelowi. Wiersz poleceń przyjmuje skwantyzowany model dyfuzyjny bezpośrednio: --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, wraz z --steps 20 --cfg-scale 6.0 --sampling-method euler w przykładzie podanym przez samego wydawcę.

• ComfyUI, za pomocą niestandardowego węzła. To ścieżka, którą obierze większość czytelników, a ma ona pewien szczegół wart poznania przed instalacją czegokolwiek. Repozytorium, na które wskazuje większość kwantyzatorów, to city96/ComfyUI-GGUF; autor stable-diffusion.cpp publikuje własny fork, leejet/ComfyUI-GGUF, a jego README zawiera wyraźne zalecenie, by preferować właśnie ten, z podanym uzasadnieniem, że „repozytorium city96 wydaje się już nie być aktywnie utrzymywane”. To twierdzenie jednej strony o drugiej i jest ono datowane; historia commitów w city96/ComfyUI-GGUF faktycznie pokazuje ostatnią aktywność w styczniu 2026 r. Oficjalna strona dokumentacji ComfyUI dla Qwen-Image-2.1 wymienia tylko wagi .safetensors i w ogóle nie wspomina o GGUF, więc niestandardowy węzeł nie jest opcjonalny i nie jest oficjalnie zatwierdzony przez producenta. Oba loadery umieszczają plik w ComfyUI/models/diffusion_models/ i udostępniają go przez loader modeli dyfuzyjnych GGUF.

• llama.cpp / ggml — nie jest to sampler dla tego modelu, lecz źródło formatu i zestaw narzędzi, który tworzy te pliki. Oba repozytoria — leejet i Abiray — wyraźnie przyznają mu zasługi. Jeśli chcesz uzyskać poziom, którego nikt nie opublikował, właśnie tym konwertujesz.

• Unsloth Desktop — wymieniony przez repozytorium unsloth jako obsługiwany frontend obok stable-diffusion.cpp.

Jedno środowisko uruchomieniowe w widoczny sposób nie ładuje go: Diffusers. Własny quick-start dostawcy to QwenImage21Pipeline na repozytorium bfloat16 safetensors, a w tym pipeline nie ma ścieżki GGUF. Jeśli chcesz Diffusers, nie jesteś odbiorcą pliku skwantyzowanego; jeśli chcesz plik skwantyzowany, trafiasz do stable-diffusion.cpp albo grafu ComfyUI.

Część, która tak naprawdę blokuje ludzi

Każdy raport o niepowodzeniu dotyczący tego formatu sprowadza się do tego samego: GGUF jest transformerem, więc resztę potoku trzeba złożyć ręcznie, w odpowiednich formatach, z właściwych repozytoriów. W zakresie są trzy komponenty, a jeden z nich ma w sobie pułapkę.

• Koder tekstu. Qwen-Image-2.1 jest warunkowany przez Qwen3-VL 8B, a ten koder w pełnej precyzji jest większy niż transformer — 17,53 GB w bfloat16 w repacku Comfy-Org, w porównaniu z 14,23 GB dla modelu dyfuzyjnego. W tym samym repacku istnieją alternatywy skwantyzowane o rozmiarze 9,35 GB (int8) i 6,31 GB (w4a8), a niezależnie także w formacie GGUF: dostawca publikuje własny Qwen/Qwen3-VL-8B-Instruct-GGUF z F16 o rozmiarze 16,39 GB, Q8_0 o rozmiarze 8,71 GB i Q4_K_M o rozmiarze 5,03 GB. Warto zauważyć, że ten GGUF kodera jest artefaktem dostawcy, inaczej niż sąsiadujący z nim GGUF transformera — obie połowy Twojego potoku pochodzą od różnych wydawców o różnym pochodzeniu.

• VAE. Pojedynczy plik, qwen_image_2.1_vae_bf16.safetensors, 0,68 GB w repacku Comfy-Org. Jest mały i jest to komponent, który najczęściej uznaje się za wymienny, a nim nie jest: dokumentacja stable-diffusion.cpp podaje, że wcześniejsze wagi VAE Qwen Image i Wan 2.2 nie są wymienne z wagami VAE Qwen Image 2.1. Dobierz niewłaściwy, a graf wczyta się i wygeneruje nieprawidłowy obraz.

• Projektor wizji, jeśli chcesz edytować. Tekst-na-obraz to łatwiejsza połowa. Do edycji obrazu enkoder potrzebuje osobnego multimodalnego projektora: dokumentacja stable-diffusion.cpp instruuje czytelników, aby pobrali również mmproj-Qwen3VL-8B-Instruct-F16.gguf (1,16 GB) z repozytorium enkodera i przekazali go z --llm_vision, a także powtórzyli -r raz na każdy obraz referencyjny. GGUF zawierający wyłącznie transformer wraz z enkoderem tekstu to pipeline tekst-na-obraz i nic więcej.

Warto wiedzieć o jeszcze dwóch uploadach. Wydanie zawiera też dwa enkodery przepisujące prompty — Qwen-Image-2.1-PE-T2I i Qwen-Image-2.1-PE-I2I, oba to dostrojone modele 9B — które dostawca zaleca uruchamiać przed modelem obrazu, a one również są poddawane kwantyzacji: kompilacja GGUF przepisywacza T2I z projektu LightX2V pojawiła się na Hugging Face 12 października 2026 r., obok kilku kompilacji społecznościowych. A kanał alfa, który jest jedną z bardziej charakterystycznych cech tego modelu, przetrwa kwantyzację, ale nie w każdym kontenerze: model dyfuzyjny decyduje o przezroczystości na podstawie promptu, a nie przełącznika, a alfa jest zachowywana tylko w .png i .webp na wyjściu.

Planowanie pamięci wokół samego GGUF to obszar, w którym dokumentacja środowiska uruchomieniowego jest naprawdę konkretna, co zdarza się rzadko. stable-diffusion.cpp ponownie wykorzystuje niezależne od kroku klucze i wartości tekstu oraz obrazu referencyjnego jako pamięć podręczną prefiksu i podaje, ile to kosztuje na warunek dla modelu 32-warstwowego przy prefiksie 4096 tokenów: 4 GiB przy FP32, 2 GiB przy FP16, 1,0625 GiB przy q8_0, 0,5625 GiB przy q4_0. Kwantyzacja pamięci podręcznej to drugi, odrębny kompromis względem kwantyzacji wag, jest domyślnie wyłączona, a skwantyzowane przechowywanie pamięci podręcznej wprowadza dodatkowy błąd zaokrąglenia, który dokumentacja sygnalizuje, a nie ukrywa.

Licencja, którą dziedziczy kwantyzacja

To jest sekcja, którą pomija większość stron o GGUF, a w przypadku tego modelu właśnie ona zmienia to, co możesz zrobić.

Wagi bazowe nie są rozpowszechniane na licencji permisywnej. Qwen/Qwen-Image-2.1 to repozytorium, które zawiera license: other wraz z license_name: qwen-research, a plik LICENSE to Qwen Research License Agreement, z datą wydania 20 września 2026 r. Przeczytana w całości 13 października 2026 r., w swoim zasadniczym postanowieniu udziela niewyłącznej, ogólnoświatowej, nieprzenoszalnej i wolnej od opłat licencyjnych licencji na „używanie, powielanie, rozpowszechnianie, kopiowanie, tworzenie utworów zależnych oraz modyfikowanie Materiałów WYŁĄCZNIE W CELACH NIEKOMERCYJNYCH”, przy czym termin „Non-Commercial” zdefiniowano w umowie jako „wyłącznie do celów badawczych lub ewaluacyjnych”, a użytkowanie komercyjne wymaga odrębnej licencji, o którą należy wystąpić e-mailem pod wskazanym w umowie adresem.

Skwantyzowany checkpoint jest utworem zależnym od tych Materiałów, co oznacza, że redystrybucja GGUF jest redystrybucją na mocy tej umowy i pociąga za sobą wszystkie warunki do niej dołączone. Trzy z nich są konkretne:

• Musisz przekazać umowę dalej. Sekcja 3(a) wymaga, abyś każdemu, kto otrzymuje materiały lub utwór zależny, przekazał kopię licencji. Repozytorium GGUF z tagiem licencji i bez tekstu umowy nie spełnia wymogów, niezależnie od liczby pobrań.

• Musisz oznaczyć, co zmieniłeś. Sekcja 3(b) wymaga, aby zmodyfikowane pliki zawierały widoczne informacje, że zostały zmienione. Ponownie zakodowany plik wag jest plikiem zmodyfikowanym.

• Musisz dołączyć informację o atrybucji w dosłownym brzmieniu. Sekcja 3(c) wymaga, aby tekst informacji — „Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved.” — został zachowany w pliku tekstowym „Notice” rozpowszechnianym wraz z kopiami.

Dwie dodatkowe zasady wiążą osobę wykonującą kwantyzację oraz każdego, kto bazuje na jej wyniku. Jeśli trenujesz, dostrajasz lub ulepszasz model AI z użyciem materiałów lub ich wyników, a następnie go rozpowszechniasz, musisz w widoczny sposób umieścić w dokumentacji produktu napis „Built with Qwen” lub „Improved using Qwen”. Nie możesz też używać nazwy „Qwen” jako podstawowej nazwy ani identyfikatora utworu zależnego, dopuszczalne jest jednak użycie opisowe, takie jak „fine-tuned from Qwen Image”. Prawem właściwym jest prawo chińskie, a wyłączną jurysdykcję mają Sądy Ludowe w Hangzhou.

Praktyczny wniosek sprowadza się do jednego zdania i warto powiedzieć go wprost, bo format go ukrywa: kwantyzacja wag nie zmienia licencji. Każde repozytorium sprawdzone na potrzeby tej strony zawiera license_name: qwen-research i linkuje z powrotem do pliku LICENSE dostawcy, a liczba pobrań pliku GGUF nie jest przyznaniem praw komercyjnych. Dla kontrastu wcześniejsza linia modeli graficznych Qwen była permisywna — karty modeli dla Qwen-Image, Qwen-Image-Edit, Qwen-Image-Edit-2511 i Qwen-Image-2512 zawierają apache-2.0 w dniu 13 października 2026 — a Qwen-Image-2.1 jest wyłamaniem się z tego wzorca. Jeśli celem jest komercyjny potok przetwarzania, licencja to pierwsza rzecz do przeczytania, a nie ostatnia.

Gdzie cię to stawia

Sformułowane jako decyzja, a nie podsumowanie: jeśli twoja karta nie pomieści transformera 14,23 GB plus enkodera 17,53 GB plus VAE, build GGUF to jedyny sposób, w jaki w ogóle uruchomisz Qwen-Image-2.1, a uczciwe oczekiwanie jest takie, że średniopoziomowa kwantyzacja kupuje ci uruchomienie i kosztuje cię coś w drobnych szczegółach, dłoniach, małym tekście i podążaniu za instrukcjami — bez opublikowanych pomiarów, które powiedziałyby ci, jak dużo. Jeśli twoja karta może to pomieścić, ścieżka safetensors jest tą, którą dokumentuje dostawca, i tą z określoną referencją.

Dwóch czytelników potrzebuje po jednym zdaniu w innym miejscu tej witryny. Jeśli tak naprawdę chcesz kompilację społecznościową z usuniętym filtrowaniem bezpieczeństwa, a nie dyskusję o formacie, to inna strona i to tam omówiono nieocenzurowane kompilacje. A jeśli twoim prawdziwym celem jest działający graf węzłów, a nie plik, który musisz złożyć ręcznie, strona ComfyUI przeprowadzi cię przez cały potok, loader po loaderze.

To, co pozostaje otwarte, to rzecz, której ekosystem nie opublikował: kontrolowane porównanie tych poziomów na stałym ziarnie, z tym samym promptem i tym samym samplerem, na sprzęcie, który ktoś wskaże z nazwy. Uwaga RealRebelAI, że generyczny Q4_K_M w widoczny sposób uległ degradacji względem referencji INT8, podczas gdy build o mieszanej precyzji pod tą samą etykietą nie, jest publicznie najbliższym przybliżeniem tej odpowiedzi, i jest to własny test A/B jednego wydawcy. Dopóki ktoś nie opublikuje tego porównania, poziom, który powinieneś wybrać, to najwyższy, na jaki pozwala twoja pamięć, a etykieta w nazwie pliku jest słabszą gwarancją niż stojąca za nią polityka tensorowa.