A alegação de Bittensor sobre o Kimi K3 em 80 GPUs põe à prova a infraestrutura de IA de consumo

A Bittensor chegou ao Google News depois que um participante de seu ecossistema afirmou que o Kimi K3, da Moonshot AI, com 2,8 trilhões de parâmetros, estava rodando em 80 GPUs Nvidia RTX 5090. Segundo uma publicação em rede social associada ao projeto, o cluster produziu 20 tokens por segundo em um único fluxo. Esse número não foi verificado de forma independente.

A alegação importa porque o Kimi K3 não é um modelo que normalmente cabe em hardware de consumo. Seu checkpoint lançado ocupa cerca de 1,56 terabyte, enquanto cada RTX 5090 oferece 32 gigabytes de memória gráfica. Coordenar 80 placas também cria um difícil problema de comunicação que a capacidade bruta de memória não resolve.

Portanto, não se trata de uma simples disputa entre a Bittensor e uma empresa centralizada de IA. O conflito mais relevante coloca clusters de GPUs relativamente acessíveis contra sistemas altamente integrados, construídos em torno de aceleradores de datacenter e interconexões de alta largura de banda. Os primeiros ampliam o acesso ao hardware. Os últimos ainda mantêm grandes vantagens em velocidade, confiabilidade e simplicidade operacional.

O que a alegação sobre o Kimi K3 em 80 GPUs realmente diz

O resultado relatado é uma alegação de implantação para inferência, não uma evidência de que a Bittensor treinou um modelo de 2,8 trilhões de parâmetros.

A Moonshot AI desenvolveu o Kimi K3 e lançou seus pesos em julho de 2026. Posteriormente, uma conta ligada à Bittensor afirmou que o modelo completo estava rodando em 80 placas RTX 5090 por uma rede Ethernet de 25 gigabits. A publicação descreveu um desempenho de cerca de 20 tokens por segundo para um fluxo de geração.

A distinção entre desenvolvimento e implantação é essencial. A Moonshot projetou e treinou o modelo. O participante do ecossistema Bittensor teria montado a infraestrutura usada para carregá-lo e servi-lo.

A alegação pública também se refere à inferência, ou seja, à geração de resultados a partir de um modelo já treinado. O treinamento exigiria armazenar estados do otimizador, gradientes e valores intermediários, criando uma carga muito maior de memória e comunicação.

A escala do Kimi K3 torna até a inferência incomum. O relatório técnico da Moonshot descreve um modelo de mistura de especialistas com cerca de 2,8 trilhões de parâmetros totais. Um modelo de mistura de especialistas, ou MoE, direciona cada token por um pequeno subconjunto de blocos especializados de rede neural.

O Kimi K3 ativa cerca de 104 bilhões de parâmetros para cada token. Ele seleciona 16 de 896 especialistas roteados, além de componentes compartilhados. Essa ativação esparsa reduz o cálculo, mas não faz desaparecer os pesos restantes.

Todos os especialistas precisam permanecer disponíveis, porque diferentes tokens podem acionar rotas distintas. O sistema, portanto, deve armazenar o checkpoint inteiro em algum lugar e mover dados intermediários entre os dispositivos que abrigam os especialistas selecionados.

O título do Google News comprime esse problema de sistemas em uma contagem de hardware fácil de memorizar. Ele não responde a várias perguntas necessárias para a verificação técnica.

As informações públicas não documentam integralmente a pilha de software, o tamanho dos prompts, o contexto, o tamanho do lote, o consumo de energia, a taxa de falhas ou a qualidade da saída. Também não estabelecem se a velocidade relatada se manteve em cargas de trabalho variadas.

A expressão “modelo completo” exige cautela semelhante. Ela aparentemente significa que a implantação usou a arquitetura completa do Kimi K3, em vez de uma substituição menor e destilada. Não significa necessariamente que todos os recursos, comprimentos de contexto ou cenários de produção tenham sido testados.

Um resultado confiável deveria eventualmente incluir arquivos de configuração reproduzíveis, checksums do modelo, detalhes de precisão, logs e medições padronizadas de throughput. Até que isso apareça, 20 tokens por segundo continua sendo um resultado relatado, não um benchmark consolidado.

Por que o Google News focou em GPUs de consumo

A verdadeira atração não é que 80 GPUs sejam poucas, mas que elas pertençam a um mercado de hardware mais amplo e competitivo.

