A IBM teve o maior tombo nas ações em quase seis décadas, e isso não foi “só” variação de mercado. Segundo o Olhardigital.com.br, a prévia da receita do 2º trimestre ficou abaixo do esperado por causa de um efeito bem concreto: a cadeia de fornecimento de semicondutores está em modo escassez, e isso acabou deslocando gastos dos clientes para chips, servidores e memória — derrubando espaço orçamentário para outras tecnologias e softwares. Na prática, isso é um aviso de engenharia: IA não é só modelo. É hardware, prazos, custos e trade-offs que chegam até o backlog do seu produto.
O que aconteceu com a IBM (e por que isso importa para devs)
Segundo o Olhardigital.com.br, a IBM atribuiu o desempenho fraco a uma mudança no perfil de investimentos dos clientes. Com a expansão dos data centers voltados a IA, a escassez global de semicondutores — especialmente chips de memória — elevou custos e afetou timing de entregas. Com isso, clientes passaram a priorizar:
- compra de chips e servidores;
- armazenamento e memória para sustentar cargas de IA;
- projetos que conseguem “rodar agora”, deixando menos prioridade para mainframes e certos softwares.
Isso vira um efeito cascata: quando o orçamento migra para infraestrutura (capex) e o cronograma de hardware trava, todo ecossistema de software sente. Mesmo empresas de software do setor, que não fabricam chips, sofrem por demanda adiada.
Escassez de semicondutores: como isso “entra” no seu código
O mercado costuma narrar semicondutores como “um tema de hardware”. Para quem desenvolve, o ponto é: escassez vira latência de decisão. Se a empresa não consegue comprar memória ou acelerar capacidade, você passa a ver mudanças em tempo real no desenvolvimento e na operação:
- limites de escala: menos GPUs/servidores disponíveis por período;
- replanejamento: redução do escopo de features ou atrasos em migrações;
- mudança de arquitetura: mais otimização de custo (caching, batching, compressão, quantização);
- trade-off de qualidade: menor tamanho de modelo, menos contexto, ou maior uso de distillation.
Em ambientes de IA, “o algoritmo” continua importante, mas “o pipeline” decide se o sistema vai aguentar custo e prazo.
IA não é só treino: por que memória e servidor aparecem mais
O Olhardigital.com.br menciona que a escassez é especialmente forte em chips de memória. Isso faz sentido técnico. Em cargas de IA, memória vira gargalo em pelo menos três frentes:
- KV Cache em inferência (transformers acelerados por contexto longo);
- batching e paralelismo (mais tokens em paralelo exigem mais VRAM/RAM);
- armazenamento de embeddings e índices (RAG não vive só de modelo).
Quando memória falta, você frequentemente ajusta parâmetros como tamanho de lote, duração de cache e estratégia de shard. Ou seja: impacto direto no throughput e no custo por requisição.
Comparando abordagens: o que as empresas fazem quando falta hardware
Na minha experiência com sistemas de IA em produção, quando o hardware encarece ou atrasa, você vê três caminhos típicos:
- Otimização no modelo: quantização (ex.: INT8/INT4), distilação, pruning e ajuste de contexto;
- Otimização no serving: batching inteligente, roteamento por perfil de requisição, caching de respostas/trechos, speculative decoding;
- Rearquitetura do fluxo: mais RAG em vez de gerar tudo, fallback com modelos menores, chamadas assíncronas e filas.
O erro comum é tratar isso como “itens de backlog técnico”. Em escassez, são decisões de negócio: se você não reduz custo por token/req, você simplesmente fica sem margem para crescer.
Na Prática: como eu adapto um serviço de IA quando o custo de memória sobe
Vou descrever um passo a passo que eu já apliquei quando o time precisou reduzir consumo de VRAM sem derrubar muito a qualidade. A ideia é atacar “onde a memória morre” primeiro: KV cache e concorrência.
-
Instrumente antes de mexer:
meça p95/p99 de latência, throughput, tamanho médio de prompt e taxa de reutilização de contexto.
Sem isso, você só “chuta”. -
Imponha limites de contexto:
aplique truncation e regras por intenção (ex.: sumarize histórico).
Motivo: KV cache cresce com tokens. -
Use batching com teto de tokens:
em vez de “N requisições por lote”, faça “até X tokens por lote”.
Isso evita estouro de memória em picos. -
Cache de trechos estáveis:
se você faz RAG, cacheie embeddings/trechos recuperados e normalize queries quando possível. -
Fallback com modelo menor:
quando detectar prompt longo ou carga alta, use rota para modelo menor/diferente.
Motivo: garantir SLO. -
Reavalie quantização:
quantize e rode testes A/B para medir queda real de qualidade.
Nem toda quantização vale a pena.
Um exemplo funcional de “batching por tokens” em Node.js (esqueleto). Ele não é um framework completo, mas mostra o mecanismo para você adaptar ao seu runtime:
const queue = [];
let timer = null;
function estimateTokens(text) {
// Placeholder: use um tokenizer real (tiktoken, sentencepiece, etc.)
return Math.ceil(text.length / 4);
}
function enqueueRequest(req) {
return new Promise((resolve, reject) => {
const item = { req, resolve, reject, tokens: estimateTokens(req.prompt) };
queue.push(item);
scheduleFlush();
});
}
function scheduleFlush() {
if (timer) return;
timer = setTimeout(flushBatch, 10); // 10ms window
}
async function flushBatch() {
clearTimeout(timer);
timer = null;
const MAX_TOKENS = 6000; // ajuste conforme seu limite de memória
let batchTokens = 0;
const batch = [];
while (queue.length > 0) {
const next = queue[0];
if (batchTokens + next.tokens > MAX_TOKENS && batch.length > 0) break;
batchTokens += next.tokens;
batch.push(queue.shift());
}
// Aqui você chama seu modelo/serving em modo batch
// Exemplo: await model.generate(batch.map(x => x.req.prompt))
const outputs = await fakeGenerate(batch.map(x => x.req.prompt));
batch.forEach((item, idx) => item.resolve(outputs[idx]));
}
async function fakeGenerate(prompts) {
// Simula geração
return prompts.map(p => `resp: ${p.slice(0, 30)}...`);
}
// Exemplo de uso:
(async () => {
const p1 = enqueueRequest({ prompt: "Explique caching em LLMs..." });
const p2 = enqueueRequest({ prompt: "Como reduzir KV cache para contexto longo?" });
console.log(await Promise.all([p1, p2]));
})();Por que isso funciona? Porque ele impede que o sistema aceite um lote “grande em número” mas “explosivo em tokens”. Em escassez de memória (e portanto menos capacidade), tokens por batch viram o controle mais direto de estabilidade.
Erros Comuns: o que devs fazem e que vira armadilha
Quando vejo times tentando “compensar” escassez com engenharia sem estratégia, aparecem alguns padrões:
-
Otimizar só o modelo e ignorar o serving:
você diminui custo de compute, mas ainda estoura VRAM por concorrência e KV cache. -
Batching por quantidade (N req) em vez de tokens:
isso falha nos picos de prompt longo. A latência e o OOM aparecem do nada. -
Não medir SLOs por perfil de requisição:
tratar tudo igual não revela que “um tipo de request” está dominando memória/custo. -
Truncation ingênua do prompt:
cortar no fim pode destruir contexto de instrução. Em LLMs, a posição do erro importa. -
Ignorar RAG/embeddings e querer resolver tudo com geração:
quando faltam recursos, a geração completa é a coisa mais cara. -
Deixar o cache sem estratégia de invalidação:
cache “pra sempre” pode piorar qualidade e vazar memória (ou resultados desatualizados).
Implicações práticas para quem programa (produto, arquitetura e operação)
Mesmo que você não trabalhe na cadeia de suprimentos, você sente isso na operação:
- Cloud bills sobem → pressão para otimização de throughput e redução de tokens.
- Capacidade fica intermitente → mais filas, timeouts e necessidade de backpressure.
- Backlog muda de prioridade → segurança e features competem com “manter SLO em custo viável”.
- Testes de carga viram obrigatórios → “funciona no dev” não escala sem memória.
Em outras palavras: a conversa deixa de ser só “arquitetura limpa” e vira engenharia orientada a restrição real.
O que podemos aprender do “tombo” da IBM
O ponto mais útil aqui não é prever o próximo movimento de ações. É entender o mecanismo. Segundo o Olhardigital.com.br, o hardware escasso empurra gastos de tecnologia para componentes. Isso reduz espaço para certos softwares e tecnologias que dependem de ciclos de compra mais longos.
Para desenvolvedores, isso significa que a tecnologia que você escolhe hoje precisa sobreviver a restrições de supply. Estratégias como:
- serving eficiente (batching por tokens, cache bem feito);
- rotas por capacidade (modelo pequeno/normal);
- design de produto orientado a custo (SLO por perfil);
- arquiteturas que degradam com elegância;
viram vantagem competitiva. Não é “otimização premium”. É resiliência.
FAQ
Escassez de semicondutores afeta apenas empresas de hardware?
Não. Segundo o Olhardigital.com.br, a escassez fez clientes priorizarem chips e infraestrutura. Isso adia compras de outras tecnologias e derruba demanda de software. Seu produto pode sofrer mesmo sem fabricar hardware.
Como eu sei se o gargalo no meu sistema de IA é memória (e não compute)?
Olhe OOM/fragmentação, comportamento sob picos de prompt, e métricas de KV cache/VRAM. Se a latência explode quando o tamanho do contexto cresce, a memória é suspeita forte.
Truncation resolve o problema de custo automaticamente?
Não automaticamente. Pode melhorar custo, mas pode degradar qualidade. O que funciona é truncar com regras (ex.: manter instruções, resumir histórico) e medir impacto em A/B.
Batching aumenta throughput, mas como evitar estouros de memória?
Use “teto por tokens” e limites de concorrência. Batching por número de requisições costuma falhar em prompts longos.
Qual abordagem costuma dar melhor ROI quando falta capacidade?
Na prática, a melhor combinação costuma ser: RAG mais forte (reduz geração), caching bem definido, fallback com modelo menor e ajuste de serving (tokens por batch). O conjunto reduz custo e aumenta estabilidade.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.