Revolut e GLM-5.3: custos da hospedagem própria e da API

Para a maioria das equipes que avaliam o GLM-5.3 auto-hospedado da Revolut, o primeiro passo deve ser um piloto com API cobrada por uso. Mantenha uma rota para um modelo de ponta nas tarefas que não passarem pelos seus critérios de qualidade. Considere a hospedagem dedicada somente quando seu tráfego, seus requisitos de latência e seus custos operacionais justificarem essa escolha.

Os números abaixo separam os resultados declarados pela Revolut das recomendações para sua equipe. A documentação e os preços das APIs foram verificados em 2026-11-09.

O que a Revolut realmente implantou?

A Revolut tornou os modelos GLM abertos a opção padrão para cerca de 2,000 engenheiros e manteve modelos de ponta para exceções. A apresentação no AI Engineer e sua transcrição descrevem a mudança de GLM-5.1 para GLM-5.3. A implantação posterior usava 56 GPUs Nvidia B200.

O slide com métricas operacionais também cita a Together. Isso não permite afirmar que a Revolut comprou 56 placas para instalar em suas próprias instalações. O slide identifica um parceiro, não o proprietário do hardware nem o acordo operacional completo.

O endpoint do modelo e o cliente de programação são escolhas separadas. Não condicione a troca de modelo à substituição de todos os clientes. Na arquitetura descrita, o GLM atende às tarefas baseadas em texto. Um roteador encaminha a interpretação de imagens para um modelo com capacidade visual.

Os números de produtividade também precisam de contexto. Abitbol relatou uma melhora de cerca de 60% no tempo de programação e de 70% no prazo de entrega, ou lead time. Porém, o slide sobre adoção indica uma melhora de 60% no lead time.

Trate esses dados como tendências internas relatadas, não como um teste controlado entre GLM e Claude. Eles não demonstram que apenas a troca do modelo causou a melhora.

O que a redução de custos de 90% mede?

A manchete compara as faturas de inferência relatadas pela Revolut. Não compara o custo total de empregar seus engenheiros nem de possuir a infraestrutura. O relato oficial da palestra descreve uma fatura próxima de um décimo do gasto anterior com provedores de modelos de ponta. Pagar um décimo da fatura anterior equivale a uma redução de 90%.

Separadamente, a reportagem do The Register atribui $0.30 por milhão de tokens de entrada/saída à fase de GLM-5.1 da Revolut. Mantenha esse valor histórico por token separado da redução relatada nas faturas. Ele não é uma tarifa pública da API de GLM-5.3 nem uma franquia de assinatura do Claude Code ou do Codex.

O slide operacional também informa que os tokens em cache eram gratuitos. No entanto, o relato não fornece volumes de tráfego e períodos de faturamento equivalentes. Também falta o detalhamento dos custos operacionais necessário para reconstruir um valor completo. Não apresente $0.30 como custo total de propriedade com toda a amortização incluída.

Antes de comparar uma proposta de hospedagem, pergunte o que entra no numerador do custo por token. Verifique aluguel ou depreciação das GPUs, servidores auxiliares, rede, armazenamento, energia, suporte e trabalho de engenharia. Confira quais cobranças já estão incluídas para não contá-las duas vezes.

Depois, defina o denominador. Entrada nova, leituras de cache e saída gerada são categorias diferentes de cobrança. Uma média que inclui leituras gratuitas de cache não pode ser comparada diretamente com a tarifa de entrada sem cache.

Por que usar contexto de 256K e buscar o primeiro token em menos de três segundos?

Use 256K como um orçamento de contexto a testar, não como o limite de GLM-5.3. A documentação atual da Z.ai informa entrada somente de texto e uma janela de contexto de 1M tokens.

A frase de Abitbol, “contexto longo é uma fraude”, descreve uma escolha prática na operação do modelo. Requisições maiores exigem mais armazenamento de contexto e processamento de entrada. Em um conjunto fixo de GPUs, isso reduz o espaço para sessões simultâneas.

Suas metas práticas eram menos de três segundos até o primeiro token e cerca de 200 tokens gerados por segundo. Elas descrevem a experiência desejada pela Revolut. Não garantem que toda requisição nova de 256K tokens termine de processar a entrada em três segundos.

No piloto, meça separadamente requisições sem cache prévio e requisições que reutilizam contexto em cache. Registre a mediana e o percentil 95 da latência com concorrência normal e de pico. Meça também o tempo para concluir a tarefa. A velocidade de geração não inclui o tempo de execução dos testes nem a espera pelas ferramentas.

Comece pelos arquivos relevantes e pelas informações recuperadas, em vez de preencher toda a janela disponível. Reserve espaço para a saída. Aumente o orçamento de contexto apenas quando os resultados das tarefas aceitas justificarem o custo ou o atraso adicional.

Quais partes exigem GPUs e trabalho de operação?

Reproduzir o desempenho da Revolut exige ajustes para a carga de trabalho, não apenas carregar os mesmos pesos do modelo. O slide de desempenho mostra o tempo até o primeiro token caindo de 14.26 para 1.68 segundos. O conjunto de 56 GPUs B200 permaneceu o mesmo.

Isso representa uma redução de aproximadamente 88% na espera pelo primeiro token. Não demonstra que todas as tarefas de programação ficaram 88% mais rápidas.

A palestra aborda quantização FP4 e a separação entre prefill e decode. Prefill processa a entrada. Decode gera os tokens de saída. Essas escolhas de infraestrutura exigem testes de capacidade e alguém responsável por regressões.

As 56 placas também não são o requisito mínimo para carregar GLM-5.3. A receita atual do vLLM documenta uma implantação FP8 em um único nó com oito GPUs H200 ou H20. Essa configuração menor não promete a concorrência, a latência nem a estrutura de custos da Revolut.

Para um piloto de hospedagem dedicada, peça a reprodução de sessões representativas do agente no hardware proposto. Fixe a versão dos pesos, a precisão, o orçamento de contexto e a concorrência de pico. Exija resultados aprovados nas tarefas e latência aceitável antes de ampliar a capacidade.

O que uma equipe pode copiar sem 56 GPUs?

Copie a política de modelo padrão e o método de avaliação antes da infraestrutura. O roteiro a seguir é uma proposta de piloto, não uma reconstrução da configuração privada da Revolut.

Selecione 20 tarefas representativas dos seus repositórios, como correções de bugs, testes, refatorações e alterações na documentação. Execute GLM-5.3 e o modelo atual a partir dos mesmos commits iniciais. Mantenha o cliente, as permissões das ferramentas, os testes de aceitação e os critérios de revisão.

Use uma cópia de trabalho separada para cada execução. Uma tarefa bem-sucedida deve ler os arquivos necessários, produzir uma alteração revisável e passar pelas verificações combinadas. Uma resposta plausível no chat não basta.

Defina uma política explícita de roteamento:

• Encaminhe as tarefas comuns de programação baseadas em texto para GLM-5.3.
• Encaminhe tarefas que exigem interpretar imagens para um modelo visual aprovado.
• Após uma tentativa de correção malsucedida, ou um pedido explícito do revisor, passe a tarefa ao modelo de ponta e registre o motivo.

Essa política é um ponto de partida para a avaliação, não uma quantidade ideal de novas tentativas para todos os casos. Mantenha ambas as rotas dentro das regras aprovadas de tratamento de dados e permissões das ferramentas.

Para implementar o roteamento no cliente, consulte o guia de configuração do Claude Code Router. Essa é uma opção de implementação, não uma afirmação de que a Revolut usou esse pacote.

Registre entrada, entrada em cache, saída, tentativas malsucedidas, cobranças pelo uso do modelo de ponta, tempo total e tempo de revisão humana. Compare o gasto total por tarefa aceita. O guia de custo por tarefa de agentes de programação explica por que uma tarifa menor por token não resolve essa comparação.

Adote GLM-5.3 como padrão apenas nas categorias de tarefas que atingirem seu nível mínimo de qualidade. Mantenha a rota atual quando novas tentativas ou revisões adicionais eliminarem a economia.

Quanto custa usar GLM-5.3 por API?

A API padrão da Z.ai oferece uma referência mensurável sem assumir um compromisso com GPUs. Em 2026-11-09, os preços publicados indicavam estas tarifas em USD para GLM-5.3:

Categoria de tokens	Preço por 1 milhão de tokens
Entrada sem cache	$1.40
Entrada em cache	$0.26
Saída	$4.40

O armazenamento da entrada em cache aparece como gratuito por tempo limitado. Não trate essa condição temporária como permanente.

Para uma carga ilustrativa com 100 milhões de tokens de entrada e 10 milhões de saída, a cobrança sem cache seria:

100 × $1.40 + 10 × $4.40 = $184.00

Se 90 milhões desses tokens de entrada forem cobrados como acertos de cache, a estimativa passa a ser:

