A capacidade de computação não utilizada à nossa volta

Às vezes, uma grande questão de infraestrutura começa com uma imagem muito pequena: um smartphone está no carregador durante a noite. O portátil está fechado. A consola de jogos espera na sala. O carro está na garagem. Em todo o lado existe capacidade de computação já paga, ligada à corrente e quase sempre sem fazer nada.

Ao mesmo tempo, surgem novos centros de dados tão grandes como instalações industriais. Pavilhões cheios de GPUs, fibra ótica, transformadores, tecnologia de arrefecimento e contratos de energia. Estamos a construir uma nova camada de infraestrutura digital que deverá sustentar a nossa escrita, pesquisa, programação, análise e, talvez um dia, também decisões.

E se uma pequena parte desta capacidade não se perdesse simplesmente? Não como uma fantasia em que cada telemóvel substitui de repente um centro de dados. Mas como uma experiência mental séria: poderia existir uma espécie de rede inteligente de computação em que dispositivos contribuem capacidade de forma voluntária, limitada e remunerada?

No artigo De PRISM aos prompts abordo o outro lado desta evolução: a crescente dependência de poucas plataformas de IA, sobretudo dos EUA e da China. Aqui interessa-me a ideia contrária. Não como romantismo P2P ingénuo, mas como pergunta técnica: quanta capacidade de computação já está distribuída por aí, que tarefas de IA poderiam sequer ser distribuídas, e o que teria de acontecer para que as pessoas fossem pagas de forma justa?

A experiência mental

IA não é simplesmente software. IA é eletricidade, arrefecimento, fibra ótica, GPUs, terreno, água e capital. A Agência Internacional de Energia estima que, em 2024, os centros de dados consumiram cerca de 415 TWh de eletricidade em todo o mundo, aproximadamente 1,5 por cento do consumo global de eletricidade. Até 2030, esse valor poderá chegar a cerca de 945 TWh.

Isto não é apenas um número para relatórios de sustentabilidade. É política de infraestrutura. Os serviços de IA estão disponíveis 7x24. Cada resumo, cada pergunta de código, cada imagem, cada execução de agente é uma computação. E quando milhares de milhões de pessoas e empresas colocam trabalho em ciclos de IA, isso transforma-se numa carga de base.

Por isso compreendo o fascínio por grandes soluções centrais. Centros de dados são controláveis: o mesmo hardware, os mesmos racks, as mesmas redes, zonas de segurança claras, SLAs, monitorização, faturação. Do ponto de vista operacional, isto é atraente. Mas política, económica e arquitetonicamente volta a criar exatamente aquilo que sempre nos tornou vulneráveis na rede: poucos centros de poder.

A experiência mental começa, por isso, com uma contra-pergunta simples: o que já existe antes de construirmos o próximo centro de dados?

Qual é o tamanho da capacidade não utilizada?

A ideia nasce, na verdade, num momento muito quotidiano. O smartphone está à noite na mesa de cabeceira, ligado à corrente, e quase não faz nada. Mas dentro dele há um chip com mais capacidade de computação específica para IA do que muitos computadores de há dez anos tinham no conjunto inteiro. Um iPhone 15 Pro com A17 Pro chega a cerca de 35 biliões de operações da Neural Engine por segundo. Mesmo tomando apenas uma média cautelosa, isto é absurdamente muito para um dispositivo que passa a maior parte da noite à espera.

O mesmo acontece em cima da secretária. Os novos portáteis já não têm apenas CPU e GPU, mas também NPUs ou Neural Engines. A Apple integra uma Neural Engine nos seus chips há anos. Portáteis Windows chegam como AI PCs com processadores de IA dedicados. Uma consola de jogos na sala tem capacidade de GPU que antes soaria a workstation. E, ainda assim, usamos esta computação local quase sempre apenas em picos curtos: um jogo, uma exportação, uma videochamada, um efeito local, uma pesquisa. Depois o dispositivo volta ao estado inativo.

É exatamente aqui que começa a experiência mental. Não: “posso alugar amanhã o meu iPhone como centro de dados?” Isso seria absurdo. Mas sim: se tanto silício já está pago, ligado em rede e à corrente todas as noites, qual seria a capacidade teórica se apenas pequenas janelas temporais seguras e adequadas pudessem ser utilizadas?

