Thiago Taranto

Fronteira 'aberta' a um terço do custo: o Kimi K3 e a pressão sobre o seu contrato de IA

Thu, 30 Jul 2026 00:00:00 +0000

§1 — O que o paper afirma

A Moonshot AI (time Kimi) apresenta o Kimi K3, um modelo de linguagem Mixture-of-Experts (MoE) — arquitetura em que só uma parte dos “especialistas” internos é ativada por token, em vez do modelo inteiro — com visão nativa e janela de contexto de 1 milhão de tokens. O modelo é descrito como o primeiro modelo aberto de “classe 3 trilhões” de parâmetros (Conclusão, §8).

A conta do 'rodar em casa' está errada: por que o custo real de inferência varia até 36×

Sat, 04 Jul 2026 00:00:00 +0000

§1 — O que o paper afirma

A pergunta que o paper ataca é a mais concreta que existe numa diretoria de tecnologia: rodar o modelo na nossa própria infraestrutura sai mais barato do que pagar a API por token? A resposta que quase toda planilha dá está errada — e o erro tem uma causa única e mensurável.

O erro está em assumir a GPU sempre cheia. O autor levantou mais de 15 calculadoras públicas de custo de LLM (Helicone, LiteLLM, llm-prices.com e outras) e todas cometem o mesmo pecado: tratam a ocupação da GPU (utilization) como um número que o usuário digita — ou assumem silenciosamente 100% (§2.1, §6.1). Ocupação não é uma entrada que você escolhe; é um resultado de quanto tráfego chega. Uma GPU só fica cheia quando há requisições suficientes chegando ao mesmo tempo para preencher o lote de processamento. Com pouco tráfego, ela fica ociosa esperando — e você paga a hora de GPU inteira para processar um punhado de tokens.

A mesma GPU, 60–85% mais rápida por usuário: o ganho de inferência que não exige trocar de modelo

Sat, 04 Jul 2026 00:00:00 +0000

§1 — O que o paper afirma

Antes dos números, o mecanismo — porque sem ele nada faz sentido. Decodificação especulativa (speculative decoding) é um truque para acelerar a geração de texto de um modelo grande sem trocá-lo: um modelo pequeno e rápido (o rascunhador, ou drafter) “chuta” vários tokens de uma vez; o modelo grande então confere todos esses chutes num único passo, aceita o maior prefixo que ele mesmo teria gerado e descarta o resto. O ponto crucial: o resultado é matematicamente idêntico ao do modelo grande sozinho — a técnica é lossless, não muda uma vírgula da qualidade da resposta, só a velocidade com que ela sai (§1; §2.1). É pura economia de tempo e de GPU, não um modelo “melhor”.

Raciocínio de fronteira por 5% do custo: o que o DeepSeek-R1 muda no seu orçamento de IA

Sat, 04 Jul 2026 00:00:00 +0000

§1 — O que o paper afirma

O paper apresenta o DeepSeek-R1, um modelo de raciocínio treinado majoritariamente por reinforcement learning — sem depender de grandes volumes de dados anotados por humanos para a etapa de raciocínio. A tese central é que a capacidade de “pensar em passos” (chain-of-thought) pode ser incentivada por recompensa, e não apenas copiada de exemplos.

Dois resultados sustentam o argumento (ver seções de avaliação e as tabelas de benchmark do paper):

Por que o Whisper transformou cada ligação do seu call center em dado estruturado

Sat, 27 Jun 2026 00:00:00 +0000

§1 — O que o paper afirma

O paper descreve um sistema de reconhecimento de fala treinado com supervisão fraca em larga escala: em vez de um conjunto pequeno de áudios cuidadosamente rotulados, usa-se uma quantidade enorme de áudio-com-legenda coletado de forma ampla. A aposta é que escala compensa ruído de rótulo.

Os resultados centrais (ver as seções de avaliação multilíngue do paper):

