Configuración

Idioma

Cómo reducir tus costos de API de IA en un 30% sin cambiar de modelo

L
LemonData
·26 de febrero de 2026·415 vistas
Cómo reducir tus costos de API de IA en un 30% sin cambiar de modelo

La mayoría de los equipos pagan de más por las llamadas a AI API. No porque hayan elegido el modelo equivocado, sino porque ignoran tres optimizaciones que requieren cambios mínimos de código: prompt caching, smart model routing y batch processing.

Aquí tienes un desglose de cada técnica con cifras reales.

Si aún estás decidiendo si el problema es tu combinación actual de proveedores, lee primero la comparativa de precios. Si tu mayor problema son las tormentas de reintentos o el estrangulamiento (throttling) de los proveedores en lugar del gasto bruto, combina esta página con la guía de rate limiting.

1. Prompt Caching: El mayor triunfo

Si tu aplicación envía el mismo system prompt con cada solicitud, estás pagando el precio completo por tokens que el proveedor ya ha procesado.

Cómo funciona

OpenAI almacena prompts en caché automáticamente para entradas de más de 1.024 tokens. Los tokens en caché cuestan el 50% del precio de entrada estándar. No necesitas cambiar nada en tu código.

Anthropic utiliza un almacenamiento en caché explícito mediante puntos de interrupción de cache_control. El coste de escritura es un 25% más alto que la entrada estándar, pero las lecturas cuestan un 90% menos. El TTL de la caché es de 5 minutos, extendiéndose con cada hit.

En los precios más recientes de OpenAI, el descuento práctico puede ser mejor de lo que los equipos esperan. La entrada en caché de GPT-4.1 tiene un precio de una cuarta parte de la entrada estándar, lo que significa que los prefijos consistentes generan ahorros mucho mayores de lo que sugería el antiguo enfoque de "es bueno tenerlo".

Las cuentas

Tomemos un bot de atención al cliente típico:

  • System prompt: 2.000 tokens
  • Mensaje del usuario: 200 tokens de media
  • 5.000 solicitudes/día usando Claude Sonnet 4.6

Sin caching:

Coste de entrada diario = 5.000 × 2.200 tokens × $3.00/1M = $33.00

Con Anthropic prompt caching (asumiendo una tasa de acierto de caché del 95%):

Escrituras en caché: 250 × 2.200 × $3.75/1M = $2.06
Lecturas de caché:  4.750 × 2.200 × $0.30/1M = $3.14
Tokens de usuario:  5.000 × 200 × $3.00/1M = $3.00
Total diario = $8.20 (75% de ahorro en costes de entrada)

Implementación

from anthropic import Anthropic

client = Anthropic(
    api_key="sk-lemon-xxx",
    base_url="https://api.lemondata.cc"
)

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are a customer support agent for Acme Corp...",
            "cache_control": {"type": "ephemeral"}  # Esto habilita el caching
        }
    ],
    messages=[{"role": "user", "content": user_message}]
)

# Verifica el rendimiento de la caché en los encabezados de respuesta
# cache_creation_input_tokens vs cache_read_input_tokens

Para los modelos de OpenAI, el caching es automático. Solo asegúrate de que tus prompts superen los 1.024 tokens y mantén el prefijo estático consistente en todas las solicitudes.

Dónde se equivocan los equipos:

  • Poner marcas de tiempo o IDs de solicitud al principio de cada prompt.
  • Reordenar las instrucciones del sistema en cada llamada.
  • Incrustar contexto de usuario variable antes del prefijo estable.

Si el prefijo cambia cada vez, la caché nunca ayuda. Trata la estructura del prompt como una primitiva de coste, no solo como un detalle de prompt engineering.

2. Smart Model Routing: Usa el modelo adecuado para cada tarea

No todas las solicitudes necesitan tu modelo más caro. Una tarea de clasificación que GPT-4.1 maneja por $2.00/1M de tokens de entrada funciona igual de bien con GPT-4.1-mini a $0.40/1M, una reducción de coste de 5 veces.

La estrategia de enrutamiento (Routing)

Tipo de tarea Modelo recomendado Coste de entrada/1M
Razonamiento complejo Claude Opus 4.6 / GPT-4.1 $5.00 / $2.00
Chat general Claude Sonnet 4.6 / GPT-4.1 $3.00 / $2.00
Clasificación, extracción GPT-4.1-mini / Claude Haiku 4.5 $0.40 / $1.00
Embeddings text-embedding-3-small $0.02
Formateo simple DeepSeek V3 $0.28

