Especificações técnicas do Qwen3.5-397B-A17B
| Item | Qwen3.5-397B-A17B (pesos abertos pós-treinado) |
|---|---|
| Model family | Qwen3.5 (série Tongyi Qwen, Alibaba) |
| Architecture | Mixture-of-Experts (MoE) híbrido + Gated DeltaNet; treinamento multimodal de fusão antecipada |
| Total parameters | ~397 bilhões (total) |
| Active parameters (A17B) | ~17 bilhões ativos por token (roteamento esparso) |
| Input types | Texto, Imagem, Vídeo (fusão antecipada multimodal) |
| Output types | Texto (chat, código, saídas de RAG), imagem para texto, respostas multimodais |
| Native context window | 262,144 tokens (ISL nativo) |
| Extensible context | Até ~1,010,000 tokens via escalonamento YaRN/ RoPE (dependente da plataforma) |
| Max output tokens | Dependente do framework/serviço (exemplos mostram 81,920–131,072 nos guias) |
| Languages | 200+ idiomas e dialetos |
| Release date | 16 de fevereiro de 2026 (lançamento de pesos abertos) |
| License | Apache‑2.0 (pesos abertos no Hugging Face / ModelScope) |
O que é o Qwen3.5-397B-A17B
Qwen3.5-397B-A17B é o primeiro lançamento de pesos abertos na família Qwen3.5 da Alibaba: um grande modelo base multimodal de mistura de especialistas, treinado com objetivos de visão–linguagem de fusão antecipada e otimizado para fluxos de trabalho orientados a agentes. O modelo expõe a capacidade total de uma arquitetura de 397B parâmetros, ao mesmo tempo em que usa roteamento esparso (o sufixo “A17B”), de modo que apenas ~17B parâmetros ficam ativos por token — oferecendo um equilíbrio entre capacidade de conhecimento e eficiência de inferência.
Este lançamento destina-se a pesquisadores e equipes de engenharia que precisam de um modelo base aberto, implantável e multimodal, capaz de raciocínio em contextos longos, compreensão visual e aplicações com recuperação aumentada/orientadas a agentes.
Principais recursos do Qwen3.5-397B-A17B
- MoE esparso com eficiência de parâmetros ativos: Grande capacidade global (397B) com atividade por token comparável a um modelo denso de 17B, reduzindo FLOPS por token enquanto preserva a diversidade de conhecimento.
- Multimodalidade nativa (fusão antecipada): Treinado para lidar com texto, imagens e vídeo por meio de uma estratégia unificada de tokenização e codificador para raciocínio intermodal.
- Suporte a contextos muito longos: Comprimento nativo de sequência de entrada de 262K tokens e caminhos documentados para estender a ~1M+ tokens usando escalonamento RoPE/YARN para recuperação e pipelines de documentos longos.
- Modo de raciocínio e ferramentas de agente: Suporte a rastros de raciocínio interno e a um padrão de execução orientado a agentes; exemplos incluem habilitar chamadas de ferramentas e integração com interpretador de código.
- Pesos abertos e ampla compatibilidade: Lançado sob Apache‑2.0 no Hugging Face e ModelScope, com guias oficiais de integração para Transformers, vLLM, SGLang e frameworks da comunidade.
- Cobertura de idiomas adequada a empresas: Treinamento multilíngue extenso (200+ idiomas), além de instruções e receitas para implantação em escala.
Qwen3.5-397B-A17B vs modelos selecionados
| Model | Context window (native) | Strength | Typical trade-offs |
|---|---|---|---|
| Qwen3.5-397B-A17B | 262K (native) | MoE multimodal, pesos abertos, capacidade de 397B com 17B ativos | Artefatos de modelo grandes, requer hospedagem distribuída para desempenho máximo |
| GPT-5.2 (representative closed) | ~400K (reported for some variants) | Alta precisão de raciocínio em modelo denso único | Pesos fechados, custo de inferência mais alto em escala |
| LLaMA‑style dense 70B | ~128K (varies) | Pilha de inferência mais simples, menor VRAM para runtimes densos | Menor capacidade de parâmetros em relação ao conhecimento global de MoE |
Limitações conhecidas e considerações operacionais
- Pegada de memória: O MoE esparso ainda exige armazenar grandes arquivos de pesos; a hospedagem demanda armazenamento e memória de dispositivo significativos em comparação com um clone denso de 17B.
- Complexidade de engenharia: Vazão ideal requer paralelismo cuidadoso (tensor/pipeline) e frameworks como vLLM ou SGLang; a hospedagem ingênua em uma única GPU é impraticável.
- Economia de tokens: Embora o cálculo por token seja reduzido, contextos muito longos ainda aumentam o I/O, o tamanho do cache KV e a cobrança em provedores gerenciados.
- Segurança e limites de proteção: Pesos abertos aumentam a flexibilidade, mas transferem ao operador a responsabilidade por filtragem de segurança, monitoramento e limites de implantação.
Casos de uso representativos
- Pesquisa e análise de modelos: Pesos abertos permitem pesquisa reprodutível e avaliação orientada pela comunidade.
- Serviços multimodais on‑premise: Empresas que exigem residência de dados podem implantar e executar cargas de trabalho de visão+texto localmente.
- Pipelines de RAG e de documentos longs: O suporte nativo a contextos longos ajuda no raciocínio em passagem única sobre grandes corpora.
- Inteligência de código e ferramentas de agente: Analisar monorepos, gerar patches e executar loops de chamadas de ferramentas orientados a agentes em ambientes controlados.
- Aplicações multilíngues: Suporte de idiomas amplo para produtos globais.
Como acessar e integrar o Qwen3.5-397B-A17B
Etapa 1: Cadastre-se para obter a chave de API
Faça login em cometapi.com. Se você ainda não é nosso usuário, registre-se primeiro. Entre no seu console CometAPI. Obtenha a chave de API de credencial de acesso da interface. Clique em “Add Token” no token de API no centro pessoal, obtenha a chave do token: sk-xxxxx e envie.
Etapa 2: Envie solicitações para a API do Qwen3.5-397B-A17B
Selecione o endpoint “Qwen3.5-397B-A17B” para enviar a solicitação de API e definir o corpo da solicitação. O método e o corpo da solicitação são obtidos na documentação de API do nosso site. Nosso site também fornece teste no Apifox para sua conveniência. Substitua <YOUR_API_KEY> pela sua chave CometAPI real da sua conta. Onde chamá-lo: formato de Chat.
Insira sua pergunta ou solicitação no campo content — é a isso que o modelo responderá. Processe a resposta da API para obter a resposta gerada.
Etapa 3: Recuperar e verificar os resultados
Processe a resposta da API para obter a resposta gerada. Após o processamento, a API responde com o status da tarefa e os dados de saída.