3 publicações com a etiqueta "tech"

O lançamento do GPT-5 em março de 2026 trouxe três mudanças que importam mais do que os benchmarks de marketing: contexto de 10M tokens, modalidade visual + áudio nativa e redução de 60% no custo por token de output. O que isso muda na arquitetura de quem já roda IA em produção?

Contexto de 10M tokens — o que realmente significa​

10M tokens equivale a aproximadamente:

• 15.000 páginas de texto
• O Linux kernel inteiro + comentários
• ~80 horas de transcrição de podcast

Mas atenção: latência cresce não-linearmente com contexto. Em testes internos no laboratório:

Contexto    Latência média (p95)
4K          820 ms
32K         1.4 s
128K        4.8 s
512K        18 s
2M          76 s

Para a maioria dos casos, RAG bem feito com 32K de contexto ainda bate carregar 2M de tokens "para garantir". O ganho é em casos específicos: análise de codebase inteira, processamento de documentos legais longos, debugging de logs corporativos.

Multimodal nativo​

O grande salto não é "aceita imagem" — isso o GPT-4 já fazia. É que o modelo raciocina nativamente sobre o conteúdo visual e textual no mesmo passe. Em prática:

• Você manda um screenshot de erro de UI + o componente React + o stack trace
• O modelo conecta os três num único contexto de raciocínio
• Diagnóstico cai de minutos (humano vendo cada parte) para 4 segundos

Custo: 60% mais barato, mas com pegadinhas​

Output tokens caíram 60%. Input tokens caíram só 25%. Para workloads que são input-heavy (RAG, busca semântica), o ganho é menor do que parece. Para output-heavy (geração de código, escrita longa), o ganho é real.

A regra prática que estamos usando: se 70%+ do custo do seu pipeline está em output tokens, migre para GPT-5 hoje. Se está em input, espere o GPT-5 Mini sair em julho.

Quando NÃO migrar​

• Pipelines críticos com prompt engineering muito específico ao GPT-4 (vai precisar re-tunar)
• Workloads onde Claude 4.6 ainda é melhor (tarefas de raciocínio matemático e código longo)
• Aplicações com SLA agressivo de latência (GPT-5 é, em média, 15% mais lento que GPT-4o em prompts curtos)

Conclusão​

GPT-5 é evolução, não revolução. Mas a economia de output + multimodal nativo justifica a migração para a maioria dos pipelines do laboratório. Migramos 3 dos nossos 7 pipelines até agora — os outros 4 ficam no GPT-4o ou Claude até a próxima geração.

Em 2018, a AWS abriu o Firecracker (a VM minimalista que roda o Lambda e o Fargate) em Rust. Em 2022, o S3 começou a migrar componentes-chave para Rust. Em 2025, o time do EC2 anunciou que o novo controlador de placement está sendo escrito em Rust do zero. Em 2026, a Amazon publicou que 40% do código novo de infra core é Rust.

Não é hype. É decisão técnica.

O que Rust resolve que Go/C++/Java não resolviam​

Memória sem garbage collector. Lambda precisa de cold start de < 100ms — GC pause de Go (mesmo do Go 1.21+) pode estourar isso em workloads sensíveis.

Concorrência sem data races em compile-time. O borrow checker do Rust impede que você compile código com race condition. Em sistemas distribuídos críticos (S3 servindo milhões de req/s), isso elimina uma classe inteira de bugs.

Performance C/C++, segurança Java. Sem segfault, sem buffer overflow, sem dangling pointer — e com o mesmo overhead de runtime que C.

O custo real​

Rust é mais caro de escrever. A AWS aceita esse custo porque o ganho operacional (menos pages às 3 da manhã) compensa em escala.

O que isso significa para times menores​

Se você tem 5 engineers e está escrevendo uma API CRUD, Rust é a escolha errada. A produtividade cai mais do que o ganho de performance compensa.

Se você está escrevendo:

• Hot path de proxy / load balancer
• Serializer/parser que processa GB/s
• Sistema embarcado (IoT, edge)
• Service mesh / data plane

...Rust passa a fazer sentido econômico.

A migração no laboratório​

Estamos migrando um único serviço para Rust: o API gateway interno que processa autenticação de todos os pipelines de ML. Volume: ~50k req/s no pico. Razão: o serviço atual em Node consome 8 GB de RAM em pico e o cold start em deploy custa 2-3 min de degradação.

Resultado parcial (semana 3 de 12):

• RAM em pico: 8GB → 600MB
• Cold start: 2-3 min → ~3 segundos
• Custo do time: 1 engineer Rust em formação por 3 meses

