Quando eu vejo a Nokia “ressurgindo” depois de anos fora do jogo de celulares, eu não penso em marketing. Eu penso em arquitetura: a empresa decidiu voltar ao core onde existem megainvestimentos (centros de dados, redes ópticas e a malha que interliga servidores) e está tentando capturar parte do gasto que hoje alimenta IA. Segundo o Olhardigital.com.br, a mudança vem de uma combinação de liderança mais focada em data centers e aquisições voltadas a tecnologia óptica — e a aposta faz sentido técnico. Mas, do ponto de vista de desenvolvedor, a pergunta real é: isso vira vantagem concreta para quem programa, deploya e constrói sistemas com baixa latência?
O que mudou na Nokia: de “celular” para infraestrutura de IA
Segundo o Olhardigital.com.br, a Nokia saiu do protagonismo em aparelhos móveis e acelerou sua transformação para fornecedora de infraestrutura para inteligência artificial. Traduzindo do mundo do “produto” para o mundo do “sistema”: ela está mirando camadas que impactam diretamente desempenho, custo e confiabilidade de data centers.
O movimento concentra esforços em equipamentos e softwares que atuam na comunicação entre servidores, redes ópticas e no gerenciamento do tráfego de dados. Isso é crucial porque IA em escala não é só GPU. É o conjunto: rede, sincronização, topologia, troca de pacotes, controle de congestionamento e observabilidade do tráfego.
Por que infraestrutura importa tanto para IA (e por que o mercado “compra” isso)
Treinar e inferir modelos grandes é uma corrida constante entre compute e movimentação de dados. Se a rede falha em sustentar throughput e latência previsíveis, você perde eficiência nos clusters — e isso vira custo operacional.
- Rede como gargalo: em muitos pipelines, o tempo de comunicação entre nós vira dominante.
- Óptica e escalabilidade: redes ópticas ajudam a escalar capacidade e reduzir limitações de banda em distâncias e topologias.
- Gerência de tráfego: não basta ter banda; precisa gerenciar rotas, congestionamento e políticas para manter SLA.
Na minha experiência construindo sistemas distribuídos, “infra” parece invisível até dar ruim. A diferença entre uma rede bem configurada e outra mal alinhada aparece em coisas como throughput instável e caudas de latência (p99) ruins — e IA sente isso rápido.
O papel da liderança e da aquisição (Infinera): por trás do “por que agora”
O Olhardigital.com.br cita que a nova fase ganhou força com a chegada do presidente-executivo Justin Hotard, ex-líder em data centers e IA na Intel, e com a aquisição da Infinera, especializada em tecnologia óptica.
Eu vejo isso como uma correção de rota. Trocar apenas narrativa por tecnologia costuma falhar. Mas quando a empresa entra em uma trilha onde já existem competências e portfólio (óptica e interconexão), ela reduz risco de “roadmap futurista” e aumenta chance de vender soluções integráveis em instalações reais.
Comparação com alternativas reais: por que isso não é só “mais um fornecedor”
No mercado de infraestrutura, há fornecedores com foco mais amplo (cloud/hiperscalers) e outros mais especializados (componentes, comutação, transmissão, automação). A Nokia tenta se reposicionar como integradora de partes relevantes para o caminho “rede → tráfego → conectividade em escala”.
Na prática, o desafio é sempre o mesmo:
- hiperscalers conseguem desenhar tudo internamente e pressionam margem de fornecedores;
- fornecedores especializados podem ter tecnologia superior em um pedaço específico, mas sem integração completa;
- o cliente final quer time-to-deploy e previsibilidade — não só “feature no datasheet”.
Ou seja: não basta ter hardware e software. É preciso encaixar o produto no ciclo de procurement, integrar com stacks existentes e reduzir risco de operação.
Como essa estratégia vira impacto no dia a dia de quem desenvolve
Você pode estar pensando: “Ok, isso é bolsa e empresas. Eu programo. Onde eu sinto isso?”. Sinto em três frentes: observabilidade, performance consistente e custo previsível de execução.
1) Latência p99 e “caudas” em aplicações distribuídas
IA (treino e inferência) usa coletivas distribuídas e tráfego em rajadas. Se a rede não lida bem com congestionamento ou não tem controle fino, a cauda de latência explode. Em sistemas que dependem disso (RAG, pipelines com múltiplas chamadas, filas com backpressure), você paga em tempo e em reprocessamento.
Quando infraestrutura melhora (topologia, políticas e gerenciamento de tráfego), fica mais fácil manter latência consistente. Isso facilita tuning de batch sizes, paralelismo e estratégias de cache.
2) Throughput e custo por token
Em inferência, o custo por token depende do tempo total e do uso eficiente dos recursos. Se a rede limita o escalonamento eficiente, você perde tokens por segundo para o mesmo custo de compute.
Eu gosto de medir isso com indicadores simples: tokens/s por GPU efetiva e re-tentativas por saturação. Quando a infra melhora, o software passa a “ter chão” para otimizações que antes não apareciam.
3) Observabilidade e automação de rede
Um ponto frequentemente ignorado: IA exige telemetria. Você precisa entender drops, retransmissões, jitter e variação. Infra que vem com tooling de gestão e integração pode reduzir tempo de diagnóstico — e isso é produtividade real para equipes.
Na minha experiência, boa observabilidade vira “menor MTTR”. A equipe não fica horas bisbilhotando logs; ela valida hipóteses com métricas corretas.
Na Prática: como desenvolvedores podem aproveitar melhor clusters com redes e interconexão novas
Vou colocar um passo a passo que eu aplico em ambientes de IA distribuída (ou qualquer cluster com comunicação entre nós), para transformar melhor infra em ganho real no seu software.
- Meça o gargalo antes de otimizar: colete métricas de rede (latência, retransmissões, saturação) junto com métricas de GPU (utilização, tempos de espera).
- Verifique se a sua estratégia de paralelismo está alinhada com a topologia: não adianta aumentar workers se a comunicação coletiva fica “cara”.
- Controle batching e backpressure: evite que filas explodam e gerem tempestade de tráfego.
- Valide p50 e p99: para IA, o p99 frequentemente manda mais do que o p50.
- Reduza retrabalho: se a rede era instável antes, seu sistema pode estar “compensando” com reenvios. Ajuste limites e timeouts com base em dados reais.
Um teste funcional simples (que eu uso como sanity check) é simular chamadas concorrentes e medir caudas. Se p99 piora sob carga, você pode estar dependente de rede/serviço compartilhado. Um exemplo com Node.js para medir latência de requests concorrentes:
import fetch from "node-fetch";
const URL = process.env.URL || "http://localhost:8080/infer";
const CONCURRENCY = 50;
const TOTAL = 1000;
function nowMs() {
return Number(process.hrtime.bigint()) / 1e6;
}
async function one() {
const start = nowMs();
const res = await fetch(URL, { method: "POST" });
if (!res.ok) throw new Error(`HTTP ${res.status}`);
await res.text();
return nowMs() - start;
}
function percentile(values, p) {
const sorted = [...values].sort((a, b) => a - b);
const idx = Math.floor((p / 100) * (sorted.length - 1));
return sorted[idx];
}
async function main() {
const latencies = [];
let i = 0;
const workers = Array.from({ length: CONCURRENCY }, async () => {
while (true) {
const my = i++;
if (my >= TOTAL) break;
try {
latencies.push(await one());
} catch (e) {
// log mínimo: em produção você registraria com tracking
}
}
});
await Promise.all(workers);
console.log("count:", latencies.length);
console.log("p50:", percentile(latencies, 50).toFixed(2), "ms");
console.log("p90:", percentile(latencies, 90).toFixed(2), "ms");
console.log("p99:", percentile(latencies, 99).toFixed(2), "ms");
}
main().catch(console.error);
Por que isso importa? Porque quando a infra melhora (como a Nokia mira), você quer garantir que seu sistema “aproveitou” a estabilidade. Se a cauda não melhora, talvez o gargalo esteja em outra camada (GC, serialização, filas, CPU de pré-processamento, ou limites de serviço).
Erros Comuns: o que devs e engenheiros costumam fazer (e que atrapalha quando a infra muda)
Esse é o trecho que eu mais vejo em time real. Mudou rede, mudou equipamento, e mesmo assim o ganho não aparece. Normalmente é um desses motivos:
1) Otimizar só GPU e ignorar comunicação
Quando você aumenta batch size ou mexe em kernels sem olhar comunicação, pode até melhorar um pedaço e piorar outro. Com IA distribuída, “o todo” manda.
2) Benchmarks curtos que não mostram caudas
Se você mede só média em 30 segundos, você esconde jitter e congestionamento. Eu sempre peço p95/p99 com carga sustentada.
3) Timeouts e retrys agressivos
Infra instável gera reenvios. Mas se depois a infra melhora e você não ajusta, você continua “pagando” custo e latência. Isso pode mascarar ganhos.
4) Falta de correlação entre métricas
Sem correlacionar logs/trace com métricas de rede e de compute, você não sabe onde está o problema. E aí qualquer mudança vira “achismo”.
5) Não revisar limites de filas e backpressure
Se o cluster aguenta mais throughput, mas sua API continua com mesma política de fila, você vai saturar a camada de aplicação primeiro. O ganho de infra fica preso no design do software.
O risco real dessa “nova Nokia”: transformar entusiasmo em resultados consistentes
O Olhardigital.com.br faz um alerta importante: a estratégia depende de transformar o entusiasmo do mercado em resultados financeiros consistentes. Eu traduziria isso como: vender é uma coisa; operar, integrar e manter margens é outra.
Para empresas de infraestrutura, o ciclo é lento e cheio de dependências:
- integração com stack do cliente (automação, observabilidade, orquestração);
- certificações e validações em ambientes complexos;
- confiança operacional (SLA, uptime, suporte 24/7);
- competição com fornecedores consolidados e com soluções custom dos próprios hiperscalers.
Na minha visão, isso afeta diretamente quem trabalha com software porque qualquer atraso na entrega de capacidade “muito prometida” vira projeto redondo e custoso de migração. Então, do lado técnico, a recomendação é simples: se você depende de melhorias na rede para escalabilidade, trate isso como uma premissa verificável. Teste em ambiente controlado e meça.
FAQ
A Nokia está voltando para competir com provedores de nuvem (AWS/GCP/Azure)?
Não é o foco. Pelo que o Olhardigital.com.br descreve, a Nokia mira infraestrutura (rede, óptica, gerenciamento de tráfego) para data centers. Isso é diferente de competir com cloud na camada de serviços. Na prática, ela tenta ser “peça” no ecossistema, não o ecossistema inteiro.
Como um dev percebe que melhorias de rede realmente ajudaram na IA?
Você mede p50/p99 de latência e throughput efetivo (por exemplo, tokens/s). Além disso, correlaciona com métricas do cluster: waits, retransmissões, jitter e saturação. Sem correlação, você fica só com sensação.
Óptica e gerenciamento de tráfego impactam inferência em produção?
Sim. Mesmo em inferência, você tem comunicação entre serviços (microserviços, gateways, workers) e frequentemente entre nós/GPUs em pipelines paralelos. Se houver estabilidade maior e menos congestionamento, você reduz caudas e melhora custo por unidade.
Quais otimizações de software eu devo revisar depois que a infra melhora?
Timeouts, retry/backoff, batch sizing e políticas de fila/backpressure. Também vale revisar limites de concorrência e pontos de serialização/transformação de dados que podem virar novo gargalo.
Que tipo de benchmark evita conclusões erradas?
Benchmark com carga sustentada e coleta de percentis (p95/p99). Eu também gosto de rodar comparações A/B com o mesmo dataset e mesmas configurações por tempo suficiente para deixar o sistema “esquentar”.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.