API de LLM gratuitas: la verdadera comparativa (y la opción locale)

#¿Por qué este comparativo?

Buscar una API gratuita de LLM suele ser el primer paso al crear un prototipo: quieres probar una idea sin sacar la tarjeta, conectar un modelo a un script y ver si funciona. La buena noticia es que existen opciones gratuitas, a veces bastante generosas. La mala es que «gratis» puede significar cosas muy distintas: un plan gratuito permanente, un crédito de prueba que caduca o un acceso comunitario con velocidad limitada.

El enfoque de esta guía no es decirte «ejecutar en local es mejor». Es darte las cifras para que decidas por ti mismo: qué permite realmente cada oferta gratuita, qué obtiene a cambio y a partir de qué volumen o de qué requisito de confidencialidad un endpoint local se convierte en la opción racional. A menudo, la mejor respuesta no es una opción ni la otra, sino ambas, con un enrutamiento según la tarea.

#Recorrido por las API de LLM gratuitas

Se pueden clasificar las ofertas gratuitas en cuatro familias. Entender a qué familia pertenece una oferta evita sorpresas cuando el contador llega a cero durante un sprint.

Plan gratuito permanente

Un acceso gratuito que no caduca, pero con un límite de solicitudes por minuto y por día. Es el caso de Google AI Studio (API Gemini) o de Groq, que ofrecen modelos abiertos (Llama, Qwen, gpt-oss) con una tasa de solicitudes gratuita, pero limitada.

Agregadores y modelos :free

OpenRouter expone decenas de modelos, algunos con sufijo «:free». El acceso es real, pero la velocidad depende de un recurso compartido y puede disminuir en horas pico.

Crédito de prueba

Un monto ofrecido (a menudo unos dólares) al crear la cuenta, que vence después de algunas semanas. Útil para una prueba puntual, inútil para un proyecto que dure.

Inferencia comunitaria

Hugging Face Inference y servicios similares: acceso gratuito a muchos modelos, pero con arranque en frío (cold start), colas de espera y rendimiento no garantizado.

#Los límites reales, sin filtro

La palabra «gratuito» oculta tres límites distintos que, juntos, determinan si la oferta sirve para tu uso. Un nivel puede ser generoso en uno y muy restrictivo en los otros dos.

Consultas por minuto (RPM)

El número de llamadas permitidas por minuto. Los planes gratuitos suelen estar alrededor de varias decenas de RPM — más que suficiente para un desarrollador que prueba, pero demasiado poco para atender varios usuarios simultáneamente.

Tokens por día (TPD)

El límite que realmente condiciona el uso. Una cuota diaria de tokens se agota muy rápido en cuanto se envían prompts grandes, contexto RAG o se itera sobre un conjunto de datos.

Velocidad de generación y latencia

En las ofertas gratuitas compartidas, la velocidad de generación nunca está garantizada. En las horas de menor demanda, la generación es fluida; en los picos de demanda, la latencia se dispara o se rechazan las solicitudes (error 429).

En concreto: para el prototipado manual, con unas pocas consultas de vez en cuando, las cuotas gratuitas dan margen suficiente. En cuanto automatizas mediante un script un procesamiento por lotes —clasificar mil tickets, resumir un buzón de correo, generar pruebas para un repositorio—, alcanzas el límite de TPD en pocos minutos, y la limitación de la tasa de procesamiento convierte un lote de 10 minutos en una espera de una hora interrumpida por errores 429.

#Lo que realmente pagas

Una API gratuita no está exenta de costos: el precio simplemente se traslada del bolsillo a otras columnas. Tres de ellas pesan mucho para un proyecto de desarrollo.

Tus datos

En muchos planes gratuitos, los prompts y las respuestas se conservan y pueden usarse para entrenar o mejorar los modelos. Lo que es aceptable para una prueba con datos ficticios no lo es con código propietario, datos de clientes o información personal (RGPD).