Não é possível medir exatamente a capacidade de computação não utilizada no mundo. Demasiados dispositivos são diferentes, demasiados estão offline, demasiados nem sequer podem participar por razões de bateria, calor, segurança ou plataforma. Ainda assim, uma estimativa grosseira ajuda a ganhar noção da ordem de grandeza.

Para isso, tomemos alguns blocos deliberadamente simples. O ponto importante é: não calculo como se cada dispositivo estivesse sempre totalmente disponível. Calculo com janelas temporais, taxas de participação e descontos cautelosos. Continua a ser uma experiência mental, mas uma com números debaixo dos pés.

Tesla: silício sobre rodas

A Tesla anunciou em junho de 2025 o oitavo milionésimo veículo produzido. Nem todos ainda estão ativos, nem todos têm o mesmo hardware Autopilot, e nem todos os proprietários libertariam o seu carro para uma rede de computação. Portanto, calculo de forma conservadora:

• Dos 8 milhões de veículos produzidos, talvez 80 por cento ainda estejam realisticamente ativos e tecnicamente relevantes. Isso daria 6,4 milhões de veículos.
• Para Hardware 3, ou seja, o computador FSD desde 2019, é frequentemente mencionada uma ordem de grandeza de 144 TOPS para o sistema.
• O Hardware 4 está em veículos mais recentes e é mais moderno, mas a Tesla não publica para ele um valor TOPS simples e limpo como nas antigas cifras do Autonomy Day. Para este cálculo, uso por isso ainda 144 TOPS como valor base conservador.
• Um carro fica muitas vezes parado 23 horas por dia, mas a janela realmente interessante é a de carregamento. Se estiver 6,5 horas ligado à corrente durante a noite, isso corresponde, em média sobre 24 horas, a cerca de 27 por cento de disponibilidade.

Se apenas 25 por cento destes proprietários Tesla ativos se inscrevessem, seriam 1,6 milhões de veículos e cerca de 62 exa-operações por segundo como equivalente diário. Com 50 por cento de participação, seriam cerca de 125 exa-operações por segundo. Se teoricamente todos os veículos ativos participassem, o valor ficaria em torno de 250 exa-operações por segundo. Na própria janela noturna, a potência instantânea seria mais alta; o valor equivalente diário é apenas a comparação mais justa com um centro de dados que funciona 24 horas.

iPhones: a maior surpresa

Nos iPhones, o cálculo é simultaneamente mais simples e mais difícil. Simples, porque a Apple entrega todos os anos volumes enormes. Difícil, porque a Apple não fornece uma tabela pública limpa sobre que geração de iPhone ainda está ativa globalmente. Por isso, uso os envios publicados dos últimos anos e aplico uma quota ativa residual plausível.

Esta conta mista resulta em cerca de 885 milhões de iPhones provavelmente ainda ativos a partir de apenas cinco anos de envios. Não é a base total instalada de iPhones, mas sim um recorte deliberadamente limitado. As gerações A14/A15 mais antigas estavam na faixa baixa dos TOPS de dois dígitos, o A16 pouco abaixo de 17 TOPS, o A17 Pro em cerca de 35 TOPS. Por isso, uma média por ano faz mais sentido do que fingir que todos os dispositivos têm o mesmo chip.

Agora, o mesmo jogo: 6,5 horas à noite ligados à corrente, não o dia inteiro. Se 25 por cento destes dispositivos participassem, chegaríamos a cerca de 1'437 exa-operações por segundo como equivalente diário. Com 50 por cento de participação, seriam cerca de 2'875 exa-operações por segundo. Se teoricamente todos os dispositivos participassem, o valor ficaria em torno de 5'750 exa-operações por segundo.

Parece louco. Mas é exatamente esse o ponto. Não porque um iPhone seja um servidor. Mas porque a massa de dispositivos é tão grande que até quotas cautelosas entram de repente numa ordem de grandeza que normalmente só atribuímos a centros de dados.

A comparação

Como outros pontos de referência, uso:

