Qwen-Image-2.1-Turbo vs Qwen-Image-2.1: Co tak naprawdę zmieniło się między bazowym checkpointem a wersją przyspieszoną

Ten sam 7B komponent generowania wizualnego. Te same 32 warstwy DiT z pojedynczym strumieniem. Te same siedem ustawień rozdzielczości, ten sam zunifikowany interfejs generowania i edycji, ta sama licencja niekomercyjna, ta sama klasa pipeline do jego załadowania. Qwen-Image-2.1-Turbo i Qwen-Image-2.1 nie są dwoma modelami, między którymi wybierasz pod kątem możliwości — checkpoint Turbo to dostrojenie modelu bazowego i repozytorium mówi o tym we własnych metadanych. Różni je pojedyncza trajektoria próbkowania oraz sposób, w jaki ta trajektoria jest zapisywana. Jeden wykonuje czterdzieści kroków. Drugi wykonuje osiem i nie pozwala sobie powiedzieć inaczej w momencie wywołania. Wszystko, co w tej parze interesujące, zawiera się w tym drugim zdaniu.

Zacznij od części, które są identyczne

Zanim przejdziemy do różnic, warto zmapować to, co wspólne, ponieważ jest tego więcej, niż sugeruje etykieta „Turbo”, i to właśnie czyni tę zamianę tak atrakcyjną.

• Architektura. Karta modelu Turbo stwierdza, że „wykorzystuje tę samą 7B architekturę generowania wizualnego" co Qwen-Image-2.1. Projekt opisuje ten komponent jako 7B parametrów w 32 warstwach Single-Stream DiT. Nic w repozytorium Turbo nie zapowiada mniejszego, przyciętego ani przeprojektowanego szkieletu.

• Możliwości.Oba checkpointy opisano jako wykonujące generowanie obrazów na podstawie tekstu i edycję obrazów. Turbo dziedziczy zakres możliwości modelu bazowego, zamiast go powtarzać: karta modelu bazowego dokumentuje natywną przezroczystość RGBA, do 10 obrazów referencyjnych oraz edycje lokalne określane za pomocą okręgów, namalowanych adnotacji lub oddzielnych masek, z zachowaniem tożsamości osób i produktów.

• Rozdzielczości. Karta Turbo mówi, aby „używać tych samych presetów rozdzielczości co Qwen-Image-2.1”, a następnie wymienia je: 1:1 przy 2048 × 2048, 4:3 przy 2400 × 1792, 3:4 przy 1792 × 2400, 3:2 przy 2528 × 1696, 2:3 przy 1696 × 2528, 16:9 przy 2752 × 1536 i 9:16 przy 1536 × 2752. Karta modelu bazowego wymienia identyczną tabelę. Obie karty w swoich przykładach używają poziomu rozdzielczości 2048.

• Ścieżka ładowania. Oba ładują się przez QwenImage21Pipeline w Diffusers. Quick start karty Turbo to quick start karty bazowej ze zmienioną nazwą checkpointu i zapisem bfloat16 jako dtype zamiast torch_dtype.

• Dokumentacja. Oba są objęte licencją Qwen-Image-2.1 Research License Agreement, oba mają license: other z license_name: qwen-research, a w obu przypadkach w repozytorium, obok wag, znajduje się plik LICENSE.

Jeśli masz już podłączony Qwen-Image-2.1, to zakres migracji jest naprawdę niewielki. I właśnie dlatego warto zatrzymać się nad tym jednym argumentem, który nie zachowuje się tak, jak się spodziewasz.

Harmonogram wyszedł z twojego kodu i trafił do punktu kontrolnego.

W modelu bazowym liczbę kroków ustawiasz sam. Przykład text-to-image z karty Qwen-Image-2.1, jej przykład edycji oraz przykład przezroczystości RGBA — wszystkie przekazują num_inference_steps=40, a ta liczba jest argumentem przekazywanym w momencie wywołania, zgodnie ze zwykłym sposobem w Diffusers. Nic na tej karcie nie mówi, że checkpoint ma zdanie na temat harmonogramu.

