Inspur constrói infraestrutura de agentes: 40 mil agentes por rack e colaboração multimodelo

Introdução

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:

1. Servidores de rack refrigerados a líquido nativos para CPU, projetados para suportar mais de 40.000 agentes concorrentes em um único rack.
2. A combinação do Super Nó MetaBrain SD200 com a API de Fusão Multi-Modelo EPAI, permitindo que vários grandes modelos gerem, revisem e combinem respostas para tarefas complexas.

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.

Os Diferentes Desafios de Infraestrutura Impostos pelas Cargas de Trabalho de Agentes

A inferência tradicional de grandes modelos geralmente segue um padrão simples:

1. O usuário envia uma solicitação.
2. O modelo executa a inferência.
3. O sistema retorna uma resposta.
4. A sessão termina ou aguarda a próxima solicitação.

Já o caminho de execução de uma aplicação de agente é muito mais longo.

Uma única tarefa de negócio pode envolver:

• Planejamento
• Decomposição de tarefas
• Recuperação
• Chamada de ferramentas
• Execução de código
• Verificação de permissões
• Processos em sandbox
• Inferência em múltiplas rodadas
• Coordenação de subagentes
• Validação de saída
• Agregação de resultados
• Gerenciamento de estado de longa duração

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.

GPUs Geram Tokens

As GPUs permanecem insubstituíveis em:

• Inferência de grandes modelos
• Pré-preenchimento e decodificação
• Geração de embeddings
• Processamento multimodal
• Produção de tokens de alto rendimento
• Execução paralela de modelos

CPUs Executam o Ambiente do Agente

As CPUs lidam com grande parte do trabalho periférico:

• Escalonamento de processos do agente
• Chamada de ferramentas
• Gerenciamento de contexto e estado
• Interação com sistemas de negócios
• Execução em sandbox
• Operações de rede e armazenamento
• Autenticação e permissões
• Coordenação de fluxo de trabalho
• Preparação de resultados

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.

Por Que a Densidade de CPU Está se Tornando Cada Vez Mais Importante

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.

Um Único Rack Pode Suportar Mais de 40.000 Agentes

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.

Expansão do Resfriamento por Placa Fria da CPU para Todos os Componentes

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:

• CPU
• Memória
• Placa de rede
• Módulo óptico
• SSD
• Componentes de comunicação

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)

Unidade de Computação Compacta

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:

• Grandes ventiladores
• Dutos de ar
• Tubulações de resfriamento
• Cabos internos
• Bandejas tradicionais de servidor

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.

Por que o OCM é importante

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:

• Mais opções de hardware
• Maior facilidade para atualizações de plataforma
• Redução de trabalho de design redundante
• Melhor compatibilidade com arquiteturas x86 e Arm
• Prolongamento do ciclo de vida da infraestrutura do rack

Os resultados reais dependem da compatibilidade do ecossistema, interoperabilidade e disponibilidade de componentes complementares.

Tamanho não é igual a inteligência

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:

• Raciocínio lógico
• Escrita de código
• Análise de textos longos
• Pesquisa técnica
• Redação natural
• Extração estruturada
• Tarefas multilíngues

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.

Colaboração de múltiplos modelos na mesma tarefa

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:

• Conclusões comuns
• Julgamentos contraditórios
• Informações omitidas
• Insights únicos

Declarações não suportadas:

• Áreas que precisam de coordenação

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:

1. Geração de candidatos
2. Revisão entre modelos
3. Análise de diferenças e omissões
4. Fusão na saída final

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.

Tarefas simples ainda usam modelo único

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.

Tarefas adequadas para modelo único

Modelos leves podem ser suficientes para:

• Perguntas e respostas simples
• Conversão de formato
• Extração básica
• Tarefas de classificação
• Chamadas curtas de ferramentas
• Conversão de conteúdo rotineiro

Tarefas mais adequadas para fusão de múltiplos modelos

Vários modelos podem ser úteis para:

• Pesquisa aprofundada
• Comparação técnica
• Análise de arquitetura
• Planejamento complexo
• Raciocínio em textos longos
• Revisão de alto impacto
• Tarefas com evidências ambíguas
• Saídas que necessitam de verificação independente

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.

Fluxo de trabalho de fusão de múltiplos modelos do EPAI

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:

• Seleção do modelo candidato
• Distribuição paralela de tarefas
• Coleta de respostas
• Execução do modelo de avaliação
• Análise de diferenças
• Geração da resposta final

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:

• Modelos de código aberto
• Modelos proprietários
• Modelos de uso geral
• Modelos específicos de domínio
• Modelos implantados localmente
• Modelos de API em nuvem

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.

MetaBrain SD200 fornece o motor de tokens

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:

• Arquiteturas abertas de computação OCM e OAM
• Interconexão 3D Mesh
• Endereçamento unificado de aceleradores
• Comunicação ponto a ponto de alta velocidade
• Memória compartilhada de grande capacidade

Capacidades

• Suporta vários modelos com trilhões de parâmetros
• Otimização cooperativa de software e hardware

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.

Tempo de geração de token da Inspur atinge 4,77 milissegundos

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.

Predição de múltiplos tokens

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.

Quantização W4A8

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:

• Pressão na largura de banda da memória
• Uso de memória do acelerador
• Demandas computacionais
• Custo de inferência por token

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.

Compilação Just-in-Time de kernels

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.

Separação prefill-decode

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.

Compatibilidade de modelos

A Inspur afirma que o SD200 concluiu a otimização de desempenho para vários modelos de código aberto populares, incluindo:

• Kimi K2.6
• DeepSeek V4
• GLM 5.2
• MiniMax M3

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.

Edição Enterprise reduz a barreira de implantação

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:

• Domínio de interconexão unificada de 16 aceleradores
• Comunicação de semântica de memória nativa
• Endereçamento unificado
• Memória de acelerador unificada de terabytes
• Melhoria de mais de 40% no tempo de geração do primeiro token para inferência de trilhões de parâmetros
• Suporte nativo para modelos de código aberto líderes de trilhões de parâmetros
• Custos de migração e adaptação menores que o sistema SD200 completo

Esta edição Enterprise é direcionada principalmente para as seguintes cargas de trabalho:

• Compreensão de documentos longos
• Raciocínio lógico complexo
• Implantação de modelos privados
• Colaboração multiagente
• Pesquisa interna
• Aplicações de negócios sensíveis

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.

A pilha de infraestrutura está se tornando mais integrada

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:

• Quantos processos de agente podem permanecer online?
• Quão rápido eles chamam modelos e ferramentas?
• Vários modelos podem ser executados simultaneamente?
• Como a memória é compartilhada ou isolada?
• Como as permissões são aplicadas?
• A plataforma pode rotear tarefas simples e complexas de forma diferente?
• O sistema pode permanecer estável sob alta concorrência?
• Quão eficientemente ele gera tokens úteis?

O que as empresas devem avaliar antes da implantação

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.

1. Concorrência de Agentes

Não apenas conte usuários ativos, mas também:

• Subagentes por tarefa
• Processos de ferramentas
• Sandboxes
• Trabalhos em segundo plano
• Sessões persistentes
• Picos de rajada
• Processos de recuperação de falhas

2. CPU e memória por agente

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.

3. Latência do modelo

É necessário medir:

• Tempo até o primeiro token
• Latência entre tokens
• Tempo total da tarefa
• Latência de fila
• Latência de chamada de ferramenta
• Latência sob concorrência

Um tempo de geração de token baixo em benchmarks não garante baixa latência em fluxos de trabalho de ponta a ponta.

4. Economia de múltiplos modelos

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:

