Reflection Beam: o modelo open-weight para codificação agêntica na AWS

O que é o Reflection Beam?

A Reflection AI anunciou o Beam, um modelo de linguagem open-weight projetado especificamente para tarefas de codificação agêntica e fluxos de trabalho de longa duração — como manutenção de código, uso de ferramentas, interpretação de resultados e execução de pipelines de múltiplas etapas.

A disponibilização dos pesos do modelo em formato aberto é uma escolha deliberada da empresa: ela dá a desenvolvedores e pesquisadores controle total sobre o ambiente de execução, a infraestrutura de implantação e o processo de customização. A missão declarada da Reflection é tornar a inteligência aberta e acessível a todos, por meio de pesos de modelos públicos, pesquisa publicada e software de código aberto. O stack completo de IA da empresa abrange modelos, software de base, infraestrutura de produção e aplicações.

Arquitetura do modelo

O Beam é um modelo do tipo sparse mixture-of-experts (mistura esparsa de especialistas), desenhado para resolver problemas em código, modificar arquivos, acionar ferramentas e agir sobre resultados intermediários. Seus números principais são:

• 501 bilhões de parâmetros totais — determinam o tamanho do checkpoint, a memória necessária para os pesos, o particionamento e o paralelismo.
• 23 bilhões de parâmetros ativos — influenciam o custo computacional por token gerado.
• Comprimento de contexto efetivo de 1 milhão de tokens, conforme reportado pela Reflection.

Os pesos são distribuídos pelo Hugging Face sob a licença Apache 2.0. O Beam 1.0 está disponível em três variantes de checkpoint: BF16, FP8 e NVFP4. Cada formato tem um footprint de memória diferente e compatibilidade distinta com hardware, o que permite adaptar a implantação ao ambiente disponível.

No lançamento, o Beam está disponível no Amazon SageMaker JumpStart nas regiões US East (N. Virginia) e US East (Ohio).

Caminhos de implantação na AWS

A AWS oferece três caminhos principais para colocar o Beam em produção. A escolha depende do nível de controle necessário sobre a infraestrutura e o runtime de inferência.

• SageMaker JumpStart (endpoint em tempo real): caminho mais gerenciado, sem necessidade de operar Kubernetes. Ideal para quem quer sair do catálogo de modelos e chegar a um endpoint HTTPS gerenciado com o menor atrito possível.
• JumpStart no SageMaker HyperPod Inference: mantém o container e a configuração de modelo gerenciados pela AWS, mas sobre um cluster HyperPod orquestrado pelo Amazon Elastic Kubernetes Service (EKS). Oferece controle nativo sobre capacidade, escalonamento e observabilidade do cluster.
• SGLang ou vLLM no HyperPod Inference: para quem precisa controlar diretamente a imagem de serving, os argumentos de runtime, a quantização ou a execução distribuída.

Planejamento de capacidade de GPU

Com 501 bilhões de parâmetros totais, o Beam exige uma implantação multi-GPU — e, dependendo da precisão escolhida, multi-nó. Alguns pontos importantes de planejamento:

• A variante BF16 tem o maior requisito de memória para os pesos; planeje uma configuração multi-nó com memória agregada de GPU suficiente para os pesos e o overhead de runtime.
• Para FP8, use instâncias ml.p5.48xlarge (NVIDIA H100) ou ml.p5e.48xlarge e ml.p5en.48xlarge (H200).
• Para NVFP4, use ml.p6-b200.48xlarge (NVIDIA B200).

Antes de iniciar, verifique a cota de serviço e a disponibilidade de capacidade para o tipo de instância escolhido. Quando a capacidade sob demanda não estiver disponível, é possível usar um plano de treinamento do SageMaker como reserva de curto prazo para trabalhos agendados.

Caminho 1: endpoint em tempo real com SageMaker JumpStart

Este é o caminho recomendado para quem quer o menor tempo entre o catálogo de modelos e um endpoint gerenciado. O exemplo de código suporta as variantes BF16, FP8 e NVFP4 por meio de um único comando com parâmetro de variante.

O fluxo básico é:

git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git
cd sagemaker-genai-hosting-examples/01-models/ReflectionAI/Beam-1.0-501B-A23B-NVFP4/
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
python jumpstart_real_time.py \
    --variant fp8 \
    --endpoint-name reflection-beam-fp8-smoke

O comando implanta o endpoint FP8, envia uma requisição curta, imprime a resposta e remove o endpoint ao final. Use bf16 ou nvfp4 para selecionar outra variante de checkpoint; NVFP4 é o padrão quando o parâmetro --variant é omitido.

Caminho 2: implantação com SageMaker HyperPod Inference

Use o HyperPod Inference quando precisar de controle nativo Kubernetes sobre a infraestrutura distribuída de GPU. O README do exemplo de implantação no HyperPod Inference é a referência definitiva para os manifests publicados, identificadores de modelo e imagem, versões de runtime suportadas e comandos.

Antes de começar, configure o acesso via kubectl a um cluster HyperPod orquestrado pelo EKS, com o HyperPod Inference Operator e os add-ons necessários. Também são necessários VPC, subnets, grupos de segurança e acesso aos artefatos do Beam e do runtime selecionado.

