A ação da Zhipu AI sobe 26% após o lançamento da API de 400 tokens/s

Texto | AIDeepDive

Hoje, o "primeiro stock global de grandes modelos", Zhipu (02513.HK), subiu novamente fortemente.

A alta intradiária chegou a superar 30%. Fechou em 1.282 dólares de Hong Kong, com ganho superior a 26% no dia, e capitalização de mercado atingiu 571,57 bilhões de dólares de Hong Kong, estabelecendo novo recorde histórico.

O que desencadeou esta alta foi um indicador técnico específico: 400 tokens/s.

Em 22 de maio, Zhipu lançou oficialmente a API GLM-5.1-highspeed para clientes corporativos, com o parâmetro central mais importante sendo apenas um: a velocidade de saída do modelo atinge 400 tokens por segundo, superando o limite superior de velocidade de API de todos os fornecedores de modelos grandes do mundo.

Eu originalmente pensei que se tratava apenas de mais uma campanha de relações públicas de um grande modelo nacional, mas após analisar detalhadamente os aspectos técnicos, finalmente compreendi a lógica por trás dos mercados financeiros.

O que significa 400 tokens/s?

O modelo pode gerar aproximadamente 200 caracteres chineses por segundo, o que equivale à produção intensa de um escritor profissional em um minuto, comprimida em um único segundo.

A quantidade de texto que um criador leva vários dias seguidos para escrever, o GLM-5.1 versão de alta velocidade entrega em 1 minuto; uma tarefa de reestruturação de sistema que um engenheiro leva três dias para concluir, ele conclui no tempo de tomar uma xícara de café.

A velocidade, historicamente, é a dimensão mais negligenciada na competição entre modelos de IA.

Nos últimos três anos, a corrida armamentista de grandes modelos concentrou-se em duas trilhas: escala de parâmetros (modelos maiores e mais inteligentes) e guerra de preços (tokens mais baratos e mais acessíveis). "Rapidez" nunca foi o protagonista.

Isso ocorre porque, no passado, a “velocidade” geralmente era alcançada reduzindo os parâmetros do modelo. Para acelerar, era necessário usar modelos menores e mais simplificados, com a consequência de uma redução na capacidade.

A versão de alta velocidade do GLM-5.1 tem como significado nesta ocasião manter a capacidade de base de tamanho completo de topo, ao mesmo tempo em que aumenta a velocidade para 400 tokens/s.

Pela primeira vez, tanto em termos de modelos nacionais quanto em termos globais, "capacidade旗舰" e "latência mínima extrema" foram alcançadas sem compromissos.

Por que a velocidade é tão crítica? Porque o campo de batalha principal da IA está passando por uma migração fundamental.

Quando a IA passa do era ChatBot para o era Agent, perguntas e respostas já não são o cenário principal da IA; para concluir uma tarefa, um Agent frequentemente precisa realizar dezenas ou até centenas de chamadas internas ao modelo: escrever código, chamar APIs, pesquisar informações, usar ferramentas...

Neste modo de operação, o atraso entre cada chamada é acumulado e amplificado de forma implacável. Uma tarefa que exige 50 chamadas, se economizar 1 segundo em cada uma, será concluída quase 1 minuto mais rápido. Para assistentes de programação por IA, interações por voz e sistemas de tomada de decisão comercial, essa diferença pode ser decisiva.

Em um nível mais profundo, uma inferência mais rápida dentro de um orçamento de tempo fixo significa que o modelo pode percorrer caminhos de inferência mais profundos e realizar mais rodadas de validação própria. A velocidade está se transformando de uma métrica do sistema em um limite intrínseco da inteligência.

Qual é o nível atual da indústria em termos de velocidade?

Entre os principais fabricantes, o GPT-4o da OpenAI opera em cerca de 100–150 tokens/s, a série Claude Sonnet da Anthropic em cerca de 80–120 tokens/s, e a maioria dos principais modelos locais tem APIs na faixa de 50–100 tokens/s. 400 tokens/s é aproximadamente 3 a 5 vezes a média do setor.

Mais importante ainda, essa lacuna não pode ser compensada apenas com mais poder de processamento.

Um servidor equipado com oito GPUs H200 pode, teoricamente, transferir até 38 TB de dados por segundo. Para o GLM-5.1, a geração de um único token requer a leitura de aproximadamente 42 GB de parâmetros de ativação; com base nesse cálculo teórico puro, deveria ser possível alcançar cerca de 1000 tokens/s.