10 × $1.40 + 90 × $0.26 + 10 × $4.40 = $81.40

Esses são exemplos calculados, não faturas medidas. Eles pressupõem ausência de ferramentas pagas e cobrem apenas os tokens do modelo. A participação de 90% do cache é uma hipótese do exemplo, não uma promessa para sua carga.

Use o campo real da resposta usage.prompt_tokens_details.cached_tokens para identificar a entrada em cache. A Z.ai documenta esse campo no guia de cache de contexto.

O catálogo da BetterToken, verificado em 2026-11-09, também inclui glm-5.3. A integração de GLM com OpenCode usa a URL base compatível com OpenAI https://www.bettertoken.ai/v1. Compare os preços atuais com a proporção de tokens medida na sua carga. Esse acesso por API não reproduz a economia da infraestrutura da Revolut nem inclui uma assinatura de ferramenta de programação.

Para verificar o acesso à Z.ai, crie uma Standard API Key seguindo as instruções de HTTP API. Use uma conta da API padrão com saldo para este exemplo.

Execute o código em Bash, com curl instalado. O primeiro comando espera a chave sem exibir uma mensagem. Cole a chave e pressione Enter; ela não aparecerá na tela.

read -rs ZAI_API_KEY && export ZAI_API_KEY

curl --silent --show-error \
  --write-out '\nHTTP %{http_code}\n' \
  "https://api.z.ai/api/paas/v4/chat/completions" \
  -H "Authorization: Bearer $ZAI_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "glm-5.3",
    "messages": [
      {"role": "user", "content": "Return exactly READY."}
    ]
  }'

A referência de Chat Completion documenta esse endpoint e o formato da resposta. Verifique HTTP 200, conteúdo não vazio em choices[0].message.content e o objeto usage. A resposta esperada é READY. Isso verifica o acesso, não a qualidade da programação nem a execução de ferramentas.

Ao receber HTTP 429, examine o código de erro no JSON antes de tentar novamente. A Z.ai distingue 1113, saldo insuficiente ou ausência de pacote de recursos, de 1302, limite de frequência de requisições. No primeiro caso, adicione saldo à conta de API correta; no segundo, reduza a frequência. Esses significados são específicos da referência de erros da Z.ai.

O ponto de equilíbrio de 35% de Yingjun Wu se aplica à sua equipe?

Não. Wu analisa a venda de inferência de DeepSeek V4.1 Flash, não o uso interno de GLM-5.3 por uma equipe de engenharia.

Na análise atualizada em 2 de novembro de 2026, H200 não cobre o aluguel nem com utilização plena. O cenário com B300 atinge o equilíbrio perto de 35%. No cenário H200, a receita é de cerca de $1.60 por GPU-hour, contra $3.99 de aluguel. Esses valores arredondados resultam em um déficit calculado de $2.39 por hora, antes dos demais custos.

O cálculo exclui banda de rede, pessoal e capacidade de reserva. Trate esses valores como premissas do cenário do autor, não como cotações atuais nem medições reproduzidas aqui.

A lição útil é o método. Para hospedagem interna, substitua a receita com a venda de tokens pelo gasto com API que sua implantação realmente evitaria. Recalcule com seu modelo, proporção de cache, desempenho alcançável, verificações de qualidade e latência necessária.

Qual opção de implantação escolher?

Escolha acesso por API com cobrança por uso quando a demanda for incerta ou faltarem especialistas em operação de inferência. Reavalie quando medições repetidas mostrarem que o gasto evitado com API cobre uma proposta completa de hospedagem.

Teste capacidade dedicada em um provedor quando a demanda for estável, mas possuir e operar o hardware não for seu objetivo. Exija que o contrato defina quem cuida de atualizações, limites de capacidade, falhas, localização dos dados e suporte. Continue pagando por uso quando o compromisso exigido superar sua utilização realista.

Opere sua própria infraestrutura de inferência quando os requisitos de controle justificarem essa escolha e houver uma equipe capaz de mantê-la. Reverta a decisão se a latência no pico, as regressões de qualidade ou os custos com pessoal eliminarem o benefício esperado.

Antes de assinar, exija uma comparação por tarefa aceita, uma reprodução da carga de pico e um orçamento mensal completo. Nomeie um responsável pela operação. Inclua capacidade ociosa e exceções encaminhadas aos modelos de ponta. Use o modelo de custo total de propriedade para equipes para fechar o orçamento, em vez de adotar o valor histórico de GLM-5.1 da Revolut como sua previsão.