Velocidade de Inferência do GLM-5 no WaveSpeed: Latência e Throughput

Queria uma resposta rápida enquanto redigia um e-mail de integração. O GLM-5 parecia inteligente, mas o primeiro token demorou o suficiente para eu me pegar olhando fixamente para o cursor. Não foi uma crise, apenas uma pequena pausa que ficava se repetindo. Esse é geralmente o meu sinal para verificar o que está realmente acontecendo.

Sou Dora. Fiz um conjunto simples de testes para ver o quanto conseguia extrair de velocidade de inferência do GLM-5 sem transformar meu fluxo de trabalho em um projeto científico. Nada sofisticado, apenas o suficiente para sentir a diferença no trabalho real, não em laboratório.

Metodologia de teste (hardware, configurações, tamanhos de prompt)

Experimentei três caminhos de acesso:

• ​WaveSpeed​: uma camada de aceleração leve que venho testando e que gerencia o molde de requisições e cache no lado do cliente/gateway.
• ​API Z.ai direta: o caminho direto para o GLM-5 via provedor.
• ​OpenRouter​: um intermediário que encaminha para o provedor do modelo com alguns recursos extras.

Hardware e contexto

• Cliente local: MacBook Pro (M2 Max, 64 GB de RAM). Rede em fibra estável (≈500 Mbps de download, ≈30 ms para endpoints comuns nos EUA).
• Lado do servidor: sem servidor personalizado, apenas chamadas de cliente, exceto o WaveSpeed, que executa um pequeno gateway local para gerenciar cache e molde de lotes.

Configurações que mantive constantes, salvo indicação em contrário

• Modelo: GLM-5 (chat/completions), temperature 0.2, top_p 0.9, max_tokens 512.
• Streaming ativado, porque é assim que trabalho de verdade.
• Novas tentativas desativadas, exceto para erros de rede.

Prompts utilizados

• Curto: 60–80 tokens (uma instrução concisa com 2–3 restrições).
• Médio: ~350 tokens (rascunho de e-mail com notas de marca e exemplos).
• Longo: ~1.500 tokens (um pequeno briefing com contexto de produto, notas de tom e listas de fazer/não fazer).

Executei 25 iterações por condição e registrei:

• Tempo até o primeiro token (TTFT): do envio da requisição ao primeiro token transmitido.
• Throughput (tokens/s): taxa de saída em streaming após o início dos tokens.
• Um alternador para “modo de raciocínio” (rastros de raciocínio do provedor).

Métricas principais

Tempo até o primeiro token (TTFT)

Prompts curtos ficaram entre 250–400 ms nas melhores rotas. Prompts médios empurraram o TTFT para mais perto de 450–700 ms. Prompts longos ultrapassaram um segundo, a menos que o cache entrasse em ação. O salto não foi linear: parecia que a sobrecarga de fila e validação importava tanto quanto o tamanho do prompt.

Minha reação: abaixo de 400 ms parece ágil; qualquer coisa acima de um segundo me tira do fluxo. Quando estou editando um texto ao vivo, esse primeiro token importa mais do que o throughput final.

Tokens por segundo (throughput)

Uma vez iniciado o streaming, observei 35–70 tok/s em execuções sem raciocínio. Isso é confortavelmente rápido para textos, no limite para diffs de código. O throughput caiu em saídas mais longas, o que suspeito ser moldagem do lado do servidor e verificações de segurança, em vez de velocidade pura do modelo.

Modo de raciocínio vs. modo sem raciocínio

Com o “raciocínio” ativado, o TTFT aumentou 30–80%, e o throughput caiu pela metade em alguns casos. O texto foi mais coerente em prompts difíceis, mas para rascunhos do dia a dia não precisei disso. Não economizou tempo de início, mas após algumas execuções percebi que reduziu o esforço mental em edições complexas. Em tarefas simples, deixo desativado.

Como a aceleração do WaveSpeed se aplica ao GLM-5

O WaveSpeed não tocou nos pesos do modelo. Ele fez duas coisas simples e úteis do meu lado da conexão: reduziu o trabalho redundante e moldou as requisições para que o provedor pudesse responder mais rápido. No GLM-5, isso se traduziu em um TTFT melhor em prompts repetidos e pequenos ganhos em prompts médios.

ParaAttention e técnicas de cache

