Wan 2.5 é de código aberto? Compreender a mudança estratégica da Alibaba

Quando a Alibaba publicou Wan 2.1 e 2.2 sob Apache 2.0, a comunidade de IA celebrou mais uma vitória da geração de vídeo de código aberto. Mas se procurar Wan 2.5 ou 2.6 no GitHub, não os encontrará. Não é um lapso: é uma mudança estratégica deliberada que revela como as empresas de IA estão a repensar a economia do código aberto.

Resumo executivo

Wan 2.5 e 2.6 não são de código aberto. São distribuídos exclusivamente através das API da Alibaba Cloud, marcando uma clara rutura com o modelo Apache 2.0 usado em Wan 2.1 e 2.2. Este artigo analisa:

Porque a evolução técnica de 2.2 para 2.5 tornou inevitável a distribuição centrada em API
Um quadro de decisão entre 2.2 de código aberto e 2.5/2.6 através de API
Como a abordagem de Wan se compara às estratégias da Stability AI e da Meta
O que isto indica sobre o futuro da IA de código aberto

Parte I: A evolução técnica que mudou tudo

De 1.3B ao multimodal: Compreender o salto de capacidades

A evolução de Wan 2.1 para 2.6 não é apenas uma melhoria gradual: representa alterações arquiteturais fundamentais:

Wan 2.1 (fevereiro de 2025)

Dimensão: 1.3B parâmetros (variante T2V)
Capacidade: Geração de texto para vídeo
Saída: Clips de vídeo sem som
Inferência: Viável em GPU de consumo (24GB VRAM)

Wan 2.2 (julho de 2025)

Dimensão: 5B parâmetros (variante TI2V)
Capacidade: Texto + imagem para vídeo
Saída: Maior qualidade, ainda sem som
Inferência: Requer GPU profissionais (40GB+ VRAM)

Wan 2.5/2.6 (desde setembro de 2025)

Dimensão: Não divulgada (provavelmente 10B+)
Capacidade: Multimodal (texto, imagem, sincronização de áudio)
Saída: Vídeo com áudio sincronizado
Inferência: Requer clusters de GPU distribuídos

Porque a sincronização audiovisual mudou as regras

Adicionar áudio sincronizado a Wan 2.5/2.6 não é apenas uma funcionalidade: multiplica a complexidade arquitetural:

Custo computacional: O alinhamento audiovisual exige treino conjunto entre modalidades, aumentando o custo do treino em cerca de 3-5x
Complexidade da inferência: A sincronização em tempo real exige cadeias de geração coordenadas, difíceis de otimizar fora de ambientes controlados
Controlo de qualidade: Saídas audiovisuais desalinhadas prejudicam a experiência e exigem pós-processamento e validação extensos

Esta complexidade torna o alojamento próprio economicamente impraticável para a maioria dos utilizadores. Um modelo que exige 8x A100 GPU para uma latência aceitável não é «de código aberto» num sentido prático para 99% dos programadores.

A realidade do alojamento próprio

Calculemos o custo real de executar Wan 2.2, a última versão de código aberto, em grande escala:

Requisitos de hardware para produção:

Mínimo: 2x A100 (80GB) = ~$20,000 de hardware
Recomendado: 4x A100 para redundância = ~$40,000
Empresa: Cluster 8x A100 = ~$80,000

Custos operacionais anuais:

Consumo elétrico: ~$15,000-30,000/ano (conforme a utilização)
Refrigeração e infraestrutura: ~$5,000-10,000/ano
Engenharia DevOps/ML: ~$150,000/ano (1 FTE)
Total: ~$170,000-220,000/ano

Análise do limiar de rentabilidade: Se a Alibaba Cloud cobrar $0.10 por geração de vídeo, teria de gerar 1.7-2.2 milhões de vídeos por ano para justificar o alojamento próprio. São ~4,800-6,000 vídeos por dia.

Parte II: Quadro de decisão para programadores

Cenário 1: Protótipos e projetos pequenos (<1,000 vídeos/mês)

Recomendação: API Wan 2.5/2.6

Motivos:

Nenhum investimento em infraestrutura
Acesso às funcionalidades mais recentes (sincronização de áudio, maior qualidade)
Custo estimado: $100-500/mês
Tempo até ao primeiro vídeo: <1 hora

Compromissos:

Dependência da API e possíveis limites de pedidos
Os dados passam pela infraestrutura da Alibaba
Sujeito a alterações de preços

Cenário 2: Aplicações em produção (10,000-100,000 vídeos/mês)

Recomendação: Avaliar cuidadosamente ambas as opções

Alojar Wan 2.2 faz sentido se:

Já tem infraestrutura GPU
A privacidade é fundamental (saúde, área jurídica, empresas)
Precisa de afinar o modelo de forma personalizada
O seu caso de utilização não exige áudio

A API Wan 2.5/2.6 faz sentido se:

Precisa de capacidades audiovisuais
A equipa não tem conhecimentos de infraestrutura ML
Pretende evitar despesas de capital
A flexibilidade de escala importa mais do que a otimização de custos