• Precisão do modelo único
• Precisão do modelo fundido
• Número de tokens consumidos
• Utilização da GPU
• Tempo de resposta
• Custo do modelo de revisão
• Taxa de falha
• Redução na revisão manual

5. Compatibilidade de refrigeração e instalações

Racks refrigerados a líquido nativos requerem infraestrutura de instalações de suporte.

É necessário verificar:

• Unidade de distribuição de líquido refrigerante
• Temperatura de fornecimento e retorno
• Requisitos de pressão e vazão
• Detecção de vazamentos
• Procedimentos de manutenção
• Esquema de recuperação de calor residual
• Capacidade de energia do rack
• Capacidade de carga do piso do data center

6. Portabilidade de modelo e acelerador

Padrões de módulo abertos podem aumentar a flexibilidade, mas a portabilidade real depende da compatibilidade do software.

É necessário validar:

• Frameworks de modelo
• Motores de inferência
• Suporte a quantização
• Disponibilidade de kernel
• Maturidade do driver
• Ferramentas de monitoramento
• Substituição do acelerador
• Processos de atualização

7. Confiabilidade e governança

Agentes de longa duração requerem controles rigorosos sobre:

• Autenticação de identidade
• Configuração de permissões
• Gerenciamento de chaves
• Acesso à rede
• Ambiente sandbox
• Logs de auditoria
• Limitação de taxa
• Aprovação manual
• Roteamento de modelo
• Retenção de dados

A densidade da infraestrutura não deve vir às custas do isolamento operacional.

Perguntas Frequentes

O que é o rack de agente refrigerado a líquido nativo de CPU da Inspur?

É 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.

Um rack pode realmente executar 40.000 agentes de IA?

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.

Por que os agentes de IA precisam de tantas CPUs?

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.

O que é OCM 2.0?

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.

O que é MetaBrain SD200?

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.

O que é a API de fusão de múltiplos modelos EPAI?

É 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.

A fusão de múltiplos modelos é sempre melhor que um modelo único?

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.

Qual é a diferença entre o SD200 e o SD200 Enterprise Edition?

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.

Ferramentas relacionadas

• Inspur EPA Plataforma de IA de nível empresarial: suporta gerenciamento de modelos, desenvolvimento de aplicações, recuperação, implantação e fluxos de trabalho de múltiplos modelos.
• Solução de refrigeração líquida Inspur: Solução de infraestrutura para implantação de servidores CPU/GPU refrigerados a líquido.
• Open Compute Project: Comunidade da indústria que desenvolve designs de hardware abertos para servidores, racks, energia, refrigeração e data centers.
• Kimi: Plataforma de assistente e modelo da Moonshot AI, cujos resultados de otimização são citados no Inspur SD200.

DeepSeek: Fornecedor de modelos de IA, cujo modelo de código aberto foi incluído na lista de compatibilidade SD200.

Links Relacionados

• Anúncio da Infraestrutura de Agentes da Inspur: Cobre o lançamento oficial de racks de CPU refrigerados a líquido, SD200 e supernós de nível empresarial.
• Anúncio de Desempenho de 4,77ms do MetaBrain SD200: Visão técnica da Inspur sobre a otimização do SD200 e resultados de geração de tokens.
• API de Fusão Multimodelo EPA: Explicação oficial dos mecanismos de geração de candidatos, revisão, fusão e pontuação DRACO.
• Página de Produto EPA da Inspur: Informações do produto da plataforma de desenvolvimento de modelos grandes de nível empresarial.
• Solução de Data Center Refrigerado a Líquido da Inspur: Informações oficiais sobre soluções de implantação de data centers refrigerados a líquido.
• Cúpula de Tecnologia de Computação Aberta 2026: Página do evento OCTS 2026 e anúncios relacionados à computação aberta.
• Fundação do Projeto de Computação Aberta: Informações oficiais sobre padrões de infraestrutura aberta e projetos comunitários.

Resumo

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.