Optimizar latencia, coste y experiencia

Optimizar una aplicación LLM no significa elegir siempre el modelo más pequeño ni recortar contexto hasta que responda rápido. Significa reducir trabajo innecesario sin degradar las propiedades que importan.

La optimización empieza después de medir.

Perfila el recorrido

Descompón:

autenticación → datos → RAG → modelo → tools → validación → persistencia → render

Mide cada fase.

Para interfaces conversacionales distingue:

• tiempo hasta primer resultado;
• tiempo hasta respuesta completa;
• tiempo hasta efecto confirmado.

Usa percentiles. La media oculta colas largas.

Reduce llamadas antes de abaratar llamadas

Pregúntate:

• ¿esta llamada LLM es necesaria?
• ¿puede resolverlo una regla?
• ¿puedo reutilizar resultado?
• ¿puedo paralelizar dependencias independientes?
• ¿puedo limitar salida?
• ¿estoy reenviando contexto redundante?
• ¿necesito un modelo de máxima capacidad para esta tarea?

La mayor reducción de coste suele venir de eliminar trabajo, no solo de cambiar tarifas.

Selecciona modelo por tarea

Construye una matriz con:

• calidad;
• latencia;
• coste;
• capacidad de tools;
• structured outputs;
• contexto;
• modalidad;
• política de datos.

Las capacidades y precios son volátiles. No incrustes una decisión eterna en código.

Ejecuta evals por tarea antes de cambiar.

Usa streaming cuando mejora experiencia

El streaming puede reducir percepción de espera en prosa, pero no siempre es apropiado.

Si la aplicación necesita validar una estructura completa antes de mostrarla, quizás sea mejor esperar. Si el usuario lee una respuesta larga, mostrar tokens progresivamente puede ser útil.

No confundas «primer token rápido» con «tarea completada rápido».

Cachea con cuidado

Una cache necesita:

• clave;
• identidad;
• tenant;
• versión;
• permisos;
• expiración;
• invalidación.

No cachees resultados sensibles solo por similitud semántica sin considerar autorización.

Los cambios de fuente, modelo o política pueden invalidar entradas.

Controla coste completo

Registra:

• input tokens;
• output tokens;
• tools;
• retrieval;
• reranking;
• retries;
• almacenamiento;
• revisión humana;
• infraestructura.

El coste del modelo es solo una parte.

Diseña presupuestos

Puedes establecer:

• presupuesto por usuario;
• por tarea;
• por job;
• por día;
• límite de reintentos;
• longitud máxima;
• número máximo de tools.

Cuando el presupuesto se agota, el sistema debe degradar de forma segura: pedir confirmación, pasar a asíncrono o rechazar.

Protege la experiencia

Muestra estados reales:

• preparando;
• esperando herramienta;
• procesando job;
• requiere revisión;
• error recuperable.

No simules progreso.

Permite cancelar cuando la semántica sea clara y conserva borradores si aporta valor.

Construye perfiles de rendimiento

No compares solo una media global.

Segmenta por:

• tarea;
• tamaño;
• modelo;
• uso de tools;
• RAG;
• usuario;
• error.

Una tarea simple puede tener p95 excelente mientras una extracción larga degrada la experiencia.

Separa latencia de red, modelo y aplicación

Instrumenta:

• DNS/conexión si es relevante;
• cola;
• proveedor;
• retrieval;
• tool;
• validación;
• persistencia.

Optimizar el frontend no arregla un reranker lento.

Usa concurrencia solo cuando existe independencia

Puedes paralelizar:

• dos búsquedas independientes;
• varias fuentes sin dependencia.

No paralelices pasos que necesitan resultado anterior.

La concurrencia puede aumentar rate limits y coste. Mide.

Controla prompts y contexto

Elimina:

• instrucciones repetidas;
• historial irrelevante;
• chunks duplicados;
• campos nunca usados.

Pero conserva evidencia y reglas críticas.

Evalúa batching cuando el producto lo permita

Tareas offline pueden agruparse o enviarse mediante mecanismos asíncronos si el proveedor los ofrece.

No es adecuado para una interacción que necesita respuesta inmediata.

Mide coste marginal

Pregunta cuánto cuesta:

• una consulta;
• una revisión;
• una herramienta;
• un retry;
• un caso fallido.

El coste medio puede ocultar una minoría muy cara.

Diseña degradación económica

Si un usuario alcanza presupuesto:

• reduce funciones no críticas;
• pasa a cola;
• solicita confirmación;
• bloquea.

No cambies silenciosamente a una opción de menor calidad si afecta el contrato.

Optimiza UX con feedback real

Mide:

• abandono;
• reintentos del usuario;
• ediciones;
• tiempo hasta completar tarea.

La percepción de velocidad es importante, pero el objetivo final es completar el trabajo correctamente.

Ejercicio

Elige dos optimizaciones y formula hipótesis:

«Reducir el contexto redundante un 30 % disminuirá coste y p95 sin degradar groundedness».

Ejecuta baseline y candidata con la misma batería. Documenta:

• calidad;
• latencia;
• coste;
• errores;
• experiencia;
• regresiones.

Resultado de la lección

Debes terminar con una política de optimización basada en datos. La aplicación será más eficiente porque hace menos trabajo innecesario, no porque haya eliminado controles esenciales.