User's blog

Deploy do Qwen3.8-2.4T-A95B no Amazon SageMaker HyperPod com vLLM

Written by

Make.com Service User

in

O modelo: Qwen3.8-2.4T-A95B em perspectiva

Em 12 de agosto de 2026, a equipe Qwen da Alibaba lançou o Qwen3.8-2.4T-A95B — a primeira vez que um modelo da classe Qwen-Max é disponibilizado como open weights. Os números impressionam: 2,4 trilhões de parâmetros totais, com 95 bilhões ativados por token. A arquitetura combina atenção linear com atenção completa (hybrid linear-plus-full-attention), e o contexto nativo chega a 262 mil tokens, extensível até 1 milhão.

O perfil de uso é claramente voltado para cargas agênticas e de raciocínio intenso: codificação em múltiplos passos, planejamento de longo horizonte e uso autônomo de ferramentas. O fato de ser open weights traz controle total — os dados ficam na sua infraestrutura, o comportamento de inferência pode ser customizado e não há cobrança por token em escala. O custo, porém, é operacional: hospedar um modelo de 2,4 trilhões de parâmetros exige infraestrutura de GPU especializada e uma stack de serving otimizada.

Este artigo é o segundo de uma série da AWS sobre deploy de modelos open trillion-parameter no Amazon SageMaker HyperPod. O primeiro, cobrindo o Kimi K3, está disponível em Deploying Kimi K3 on Amazon SageMaker HyperPod and Amazon EKS.

Arquitetura do modelo

A estrutura interna do Qwen3.8 é relevante para entender as decisões de deploy. São 92 camadas organizadas em um padrão repetido: três blocos de Gated DeltaNet seguidos de Mistura de Especialistas (MoE — Mixture of Experts), mais um bloco de Gated Attention com MoE. Das 92 camadas, 69 usam atenção linear com estado recorrente de tamanho fixo (DeltaNet), enquanto as 23 restantes usam atenção quadrática completa.

Essa proporção 3:1 é a chave para inferência eficiente em contextos longos: as camadas DeltaNet não crescem com o contexto, mantendo memória e computação limitadas mesmo ao se aproximar de 1 milhão de tokens. Já o MoE distribui a capacidade entre 512 especialistas pequenos, ativando apenas cerca de 95 bilhões de parâmetros por passagem — o custo de serving acompanha os parâmetros ativados, não os 2,4 trilhões totais.

O modelo também inclui controle nativo de raciocínio via parâmetro reasoning_effort (baixo, médio, alto) e cabeças de rascunho MTP (Predição Multi-Token — Multi-Token Prediction) integradas nos próprios pesos, o que permite decodificação especulativa sem necessidade de um modelo separado.

Por que o Amazon SageMaker HyperPod para MoE de grande escala

Hospedar um modelo de 2,4 trilhões de parâmetros vai muito além de ter GPUs suficientes. É preciso orquestração que cuide de download de pesos, agendamento de contêineres, monitoramento de saúde, autoescalonamento e recuperação de falhas de nós — tudo sem intervenção manual. O Amazon SageMaker HyperPod foi projetado exatamente para essa classe de workload.

Imagem original — fonte: Aws

Os clusters HyperPod usam o Amazon Elastic Kubernetes Service (Amazon EKS) como plano de controle. Isso significa acesso ao ecossistema completo do Kubernetes — kubectl, Helm charts, definições de recursos customizados — enquanto a AWS gerencia o ciclo de vida da infraestrutura subjacente: rede, armazenamento, instalação de drivers de GPU e o plugin de dispositivos NVIDIA.

O HyperPod Inference Operator fornece um único CRD (Definição de Recurso Customizado — Custom Resource Definition) chamado InferenceEndpointConfig, que declara de forma declarativa o modelo, a imagem de contêiner, os recursos de GPU e os argumentos do vLLM. O operador cuida de download dos pesos (do Hugging Face Hub, Amazon S3 ou Amazon FSx), agendamento de contêineres, verificações de saúde, atualizações contínuas e autoescalonamento via KEDA com métricas do Amazon CloudWatch ou Prometheus.