A RTX 5090 continua sendo uma placa gráfica cara e com alto consumo de energia. Uma instalação com 80 placas exige racks, rede, refrigeração, distribuição elétrica, processadores host, armazenamento e considerável conhecimento operacional. Chamar esse sistema de “local” pode esconder sua escala industrial.

Ainda assim, essas placas diferem dos principais aceleradores de datacenter em um aspecto importante. As organizações podem adquiri-las por canais de hardware mais convencionais, sem depender inteiramente de configurações escassas de supercomputadores.

Essa possibilidade está alinhada à ideia central da Bittensor. A Bittensor organiza subnets especializadas, nas quais participantes fornecem serviços e validadores avaliam suas contribuições. Seu diretório público de subnets inclui projetos voltados à inferência, treinamento, dados, avaliação de modelos e outras cargas de trabalho de IA.

Uma implantação bem-sucedida em GPUs de consumo fortaleceria o argumento de que infraestrutura útil de IA pode surgir fora de alguns poucos datacenters em hiperescala. Isso não provaria que a inferência descentralizada já é mais barata ou melhor. Mostraria que o limite do hardware viável está se deslocando.

O Kimi K3 foi projetado levando esse limite em conta. Seus pesos lançados usam MXFP4, um formato numérico de baixa precisão que armazena valores do modelo com menos bits. Uma precisão menor reduz as necessidades de memória e o tráfego de memória, embora o suporte de hardware e a qualidade dos kernels determinem os ganhos reais.

O modelo também usa Kimi Delta Attention, que combina processamento de estado fixo com camadas periódicas de atenção global. A atenção convencional costuma manter um cache de chave-valor que cresce com o prompt. O projeto do Kimi limita esse crescimento em muitas camadas.

O Stable LatentMoE reduz a representação oculta antes do cálculo dos especialistas. Apenas uma fração dos especialistas processa cada token. Juntas, essas escolhas reduzem a carga de trabalho ativa em comparação com um modelo denso que tenha o mesmo número total de parâmetros.

Elas não eliminam o desafio de rede. O roteador pode enviar tokens consecutivos a especialistas armazenados em placas diferentes. Cada decisão desse tipo cria uma comunicação que precisa terminar antes que a próxima operação dependente possa prosseguir.

É aqui que o cluster de consumo se diferencia de um supernó de datacenter. Os sistemas de ponta da Nvidia conectam GPUs usando tecnologias projetadas para transferências rápidas entre dispositivos. Um cluster construído em torno de Ethernet geralmente tem menor largura de banda e maior latência entre as placas.

A rede relatada de 25 gigabits é especialmente relevante. Vinte e cinco gigabits por segundo equivalem a um máximo teórico próximo de 3,125 gigabytes por segundo antes da sobrecarga de protocolo. As interconexões de GPUs de datacenter operam com taxas agregadas muito mais altas.

Um particionamento cuidadoso pode reduzir o que atravessa a rede. O paralelismo de especialistas posiciona especialistas distintos em dispositivos diferentes, enquanto o paralelismo de tensor divide cálculos individuais. O software também pode sobrepor comunicação e computação ou agrupar tokens em lotes maiores.

No entanto, uma carga de trabalho de fluxo único oferece menos oportunidade de processamento em lote do que um serviço compartilhado movimentado. Se a taxa relatada de 20 tokens se mantiver nessa condição, a estratégia de agendamento e posicionamento merece análise detalhada.

Ainda seria incorreto inferir uma economia de produção equivalente. Uma demonstração de fluxo único mede a latência sob uma carga de trabalho. O atendimento comercial também depende de solicitações simultâneas, throughput total, disponibilidade, consumo de energia e tempos de resposta previsíveis.

O enquadramento do Google News capta uma surpresa de hardware. A questão mais consequente é saber se o mesmo arranjo continua eficiente quando muitos usuários chegam ao mesmo tempo.

Clusters de consumo desafiam supernós, não a física

Hardware de consumo distribuído muda quem pode tentar executar inferência em modelos grandes, mas não elimina o valor da memória rápida e das interconexões.

As orientações oficiais de implantação oferecem uma comparação útil. A AMD informa que o Kimi K3 cabe em oito aceleradores Instinct MI355X usando paralelismo de tensor. Sua análise de implantação estima o checkpoint em cerca de 1,56 terabyte e explica como os pesos são distribuídos.