W Turbo harmonogram to harmonogram. Karta podaje, że checkpoint „zawiera zalecany harmonogram próbkowania, więc jest gotowy do użycia bez ręcznego konfigurowania schedulera”, a następnie w sekcji próbkowania precyzuje, co to oznacza w praktyce: „Zalecany 8-krokowy harmonogram próbkowania jest zapisywany wraz z checkpointem i ładowany automatycznie. Samo ustawienie __init__ go nie nadpisuje.”

Z tego wynikają dwie rzeczy — a obie łatwo błędnie zrozumieć, i to w przeciwnych kierunkach.

Pierwszą rzeczą jest to, że osiem nie jest wartością domyślną, którą można dostrajać w górę. Jeśli chcesz wiedzieć, jak Turbo wygląda przy dwunastu krokach albo dwudziestu, karta informuje, że jedyną drogą jest jawne podanie argumentu sigmas w czasie wywołania — a potem zamyka drzwi do eksperymentu, stwierdzając, że inne harmonogramy „nie zostały ocenione dla tego checkpointu”. To dostawca mówiący, że to konfiguracja ośmiokrokowa jest tą, za którą stoi, a wszystko inne to niezbadane terytorium, na które wchodzisz sam. To niezwykle szczere zdanie i należy je czytać jako granicę, a nie zaproszenie.

Drugi przypadek to pułapka reprodukcji bez dołączonego komunikatu o błędzie. Weź przykład modelu bazowego, zmień ciąg repozytorium na checkpoint Turbo, pozostaw num_inference_steps=40 bez zmian, a kod się uruchomi. Nie ostrzeże cię. Wygeneruje obraz przy użyciu zapisanego harmonogramu ośmiu kroków i nie będzie to wynik, który prezentuje showcase Turbo, ponieważ wartość czterdzieści nigdy nie została odczytana. To tryb awarii, w którym nic nie wygląda na zepsute — renderowanie się kończy, obraz jest wiarygodny, a jedynym sposobem, by się o tym przekonać, jest szukanie różnicy. Jest jeszcze druga zależność ukryta obok: checkpoint wymaga kompilacji Diffusers, która rozumie sigmy próbkowania konfigurowane przez pipeline, dodanej w PR #14950, która w chwili pisania znajduje się w drzewie źródłowym Diffusers, a nie w wydaniu oznaczonym tagiem. Podana instalacja to kompilacja PyTorch zgodna z CUDA oraz źródła Diffusers, transformers>=5.17.0, accelerate i pillow.

Co płaci za 32 kroki, których nie podjąłeś?

Karta wymienia dwa mechanizmy i oba warto znać, ponieważ wyjaśniają, co punkt kontrolny Turbo zakłada o tym, jak będziesz go wywoływać.

• Domyślnie CFG 1.„Generowanie domyślnie używa CFG=1”. Przy skali guidance bez klasyfikatora wynoszącej jeden model nie wykonuje drugiego, bezwarunkowego przebiegu, którego normalnie wymaga CFG — co w dużej mierze odpowiada za to, że trajektoria zostaje skrócona, a nie po prostu ucięta. Oznacza to również, że nawyk modelu bazowego polegający na dostrajaniu skali guidance nie przenosi się; nie ma tu nic do dostrojenia, a karta nie oferuje żadnej rekomendacji dotyczącej guidance, do której można by dostrajać.

• Buforowanie KV prefiksu.Karta Turbo mówi, że „buforowanie KV prefiksu ponownie wykorzystuje kontekst tekstu i obrazu referencyjnego w kolejnych krokach odszumiania”. To odziedziczony mechanizm, a nie coś nowego dla przyspieszonego checkpointu: ogłoszenie Qwen-Image-2.1 wymienia ponowne wykorzystanie pamięci podręcznej KV prefiksu jako jedno z czterech kluczowych ulepszeń modelu bazowego, obok mechanizmu uwagi o mieszanej granularności, a integracje serwowania od dnia zero dla modelu bazowego — wpisy vLLM-Omni i SGLang na liście aktualności projektu — wymieniają buforowanie KV prefiksu wprost wśród obsługiwanych funkcji. W pętli czterdziestu kroków to ponowne wykorzystanie jest optymalizacją. W pętli ośmiu kroków ma proporcjonalnie większe znaczenie, ponieważ każdy zbuforowany krok stanowi większą część całkowitej pracy.