Implementación

from openai import OpenAI

client = OpenAI(
    api_key="sk-lemon-xxx",
    base_url="https://api.lemondata.cc/v1"
)

def route_request(task_type: str, messages: list) -> str:
    """Elige el modelo más barato que maneje bien esta tarea."""
    model_map = {
        "classification": "gpt-4.1-mini",
        "extraction": "gpt-4.1-mini",
        "summarization": "gpt-4.1-mini",
        "complex_reasoning": "gpt-4.1",
        "creative_writing": "claude-sonnet-4-6",
        "code_generation": "claude-sonnet-4-6",
    }
    model = model_map.get(task_type, "gpt-4.1-mini")

    response = client.chat.completions.create(
        model=model,
        messages=messages
    )
    return response.choices[0].message.content

Ahorros reales

Un asistente de programación que enruta el 60% de las solicitudes (linting, formateo, completados simples) a GPT-4.1-mini y el 40% (arquitectura, depuración) a Claude Sonnet 4.6:

Antes (todo Claude Sonnet 4.6):
  1.000 req/día × 3K entrada × $3.00/1M = $9.00/día

Después (división 60/40):
  600 req × 3K × $0.40/1M = $0.72/día (mini)
  400 req × 3K × $3.00/1M = $3.60/día (sonnet)
  Total = $4.32/día (52% de ahorro)

3. Batch Processing: Precios más bajos para trabajos no urgentes

OpenAI ofrece una Batch API con un 50% de descuento en tokens de entrada y salida. La contrapartida: los resultados se entregan en un plazo de 24 horas en lugar de en tiempo real.

Anthropic también ofrece descuentos por lotes (batch) del 50% en modelos compatibles. Si tu carga de trabajo es nocturna, asíncrona o está orientada a revisión, rara vez hay una buena razón para pagar precios de tiempo real.

Buenos candidatos para batching:

  • Generación de contenido nocturna
  • Clasificación masiva de documentos
  • Etiquetado de conjuntos de datos (datasets)
  • Generación de informes programados
# Crear un archivo por lotes (formato JSONL)
import json

requests = []
for i, doc in enumerate(documents):
    requests.append({
        "custom_id": f"doc-{i}",
        "method": "POST",
        "url": "/v1/chat/completions",
        "body": {
            "model": "gpt-4.1-mini",
            "messages": [
                {"role": "system", "content": "Classify this document..."},
                {"role": "user", "content": doc}
            ]
        }
    })

# Escribir archivo JSONL
with open("batch_input.jsonl", "w") as f:
    for req in requests:
        f.write(json.dumps(req) + "\n")

# Enviar lote
batch_file = client.files.create(file=open("batch_input.jsonl", "rb"), purpose="batch")
batch = client.batches.create(input_file_id=batch_file.id, endpoint="/v1/chat/completions", completion_window="24h")

Buenos candidatos para batching dentro de un producto real:

  • Tareas de actualización de contenido nocturnas
  • Resumen de tickets de soporte
  • Backfills de embeddings
  • Revisiones de grandes bases de código o documentos
  • Notificaciones de usuario de baja prioridad

Malos candidatos:

  • Respuestas de chat
  • Asistencia de programación interactiva
  • Flujos de trabajo donde la siguiente acción del usuario depende de la respuesta inmediata

4. Bonus: Reduce el recuento de tokens

Antes de optimizar a nivel de API, comprueba si estás enviando más tokens de los necesarios.

Desperdicios comunes:

  • System prompts prolijos que repiten instrucciones que el modelo ya sigue.
  • Incluir el historial completo de la conversación cuando solo importan los últimos 3-5 turnos.
  • Enviar HTML/markdown sin procesar cuando el texto plano funcionaría.
  • No usar max_tokens para limitar la longitud de la salida.

Una reducción del 30% en la longitud del prompt se traduce directamente en un 30% menos de costes de entrada.

La forma más fácil de encontrar desperdicios es registrar la longitud del prompt por ruta o funcionalidad. La mayoría de los equipos no tienen un problema de precios de modelos. Tienen un problema de "el mismo prompt inflado se envía 100.000 veces al día".

5. Añade visibilidad de costes antes de optimizar a ciegas

La optimización de costes falla cuando los equipos optimizan basándose en la intuición.

