O Keepalive de 30 Segundos É Folclore: Economia de Cache É Política por Provedor

Em algum lugar da sua frota de agentes, um scheduler faz ping no cache de prompt a cada 30 segundos para mantê-lo quente. Ninguém mediu o intervalo. Ele veio de um post de blog, entrou num runbook e agora roda em todos os workers. Maxim Khailo construiu um harness para checar essa suposição, e a resposta incomoda: 30 segundos é cerca de 8x mais frequente do que o necessário, e em alguns provedores um keepalive perde dinheiro contra a alternativa de deixar o cache morrer.

A medição é pública. Quatro provedores (Anthropic, OpenAI, Google, DeepSeek), dois tamanhos de prefixo, intervalos ociosos esticados até 10 minutos, três execuções independentes, cada chamada com timestamp. O harness está aberto no GitHub, com um artigo companheiro no arXiv. É trabalho independente, autopublicado, sem revisão por pares, então trate os números como uma foto datada, não como uma lei. O comportamento de cache do provedor pode mudar na semana que vem. Essa ressalva é justamente o ponto do texto: a convenção que as pessoas copiam não tem prazo de validade estampado, e o comportamento por baixo dela tem.

As curvas de evicção não concordam

Rode o mesmo teste de ocioso-e-retomada nos quatro provedores e você obtém quatro formatos diferentes.

Com 10 minutos de ociosidade e um prefixo de 100 mil tokens, os caches divergiram forte:

Anthropic: 0 de 48 requisições voltaram quentes. Existe um penhasco rígido de TTL. Depois de cerca de 5 minutos o cache some, e nenhuma espera o recupera.
OpenAI: 39 de 48 quentes. O cache decai devagar e costuma sobreviver aos 10 minutos.
Google: 20 de 24 quentes. O Gemini usa um cache implícito que tende a persistir.
DeepSeek: 4 de 48 quentes. Evicção agressiva, na prática próxima da Anthropic.

Um botão, quatro políticas. Uma estratégia de keepalive calibrada para o penhasco da Anthropic está errada para a ladeira da OpenAI, e é ativamente desperdiçadora para o cache implícito do Gemini. Copiar um único intervalo por uma frota heterogênea garante que você esteja errado em pelo menos três dos quatro.

A convenção de 30 segundos é 8x frequente demais

O intervalo do folclore é 30 segundos. O harness testou intervalos maiores. Um keepalive de 4 minutos manteve 23 de 24 requisições quentes nos provedores com TTL, a um custo 7,8x menor do que fazer ping a cada 30 segundos. A temperatura é quase idêntica. A conta é uma fração.

O motivo é mecânico. Um ping de keepalive é uma requisição real contra o prefixo em cache. Você paga por ele toda vez. Faça ping 8x mais vezes do que o TTL exige e você paga 8x o custo de keepalive para comprar a mesma residência de cache. Num provedor com TTL de 5 minutos, um ping aos 4 minutos e 30 segundos mantém o cache vivo tão bem quanto um ping aos 30 segundos, e custa quase nada em comparação.

Existe uma fórmula para o horizonte de ociosidade de equilíbrio. O cache vale ser mantido quente apenas quando o intervalo ocioso é curto o suficiente para que um keepalive custe menos do que recomputar do zero:

ocioso_equilibrio ≈ τ · (w/r − 1)

onde τ é o TTL do cache, w é o multiplicador de preço de escrita (criação do cache) e r é o multiplicador de preço de leitura (acerto de cache). Ponha os números reais de cada provedor e os horizontes se espalham:

Anthropic: o keepalive compensa até cerca de 46 minutos de ociosidade.
OpenAI / DeepSeek: cerca de 36 minutos.
Google: cerca de 12 minutos.

Cada um desses horizontes é bem mais longo que 30 segundos e bem mais longo que o intervalo que a maioria dos schedulers de fato usa. Com 10 minutos de ociosidade, a convenção de 30 segundos perde dinheiro nos quatro provedores. Ela compra residência que você teria mais barato, ou residência que você não precisava.

O Gemini inverte a premissa inteira

O achado mais afiado: no Google, manter o cache quente pode custar mais do que deixá-lo morrer.