Mas sistemas reais geralmente conseguem processar apenas dezenas de tokens/s.

É uma lacuna de ordem de grandeza. O GPU não é lento demais, mas sim gasta grande parte do tempo esperando, ocioso e com agendamentos ineficazes.

ZhiPu está inovando simultaneamente em três níveis — motor de inferência, estratégia paralela e arquitetura de rede — alcançando uma ruptura na velocidade final.

Os grandes modelos funcionam assim: são divididos em operadores individuais, cada um dos quais inicia separadamente um núcleo de cálculo (kernel), conclui o cálculo, aguarda sincronização e, em seguida, inicia o próximo.

Durante a fase de treinamento, cada cálculo leva vários segundos ou até minutos, então esses custos de inicialização e espera podem ser totalmente ignorados. Mas durante a inferência, ao gerar um único token por vez, um passo crítico pode levar apenas dezenas de microssegundos, tornando os custos de inicialização e espera relativamente significativos.

A ideia central do TileRT: compilar todo o modelo em um motor em execução contínua, iniciado uma vez, nunca parado.

TileRT pré-expande estaticamente toda a lógica de cálculo do modelo em uma única linha de pipeline durante a fase de compilação do código, mantendo a GPU em alta velocidade durante a execução, com cálculos, transferência de dados e comunicação avançando em paralelo, mantendo os resultados intermediários o máximo possível na cache de alta velocidade da GPU, evitando escritas e leituras repetidas na memória de vídeo mais lenta.

Existe um detalhe de design essencial: especialização Warp.

Para entender o Warp, é necessário primeiro compreender como a GPU funciona. A principal diferença entre a GPU e a CPU é que a GPU contém milhares de unidades de cálculo relativamente simples, agrupadas em conjuntos de 32, chamados de Warp.

Os 32 unidades dentro do mesmo Warp devem sempre agir sincronizadamente e executar a mesma instrução, como uma turma de soldados, onde o sargento dá a ordem e todos realizam o mesmo movimento ao mesmo tempo.

No framework tradicional, todos os Warp executam a mesma sequência de instruções; o TileRT atribui funções diferentes a grupos distintos de Warp: um grupo se encarrega de antecipadamente transferir os próximos dados, outro se dedica exclusivamente ao cálculo matemático e um terceiro se ocupa exclusivamente da comunicação com outros GPUs. Os três grupos trabalham simultaneamente, em fluxo contínuo, sem esperar uns pelos outros.

É como passar de "um trabalhador transportando tijolos, construindo paredes e inspecionando sequencialmente" para "equipes de transporte de tijolos, construção de paredes e inspeção operando simultaneamente".

A eficiência dentro de um único cartão foi resolvida, mas o paralelismo múltiplo traz novos desafios.

A prática padrão da indústria é o paralelismo de tensores (Tensor Parallel): dividir as matrizes de pesos do modelo em várias partes, com cada GPU responsável por uma parte, calculando separadamente e depois agregando os resultados por meio de interconexão de alta velocidade (NVLink).

Este esquema funciona muito bem para cálculos densos e regulares, como multiplicação de matrizes, e é a solução padrão de múltiplos GPUs em todos os frameworks de inferência de grandes modelos atuais.

GLM-5.1 utiliza **MLA (Multi-head Latent Attention)**, um mecanismo de atenção proposto pelo DeepSeek.

O mecanismo de atenção tradicional exige salvar completamente todos os dados intermediários calculados a cada passo (KV Cache) para uso futuro, consumindo muita memória gráfica; o método da MLA comprime primeiro esses dados intermediários em um "vetor latente" compacto para armazenamento, expandindo e restaurando quando necessário, reduzindo significativamente a demanda de memória e aumentando a eficiência de inferência.

Mas o processo de cálculo da MLA inclui uma etapa especial: é necessário criar um índice esparsa a partir de grandes volumes de informações históricas: semelhante a encontrar rapidamente alguns livros mais relevantes em uma biblioteca enorme e, em seguida, ler detalhadamente esses livros.