Antes de cambiar las reglas de enrutamiento, registra:

  • Nombre de la ruta o funcionalidad
  • Modelo
  • Tokens de entrada
  • Tokens de salida
  • Acierto (hit) o fallo (miss) de caché
  • Recuento de reintentos
  • Latencia visible para el usuario

Eso te permite responder a las preguntas que importan:

  • ¿Qué ruta es cara porque es genuinamente útil?
  • ¿Qué ruta es cara porque el prompt es ineficiente?
  • ¿Qué ruta debería pasar a batch?
  • ¿Qué ruta debería pasar a un nivel de modelo más barato?

Si no puedes responder a esas cuatro preguntas, tu "optimización de costes" solo desplazará el gasto de un lugar a otro.

6. Un orden de optimización real

El orden más efectivo suele ser:

  1. Eliminar el desperdicio obvio de tokens.
  2. Activar o arreglar el caching.
  3. Separar las tareas baratas de las tareas caras.
  4. Pasar a batch todo lo que no sea urgente.
  5. Solo entonces renegociar la combinación de proveedores.

Ese orden importa porque los mayores ahorros a menudo llegan antes de cambiar de proveedor. Si cambias de proveedor sin arreglar la estructura del prompt, seguirás pagando por la misma ineficiencia.

7. Un despliegue concreto de antes y después

Tomemos un flujo de trabajo de soporte que actualmente hace esto en cada solicitud:

  • Envía un system prompt de 2.000 tokens.
  • Llama a un modelo premium para todas las solicitudes.
  • Reintenta la misma estructura de solicitud en fallos temporales.
  • Ejecuta resúmenes nocturnos de forma síncrona en lugar de en batch.

La primera versión a menudo parece "simple" porque solo tiene una ruta de código. Financieramente, está haciendo cuatro cosas caras a la vez.

Un despliegue más eficiente se ve así:

  1. Mover el texto de política estable al principio del prompt para que el caching pueda funcionar realmente.
  2. Enrutar la clasificación, extracción y resúmenes cortos a un nivel de modelo más barato.
  3. Reservar el modelo premium para escalaciones, razonamiento complicado o síntesis de la respuesta final.
  4. Pasar los resúmenes nocturnos y backfills a batch.
  5. Revisar los registros semanalmente para detectar rutas cuya estructura de prompt haya derivado y arruinado la eficiencia de la caché.

Ese tipo de despliegue no requiere una reescritura. Requiere una semana de instrumentación y la voluntad de tratar los prompts y el enrutamiento como superficies de producción.

8. Qué no hacer

La forma más rápida de desperdiciar un esfuerzo de optimización de costes es optimizar lo que no corresponde.

Evita estas trampas:

  • Cambiar de proveedor antes de medir el desperdicio de prompts.
  • Enrutar tareas baratas a modelos baratos sin validar la calidad de la salida.
  • Habilitar el caching en prompts cuyos prefijos cambian en cada solicitud.
  • Pasar a batch trabajos de cara al usuario que realmente necesitan respuestas en tiempo real.
  • Mirar solo el precio del token e ignorar los costes de reintentos, latencia y fallbacks.

El trabajo de costes tiene éxito cuando el producto sigue comportándose bien después de que se apliquen los ahorros. Si la UX empeora, la victoria en la hoja de cálculo es falsa.

Resumen final

Técnica Esfuerzo Ahorro típico
Prompt caching Bajo (añadir cache_control) 40-75% en entrada
Model routing Medio (clasificar tareas) 30-50% total
Batch processing Medio (flujo asíncrono) 50% en trabajos batch
Reducción de tokens Bajo (recortar prompts) 10-30% en entrada

Estas técnicas se potencian entre sí. Un equipo que implemente las cuatro puede reducir de forma realista su factura mensual de API de $3.000 a menos de $1.000 sin ninguna degradación en la calidad de la salida.

La idea clave: la optimización de costes en AI APIs no se trata de encontrar proveedores más baratos. Se trata de usar el modelo adecuado, en el nivel de precio adecuado, con la estrategia de caching adecuada, para cada tarea específica.

Si ya estás usando múltiples proveedores, el aspecto operativo también importa. La guía de migración y la comparativa con OpenRouter ayudan a decidir cuándo es el momento de centralizar el enrutamiento en lugar de seguir parcheando integraciones separadas.


Empieza a optimizar hoy mismo: LemonData te da acceso a más de 300 modelos a través de una sola API key, con soporte de prompt caching para las familias de modelos de OpenAI y Anthropic, y un único lugar para comparar el uso entre ellos.

Share: