Os pesos do Beam saíram. Como você serve o modelo agora pesa tanto quanto o modelo
O Beam saiu em 16 de outubro em três precisões, com receitas de day zero da AWS e do Google Cloud. Para agentes de código, a arquitetura de serving agora define o custo tanto quanto o modelo.
Ouça este artigo · 6 min
Narração completa do artigo, gerada por IA.
Quando o Reflection anunciou o Beam em 5 de outubro, os pesos ainda estavam em red teaming final. Nossa primeira análise tratava do que uma empresa herda quando roda por conta própria um modelo de 501 bilhões de parâmetros. Em 16 de outubro os pesos chegaram, e a pergunta mudou de lugar: não é se você consegue rodar o Beam, mas por qual caminho de servir você está pagando.
O que foi lançado
O Beam está no Hugging Face sob Apache 2.0 em três precisões, BF16, FP8 e NVFP4, mais um modelo drafter pequeno para decodificação especulativa, com model card e um relatório técnico de segurança. A arquitetura é a anunciada: um mixture of experts esparso com 501 bilhões de parâmetros totais e cerca de 23 bilhões ativos por token. Os posts da AWS e do Google dão a janela de contexto como cerca de um milhão de tokens.
O Reflection também lançou o Mirror, um harness de linha de comando de código aberto para rodar o Beam como agente de código. Ele permite ao desenvolvedor inspecionar o que o agente está fazendo, aprovar chamadas de ferramenta, conduzir o agente no meio da tarefa e rodar agentes em paralelo em worktrees Git separados, e é estendido por instruções de projeto, skills, conexões MCP e Python. Mais de vinte plataformas anunciaram suporte no dia do lançamento, entre elas AWS, Google Cloud, Microsoft Foundry, Databricks, Oracle e Cloudflare, além de Dell e HPE para deploy on-premises. As receitas de autodestilação estão prometidas “nos próximos dias”.
Três precisões são três decisões de qualidade
A precisão que você escolhe não é só uma decisão de hardware. Na AWS, os pesos em FP8 rodam em instâncias H100 ou H200 (ml.p5.48xlarge, ml.p5e.48xlarge, ml.p5en.48xlarge), o NVFP4 roda em B200 (ml.p6-b200.48xlarge) e o BF16 exige uma configuração multi-node. Como aritmética grosseira, 501 bilhões de parâmetros ocupam cerca de um terabyte em 16 bits, cerca de metade disso em 8 bits e cerca de um quarto em 4 bits, antes do KV cache que sessões longas de agente enchem.
A orientação da própria AWS é rechecar a qualidade da saída depois de mudar a precisão. É o instinto certo: um modelo em 4 bits que cabe em menos GPUs é outro modelo do ponto de vista de avaliação. Rode seu conjunto de avaliação de código na precisão que você vai servir de fato, não na que o benchmark usou. Quem pensa no SageMaker JumpStart esbarra numa restrição prática: no lançamento, ele cobre apenas US East (N. Virginia) e US East (Ohio), sem a região de São Paulo, então prompts e código seriam processados nos Estados Unidos. Já o HyperPod roda em qualquer região que ofereça as instâncias de GPU necessárias, e cabe ao time confirmar São Paulo antes de planejar.
| Quem opera | O que você escolhe | O que você ainda precisa provar | |
|---|---|---|---|
| API do Reflection ou um parceiro hospedado | O provedor | Plano e região | Qualidade nas suas tarefas, termos de dados |
| SageMaker JumpStart | A AWS gerencia o endpoint | Tipo de instância e precisão | Qualidade naquela precisão, cota de capacidade |
| GKE com llm-d ou Dynamo | Seu time de plataforma | Roteamento, cache, desagregação | Throughput e latência no seu tráfego |
| Seu próprio data center (Dell, HPE) | Você, de ponta a ponta | Tudo | Tudo, mais patching |
Por que a camada de serving agora pesa tanto quanto o modelo
O post do Google é o documento mais instrutivo do lançamento, se lido com atenção. No GKE, o Google reporta até 5x mais throughput e 8x menos latência usando NVIDIA Dynamo com SGLang em 32 GPUs GB300, e até 2x mais throughput e 8x menos latência usando llm-d com vLLM em oito GPUs RTX PRO 6000. Os dois números comparam com um deploy simples no mesmo hardware, com roteamento round-robin sem estado, numa carga de trabalho de código agêntico com múltiplos turnos. O número de 5x está marcado como baseado em benchmark de cliente, e as duas configurações não são comparáveis entre si.
Os ganhos vêm de três técnicas: rotear cada sessão de múltiplos turnos de volta para a réplica que já guarda o KV cache dela, separar a fase de processamento de prompt da geração de tokens para que rajadas de prompts longos não travem a saída, e levar o KV cache para a memória do host e o SSD local. Nenhuma delas muda o modelo. Todas mudam quanto custa uma tarefa de código concluída.
Isso importa porque agentes de código são o pior caso para serving ingênuo. Uma sessão manda um contexto longo e crescente a cada turno. Sem roteamento com consciência de cache, cada turno pode cair numa réplica que precisa processar de novo todo o histórico. Os mesmos pesos, nas mesmas GPUs, podem portanto custar várias vezes mais por tarefa dependendo de uma decisão de roteamento que o seu time de plataforma toma, que é o ponto que fizemos sobre precificar inferência por tarefa concluída.
Duas ressalvas. Os números do Google são “até” contra uma linha de base fraca, e os ganhos crescem com o tamanho do deployment, então um piloto pequeno não vai vê-los. E a afirmação do Reflection de 3x a 4x menos tokens de raciocínio que modelos abertos comparáveis é do próprio Reflection; teste nas suas tarefas antes de ela virar business case.
O que fazer com o lançamento
Para times que avaliaram o Beam a partir do anúncio, o trabalho agora é concreto. Escolha o caminho da tabela por quem deve operar o modelo. Escolha uma precisão e avalie naquela precisão. Se você faz self-host, trate roteamento com consciência de KV cache como requisito para tráfego de agente, não como otimização. E olhe as aprovações de chamada de ferramenta do Mirror antes de apontar seus desenvolvedores para um repositório com credenciais de produção: um harness aberto é útil justamente porque você consegue ver e definir onde ele para para perguntar.