Si has investigado herramientas de atribución de costos de IA o de observabilidad en la nube, seguramente te topaste con el término eBPF. Aparece en plataformas de seguridad, herramientas de networking, monitores de rendimiento y, cada vez más, en la atribución de costos de IA. Pero ¿qué significa realmente y por qué importa a la hora de medir el gasto en IA?
eBPF, definido
eBPF significa extended Berkeley Packet Filter. El nombre es un vestigio de sus orígenes (nació como una forma de filtrar paquetes de red), pero la tecnología evolucionó hacia algo mucho más amplio: una manera de ejecutar pequeños programas aislados directamente dentro del kernel de Linux, sin modificar su código fuente ni instalar un módulo de kernel.
En términos prácticos, eBPF permite que el software observe lo que ocurre en una máquina al nivel más bajo: cada llamada al sistema, cada paquete de red, cada proceso, cada interacción con la GPU, en tiempo real. Y lo hace de forma segura. Los programas eBPF corren en un entorno verificado y aislado, así que no pueden tumbar el kernel ni abrir agujeros de seguridad. Para un recorrido técnico más profundo sobre el loader y la arquitectura de verificación, la introducción de eBPF.io es la referencia pública más completa disponible.
Un sensor eBPF es el software que aprovecha esta capacidad. Es un programa ligero que se engancha a eventos del kernel y transmite datos sobre lo que observa, normalmente hacia una capa de recolección o análisis que corre en otro lugar. Piénsalo como un sensor incrustado en el propio sistema operativo, que observa actividad que ninguna herramienta de la capa de aplicación puede ver.
Sensores eBPF frente a módulos de kernel y agentes
Antes de eBPF, obtener este tipo de visibilidad solía implicar una de dos cosas: escribir un módulo de kernel a medida o desplegar un agente pesado enganchado a la capa de aplicación.
Los módulos de kernel pueden ver todo lo que ve un sensor eBPF, pero conllevan un riesgo real. Un bug en un módulo de kernel puede tumbar toda la máquina, porque el módulo se ejecuta con acceso total y sin restricciones a la memoria del kernel. Además, hay que recompilarlos y probarlos contra cada versión del kernel, lo que se traduce en una carga de mantenimiento continua que pocos equipos quieren asumir.
Los agentes de la capa de aplicación evitan ese riesgo, pero lo pagan con puntos ciegos. Un agente instalado dentro de una aplicación solo puede ver lo que esa aplicación decida exponer. No ve el tráfico que pasa por un driver de GPU compartido, un socket de red del kernel ni un proceso del que nunca se le informó.
Un sensor eBPF se ubica en el medio, con lo mejor de ambos mundos. Corre dentro del kernel, así que ve todo lo que vería un módulo de kernel, pero cada programa eBPF pasa antes por el verificador del kernel, así que no puede tumbar el sistema ni leer memoria que no le corresponde. Esa combinación —visibilidad total con riesgo acotado— es lo que ha convertido a eBPF en la opción por defecto para la observabilidad, la seguridad y, ahora, las herramientas modernas de atribución de costos.
Por qué importa la observación a nivel de kernel
La mayoría de las herramientas de monitoreo y atribución trabajan en la capa de aplicación. Dependen de que algo esté instrumentado: un tag sobre un recurso, un SDK envolviendo una llamada a una API, una línea de log que un ingeniero se acordó de agregar. Eso funciona bien cuando lo que mides es estático y está bien definido.
La infraestructura de IA no es estática ni está bien definida. Es justo ahí donde las prácticas tradicionales de FinOps empiezan a tensionarse; revisa cómo se adapta (y cómo no) FinOps a los workloads de IA para profundizar en ese cambio. Un cluster de GPU compartido atiende varios productos a la vez. Una cuenta de API de modelos gestionados recibe solicitudes de decenas de equipos. Un gateway de LLM agrega tráfico de agentes, pipelines y usuarios humanos en un único flujo saliente, muchas veces borrando la identidad de quien llamó por el camino. Nada de esa actividad lleva un tag. Nada pasa por un SDK que tú controles.
Un sensor eBPF no necesita nada de eso. Al operar dentro del sistema operativo, ve el consumo real directamente: el proceso, el contenedor, el pod, el ciclo de GPU, el token. No le pide a la aplicación que reporte nada. Observa el sistema mismo.
Piensa en un escenario común: un equipo de Engineering enruta todo el tráfico de modelos por un único gateway de LLM para gestionar rate limits y failover entre proveedores. Desde la perspectiva del gateway, cada solicitud se ve igual: una API key, un flujo saliente. La factura del proveedor de modelos refleja esa misma nivelación. Con la factura sola no hay forma de saber si un dólar dado vino de una funcionalidad de cara al cliente, de una automatización interna o de un script de prueba fuera de control. Un sensor eBPF resuelve esto observando el tráfico en el punto exacto en el que sale de la máquina, antes de que el gateway lo agregue, y vinculando cada solicitud al proceso que la originó.
Cómo funciona un sensor eBPF, paso a paso
- Enganche. El sensor se engancha a eventos específicos del kernel —llamadas al sistema, actividad de red o planificación de GPU—, según lo que esté diseñado para observar.
- Captura. A medida que ocurren esos eventos, el sensor captura los datos relevantes: IDs de proceso, uso de recursos, tiempos y demás.
- Verificación. Antes de que nada de esto suceda, el verificador eBPF del kernel de Linux revisa el programa para confirmar que es seguro ejecutarlo. Esto es lo que diferencia a eBPF de un módulo de kernel tradicional, que implica mucho más riesgo.
- Streaming. El sensor transmite lo que observa a una capa de recolección fuera del kernel, donde se puede combinar con otros datos, como los registros de facturación del proveedor.
- Mapeo. Esos datos combinados se mapean de vuelta al workload responsable: qué agente, qué funcionalidad, qué cliente.
Todo el proceso ocurre de forma continua y en tiempo real, sin necesidad de cambios de código, edición de manifiestos ni instrumentación de ningún tipo.
Sensores eBPF y atribución de costos de IA
Aquí es donde eBPF cobra relevancia directa para Tokenomics, la disciplina de entender cuánto cuesta cada token y cuánto vale. Los workloads de IA se mueven demasiado rápido y de forma demasiado impredecible como para que la atribución basada en instrumentación pueda seguirles el ritmo. Un agente puede generar mil subagentes de la noche a la mañana. Para cuando un equipo de Engineering envolvió un nuevo patrón de llamadas en un SDK, la factura ya llegó.
Un sensor eBPF esquiva ese problema por completo. Como mide desde dentro del sistema operativo, antes de cualquier proxy, antes de cualquier abstracción, antes de cualquier frontera de propiedad, captura cada token, cada solicitud a modelo y cada ciclo de GPU en el momento en que ocurre. Esos datos se pueden combinar con la facturación de proveedores como Anthropic, OpenAI, Google Gemini y AWS Bedrock, separando automáticamente tokens cacheados, tokens de razonamiento, tokens de entrada y tokens de salida.
El resultado es una atribución que no depende de tags, SDKs ni cambios de código, desplegada en minutos y no en meses. Esa granularidad es también la base para medir el ROI de la IA con precisión. Sin saber cuánto cuesta realmente una funcionalidad, cualquier cálculo de ROI se apoya en una suposición.
Preguntas frecuentes
¿Es seguro ejecutar un sensor eBPF en producción? Sí. Cada programa eBPF pasa por el verificador integrado del kernel antes de que se le permita cargarse. El verificador comprueba que el programa siempre termina, que no lee memoria fuera de sus límites y que no puede tumbar ni desestabilizar el kernel. Es un perfil de riesgo fundamentalmente distinto al de un módulo de kernel tradicional, que tiene acceso sin restricciones y ninguna verificación de seguridad integrada.
¿Un sensor eBPF requiere cambios de código o instrumentación? No. Esa es su ventaja principal. Un sensor eBPF observa la actividad a nivel de kernel, así que no necesita un tag, un SDK ni un cambio de código para ver lo que ocurre. Funciona igual sin importar cómo se haya escrito la aplicación ni en qué lenguaje esté.
¿Cuánto tarda en desplegarse un sensor eBPF? El despliegue se mide en minutos, no en semanas. Como no hay paso de instrumentación, ni cambios de manifiesto, ni necesidad de modificar el código de la aplicación, un sensor puede instalarse y empezar a observar tráfico casi de inmediato. Con Attribute™ by DoiT, la mayoría de los clientes ve datos atribuidos el mismo día.
¿Puede un sensor eBPF ver dentro de una GPU compartida o de un gateway de LLM? Sí, y eso es precisamente lo que lo diferencia de los enfoques basados en tagging o SDK. Como el sensor observa el tráfico a nivel del sistema operativo, antes de que pase por cualquier gateway, proxy o recurso compartido, puede rastrear la actividad hasta el proceso originario incluso cuando esa actividad se agrega o anonimiza más adelante en la cadena.
¿eBPF solo sirve para casos de uso de networking y seguridad? No. eBPF nació como una tecnología de networking (el nombre viene de extended Berkeley Packet Filter), pero desde entonces se ha expandido a la observabilidad, la seguridad y, ahora, la atribución de costos. Cualquier caso de uso que se beneficie de ver la actividad del sistema directamente, sin depender de que la aplicación se auto-reporte, es candidato a un enfoque basado en eBPF.
¿Cuál es la diferencia entre un sensor eBPF y un programa eBPF? Un programa eBPF es la unidad de código subyacente que se ejecuta dentro del kernel: una pieza pequeña y verificada de lógica conectada a un punto de enganche específico. Un sensor eBPF es el sistema más amplio construido encima, que incluye la lógica de recolección y mapeo que convierte las observaciones crudas del kernel en datos utilizables.
Esa es la base sobre la que se construye Attribute™ by DoiT. Descubre cómo se ve la atribución de costos de IA a nivel de kernel en tu propio entorno.