Entre os recursos adicionais do Inference Operator v3.x, destacam-se: Prefill e Decode Desagregados (DPD), que separa as fases de prefill e decode em pools de GPU distintos para latência previsível; captura de dados de inferência em nível de endpoint, load balancer ou pod; deploy com NVMe local para reduzir latência de cold-start; e gerenciamento de DNS via Amazon Route 53 para registros de domínio customizados.

Dimensionamento de infraestrutura: a instância ml.p6-b300

A instância ml.p6-b300.48xlarge oferece a densidade de computação necessária para serving do Qwen3.8 em um único nó. São 8 GPUs NVIDIA B300 (Blackwell Ultra) com 288 GB de memória HBM3e cada (2,1 TB no total), largura de banda de memória de 8 TB/s por GPU, interconexão NVLink + NVSwitch com 14,4 TB/s de largura de banda bissecionada, ~15 PFLOPS por GPU em FP4, 192 vCPUs, 4.096 GiB de memória de sistema, rede de 6.400 Gbps EFA e 3,8 TB de armazenamento NVMe local.

Essa instância não está disponível sob demanda — é necessário adquirir capacidade via Flexible Training Plan, uma reserva comprometida de disponibilidade de GPU para o cluster HyperPod, sem concorrência com pools on-demand e sem risco de indisponibilidade no cold-start.

Por que quantização NVFP4

Em precisão BF16, os 2,4 trilhões de parâmetros do Qwen3.8 exigiriam aproximadamente 4,8 TB apenas para os pesos — excedendo um único nó de 8 GPUs. A quantização NVFP4 (W4A4) comprime os pesos para cerca de 4 bits por parâmetro, reduzindo o footprint total para aproximadamente 1,2 TB. Isso cabe confortavelmente nos 2,1 TB de memória GPU agregada do p6-b300, deixando espaço para KV-cache e ativações.

A arquitetura híbrida de atenção é uma vantagem adicional: as 69 camadas DeltaNet mantêm um estado recorrente de tamanho fixo independentemente do comprimento do contexto, ao contrário de modelos tradicionais onde o KV-cache cresce linearmente com todas as camadas. Apenas as 23 camadas de atenção completa contribuem para o crescimento de memória dependente do contexto.

Configuração do vLLM em profundidade

A configuração de serving do vLLM para o Qwen3.8 em um único nó p6-b300 é baseada na receita oficial do vLLM para Qwen3.8 no B300 (NVFP4). O comando completo de serving é:

vllm serve Inferact/Qwen3.8-2.4T-A95B-NVFP4 \
  --tensor-parallel-size 8 \
  --quantization nvfp4 \
  --load-format fastsafetensors \
  --trust-remote-code \
  --enable-prefix-caching \
  --moe-backend auto \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}' \
  --served-model-name Qwen3.8

Os flags mais relevantes: --tensor-parallel-size 8 distribui o modelo pelas 8 GPUs B300; --quantization nvfp4 ativa a quantização NVIDIA FP4 (W4A4); --enable-prefix-caching reutiliza blocos de KV-cache entre requisições que compartilham prefixos de prompt — crítico para conversas agênticas multi-turno; --reasoning-parser qwen3 extrai o conteúdo de raciocínio dos blocos <think>...</think> do modelo, separando-o na resposta da API; e --speculative-config '{"method":"mtp","num_speculative_tokens":1}' ativa a decodificação especulativa usando as cabeças de rascunho nativas do Qwen3.8, sem necessidade de modelo separado.

Passo a passo do deploy no SageMaker HyperPod

Os manifestos e scripts completos estão disponíveis no repositório GitHub. O pré-requisito é ter um cluster HyperPod em execução com capacidade p6-b300: crie o cluster com orquestração EKS no console do Amazon SageMaker AI, provisione um Flexible Training Plan cobrindo a instância ml.p6-b300.48xlarge, adicione um grupo de workers com pelo menos 1 instância e aguarde o cluster atingir o estado Active com nós GPU saudáveis.