La dependencia

Construir sobre una cuota gratuita es como construir sobre un terreno que puede ceder: cambios de condiciones, retirada de un modelo, eliminación de un nivel. Tu código, tus prompts y tus ajustes están calibrados para un proveedor; migrar requiere un tiempo que no habías previsto.

La imprevisibilidad

Latencia variable, colas, interrupciones: es difícil cumplir una promesa de calidad de servicio cuando el componente central escapa a tu control y no ofrece ningún compromiso en la modalidad gratuita.

#Opción local con Ollama

Frente a lo gratuito con condiciones, está lo gratuito de verdad: ejecutar el modelo en tu propia máquina. Ollama es la herramienta más sencilla para eso. Es un daemon que descarga modelos con pesos abiertos y expone una API HTTP local en http://localhost:11434, incluido un endpoint compatible con OpenAI, lo que significa que el código escrito para una API en la nube suele funcionar simplemente cambiando la URL base.

# Installer Ollama (Linux/macOS)
curl -fsSL https://ollama.com/install.sh | sh

# Tirer et lancer un modèle 7-8B quantifié Q4_K_M
ollama pull qwen2.5:7b
ollama run qwen2.5:7b

# Le daemon écoute sur http://localhost:11434

En cuanto al código, el endpoint compatible con OpenAI se conecta en tres líneas. No hay clave de API que gestionar, no hay límite de uso, no hay datos que salgan de la máquina.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",  # endpoint local Ollama
    api_key="ollama",  # ignoré en local, mais requis par le client
)

resp = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=[{"role": "user", "content": "Explique la récursion en une phrase."}],
)
print(resp.choices[0].message.content)

La contrapartida es el hardware. Un modelo local necesita VRAM (o memoria unificada en Mac Apple Silicon). Con cuantización Q4_K_M, las cifras de referencia de memoria son fáciles de recordar: un 3B cabe en aproximadamente 2 GB, un 7B en aproximadamente 5 GB, un 14B en aproximadamente 9 GB, un 32B en aproximadamente 19 GB y un 70B requiere aproximadamente 40 GB. Una RTX 3060 de 12 GB ejecuta modelos de 7 a 14B con comodidad; una RTX 4090 de 24 GB o un Mac M4 Pro con 24 a 48 GB de memoria unificada abre la puerta a los modelos de 32B.

Confidencialidad total

Ningún prompt sale de la máquina. Código propietario, datos de clientes, información personal: todo permanece en tu entorno, lo que simplifica radicalmente el cumplimiento del RGPD.

Sin cuota

Sin RPM ni TPD. Puedes procesar diez mil documentos en un bucle durante la noche sin llevar la cuenta y sin errores 429.

Coste marginal nulo

Una vez que dispones del hardware, cada solicitud es gratuita. El consumo eléctrico de una GPU de escritorio sigue siendo insignificante frente a una factura de API por uso.

Estabilidad

No cambian las condiciones ni se retiran modelos. La versión que has descargado permanece igual mientras no la actualices.

#El punto de inflexión hacia la ejecución local

La pregunta útil no es «¿gratis o local?», sino «¿a partir de cuándo la ejecución local se convierte en la mejor opción?». Cuatro señales indican que has superado el umbral.

1. 01
   Tratas datos que no puedes exponer

   En cuanto hay código propietario, datos de clientes o información personal en el prompt, la cláusula de entrenamiento de una API gratuita se vuelve inaceptable. La ejecución local resuelve el problema de raíz: nada sale.
2. 02
   Llegas a los límites de cuota con frecuencia

   Si tus scripts terminan con errores 429, si divides tus lotes para mantenerte por debajo del límite de TPD o si alternas entre varias cuentas gratuitas, ya estás pagando en tiempo lo que la ejecución local te devolvería.
3. 03
   El volumen es previsible y sostenido

   Un uso regular —generación continua de pruebas, pipeline RAG interno, clasificación permanente— se rentabiliza rápidamente en local. El hardware es un costo fijo amortizado; la API de pago por uso supone un costo variable que aumenta con el éxito del proyecto.
4. 04
   Quieres una latencia controlada

   En una máquina dedicada, la latencia depende solo de ti, no de la carga de un servicio compartido. Para una herramienta interna utilizada todo el día, esta previsibilidad tiene un gran valor.

#Mantener los dos: el enrutamiento inteligente

La arquitectura más adecuada para un proyecto de desarrollo no se limita a una sola opción: dirige cada tarea al endpoint más adecuado. La ejecución local procesa la mayor parte del volumen y todo lo que es sensible; la nube se reserva para las tareas que realmente superan la capacidad de la máquina.

Hacia la ejecución local

Tareas de alto volumen, datos sensibles, bucles de procesamiento, iteraciones de desarrollo, todo lo que debe permanecer confidencial. Un modelo local de 7-14B cubre la inmensa mayoría de las necesidades habituales de desarrollo.

Hacia la nube

Razonamiento complejo que requiere un modelo muy grande, pico de carga puntual o funcionalidad multimodal ausente localmente. Solo se envía lo que justifica su uso, y nunca datos sensibles.

Como Ollama expone una API compatible con OpenAI, este enrutamiento se programa fácilmente: dos clientes y una regla de selección según la tarea. Para ir más allá, un proxy como LiteLLM centraliza varios backends detrás de una sola interfaz, con cambio automático a una alternativa de la nube al entorno local (o al revés) y seguimiento de costes.

from openai import OpenAI

local = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
cloud = OpenAI(base_url="https://api.exemple.com/v1", api_key="VOTRE_CLE")

def router(sensible: bool, gros_raisonnement: bool):
    # Données sensibles OU volume : local par défaut
    if sensible or not gros_raisonnement:
        return local, "qwen2.5:7b"
    # Sinon, cloud pour un modèle plus puissant
    return cloud, "modele-frontiere"

client, model = router(sensible=True, gros_raisonnement=False)
resp = client.chat.completions.create(
    model=model,
    messages=[{"role": "user", "content": "Résume ce ticket interne..."}],
)

#Empezar en local en 4 pasos

1. 01
   Instalar Ollama

   Un comando en Linux/macOS (curl -fsSL https://ollama.com/install.sh | sh) o el instalador oficial en Windows. El demonio se inicia y escucha en http://localhost:11434.
2. 02
   Elegir un modelo acorde con la capacidad de tu hardware

   Identifica tu VRAM disponible y elige un modelo en Q4_K_M que quepa con margen para el contexto: 7B (~5 GB) para 8-12 GB de VRAM, 14B (~9 GB) para 12-16 GB, 32B (~19 GB) para 24 GB. Por debajo de esas capacidades, un 3B (~2 GB) sigue siendo útil para tareas sencillas.
3. 03
   Descargar el modelo y probarlo

   ollama pull qwen2.5:7b puis ollama run qwen2.5:7b pour vérifier qu'il répond. Un pull ne se fait qu'une fois ; ensuite le modèle est en cache local.
4. 04
   Conectar tu código

   Configura tu cliente OpenAI existente para que apunte a http://localhost:11434/v1. El resto del código —mensajes, streaming, llamadas a funciones— funciona como con una API en la nube, sin clave ni cuota.

#Para ir más allá

Una vez instalado Ollama, tres guías del sitio permiten continuar de forma natural esta transición. La integración de la API REST de Ollama en Python detalla el streaming, el modo JSON y las llamadas a funciones en el endpoint local. La comparativa de costes de un servidor GPU cuantifica el umbral de rentabilidad entre la compra de hardware y las API en la nube. Y para un enrutamiento a escala de producción entre local y nube, la guía de LiteLLM muestra cómo unificar ambos detrás de un proxy con fallback y seguimiento de costes.