O MI355X oferece muito mais memória de alta largura de banda por placa do que uma RTX 5090. Assim, oito aceleradores podem abrigar o modelo sem distribuí-lo por 80 domínios de memória separados.

O projeto vLLM também recomenda oito aceleradores B300 ou oito MI355X como uma configuração inicial acessível. Seu suporte ao Kimi K3 abrange as camadas de atenção especializadas do modelo, o roteamento de especialistas, componentes multimodais e os pesos nativos de baixa precisão.

Esses sistemas não são automaticamente superiores em todos os contextos econômicos. Sua aquisição, disponibilidade e restrições de implantação diferem das placas de consumo. Organizações com capacidade já existente de GPUs para jogos podem valorizar mais a reutilização de hardware do que a eficiência máxima.

Ainda assim, a comparação expõe a principal troca. Um cluster de consumo substitui a densidade de memória e o desempenho de interconexão dos aceleradores de datacenter por engenharia de expansão horizontal.

Mais dispositivos introduzem mais pontos potenciais de falha. Um serviço com 80 GPUs depende de que 80 placas, seus sistemas host, links de rede, caminhos de armazenamento e processos de software permaneçam coordenados. Um único componente com falha pode interromper uma solicitação rigidamente sincronizada, a menos que a arquitetura inclua mecanismos de recuperação.

A densidade de energia cria outra restrição. Mesmo sem publicar uma estimativa de custo, as exigências elétricas e de refrigeração são substanciais. Os operadores precisam medir tokens úteis por unidade de energia, não apenas tokens por segundo.

A latência também é apenas uma dimensão da qualidade do serviço. Um cluster pode oferecer velocidade aceitável em um único fluxo, mas ter dificuldades com processamento de prompts, contextos longos ou vários usuários simultâneos.

O Kimi K3 suporta uma janela de contexto de até um milhão de tokens. Essa capacidade de destaque não significa que toda implantação possa atender eficientemente ao contexto máximo. A memória de execução cresce com o estado da carga de trabalho, mesmo quando a arquitetura de atenção reduz a pressão sobre o cache.

Prompts longos também aumentam o trabalho de prefill, ou seja, a computação necessária antes que um modelo gere seu primeiro token de saída. Uma demonstração usando um prompt curto diz pouco aos leitores sobre o tempo até o primeiro token com uma entrada do tamanho de um livro.

A qualidade da saída também precisa de verificação. O atendimento em baixa precisão pode preservar um comportamento robusto do modelo, mas conversões alternativas ou kernels personalizados podem introduzir mudanças numéricas. Um benchmark de sistemas deve associar os números de desempenho a resultados de avaliação do modelo.

Essas ressalvas não tornam o cluster relatado pouco importante. Elas identificam que tipo de conquista ele representa.

Se for verificado, o resultado mostraria que desenvolvedores podem instalar um modelo de pesos abertos excepcionalmente grande em uma coleção de aceleradores amplamente disponíveis. Trata-se de um resultado significativo de sistemas, mesmo que um supernó menor permaneça mais rápido e mais fácil de operar.

A versão mais forte do argumento descentralizado não é que placas de consumo superam GPUs de datacenter em todas as métricas. É que hardware heterogêneo pode se tornar capacidade útil quando o software o coordena de forma eficaz.

Essa proposta tem implicações que vão além da Bittensor. Provedores independentes de hospedagem, laboratórios de pesquisa, universidades e operadores regionais de infraestrutura poderiam usar técnicas semelhantes.

Modelos de pesos abertos tornam esses experimentos possíveis. Um modelo disponível apenas por API não pode ser reparticionado, quantizado ou implantado por meio de um runtime criado pela comunidade. O Kimi K3 dá aos desenvolvedores de infraestrutura acesso aos pesos, embora a Moonshot não tenha divulgado todos os componentes de seu processo de treinamento.

Assim, os pesos abertos ampliam o campo de implantação sem torná-lo igualitário. Competência de engenharia, design de rede, acesso à energia e capital para hardware ainda determinam quem consegue operar o modelo com eficácia.

O que a alegação da Bittensor ainda não comprova

Uma contagem impressionante de máquinas não substitui desempenho reproduzível, confiabilidade do serviço ou operação descentralizada.