• 50 milhões de GPUs desktop, workstations ou pequenos servidores, que poderiam fornecer em média 20 TFLOPS FP32. Se apenas 20 por cento fossem utilizáveis na prática, restariam cerca de 200 exa-operações por segundo em janelas temporais adequadas.
• xAI Colossus como comparação do mundo dos centros de dados. Com 200'000 GPUs Hopper e cerca de 3'958 INT8 TOPS na ordem de grandeza de uma H100, chega-se a aproximadamente 792 exa-operações por segundo de pico teórico de IA. Esse é o pico com esparsidade; o desempenho denso e utilizável de forma contínua é inferior.

Isto não é uma capacidade global exata. É um modelo mental. E é exatamente aqui que é preciso travar: TOPS não podem ser despejados numa piscina comum como litros de água. Neural Engine TOPS de um iPhone, INT8 TOPS de uma GPU e desempenho FP32 de uma workstation são coisas diferentes. Muitos trabalhos úteis não precisam apenas de operações de computação, mas também de RAM, VRAM, largura de banda de memória, tempo de execução estável, acesso de software e um sistema operativo que sequer permita essas tarefas.

Ainda assim, a conta mostra por que a ideia não é ridícula. Mesmo uma combinação conservadora de PCs, veículos e smartphones chega, como silício teórico, a uma ordem de grandeza que, ao lado de um dos centros de dados de IA mais visíveis do mundo, já não parece absurdamente pequena.

O número dos iPhones é especialmente interessante porque considera apenas cinco anos de envios, não toda a base ativa instalada. Ao mesmo tempo, é o melhor exemplo de por que potência de pico não chega: um iPhone não é um servidor. Tem limites térmicos, lógica de bateria, regras do sistema operativo, modelos de privacidade e um proprietário que espera um dispositivo funcional de manhã. Ainda assim, há ali capacidade de computação que há poucos anos pareceria ficção científica.

E mesmo estes valores de pico são apenas valores de pico. Um smartphone, um portátil sem ventoinha ou uma unidade de controlo automóvel não consegue simplesmente fornecer essa potência durante seis horas como uma GPU de centro de dados. Limites térmicos, throttling e lógica de proteção reduzem drasticamente o desempenho sustentado. Quem quisesse construir uma rede real teria, portanto, de calcular com desempenho sustentado, não com o número mais bonito da ficha técnica.

Também se pode pensar isto através da eletricidade. Se 50 milhões de dispositivos contribuíssem em média 150 watts durante quatro horas por dia, seriam cerca de 11 TWh por ano. É apenas uma pequena fração do consumo global atual dos centros de dados. Mas seria suficiente para suportar muitas tarefas de fundo, embeddings, cargas de trabalho científicas, rendering, tarefas de verificação ou processos de armazenamento descentralizado.

A objeção incómoda é: isto não tem de ser automaticamente mais eficiente. Centros de dados têm melhor arrefecimento, melhor utilização, eletricidade mais barata, hardware mais recente e batching profissional. Um dispositivo doméstico pode ficar pior por unidade de trabalho útil, especialmente se houver muito overhead ou se a bateria de um smartphone envelhecer mais depressa por alguns cêntimos em créditos. Uma rede descentralizada de computação, portanto, não seria boa só por ser distribuída. Teria de fazer sentido líquido para cargas de trabalho adequadas: técnica, energética e economicamente.

Isto torna-se ainda mais interessante com os novos AI PCs. A Canalys esperava cerca de 100 milhões de AI PCs enviados em 2025. Muitos destes dispositivos trazem NPUs com 40 TOPS ou mais. TOPS não é o mesmo que GPU FLOPS, e uma NPU não substitui um centro de dados. Mas mesmo olhando para esta potência com muita cautela, surge uma nova classe de hardware local de IA que não existe só no papel, mas chega a escritórios e casas.

A conclusão, portanto, não é: “amanhã substituímos todos os centros de dados por PCs gaming, Teslas e iPhones.” A conclusão é: estamos a construir uma enorme nova capacidade central, enquanto ao mesmo tempo uma quantidade gigantesca de capacidade distribuída, já paga, se perde sem uso.

A capacidade de computação perde-se

Eletricidade posso armazenar. Não perfeitamente, não sem perdas, mas fundamentalmente. Se o meu sistema solar produz ao meio-dia mais do que eu preciso, a energia vai para uma bateria ou para a rede. À noite posso voltar a usá-la, ou o meu vizinho usa-a. Smart grids, baterias e modelos energéticos peer-to-peer tornam esta forma de pensar cada vez mais concreta: ora produzo, ora consumo, e a fronteira entre cliente e fornecedor fica mais suave.

