A infraestrutura de IA está superando a era de atender a uma única solicitação de modelo por vez. Um agente de nível de produção não apenas ...
A infraestrutura de IA está superando a era de processar uma única solicitação de modelo por vez.
Um agente de nível de produção não se limita a receber um prompt e retornar uma resposta. Ele pode dividir uma tarefa em várias etapas, chamar ferramentas externas, manter contexto, coordenar subagentes, revisar resultados intermediários e permanecer ativo por longos períodos. Quando uma empresa implanta milhares desses agentes simultaneamente, os requisitos de infraestrutura são drasticamente diferentes da inferência comum de chatbots.
Na Cúpula de Tecnologia de Computação Aberta de 2026, realizada em Pequim, a Inspur Information apresentou duas direções de infraestrutura para essa nova carga de trabalho:
A primeira direção foca na escala: manter um grande número de agentes de longa duração online. A segunda direção foca na qualidade: permitir que vários modelos com diferentes pontos fortes trabalhem juntos, em vez de forçar um único modelo a lidar com cada parte de uma tarefa difícil.
A inferência tradicional de grandes modelos geralmente segue um padrão simples:
Já o caminho de execução de uma aplicação de agente é muito mais longo.
Uma única tarefa de negócio pode envolver:
Portanto, a infraestrutura precisa suportar não apenas a inferência do modelo, mas também uma grande quantidade de processos de software persistentes.
Em ambientes empresariais, o número de agentes ativos pode passar de dezenas para milhares ou até dezenas de milhares. Alguns agentes podem operar continuamente, enquanto outros são criados dinamicamente para tarefas curtas e destruídos após a conclusão.
Isso altera o equilíbrio entre os recursos de CPU e GPU.
As GPUs permanecem insubstituíveis em:
As CPUs lidam com grande parte do trabalho periférico:
O modelo pode ser responsável por gerar raciocínio ou texto, mas a CPU geralmente executa o ambiente operacional do agente.
Portanto, a infraestrutura de agentes está evoluindo de um design centrado em GPU para um sistema onde CPU, GPU, rede, armazenamento, refrigeração e software de orquestração trabalham em conjunto.
Em servidores empresariais comuns, a densidade de CPU sempre foi limitada por fatores como consumo de energia, refrigeração, espaço, cabeamento, ventoinhas e necessidades de manutenção.
A implantação de agentes muda o modelo econômico.
Se milhares de agentes precisam de recursos de CPU para orquestração, chamada de ferramentas e ambientes de execução isolados, racks com baixa densidade de CPU ocuparão mais área de sala de servidores, conexões de rede e infraestrutura de suporte.
Ao mesmo tempo, os data centers de IA estão evoluindo para potências de rack mais altas.
De acordo com fontes do setor, a Inspur Information prevê que a potência dos racks de IA domésticos se aproximará de 300 quilowatts, enquanto alguns projetos globais já estão migrando para sistemas de rack de nível megawatt. O resfriamento a ar tradicional, geralmente limitado a dezenas de quilowatts por rack, se tornará cada vez mais desafiador nessas densidades.
Portanto, a refrigeração líquida não é mais um problema exclusivo das GPUs.
Os racks de CPU que suportam cargas de trabalho de agentes também devem se adequar à arquitetura de potência e refrigeração da próxima geração de data centers de IA.
A Inspur lançou o que afirma ser o primeiro servidor de rack refrigerado a líquido nativo para CPU do setor.
O sistema é baseado na arquitetura de refrigeração líquida OCM 2.0 e suporta processadores x86 e Arm.
Seus principais parâmetros incluem:
| Característica | Parâmetros Relatados pelo Fabricante |
|---|---|
| Número máximo de CPUs por rack | 384 |
| Número de agentes concorrentes suportados | Mais de 40.000 |
| Arquitetura do processador | x86 e Arm |
| Escopo de refrigeração | CPU, memória, SSD, placa de rede, módulo óptico e outros componentes geradores de calor |
| Densidade de computação | 4 CPUs integradas em espaço de 0,5U |
| Método de manutenção | Manutenção durante todo o ciclo de vida com refrigeração líquida |
| Cenário alvo | Data centers de IA de alta densidade e nível gigawatt |
O sistema não trata a refrigeração líquida como um complemento após o design do servidor ser concluído.
Em vez disso, o layout computacional e a arquitetura de refrigeração são desenvolvidos de forma colaborativa.
Servidores tradicionais com placa fria
Podem resfriar diretamente o processador, mas componentes como memória, rede, armazenamento, fonte de alimentação e outros dispositivos ainda dependem de ventoinhas para dissipar o calor.
À medida que a densidade aumenta, essa abordagem se torna menos eficaz.
A arquitetura de refrigeração líquida nativa da Inspur integra os principais componentes geradores de calor em um sistema de refrigeração unificado:
Isso reduz a dependência do fluxo de ar interno, permitindo uma disposição mais compacta dos componentes.
Abaixo estão três ícones azuis: "Arquitetura de Resfriamento Líquido", "Conexão de Resfriamento Líquido" e "Operação e Manutenção de Resfriamento Líquido". Esta imagem está intimamente relacionada ao contexto e apresenta visualmente a situação do servidor de arquitetura de resfriamento líquido da Inspur, ecoando o design da arquitetura de resfriamento líquido descrito no documento.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/44c90e20-2048-4f43-8d1d-8516006843e0-d14e80b4-e2a0-4468-a7b6-77e5229ab1ca.png)
Este relatório descreve uma unidade de computação compacta, que integra múltiplos conjuntos de processadores e componentes periféricos em um chassi fino e leve.
O objetivo do design é recuperar o espaço originalmente ocupado pelos seguintes componentes:
A disposição de componentes em formato plano permite que uma única placa fria de grande área cubra mais regiões do sistema.
O rack adota um design interno com redução ou eliminação de cabos, suportando manutenção sem interrupção. A Inspur afirma que isso melhora a eficiência de implantação e manutenção do rack completo.
OCM é a sigla para Open Compute Module.
A arquitetura modular visa desacoplar o módulo do processador do design geral do sistema. Esse design permite suportar processadores de diferentes gerações ou arquiteturas com mais facilidade, sem a necessidade de redesenhar o rack completo para cada processador.
Para empresas e operadores de datacenter, essa solução pode trazer os seguintes benefícios:
Os resultados reais dependem da compatibilidade do ecossistema, interoperabilidade e disponibilidade de componentes complementares.
Executar dezenas de milhares de agentes inteligentes para resolver problemas de capacidade não melhora automaticamente a qualidade das respostas.
Modelos de linguagem grandes têm especialidades distintas.
Certos modelos podem ser mais proficientes em:
Mesmo modelos de escala massiva têm lacunas de capacidade.
Ao lidar com tarefas complexas, um único modelo pode perder questões críticas, enquanto outros modelos podem identificá-las. Um único modelo também pode responder com confiança, sem expor incertezas ou considerar interpretações alternativas.
Portanto, a segunda direção de infraestrutura da Inspur foca na colaboração entre múltiplos modelos.
A API de fusão de múltiplos modelos do EPAI distribui tarefas complexas em paralelo para vários modelos candidatos.
Cada modelo gera respostas de forma independente. Outro modelo de revisão e fusão compara as respostas candidatas, identificando:
Declarações não suportadas:
Em seguida, a plataforma gera uma resposta consolidada.
Isso não é simplesmente uma votação majoritária, nem uma concatenação direta de todas as respostas. O fluxo de trabalho esperado é o seguinte:
A Inspur relata que o sistema alcançou 53,9% na avaliação DRACO, superando cada modelo individual no pool de candidatos usado no teste.
Esse resultado deve ser visto como uma referência relatada pela plataforma, e não como uma afirmação de que a fusão de modelos sempre supera o melhor modelo individual. O desempenho dependerá dos modelos candidatos, do modelo de avaliação, da lógica de roteamento, do tipo de tarefa, dos prompts e do método de pontuação.
Se cada solicitação executasse vários modelos, isso aumentaria desnecessariamente o custo e a latência.
Portanto, o EPAI distingue entre tarefas curtas e previsíveis e tarefas complexas.
Modelos leves podem ser suficientes para:
Vários modelos podem ser úteis para:
Esse princípio de roteamento é crucial para sistemas de produção.
A colaboração entre múltiplos modelos é mais valiosa quando o ganho potencial de qualidade compensa os custos extras de tokens, tempo de GPU e latência de resposta.
A API do EPAI visa ocultar a orquestração de múltiplos modelos por trás de uma interface unificada.
Os desenvolvedores enviam uma solicitação para a plataforma. O EPAI gerencia:
A mesma interface pode ser integrada em aplicações de agentes e frameworks de desenvolvimento, sem que cada equipe precise construir sistemas personalizados de roteamento e avaliação de modelos.
Essa arquitetura é adequada para empresas que usam uma combinação de modelos:
O principal desafio operacional é que vários LLMs podem precisar estar disponíveis simultaneamente. Isso impõe maiores exigências à memória do acelerador, largura de banda de interconexão, escalonamento e comunicação de baixa latência.
Descreva sua ideia uma vez e o We0 AI pode gerar um site de apresentacao, paginas e CMS, alem de ajudar a atrair clientes e trafego apos o lancamento.
Uma geração completa de projetos para registro gratuito
Melhor para experimentar um fluxo de geração completo e ver rapidamente um primeiro rascunho do projeto.
O MetaBrain SD200 Supernode é a plataforma de hardware que suporta o fluxo de trabalho de fusão de múltiplos modelos.
Este sistema adota uma arquitetura de comunicação multi-host e baixa latência com semântica de memória. De acordo com a Inspur, ele pode interconectar 64 aceleradores GPU nacionais em um único sistema.
Seu design inclui:
Capacidades
Segundo a empresa, este supernode pode suportar modelos individuais com até quatro trilhões de parâmetros, ou vários modelos com trilhões de parâmetros usados simultaneamente por aplicações de agentes.
A Inspur relata que o SD200 reduziu o tempo de geração de token único do modelo Kimi K2.6 (com trilhões de parâmetros) para 4,77 milissegundos.
A empresa também relata uma redução de 35% no tempo de geração do primeiro token em comparação com implementações anteriores.
Estes dados referem-se a resultados em ambientes de otimização e teste específicos e não devem ser interpretados como latência garantida para cada modelo, implantação, comprimento de prompt, nível de concorrência ou carga de trabalho de produção.
Essas melhorias são atribuídas a várias técnicas.
Modelos autorregressivos geralmente geram um token, verificam o novo estado e depois geram o próximo.
A predição de múltiplos tokens tenta gerar vários tokens candidatos em uma única etapa e verificá-los juntos.
Quando a precisão da predição é alta, isso pode reduzir o número de rodadas de decodificação sequencial.
A otimização usa pesos INT4 e cálculos de ativação INT8 em parte da carga de modelos de mistura de especialistas.
Em comparação com o cálculo BF16, isso pode reduzir:
A quantização pode afetar a qualidade do modelo, portanto as equipes de produção precisam avaliar a precisão com base em suas próprias cargas de trabalho, em vez de confiar apenas nos resultados de velocidade.
A compilação JIT gera kernels de acelerador especializados em tempo de execução com base na forma do tensor, layout e tipo de dados.
Em comparação com implementações estáticas genéricas, kernels especializados podem reduzir ramificações desnecessárias e melhorar o acesso à memória.
A pré-carga de prompts e a decodificação de tokens têm características de desempenho diferentes.
Separar as duas fases permite a alocação diferenciada de recursos e a transferência assíncrona do cache KV, reduzindo a contenção entre computação e comunicação.
A Inspur afirma que o SD200 concluiu a otimização de desempenho para vários modelos de código aberto populares, incluindo:
Compatibilidade não implica necessariamente que cada modelo atinja a mesma latência ou taxa de transferência.
A arquitetura do modelo, o número de parâmetros, o design MoE, o comprimento do contexto, a quantização, o lote e o software de serviço afetam o desempenho.
O supernó de 64 aceleradores é adequado para projetos de infraestrutura de IA de grande porte, mas é grande demais e caro para muitas empresas.
A Inspur também lançou o Yuannao SD200 Enterprise Edition.
A edição Enterprise reduz o domínio de computação de expansão vertical de 64 aceleradores para 16, com o objetivo de implantar localmente modelos de trilhões de parâmetros.
Seus recursos declarados incluem:
Esta edição Enterprise é direcionada principalmente para as seguintes cargas de trabalho:
Ela fornece um ponto de entrada menor para organizações que precisam de controle local do modelo, mas não conseguem justificar um supernó de 64 aceleradores.
Os produtos lançados no OCTS 2026 mostram uma arquitetura de três camadas.
| Camada | Responsabilidade Principal |
|---|---|
| Plataforma de Software | Acesso ao modelo, roteamento de tarefas, orquestração, permissões, avaliação e fusão de resultados |
| Infraestrutura de CPU | Processos de agente, chamadas de ferramentas, execução em sandbox, gerenciamento de contexto e interação com sistemas de negócios |
| Supernó de GPU | Inferência de modelos grandes, geração de tokens de alta taxa de transferência e execução de múltiplos modelos |
O sistema só funciona corretamente quando todas as três camadas trabalham em conjunto.
Um cluster de GPU rápido não pode compensar um agendamento de agente fraco. Um rack de CPU de alta densidade não pode melhorar a qualidade da inferência se não tiver acesso a modelos poderosos. Uma API de fusão complexa não pode fornecer latência útil se o modelo subjacente não puder ser carregado ou conectado com eficiência.
Esta é a principal mudança na competição de infraestrutura de agentes.
O mercado inicial focava principalmente em quão bem um único servidor suportava um único modelo grande. A era dos agentes deslocou a atenção para o desempenho em nível de sistema:
Números impressionantes fornecidos pelos fornecedores são úteis, mas insuficientes para escolher uma plataforma de infraestrutura de agentes.
Uma avaliação de ambiente de produção deve medir a carga de trabalho completa.
Não apenas conte usuários ativos, mas também:
Um agente de recuperação leve tem características de demanda de recursos drasticamente diferentes de um agente de codificação equipado com um ambiente de desenvolvimento independente.
A métrica "número de agentes por rack" deve ser mapeada para as necessidades reais de memória, CPU, armazenamento e rede da aplicação alvo.
É necessário medir:
Um tempo de geração de token baixo em benchmarks não garante baixa latência em fluxos de trabalho de ponta a ponta.
A fusão de múltiplos modelos pode melhorar a qualidade, mas pode levar a um aumento múltiplo nos custos de inferência.
As equipes devem comparar:
Racks refrigerados a líquido nativos requerem infraestrutura de instalações de suporte.
É necessário verificar:
Padrões de módulo abertos podem aumentar a flexibilidade, mas a portabilidade real depende da compatibilidade do software.
É necessário validar:
Agentes de longa duração requerem controles rigorosos sobre:
A densidade da infraestrutura não deve vir às custas do isolamento operacional.
É um servidor de rack completo projetado em torno de um sistema de refrigeração, em vez de adicionar refrigeração líquida a um design de resfriamento a ar tradicional. A Inspur afirma que pode acomodar até 384 CPUs e suportar mais de 40.000 agentes concorrentes.
Este número é o máximo relatado pela Inspur com base em relatórios de arquitetura de referência de fornecedores. A capacidade real depende dos recursos de CPU, memória, armazenamento, rede e isolamento de sandbox necessários para cada agente.
Os modelos de linguagem podem ser executados em GPUs, mas os agentes também precisam de CPUs para agendamento, execução de ferramentas, gerenciamento de estado, acesso a sistemas de negócios, verificações de segurança e ambientes de tempo de execução isolados. Fluxos de trabalho de longa duração e multiagente aumentam ainda mais essa demanda de CPU.
OCM é uma arquitetura de módulo de computação aberta usada para separar os módulos de computação do design de rack mais amplo. O sistema refrigerado a líquido OCM 2.0 da Inspur suporta múltiplas arquiteturas de CPU e refrigeração líquida de todos os componentes.
MetaBrain SD200 é um super nó de IA da Inspur projetado para inferência de modelos grandes e cargas de trabalho de múltiplos modelos. Ele usa uma arquitetura de expansão de 64 aceleradores, suportando endereçamento unificado e interconexão de alta velocidade.
É uma API que envia uma tarefa para múltiplos modelos candidatos, coleta suas respostas independentes e
usa modelos de revisão e fusão para identificar consenso, divergência, omissões e insights únicos antes de gerar a resposta final.
Não. Múltiplos modelos podem melhorar o desempenho em tarefas complexas, mas aumentam o consumo de tokens, custos computacionais e latência. Tarefas simples são mais adequadas para serem roteadas para um único modelo leve.
O SD200 completo usa um domínio de expansão de 64 aceleradores para cargas de trabalho de grande escala. O SD200 Enterprise Edition reduz o domínio para 16 aceleradores, visando empresas que precisam implantar modelos locais de trilhões de parâmetros com uma barreira de infraestrutura mais baixa.
DeepSeek: Fornecedor de modelos de IA, cujo modelo de código aberto foi incluído na lista de compatibilidade SD200.
O anúncio da Inspur no OCTS 2026 aborda dois grandes problemas causados pelos agentes empresariais.
O rack nativo refrigerado a líquido foca na escalabilidade, fornecendo um ambiente intensivo para agendamento de agentes, ferramentas, sandboxes, gerenciamento de contexto e execução de processos longos. O fluxo de trabalho de fusão multimodelo do SD200 e EPA foca na inteligência, permitindo que vários modelos grandes colaborem em tarefas complexas, com o modelo de revisão integrando os resultados.
A lição mais ampla é: a infraestrutura de agentes não pode ser reduzida a um único acelerador mais rápido. Sistemas de produção precisam coordenar
CPU, GPU, memória, interconexão, refrigeração, orquestração, permissões e avaliação.
A principal métrica da infraestrutura de agentes está mudando do desempenho de execução de um único modelo para a capacidade de todo o sistema em agendar eficientemente milhares de agentes e produzir resultados confiáveis de forma contínua.
Comece com uma frase e tenha um site completo em minutos.