O manifesto InferenceEndpointConfig para deploy do Qwen3.8 é:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: qwen38
spec:
  modelName: qwen38
  instanceType: ml.p6-b300.48xlarge
  invocationEndpoint: v1/chat/completions
  replicas: 1
  modelSourceConfig:
    huggingFaceModel:
      modelId: Inferact/Qwen3.8-2.4T-A95B-NVFP4
    modelSourceType: huggingface
  worker:
    image: vllm/vllm-openai:qwen38
    modelInvocationPort:
      containerPort: 8000
      name: http
    modelVolumeMount:
      mountPath: /opt/ml/model
      name: model-weights
    resources:
      limits:
        nvidia.com/gpu: 8
      requests:
        nvidia.com/gpu: 8
    args:
      - "--model"
      - "/opt/ml/model"
      - "--serving-model-name"
      - "Qwen3.8"
      - "--linear-backend"
      - "flashinfer_cutedsl"
      - "--trust-remote-code"
      - "--enable-prefix-caching"
      - "--enable-auto-tool-choice"
      - "--tool-call-parser"
      - "qwen3_coder"
      - "--reasoning-parser"
      - "qwen3"
      - "--served-model-name"
      - "Qwen3.8"
      - "--tensor-parallel-size"
      - "8"
    environmentVariables:
      - name: "VLLM_ENGINE_READY_TIMEOUT_S"
        value: "1800"

Para aplicar e monitorar o deploy:

kubectl apply -f qwen.yaml

# Acompanhar o status do InferenceEndpointConfig
kubectl get inferenceendpointconfig qwen38 -w

# Verificar status dos pods (download do modelo e inicialização do contêiner)
kubectl get pods -l model-name=qwen38

# Ver logs de inicialização do vLLM
kubectl logs -f <pod-name> --tail=100

O deploy passa pelas etapas de download dos pesos (~1,2 TB do Hugging Face), carregamento na memória GPU e verificações de saúde. Em um deploy inicial sem cache, espera-se de 15 a 30 minutos. Reinicializações subsequentes com cache NVMe local são significativamente mais rápidas.

Chamando o endpoint: exemplos práticos

Após o endpoint estar pronto, ele expõe uma API compatível com OpenAI. Exemplo básico de chat com raciocínio:

from openai import OpenAI

client = OpenAI(
    base_url="http://<service-endpoint>:8000/v1",
    api_key="unused",  # vLLM não exige auth por padrão
)

response = client.chat.completions.create(
    model="Qwen3.8",
    messages=[{"role": "user", "content": "Explain the trade-offs of MoE vs dense models for inference."}],
    temperature=0.6,
    top_p=0.95,
)

# Trace de raciocínio (o pensamento do modelo)
print("Thinking:", response.choices[0].message.reasoning_content)
# Resposta final
print("Answer:", response.choices[0].message.content)

Para desativar o raciocínio por requisição:

response = client.chat.completions.create(
    model="Qwen3.8",
    messages=[{"role": "user", "content": "What is 2+2?"}],
    extra_body={"chat_template_kwargs": {"enable_thinking": False}},
)

Exemplo de tool calling com schema estrito:

tools = [{
    "type": "function",
    "function": {
        "name": "get_stock_price",
        "description": "Get the current stock price for a ticker symbol",
        "parameters": {
            "type": "object",
            "properties": {
                "ticker": {"type": "string", "description": "Stock ticker, e.g. 'AMZN'"}
            },
            "required": ["ticker"],
            "additionalProperties": False,
        },
        "strict": True,
    }
}]

response = client.chat.completions.create(
    model="Qwen3.8",
    messages=[{"role": "user", "content": "What's Amazon's stock price right now?"}],
    tools=tools,
    tool_choice="auto",
)

print("Thinking:", response.choices[0].message.reasoning_content)
tool_call = response.choices[0].message.tool_calls[0].function
print(f"Function: {tool_call.name}, Args: {tool_call.arguments}")

Os parâmetros de sampling recomendados para a maioria dos casos de uso são temperature=0.6, top_p=0.95 e top_k=20. Para tarefas de raciocínio complexo, defina max_tokens generosamente (32.768–65.536), já que o reasoning_content conta para o orçamento de tokens.

Benchmarks e otimizações de performance