To, czego karta nie wymienia, to żadna technika destylacji. Karta bazowego modelu Qwen-Image-2.1 i README projektu opisują architekturę i możliwości; karta Turbo opisuje mechanikę. Jeśli próbujesz rozumować, ile osiem kroków kosztuje pod względem jakości, repozytorium nie daje ci żadnej metody rozumowania — tylko harmonogram i zestaw obrazów pokazowych.

Liczba kroków nie jest wyznacznikiem

To jest ta część porównania, w której uczciwa odpowiedź brzmi: nie ma porównania, i warto powiedzieć bez ogródek dlaczego.

• Checkpoint Turbo nie ma opublikowanego wyniku. Na jego karcie nie ma żadnej liczby z oceny. Nie istnieje wynik Qwen-Image-Bench dla Turbo, żadne zestawienie obok siebie z bazowym checkpointem, żadna ablacja liczby kroków ani tabela pokazująca, w którym miejscu jakość przestaje się poprawiać.

• Wynik bazowego checkpointu jest raportowany przez dostawcę. Jedyną kluczową liczbą w linii Qwen-Image-2.1 jest wynik Qwen-Image-Bench samego modelu bazowego, podany przez dostawcę w odniesieniu do bazowego checkpointu. Nie jest to pomiar checkpointu Turbo i nie należy go na niego przenosić — przyspieszenie jest dokładnie tym czynnikiem, który — jak można by oczekiwać — zmieniłby taką liczbę, a dostawca nie podał, o ile.

• Żadna z kart nie podaje czasu ani pamięci. Nie ma danych o opóźnieniu, przepustowości ani zużyciu pamięci dla żadnego z checkpointów, a żadna karta nie wymienia sprzętu, na którym uruchomiono jej przykłady. Karta modelu bazowego przynajmniej dokumentuje sekcję optymalizacji pamięci; karta Turbo dokumentuje instalację, generowanie, edycję, próbkowanie i proporcje obrazu, i na tym się kończy.

Argument za Turbo zamiast podstawowego checkpointu jest obecnie argumentem o intencji projektowej, a nie o zmierzonych wynikach. Osiem kroków przy tej samej architekturze i tym samym poziomie rozdzielczości 2048 powinno kosztować znacznie mniej na obraz. „Znacznie” odgrywa w tym zdaniu realną rolę, a jedynym sposobem, by zastąpić je liczbą, jest uruchomienie obu checkpointów na własnym obciążeniu, co jest także jedynym sposobem, aby przekonać się, co skrócona trajektoria robi z konkretnymi obrazami, na których ci zależy.

Nic innego się nie przesunęło, w tym licencja.

Dwie rzeczy, co do których czytelnik mógłby rozsądnie oczekiwać, że się zmieniły, a które się nie zmieniły.

Pierwszym elementem jest ekosystem. Gdy Qwen-Image-2.1 ukazał się 20 września 2026 r., lista nowości projektu odnotowała tego samego dnia pięć osobnych integracji dostępnych od dnia premiery: obsługę Diffusers przez PR #14804, natywną obsługę ComfyUI z opublikowanymi szablonami przepływów pracy do generowania obrazu z tekstu i edycji, obsługę vLLM-Omni z wykonywaniem krok po kroku oraz dekodowaniem CUDA Graph, kwantyzacją FP8 i równoległością tensorową, obsługę SGLang z Cache-DiT i odciążaniem komponentów oraz przyspieszenie z projektu LightX2V. Wpis z 9 października 2026 r. dotyczący Qwen-Image-2.1-Turbo odnotowuje sam checkpoint oraz informację, że API Pro i Turbo są dostępne w Alibaba Cloud Model Studio. Nie ma listy frameworków na dzień premiery dla Turbo, a każdy wpis dotyczący frameworków na liście nowości nadal odnosi się do modelu bazowego. Checkpoint Turbo ładuje się przez klasę pipeline, która już istniała; obsługa jego zapisanego harmonogramu to jedyny nowy element i pojawia się ona przez źródła Diffusers, a nie przez wydanie oznaczone tagiem.