Cálculo decisivo: Com 50,000 vídeos/mês, os custos da API (~$5,000/mês) aproximam-se dos custos operacionais do alojamento próprio. Este é o ponto de viragem da decisão.

Cenário 3: Investigação e personalização

Recomendação: Wan 2.2 (única opção viável)

Motivos:

As API não permitem alterar a arquitetura do modelo
A investigação exige reprodutibilidade e controlo de versões
O uso académico tem frequentemente limitações orçamentais, mas acesso a recursos de computação institucionais
A afinação com dados específicos exige acesso aos pesos

Verificação realista: Se a investigação exige capacidades de 2.5/2.6, terá de:

Colaborar diretamente com a Alibaba
Usar as saídas da API como referência de comparação
Esperar por uma possível publicação aberta futura (incerta)

Parte III: Três modelos de IA «aberta»: Comparação estratégica

A indústria de IA converge em três abordagens distintas para equilibrar abertura e viabilidade comercial. Compreendê-las revela porque Wan escolheu o seu caminho.

Modelo A: Segmentação geracional (Alibaba Wan)

Estratégia: Manter as gerações anteriores completamente abertas e distribuir as versões de ponta através de API

Implementação de Wan:

Wan 2.1/2.2: Apache 2.0, repositórios GitHub, pesos no Hugging Face
Wan 2.5/2.6: Apenas API através do Alibaba Cloud Model Studio

Vantagens:

Mantém a credibilidade do código aberto e a boa vontade da comunidade
Obtém receitas empresariais de utilizadores que precisam das capacidades mais recentes
Reduz o esforço de assistência (os utilizadores da API não podem danificar o modelo)
Controla abusos e utilizações indevidas das versões mais poderosas

Desvantagens:

Cria um ecossistema de dois níveis (entusiastas e empresas)
A comunidade de investigação fica presa a gerações anteriores
Risco de fragmentação comunitária

Modelo B: Licenciamento por escalões (Stability AI)

Estratégia: Publicar pesos com restrições de licença baseadas nas receitas

Implementação da Stability:

Stable Video Diffusion: Pesos no Hugging Face
Licença: Gratuita para investigação e receitas <$1M; exige licença empresarial acima do limiar
Atualizada em julho de 2024 após a reação negativa da comunidade ao SD3 Medium

Vantagens:

Pesos acessíveis à investigação e a pequenas empresas
Via clara de monetização de utilizadores com receitas elevadas
Mantém o posicionamento de «pesos abertos»

Desvantagens:

Dificuldade de fiscalização (como verificar receitas?)
Complexidade jurídica entre jurisdições
Não é verdadeiramente «código aberto» segundo a definição da OSI

Modelo C: Permissivo com restrições de utilização (Meta Llama)

Estratégia: Pesos completamente abertos com política de utilização aceitável e restrições de escala

Implementação da Meta:

Modelos Llama: Pesos livremente disponíveis
Licença: Permissiva, mas restringe empresas com >700M utilizadores ativos mensais
Objetivo: Impedir concorrência direta (Google ou Microsoft a utilizar Llama contra a Meta)

Vantagens:

Máxima acessibilidade para programadores
Forte adoção comunitária e ecossistema sólido
Posiciona a Meta como fornecedora de infraestrutura IA

Desvantagens:

Sem monetização direta do próprio modelo
Possíveis abusos mais difíceis de controlar
Os concorrentes beneficiam do investimento da Meta em investigação e desenvolvimento

Análise comparativa

Dimensão	Wan (geracional)	Stability (licença por escalões)	Meta (permissivo)
Acesso aos pesos	Apenas versões antigas	Todas as versões	Todas as versões
Modelo de receitas	Serviços API	Licenças + API	Indireto (ecossistema)
Alcance comunitário	Médio	Elevado	O mais elevado
Controlo de abusos	Forte (acesso controlado por API)	Médio (condições da licença)	Fraco (sistema de confiança)
Impacto na investigação	Limitado às versões antigas	Acesso completo	Acesso completo
Clareza comercial	Clara (pagar pela API)	Complexa (verificação de receitas)	Simples (utilização direta)

Porque Wan escolheu a segmentação geracional

A abordagem da Alibaba faz sentido estratégico dada a sua posição:

Vantagem da infraestrutura cloud: Ao contrário da Meta (redes sociais) ou Stability (apenas IA), a Alibaba tem uma enorme infraestrutura cloud para monetizar
Dinâmica do mercado chinês: Os utilizadores nacionais preferem serviços cloud integrados; os internacionais beneficiam da abertura de 2.1/2.2
Posicionamento competitivo: Compete com AWS Bedrock e Google Vertex AI, não com a comunidade de código aberto
Estrutura de custos: Gerar vídeo custa mais do que gerar texto ou imagens, favorecendo a economia das API

Parte IV: O que significa para o futuro

O fim da IA de código aberto incondicional?

O padrão é claro: à medida que os modelos ganham capacidade e ficam mais caros, as empresas procuram monetizá-los mantendo alguma abertura. As publicações de modelos de ponta inteiramente sob Apache 2.0 tornam-se raras.

O que impulsiona esta mudança:

Custos de treino: Treinar Wan 2.5/2.6 terá custado $10M+; as empresas precisam de retorno do investimento
Economia da inferência: Gerar vídeo custa 100-1000x mais do que gerar texto
Pressão competitiva: O Sora da OpenAI é fechado; as alternativas abertas precisam de modelos comerciais sustentáveis
Preocupações com abusos: Deepfakes e desinformação tornam arriscado o acesso sem restrições

Previsões para os próximos 12-24 meses

Cenários prováveis:

Mais segmentação geracional: Outras empresas deverão adotar o modelo Wan: geração N-1 aberta e a mais recente apenas através de API
Consolidação em três modelos: Geracional (Wan), licenciamento por escalões (Stability), permissivo (Meta)
Crescimento do termo «pesos abertos»: As empresas evitarão «código aberto» e usarão «pesos abertos» para descrever publicações restritas
Programas de acesso académico: Os fornecedores criarão programas especiais para investigadores acederem aos modelos mais recentes

Cenários improváveis:

Regresso a Apache 2.0 incondicional para modelos de ponta
Fecho completo de todos os pesos (reação comunitária demasiado forte)
Regulamentação governamental a impor publicações abertas (demasiado cedo no ciclo político)

Recomendações práticas para programadores

Se começar um novo projeto hoje:

Crie primeiro protótipos com API: Valide o caso de utilização com a API Wan 2.5/2.6 antes de investir em infraestrutura
Conceba para a portabilidade: Abstraia a camada de geração de vídeo para poder mudar de fornecedor
Acompanhe o limiar de 50K: Monitorize o volume mensal e reavalie o alojamento próprio ao aproximar-se de 50,000 vídeos/mês
Mantenha Wan 2.2 como alternativa: Preserve a capacidade de regressar a 2.2 alojado por si se os preços da API mudarem desfavoravelmente

Se já utiliza Wan 2.2:

Não migre sem precisar de áudio: Os casos de vídeo sem som não beneficiam de 2.5/2.6
Calcule o limiar de rentabilidade: Utilize a fórmula anterior para determinar se a API faz sentido económico
Teste as diferenças de qualidade: Faça testes A/B para avaliar se as melhorias de 2.5/2.6 justificam o custo

Conclusão: O código aberto não é binário

A pergunta «Wan 2.5 é de código aberto?» revela uma verdade mais profunda: a abertura na IA existe num espetro, não como estado binário.

A abordagem de Wan é pragmática, não cínica. Ao manter 2.1 e 2.2 completamente abertos e distribuir 2.5/2.6 por API, a Alibaba preserva a boa vontade da comunidade enquanto constrói um negócio sustentável. Para a maioria dos programadores, Wan 2.2 continua suficientemente potente para produção. Para quem necessita de capacidades de ponta, a via API é clara e economicamente racional.

A verdadeira pergunta não é se Wan 2.5 é de código aberto, mas se esse modelo consegue sobreviver numa era de treinos de $10M+ e enormes custos de inferência. Segundo os dados atuais, a resposta é: apenas para modelos de gerações anteriores.

Como programadores, precisamos de adaptar as expectativas. «IA de código aberto» significa cada vez mais «o modelo do ano passado é aberto; o deste ano é uma API». Não é ideal, mas é melhor do que nada e talvez seja a única via sustentável.

Apêndice: Perguntas frequentes

P: Posso encontrar pesos Wan 2.5 de terceiros no Hugging Face?

R: Alguns repositórios de terceiros afirmam oferecer Wan 2.5, mas normalmente têm licenças pouco claras, pesos incompletos ou conversões não autorizadas. Confie apenas nas publicações oficiais da organização Wan-AI. Em março de 2026, não existem pesos oficiais Wan 2.5/2.6 no Hugging Face.

P: A Alibaba acabará por publicar Wan 2.5/2.6 em código aberto?

R: Não se sabe. Contudo, o padrão sugere que poderá abrir 2.5 quando surgir 2.7 ou 3.0. O modelo geracional significa que o «código aberto» fica sempre uma geração atrás.

P: Como se compara ao Sora da OpenAI?

R: O Sora é totalmente fechado, sem opção de alojamento próprio. Wan é mais aberto: pode continuar a utilizar Wan 2.2 com controlo total. A comparação torna Wan relativamente favorável aos programadores.

P: E a utilização comercial de Wan 2.2?

R: É totalmente permitida sob Apache 2.0. Pode utilizá-lo comercialmente, modificá-lo e implementá-lo sem restrições ou limiares de receitas.

Referências e leituras adicionais

Fontes primárias:

Organização Wan-Video no GitHub - Repositórios oficiais de Wan 2.1 e 2.2
Wan-AI no Hugging Face - Pesos oficiais dos modelos
Documentação API do Alibaba Cloud Model Studio - Referência API Wan 2.5/2.6

Análise comparativa:

Visão geral das licenças Stability AI - Detalhes da Community License
Licença Meta Llama - Permissiva com restrições de utilização