Robustez a sotaque, ruído de fundo e vocabulário técnico sem ajuste fino específico — o modelo funciona “de fábrica” em condições variadas.
Cobertura multilíngue, incluindo português, com qualidade utilizável em produção — não apenas em inglês de estúdio.

“Supervisão fraca” aqui quer dizer: aceitar rótulos imperfeitos em troca de volume. É o oposto da abordagem clássica de fonoaudiologia computacional, que dependia de transcrições caras e limpas.

Llama 3 e a decisão que todo CEO vai ter que tomar: alugar inteligência ou ser dono dela

Sat, 20 Jun 2026 00:00:00 +0000

§1 — O que o paper afirma

O paper documenta uma família (“herd”) de modelos de linguagem abertos, cobrindo diferentes tamanhos, com relatório detalhado de dados, treino e avaliação. O ponto que interessa à diretoria não é a arquitetura — é a combinação de qualidade competitiva com pesos abertos e documentação de nível industrial.

Do relatório (ver as seções de avaliação e as tabelas comparativas do paper):

Os modelos maiores competem com fornecedores fechados de ponta numa faixa ampla de tarefas.
Os modelos menores são pensados para rodar em hardware acessível — viabilizando implantação dentro da infraestrutura do cliente.
O paper trata explicitamente de segurança e de práticas de avaliação, o que reduz o risco de adoção corporativa.

§2 — Por que importa para o negócio

Esta é, no fundo, uma decisão de make-or-buy aplicada à inteligência. Por padrão, a indústria escolheu “buy”: consumir IA como API de um fornecedor. Modelos abertos de alta qualidade colocam “make” de volta na mesa — não como projeto de pesquisa, mas como opção operacional.

A nuvem não é a resposta padrão: o caso econômico do on-premise em 2026

Mon, 15 Jun 2026 00:00:00 +0000

Durante quinze anos, “vai pra nuvem” foi a resposta padrão para qualquer decisão de infraestrutura. Era o caminho seguro de carreira: ninguém foi demitido por escolher a nuvem. Este ensaio é sobre por que, na Mobi2Buy, tomamos a decisão oposta — e o que aprendemos operando 100% em datacenter próprio.

A conta que ninguém faz no começo

O erro clássico é comparar o preço de tabela da nuvem com o CAPEX de um servidor. A comparação honesta é outra: custo total ao longo de três anos, incluindo transferência de dados, IOPS provisionado, e o imposto silencioso do egresso. Em cargas de trabalho estáveis e intensivas — que são exatamente as nossas — a curva vira a favor do on-premise mais cedo do que a narrativa dominante admite.

15 devs, 50 PRs por semana e um agente de IA revisando cada um

Wed, 20 May 2026 00:00:00 +0000

Com quinze engenheiros abrindo cerca de cinquenta PRs por semana, o gargalo do review humano ficou visível: ou os revisores viravam engarrafamento, ou a qualidade caía. Colocamos um agente de IA para revisar cada PR. Este é o relato honesto do que funcionou e do que quebrou.

O que o agente é bom em pegar

Consistência. O agente nunca está cansado, nunca deixa passar um padrão de nomenclatura por pressa, e reclama do mesmo jeito na sexta-feira à noite e na segunda de manhã. Para regras de estilo, contratos de API internos e anti-padrões conhecidos, ele é um revisor incansável e barato.

322 milhões de dead tuples depois: anatomia de um incidente PostgreSQL

Fri, 10 Apr 2026 00:00:00 +0000

Este é um post-mortem honesto. Não o tipo higienizado que vira slide de conferência, mas o relato de um incidente que começou meses antes de acontecer — em decisões de tuning que adiamos porque “estava funcionando”.

O sintoma não é o problema

O alerta que disparou foi latência de query. O problema real eram 322 milhões de dead tuples acumuladas: versões de linha que o VACUUM não conseguiu recolher no ritmo em que criávamos. O banco estava carregando um cemitério e pagando pedágio em cada leitura.