A capacidade de computação funciona de outra forma.

Uma hora de GPU não utilizada ontem não posso tirá-la hoje de uma gaveta. Um processador que passou uma noite sem fazer nada não guardou computação para mais tarde. Esse tempo desapareceu. Irremediavelmente. A computação é perecível.

É exatamente isso que torna os dispositivos não utilizados interessantes. Não temos apenas hardware. Temos possibilidades que expiram constantemente. O conjunto realisticamente alcançável a curto prazo é sobretudo composto por GPUs desktop, workstations, consolas de jogos, pequenos servidores, NAS e recursos disponíveis em campus ou fornecedores. Smartphones e carros são mais casos de fronteira a longo prazo: tecnicamente fascinantes, mas claramente mais difíceis por causa de bateria, calor, regras de plataforma, segurança e controlo dos fabricantes.

Portanto, não falha apenas por causa da matemática, mas também por causa dos incentivos. Os dispositivos com o silício parado mais interessante pertencem justamente a plataformas fechadas: com o Private Cloud Compute, a Apple constrói a sua própria infraestrutura para grandes pedidos do Apple Intelligence; com o Cortex, a Tesla constrói a sua própria capacidade de treino para FSD e Optimus. Porque deveriam precisamente estas empresas abrir a sua frota de dispositivos a um mercado de computação independente do fabricante, se o controlo sobre hardware, software e cloud é o verdadeiro fosso competitivo?

Ainda assim, a pergunta de fundo permanece: porque tratamos capacidade de computação distribuída como se fosse irrelevante, enquanto construímos instalações centrais cada vez maiores?

A IA consegue sequer calcular de forma descentralizada?

Aqui é preciso ser honesto: para muito do que hoje é visível como IA, a descentralização é difícil.

Um grande modelo de linguagem não é simplesmente uma lista de pequenas tarefas que se atiram arbitrariamente para dispositivos de estranhos. Modelos precisam de RAM ou VRAM. Precisam de largura de banda de memória. Em parte precisam de interligações rápidas. Na geração de tokens, o modelo é percorrido repetidamente, e cada salto adicional pela rede torna a resposta mais lenta. Dividir um modelo de fronteira por smartphones alheios, portáteis antigos e carros seria, para uma resposta de chat interativa, quase sempre absurdo.

Mas isso não significa que IA descentralizada seja impossível. Significa apenas que é preciso escolher as tarefas certas.

Encaixam muito bem trabalhos que não precisam de terminar em dois segundos: embeddings para grandes arquivos, resumos em batch, rendering, simulações científicas, dados sintéticos, testes, crawling, tarefas de verificação, reparação de armazenamento descentralizado, pequenos modelos locais, pré-processamento e tarefas em que os resultados possam ser verificados ou calculados várias vezes.

Na prática, seria preciso separar as tarefas de forma muito mais limpa:

Grandes modelos também não estão completamente excluídos, mas precisam de outra arquitetura. Petals mostrou que inferência colaborativa e fine-tuning de grandes modelos através de recursos distribuídos são possíveis em princípio. A Prime Intellect vai com INTELLECT-2 um passo mais longe e mostra como reinforcement learning distribuído pode funcionar com workers não confiáveis, desde que os resultados sejam verificados. Ainda não é o mundo em que o teu iPhone treina secretamente o GPT-7 durante a noite. Mas é uma indicação de que o problema não é fundamentalmente impossível.

O início realista, portanto, não seria: “vamos distribuir um modelo gigante por tudo.” O início realista seria: primeiro modelos locais, conjuntos regionais para tarefas batch adequadas, tarefas verificáveis, zonas de dados claras e centros de dados centrais apenas onde são realmente necessários.

O velho sonho dos sistemas distribuídos

Há outra narrativa da Internet. Uma que soa menos a catedral e mais a enxame.

Computação voluntária