A primeira incerteza diz respeito à atribuição. As evidências disponíveis se concentram em uma publicação nas redes sociais vinculada ao ecossistema Bittensor, seguida por cobertura secundária. Isso não deve ser descrito como um resultado formal e auditado de forma independente pela fundação Bittensor ou pela rede como um todo.

A Bittensor é um protocolo com muitas sub-redes e participantes operados de forma independente. O trabalho realizado por uma equipe pode demonstrar atividade dentro desse ecossistema sem representar todas as sub-redes ou se tornar uma capacidade de toda a rede.

A segunda incerteza diz respeito à descentralização. Oitenta GPUs de consumo podem estar em uma única instalação, sob o controle de um único operador. Essa configuração utiliza computação distribuída, mas não é automaticamente descentralizada.

Um serviço descentralizado normalmente abrange provedores independentes, domínios de falha e limites administrativos. Esse arranjo cria problemas mais difíceis envolvendo confiança, condições variáveis de rede, diferenças de hardware e rotatividade de participantes.

O cluster relatado parece mais útil como evidência sobre hardware commodity escalável horizontalmente. Os detalhes públicos ainda não estabelecem que uma sub-rede Bittensor ativa tenha distribuído a inferência do Kimi K3 entre miners não relacionados.

A terceira incerteza diz respeito ao benchmark. Vinte tokens por segundo parecem interativos para muitas tarefas de texto, mas um único número não consegue descrever um sistema de serving.

Os leitores precisam conhecer o comprimento do prompt, a quantidade de tokens gerados, o tamanho do lote, a concorrência, as configurações de amostragem, a precisão e a duração da medição. Também precisam do tempo até o primeiro token e do throughput total de saída.

Um benchmark realizado imediatamente após a inicialização pode diferir de outro medido após horas de tráfego sustentado. Limites térmicos, fragmentação de memória, congestionamento de rede e falhas de dispositivos se tornam visíveis em testes mais longos.

Uma replicação independente fortaleceria consideravelmente o resultado. Um segundo operador deveria conseguir implantar os mesmos pesos e software em hardware comparável e, então, relatar medições semelhantes.

A quarta incerteza é a utilidade comercial. Um sistema que gera um fluxo a 20 tokens por segundo ainda pode oferecer baixo throughput agregado. Alternativamente, o processamento em lote pode melhorar a eficiência enquanto aumenta a latência por usuário.

Operadores de produção precisam equilibrar esses dois resultados. Também precisam de monitoramento, controle de admissão, segurança, isolamento e procedimentos de recuperação. Nenhum desses requisitos é capturado pela manchete original.

A quinta incerteza é se 80 placas RTX 5090 representam o melhor uso do hardware de consumo. Diferentes topologias de rede, aceleradores mais novos, formatos comprimidos ou projetos híbridos de CPU-GPU poderiam mudar a configuração ideal.

A própria arquitetura da Moonshot também cria oportunidades e restrições. Ativar apenas 16 especialistas roteados por token reduz a computação. Ainda assim, as escolhas do roteador podem dispersar o tráfego entre dispositivos, tornando o posicionamento dos especialistas e o agendamento da rede decisivos.

Um sistema cuidadosamente projetado poderia manter especialistas frequentemente combinados próximos uns dos outros ou duplicar pesos selecionados. A duplicação reduz a comunicação, mas consome memória extra. Esse é o trade-off recorrente na inferência distribuída.

A ampla reação pública ao Kimi K3 mostra por que a verificação importa. O modelo atraiu atenção substancial após o lançamento, e a demanda teria excedido a capacidade inicial de serviço da Moonshot. A resposta de capacidade mostrou que disponibilidade do modelo e serving confiável continuam sendo conquistas distintas.

A premissa da Bittensor é relevante para esse gargalo. Um mercado que atraia capacidade computacional adicional poderia expandir a capacidade de serving. No entanto, incentivos por si só não podem resolver o particionamento de modelos, a conectividade de rede ou a confiabilidade.

Os validadores também precisam medir corretamente o serviço útil. Se as recompensas enfatizarem um teste restrito de throughput, os operadores poderão otimizar para esse teste enquanto negligenciam prompts longos, concorrência ou qualidade da saída.