Druga rzecz to licencja. Turbo jest objęty umową Qwen Research License Agreement, dokładnie tak samo jak model bazowy. Przyspieszenie nie przyszło z komercyjnym wyjątkiem, osobnym poziomem ani złagodzeniem warunków — ograniczenie niekomercyjne dotyczy dostrajania w takim samym stopniu jak modelu bazowego. Dowodem są metadane samego repozytorium oraz plik licencji obok wag; sekcja licencji na karcie to jedno zdanie wskazujące na tę samą umowę. Jeśli ośmioetapowość ma dla ciebie znaczenie dlatego, że czyni model wystarczająco tanim, by umieścić go w produkcie, licencja stoi temu wprost na przeszkodzie, a odpowiedzialność za to ponosi dostawca — nie to repozytorium.

Hostowane endpointy i gdzie pasuje OrcaRouter

OrcaRouter nie obsługuje routingu ani dla Qwen-Image-2.1-Turbo, ani dla Qwen-Image-2.1. Oba są nieobecne w naszym katalogu i nic tutaj nie stanowi oferty ich udostępniania. Jeśli ich potrzebujesz, masz do wyboru: własne hostowane API dostawcy, kilka platform zewnętrznych albo wagi z kompilacją Diffusers wystarczająco nową, by obsłużyć zapisany harmonogram próbkowania punktu kontrolnego Turbo.

To, gdzie OrcaRouter jest istotny w tym konkretnym porównaniu, to zamiana, której dokonujesz, gdy samodzielne hostowanie checkpointu przestaje być właściwą odpowiedzią. Przejście od modelu o otwartych wagach, który uruchamiasz sam, do hostowanego endpointu obrazowego to nie tylko zmiana modelu — to zmiana sposobów awarii. Lokalny proces zawodzi w sposób, który widzisz; hostowany endpoint zawodzi w sposób, który zależy od tego, który dostawca odpowiedział, oraz od tego, co się dzieje, gdy jeden z nich pogorszy działanie w trakcie żądania. OrcaRouter umieszcza ponad 200 modeli za jednym endpointem zgodnym z OpenAI i przekazuje ceny katalogowe dostawców bez marży, więc obniżka ceny u dostawcy pojawia się po naszej stronie tego samego dnia, zamiast czekać na aktualizację cennika. Co więcej, dodaje automatyczne przełączanie awaryjne między dostawcami, DSL routingu do określania, których modeli i dostawców może użyć żądanie, oraz fuzję modeli do łączenia kilku modeli w jedno wywołanie. Modele obrazowe, które obsługujemy, to rodzina OpenAI GPT-Image, poziomy Google Imagen 4, w tym warianty fast i ultra, endpointy podglądu obrazów Google Gemini oraz endpoint obrazowy xAI Grok Imagine.

Konkretnie: jeśli wybierasz między dwoma checkpointami Qwen, to jest decyzja o samodzielnym hostowaniu, a powody, by preferować jeden nad drugim, to zachowanie harmonogramu i liczba kroków. Jeśli tak naprawdę potrzebujesz obrazu na produkcji, nie posiadając GPU, to jest decyzja, w której możemy pomóc, i to jest inna decyzja.

Krótka wersja

• Wybierz Qwen-Image-2.1, jeśli chcesz punkt kontrolny, którego zachowanie podczas próbkowania jest zgodne z jego dokumentacją, jeśli musisz zmieniać liczbę kroków lub eksperymentować z harmonogramami, albo jeśli chcesz wydanie, które pojawiło się wraz ze wsparciem od pierwszego dnia w Diffusers, ComfyUI, vLLM-Omni, SGLang i LightX2V.

• Wybierz Qwen-Image-2.1-Turbo, jeśli chcesz tę samą architekturę i te same możliwości przy dramatycznie krótszej trajektorii i jesteś gotów uznać osiem kroków za stałe oraz zainstalować Diffusers ze źródeł, aby go załadować.

• Tak czy inaczej, spodziewaj się tej samej licencji, a także braku opublikowanej liczby dotyczącej jakości dla przyspieszonego checkpointu, z którą można by porównać wersję bazową. Redukcja liczby kroków jest rzeczywista i udokumentowana. Ile kosztuje to w zakresie jakości obrazu, nie jest nigdzie udokumentowane i żadne czytanie obu kart tego nie rozstrzygnie — ta odpowiedź istnieje wyłącznie na twoim własnym sprzęcie, w odniesieniu do twoich własnych promptów.