Qwen-Image-2.1-Turbo vs Qwen-Image-2.1: O que realmente mudou entre o checkpoint base e o acelerado

Mesmo componente de geração visual de 7B. Mesmas 32 camadas DiT de fluxo único. Mesmas sete predefinições de resolução, mesma superfície unificada de geração e edição, mesma licença não comercial, mesma classe de pipeline para carregá-lo. Qwen-Image-2.1-Turbo e Qwen-Image-2.1 não são dois modelos entre os quais se escolhe com base na capacidade — o checkpoint Turbo é um fine-tune da base, e o repositório diz isso nos seus próprios metadados. O que os separa é uma única trajetória de amostragem, e a forma como essa trajetória é armazenada. Um executa quarenta passos. O outro executa oito, e recusa-se a que lhe digam o contrário no momento da chamada. Tudo o que há de interessante nesse par está nessa segunda frase.

Comece pelas partes que são idênticas.

Antes das diferenças, vale a pena mapear as semelhanças, porque são mais extensas do que o rótulo "Turbo" sugere e são o que torna a troca atrativa.

• A arquitetura. O cartão do Turbo afirma que "usa a mesma arquitetura de geração visual de 7B" que o Qwen-Image-2.1. O projeto descreve esse componente como 7B de parâmetros distribuídos em 32 camadas Single-Stream DiT. Nada no repositório do Turbo anuncia um backbone menor, podado ou rearquitetado.

• As capacidades. Ambos os checkpoints são descritos como realizando geração de texto para imagem e edição de imagem. O Turbo herda a superfície do modelo base em vez de reapresentá-la: o card do modelo base documenta transparência RGBA nativa, até 10 imagens de referência e edições locais especificadas por círculos, anotações pintadas ou máscaras separadas, com preservação de identidade para pessoas e produtos.

• As resoluções.O cartão do Turbo diz para "usar as mesmas predefinições de resolução que o Qwen-Image-2.1" e depois lista-as: 1:1 em 2048 × 2048, 4:3 em 2400 × 1792, 3:4 em 1792 × 2400, 3:2 em 2528 × 1696, 2:3 em 1696 × 2528, 16:9 em 2752 × 1536 e 9:16 em 1536 × 2752. O cartão do modelo base lista a tabela idêntica. Ambos os cartões usam o nível de resolução 2048 nos seus exemplos.

• O caminho de carregamento. Ambos carregam por meio do QwenImage21Pipeline no Diffusers. O guia de início rápido do cartão Turbo é o guia de início rápido do cartão base, com o nome do checkpoint alterado e bfloat16 grafado como dtype em vez de torch_dtype.

• A papelada. Ambos estão licenciados sob o Acordo de Licença de Pesquisa Qwen-Image-2.1, ambos trazem license: other com license_name: qwen-research, e ambos têm um arquivo LICENSE no repositório, ao lado dos pesos.

Se você já tem o Qwen-Image-2.1 configurado, então, a superfície de migração é genuinamente pequena. É exatamente por isso que vale a pena se debruçar sobre o único argumento que não se comporta como você espera.

O cronograma saiu do seu código e foi para o checkpoint

No modelo base, o número de passos é você quem define. O exemplo de text-to-image do card do Qwen-Image-2.1, o exemplo de edição e o exemplo de transparência RGBA passam todos num_inference_steps=40, e o número é um argumento passado na chamada, à maneira habitual do Diffusers. Nada naquele card indica que o checkpoint tenha opiniões sobre o cronograma.

No Turbo, o cronograma é um metadado do checkpoint. O card afirma que o checkpoint "inclui seu cronograma de amostragem recomendado, então está pronto para usar sem configurar manualmente o agendador" e, em seguida, na seção de amostragem, explica o que isso significa na prática: "O cronograma de amostragem recomendado de 8 etapas é salvo com o checkpoint e carregado automaticamente. Definir apenas num_inference_steps não o substitui."

Duas coisas se seguem, e ambas são fáceis de errar em direções opostas.

A primeira é que oito não é um padrão que você pode ajustar para cima. Se você quer saber como o Turbo se comporta com doze passos ou vinte, o cartão informa que o único caminho é um argumento sigmas explícito no momento da chamada — e então fecha a porta para o experimento ao observar que outros cronogramas "não foram avaliados para este checkpoint". Isso é um fornecedor dizendo que a configuração de oito passos é aquela que eles endossam, e que qualquer outra coisa é território inexplorado que você está adentrando sozinho. É uma frase incomumente honesta e deve ser lida como um limite, e não como um convite.

A segunda é uma armadilha de reprodução sem nenhuma mensagem de erro associada. Pegue o exemplo do modelo base, altere a string do repositório para o checkpoint Turbo, deixe num_inference_steps=40 no lugar, e o código vai rodar. Ele não vai avisar você. Ele produzirá uma imagem usando o cronograma salvo de oito etapas, e não será a saída que a vitrine do Turbo exibe, porque quarenta nunca foi lido. Este é o modo de falha em que nada parece quebrado — a renderização termina, a imagem é plausível, e a única maneira de você descobrir é se for procurar uma diferença. Há uma segunda dependência enterrada junto com isso: o checkpoint precisa de uma build do Diffusers que entenda sigmas de amostragem configurados no pipeline, adicionados na PR #14950, que, no momento em que escrevo, está na árvore de código-fonte do Diffusers, e não em uma versão com tag. A instalação indicada é uma build do PyTorch compatível com CUDA mais o código-fonte do Diffusers, transformers>=5.17.0, accelerate e pillow.

O que paga pelos 32 passos que você não deu

O cartão nomeia dois mecanismos, e vale a pena conhecer ambos, porque explicam o que o checkpoint Turbo pressupõe sobre como você o chamará.

• CFG 1 por padrão. "A geração usa CFG=1 por padrão." Com uma escala de orientação livre de classificador igual a um, o modelo não está executando a segunda passagem, incondicional, que a CFG normalmente exige — o que é grande parte de como uma trajetória é encurtada sem simplesmente ser truncada. Isso também significa que o hábito do modelo base de ajustar uma escala de orientação não se transfere; não há nada para ajustar aqui, e o cartão não oferece nenhuma recomendação de orientação para a qual ajustar.

• Cache KV de prefixo. O card do Turbo diz que "o cache KV de prefixo reutiliza o contexto de texto e de imagem de referência entre as etapas de denoising". Isso é um mecanismo herdado, não algo novo para o checkpoint acelerado: o anúncio do Qwen-Image-2.1 lista a reutilização do cache KV de prefixo como uma das quatro melhorias de destaque do modelo base, ao lado da atenção de granularidade mista, e as integrações de serving no day-zero para o modelo base — as entradas vLLM-Omni e SGLang na lista de notícias do projeto — nomeiam explicitamente o cache KV de prefixo entre os recursos que suportam. Em um loop de quarenta passos, essa reutilização é uma otimização. Em um loop de oito passos, ela importa proporcionalmente mais, porque cada passo em cache representa uma parcela maior do trabalho total.

O que o card não nomeia é nenhuma técnica de destilação. O card do Qwen-Image-2.1, modelo base, e o README do projeto descrevem a arquitetura e as capacidades; o card do Turbo descreve a mecânica. Se você está tentando raciocinar sobre o que oito passos custam em termos de qualidade, o repositório não oferece nenhum método a partir do qual raciocinar — apenas um cronograma e um conjunto de imagens de demonstração.

A contagem de passos não é uma referência.

Esta é a parte da comparação em que a resposta honesta é que não há comparação, e vale a pena ser direto sobre o porquê.

• O checkpoint Turbo não tem pontuação publicada. O seu cartão não apresenta qualquer número de avaliação. Não há resultado do Qwen-Image-Bench para o Turbo, nem comparação lado a lado com o checkpoint base, nem ablação sobre contagens de passos, nem tabela que mostre onde a qualidade estabiliza.

• A pontuação do checkpoint base é informada pelo fornecedor. O único número de destaque da linha Qwen-Image-2.1 é o resultado do próprio modelo base no Qwen-Image-Bench, reportado pelo fornecedor em relação ao checkpoint base. Não se trata de uma medição do checkpoint Turbo e não deve ser atribuído a ele — a aceleração é exatamente o fator que se esperaria alterar esse número, e o fornecedor não informou em quanto.

• Nenhum dos cards informa tempo ou memória. Não há nenhum número de latência, nenhum número de throughput e nenhuma pegada de memória para qualquer um dos checkpoints, e nenhum dos cards nomeia o hardware em que seus exemplos foram executados. O card do modelo base ao menos documenta uma seção de otimização de memória; o card do Turbo documenta instalação, geração, edição, amostragem e proporções de aspecto, e para por aí.

Portanto, o argumento a favor do Turbo em vez do checkpoint base atualmente é um argumento sobre intenção de design, não sobre resultados medidos. Oito passos na mesma arquitetura e no mesmo nível de resolução 2048 deveriam custar substancialmente menos por imagem. “Substancialmente” está fazendo um trabalho de verdade nessa frase, e a única maneira de substituí-lo por um número é rodar os dois checkpoints na sua própria carga de trabalho, que também é a única maneira de descobrir o que a trajetória encurtada faz com as imagens específicas com que você se importa.

Nada mais se moveu, incluindo a licença

Duas coisas que um leitor poderia razoavelmente esperar que tivessem mudado, e que não mudaram.

O primeiro é o ecossistema. Quando o Qwen-Image-2.1 foi lançado em 20 de setembro de 2026, a lista de notícias do projeto registou cinco integrações day-zero separadas no mesmo dia: suporte do Diffusers via PR #14804, suporte nativo ao ComfyUI com modelos de fluxo de trabalho publicados para texto-para-imagem e edição, suporte ao vLLM-Omni com execução passo a passo e descodificação CUDA Graph e quantização FP8 e paralelismo de tensores, suporte ao SGLang com Cache-DiT e offload de componentes, e aceleração do projeto LightX2V. A entrada datada de 9 de outubro de 2026 que cobre o Qwen-Image-2.1-Turbo regista o próprio checkpoint e uma nota de que as APIs Pro e Turbo estão ativas no Alibaba Cloud Model Studio. Não existe uma lista de frameworks day-zero para o Turbo, e todas as entradas de frameworks na lista de notícias ainda se referem ao modelo base. O checkpoint Turbo carrega através de uma classe de pipeline que já existia; o suporte para o seu agendamento guardado é a única peça nova, e chega através do código-fonte do Diffusers e não de uma versão etiquetada.

A segunda é a licença. O Turbo traz o Qwen Research License Agreement, exatamente como o modelo base. A aceleração não veio com uma isenção comercial, uma categoria separada ou uma flexibilização dos termos — a restrição não comercial aplica-se ao fine-tune tanto quanto ao modelo base. Os metadados do próprio repositório e o ficheiro de licença junto aos pesos são a prova; a secção de licença do card é uma frase que aponta para o mesmo acordo. Se a razão pela qual oito passos são importantes para você é que eles tornam o modelo barato o suficiente para ser colocado num produto, a licença está claramente no caminho, e é o fornecedor — não este repositório — que tem de responder por isso.

Endpoints hospedados, e onde o OrcaRouter se encaixa

O OrcaRouter não roteia nem o Qwen-Image-2.1-Turbo nem o Qwen-Image-2.1. Ambos estão ausentes do nosso catálogo, e nada aqui é uma oferta para atender a qualquer um deles. Se você os quiser, suas rotas são as APIs hospedadas do próprio fornecedor, várias plataformas de terceiros, ou os pesos com uma build do Diffusers recente o suficiente para lidar com o cronograma de amostragem salvo do checkpoint Turbo.

Onde o OrcaRouter se torna relevante para esta comparação específica é na troca que você faz quando hospedar um checkpoint por conta própria deixa de ser a resposta certa. Passar de um modelo de pesos abertos que você mesmo executa para um endpoint de imagem hospedado não é apenas uma mudança de modelo — é uma mudança de modos de falha. Um processo local falha de formas que você consegue ver; um endpoint hospedado falha de formas que dependem de qual provedor respondeu e do que acontece quando um deles degrada no meio da requisição. O OrcaRouter coloca mais de 200 modelos por trás de um único endpoint compatível com a OpenAI e repassa o preço de tabela do provedor sem margem, então um corte de preço de um fornecedor aparece do nosso lado no mesmo dia, em vez de esperar por um ciclo de reprecificação. Além disso, ele adiciona failover automático entre provedores, uma DSL de roteamento para especificar quais modelos e provedores uma requisição pode usar, e fusão de modelos para compor vários modelos em uma única chamada. Os modelos de imagem que cobrimos são a família GPT-Image da OpenAI, os níveis do Imagen 4 do Google, incluindo as variantes fast e ultra, os endpoints de prévia de imagem do Gemini do Google e o endpoint de imagem Grok Imagine da xAI.

Concretamente: se você está escolhendo entre os dois checkpoints do Qwen, essa é uma decisão de auto-hospedagem, e as razões para preferir um em vez do outro são o comportamento do agendamento e o número de passos. Se o que você realmente precisa é de uma imagem em produção sem possuir as GPUs, essa é a decisão para a qual estamos em posição de ajudar, e é uma decisão diferente.

A versão curta

• Escolha o Qwen-Image-2.1 se você quiser o checkpoint cujo comportamento de amostragem corresponde à sua documentação, se precisar variar o número de passos ou explorar cronogramas, ou se quiser a versão que chegou com suporte day-zero em Diffusers, ComfyUI, vLLM-Omni, SGLang e LightX2V.

• Escolha o Qwen-Image-2.1-Turbo se você quiser a mesma arquitetura e as mesmas capacidades com uma trajetória drasticamente mais curta e estiver disposto a tratar oito passos como fixos e a instalar o Diffusers a partir do código-fonte para carregá-lo.

• Espere a mesma licença de qualquer forma, e não espere nenhum número de qualidade publicado para o checkpoint acelerado que permita comparar com o base. A redução de passos é real e documentada. Quanto de qualidade de imagem isso custa não está documentado em lugar nenhum, e não há leitura dos dois cards que lhe dê essa resposta — essa resposta só existe no seu próprio hardware, com os seus próprios prompts.