Optimización de tokens LLM estilo Headroom: reducir costo de contexto sin romper respuestas

Respuesta rápida

La optimización de costos LLM debe empezar por la calidad del contexto, no por compresión ciega. Un optimizador estilo Headroom se ubica entre la aplicación y el modelo, elimina contexto de bajo valor, comprime salida ruidosa de herramientas, reutiliza partes estables del prompt y enruta tareas simples a modelos más baratos cuando la calidad lo permite.

El objetivo no es "usar menos tokens a cualquier costo". El objetivo es:

Mantener estable la calidad de la respuesta.
Preservar instrucciones críticas de seguridad.
Reducir contexto repetido, irrelevante o generado por máquinas.
Medir ahorros y regresiones con el mismo conjunto de pruebas.
Desplegar gradualmente con observabilidad y rollback.

Si tus prompts incluyen logs largos, payloads JSON, resultados de búsqueda, chunks RAG o historial repetido, vale la pena probar optimización de contexto.

De dónde suele venir el desperdicio de tokens

La mayoría de las requests LLM caras no lo son por una frase del usuario. Son caras porque la aplicación adjunta demasiado contexto.

Fuente de desperdicio	Ejemplo	Mejor enfoque
Texto de sistema repetido	Mismo bloque de política en cada turno	Cachear o acortar instrucciones estables
Salida ruidosa de herramientas	Logs, stack traces, HTML, JSON completos	Extraer campos relevantes antes de enviarlos
Chunks RAG excesivos	20 pasajes cuando 4 bastan	Rerank y recorte agresivo
Historial largo	Todos los mensajes desde la primera sesión	Resumir o crear ventana por recencia y relevancia
Routing de modelo incorrecto	Clasificación simple enviada a modelo grande	Enrutar tareas simples a modelos pequeños
Reintentos sin límite	Calls fallidos reenvían todo el contexto	Presupuestos de retry y estado intermedio cacheado

Una arquitectura de optimización más segura

Usa capas. No apliques todas las optimizaciones a la vez.

User request
  -> input normalization
  -> context selection
  -> tool/RAG output cleanup
  -> prompt assembly
  -> cache lookup
  -> model routing
  -> model call
  -> quality and cost logging

Cada capa debe ser medible y poder desactivarse de forma independiente.

Capa 1: selección de contexto

La selección de contexto decide qué necesita realmente el modelo.

Buenos candidatos para eliminar:

Instrucciones duplicadas.
Turnos antiguos que ya no son relevantes.
Documentos recuperados con baja similitud o bajo score de rerank.
Campos de salida de herramientas que la tarea no usa.
Stack frames o líneas de log repetidas.

No elimines:

Instrucciones de seguridad y permisos.
Restricciones del usuario.
Contratos de API.
Reglas de negocio.
Procedencia de datos necesaria para citas o auditoría.

Regla de ejemplo:

type ContextBlock = {
  id: string;
  source: "system" | "user" | "tool" | "rag" | "memory";
  text: string;
  score?: number;
  required?: boolean;
};

function selectContext(blocks: ContextBlock[], maxBlocks = 8) {
  const required = blocks.filter((block) => block.required);
  const optional = blocks
    .filter((block) => !block.required)
    .sort((a, b) => (b.score ?? 0) - (a.score ?? 0))
    .slice(0, maxBlocks);

  return [...required, ...optional];
}

Capa 2: compresión de salida de herramientas

La salida de herramientas suele ser la mayor fuente de tokens evitables. Logs, JSON, HTML, filas de base de datos y salida CLI deben convertirse en resúmenes específicos de la tarea antes de llegar al modelo.

Salida de herramienta	Enviar esto en su lugar
Stack trace completo repetido 200 veces	Error único, frames principales, primera/última ocurrencia
500 filas de base de datos	Agregados, anomalías, filas de muestra
HTML crudo	Texto extraído, links, encabezados, metadata
Respuesta JSON completa	Campos necesarios para la tarea actual
Logs de tests	Tests fallidos, assertions y bloques de error relevantes

Ejemplo:

function summarizeTestOutput(output: string) {
  const failed = output
    .split("\n")
    .filter((line) => /FAIL|Error:|AssertionError/.test(line));

  return failed.slice(0, 80).join("\n");
}

Esto es más seguro que compresión genérica porque conserva evidencia relevante.

Capa 3: prompt caching

Muchos prompts contienen partes estables: instrucciones del sistema, reglas del producto, schemas, guías de estilo y descripciones de herramientas. Mantén los bloques estables separados del contexto dinámico para que el caching funcione.

