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

En resumen

La IA local se ejecuta en tu hardware, no tiene costo por solicitud y mantiene los datos privados. La IA basada en API es más rápida de implementar, más capaz y escala sin infraestructura. La mayoría de los equipos necesitan ambas. Esta guía cubre cuándo cada enfoque es superior, con cifras concretas.

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 una clave API. Esto no era posible hace 18 meses. Hoy se están lanzando en HackerNews.

La decisión solía ser sencilla: los modelos de vanguardia solo eran accesibles por API, todo lo demás era demasiado débil para importar. Eso ha cambiado. Modelos locales como Qwen2.5-72B, Gemma 4 y DeepSeek-V3 ahora compiten en benchmarks reales. Los desarrolladores que antes optaban por la API de OpenAI están reconsiderando, especialmente para aplicaciones sensibles a la privacidad o tareas de alto volumen donde los costos por token se acumulan rápidamente.

Este artículo va más allá del marketing. Obtendrás cifras concretas sobre costos, latencia y capacidad para que puedas tomar la decisión correcta para tu caso de uso.

Qué significa realmente "ejecutar IA localmente"

La IA local no es una sola cosa. Hay tres configuraciones distintas:

Inferencia en el dispositivo: el modelo se ejecuta completamente en el dispositivo, sin servidor. Gemma Gem en una pestaña del navegador, Gemma 4 en el Neural Engine de un iPhone, o un modelo Ollama en tu MacBook. No se requiere internet después de la descarga.

Servidor autoalojado: ejecutas un modelo en tu propio hardware (una estación de trabajo, una VM en la nube que controlas o un servidor local) y expones una API. El modelo no se ejecuta en el dispositivo del usuario final, pero tampoco está en OpenAI. Herramientas como llama-server, Ollama y vLLM se encargan de esto.

Nube privada: implementas un modelo en tu propia infraestructura en la nube (modelos personalizados de AWS Bedrock, endpoints privados de Azure, modelos personalizados de GCP Vertex AI). Más control que una API pública, menos complicaciones que un autoalojamiento completo.

La comparación en este artículo se centra en autoalojado vs. API pública, ya que esa es la decisión que enfrentan la mayoría de los desarrolladores.

Comparación de costos

Aquí es donde la IA local gana claramente para cargas de trabajo de alto volumen.

Precios de API pública (abril de 2026):

Estimación de costo autoalojado (Qwen2.5-72B en una sola A100 de 80GB):

Una A100 de 80 GB de Lambda Labs cuesta aproximadamente $1.99/hora bajo demanda. Qwen2.5-72B con cuantización INT4 cabe en una A100 y procesa aproximadamente 200 tokens/segundo.

A 200 tokens/segundo con un 100% de utilización, eso es 720K tokens/hora, o aproximadamente $0.0028 por 1K tokens en total (entrada + salida). Para contextualizar, GPT-4o cobra $0.01 por 1K tokens solo de salida.

Punto de equilibrio: si procesas más de ~70K tokens de salida por día de forma consistente, el autoalojamiento supera a GPT-4o en costo. Por debajo de eso, la API gana porque no estás pagando por el tiempo de GPU inactivo.

Para modelos más ligeros: un Gemma 4 (12B) cuantizado a 4 bits se ejecuta en una única RTX 4090 ($600-800 usada). A $0.40/hora por tiempo de GPU en la nube equivalente, el autoalojamiento alcanza el punto de equilibrio frente a GPT-4o mini con aproximadamente 15K tokens de salida/día.

Comparación de latencia

Aquí es donde la situación se vuelve más matizada.

Tiempo hasta el primer token (TTFT): en una A100 dedicada, el TTFT para un prompt de 1K tokens con un modelo de 72B es de aproximadamente 800ms-1.5s. La API de OpenAI generalmente devuelve el primer token en 300-800ms para entradas similares bajo carga normal.

Para la inferencia en el dispositivo (Neural Engine de iPhone, Apple Silicon), el TTFT para Gemma 4 es de 200-400ms porque no hay sobrecarga de red. Aquí es donde la ejecución en el dispositivo gana claramente.

Rendimiento: una única A100 ejecutando un modelo de 72B en INT4 atiende bien a un usuario, pero se degrada bajo carga concurrente sin procesamiento por lotes. Las APIs públicas gestionan la concurrencia de forma transparente.