A etapa "procurar o livro" depende de informações globais e não é adequada para distribuição entre múltiplos GPUs; a "leitura detalhada" é o processo adequado para computação densa em paralelo entre múltiplos GPUs. Forçar todas as 8 GPUs a participarem da etapa "procurar o livro" desperdiçará grande parte do tempo em sincronização e comunicação entre GPUs.

A solução da TileRT é fazer o GPU operar de forma heterogênea: o GPU 0 atua exclusivamente como "bibliotecário", responsável pelo índice esparsa e pela tomada de decisões de roteamento; os GPU 1–7 atuam como "analistas de leitura detalhada", responsáveis pelos cálculos densos de atenção e operações matriciais. Os dois tipos de trabalhadores utilizam estratégias de paralelismo otimizadas para cada um, colaborando para concluir toda a camada de cálculo.

Em seguida, o TileRT incorpora diretamente as operações de comunicação entre GPUs na linha de execução, em vez de tratá-las como etapas independentes. Para o usuário externo, todo o sistema de 8 GPUs realiza um único cálculo de atenção com apenas uma inicialização de kernel, com a comunicação e o cálculo internos sendo concluídos seamlessmente dentro da linha de execução contínua.

As duas camadas acima resolvem problemas dentro do escopo de uma única máquina. Quando o cluster é expandido para centenas ou mesmo milhares de GPUs, a transmissão de dados entre as GPUs em si se torna um novo limite.

A prática padrão da indústria é ROFT (Rail-Optimized Fat-Tree), a solução recomendada oficialmente pela NVIDIA e o padrão absoluto do setor.

Sua estrutura é uma árvore: o servidor primeiro se conecta ao switch Leaf inferior (camada de acesso, diretamente voltado para os servidores), e o Leaf, por sua vez, se conecta para cima aos switches Spine (camada principal, responsável pela interconexão entre diferentes Leaf, como um nó rodoviário). Os dados transmitidos entre dois GPUs devem “subir primeiro até o Spine e depois descer até o Leaf de destino”, passando por pelo menos 3 saltos.

Para evitar que o tráfego se concentre em poucas conexões, esta arquitetura depende do algoritmo ECMP para distribuir os dados entre múltiplas rotas, funcionando bem sob a premissa de que o tráfego da internet é "estatisticamente uniforme".

Mas o tráfego nos cenários de inferência é totalmente desigual. A diferença no comprimento do contexto entre diferentes solicitações pode chegar a dezenas de vezes, a direção de transmissão do KV Cache entre GPUs é quase aleatória, e alguns switches Leaf tornam-se periodicamente pontos quentes, acionando o mecanismo de retroalimentação e espalhando o congestionamento de local para toda a cadeia. Esse congestionamento não pode ser resolvido apenas ajustando parâmetros do protocolo; é um produto da própria estrutura da topologia.

A ruptura fundamental do ZCube: impedir fisicamente esse tipo de congestionamento a nível de arquitetura.

O design principal é feito em duas etapas:

Primeiro passo: desativar a camada Spine e tornar a rede plana. Divida todos os switches Leaf em dois grupos, conforme numeração ímpar e par, e interconecte completamente os dois grupos: qualquer switch ímpar está conectado a todos os switches pares, e vice-versa. Qualquer par de GPUs pode se comunicar por meio de no máximo dois switches, reduzindo o número de saltos de 3 para 2.

Segundo passo, e também o mais sutil: cada placa de GPU é conectada a dois conjuntos de switches de maneiras completamente diferentes. Essa topologia especial traz uma propriedade matemática fundamental: entre quaisquer duas placas de GPU na rede, existe exatamente um caminho ótimo.

O caminho único elimina diretamente a causa da congestão. Arquiteturas tradicionais são propensas a pontos quentes exatamente porque há múltiplos caminhos disponíveis; se o algoritmo de balanceamento de carga escolher mal, o tráfego se concentra. O ZCube foi projetado para eliminar a própria "escolha": não há necessidade de balanceamento, pois não existem desvios.

Após atualizar o cluster de produção do GLM-5.1 da ROFT tradicional para o ZCube, o Zhipu obteve três números:

Em resumo, com o mesmo investimento em GPU, o cluster pode atender mais usuários; com os mesmos requisitos de experiência do usuário, o cluster pode comprar um terço a menos de equipamentos de rede. Eficiência e custo melhoram simultaneamente.

Especificamente, um aumento de 15% na taxa de processamento equivale a obter 15% de poder de computação adicional gratuitamente. Com o mesmo número de GPUs, um aumento de 15% na taxa de processamento equivale a uma redução de aproximadamente 13% no custo médio por token, ou seja, com o mesmo custo é possível atender 15% mais usuários.

Se um cluster tiver 1.000 GPUs, esta atualização equivale a adicionar 150 GPUs de capacidade adicional do nada; com base no preço de mercado atual das GPUs de inferência de alto desempenho, isso representa um valor de computação na ordem de centenas de milhões de yuan.

Atraso de cauda reduzido em 40,6%, resolvendo a estabilidade, não a velocidade média. Uma tarefa de Agent que requer 50 chamadas, se o atraso de cauda for reduzido em 1 segundo a cada chamada, comprime o tempo de conclusão mais longo em quase 1 minuto.

O custo foi reduzido em um terço, uma economia direta na infraestrutura. O ZCube eliminou a camada Spine, reduzindo diretamente em um terço o número de switches e módulos ópticos necessários para o mesmo tamanho de cluster. Segundo cálculos da Zhipu, em um cluster de escala de dez mil GPUs, apenas essa medida pode economizar entre 210 milhões e 640 milhões de yuans.

A longo prazo, à medida que o tamanho do cluster aumenta exponencialmente, a complexidade da comunicação entre GPUs aumenta várias vezes, elevando proporcionalmente a probabilidade e o impacto da congestão. Isso significa que o valor de inovações arquiteturais como o ZCube se tornará mais evidente à medida que os clusters de inferência continuarem a se expandir. Os ganhos com clusters de dez mil GPUs amanhã podem ultrapassar muito os 15% de hoje.

Depois de ler o relatório técnico do Zhipu, me perguntei se isso causará uma tempestade na indústria, assim como o DeepSeek fez.

Pense bem, os impactos dos dois parecem ocorrer em aspectos diferentes. Quando o DeepSeek foi lançado, demonstrou que a mesma inteligência pode ser alcançada com muito menos poder de processamento. O mercado temeu que "a quantidade de GPUs necessária diminuísse", fazendo com que a capitalização de mercado da NVIDIA caísse cerca de US$ 600 bilhões naquele dia.

Mas hoje a prova técnica da Zhipu mostra: com a mesma capacidade de processamento, é possível produzir mais. Ela está reestruturando "como deveriam ser as outras infraestruturas além da GPU".

A curto prazo, a NVIDIA não será afetada, mas a longo prazo, a vantagem competitiva formada pelo GPU + NVLink + rede InfiniBand + ecossistema de software CUDA está sendo "escavada", especialmente o InfiniBand adquirido pela NVIDIA em 2019 por US$ 6,9 bilhões, o que levará a uma erosão significativa da premium da NVIDIA no segmento de redes.

Além disso, o ZCube eliminou a camada Spine, mas aumentou a exigência de densidade de portas nos switches Leaf. Os beneficiados são os fabricantes capazes de produzir switches Leaf de alta densidade e muitas portas (Ruijie, Arista, chips de switch Broadcom), enquanto os prejudicados são os fabricantes que dependem principalmente dos switches de alto nível da camada Spine para obter margens de lucro.

Em 2025, Celestica e NVIDIA juntas ocupam cerca de 50% do mercado de switches de rede de back-end de IA, um cenário que enfrentará uma reestruturação após a disseminação do paradigma ZCube.

Os módulos ópticos são a direção mais diretamente beneficiada por esta mudança na cadeia de suprimentos, com uma lógica muito clara. Para os fabricantes chineses de módulos ópticos (como InnoLight e Tech-Faith Communications), trata-se de um benefício estrutural: não apenas o volume total está aumentando, mas também a demanda por módulos ópticos de alta velocidade (800G, 1,6T) sob o paradigma ZCube é mais concentrada e urgente do que sob arquiteturas tradicionais.

Tanto a arquitetura TileRT quanto a ZCube são motores de inferência puramente baseados em software que rodam em GPUs padrão, sem depender de recursos de hardware proprietários da NVIDIA, e teoricamente podem ser portados para chips nacionais como o Huawei Ascend. Se esse caminho for bem-sucedido, reduzirá significativamente a barreira de entrada para o software de inferência em chips de IA nacionais.

This may be the greater significance behind this technological innovation.