Una sesión de depuración de 287 dólares llevó a un ingeniero a replantearse cómo alimentamos de datos a los grandes modelos de lenguaje (LLM). El resultado ha supuesto un ahorro estimado de 700.000 dólares para los usuarios en cinco meses.

Tejas Chopra estaba depurando un fallo en la unidad de procesamiento gráfico (GPU). Un procedimiento habitual para un ingeniero sénior: obtener los registros, pedirle a Claude que identifique el problema y seguir con su trabajo. Cuando recibió la respuesta, notó algo extraño. Esa única pregunta había consumido toda su ventana de contexto dos veces. «Gasté mucho dinero solo con esa pregunta», recuerda. Se preguntó por qué.

Resultó que el modelo había leído el archivo de registro completo varias veces, procesándolo todo antes de extraer las tres líneas realmente importantes. Cuando Chopra sumó su factura mensual, se encontró con 287 dólares por trabajo en proyectos personales.

La solución fue reescribir la pregunta para que ignorara las líneas INFO y se centrara solo en las advertencias y alertas. El tiempo de respuesta mejoró y el coste de los tokens se redujo, pero Chopra seguía preocupado.

“No se puede esperar que cada desarrollador abra su ventana y personalice las sugerencias según lo que busca”, afirma. “Las personas —o los modelos— dirán a ciegas: ‘Necesito revisar los registros, necesito obtener los registros’”. Para solucionar esto, se preguntó si el proceso podría automatizarse.

El resultado es Headroom, una capa de optimización de contexto de código abierto para LLM. Al presentar el proyecto en la Cumbre de Código Abierto de Linux, Chopra descubrió que la idea tuvo una gran acogida. “En pocas palabras, muchas empresas tienen dificultades, primero para comprender dónde se gastan los tokens y luego para optimizarlo. Headroom, como proyecto de código abierto que puede ejecutarse en tu máquina, ayuda con ambos problemas”.

Antes de dejar de recopilar las estadísticas, Headroom había ahorrado a sus usuarios unos 700.000 dólares y recuperado 200.000 millones de tokens en tan solo cinco meses. Este éxito inicial impulsó a Chopra a dejar su puesto de ingeniero sénior y fundar Headroom Labs para explorar la idea de que gran parte de lo que enviamos a los másteres en Derecho (LLM) no es necesario.

Cómo funciona la compresión de Headroom
 

Chopra describe el proceso de compresión como una evolución a través de tres etapas distintas, cada una basada en la anterior.

El primer objetivo fue la Notación de Objetos JavaScript (JSON), ya que es ampliamente utilizada y resulta ineficiente cuando se tokeniza de forma ingenua. Los espacios en blanco, las comas, las comillas y la indentación anidada consumen tokens sin añadir significado semántico. Headroom los elimina y los convierte a una representación compacta que genera un ahorro instantáneo del 30%, sin perder ningún dato, según Chopra.

A continuación, Headroom busca similitudes estadísticas entre los valores y los comprime en consecuencia. Si 88 de 90 valores en un array se encuentran entre 0 y 1, y dos son valores atípicos (99 y 100), no es necesario transmitir los 90 valores. Se transmiten los valores atípicos y un resumen: «88 entradas entre 0 y 1». Los valores atípicos se conservan tal cual; los casos comunes se convierten en una sola anotación. «Eso en sí mismo es valioso», afirma Chopra. «Solo se necesita conservar una copia de los elementos estadísticamente similares y la diferencia».

Cada carga útil comprimida en Headroom está respaldada por una entrada de caché con una clave, que es una combinación del ID de sesión y un hash de los datos originales. Dado que el hash se basa en el contenido y no en el contexto, las colisiones de hash no producirán contaminación entre sesiones.

La carga útil original completa reside en una instancia local de Redis o SQLite. Dado que el contexto que era válido hace media hora puede no serlo ahora, la caché tiene un tiempo de vida (TTL) configurable, con un valor predeterminado de entre cinco y treinta minutos para cada desarrollador. La caducidad garantiza la actualización de los datos, sin que el desarrollador tenga que preocuparse por la invalidación manual de la caché.

Para implementaciones empresariales, en lugar de una instancia local de Redis, la caché puede residir en una base de datos como RDS en AWS, Bigtable en GCP o PostgreSQL en una nube privada o centro de datos local, según el servicio que la organización ya utilice.

Varios desarrolladores que trabajan en múltiples sesiones pueden beneficiarse de las entradas de caché compartidas. Una respuesta de la interfaz de programación de aplicaciones (API) obtenida por diez ingenieros en la misma tarde se comprime y almacena una sola vez, no diez. La configuración del TTL se convierte en una decisión organizacional, configurable de forma centralizada.

Un riesgo de la compresión es que el modelo pueda necesitar los datos descartados. La solución de Chopra consiste en dejar una llamada a una herramienta en la salida comprimida. Cuando Headroom comprime una carga útil, aplica un hash al original y lo almacena localmente. Luego, inserta una ruta de navegación en la versión comprimida, que proporciona la definición de una herramienta que el modelo puede usar para recuperar los datos originales completos, si lo necesita.

Si el modelo es lo suficientemente inteligente como para solicitar más contexto, el mecanismo existe; si no lo es, no se desperdicia nada enviando datos que el modelo habría ignorado. "Confío en la inteligencia de los modelos para hacer eso", dice Chopra, "además de mi propio análisis estadístico".

Fuente: Noticia Original