Se você já pesquisou sobre atribuição de custos de IA ou ferramentas de observabilidade em nuvem, provavelmente esbarrou no termo eBPF. Ele aparece em plataformas de segurança, ferramentas de rede, monitores de performance e, cada vez mais, na atribuição de custos de IA. Mas o que isso significa na prática, e por que importa para medir gastos com IA?
eBPF: o que é
eBPF é a sigla para extended Berkeley Packet Filter. O nome é um resquício das origens (a tecnologia começou como uma forma de filtrar pacotes de rede), mas evoluiu para algo muito mais amplo: uma maneira de executar pequenos programas em sandbox diretamente dentro do kernel do Linux, sem modificar o código-fonte do kernel nem instalar um módulo de kernel.
Na prática, o eBPF permite que o software observe o que está acontecendo em uma máquina no nível mais baixo: cada chamada de sistema, cada pacote de rede, cada processo, cada interação com a GPU, no momento em que acontece. E faz isso com segurança. Programas eBPF rodam em um ambiente verificado e isolado (sandbox), então não conseguem travar o kernel nem abrir brechas de segurança. Para um passo a passo técnico mais aprofundado sobre o loader e a arquitetura de verificação, a introdução do eBPF.io é a referência pública mais completa disponível.
Um sensor eBPF é o software que tira proveito dessa capacidade. É um programa leve que se conecta a eventos do kernel e transmite dados sobre o que observa, normalmente para uma camada de coleta ou análise rodando em outro lugar. Pense nele como um sensor embutido no próprio sistema operacional, monitorando atividades que nenhuma ferramenta na camada de aplicação consegue enxergar.
Sensores eBPF versus módulos de kernel e agentes
Antes do eBPF, obter esse tipo de visibilidade normalmente significava uma de duas coisas: escrever um módulo de kernel customizado ou rodar um agente pesado conectado à camada de aplicação.
Módulos de kernel enxergam tudo o que um sensor eBPF enxerga, mas trazem um risco real. Um bug em um módulo de kernel pode travar a máquina inteira, porque o módulo roda com acesso total e irrestrito à memória do kernel. Módulos também precisam ser recompilados e testados a cada versão do kernel, o que gera uma carga de manutenção contínua que poucos times querem assumir.
Agentes na camada de aplicação evitam esse risco, mas pagam o preço com pontos cegos. Um agente instalado dentro de uma aplicação só consegue ver o que essa aplicação escolhe expor. Ele não vê o tráfego passando por um driver de GPU compartilhado, um socket de rede do kernel ou um processo do qual nunca foi informado.
Um sensor eBPF fica no meio-termo, com as melhores propriedades dos dois lados. Roda dentro do kernel, então enxerga tudo o que um módulo de kernel enxergaria, mas cada programa eBPF passa pelo verificador do kernel antes de ser executado, portanto não pode travar o sistema nem ler memória indevida. Essa combinação de visibilidade total com risco controlado é o motivo pelo qual o eBPF virou a escolha padrão para ferramentas modernas de observabilidade, segurança e, agora, atribuição de custos.
Por que a observação no nível do kernel importa
A maioria das ferramentas de monitoramento e atribuição trabalha na camada de aplicação. Elas dependem de algo estar instrumentado: uma tag em um recurso, um SDK envolvendo uma chamada de API, uma linha de log que um engenheiro lembrou de adicionar. Isso funciona bem quando o que você mede é estático e bem definido.
Infraestrutura de IA não é estática nem bem definida. É exatamente aqui que as práticas tradicionais de FinOps começam a ficar no limite; veja como o FinOps se adapta (e não se adapta) para workloads de IA para mais detalhes sobre essa mudança. Um cluster de GPU compartilhado atende vários produtos ao mesmo tempo. Uma conta de API de modelo gerenciado recebe requisições de dezenas de times. Um gateway de LLM agrega tráfego de agentes, pipelines e usuários humanos em um único fluxo de saída, muitas vezes removendo pelo caminho a identidade de quem originou a chamada. Nada dessa atividade carrega uma tag. Nada disso passa por um SDK que você controla.
Um sensor eBPF não precisa de nada disso. Como opera dentro do sistema operacional, ele enxerga o consumo real diretamente: o processo, o container, o pod, o ciclo de GPU, o token. Não pede à aplicação que reporte nada. Observa o próprio sistema.
Pense num cenário comum: um time de engenharia roteia todo o tráfego de modelos por um único gateway de LLM para gerenciar rate limits e failover entre provedores. Do ponto de vista do gateway, toda requisição parece igual: uma chave de API, um fluxo de saída. A fatura do provedor do modelo reflete esse mesmo achatamento. Não dá para saber, só pela fatura, se um determinado valor veio de uma funcionalidade voltada ao cliente, de uma automação interna ou de um script de teste que saiu do controle. Um sensor eBPF resolve isso observando o tráfego no ponto em que ele de fato sai da máquina, antes de o gateway agregar tudo, e amarrando cada requisição ao processo que a originou.
Como funciona um sensor eBPF, passo a passo
- Conexão. O sensor se conecta a eventos específicos do kernel, como chamadas de sistema, atividade de rede ou agendamento de GPU, dependendo do que ele foi projetado para observar.
- Captura. Conforme esses eventos ocorrem, o sensor captura os dados relevantes: IDs de processo, uso de recursos, timing e por aí vai.
- Verificação. Antes de qualquer coisa acontecer, o verificador eBPF do kernel do Linux confere o programa para confirmar que é seguro executá-lo. É isso que diferencia o eBPF de um módulo de kernel tradicional, que carrega um risco bem maior.
- Streaming. O sensor transmite o que observa para uma camada de coleta fora do kernel, onde os dados podem ser cruzados com outras informações, como registros de faturamento do provedor.
- Mapeamento. Esses dados combinados são mapeados de volta para o workload responsável: qual agente, qual funcionalidade, qual cliente.
Todo o processo acontece continuamente e em tempo real, sem exigir alterações de código, edições de manifest nem qualquer tipo de instrumentação.
Sensores eBPF e atribuição de custos de IA
É aqui que o eBPF fica diretamente relevante para Tokenomics, a disciplina de entender quanto cada token custa e qual é o seu valor. Workloads de IA se movem rápido demais e de forma imprevisível demais para que atribuições baseadas em instrumentação consigam acompanhar. Um agente pode gerar mil sub-agentes de um dia para o outro. Quando um time de engenharia termina de envolver um novo padrão de chamada em um SDK, a fatura já chegou.
Um sensor eBPF contorna esse problema por completo. Como mede de dentro do sistema operacional, antes de qualquer proxy, antes de qualquer abstração, antes de qualquer fronteira de propriedade, ele captura cada token, cada requisição de modelo e cada ciclo de GPU no momento em que acontecem. Esses dados podem então ser cruzados com o faturamento de provedores como Anthropic, OpenAI, Google Gemini e AWS Bedrock, separando automaticamente tokens em cache, tokens de raciocínio, tokens de entrada e tokens de saída.
O resultado é uma atribuição que não depende de tags, SDKs nem alterações de código, implantada em minutos em vez de meses. Essa granularidade também é a base para medir o ROI de IA com precisão. Sem saber quanto uma funcionalidade realmente custa, qualquer cálculo de ROI se apoia em um palpite.
Perguntas frequentes
É seguro rodar um sensor eBPF em produção? Sim. Todo programa eBPF passa pelo verificador embutido no kernel antes de ser autorizado a carregar. O verificador confere se o programa sempre termina, se não lê memória fora dos seus limites e se não pode travar ou desestabilizar o kernel. É um perfil de risco fundamentalmente diferente do de um módulo de kernel tradicional, que tem acesso irrestrito e nenhuma verificação de segurança embutida.
Um sensor eBPF exige alterações de código ou instrumentação? Não. Essa é a principal vantagem. Um sensor eBPF observa a atividade no nível do kernel, então não precisa de tag, SDK nem alteração de código para ver o que está acontecendo. Ele funciona da mesma forma, independentemente de como a aplicação foi escrita ou em qual linguagem.
Quanto tempo leva para implantar um sensor eBPF? A implantação costuma ser medida em minutos, não em semanas. Como não há etapa de instrumentação, alterações de manifest nem necessidade de modificar o código da aplicação, um sensor pode ser instalado e começar a observar o tráfego quase que imediatamente. Com o Attribute™ da DoiT, a maioria dos clientes vê dados atribuídos no mesmo dia.
Um sensor eBPF consegue enxergar dentro de uma GPU compartilhada ou de um gateway de LLM? Sim, e é exatamente isso que o diferencia de abordagens baseadas em tags ou SDKs. Como o sensor observa o tráfego no nível do sistema operacional, antes de passar por qualquer gateway, proxy ou recurso compartilhado, ele consegue rastrear a atividade até o processo de origem, mesmo quando essa atividade é agregada ou anonimizada mais adiante no fluxo.
O eBPF só serve para casos de uso de rede e segurança? Não. O eBPF começou como uma tecnologia de rede (a sigla significa extended Berkeley Packet Filter), mas desde então se expandiu para observabilidade, segurança e, agora, atribuição de custos. Qualquer caso de uso que se beneficie de ver a atividade do sistema diretamente, sem depender de a aplicação se reportar sozinha, é candidato a uma abordagem baseada em eBPF.
Qual a diferença entre um sensor eBPF e um programa eBPF? Um programa eBPF é a unidade de código subjacente que roda dentro do kernel: um pequeno trecho de lógica verificado e conectado a um hook point específico. Um sensor eBPF é o sistema mais amplo construído em cima disso, incluindo a lógica de coleta e mapeamento que transforma observações brutas do kernel em dados utilizáveis.
Essa é a base sobre a qual o Attribute™ da DoiT foi construído. Veja como a atribuição de custos de IA no nível do kernel funciona no seu próprio ambiente.