A AWS realizou benchmarks do Qwen3.8-2.4T-A95B em uma única instância p6-b300 (8× B300 GPUs) com 512 requisições de 1.024 tokens de entrada e 1.024 tokens de saída, com concorrência de 32. Foram testadas quatro configurações para isolar o impacto do Paralelismo de Especialistas (EP — Expert Parallelism) e da decodificação especulativa MTP:

Imagem original — fonte: Aws

O MTP é a otimização dominante para o Tempo até o Primeiro Token (TTFT — Time to First Token): habilitar a decodificação especulativa com apenas 1 token de rascunho reduz o TTFT em quase 59%, de 1.244 ms para 513 ms. O EP sozinho oferece ganhos modestos (~3,5% no TTFT). A combinação EP+MTP entrega o melhor resultado geral: 59,7% de redução no TTFT, 12,2% de redução na latência total e 12,6% de aumento no throughput de saída. A recomendação para produção é habilitar ambos: --enable-expert-parallel combinado com --speculative-config '{"method":"mtp","num_speculative_tokens":1}'.

Outros ajustes relevantes: o prefix caching (--enable-prefix-caching) pode reduzir o TTFT em 50–80% em conversas com alto reúso de prefixo. Para MTP, monitore a taxa de aceitação via endpoint /metrics do vLLM — se ficar acima de 70–80%, aumentar num_speculative_tokens para 2–3 é lucrativo; abaixo de 50%, reduza ou desative. Em cargas de alta concorrência, o overhead do MTP pode reduzir o throughput agregado, então considere desativá-lo nesse cenário.

Para gerenciamento de memória, o parâmetro --gpu-memory-utilization (padrão 0,9) controla quanto da memória GPU o vLLM pré-aloca para KV-cache. Com NVFP4, os pesos ocupam ~57% da memória, deixando ~43% (~900 GB) para cache. Reduzir para 0,85 em caso de erros de memória (OOM) em requisições de contexto longo sacrifica capacidade de batch mas evita cascatas de preempção. O parâmetro --max-model-len limita o comprimento máximo de sequência aceito — defini-lo abaixo do contexto nativo de 262K libera mais slots de KV-cache para requisições mais curtas.

Monitoramento

O vLLM expõe métricas Prometheus no endpoint /metrics. As principais a monitorar são: vllm:num_requests_running (tamanho atual do batch), vllm:gpu_cache_usage_perc (utilização do KV-cache — acima de 95% indica risco de preempção), vllm:num_preemptions_total, vllm:spec_decode_acceptance_rate (taxa de aceitação do MTP) e vllm:e2e_request_latency_seconds. Em deploys HyperPod, essas métricas podem ser coletadas pelo Amazon Managed Prometheus e visualizadas no Grafana, ou alimentar decisões de autoescalonamento no KEDA.

Limpeza dos recursos

Para evitar cobranças contínuas, remova os recursos na ordem inversa:

# Deletar o endpoint de inferência
kubectl delete inferenceendpointconfig qwen38

# (Opcional) Escalar ou deletar o cluster HyperPod
# via console do SageMaker AI ou CLI

A exclusão do cluster interrompe as cobranças de computação. O compromisso do Flexible Training Plan permanece até o fim do prazo independentemente do uso.

Próximos passos

Com o endpoint em produção, a AWS sugere alguns caminhos de evolução: benchmarkar com sua distribuição real de prompts usando vllm bench serve; integrar o endpoint em pipelines agênticos via LangChain, CrewAI ou SDK OpenAI padrão; fazer fine-tuning para domínios específicos com NVIDIA NeMo ou jobs de treinamento do SageMaker, trocando apenas o model ID no manifesto; e adicionar guardrails de segurança de conteúdo (como NVIDIA NeMo Guardrails ou proxy customizado) na frente do endpoint vLLM.

Referências

Fonte

Deploying Qwen3.8-2.4T-A95B on Amazon SageMaker HyperPod with vLLM (https://aws.amazon.com/blogs/machine-learning/deploying-qwen3-8-2-4t-a95b-on-amazon-sagemaker-hyperpod-with-vllm/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts