Os erros de dados silenciosos, ou corrupção silenciosa de dados (Silent Data Errors/Silent Data Corruption), revelam uma lacuna crescente entre a aprovação de um chip nos testes de fabricação tradicionais e sua capacidade de produzir resultados corretos durante todo o período de operação. Um processador pode passar por testes ATPG, testes de defeitos de transição e de defeitos presos, além de testes estruturais em velocidade, e ainda executar uma operação de forma incorreta sem registrar uma falha clara, antes que o resultado corrompido chegue a um aplicativo ou a uma tarefa de treinamento de inteligência artificial.
Esta análise baseia-se em um estudo publicado pela Semiconductor Engineering em 10 de setembro de 2026, reunindo opiniões e resultados da Advantest, Siemens EDA, NXP, Synopsys, Intel, Meta, Google e proteanTecs. Não se trata do lançamento de um produto específico, mas de uma mudança na forma de definir a qualidade do processador, testar sua cobertura e gerenciá-lo depois que chega ao data center.
Um problema raro no nível do chip, amplo no nível da frota
Os erros de dados silenciosos parecem raros quando medidos em um único dispositivo, mas tornam-se frequentes e dispendiosos quando milhões de processadores operam com altas taxas de utilização. Análises iniciais da Google e da Meta indicam que esses erros podem afetar um em cada mil servidores, o equivalente a um nível entre 100 e 1.000 peças defeituosas por milhão. Mesmo uma taxa de 10 FIT, ou seja, uma falha a cada bilhão de horas de operação, pode significar a ocorrência de um erro aproximadamente a cada quatro dias quando 10 milhões de dispositivos são implantados.
O perigo está no fato de que o erro pode aparecer como um resultado numérico incorreto ou um valor indefinido, e depois causar corrupção de bancos de dados, comportamento inesperado de um modelo de inteligência artificial ou resultados analíticos contraditórios. Como o próprio processador pode não enviar um sinal de erro, a falha talvez só seja detectada depois que um resultado ilógico aparece no fim de uma tarefa longa.
Por que os testes tradicionais falham?
Os erros silenciosos estão associados a defeitos marginais, como conexões metálicas de alta resistência, defeitos de ponte fracos e variações de temporização e tensão, além dos efeitos do envelhecimento, da radiação e das condições de temperatura e carga. Suas probabilidades aumentam com os nós de fabricação avançados, nos quais as margens se tornam menores e as conexões, menores e mais resistentes; além disso, os encapsulamentos baseados em chiplets aumentam a complexidade dos caminhos de verificação.
O setor estima que cerca de 80% dos erros de execução corrompida estejam relacionados a defeitos que escapam aos testes de tempo zero, enquanto os 20% restantes aparecem de forma intermitente ou como resultado do envelhecimento. No entanto, testar todas as combinações possíveis de tensão, frequência, temperatura, idade e tipo de carga não é viável. Além disso, relacionar uma falha que surgiu no nível do sistema a um padrão de defeito específico no teste do chip pode levar semanas e exigir a colaboração das equipes de projeto, teste, análise de falhas e integração de sistemas.
A Siemens EDA aponta que depender da comutação de uma única entrada ao testar defeitos de atraso pode não simular a operação funcional real, pois a comutação de múltiplas entradas pode produzir atrasos maiores. Por isso, os testes precisam atingir múltiplos pontos de tensão, temperatura e frequência, em vez de se limitar a modelos de defeitos estruturais que não cobrem todas as condições de uso.
Testes mais profundos, da fábrica ao data center
Esse problema redefine o conceito de cobertura de teste. Em vez de contabilizar a porcentagem de defeitos de fabricação conhecidos que o teste consegue detectar, a cobertura também passa a estar relacionada à probabilidade de descobrir uma resposta computacional incorreta durante uma operação real e sob uma carga efetiva. Por isso, as empresas estão adotando testes funcionais no nível do sistema, testes conscientes da carga e testes no modo de tarefa, além de aprimorar o projeto do teste incorporado e o monitoramento das margens dentro do chip.
A experiência da Intel demonstra a dimensão do desafio. Depois de testar 1,2 milhão de processadores ao longo de cinco gerações de processadores Intel Xeon, a empresa precisou de mais de 1.000 testes funcionais no conjunto DCDiag e de 5.000 testes de estresse sintéticos para detectar defeitos de erros silenciosos. Os testes não estavam distribuídos igualmente entre os defeitos: cerca de 50% das peças defeituosas podiam ser detectadas usando apenas 5% dos testes, enquanto a detecção de 90% dos erros exigia mais da metade dos mil testes. Os resultados também mostraram que mais de 70% dos defeitos eram detectados por apenas um teste e que a receita de teste eficaz para uma geração de produtos não era diretamente transferível para a geração seguinte.
O que muda, na prática, nas frotas?
A resposta não termina no portão da fábrica. As empresas que operam data centers utilizam camadas de verificação por software e testes em campo para isolar servidores ou núcleos que apresentam comportamento anormal. Na Meta, o programa Fleetscanner retira o servidor de serviço e o executa em testes computacionais com resultados conhecidos, enquanto o programa Ripple executa padrões curtos durante a operação normal. Já o Hardware Sentinel analisa exceções de aplicativos e o comportamento do sistema sem reservar cargas de teste, e a Meta afirmou que ele melhorou a detecção em 40% em comparação com métodos baseados em testes, em diferentes arquiteturas, aplicativos e data centers.
A Google utiliza um conjunto de mecanismos de proteção, incluindo a verificação de conjuntos de teste de ponta a ponta, cálculos duplicados e sua comparação, verificações de invariantes e asserções, verificação dos dados durante sua transferência e verificação periódica dos dados armazenados. A medição de aplicativos, como a abordagem Spanner, também pode detectar corrupção e remover do conjunto de dispositivos suspeitos, enquanto os métodos de verificação são ajustados quando os dispositivos retornam, para identificar os núcleos suscetíveis ao problema antes que ele se agrave.
Do teste de expedição ao gerenciamento do ciclo de vida do silício
Essas tendências impulsionam o monitoramento contínuo das margens de temporização, tensão, temperatura e degradação, além do uso de análise de séries temporais e aprendizado de máquina para detectar desvios antes que se transformem em um erro silencioso. As medições paramétricas e os modelos de aprendizado de máquina podem ajudar a isolar dispositivos que se desviam de seu perfil esperado, enquanto testes variados de instruções, execução redundante e comparação entre núcleos podem aumentar as chances de detecção.
Mas essa abordagem não elimina as limitações. Não existe um único método capaz de capturar todos os mecanismos de erro, os resultados dos testes não são transferidos automaticamente de um projeto para outro e o diagnóstico da causa raiz continua difícil quando o efeito aparece no aplicativo, distante do defeito físico. A análise também indica que o compartilhamento de dados de falhas entre fabricantes, fornecedores de ferramentas de teste, operadores de data centers e universidades ainda é limitado por considerações comerciais e jurídicas. Portanto, a mudança efetiva não consiste em adicionar um teste isolado, mas em construir uma cadeia de visibilidade que se estenda da fabricação à operação, reconhecendo que a qualidade do processador não é totalmente determinada no momento de sua expedição.