Streaming: ambos enfoques admiten el streaming. Para los modelos en el dispositivo, toda la generación ocurre localmente, por lo que no hay fluctuaciones de red. Para los modelos de API, estás a merced de las condiciones de la red.

Resumen: la ejecución en el dispositivo gana por la latencia más baja (sin red). El autoalojamiento gana por el rendimiento a escala (con un procesamiento por lotes adecuado a través de vLLM). La API pública gana por la capacidad de ráfaga y la simplicidad.

Comparación de capacidades

Aquí es donde las APIs públicas todavía tienen ventaja para las tareas más exigentes.

Razonamiento y tareas complejas: GPT-4o y Claude 3.5 Sonnet siguen estando por delante de los modelos de código abierto en MMLU, HumanEval y razonamiento complejo de múltiples pasos. La brecha se ha reducido significativamente con Qwen2.5-72B y DeepSeek-V3, pero sigue siendo real.

Generación de código: cerca. DeepSeek-Coder-V2 y Qwen2.5-Coder-32B igualan a GPT-4o en muchos benchmarks de código. Para tareas específicas de código en una configuración autoalojada, puedes usar un modelo de código especializado en lugar de uno de propósito general.

Longitud del contexto: los modelos API de vanguardia admiten contextos de 128K-1M tokens. La mayoría de los modelos autoalojados alcanzan un máximo de 32K-128K en la práctica (contextos más largos requieren proporcionalmente más memoria).

Multimodal: GPT-4o y Gemini 1.5 Pro manejan entradas de imagen, audio y video. Existen modelos multimodales de código abierto (LLaVA, Qwen-VL) pero están rezagados.

Llamada a funciones / uso de herramientas: OpenAI y Anthropic tienen el soporte más fiable para el uso de herramientas. Los modelos de código abierto con uso de herramientas funcionan, pero son menos consistentes en cadenas de herramientas complejas. Consulta [interno: cómo-funciona-la-memoria-del-agente-ia] para ver cómo esto afecta las arquitecturas de agentes.

Privacidad y control de datos

Aquí es donde lo local gana sin discusión.

Con una API pública: - Tus prompts salen de tu red - Se aplica la política de retención de datos del proveedor (OpenAI retiene las entradas durante 30 días por defecto, a menos que optes por no hacerlo a través de la API) - Estás sujeto a los términos de servicio del proveedor sobre contenido sensible - En industrias reguladas (salud, finanzas, legal), esto puede ser un impedimento para el cumplimiento.

Con un modelo autoalojado: - Los prompts permanecen en tu infraestructura - Sin retención de datos de terceros - Control total sobre lo que el modelo puede y no puede procesar - El cumplimiento de GDPR/HIPAA es más fácil de mantener.

Para aplicaciones que manejan datos de salud personales, documentos legales o código propietario, el autoalojamiento a menudo no es opcional.

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

Ya sea que estés apuntando a https://api.openai.com/v1/chat/completions o http://localhost:11434/api/chat (Ollama) o http://localhost:8080/v1/chat/completions (llama-server), la superficie de la API es compatible con OpenAI. Esto es importante porque los escenarios de prueba de Apidog funcionan con cualquier endpoint HTTP.

Un único escenario de prueba puede ejecutarse contra ambos:

{
  "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}
      ]
    }
  ]
}

Ejecuta este escenario contra tu instancia local de Ollama durante el desarrollo y contra la API de OpenAI en CI. Si tu código funciona con el modelo local, debería funcionar con la API. Si no, la diferencia suele radicar en: - Formato del nombre del modelo (Ollama usa qwen2.5:72b, OpenAI usa gpt-4o) - Estructura de respuesta de la llamada a funciones (diferencias sutiles entre proveedores) - Formato de eventos de streaming (data vs. delta vs. objetos de respuesta completos)

Smart Mock de Apidog es útil para simular el comportamiento del modelo local en CI sin necesidad de tener la GPU en línea. Configura un mock que devuelva respuestas válidas compatibles con OpenAI y ejecuta tus escenarios de prueba contra él. Consulta [interno: cómo-construir-un-llm-pequeño-desde-cero] para obtener información sobre por qué las estructuras de respuesta difieren a nivel del modelo.

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

Si quieres probar el autoalojamiento antes de comprometerte, Ollama es el camino más 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 compatible con OpenAI en el 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 el autoalojamiento en producción con concurrencia multiusuario, vLLM es la mejor opción:

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 compatible con OpenAI en el puerto 8000. Apunta Apidog a http://your-server:8000 y ejecuta tus escenarios de prueba directamente.

Cuándo elegir cada enfoque

La respuesta honesta para la mayoría de los equipos: usa una API pública para producción (Claude o GPT-4o para tareas de calidad, Haiku o 4o-mini para tareas más baratas de alto volumen), y Ollama localmente para desarrollo y pruebas. Esto te da lo mejor de ambos mundos: calidad de vanguardia en producción, costo cero en desarrollo y una superficie de API consistente compatible con OpenAI en todo momento.

Consulta [interno: asistentes-de-codificacion-de-codigo-abierto-2026] para ver cómo los asistentes de codificación de código abierto encajan en el panorama de la IA local.

Conclusión

La decisión entre local y API no es binaria. La respuesta correcta depende de tu volumen, requisitos de privacidad, necesidades de latencia y el nivel de capacidad que necesites.

Para la mayoría de los desarrolladores que construyen aplicaciones con IA: empieza con una API pública, muévete al autoalojamiento cuando tu factura mensual supere los $200-300, y usa Ollama en tu entorno local desde el primer día. Mantén tu código independiente del proveedor usando la superficie de API compatible con OpenAI en todas partes.

Prueba ambos entornos de forma consistente con Apidog para detectar las diferencias sutiles entre el comportamiento de los modelos locales y en la nube antes de que se conviertan en errores de producción.

Preguntas Frecuentes (FAQ)

¿Cuál es la GPU mínima para ejecutar un modelo local útil?Una RTX 3060 (12GB VRAM) ejecuta Qwen2.5-7B o Gemma 4 4B con calidad completa. Una RTX 4090 (24GB VRAM) maneja la mayoría de los modelos de 14B-20B con cuantización INT4 y modelos de 34B con INT2. Para modelos de 72B, necesitas 2 GPUs de 24GB o una sola A100/H100.

¿Puedo ejecutar IA local en Apple Silicon?Sí. Ollama tiene soporte nativo para Apple Silicon y utiliza el Neural Engine para la aceleración. Un M3 Pro (18GB de memoria unificada) ejecuta Qwen2.5-14B cómodamente. Un M4 Max (128GB) maneja modelos de 70B.

¿La calidad de la salida del modelo local es suficiente para producción?Depende de la tarea. Para generación de código, resumen y extracción de datos estructurados: sí, con un modelo de 32B+. Para razonamiento complejo, escritura matizada o tareas que requieren un conocimiento profundo del mundo: los modelos API de vanguardia todavía tienen una clara ventaja.

¿Los modelos locales admiten la llamada a funciones?Sí, pero de forma inconsistente. Llama 3.1, Qwen2.5 y Mistral admiten el uso de herramientas. La fiabilidad es menor que la de GPT-4o o Claude 3.5 Sonnet en cadenas de herramientas complejas. Prueba a fondo con los escenarios de prueba de Apidog antes de depender del uso de herramientas de modelos locales en producción. Consulta [interno: código-claude] para ver cómo los modelos de vanguardia manejan el uso de herramientas en contextos de codificación.

¿Cuánto cuesta autoalojar un modelo de 70B en AWS?Una p4d.24xlarge (8x A100 40GB) cuesta $32.77/hora bajo demanda. Ejecuta un modelo 70B INT8 con alto rendimiento. Una g5.2xlarge (1x A10G 24GB) a $1.21/hora ejecuta un modelo 14B INT4 para cargas de trabajo más ligeras. Las instancias reservadas reducen estos costos en un 30-40%.

¿Cuál es la diferencia entre Ollama y llama.cpp?llama.cpp es el motor de inferencia subyacente. Ollama envuelve llama.cpp con una API REST, gestión de modelos (descargar, listar, eliminar) y una CLI sencilla. Usa Ollama para desarrollo. Usa llama.cpp directamente (a través de llama-server) si necesitas más control sobre los formatos de cuantización o la configuración del hardware.

¿Puedo cambiar entre modelos locales y de API sin modificar mi código?Sí, si usas un cliente compatible con OpenAI. En Python: openai.OpenAI(base_url='http://localhost:11434/v1', api_key='ollama') se conecta a Ollama. Cambia base_url a https://api.openai.com/v1 y actualiza api_key para cambiar a la nube. Configura esto a través de variables de entorno y tu código nunca cambiará.