Conclusão​

Rust não é "o novo Go". É a linguagem certa para sistemas onde overhead e correctness importam mais do que velocidade de desenvolvimento. Para o resto, Python/Go/TypeScript seguem sendo as escolhas certas.

A AWS migra porque a conta fecha. Para a maioria dos times, ainda não fecha.

Em 2026, "rodar IA na borda" deixou de ser pesquisa experimental e virou opção real de arquitetura. Em 6 meses no laboratório, testamos três cenários reais. O resumo: muito mais difícil do que vendem, e muito mais útil do que parece em alguns casos específicos.

Cenário 1: classificação de texto em Cloudflare Workers AI​

Modelo: Llama-3.2-3B quantizado para 4-bit Tarefa: classificar tickets de suporte em 12 categorias Volume: ~80k requests/dia

Resultado​

• Latência média: 120 ms (vs 800 ms chamando OpenAI)
• Custo: $8/mês (vs $240/mês na OpenAI no mesmo volume)
• Acurácia: 91% (vs 96% no GPT-4o)

Trade-off claro: 5% menos preciso, 30x mais barato, 7x mais rápido. Para classificação de ticket onde o humano revisa de qualquer jeito, vale demais.

O que não documentavam​

• Tamanho do modelo no edge: Cloudflare Workers AI cobra por modelo ativo. Modelos > 8GB têm cold start de 5-8s na primeira request da hora.
• Determinismo: quantização 4-bit introduz não-determinismo perceptível. Mesmo input pode dar saídas diferentes em 1-2% das requests.

Cenário 2: ONNX no navegador (busca semântica client-side)​

Modelo: all-MiniLM-L6-v2 (22 MB após quantização) Tarefa: busca semântica em um catálogo de 5k itens Onde roda: direto no navegador do usuário, via WebAssembly

Resultado​

• Latência de inferência: 40-80 ms (M1 Mac), 200 ms (Android médio)
• Custo de servidor: $0 (tudo no client)
• Privacidade: dados nunca saem do device

O que não documentavam​

• Download inicial de 22MB trava o primeiro paint. Solução: lazy-load com IntersectionObserver na busca, não na home.
• Memória: modelos em WebAssembly não liberam memória depois de carregados — chrome chega a 800MB de RAM no tab. Não dá pra carregar 3 modelos diferentes.
• iOS Safari tem implementação WASM limitada. Em iPhones antigos, a inferência leva 2-3s.

Cenário 3: llama.cpp em Raspberry Pi 5 (lab-only, off-grid)​

Modelo: Llama-3.2-1B quantizado em 4-bit (700 MB) Tarefa: assistant para o sistema de monitoramento de sensores do lab Onde roda: Raspberry Pi 5 8GB conectado direto aos sensores, sem internet

Resultado​

• Tokens/segundo: 8-12 (suficiente para resposta de 100 tokens em ~10s)
• RAM: 1.8 GB em uso constante
• Funciona offline, sem dependência de API externa

Custo​

• Raspberry Pi 5 8GB: R$ 900
• SD card 128GB: R$ 80
• Cooler ativo: R$ 60
• Total: R$ 1040 hardware único vs ~R$ 100/mês de API perpétua

Em 11 meses se paga. Útil para cenários air-gapped (laboratórios sensíveis, ambientes sem internet).

Quando edge NÃO compensa​

• Modelos > 8 GB (Llama 70B, GPT-5) — edge não tem RAM/GPU pra isso
• Workloads com baixíssimo volume (< 100 req/dia) — overhead de operação não compensa
• Aplicações onde 5% de queda na precisão é inaceitável (saúde, jurídico, financeiro)

Checklist para considerar edge no seu caso​

1. Volume > 10k req/dia? ✅ sim, vale avaliar
2. Modelo tem versão quantizada de qualidade conhecida? ✅ vale avaliar
3. Latência atual é gargalo? ✅ vale avaliar
4. Custo de API hoje > R$ 500/mês? ✅ vale avaliar
5. Time tem alguém disposto a aprender quantização? ✅ vale avaliar

Se respondeu sim em 3+, faça um POC de 1 semana.

Conclusão​

Edge AI é tecnologia real e útil — mas apenas em casos específicos onde o trade-off de precisão por latência/custo/privacidade compensa. Para 80% dos workloads, chamar OpenAI ainda é a escolha certa.

A pergunta correta não é "podemos colocar IA na borda?" mas "esse caso específico paga o custo operacional de manter modelo na borda?"