Capítulo 13: El manual de optimización

Seis pasos para encontrar los pocos cambios que más van a bajar tu factura.

Publicada el

Leer hasta 4 min completo

Visión general#

No te recomendamos implementar todas las técnicas de esta guía; podría llevarte meses. Algunos cambios eliminan mucho trabajo innecesario. Otros no ahorran casi nada o hacen que el sistema sea más difícil de mantener.

Empieza por la factura y después mira el flujo de trabajo. Separa la inferencia, la recuperación y las herramientas, la infraestructura, las suscripciones y los gastos operativos, atribuye esos costes a funcionalidades y tareas aceptadas, y solo entonces elige qué cambiar.

Práctica#

Trabaja en este orden:

  1. Encuentra las operaciones caras. Identifica los mayores costes totales y el peor coste por tarea aceptada. Mira los casos atípicos caros además de la media.
  2. Elimina el trabajo que no debería ocurrir. Las peticiones duplicadas, las búsquedas repetidas, los cálculos innecesarios con un LLM y la salida que nadie usa a menudo se pueden corregir sin cambiar de proveedor.
  3. Replantea las elecciones de modelo y de razonamiento. Usa modelos más pequeños adecuados para tareas acotadas; añade enrutamiento o cascadas solo cuando tengan sentido económico.
  4. Corrige el contexto y la forma de la respuesta. Conserva la evidencia necesaria, quita el material irrelevante, preserva los prefijos reutilizables y compacta el estado del agente de forma deliberada.
  5. Elige cómo se ejecuta el trabajo. Procesa por lotes el trabajo que puede esperar. Compara una API de pago por uso, un plan de tarifa plana y capacidad dedicada, gestionada o autoalojada, frente a la carga de trabajo que queda.
  6. Compra para la carga de trabajo que has medido. Cuando el volumen y la forma de las peticiones sean estables, mira los descuentos por compromiso de uso o enterprise, los tramos por volumen, el rendimiento (throughput) aprovisionado o reservado, los niveles de servicio prioritarios frente a los flexibles y las tarifas más altas que algunos proveedores cobran por contexto largo. Comprométete solo con el uso que ya has observado, deja margen para cambios de modelo y de tráfico, y compara el coste total del compromiso con la línea base de pago por uso para el mismo trabajo.
El orden importa: medir y quitar el trabajo innecesario va antes de cualquier cambio de modelo o de proveedor, y suele ser lo que antes se amortiza.

Prioriza por impacto económico neto, confianza, esfuerzo de implementación y riesgo. Como ilustración, eliminar una extracción duplicada podría ahorrar 400 $ al mes con poco trabajo de ingeniería, mientras que una migración a GPU promete 1.500 $ pero conlleva una carga de mantenimiento grande y depende de la utilización. La cifra más llamativa no debería decidir por sí sola qué va primero.

Antes de aprobar cualquier optimización, pregunta:

  • ¿Qué trabajo elimina o abarata este cambio?
  • ¿Qué parte del flujo de trabajo total representa ese trabajo?
  • ¿Qué puede empeorar: corrección, latencia, fiabilidad, privacidad o mantenibilidad?
  • ¿Qué nuevo coste recurrente introduce el cambio?
  • ¿Estamos comparando resultados aceptados equivalentes?

Apruébala solo si las respuestas muestran que baja el coste de un trabajo aceptado equivalente una vez contados sus nuevos costes.

La hoja de cálculo tiene una hoja para ordenar los cambios candidatos por ahorro, plazo de recuperación, confianza, esfuerzo y riesgo, con estas preguntas como columnas.

Revisa también las suscripciones de IA que están fuera de tu factura de inferencia: asistentes para desarrolladores, herramientas de escritura e investigación, productos para reuniones, licencias de automatización. Cancelar diez licencias sin usar de 30 $/mes en un contrato cancelable ahorra 300 $ al mes, a veces con menos esfuerzo que rediseñar parte de la pila de inferencia.

Ledgerline. Las partidas de inferencia de Ledgerline pasaron de 1.200 $, 600 $ y 800 $ a 567 $, 330 $ y 560 $: 1.457 $ al mes, un 44 % menos. Una herramienta de observabilidad y las ejecuciones periódicas de evaluación añaden 140 $ al mes, así que el total mensual es de 1.597 $ y el ahorro neto de 1.003 $, un 38,6 %. El trabajo costó unos 8.000 $ de tiempo de ingeniería, que se recuperan en ocho meses. Medir fue lo primero: sin el informe por operación del capítulo 2, el equipo habría empezado por el modelo del agente de investigación en lugar de por sus ejecuciones descontroladas.

En profundidad#

Mide el ahorro neto sobre el total, para que un porcentaje nunca caiga sobre el denominador equivocado:

El plazo de recuperación solo tiene sentido cuando el ahorro neto mensual es positivo. Deja los costes únicos (migración, tiempo de ingeniería, penalizaciones por salida de contrato) fuera de la cifra mensual y muéstralos a través del plazo de recuperación. Si la inferencia baja de 4.000 $ a 2.800 $ pero el cambio añade 300 $ de herramientas y 400 $ de operaciones, el gasto mensual pasa a ser de 3.500 $. La partida de inferencia bajó un 30 %; el total bajó un 12,5 %, un ahorro neto de 500 $ al mes. Si el cambio supuso 4.000 $ de trabajo de ingeniería, el plazo de recuperación es de 8 meses.

Un panel de presupuesto puede avisarte, pero los límites de gasto de los agentes se tienen que aplicar en el código de la aplicación, como se describe en Bucles de agentes, validación y reintentos.

Mantén una rutina ligera. Revisa a menudo las ejecuciones inusuales, mira el coste por funcionalidad y por proveedor cada mes, y replantea las suscripciones, los compromisos y la infraestructura con menos frecuencia. Los cambios grandes de tráfico, de modelos o de comportamiento del producto son motivo para revisar tus supuestos.

Referencias: Niveles Flex y Priority de Gemini, Procesamiento Flex de OpenAI, Precios de Gemini por longitud de contexto.