Avançado 13 minQwen

Qwen3.7 Max localmente: o melhor dos modelos de pesos abertos auto-hospedáveis

O Qwen3.7 Max é o maior modelo de pesos abertos da Alibaba até o momento: um MoE de fronteira projetado para rivalizar com modelos proprietários de ponta. Executar o Qwen3.7 Max localmente não é uma tarefa para o público em geral — exige hardware potente e um pouco de método. Este guia mostra as quantizações que realmente cabem em 24 a 48 GB por placa, como distribuir o modelo entre várias GPUs, a taxa de geração que se pode esperar e os casos em que ele supera de longe as APIs de nuvem.

Por Mohamed Meguedmi·Atualização 2026-06-03·Testado no Windows, macOS e Linux

#Por que Qwen3.7 Max

Em quase todos os benchmarks públicos do final de 2026, o Qwen3.7 Max ocupa o primeiro lugar entre os modelos de pesos abertos: raciocínio em múltiplas etapas, código, matemática, cumprimento de instruções longas em chinês e em inglês — e um nível de francês que já não tem nada de constrangedor. Nesse nível, não há mais razão técnica para enviar seus prompts a um provedor de nuvem, salvo se você precisar de uma taxa de processamento muito alta.

O modelo é distribuído sob a licença Tongyi Qianwen (Apache-2.0 para a maioria dos pesos). As variantes Instruct, Coder e Thinking são publicadas no Hugging Face e também disponibilizadas em ollama.com/library. Para quem dispõe de uma estação de trabalho de IA bem equipada, ele é hoje o modelo de pesos abertos mais convincente como alternativa ao GPT-5 Mini ou ao Claude Sonnet 4.

i
Para quem é este guia
Você tem, no mínimo, uma RTX 4090, um Mac Studio M5 Ultra ou uma configuração com duas GPUs 3090/4090. Se tiver apenas uma placa com 12 a 16 GB, continue usando Qwen3.6 35B-A3B ou Qwen3 32B — o Qwen3.7 Max não é para você.

#O modelo de forma resumida

O kit IA Local

Seu ChatGPT privado e gratuito na sua máquina em 1 hora — LM Studio, Ollama, Open WebUI, seus documentos, sem nuvem.

  • Espaço online vitalício
  • PDF + arquivos
  • Atualizações vitalícias
Arquitetura
Mistura de Especialistas. Aproximadamente 480 bilhões de parâmetros totais, ~46B ativos por token (roteamento para 8 dos 128 especialistas).
Contexto nativo
256 k tokens via YaRN, 1 M tokens com uma extensão experimental. A grande maioria dos usos fica abaixo de 32 k.
Tokenizer
BPE multilíngue no estilo do Tiktoken, com uma baixa proporção de tokens por palavra em francês (≈ 1,4 token/palavra — comparável ao GPT-4).
Variantes
Qwen3.7-Max-Instruct (chat geral), -Coder (programação), -Thinking (raciocínio explícito tipo DeepSeek R1).
Licença
Licença Apache-2.0 nos pesos principais. Uso comercial autorizado, redistribuição permitida, sem cláusula anti-concorrência rígida.
!
MoE = todos os pesos na memória
Mesmo com apenas 46B parâmetros ativos por token, a totalidade dos 480B deve permanecer acessível. O roteador alterna os experts a cada token — impossível 'descarregar' os inativos sem pagar um custo I/O catastrófico. Planeje sua VRAM total com base nisso.

#Pré-requisitos de hardware

VRAM total (Q4_K_M)
Prever ≈ 270 GB para o modelo + cache KV. Essa é a meta com múltiplas GPUs ou um Mac Studio Ultra de 256 GB.
Estação de trabalho mínima viável
Mac Studio M2 Ultra 192 GB (Q3_K_M, contexto 8 k) — a única configuração de uma só máquina voltada ao consumidor que dá conta sem duas GPUs.
Estação de trabalho confortável
4× RTX 4090 de 24 GB (96 GB no total, Q2_K + offload), ou 2× RTX 6000 Ada de 48 GB, ou Mac Studio M3 Ultra ou M5 Ultra de 256 GB para Q4_K_M completo.
RAM do sistema
No mínimo 128 GB se você pretende fazer offloading de especialistas. 256 GB recomendados se você carregar o modelo somente na RAM (muito lento, mas funcional).
Disco
≈ 270 GB para Q4_K_M, ≈ 1 TB para FP16. SSD NVMe Gen4 obrigatório — caso contrário, o carregamento inicial dura 20+ minutos.
Runtime
compilação do llama.cpp pós-outubro de 2026 (suporte a tensor-parallel MoE), vLLM ≥ 0.7, ou Ollama ≥ 0.6 (se a variante GGUF for publicada).

