O que é o GLM 5.3 e por que ele importa
Tarefas de codificação e fluxos de trabalho agênticos estão exigindo cada vez mais dos modelos de IA: refatorar repositórios com centenas de arquivos, sustentar pipelines de execução autônoma por horas sem perder contexto e raciocinar sobre sistemas complexos com uso de ferramentas em cada etapa. Historicamente, atender a essas demandas com modelos de pesos abertos significava provisionar e operar a própria infraestrutura de inferência.
A AWS anunciou que o GLM 5.3 da Z.ai (Zhipu AI) está agora disponível no Amazon Bedrock. Publicado no Hugging Face Hub, o GLM 5.3 é um modelo de mistura de especialistas (MoE) com 753 bilhões de parâmetros, otimizado para codificação e tarefas agênticas de longa duração. A Z.ai também reportou capacidades notáveis em segurança cibernética. No Amazon Bedrock, o modelo é acessado via APIs totalmente gerenciadas, com inferência entre regiões, cache de prompt e camadas de serviço — sem necessidade de gerenciar infraestrutura. O acesso ao GLM 5.3 no Bedrock está disponível para clientes empresariais elegíveis.
O que mudou em relação ao GLM 5
O GLM 5 já estava disponível no Amazon Bedrock anteriormente. O GLM 5.3 evolui a mesma linhagem com melhorias relevantes em três frentes:
- Codificação mais forte: A Z.ai afirma desempenho competitivo em benchmarks como DeepSWE, Terminal Bench 3.0 e FrontierSWE, além de uma melhoria de 50% sobre o GLM 5.2 em seu benchmark interno de codificação. Comparações diretas com o GLM 5 não foram divulgadas porque a magnitude das melhorias levou à atualização dos próprios testes de benchmark desde o anúncio do GLM 5.1.
- Capacidades emergentes em segurança cibernética: O desempenho reportado em tarefas de segurança é um diferencial, tornando o modelo adequado para fluxos de segurança defensiva. Por exemplo, a Z.ai mediu uma pontuação de 84,5 no benchmark CyberGym no lançamento.
- Integração mais ampla com o Amazon Bedrock: Suporte a perfis de inferência entre regiões, cache de prompt implícito e explícito, e melhor paridade de recursos nas APIs compatíveis com OpenAI (Respostas e Completions de Chat), além das APIs Invoke e Converse nativas do Bedrock.
Principais capacidades
Codificação de fronteira e desempenho agêntico
O GLM 5.3 foi projetado para engenharia de sistemas complexos e tarefas agênticas de longa duração, incluindo raciocínio em múltiplas etapas, fluxos de trabalho com uso de ferramentas e manutenção de contexto em grandes bases de código.
Acesso flexível por API
O modelo pode ser invocado pelas APIs compatíveis com OpenAI (Responses e Chat Completions), ou pelas APIs nativas do Amazon Bedrock (Invoke e Converse).
Cache de prompt
O GLM 5.3 suporta cache de prompt implícito (automático) por padrão e controles de cache explícito nas APIs Responses e Chat Completions. Para fluxos agênticos que reenviam grandes prompts de sistema ou contexto de repositório a cada turno, o cache reduz tanto a latência quanto o custo de tokens de entrada.
Inferência entre regiões
O modelo está disponível por meio de perfis de inferência entre regiões dos EUA (us.zai.glm-5.3) e global (global.zai.glm-5.3). As requisições são enviadas para a região AWS de origem escolhida, e o Amazon Bedrock roteia cada chamada de forma segura. Consulte o Guia do Usuário do Amazon Bedrock para mais detalhes.
Camadas de serviço
É possível escolher entre três opções: Flex para otimizar custo em cargas menos sensíveis ao tempo, Priority para priorizar requisições com latência crítica (com preço mais alto) e Standard para o equilíbrio padrão entre preço e velocidade.
Como começar a usar
Pré-requisitos
Para os exemplos de uso a seguir, são necessários:
- Uma conta AWS com acesso ao Amazon Bedrock.
- Permissões de Gerenciamento de Identidade e Acesso (IAM) para chamar o modelo base e o perfil de inferência de destino:
bedrock:InvokeModel,bedrock:InvokeModelWithResponseStreamebedrock:CallWithBearerToken. - Python 3.10 ou superior (para os exemplos baseados em código).
- Docker e Strix com o extra bedrock instalados (apenas para o demo opcional de testes de segurança).
Testando pelo console do Amazon Bedrock
É possível começar a enviar prompts ao GLM 5.3 diretamente pelo Console de Gerenciamento da AWS, sem precisar escrever código ou instalar ferramentas de desenvolvimento. Basta navegar até o Amazon Bedrock e escolher Test > Playground no menu lateral. A partir daí, selecione o GLM 5.3 na lista de modelos e envie os primeiros prompts pela interface de chat.
Primeiros passos com a API Responses
Via código, o modelo pode ser chamado pelo endpoint bedrock-runtime, que suporta as APIs compatíveis com OpenAI e as APIs nativas do Bedrock. Para novas aplicações, as APIs compatíveis com OpenAI são recomendadas por oferecerem um conjunto mais completo de funcionalidades.
O Amazon Bedrock suporta a geração de chaves de API para integrações que as exijam. No entanto, a recomendação é preferir credenciais de curta duração em vez de chaves de longa duração.
No exemplo abaixo, a API Responses é chamada a partir do Python usando o SDK do OpenAI e a biblioteca aws-bedrock-token-generator para gerar tokens de curta duração a partir das credenciais padrão da Interface de Linha de Comando da AWS (AWS CLI).
Instale os pacotes necessários:
pip install -U openai aws-bedrock-token-generatorSalve o código a seguir como bedrock-request.py:
from aws_bedrock_token_generator import provide_token
from openai import OpenAI
region = "us-west-2" # Your source AWS Region
client = OpenAI(
api_key=provide_token(region=region),
base_url=f"https://bedrock-runtime.{region}.amazonaws.com/openai/v1",
)
resp = client.responses.create(
input="Refactor this Python function to be iterative instead of recursive: ...",
model="global.zai.glm-5.3",
)
print(resp.output_text)Execute o script para ver a saída do modelo:
python bedrock-request.pyOtimizando a inferência com cache de prompt explícito
Fluxos de trabalho de codificação e conhecimento de longa duração frequentemente reenviam contexto estável a cada turno da conversa — como prompts de sistema, definições de ferramentas ou arquivos de repositório. O GLM 5.3 no Amazon Bedrock suporta cache de prompt implícito por padrão, reduzindo latência e custo de tokens de entrada para chamadas repetidas que compartilham o mesmo prefixo inicial de prompt.
Com o modo de cache de prompt explícito, é possível identificar especificamente os prefixos reutilizáveis, o que pode melhorar ainda mais a taxa de acerto do cache em relação ao modo implícito.
Para usar o cache explícito com o GLM 5.3:
- Selecione o modo de cache explícito via
prompt_cache_optionsna requisição. - Adicione um ou mais marcadores
prompt_cache_breakpointnos blocos de conteúdo de entrada para indicar o fim (inclusive) dos prefixos reutilizáveis. Cada ponto de quebra deve conter pelo menos 1.024 tokens para ser elegível ao cache.
resp = client.responses.create(
model="global.zai.glm-5.3",
# Enable explicit caching mode:
extra_body={"prompt_cache_options": {"mode": "explicit"}},
input=[
{
"type": "message",
"role": "system",
"content": [
{
"type": "input_text",
"text": SYSTEM_PROMPT,
# A long, static system prompt is a great target for caching:
"prompt_cache_breakpoint": {"mode": "explicit"},
},
]
},
{
"type": "message",
"role": "user",
"content": [
{
"type": "input_text",
"text": USER_INPUT,
# Multiple breakpoints can also be defined, for layered cache:
"prompt_cache_breakpoint": {"mode": "explicit"},
},
],
},
],
)
if resp.usage.input_tokens_details.cached_tokens:
print("Hit cache!")Para mais informações, consulte a seção de cache de prompt do Guia do Usuário do Amazon Bedrock.
Caso de uso agêntico: testes de segurança autorizados com o Strix
Um dos casos de uso que se beneficia diretamente dos pontos fortes do GLM 5.3 é a automação de testes de segurança em aplicações próprias. O Strix é um agente de teste de penetração de código aberto que executa código dinamicamente, encontra vulnerabilidades e as valida com testes de prova de conceito. No momento da publicação do post original, a documentação do Strix já usa o GLM 5.3 como modelo padrão.
É possível configurar o Strix para usar o GLM 5.3 no Amazon Bedrock em vez de um provedor de inferência terceiro, mantendo a inferência do modelo sob os controles da conta AWS.
Importante: teste apenas aplicações que você possui ou para as quais tem permissão escrita explícita. Testes de segurança não autorizados em sistemas de terceiros são ilegais na maioria das jurisdições e violam a Política de Uso Aceitável da AWS.
Nesse walkthrough, o alvo é o OWASP Juice Shop, uma aplicação de exemplo intencionalmente vulnerável rodando localmente na máquina.
Para quem busca testes de segurança contínuos e totalmente gerenciados além de rodar agentes de código aberto, o AWS Continuum oferece testes de penetração sob demanda e outras análises de segurança como serviço gerenciado. As duas abordagens são complementares: agentes de código aberto como o Strix oferecem testes orientados pelo desenvolvedor, com alto grau de customização contra builds locais, enquanto o AWS Continuum executa avaliações gerenciadas em escala.
Executando um teste de segurança autorizado
Inicie a aplicação Juice Shop localmente:
docker run --rm -p 3000:3000 bkimminich/juice-shopConfigure o Strix para usar o GLM 5.3 no Amazon Bedrock. O Strix utiliza o LiteLLM internamente, então as credenciais da AWS CLI são capturadas automaticamente (conforme descrito na documentação do Strix para Amazon Bedrock). Nenhuma chave de API é necessária, mas pode ser útil definir variáveis de ambiente como AWS_PROFILE e AWS_REGION.
No momento da publicação, o LiteLLM ainda não resolve bedrock/global.zai.glm-5.3. Até que isso seja corrigido, é possível especificar explicitamente a rota da API Converse e o ARN (Nome do Recurso Amazon) do perfil de inferência:
# Fill in the REGION and ACCOUNT_ID placeholders below before running!
export STRIX_LLM="bedrock/converse/arn:aws:bedrock:{AWS_REGION}:{AWS_ACCOUNT_ID}:inference-profile/global.zai.glm-5.3"Execute o Strix contra o alvo local:
strix --target http://localhost:3000Aguarde o agente raiz do Strix concluir e revise os resultados. O Strix cria uma equipe de sub-agentes para mapear a superfície de ameaças, explorar categorias de vulnerabilidades e tentar validar cada achado com uma prova de conceito funcional. Isso ajuda a minimizar o tempo gasto na triagem de falsos positivos. Uma execução bem-sucedida gera um relatório com severidade, evidências e orientações de remediação para cada achado.
Limpeza do ambiente
Encerre o container do Juice Shop com Ctrl+C no terminal onde ele está rodando, ou execute docker ps para encontrar o ID do container e encerrá-lo com docker stop <container-id>. A inferência no Amazon Bedrock é cobrada por token, sem recursos persistentes, portanto não há cobranças adicionais após a conclusão das requisições. Se uma chave de API do Amazon Bedrock foi gerada para este walkthrough e não é mais necessária, exclua-a pelo console.
Disponibilidade
O GLM 5.3 já pode ser testado no console do Amazon Bedrock, utilizado via assistentes de codificação como o OpenCode (conforme demonstrado no post recente com o Kimi K3), ou integrado a aplicações customizadas pelas APIs suportadas.
Fonte
Introducing GLM 5.3 on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/introducing-glm-5-3-on-amazon-bedrock/)
Leave a Reply