Uma sub-rede crível, portanto, precisa de regras de avaliação que reflitam as necessidades reais dos usuários. Essas regras devem resistir à manipulação e se adaptar à medida que as técnicas de serving melhoram.

A alegação do Google News merece atenção porque aponta para um caminho diferente de infraestrutura. Ela não deve ser tratada como prova de que esse caminho já alcançou maturidade de produção.

A verdadeira inovação é coordenar memória e tráfego

Executar o Kimi K3 em 80 placas depende menos de aumentar a quantidade de GPUs do que de controlar onde os pesos ficam e como as ativações se movem.

O checkpoint primeiro precisa ser dividido em partes pequenas o suficiente para placas individuais. O paralelismo básico de tensores pode dividir grandes operações de matriz, mas estendê-lo por dezenas de dispositivos conectados por Ethernet pode gerar tráfego intenso de sincronização.

O paralelismo de especialistas se encaixa de forma mais natural em um modelo MoE. Placas ou grupos diferentes podem hospedar especialistas diferentes, permitindo que um token visite apenas o subconjunto selecionado pelo roteador.

Essa abordagem reduz a computação por token, mas introduz um padrão de comunicação all-to-all. Os tokens deixam seus dispositivos originais, viajam até as placas que contêm os especialistas selecionados e retornam após o processamento.

A topologia de rede se torna parte do runtime do modelo. Uma coleção plana de conexões pode apresentar desempenho diferente de uma hierarquia que agrupa placas dentro de hosts e depois conecta os hosts por switches.

O agendador precisa conhecer esses limites. Sempre que possível, ele deve manter trocas de alto volume em caminhos locais mais rápidos e limitar o tráfego que cruza conexões mais lentas.

O posicionamento da memória é igualmente importante. O sistema precisa reservar espaço para pesos, ativações, buffers de comunicação e estado das cargas de trabalho. Preencher cada placa com pesos estáticos não deixa espaço para a inferência propriamente dita.

A representação nativa de baixa precisão do Kimi K3 ajuda nesse ponto. Pesos de aproximadamente quatro bits exigem muito menos armazenamento do que pesos convencionais de 16 bits. Essa redução é uma razão central pela qual o checkpoint completo pode caber na memória agregada relatada.

O suporte à execução no hardware continua desigual. Placas de consumo podem lidar com o formato armazenado de maneira diferente dos aceleradores mais novos de datacenters. Alguns runtimes convertem valores durante a computação, criando trabalho adicional e tráfego de memória.

Kernels personalizados podem reduzir essa diferença. Um kernel é um programa especializado de GPU para operações como multiplicação de matrizes, atenção, roteamento ou conversão de dados. Bons kernels mantêm as unidades aritméticas ocupadas enquanto minimizam a movimentação de memória.

O modelo da Moonshot introduz operações que os mecanismos de inferência de uso geral historicamente não suportavam. O trabalho desde o primeiro dia de projetos como vLLM e de fornecedores de hardware indica quanto esforço de software existe por trás de um lançamento aparentemente simples de modelo.

A implantação vinculada à Bittensor adiciona outra dimensão. Segundo relatos, ela distribui essas operações por muitos dispositivos menores conectados por Ethernet.

Esse design se assemelha tanto a um sistema de armazenamento quanto a um servidor convencional de IA. Ele precisa localizar componentes do modelo, mover solicitações aos recursos corretos e tolerar desequilíbrios entre dispositivos.

O sistema também precisa impedir que workers lentos atrasem todos os tokens. Na inferência sincronizada, uma conexão ou placa sobrecarregada pode se tornar um gargalo que determina a latência total.

O balanceamento de carga é especialmente difícil porque a popularidade dos especialistas pode ser desigual. Alguns especialistas podem receber mais tokens do que outros, produzindo pontos quentes mesmo quando os pesos são distribuídos uniformemente.

A Moonshot afirma que sua infraestrutura de treinamento tratou do uso equilibrado de especialistas, mas as cargas de trabalho de serving ainda podem variar. Diferentes idiomas, prompts de programação, imagens e tarefas de raciocínio podem gerar padrões de roteamento distintos.

É por isso que testes repetíveis com cargas de trabalho são importantes. Um cluster otimizado para uma categoria de prompts pode se comportar de forma diferente sob outra.