Ensamblado recomendado:

Stable:
  - system policy
  - output schema
  - product rules
  - tool descriptions

Dynamic:
  - current user request
  - selected history
  - selected retrieved passages
  - current tool output

Incluso cuando no hay prompt caching del proveedor, el caching a nivel aplicación puede evitar repetir retrieval, reranking y summarization costosos.

Capa 4: model routing

Model routing puede reducir costos cuando las tareas tienen niveles de complejidad claros.

Tipo de request	Ruta típica
Clasificación, extracción, reescritura simple	Modelo pequeño/rápido
Respuesta con retrieval y contexto corto	Modelo medio
Razonamiento complejo, coding, revisión legal	Modelo más fuerte
Acción crítica de seguridad o dinero	Modelo más fuerte más revisión humana

El routing debe basarse en calidad medida, no en intuición. Mantén fallback: si el modelo barato no está seguro o falla validación, reintenta con uno más fuerte.

function chooseModel(task: { type: string; risk: "low" | "medium" | "high"; tokens: number }) {
  if (task.risk === "high") return "strong-model";
  if (task.type === "classification" && task.tokens < 2000) return "small-model";
  if (task.tokens > 24000) return "long-context-model";
  return "balanced-model";
}

Medir calidad antes que ahorros

Los ahorros de tokens solo sirven si la calidad de salida sigue siendo aceptable.

Registra al menos:

Métrica	Por qué importa
Input tokens	Driver directo de costo
Output tokens	Driver directo de costo
Task success rate	Señal primaria de calidad
Human correction rate	Revela pérdidas sutiles de calidad
Validation failures	Detecta regresiones de schema y hechos
Escalation rate	Muestra si el routing es demasiado agresivo
Latency	La compresión puede agregar overhead
Cost per successful task	Mejor que costo bruto por request

Ejecuta A/B tests con tráfico real o casos históricos. Compara salidas optimizadas y baseline antes de habilitar un rollout amplio.

Plan de rollout

Registrar uso de tokens por ruta, herramienta y feature.
Elegir un workflow de alto volumen y bajo riesgo de negocio.
Agregar solo selección de contexto.
Agregar limpieza de salida de herramientas.
Agregar caching de componentes estables del prompt.
Agregar model routing solo cuando exista validación.
Desplegar por porcentaje.
Mantener un kill switch por feature.

No empieces con tareas de alto riesgo como reembolsos, eliminación de cuentas, consejo médico, revisión legal o automatización de seguridad.

Errores comunes

Comprimir el requisito real del usuario

La instrucción más reciente del usuario casi siempre debe sobrevivir intacta. Comprime primero el contexto antiguo.

Resumir reglas de seguridad

Las reglas de seguridad y permisos deben copiarse exactamente o referenciarse desde un bloque de política estable. No dejes que un summarizer las debilite.

Optimizar solo costo promedio

Una tarea importante fallida puede borrar los ahorros de muchas requests baratas. Mide costo por tarea exitosa y costo de corrección humana.

Enrutar solo por longitud del prompt

Prompts cortos pueden ser difíciles y prompts largos pueden ser simples. Usa tipo de tarea, riesgo, confianza de validación y desempeño histórico.

Olvidar auditabilidad

Si el contexto optimizado cambia la respuesta, necesitas saber qué se eliminó, resumió, cacheó o enrutó de otra forma.

FAQ

¿La optimización de tokens puede reducir costos 50% o más?

A veces, especialmente cuando los prompts contienen logs repetidos, payloads JSON grandes o exceso de contexto recuperado. Pero los ahorros varían según el workload. Mide tu propia baseline.

¿La compresión de contexto es segura?

Puede ser segura cuando se protegen instrucciones requeridas, se validan salidas y el rollout es gradual. La compresión ciega es riesgosa.

¿Debería usar un modelo pequeño para todo?

No. Los modelos pequeños sirven para tareas simples, pero razonamiento complejo, decisiones de alto riesgo y solicitudes ambiguas requieren modelos más fuertes o revisión humana.

¿Qué se debe optimizar primero?

Empieza con salida de herramientas y contexto RAG. Normalmente contienen más desperdicio que el mensaje del usuario.

Resumen

La optimización de tokens estilo Headroom se entiende mejor como ingeniería de contexto: seleccionar mejor contexto, limpiar salida ruidosa de herramientas, cachear bloques estables del prompt, enrutar por riesgo de tarea y medir calidad antes de celebrar ahorros. Hecha con cuidado, puede reducir costo y latencia LLM. Hecha a ciegas, puede eliminar justo la información que el modelo necesita.