• ParaAttention (minhas notas): Em vez de agrupar requisições não relacionadas, o WaveSpeed paraleliza fragmentos favoráveis à atenção dentro de um único prompt longo quando detecta scaffolding repetido. Na prática, reutilizou o prelúdio (sistema + exemplos compartilhados) e só enviou o delta. Não consigo verificar os internos, mas o efeito pareceu uma reutilização parcial de KV no nível do gateway.
• Cache: Memorizou embeddings para o prelúdio do prompt e templates de sistema curtos. Quando iterei na mesma tarefa com pequenas edições, o TTFT caiu ~120–180 ms. Em prompts frios, o benefício foi menor (~40 ms), mas ainda perceptível.

Limitações que encontrei

• A primeira execução a frio ainda é limitada pelo upstream. Sem milagres.
• Se eu mudasse mais de ~20% do prompt, o cache não ajudava.
• O modo de raciocínio neutralizou amplamente os ganhos: o rastro de raciocínio se comportou como um stream separado.

Comparação: WaveSpeed vs. API Z.ai direta vs. OpenRouter

É aqui que as pequenas diferenças importam.

• API Z.ai direta: Consistente. Menor variância no TTFT. Quando precisei de inícios previsíveis para demonstrações, essa foi minha escolha. Em prompts longos, a penalidade de TTFT foi real, mas estável.
• OpenRouter: TTFT ligeiramente maior em média, um pouco mais de variância, mas configuração fácil e flexibilidade de roteamento. Bom quando estou alternando entre modelos. A documentação é sólida: veja os guias do OpenRouter.

• Camada WaveSpeed: Melhor TTFT em prompts quentes e entradas médias, provavelmente por cache e moldagem de requisições. Em prompts longos verdadeiramente frios, empatou com o direto.

Nenhuma dessas opções alterou o comportamento principal do GLM-5. Mudaram a rapidez com que senti o modelo “acordar” e o quão suave foi a iteração.

Se você está decidindo:

• Precisa de desempenho estável e menos partes móveis? Vá direto pelo provedor. Referência: a documentação da API ZhipuAI.
• Precisa de roteamento multi-modelo ou chaves compartilhadas entre ferramentas? O OpenRouter funciona bem; aceite alguns milissegundos extras.
• Iterando em prompts semelhantes o dia todo? Uma camada de aceleração leve compensa mais em tranquilidade mental do que em velocidade bruta.

Dicas de otimização para cargas de trabalho em produção

O que realmente ajudou na prática:

• Aqueça o prelúdio: Mantenha os prompts de sistema e exemplos compartilhados estáveis. Faça cache deles, mesmo no lado do cliente. Minha economia de TTFT: ~100–200 ms em repetições.
• Corte a cauda: Limite o max_tokens ao que você realmente precisa. Reduzir um limite de 1.000 tokens para 400 cortou 10–20% do tempo total nos meus rascunhos.
• Prefira novas tentativas estruturadas: Se precisar tentar novamente, retome os streams; não os reinicie. Novas tentativas cegas arruinaram o TTFT.
• Controle a variabilidade: temperature ≤0.3 em produção. Menor entropia reduziu as passagens no servidor e tornou o throughput mais estável.
• Adie o modo de raciocínio: Ative-o apenas em prompts que historicamente falham. Mapeio os “prompts difíceis” e altero o flag por rota.
• Divida contextos longos antes: Resuma as referências uma vez, armazene o resumo e reutilize. A segunda e terceira execuções parecem dramaticamente mais leves.
• Atenção à tokenização: SDKs diferentes tokenizam de forma ligeiramente diferente. Fixe o cliente e meça novamente: vi regressões fantasmas só por causa disso.
• Meça p95, não apenas p50: Caudas com picos causam a latência visível que os usuários se lembram.

Dados brutos de benchmark (tabela)

Aqui está o instantâneo das minhas execuções (25 iterações por linha). Todos os números são aproximados, mas representativos do que senti no teclado.

Notas

• “Prelúdio quente” significa que o sistema + exemplos compartilhados foram armazenados em cache pelo gateway.
• O throughput é medido após o primeiro token. Tempo total = TTFT + tokens_saída / throughput.
• A rede estava estável: quando testei em Wi-Fi de hotel, tudo ficou pior em 10–20%.

Uma última observação: reduzir 150 ms do TTFT importou mais para mim do que adicionar 5 tok/s, porque reduziu a pequena espera que aciona a troca de contexto. Essa não é uma regra universal, apenas a forma como meu cérebro lida com streams.