SETI@home foi sempre, para mim, um dos exemplos mais bonitos. Milhões de pessoas deixavam os seus computadores calcular em segundo plano dados da radioastronomia. Não porque recebessem um dashboard SaaS por isso, mas porque a ideia era suficientemente grande: procuramos juntos sinais no ruído do universo. Desde março de 2020, o SETI@home já não distribui novas Work Units e está numa espécie de hibernação. Mas, como prova de que computação voluntária global pode funcionar, continua importante.

BOINC, a plataforma por trás e ao lado disso, descreve sobriamente porque funciona: muitas tarefas independentes e computacionalmente intensivas, em que throughput é mais importante do que baixa latência. Esta é a diferença decisiva. Um sistema distribuído não tem de entregar cada resposta de chat interativa em dois segundos. Pode ser forte onde o trabalho é divisível, verificável e não precisa de resposta imediata.

Armazenamento sem lugar fixo

IPFS leva o mesmo pensamento para a área de armazenamento. Ficheiros não são endereçados principalmente por um lugar, mas pelo seu conteúdo. O conteúdo tem uma impressão digital. Quem o tem, pode fornecê-lo. É uma forma de pensar diferente de “este ficheiro está neste servidor sob este URL”.

Dinheiro sem contabilidade central

Bitcoin, completamente independentemente de como se avaliam especulação e consumo energético, popularizou uma ideia primária semelhante: um sistema sem contabilidade central, em que o consenso não depende de uma única instituição. Nem toda a ideia descentralizada é automaticamente boa. Mas Bitcoin mostrou que um protocolo pode ser politicamente poderoso quando remove o ponto central de controlo.

Armazenamento como rede

Também no armazenamento houve tentativas interessantes. A Symform era um fornecedor de cloud storage descentralizado no qual espaço excedente podia ser colocado numa rede. Em 2014, a plataforma foi adquirida pela Quantum; nessa altura falava-se de 45'000 utilizadores e pequenas empresas em 170 países. Storj, Sia, Filecoin e outras variantes mostram igualmente: a ideia não é nova. Só nunca chega totalmente ao quotidiano.

Hoje esta ideia continua viva em novas formas. A Storj divide ficheiros do lado do cliente, encripta-os e distribui fragmentos por muitos Storage Nodes. Isto está mais perto de infraestrutura do que de romantismo: no melhor caso, o utilizador não vê o enxame, mas sim um serviço de armazenamento que funciona.

Compute como marketplace

Golem e Akash querem tornar a capacidade de computação não utilizada acessível como marketplace. Para mim, esta é a ponte direta para este artigo: não é só espaço de armazenamento que está distribuído por aí, mas também processadores, GPUs e pequenos servidores que hoje ficam muitas vezes parados.

IA no enxame distribuído

Andrej Karpathy também reaparece neste ambiente: na Prime Intellect é citado como apoiador proeminente, e a Prime Intellect iniciou com INTELLECT-2 uma ronda de treino RL distribuída e descentralizada para um modelo de 32B parâmetros, em que recursos de computação heterogéneos e permissionless podem contribuir.

Ainda não é a resposta perfeita. Mas mostra: o sonho não desapareceu. Só procura repetidamente uma forma que sobreviva na operação real.

Aprender com a central elétrica virtual

É interessante que esta forma de pensar no setor elétrico já soe muito menos exótica.

A Tesla descreve o seu Virtual Power Plant como uma rede de fontes de energia distribuídas: casas com painéis solares e Powerwalls são consideradas em conjunto como uma central elétrica. Quando a rede precisa de apoio, as baterias podem fornecer eletricidade. O proprietário disponibiliza um recurso e recebe dinheiro ou outros benefícios. Powerwalls individuais são pequenas. Mas, em conjunto, podem tornar-se relevantes para a rede.

É exatamente a analogia que me fascina na computação. Uma única GPU em home office, um único NAS, um único iPhone ou um único carro não é um centro de dados. Mas muitos dispositivos juntos poderiam formar uma nova camada: não para tudo, não sempre, não sem regras, mas para determinadas tarefas.

A analogia tem limites. A eletricidade é muito mais fungível do que o trabalho de computação. Um quilowatt-hora não depende de estar a executar um modelo com 80 GB de VRAM, uma pipeline de embeddings ou uma reparação de armazenamento encriptado. Computação depende da carga de trabalho. Precisamente por isso são necessárias classes de tarefa, scheduling e exclusões rígidas.