Para a Bittensor, essas medições poderiam se tornar parte do desenho de incentivos. Os validadores poderiam avaliar latência, throughput, qualidade, disponibilidade e diversidade de cargas de trabalho, em vez de recompensar apenas hardware bruto.

Se esse sistema funcionar, operadores independentes poderão competir pela qualidade de implementação. Melhor posicionamento, kernels e roteamento se traduziriam em melhores pontuações, em vez de permanecerem como vantagens internas de um único provedor de nuvem.

Essa é a interpretação mais interessante da alegação. As 80 GPUs são evidência de uma superfície de engenharia na qual participantes distribuídos podem experimentar.

A interpretação menos convincente trata a própria contagem de hardware como a conquista. Clusters grandes não são novidade. O que importa é se este produz um serviço repetível, com economia útil e desempenho confiável.

O que os leitores do Google News devem acompanhar a seguir

Três sinais determinarão se a implantação relatada se tornará infraestrutura ou continuará sendo uma demonstração impressionante.

O primeiro sinal é uma divulgação técnica reproduzível. A equipe deveria publicar seu software de serving, topologia, configurações de precisão, configuração de inicialização e procedimento de benchmark.

Os logs devem mostrar velocidade de processamento de prompts, velocidade de geração, tempo até o primeiro token e throughput agregado. Os testes devem cobrir prompts curtos, contextos longos, várias solicitações simultâneas e diversos comprimentos de saída.

Resultados de qualidade do modelo devem acompanhar as medições de velocidade. Isso revelaria se a implantação preserva o comportamento esperado do Kimi K3 sob o formato numérico e runtime escolhidos.

A reprodução independente fortaleceria ainda mais o caso. Desempenho semelhante em outro cluster de 80 placas transformaria uma alegação isolada em um método de implantação documentado.

O segundo sinal é um serviço Bittensor ativo respaldado por múltiplos operadores. Um cluster centralizado pode validar a arquitetura de software, mas não testa a tese mais ampla de descentralização da rede.

Um próximo passo significativo distribuiria o trabalho de inferência entre miners controlados de forma independente, mantendo uma saída previsível. Os validadores precisariam verificar resultados, medir desempenho e responder à entrada ou saída de nós.

O sucesso sustentaria o argumento de que a Bittensor pode coordenar a inferência de grandes modelos além de uma única instalação. O fracasso sugeriria que a sobrecarga de rede e confiança continua alta demais para uma geração estreitamente sincronizada.

O terceiro sinal é o desempenho sob demanda real. Um benchmark de um único fluxo precisa se tornar um serviço sustentado que atenda usuários simultâneos.

Acompanhe dados sobre total de tokens por segundo, percentis de latência, tempo de atividade, uso de energia e recuperação após falhas de dispositivos. Esses números mostrarão se o cluster pode competir como um sistema operacional, e não como uma exibição técnica.

Alternativas de datacenter continuarão melhorando durante essa avaliação. AMD, Nvidia e equipes de software de inferência já estão otimizando o Kimi K3 para aceleradores com pools de memória maiores e interconexões mais rápidas.

A rota de consumo, portanto, enfrenta um alvo em movimento. Ela não precisa superar todos os supernós. Precisa oferecer uma combinação atraente de acessibilidade, utilização, resiliência e qualidade de saída.

Os desenvolvedores devem tratar a implantação relatada como um teste útil de limites. Ela sugere que modelos de pesos abertos com trilhões de parâmetros já não pertencem exclusivamente a alguns poucos clusters de laboratório.

Os compradores empresariais devem continuar sendo mais cautelosos. Eles precisam de segurança auditada, níveis de serviço previsíveis, latência estável e responsabilidade clara quando ocorrem falhas.

As equipes de produto de IA também devem separar a qualidade do modelo da qualidade de sua operação. O Kimi K3 pode ter um desempenho sólido em avaliações, enquanto uma implantação específica ainda enfrenta dificuldades com o tamanho do contexto ou picos de tráfego.

A manchete do Google News abre uma conversa importante sobre quem consegue operar modelos em escala de fronteira. A próxima etapa exige evidências de que outras equipes conseguem inspecionar, reproduzir e testar sob pressão.

Os participantes do Bittensor publicarão a configuração e a executarão como um serviço mensurável com múltiplos operadores? Esse resultado, e não apenas a contagem de 80 GPUs, determinará se isso se tornará uma nova opção de infraestrutura.