Pegue um intervalo ocioso de 600 segundos e compare três estratégias: deixar o cache expirar e pagar o recomputo frio na retomada, fazer ping a cada 30 segundos, ou fazer ping a cada 4 minutos.

No Sonnet 4.5 da Anthropic, o custo por ciclo foi de US$ 0,667 para deixar morrer, US$ 0,867 para ping a cada 30 segundos e US$ 0,414 para ping a cada 4 minutos. O keepalive de 4 minutos economiza 38% contra deixar morrer. O penhasco rígido de TTL faz com que uma retomada após 10 minutos sempre pague o preço cheio, então um keepalive bem calibrado é dinheiro real economizado.

No Gemini 2.5 Pro, as mesmas três estratégias custaram US$ 0,131 para deixar morrer, US$ 0,649 para ping a cada 30 segundos e US$ 0,186 para ping a cada 4 minutos. Deixar o cache morrer é a opção mais barata. O keepalive custa 40% mais do que não fazer nada. O cache implícito do Gemini e sua estrutura de preços tornam o recomputo na retomada barato o bastante para que qualquer tráfego de keepalive seja puro custo extra.

Mesmo código, resposta correta oposta. Uma política de frota que mantém caches quentes porque “quente é bom” está queimando dinheiro no Gemini para comprar algo que o Gemini entrega de graça.

O que isso diz sobre governança de custo de frota

Este é o segundo caso concreto de um padrão que vale nomear: a economia de frota inverte a melhor prática de agente único. Na escala de agente único, um keepalive é um arredondamento e ninguém audita. Multiplique por centenas de workers fazendo ping a cada 30 segundos o dia todo, e o intervalo vira uma linha do orçamento. O primeiro caso foi sobre paralelismo e retentativas. Este é sobre um batimento de cache que todo mundo herdou e ninguém precificou.

O ponto de governança generaliza para além deste botão. Convenções nesta área são fotos datadas do comportamento do provedor, e os provedores estão mudando o chão embaixo delas. Residência de cache está virando um produto medido e precificado. A Anthropic já expõe escrita e leitura de cache como linhas separadas. Quando a residência tem preço explícito, o intervalo ótimo de keepalive vira uma função que você calcula a partir dos preços atuais, não um número que você herda de um post de 2024. A arbitragem aqui tem prazo de validade, e toda convenção de custo construída sobre defaults de provedor também tem.

Isso conecta com a forma como uma área financeira deveria ler gasto de inferência. Um índice de eficiência de inferência que um CFO consiga governar precisa considerar economia de cache, e economia de cache tem muitos números: uma tabela por provedor e por modelo que muda quando um provedor atualiza preço ou TTL. Um painel de governança que assume uma política de keepalive boa em todo lugar está reportando um número que não verificou.

Faça isso agora

Tire o intervalo de keepalive de dentro do seu scheduler de agentes e cheque contra a fórmula de equilíbrio para cada provedor que você roda. Três movimentos concretos:

Ache todo keepalive e leia o intervalo. Se for 30 segundos e seus intervalos ociosos duram minutos, você está pagando múltiplos do custo necessário. Alargue em direção ao TTL menos uma margem de segurança.
Separe a política por provedor. Um intervalo único entre Anthropic, OpenAI e Gemini está errado por construção. Calcule τ · (w/r − 1) por provedor a partir dos preços atuais e ajuste o intervalo por modelo.
No Gemini, teste deixar o cache morrer. Meça seu custo real de retomada contra seu custo de keepalive. Se o cache implícito e o preço tornam morrer mais barato, desligue o keepalive nesse provedor e embolse a diferença.

Depois remeça periodicamente, porque cada um desses números tem data. Rode o harness de Khailo contra seus próprios prefixos e seus preços contratados antes de confiar em qualquer valor daqui, incluindo os dele.

Fontes

Maxim Khailo (independente). “Keeping the KV cache warm: measuring prompt cache eviction across Anthropic, OpenAI, and Google.” Julho de 2026. Medição autopublicada, sem revisão por pares, com harness open-source e artigo companheiro no arXiv; o comportamento de cache do provedor pode mudar a qualquer momento, então todo número é uma foto datada.

A Victorino ajuda organizações de engenharia a transformar custo de inferência de folclore em política medida por provedor: contato@victorino.com.br | www.victorino.com.br