Na Tesla, vê-se o mesmo pensamento até em dois lugares. Powerwalls podem tornar-se parte de uma central elétrica virtual. Os carros deverão, em perspetiva, tornar-se parte de uma frota autónoma de robotáxis, ou seja, ganhar dinheiro quando o proprietário não os está a usar. Se e quão rapidamente isso escalará de verdade é outra pergunta. Mas a ideia de base é importante: um dispositivo privado já não é apenas consumido; pode trabalhar como infraestrutura nas janelas livres.

A computação poderia ser pensada de forma semelhante. Não como venda de eletricidade ao vizinho, mas como venda de tempo de computação verificável, espaço de armazenamento ou trabalho de modelo a uma célula regional. No fim, o utilizador paga eletricidade, calor, desgaste de hardware e risco. Logo, também tem de ser remunerado. Sem esse ponto, a ideia torna-se apenas uma experiência técnica bonita.

Porque é que o enxame ganha tão raramente

Se a descentralização soa tão bonita, porque não se impõe simplesmente?

Porque a centralização é muitas vezes o melhor pacote de produto.

Um centro de dados é controlável. Um enxame é composto por dispositivos de terceiros, sistemas operativos diferentes, disponibilidade variável, fraca previsibilidade e proprietários que desligam, vendem, atualizam ou retiram o dispositivo da rede. Para um product manager, isto não é romantismo; é dor de cabeça.

Além disso, há a economia. Muitos projetos descentralizados tentaram resolver incentivos através de tokens. É compreensível, porque uma rede sem empresa central ainda precisa de remuneração. Mas assim que os custos de armazenamento ou tempo de computação ficam ligados a uma moeda volátil, torna-se pouco atraente para empresas normais. Não quero que o meu terabyte de backup fique subitamente mais caro porque uma coin é bombeada no Twitter. Também não quero que o meu orçamento para horas de GPU dependa de um mercado que se parece mais com um casino do que com infraestrutura.

E o adversário de preço não é a GPU on-demand mais cara na cloud. A comparação real são ofertas spot e preemptible, ou seja, capacidade excedente de centros de dados que fornecedores vendem com desconto significativo. Uma rede descentralizada de computação teria, portanto, de ser não só filosoficamente mais bonita. Teria de competir contra capacidade cloud muito barata, bem integrada, ainda que interrompível.

O segundo travão é a conveniência. S3 não ganhou porque é filosoficamente bonito. Ganhou porque é suficientemente simples, suficientemente documentado e integrado em todo o lado. Se redes descentralizadas de armazenamento ou computação quiserem tornar-se relevantes, têm de parecer quase aborrecidas para programadores e administradores: inserir API key, criar bucket, monitorização, fatura, SLA, teste de restore, pronto.

Depois vem a segurança. Numa rede empresarial não deve surgir de repente qualquer tarefa externa de computação a entrar em workstations. Qualquer firewall sensata bloquearia isso e, para sistemas de threat intelligence, pareceria suspeito. Na prática, tal sistema teria de funcionar mais de dentro para fora: o nó anuncia-se a uma célula, recolhe tarefas verificadas, corre numa sandbox e vê apenas dados que tem permissão para ver. Caso contrário, uma rede legítima de computação parece rapidamente, ao nível da rede, uma botnet formulada de forma muito educada.

A confiança é o próximo ponto duro. Sistemas descentralizados têm de conseguir provar que o trabalho foi executado corretamente sem que cada nó possa ver tudo. No armazenamento há componentes conhecidos: criptografia, erasure coding, auditorias, mecanismos de reparação. Em IA e computação, fica mais difícil. Como verifico se um dispositivo desconhecido executou corretamente um modelo? Como impeço fuga de dados? Como protejo o dispositivo do participante contra código externo?

O desgaste de hardware também é mais do que eletricidade. SSDs e armazenamento NVMe têm limites de escrita. Quem escreve constantemente pesos de modelo, dados temporários, batches de embeddings ou ficheiros de swap em dispositivos de consumo consome vida útil real. Soma-se o problema de largura de banda: se o download de um modelo ou dataset grande demora mais tempo e cria mais overhead de rede do que a própria computação, a conta vira. Os dados são mais pesados do que a simples metáfora da rede inteligente sugere.

É exatamente aqui que INTELLECT-2 se torna interessante. A Prime Intellect descreve no seu paper TOPLOC como um componente que verifica rollouts de inference workers não confiáveis. Isto não resolve subitamente todos os problemas de computação. Não é privacidade mágica para dados empresariais arbitrários em hardware alheio. Mas mostra um mecanismo real para uma determinada classe de trabalho de IA distribuído: as tarefas são construídas de modo que os resultados sejam verificáveis, em vez de se confiar cegamente em cada worker.

Para dados confidenciais, isso por si só não chega. Seriam necessários outros componentes: Confidential Computing, Trusted Execution Environments, Remote Attestation, sandboxes limpas, classificação clara de dados e, em caso de dúvida, a decisão dura de não executar certas tarefas em hardware alheio. A isto juntam-se perguntas aborrecidas, mas decisivas: impostos, responsabilidade, proteção de dados, residência dos dados e os termos dos fornecedores de Internet. Infraestrutura raramente falha apenas por causa da matemática. Muitas vezes falha por causa da operação.

Uma rede inteligente de computação

Não imagino um ingénuo “tudo é P2P e depois fica tudo bem”. Infraestrutura não funciona assim. O que poderia funcionar seria uma rede inteligente de computação com camadas claras.

A primeira camada chama-se: local primeiro. Tudo o que é pessoal, confidencial ou sensível à latência deve correr, tanto quanto possível, no próprio dispositivo ou no próprio espaço de confiança. Pequenos modelos, pesquisa local, resumos privados, classificação simples, pré-processamento, criptografia, embeddings para dados pessoais. Nem todos os emails, notas e pesquisas têm de ir para um hyperscaler.

A segunda camada seria regional e federada. Uma cidade, um bairro, um campus, uma empresa, uma cooperativa ou um fornecedor poderia operar uma célula. Nessa célula, dispositivos disponibilizam recursos voluntariamente, mas apenas sob condições claras: só ligados à corrente, só em inatividade, só dentro de limites térmicos, só com potência máxima definida, só para certas classes de tarefas.

O ponto de partida não seriam smartphones e carros, mas os dispositivos mais aborrecidos: GPUs desktop, workstations, consolas de jogos, pequenos servidores, sistemas NAS e capacidade livre em fornecedores locais. Smartphones poderiam mais tarde assumir pequenas tarefas de verificação. Carros seriam pensáveis ainda mais tarde, dentro de limites muito estreitos e controlados pelos fabricantes. Tal como na rede elétrica, seria preciso começar pelos recursos fiáveis, mensuráveis e controláveis.

A terceira camada continua central. Treino de modelos de fronteira, tempo real rigoroso, modelos extremamente grandes, casos especiais regulatoriamente sensíveis e cargas de trabalho com forte acoplamento continuam a pertencer a centros de dados profissionais. A descentralização não tem de substituir tudo. Tem apenas de impedir que todo o trabalho quotidiano passe automaticamente pelos mesmos cinco centros de poder.

Se quiséssemos testar isto, eu começaria pequeno. Não com milhões de iPhones, mas com uma célula regional de talvez 500 a 2'000 GPUs desktop voluntárias, workstations, sistemas NAS e pequenos servidores. Seriam permitidos apenas poucos tipos de tarefas: embeddings para dados não sensíveis, tarefas científicas em batch, fragmentos de armazenamento encriptados e tarefas de verificação. O sucesso não se mediria por um número exa bonito, mas por três métricas aborrecidas: tarefas concluídas por $1 de custo elétrico, taxa de erros e repetições, pagamento após desgaste de hardware.

A parte mais difícil seria a remuneração. O utilizador paga eletricidade, calor e desgaste de hardware. Portanto, precisa de receber algo em troca. Provavelmente seria mesmo necessário um token ou crédito. Mas não como objeto de especulação, e sim como crédito de infraestrutura.

Um crédito de computação desse tipo teria de representar algo real: um minuto de GPU de uma determinada classe, um GB-mês de armazenamento, uma inferência verificada, uma unidade de batch embedding ou uma unidade de computação equivalente a kWh. Quem fornece recursos ganha créditos. Quem depois precisa de capacidade de IA consome-os. Quem não quiser consumi-los poderia recebê-los em fiat, de forma semelhante a uma central elétrica virtual, onde não se quer ser pago em “Powerwall Coins”, mas em dinheiro real ou num crédito claro.