#Quantizações que cabem em 24–48 GB

A pergunta prática é: o que cabe sem comprometer tudo? Os valores de uso de memória abaixo incluem o modelo, um KV-cache para 8 k de contexto e a sobrecarga do ambiente de execução. Eles pressupõem que você some a VRAM de todas as suas placas.

IQ1_M (≈ 110 GB)
Cabe em 2× 48 GB ou em um Mac Studio de 128 GB. Qualidade degradada na programação e no raciocínio longo — útil para experimentar, não para uso em produção.
IQ2_XS (≈ 140 GB)
Mac Studio 192 GB ou 4× RTX 4090 96 GB (com ~40 GB transferidos para a RAM do sistema). Primeiro patamar razoável para chat de uso geral em francês.
Q3_K_M (≈ 200 GB)
Mac Studio M3 Ultra ou M5 Ultra com 256 GB ou 2× RTX 6000 Ada com 96 GB + 128 GB de RAM em offload. Bom equilíbrio entre qualidade e custo.
Q4_K_M (≈ 270 GB)
O ponto ideal em termos de qualidade. O Mac Studio Ultra com 256 GB comporta o modelo com contexto curto; caso contrário, 4× A6000 de 48 GB (192 GB) + offload ou um nó DGX.
Q5_K_M (≈ 330 GB)
Reservado para H100 80 GB ×4, MI300X 192 GB ×2 ou um cluster. Ganho marginal em relação ao Q4 na prática.
Q8_0 (≈ 510 GB)
Somente para datacenters. Nesse nível, vale mais a pena servir o modelo com vLLM usando paralelismo tensorial em 8× H100.
→
A escolha padrão certa
Se o seu objetivo é um uso local sério, escolha Q4_K_M e aceite investir na VRAM total. As quantizações abaixo de Q3 mostram regressões visíveis assim que se vai além de conversas triviais — tipicamente na geração de código longo ou no cumprimento de instruções com múltiplas restrições.

#Instalação

Três opções de acordo com seu hardware. Ollama para simplicidade, llama.cpp para controle, vLLM para atender múltiplos usuários.

#Via 1: Ollama (Mac Studio Ultra)

No Mac Studio Ultra, Ollama gerencia a memória unificada automaticamente. O daemon escuta em http://localhost:11434.

Terminal
# Vérifier qu'Ollama est à jour
ollama --version

# Télécharger la variante adaptée
ollama pull qwen3.7-max:q3_K_M

# Premier lancement (chargement long ~3 min)
ollama run qwen3.7-max:q3_K_M

Durante o carregamento, monitore o ollama ps em um segundo terminal. A coluna SIZE deve exibir o tamanho esperado (≈ 200 GB para Q3_K_M).

#Opção 2: llama.cpp (multi-GPU NVIDIA)

Baixe o GGUF Q4_K_M do Hugging Face (busca: Qwen3.7-Max-Instruct-GGUF, modelos publicados pela equipe Qwen ou por bartowski). O download tem 270 GB — planeje a largura de banda necessária.

Servidor llama.cpp tensor-parallel
./llama-server \
  -m ./models/Qwen3.7-Max-Q4_K_M.gguf \
  --host 0.0.0.0 --port 8080 \
  -c 16384 \
  --tensor-split 24,24,24,24 \
  --main-gpu 0 \
  --flash-attn \
  --cache-type-k q8_0 --cache-type-v q8_0
--tensor-split 24,24,24,24
Distribui as camadas igualmente entre 4 GPUs. Adaptar aos GB disponíveis por placa (ex.: 24,24 para 2 GPUs).
--cache-type-k q8_0
Quantiza o cache KV, libera ~30 % de VRAM, com perda de qualidade desprezível.
--flash-attn
Indispensável acima de 8 k de contexto com essa quantidade de parâmetros.
-c 16384
16 k de contexto é um bom equilíbrio. Aumentar para 32 k custa vários GB adicionais em um modelo de 480B.

#Via 3: vLLM (produção, múltiplos usuários)

Se você atende uma equipe, o vLLM com paralelismo tensorial aproveita melhor a largura de banda PCIe e oferece uma taxa de processamento em lote significativamente superior.

Inicialização do vLLM
vllm serve Qwen/Qwen3.7-Max-Instruct-AWQ \
  --tensor-parallel-size 4 \
  --max-model-len 32768 \
  --quantization awq \
  --gpu-memory-utilization 0.92 \
  --enable-expert-parallel
i
AWQ vs GGUF
O vLLM prefere as quantizações AWQ ou GPTQ, otimizadas para GPUs NVIDIA. O GGUF continua sendo rei em CPU/Mac e em ambientes heterogêneos. Em uma única máquina com GPU exclusivamente NVIDIA, o AWQ de 4 bits no vLLM supera o GGUF Q4_K_M no llama.cpp em taxa de processamento em lote (×2 a ×3 conforme a carga).

#Distribuição multi-GPU

Três estratégias diferentes de acordo com seu hardware e sua carga.

  1. 01
    Divisão de camadas (padrão do llama.cpp)
    Cada GPU recebe um bloco contínuo de camadas. Simples, funciona com GPUs heterogêneas (ex.: 3090 + 4090). Gargalo: apenas uma GPU faz os cálculos por vez, enquanto as outras esperam. Taxa de processamento limitada pela placa mais lenta.
  2. 02
    Paralelização tensorial (vLLM, llama.cpp recente)
    Cada camada é dividida horizontalmente entre todas as GPUs, que fazem os cálculos em paralelo. Exige largura de banda PCIe adequada (Gen4 x16 ou NVLink) e placas homogêneas. Taxa de processamento de 1,8× a 2,5× a obtida com a divisão por camadas em 4 GPUs.
  3. 03
    Paralelismo de especialistas (específico para MoE)
    Distribui os especialistas entre GPUs. Para o Qwen3.7 Max com 128 especialistas em 4 placas, cada GPU gerencia 32 especialistas. Reduz a VRAM por placa, mas cada token ativa especialistas em várias GPUs — boa opção se houver PCIe Gen5 ou NVLink.
→
O PCIe faz muita diferença aqui
Com um MoE desse tamanho, o roteamento de tokens entre especialistas gera tráfego constante entre GPUs. Uma placa-mãe de consumo com PCIe Gen4 x4 no segundo slot vai reduzir a taxa de processamento em 30-50 %. Se você montar um sistema com quatro GPUs, escolha um chassi ThreadRipper ou Xeon com todas as vias PCIe disponíveis.
Verificar a distribuição entre várias GPUs
# Sous Linux, surveille la conso VRAM en direct
watch -n 1 nvidia-smi

# Avec llama.cpp, vérifie que tous les GPU travaillent
nvidia-smi dmon -s u -c 30

#Taxa de tokens por segundo esperada

Medições realizadas em Q4_K_M (salvo indicação em contrário), contexto de 4 k, prompt curto, geração de 512 tokens, batch de 1. A taxa de geração cai logaritmicamente com o comprimento do contexto — a fase de avaliação do prompt explode acima de 16 k tokens.

Mac Studio M3 Ultra ou M5 Ultra 256 GB (Q3_K_M)
≈ 18–24 tok/s em geração. A fase de avaliação do prompt continua boa (~600 tok/s). Excelente para uso individual contínuo, silencioso 24/7.
Mac Studio M2 Ultra 192 GB (IQ2_XS)
≈ 22–28 tok/s, qualidade degradada. Aceitável para testes, não para produção.
2× RTX 6000 Ada 48 GB (Q3_K_M, divisão de camadas)
≈ 28–35 tok/s. Boa opção para workstation profissional.
4× RTX 4090 24 GB (Q4_K_M, tensor-parallel llama.cpp)
≈ 35–45 tok/s em conversa, 80–120 tok/s com batch=4. A melhor relação desempenho/€ em uma configuração caseira.
4× RTX 4090 (vLLM AWQ tensor-parallel)
≈ 50–65 tok/s em conversa individual, até 300+ tok/s agregados em lotes grandes. Preferível para atender uma equipe.
2× H100 80 GB (Q4_K_M, NVLink)
≈ 75–90 tok/s em conversa. Mercado profissional, mas NVLink muda tudo neste perfil de modelo.
i
O que esses números não mostram
Em um MoE desse tamanho, o tempo até o primeiro token com um contexto de 32 k pode chegar a 8 a 15 segundos. Para RAG ou prompts longos, armazene seus prefixos em cache (opção --prompt-cache do llama.cpp ou cache de prefixos do vLLM) — é isso que torna a experiência tolerável.

#Modelos de ponta com pesos abertos versus nuvem

Com desempenho comparável, o que justifica rodar o Qwen3.7 Max localmente em vez de pagar uma API?

Confidencialidade real
Os prompts nunca saem da sua rede. Para advogados, serviços médicos e equipes de RH, isso é inegociável — e nenhuma política de "zero retention" na nuvem se equipara a um air-gap.
Custo marginal nulo
Após a amortização do investimento em hardware, cada token é gratuito. Em cargas de trabalho intensivas (geração sintética de conjuntos de dados, análises em lote), o retorno sobre o investimento supera o da nuvem em alguns meses.
Personalização profunda
Você pode fazer fine-tuning, modificar o prompt de sistema padrão, conectar ferramentas próprias e interceptar os logprobs. Nenhuma API de modelos de fronteira oferece isso.
Independência de fornecedor
Sem cotas, sem limite de requisições por unidade de tempo, sem modelo que desaparece na próxima atualização de preços. O modelo permanece no seu disco.
Latência previsível
Sem congestionamento do servidor, sem "the model is overloaded" no meio de uma demonstração para um cliente.
!
Onde a nuvem ainda está à frente
Para uso interativo pontual com latência muito baixa ou para atender centenas de requisições por segundo, a nuvem continua mais econômica. O Qwen3.7 Max executado localmente se destaca com uma carga sustentada de processamento em lotes, não em picos pontuais — é a mesma lógica da comparação entre um servidor on-prem e SaaS.

#Solução de problemas

OOM ao carregar no quad-4090
Verificar se a soma dos valores de --tensor-split corresponde à VRAM realmente disponível (não à VRAM exibida). Deixar 1-2 GB de margem por placa para o overhead do CUDA.
Velocidade inferior a 10 tok/s
Muito provavelmente, a GPU está recorrendo à RAM do sistema por falta de espaço na VRAM. O nvidia-smi mostrará 100% de VRAM utilizada e uma placa com uso limitado a 30%. Reduza a quantização ou adicione mais VRAM.
Tempo para o primeiro token > 30s
Fase de avaliação do prompt saturada. Ative --flash-attn, quantize o KV-cache e reduza num_ctx ao estritamente necessário. Se possível, agrupe suas requisições em lotes.
Qualidade em queda livre versus benchmarks
Verifique se você está realmente usando a variante Instruct (e não Base), se o template de chat está aplicado (o Ollama faz isso; o llama.cpp não faz sem --chat-template) e se a quantização não caiu abaixo de Q3.
Crash após algumas horas
Geralmente, a causa é térmica: 4 GPUs com 100% de uso aquecem o gabinete. Verifique as temperaturas de junção, ajuste as curvas de ventilação e reduza a tensão em -50 mV a -100 mV. Consultar o guia térmico.
Lentidão extrema no primeiro prompt
O modelo é carregado a partir do SSD — conte com 2 a 5 minutos para 270 GB. Os prompts seguintes são instantâneos enquanto o modelo permanecer na memória.

#Para se aprofundar

O Qwen3.7 Max exige um investimento sério em hardware. Alguns guias relacionados para dimensionar adequadamente a configuração antes da compra:

Configuração multi-GPU com llama.cpp
O guia prático para distribuir um modelo grande entre 2 ou 4 GPUs NVIDIA, com as armadilhas do PCIe e do NVLink.
Qual LLM no Mac Studio (M2/M3/M4 Ultra, 64–512 GB)?
Comparar o que a memória unificada Apple permite em relação a um setup com múltiplos GPUs NVIDIA para esse nível de modelo.
Implantar vLLM em produção
Se o Qwen3.7 Max precisar atender vários usuários simultaneamente, o vLLM com paralelismo tensorial é o componente adequado.
Este guia ajudou você?

Um comentário, um erro ou uma observação? Avise-nos; isso ajuda a melhorar o guia para todos.