Roobia

Posted on Apr 16 • Originally published at apidog.com

Ejecutar modelos de IA localmente vs. vía API: ¿cuál elegir?

En resumen

La IA local se ejecuta en tu hardware, sin costo por solicitud y con máxima privacidad de datos. La IA basada en API es más rápida de implementar, ofrece capacidades superiores y escala automáticamente. La mayoría de los equipos necesitan ambos enfoques. Esta guía te muestra con cifras cuándo cada opción es mejor.

Prueba Apidog hoy mismo

Introducción

Gemma 4 ejecutándose de forma nativa en un iPhone. Una extensión de navegador que incorpora un modelo de lenguaje completo sin clave API. Esto era imposible hace 18 meses, pero hoy ya está ocurriendo y lanzándose en HackerNews.

Antes, la elección era sencilla: los modelos más potentes solo estaban disponibles por API; lo demás, demasiado limitado. Ahora, modelos locales como Qwen2.5-72B, Gemma 4 y DeepSeek-V3 compiten en benchmarks reales. Muchos desarrolladores que antes elegían la API de OpenAI están reconsiderando, sobre todo en aplicaciones sensibles a la privacidad o en tareas de alto volumen donde el costo por token escala rápidamente.

Este artículo va directo a los datos: verás cifras reales de costos, latencia y capacidades para decidir qué opción usar en tu caso.

💡 Tip: Si necesitas probar integraciones de API de IA, ya sea local o en la nube, los escenarios de prueba de Apidog funcionan para ambos. Puedes apuntar a un endpoint de llama-server local o a /v1/chat/completions de OpenAI y correr las mismas aserciones. Más adelante se explica a detalle. Consulta [interno: tutorial-de-pruebas-api] para ver el enfoque base de pruebas.

Qué significa realmente "ejecutar IA localmente"

"IA local" abarca tres arquitecturas principales:

Inferencia en el dispositivo: El modelo corre directamente en el dispositivo (ej. Gemma 4 en el Neural Engine de un iPhone, un modelo Ollama en tu MacBook). No requiere internet después de la descarga.
Servidor autoalojado: Ejecutas el modelo en tu hardware (workstation, VM en nube propia, servidor local) y expones una API. No está en el dispositivo del usuario, pero tampoco en OpenAI. Herramientas: llama-server, Ollama, vLLM.
Nube privada: Despliegas el modelo en tu infraestructura cloud (AWS Bedrock, Azure, GCP Vertex AI). Más control que una API pública, menos complicaciones que autoalojar.

Esta guía compara principalmente autoalojado vs. API pública, ya que es la decisión más común entre desarrolladores.

Comparación de costos

Aquí la IA local domina para cargas de alto volumen.

Precios de API pública (abril 2026):

Modelo	Entrada (por 1M de tokens)	Salida (por 1M de tokens)
GPT-4o	$2.50	$10.00
Claude 3.5 Sonnet	$3.00	$15.00
Gemini 1.5 Pro	$1.25	$5.00
GPT-4o mini	$0.15	$0.60
Claude 3 Haiku	$0.25	$1.25

Costo estimado autoalojado (Qwen2.5-72B en A100 de 80GB):

Una A100 80GB cuesta ~$1.99/hora on-demand (Lambda Labs).
Qwen2.5-72B INT4 cabe en una A100 y procesa ~200 tokens/segundo.
A 200 tokens/s, eso es 720K tokens/hora, o ~$0.0028 por 1K tokens (entrada+salida).
Comparado: GPT-4o cobra $0.01 por 1K tokens solo salida.

Punto de equilibrio: Si procesas más de ~70K tokens de salida/día, el autoalojamiento ya es más barato que GPT-4o. Por debajo de eso, la API gana porque no pagas GPU inactiva.

Modelos ligeros: Un Gemma 4 (12B) cuantizado a 4 bits se ejecuta en una RTX 4090 ($600-800 usada). A $0.40/hora en nube, el autoalojamiento supera a GPT-4o mini con ~15K tokens salida/día.

Comparación de latencia

Aquí entran matices importantes.

Tiempo hasta el primer token (TTFT):
- En A100 dedicada, TTFT para prompt de 1K tokens en modelo 72B: 800ms-1.5s.
- API OpenAI: generalmente 300-800ms para entradas similares bajo carga normal.
- Inferencia en dispositivo (ej. Neural Engine iPhone): TTFT para Gemma 4 es 200-400ms (sin red).
Rendimiento: Una A100 ejecutando 72B INT4 sirve bien a un usuario, pero se degrada bajo concurrencia sin batching. Las APIs públicas escalan concurrencia automáticamente.
Streaming: Ambos soportan streaming. En dispositivo, la generación es 100% local; en API dependes de la red.
Resumen: Inferencia en dispositivo = menor latencia. Autoalojado = más rendimiento (con batching). API pública = capacidad de ráfaga y facilidad.

Comparación de capacidades

Las APIs públicas todavía lideran en tareas más complejas.

Razonamiento/tareas complejas: GPT-4o y Claude 3.5 Sonnet siguen en la cima en MMLU, HumanEval y razonamiento multistep. Qwen2.5-72B y DeepSeek-V3 han reducido la brecha, pero no la cierran del todo.
Generación de código: Muy cerca. DeepSeek-Coder-V2 y Qwen2.5-Coder-32B igualan a GPT-4o en muchos benchmarks. Para tareas de código, puedes usar modelos especializados autoalojados.
Longitud del contexto: Modelos API soportan hasta 128K-1M tokens. Modelos autoalojados: 32K-128K en la práctica (más contexto = más RAM).
Multimodal: GPT-4o y Gemini 1.5 Pro soportan imagen/audio/video. Modelos open source (LLaVA, Qwen-VL) están rezagados.
Llamada a funciones/uso de herramientas: OpenAI/Anthropic tienen el soporte más robusto. Modelos open source funcionan, pero menos fiables en cadenas complejas. Consulta [interno: cómo-funciona-la-memoria-del-agente-ia] para ver su impacto en arquitecturas de agentes.

Privacidad y control de datos

Aquí lo local gana sin discusión.

API pública:

Tus prompts salen de tu red.
Se aplica la política de retención del proveedor (OpenAI guarda datos 30 días por defecto, salvo opt-out).
Sujeto a los términos del proveedor sobre contenido sensible.
En industrias reguladas, puede ser prohibitivo.

Autoalojado:

Prompts nunca salen de tu infraestructura.
Sin retención de terceros.
Control total sobre lo que procesa el modelo.
Cumplimiento GDPR/HIPAA mucho más fácil.

Para datos de salud, documentos legales o código propietario, el autoalojamiento suele ser obligatorio.

Cómo probar integraciones de IA independientemente de dónde se ejecute el modelo

Ya sea que apuntes a https://api.openai.com/v1/chat/completions, http://localhost:11434/api/chat (Ollama), o http://localhost:8080/v1/chat/completions (llama-server), la API suele ser compatible con OpenAI. Esto permite reutilizar los mismos escenarios de prueba en Apidog para cualquier endpoint HTTP.

Un ejemplo de escenario de prueba:

{
  "scenario": "Prueba de humo de finalización de chat",
  "environments": {
    "local": {"base_url": "http://localhost:11434"},
    "production": {"base_url": "https://api.openai.com"}
  },
  "steps": [
    {
      "name": "Completado básico",
      "method": "POST",
      "url": "{{base_url}}/v1/chat/completions",
      "body": {
        "model": "{{model_name}}",
        "messages": [{"role": "user", "content": "Di 'prueba superada' y nada más"}],
        "max_tokens": 20
      },
      "assertions": [
        {"field": "status", "operator": "equals", "value": 200},
        {"field": "response.choices[0].message.content", "operator": "contains", "value": "prueba superada"},
        {"field": "response.usage.total_tokens", "operator": "less_than", "value": 50}
      ]
    }
  ]
}

Corre este escenario contra Ollama localmente y contra la API de OpenAI en CI. Si hay incompatibilidades, suelen deberse a:

Formato del nombre del modelo (qwen2.5:72b vs. gpt-4o).
Estructura de respuesta para llamadas a funciones.
Formato de eventos de streaming.

Smart Mock de Apidog permite simular respuestas compatibles con OpenAI en CI sin tener una GPU activa. Consulta [interno: cómo-construir-un-llm-pequeño-desde-cero] para detalles sobre diferencias en estructuras de respuesta.

Configuración de un servidor de modelo local en 10 minutos

¿Quieres probar autoalojar un modelo? Usa Ollama para empezar rápido:

# Instalar Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Descargar un modelo (Gemma 4 12B, cabe en 10GB de VRAM)
ollama pull gemma4:12b

# Iniciar el servidor (API OpenAI compatible en puerto 11434)
ollama serve

# Probarlo
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4:12b",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Para producción y concurrencia multiusuario, vLLM es la opción recomendada:

pip install vllm
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-72B-Instruct-AWQ \
  --quantization awq \
  --max-model-len 32768

Esto expone una API OpenAI compatible en el puerto 8000. Apunta Apidog a http://your-server:8000 y ejecuta tus pruebas.

Cuándo elegir cada enfoque

Escenario	Local	API
Procesamiento por lotes de alto volumen (>100K tokens/día)	Más barato	Caro
Datos sensibles a la privacidad (salud, legal, finanzas)	Requerido	Arriesgado
Menor latencia en el dispositivo	Mejor	No es posible
Necesidad de capacidad de modelo de vanguardia	Insuficiente	Requerido
Cargas de trabajo con picos de tráfico variable	Complejo de escalar	Maneja automáticamente
Sin GPU disponible	Difícil	Fácil
Entorno de desarrollo/prueba	Excelente (Ollama)	Cuesta dinero
Tareas multimodales	Limitado	Soporte completo
Cumplimiento de la industria regulada	Más fácil	Requiere DPA

¿Qué es lo más práctico para la mayoría de los equipos?

Usa API pública para producción (Claude o GPT-4o para tasks críticos; Haiku o 4o-mini para tareas baratas de alto volumen).
Usa Ollama localmente en desarrollo y pruebas.
Así tienes calidad de vanguardia en producción, costo cero al desarrollar y una API consistente OpenAI-compatible en todo momento.

Consulta [interno: asistentes-de-codificacion-de-codigo-abierto-2026] para conocer el contexto de los asistentes de código open source en IA local.

Conclusión

La decisión local vs. API no es binaria. Depende de tu volumen, privacidad, requisitos de latencia y capacidad.

Recomendación práctica:

Empieza con API pública, migra a autoalojado si tu factura supera $200-300/mes, y usa Ollama en local desde el inicio. Mantén tu código desacoplado del proveedor usando la superficie OpenAI-compatible en todos los entornos.

Prueba ambos entornos siempre con Apidog para detectar diferencias sutiles antes de que lleguen a producción.

Preguntas Frecuentes (FAQ)

¿Cuál es la GPU mínima para un modelo local útil?

Una RTX 3060 (12GB VRAM) corre Qwen2.5-7B o Gemma 4 4B sin problemas. Una RTX 4090 (24GB VRAM) permite modelos de 14B-20B en INT4 y 34B en INT2. Para 72B necesitas 2x24GB o una A100/H100.

¿Puedo ejecutar IA local en Apple Silicon?

Sí. Ollama soporta Apple Silicon y usa el Neural Engine. Un M3 Pro (18GB RAM) ejecuta Qwen2.5-14B. Un M4 Max (128GB) maneja modelos de 70B.

¿La calidad de un modelo local es suficiente para producción?

Depende de la tarea. Para código, resumen y extracción estructurada: sí, con modelos de 32B+. Para razonamiento complejo y tasks que requieren conocimiento profundo: los modelos API siguen siendo superiores.

¿Los modelos locales soportan llamada a funciones?

Sí, pero con menor fiabilidad. Llama 3.1, Qwen2.5 y Mistral la soportan. Prueba a fondo con escenarios de Apidog antes de usar en producción. Consulta [interno: código-claude] para ver cómo los modelos top manejan uso de herramientas en código.

¿Cuánto cuesta autoalojar un modelo 70B en AWS?

Una p4d.24xlarge (8x A100 40GB) cuesta $32.77/hora. Corre modelos 70B INT8 con alto rendimiento. Una g5.2xlarge (1x A10G 24GB) a $1.21/hora ejecuta 14B INT4. Instancias reservadas bajan costos 30-40%.

¿Diferencia entre Ollama y llama.cpp?

llama.cpp es el motor de inferencia base. Ollama lo envuelve con API REST, gestión de modelos y CLI simple. Usa Ollama para desarrollo; llama.cpp directo si quieres controlar formatos de cuantización/hardware.

¿Puedo cambiar entre modelos locales y API sin tocar mi código?

Sí, usando un cliente OpenAI-compatible. En Python:

openai.OpenAI(base_url='http://localhost:11434/v1', api_key='ollama')

conecta a Ollama. Cambia base_url a https://api.openai.com/v1 y la api_key para cambiar a la nube. Si configuras por variables de entorno, tu código no cambia nunca.