Mas isso não resolve magicamente a questão do preço. Estabilidade precisa de uma âncora: faturação em fiat, corredores de preço de energia, clearing regional, tarifas cooperativas ou operadores regulados. Sem governance, “créditos estáveis” tornam-se rapidamente outro token livremente flutuante. E então estamos de volta ao velho problema: infraestrutura parece um casino.

Ainda mais importante é a questão dos direitos operacionais. Não precisamos de treinar nós próprios todos os grandes modelos fundacionais. Talvez se comprem ou licenciem modelos, pesos abertos ou famílias de modelos, e depois se operem de forma descentralizada, federada e regionalmente controlada. A verdadeira soberania estaria então não apenas no treino, mas na operação: onde correm os modelos? Onde ficam os dados? Quem pode auditar? Existe um canal de retorno para o fornecedor? Posso continuar a operar o modelo localmente se política, preços ou termos mudarem?

Para que isto seja mais do que um contrato de compra bonito, tais licenças teriam de conter direitos operacionais reais: deployments locais, compromissos de atualização e segurança a longo prazo, model cards compreensíveis, auditabilidade, direitos de saída claros e nenhuma obrigação de empurrar dados sensíveis de volta para a cloud central do fabricante. Não seria a utopia descentralizada pura. Mas seria um caminho realista entre autossuficiência ingénua e lock-in total de plataforma.

A noite em que os dispositivos calculam

Imagina que são 22:43. O teu desktop com GPU está em idle, o NAS está online, o telemóvel está a carregar. Nas definições, estabeleceste: máximo 80 watts, só em inatividade, só para cargas de trabalho verificadas da região e só se a remuneração cobrir custos de eletricidade mais uma taxa de hardware.

Um agente local anuncia capacidade livre. Não com o teu nome e não com os teus dados privados, mas como nó atestado com determinadas capacidades. A célula distribui pequenas tarefas: simulações, embeddings, fragmentos de armazenamento encriptados, tarefas de verificação.

De manhã não há foguete, nenhuma história de Wall Street, nenhum hype token. Apenas uma linha sóbria:

Esta noite: 2,4 créditos de GPU ganhos, 18 GB-meses de armazenamento confirmados, $0.31 de custos elétricos estimados.

Mais tarde, usas esses créditos para um modelo local sobre os teus próprios documentos. Os dados sensíveis ficam contigo. Não és apenas cliente. És participante.

Soa romântico. Sim. Mas às vezes é precisamente isso que justifica levar a sério um problema de engenharia difícil.

O enxame e a montanha

Não acredito que os centros de dados centrais desapareçam. São demasiado eficientes, demasiado importantes e, para algumas tarefas, simplesmente necessários. A montanha permanece. A pergunta é apenas se, ao lado dela, voltamos a construir um chão.

Um chão feito de dispositivos locais, células regionais, protocolos abertos, créditos estáveis e modelos de segurança claros. Um chão onde a capacidade de computação não é apenas vendida de cima para baixo, mas flui entre participantes. Um chão onde determinado trabalho de IA corre onde pertence: trabalho privado localmente, trabalho regional regionalmente, casos-limite globais no centro de dados.

Talvez seja ingénuo. Talvez não. Centrais elétricas virtuais também já foram uma ideia estranha: milhares de pequenas baterias como uma grande rede. Dinheiro descentralizado soou absurdo durante muito tempo. Carros que conduzem autonomamente como táxis pareciam ficção científica. Nem tudo chegará como foi prometido. Mas a direção é clara: recursos que antes ficavam passivos são cada vez mais pensados como parte de um sistema maior.

Neste momento, há máquinas não utilizadas em todo o lado. Em casas, escritórios, garagens, salas de servidores e bolsos. Nem todas se adequam da mesma forma. Nem todas deveriam alguma vez executar trabalho de terceiros. Mas muitas já estão lá, pagas e ligadas à rede. E cada segundo não utilizado desaparece.

Talvez devêssemos começar a escutá-las.

Até à próxima,
Joe