Para implantações de desenvolvimento, use uma revisão fixada do Beam diretamente do Hugging Face Hub. Para produção e cache de modelo, copie o checkpoint para o Amazon S3 ou Amazon FSx. O recurso de cache de modelo e imagem do HyperPod pode pré-carregar os pesos no armazenamento NVMe local dos nós e fazer o pull antecipado da imagem de serving.

O HyperPod Inference Gateway fornece uma interface compatível com OpenAI e roteia as requisições entre as réplicas. O HyperPod Inference também suporta cache KV em camadas gerenciado e roteamento inteligente, que estão entre as capacidades do Amazon SageMaker Inference introduzidas em 2026.

Implantação com JumpStart no HyperPod

Para um fluxo de infraestrutura como código, use a configuração JumpStart publicada no exemplo do HyperPod. É possível inspecionar o template de manifest reflection-beam-jumpstart.yaml antes de configurar a implantação.

git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git
cd sagemaker-genai-hosting-examples/SageMakerHyperpod/reflection-beam/
cp config/deployment.env.example config/deployment.env
cp config/release.env.example config/release.env
python hyperpod_tool.py \
    --config config/deployment.env \
    --config config/release.env \
    validate jumpstart
python hyperpod_tool.py \
    --config config/deployment.env \
    --config config/release.env \
    deploy jumpstart \
    --timeout-seconds 1800

Implantação com SGLang ou vLLM no HyperPod

Escolha SGLang ou vLLM quando precisar de controle direto sobre o runtime de serving. Antes de configurar a implantação, inspecione o template reflection-beam-sglang.yaml ou o template reflection-beam-vllm.yaml.

git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git
cd sagemaker-genai-hosting-examples/SageMakerHyperpod/reflection-beam/
cp config/deployment.env.example config/deployment.env
cp config/release.env.example config/release.env
python hyperpod_tool.py \
    --config config/deployment.env \
    --config config/release.env \
    validate sglang
python hyperpod_tool.py \
    --config config/deployment.env \
    --config config/release.env \
    deploy sglang \
    --timeout-seconds 1800

Substitua sglang por vllm para usar o vLLM. O helper valida as configurações selecionadas, aplica o manifest renderizado sem gravar os valores de release em disco, aguarda com um timeout fixo e imprime diagnósticos em caso de falha na implantação.

Escolhendo o caminho de serving

A tabela abaixo resume quando usar cada abordagem e o que você gerencia em cada caso:

• SageMaker JumpStart: use quando quiser um container e configuração de modelo gerenciados pela AWS com menos manutenção de runtime. Você gerencia a versão do modelo Beam, o tipo de instância suportado, a configuração do endpoint e a política de escalonamento.
• SGLang ou vLLM: use quando precisar de um runtime de inferência específico ou configuração customizada — como argumentos de runtime personalizados, parsers, quantização ou paralelismo. Você fixa a imagem de runtime suportada, a revisão do modelo, a configuração do parser e as configurações de execução distribuída.

Invocando o Beam e medindo performance

Para endpoints JumpStart, use o schema de requisição publicado. Para SGLang ou vLLM, use o smoke test incluído no exemplo do HyperPod:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
python hyperpod_tool.py \
    --config config/deployment.env \
    smoke sglang \
    --prompt "List three checks for a healthy model deployment." \
    --temperature 1.0 \
    --top-p 0.7

A resposta esperada se assemelha a:

1. Confirm that the endpoint reports ready.
2. Send a short inference request.
3. Review the service logs for startup errors.

Para medir e ajustar a performance, teste cada caminho de serving com requisições representativas de codificação e uso de ferramentas na concorrência esperada. Registre a versão do modelo Beam, o digest da imagem, o tipo de instância, a precisão, o comprimento de contexto, o paralelismo, os argumentos de serving, o estado do cache e as repetições do teste. Meça taxa de sucesso, tempo até o primeiro token (p50 e p95), tempo por token de saída, latência de ponta a ponta e tokens de saída por segundo agregados. A partir desses resultados, ajuste tamanho de batch, alocação de cache KV, contagem de réplicas, autoscaling e cache de modelo e imagem.

Limpeza dos recursos

Ao finalizar os testes, remova os recursos para evitar cobranças contínuas. Para um endpoint em tempo real do SageMaker JumpStart, siga as instruções de limpeza no exemplo de implantação do SageMaker JumpStart. Para JumpStart, SGLang ou vLLM no Amazon SageMaker HyperPod Inference, siga as instruções no exemplo de implantação do HyperPod Inference. Exclua também clusters HyperPod ou EKS criados para o walkthrough, pesos em cache não utilizados, artefatos espelhados, load balancers, grupos de log, funções IAM temporárias e dados de inferência capturados.

Recursos adicionais

• Variantes de checkpoint do Reflection Beam: BF16, FP8 e NVFP4
• Exemplo de implantação no SageMaker JumpStart
• Exemplos de implantação no HyperPod Inference com JumpStart, vLLM e SGLang
• Implantando modelos foundation do SageMaker JumpStart para o HyperPod Inference
• Revisão dos lançamentos do Amazon SageMaker Inference em 2026
• Para saber mais sobre a Reflection AI e sua visão de inteligência aberta, acesse Reflection AI e leia o post Introducing Beam.

Fonte

Introducing Reflection Beam: an open-weight model for agentic coding on AWS (https://aws.amazon.com/blogs/machine-learning/introducing-reflection-beam-an-open-weight-model-for-agentic-coding-on-aws/)