LLMs Locales vs. APIs en la Nube: Costo Real, Velocidad y Privacidad

Ejecutas inferencias 50 veces al día. Una API en la nube cuesta $0.03 por cada 1K tokens. Eso es manejable hasta que tu uso escala. LLM local en tu hardware: cero costo por token, funciona offline, mantiene la privacidad. Pero es más lento, requiere configuración y tu portátil de 8GB no puede ejecutar Llama 2 70B de forma efectiva.

La decisión no es «nube o local». Es: ¿qué compromiso tiene sentido para tu carga de trabajo específica, presupuesto y limitaciones? Esta guía analiza las matemáticas reales, no comparaciones teóricas, sino números de la ejecución de ambos en producción.

El Cálculo Real del Costo: Costos por Token vs. Infraestructura

Las APIs en la nube cobran por token. Los modelos locales cobran en infraestructura, electricidad y tiempo de desarrollador.

Vamos a analizar dos escenarios con números reales de marzo de 2025:

*Los costos de hardware asumen una amortización de 3 años para una GPU de gama media (RTX 4070 ~$550, alquiler en la nube A100 ~$10k). Varía significativamente según el modelo y el tamaño del lote.

Esto es lo que significa en la práctica. Un sistema de producción que procesa 10M tokens al mes:

• GPT-4o: ~$1,800/mes costo de tokens + $0 hardware = $1,800
• Claude 3.5 Sonnet: ~$1,080/mes costo de tokens + $0 hardware = $1,080
• Llama 3.1 70B (local): ~$0 costo de tokens + $60/mes hardware = $60
• Mistral 7B (local): ~$0 costo de tokens + $45/mes hardware = $45

La opción local es más barata. Para la mayoría de las cargas de trabajo por debajo de 100K tokens/mes, la nube gana en costo total (la amortización del hardware todavía domina). Más allá de eso, lo local se vuelve económico en 3-6 meses.

Pero el costo no es la única variable. La velocidad importa.

Latencia: Por Qué la Nube Suele Ser Más Rápida, Contra lo Que Podrías Esperar

Los LLMs locales deberían ser más rápidos: la inferencia ocurre en tu hardware, sin saltos de red. En la práctica, son más lentos. Por qué.

Los proveedores de API en la nube optimizan para dos cosas que tú no: procesamiento por lotes y hardware especializado. OpenAI y Anthropic ejecutan miles de solicitudes concurrentes en clústeres A100. Han optimizado cada milisegundo de la pila de inferencia. Tu GPU local es una sola máquina.

Comparación de latencia en el mundo real (de sistemas AlgoVesta, enero de 2025):

• Claude 3.5 Sonnet (API): respuesta de 400 tokens = ~840ms de extremo a extremo (incluida la red)
• Mistral 7B (local, RTX 4070): respuesta de 400 tokens = ~1,800ms
• Llama 3.1 8B (local, RTX 4070): respuesta de 400 tokens = ~1,200ms
• Llama 3.1 70B (local, RTX 4090): respuesta de 400 tokens = ~3,200ms

Los modelos locales más pequeños pueden igualar la latencia de la nube en algunos casos (Mistral 7B está cerca). Los modelos locales más grandes son estrictamente más lentos. La latencia de red añade 100-300ms a las llamadas a la nube, pero la inferencia del lado de la nube es mucho más rápida.

Si tu caso de uso requiere tiempos de respuesta inferiores a 1000ms y estás considerando lo local, planifica con Mistral 7B o uno más pequeño. Cualquier cosa más grande te decepcionará.

Precisión y Capacidad: Cuándo los Modelos Locales se Quedan Atrás

Esta es la limitación de la que nadie habla honestamente. Los modelos locales más pequeños sacrifican precisión.

Datos de referencia de MMLU (razonamiento de sentido común en 57 disciplinas):

• Claude 3.5 Sonnet: 88% de precisión
• GPT-4o: 86% de precisión
• Llama 3.1 70B: 83% de precisión
• Mistral 7B: 62% de precisión
• Phi-3.5-mini (3.8B): 51% de precisión

Esa brecha se amplía en tareas específicas de dominio (razonamiento médico, generación de código, extracción estructurada). Los modelos locales también tienen problemas con:

• Razonamiento de contexto largo: Llama 3.1 70B tiene una ventana de contexto de 8K frente a los 200K de Claude. Importa para sistemas RAG y procesamiento de documentos.
• Seguimiento de instrucciones: Los modelos en la nube tienen una mejor alineación. Los modelos locales más pequeños alucinan instrucciones que no existen.
• Soporte multilingüe: GPT-4o y Claude manejan más de 50 idiomas. Llama 3.1 está entrenado en más de 30, pero las salidas son menos fiables.
• Uso de herramientas: Los modelos en la nube llaman funciones de forma fiable. Los modelos locales fallan en el formato de los parámetros de las funciones.

Para clasificación, resumen y preguntas y respuestas simples, la brecha no importa. Para cualquier cosa que requiera razonamiento, creatividad o análisis complejo de instrucciones, los modelos locales pierden.

Privacidad y Datos: La Verdadera Victoria de lo Local

Esto no es teórico. Es contractual.

Usar APIs en la nube significa que los datos van a sus servidores. Incluso con cláusulas de «sin retención», transitan por su infraestructura. GDPR, HIPAA y otras regulaciones pueden prohibirlo. Tus acuerdos con clientes también.

Los modelos locales resuelven esto por completo. Los datos nunca abandonan tu hardware. Sin registros, sin infraestructura en la nube, sin exposición a terceros.

Pero «local» tiene grados. Todavía necesitas:

• Pesos del modelo: Descargados de HuggingFace o de un proveedor. Esa descarga única se registra.
• Seguridad del hardware: Tu servidor GPU debe estar físicamente aislado/aislado de la red. Un cortafuegos mal configurado anula el beneficio total de privacidad.
• Marco de inferencia: Herramientas como Ollama, vLLM o el servidor de inferencia de Hugging Face añaden otra capa. Verifica que no almacenen en caché ni registren la salida.

Para industrias reguladas (finanzas, salud, legal), lo local suele ser obligatorio. Para todo lo demás, es una opción si otras limitaciones coinciden.

Recomendaciones Específicas para Cargas de Trabajo: Dónde Gana Cada Uno

Usa APIs en la Nube Cuando:

• La alta precisión importa más que el costo. Razonamiento complejo, generación de código, tareas creativas. Claude 3.5 Sonnet es la mejor opción para esta categoría.
• La carga variable es impredecible. No puedes predecir el volumen de tokens mes a mes. La nube escala automáticamente. Lo local requiere sobreaprovisionamiento para manejar picos.
• El tiempo de respuesta debe ser inferior a 1 segundo. Incluso Mistral 7B tendrá problemas. La nube gana.
• La longitud del contexto importa. Procesar documentos completos, conversaciones largas o resultados de recuperación. La ventana de contexto de 200K de Claude o los 128K de GPT-4o superan las opciones locales.
• Quieres cero sobrecarga de infraestructura. Clave API + solicitud HTTP. Eso es todo. Sin adquisición de GPU, sin gestión de versiones, sin depuración de CUDA.

Usa LLMs Locales Cuando:

• La privacidad es innegociable. Cargas de trabajo HIPAA, datos regulados, datos de clientes que no pueden transitar por infraestructura en la nube.
• El volumen de tokens es predecible y alto. 10M+ tokens/mes, carga constante. El ROI del hardware se produce en 6 meses.
• La tarea es estrecha y bien definida. Clasificación, extracción, resumen. Los modelos más pequeños (7B-13B) funcionan bien y son lo suficientemente rápidos.
• La variabilidad de la latencia importa más que la velocidad absoluta. La inferencia local es más consistente que la nube (sin fluctuaciones de cola). Útil para sistemas en tiempo real que requieren un rendimiento predecible.
• Ya tienes infraestructura de GPU. La amortización de costos hundidos cambia completamente la ecuación.

Guía de Implementación: Construcción de una Pila Híbrida

La configuración óptima para la mayoría de los sistemas de producción no es puramente en la nube ni puramente local. Es ambas.

Patrón de Arquitectura: Enrutamiento por Carga de Trabajo

Enruta diferentes tareas a diferentes modelos según los requisitos:

class InferenceRouter:
    def __init__(self):
        self.cloud_client = Anthropic()  # API de Claude
        self.local_model = LocalModel("mistral-7b")  # Inferencia local
    
    def process_request(self, task_type, input_text, metadata):
        # Alta precisión, razonamiento complejo → nube
        if task_type in ["code_generation", "analysis", "reasoning"]:
            return self.cloud_inference(input_text)
        
        # Sensible a la privacidad → local
        if metadata.get("is_regulated") or metadata.get("pii_present"):
            return self.local_inference(input_text)
        
        # Clasificación/extracción simple → local (más barato, suficiente)
        if task_type in ["classification", "extraction"]:
            return self.local_inference(input_text)
        
        # Por defecto: optimizado para costos (usar local, recurrir a la nube si la confianza es baja)
        result = self.local_inference(input_text)
        if result.get("confidence", 1.0) < 0.7:
            return self.cloud_inference(input_text)
        return result
    
    def cloud_inference(self, text):
        message = self.cloud_client.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=1024,
            messages=[{"role": "user", "content": text}]
        )
        return {"output": message.content[0].text, "source": "cloud"}
    
    def local_inference(self, text):
        output = self.local_model.generate(text, max_tokens=1024)
        return {"output": output, "source": "local"}

Este patrón maneja restricciones reales: usas lo local para trabajo rutinario y ahorro de costos, la nube para tareas complejas y garantías de precisión.

Configuración de Seguimiento de Costos

Sin medición, no sabrás si el enfoque híbrido realmente está ahorrando dinero. Implementa el seguimiento de costos desde el primer día:

import json
from datetime import datetime

class CostTracker:
    def __init__(self, log_file="inference_costs.jsonl"):
        self.log_file = log_file
        self.cloud_costs = {"claude-3-5-sonnet": 0.003}  # por 1K tokens
        self.local_cost_per_hour = 0.05  # hardware amortizado + electricidad
    
    def log_inference(self, source, input_tokens, output_tokens, latency_ms):
        """Registra cada inferencia para análisis de costos"""
        if source == "cloud":
            # Claude 3.5 Sonnet: $3/1M entrada, $15/1M salida
            cost = (input_tokens * 0.000003) + (output_tokens * 0.000015)
        elif source == "local":
            # Costo por ms de tiempo de inferencia (amortizado)
            cost = (latency_ms / 1000 / 3600) * self.local_cost_per_hour
        else:
            cost = 0
        
        record = {
            "timestamp": datetime.utcnow().isoformat(),
            "source": source,
            "input_tokens": input_tokens,
            "output_tokens": output_tokens,
            "latency_ms": latency_ms,
            "cost_usd": round(cost, 6)
        }
        
        with open(self.log_file, "a") as f:
            f.write(json.dumps(record) + "\n")
        
        return cost

# Uso:
tracker = CostTracker()
tracker.log_inference("cloud", input_tokens=450, output_tokens=200, latency_ms=850)
tracker.log_inference("local", input_tokens=450, output_tokens=200, latency_ms=1800)

Ejecuta esto durante un mes. Sabrás exactamente de dónde provienen tus ahorros.

Lista de Verificación de Configuración: Puesta en Marcha de Modelos Locales

Si decides que lo local tiene sentido para tu carga de trabajo, esto es lo que realmente requiere la implementación:

Verificación de Hardware

El tamaño del modelo determina los requisitos de GPU:

Configuración de Software (usando vLLM)

vLLM es el marco de inferencia estándar para producción. Es más rápido que la carga basada en transformers y maneja el batching automáticamente:

# Instalar vLLM
pip install vllm

# Ejecutar un servidor de modelos
vllm serve mistralai/Mistral-7B-Instruct-v0.2 \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.8

# En otra terminal, probarlo
curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistralai/Mistral-7B-Instruct-v0.2",
    "prompt": "¿Cuánto es 2+2?",
    "max_tokens": 100
  }'

vLLM expone una API compatible con OpenAI. Esto significa que puedes cambiar los endpoints sin modificar el código de la aplicación: solo apunta tu cliente a localhost:8000 en lugar de api.openai.com.

Docker para Producción

No ejecutes vLLM directamente en tu máquina de producción. Usa Docker para aislamiento y reproducibilidad:

# Dockerfile para el servidor de inferencia vLLM
FROM nvidia/cuda:12.1.0-devel-ubuntu22.04

RUN pip install vllm==0.4.1

CMD ["vllm", "serve", "mistralai/Mistral-7B-Instruct-v0.2", \
     "--host", "0.0.0.0", "--port", "8000"]

Construye y ejecuta:

docker build -t local-llm .
docker run --gpus all -p 8000:8000 local-llm

Modos de Fallo Comunes y Cómo Evitarlos

Aprendiendo de implementaciones reales:

• Errores de falta de memoria durante la inferencia: Probaste con batch_size=1 pero producción ejecuta batch_size=8. La GPU se queda sin VRAM a mitad del lote. Siempre prueba con tamaños de lote y longitudes de contexto de producción.
• Picos de latencia por recolección de basura: La memoria de la GPU local se llena, se activa la GC, la inferencia se pausa. Configura `gpu_memory_utilization` de vLLM a 0.85-0.90, no a 0.95+.
• Degradación de las salidas del modelo con el tiempo: Algunos modelos locales tienen problemas de calidad con secuencias de tokens más largas. Mide la calidad de la salida (mediante revisión humana o métricas automatizadas) a 1000 tokens, 4000 tokens y 8000 tokens. Conoce los límites de tu modelo.
• Los costos de cambio de API son mayores de lo esperado: Usas vLLM localmente pero API en la nube remotamente. Los formatos de respuesta difieren ligeramente. Pequeñas diferencias en el formato del prompt se acumulan. Crea una capa de normalización en tu código cliente.
• La latencia de arranque en frío aniquila el rendimiento: La primera inferencia después de reiniciar el servidor es 2-3 veces más lenta (carga del modelo). Mantén el servidor caliente o precarga al iniciar.

Matriz de Decisión: Qué Hacer Hoy

Deja de teorizar. Responde estas tres preguntas:

1. ¿Cuántos tokens/mes procesas?

• Menos de 500K: Las APIs en la nube son más baratas. Usa Claude 3.5 Sonnet.
• 500K-5M: Zona de punto de equilibrio. Depende de las necesidades de precisión y las restricciones de privacidad.
• 5M+: Los modelos locales pagan el hardware en 6 meses. Implementa enrutamiento híbrido.

2. ¿Es la privacidad de los datos un requisito?

• Sí: Ve a lo local, sin debate. GDPR, HIPAA y los contratos con clientes a menudo lo exigen.
• No: La API en la nube es más simple. Evita la sobrecarga de infraestructura.

3. ¿Cuánta precisión necesitas?

• Clasificación/extracción: Los modelos locales 7B funcionan bien. Usa Mistral 7B.
• Razonamiento/generación de código: Los modelos en la nube son significativamente mejores. Usa Claude 3.5 Sonnet.
• No estás seguro: Empieza con la nube, mide la calidad, cambia a lo local si cumple los umbrales.

Si procesas 2M+ tokens/mes y la precisión no es crítica, implementa el enrutador híbrido de la sección anterior hoy mismo. Pruébalo en el 10% de tu carga de trabajo. Mide el costo por inferencia en ambas fuentes. En 30 días, tendrás datos para tomar la decisión real.