Cómo bajar la factura y el tiempo de respuesta de una funcionalidad con LLM sin perder calidad: dónde se va el dinero, qué se cachea, qué se puede resolver con un modelo pequeño y qué no.
Cuándo usarlo: Reducir coste y latencia de una funcionalidad con LLM en producción con caché de prompts, recuperación de fragmentos y reparto de modelos, sin perder calidad
Herramienta recomendada: Claude API
Actúa como ingeniero con experiencia optimizando el coste y la latencia de funcionalidades basadas en modelos de lenguaje en producción. Quiero un análisis y un plan concreto. ## Contexto que necesito 1. Qué hace la funcionalidad, con qué modelo y con qué volumen (peticiones al día). 2. Coste actual mensual y, si lo tienes, el desglose por endpoint o caso de uso. 3. Latencia percibida y cuál sería aceptable. 4. Tamaño típico de entrada y de salida, y qué parte del contexto se repite entre peticiones. ## Paso 1 — Diagnóstico: a dónde va el dinero Descompón el coste por petición: tokens de entrada, tokens de salida, cuántas llamadas encadenadas hay por interacción y cuánto contexto se reenvía en cada turno. En la mayoría de los casos, el coste está en la entrada que se repite, no en la salida. Marca los tres sospechosos habituales: - Historial completo reenviado en cada turno de una conversación larga. - Documentos enteros en el contexto cuando bastaría un fragmento recuperado. - Bucles de agente que hacen cinco llamadas donde una bien planteada bastaba. ## Paso 2 — Palancas, por orden de rentabilidad | Palanca | Efecto típico | Coste de implantación | |---|---|---| | Caché de prompts para el prefijo estable | Gran reducción del coste de entrada repetida (la lectura de caché es una fracción del precio normal) | Bajo, si el prefijo se mantiene estable byte a byte | | Reordenar el contexto | Habilita la caché | Bajo | | Recuperar fragmentos en lugar de meter documentos completos | Menos entrada y mejor calidad | Medio | | Modelo más pequeño para las tareas fáciles | Reducción grande de coste y latencia | Medio, exige evaluación | | Reducir el número de llamadas por interacción | Coste y latencia | Medio | | Salida más corta y estructurada | Coste de salida y tiempo | Bajo | | Procesamiento por lotes para lo que no es interactivo | Descuento notable | Bajo | Sobre la caché: es una coincidencia de prefijo. Cualquier byte que cambie al principio (una fecha, un identificador, un orden no determinista de claves) la invalida entera. Lo estable va primero y lo variable al final; verifica con las métricas de lectura de caché que de verdad está funcionando. ## Paso 3 — Latencia percibida - Streaming siempre que haya una persona esperando: cambia la percepción sin cambiar el coste. - Trabajo especulativo o precalentado en lo que se puede anticipar. - Nada de esperar a que termine todo para mostrar algo: parcial visible. - Distinguir latencia real de latencia percibida antes de gastar en la primera. ## Paso 4 — Seguridad del cambio Ninguna optimización se acepta sin evaluación: cambiar de modelo o recortar contexto sin un conjunto de casos que compare calidad antes y después es cómo se degradan los productos sin que nadie se entere. Define el umbral de calidad que no se puede cruzar. ## Entregables 1. Desglose del coste por petición y por caso de uso, con el punto donde se va el dinero. 2. Plan de optimización ordenado por rentabilidad, con el ahorro estimado de cada palanca. 3. Reordenación concreta del contexto para habilitar la caché. 4. Propuesta de reparto de modelos por tipo de tarea. 5. Cómo verificar que la calidad no ha bajado, y el umbral de rechazo.