Ejecutar LLMs en tu propio hardware: costos y requisitos reales

El año pasado invertí 4.200 USD en montar un equipo de inferencia local capaz de ejecutar un modelo de 70B parámetros a una velocidad razonable. Un colega miró mi configuración y me hizo la pregunta obvia: '¿Por qué no simplemente usar la API? Eso equivale a unos ocho años de créditos de API.' No se equivocaba con las cuentas. Pero sí se equivocaba en la lógica de fondo.

Ejecutar modelos de lenguaje grandes en local solía ser territorio de laboratorios de investigación con clústeres de GPU montados en racks. Eso cambió rápido. El hardware de consumo, las técnicas de cuantización y los motores de inferencia optimizados han puesto modelos de más de 70B al alcance de aficionados dedicados y equipos pequeños. Dispositivos como el Tinybox llevan las cosas aún más lejos: hardware diseñado específicamente para ejecutar modelos de 120B parámetros sin conexión, sin necesidad de la nube.

Pero 'posible' y 'práctico' son cosas distintas. Hablemos de lo que realmente se necesita para ejecutar modelos grandes en local, cuándo tiene sentido hacerlo y cuándo es mejor pagar por una API.

¿Por qué ejecutar modelos en local?

El modelo de API (enviar tus datos a un proveedor en la nube y recibir los resultados) funciona bien para la mayoría de los casos. Es más sencillo, más barato por consulta con volúmenes bajos y siempre te da acceso a los modelos más recientes. Entonces, ¿por qué alguien se complicaría con la inferencia local?

• Privacidad y cumplimiento. Algunos datos no pueden salir de tu red. Historiales médicos, documentos legales, código propietario, datos financieros: los sectores regulados suelen tener requisitos estrictos sobre dónde residen los datos. Enviar historiales de pacientes a un endpoint de API, incluso uno cifrado, puede violar HIPAA. La inferencia local mantiene todo dentro de tus instalaciones.
• Latencia. Las llamadas a una API implican viajes de ida y vuelta por la red, posibles tiempos de espera en cola y límites de tasa. La inferencia local no tiene latencia de red y nunca estás en una cola. En aplicaciones interactivas (asistentes de código en tiempo real, traducción en el dispositivo, interfaces de voz), la diferencia entre 50 ms y 500 ms es la diferencia entre 'ágil' y 'lento'.
• Costo a escala. El precio de las APIs se cobra por token. En volúmenes bajos es insignificante. En volúmenes altos se acumula de forma brutal. Un equipo que hace mucha revisión de código, análisis de documentos o procesamiento por lotes puede gastar miles de dólares al mes en API. El hardware local tiene un costo fijo: una vez pagado, la inferencia es prácticamente gratis.
• Disponibilidad. Las APIs en la nube se caen. Se imponen límites de uso. Los precios cambian sin previo aviso. Los modelos se deprecan. Si tu producto depende de una API de terceros, estás a merced de sus decisiones de negocio. La inferencia local significa que tu capacidad no desaparece porque el servidor de otro tenga un mal día.
• Libertad para experimentar. Los proveedores de API tienen políticas de uso. Deciden qué puedes y qué no puedes hacer con el modelo. Los modelos locales no tienen esas restricciones: puedes ajustarlos con fine-tuning, modificarlos, usarlos para cualquier fin y ejecutarlos todas las veces que quieras.

La realidad del hardware

La restricción fundamental para la inferencia de LLMs es la memoria, no el cómputo. Los parámetros del modelo tienen que caber en memoria (VRAM de la GPU o RAM del sistema) antes de que puedas hacer cualquier cosa con ellos. Un modelo de 70B parámetros en punto flotante de 16 bits necesita unos 140 GB de memoria. Eso es más de lo que ofrece cualquier GPU de consumo.

Aquí es donde la cuantización cambia el juego. Al reducir la precisión de los pesos del modelo de 16 bits a 8, 4 o incluso 2 bits, puedes reducir drásticamente los requisitos de memoria:

Memory requirements for a 70B parameter model:
FP16 (full precision):  ~140 GB  → requires multiple A100s
INT8 (8-bit quant):     ~70 GB   → requires 2x RTX 4090 (48GB total)
Q4_K_M (4-bit quant):   ~40 GB   → fits on 2x RTX 3090 or 1x A6000
Q2_K (2-bit quant):     ~25 GB   → fits on 1x RTX 4090 (24GB)
For a 120B parameter model:
FP16:                   ~240 GB  → enterprise GPU territory
INT8:                   ~120 GB  → 5x RTX 4090 or purpose-built device
Q4_K_M:                 ~70 GB   → 3x RTX 4090
Q2_K:                   ~40 GB   → 2x RTX 4090

La cuantización de 4 bits (Q4_K_M en el ecosistema de llama.cpp) es el punto ideal actual. La degradación de calidad es medible, pero suele ser aceptable para uso práctico: la mayoría de la gente no distingue la salida Q4 de la precisión completa en pruebas a ciegas. La cuantización de 2 bits afecta notablemente la calidad, sobre todo en tareas que requieren razonamiento, pero sigue funcionando para aplicaciones más simples como clasificación de texto o resúmenes.

Configuraciones de hardware de consumo

Si estás montando tu propia configuración de inferencia local, tienes tres caminos básicos, cada uno con un perfil de precio-rendimiento distinto.

El camino de una sola GPU

Una RTX 4090 (24 GB de VRAM, unos 1.600 USD) puede ejecutar cómodamente modelos cuantizados a 4 bits de hasta unos 30B parámetros, o modelos de 70B con cuantización agresiva de 2 bits. Para la mayoría de los modelos de 7B a 13B, es excesiva: obtendrás más de 40 tokens por segundo, más rápido de lo que la mayoría de la gente puede leer. Este es el camino más fácil: compra una GPU, instala llama.cpp u Ollama y listo.

El camino multi-GPU

Dos o más GPUs te permiten dividir un modelo entre varios dispositivos (paralelismo de tensores). Dos RTX 3090 (48 GB de VRAM en total, unos 2.200 USD de segunda mano) pueden ejecutar cómodamente modelos de 70B cuantizados a 4 bits. El problema: necesitas una placa base con suficientes líneas PCIe y espacio físico para varias GPUs de tamaño completo. La ventilación se vuelve un problema serio: dos GPUs de 350 W dentro de una misma caja generan mucho calor.

El camino de memoria unificada

Los Mac con Apple Silicon y gran memoria unificada ofrecen una opción sorprendentemente viable. Un M2 Ultra con 192 GB de memoria unificada puede alojar un modelo de 70B en precisión completa enteramente en memoria. La velocidad de inferencia es menor que la de las GPUs dedicadas (quizás 10 a 15 tokens por segundo con un modelo de 70B), pero la simplicidad es difícil de superar. Sin problemas de drivers, sin configuración multi-GPU, sin gestión térmica. Solo un Mac Studio sobre tu escritorio ejecutando un modelo de 70B.

Los chips de la serie M logran esto con una arquitectura de memoria unificada: la CPU y la GPU comparten el mismo pool de memoria, así que no hay cuello de botella por copiar datos entre la RAM de la CPU y la VRAM de la GPU. El ancho de banda de memoria es menor que en una configuración con GPU dedicada, y por eso la inferencia es más lenta, pero tener 192 GB de memoria direccionable en un equipo que consume 60 vatios es realmente impresionante.

Dispositivos de inferencia diseñados para ello

La categoría más nueva es la del hardware de inferencia local diseñado específicamente: dispositivos dedicados pensados para ejecutar modelos grandes de forma eficiente. Buscan resolver el lío del multi-GPU: en lugar de armar GPUs de consumo con pesadillas de cableado, obtienes un equipo diseñado desde cero para la inferencia.

El atractivo es obvio. Lo enchufas, apuntas tu aplicación hacia él y ejecuta tu modelo. Sin conflictos de drivers, sin gestionar versiones de CUDA, sin throttling térmico porque alguien puso tres GPUs demasiado juntas. La contrapartida es el costo: los dispositivos diseñados para esto suelen costar más por FLOP que las GPUs de consumo equivalentes. Pagas por la integración, la fiabilidad y por no tener que depurar la asignación de líneas PCIe.

Para las pequeñas empresas que necesitan inferencia local pero no tienen ingenieros de hardware en plantilla, estos dispositivos tienen sentido. Para los aficionados que disfrutan construyendo cosas, los equipos multi-GPU caseros siguen siendo más baratos y más flexibles.

El stack de software

El hardware es solo la mitad de la historia. El stack de software para inferencia ha evolucionado rápidamente, y la elección correcta puede duplicar tu throughput con el mismo hardware.

• llama.cpp — La navaja suiza de la inferencia local. Escrito en C/C++, funciona en todo, desde Raspberry Pi hasta servidores multi-GPU. Soporta decenas de arquitecturas de modelos y formatos de cuantización. No siempre es el más rápido, pero es el más portable y se mantiene activamente.
• vLLM — Optimizado para throughput en GPUs NVIDIA. Usa PagedAttention para gestionar la memoria de la GPU de forma eficiente, lo que mejora mucho la inferencia por lotes. Si atiendes a varios usuarios desde una misma máquina, vLLM suele ser la mejor opción.
• Ollama — El enfoque de 'Docker para LLMs'. Envuelve llama.cpp en una interfaz amigable con un registro de modelos. Ejecuta ollama run llama3:70b y descarga el modelo, configura la cuantización y empieza a servir. Excelente para empezar, pero menos configurable que llama.cpp directamente.
• MLX — El framework de machine learning de Apple, optimizado para Apple Silicon. Si usas un Mac con chip de la serie M, MLX suele dar mejor rendimiento que llama.cpp al aprovechar la memoria unificada de forma más eficaz.

# Getting started with Ollama (the easiest path)
# Install: https://ollama.ai
# Run a 7B model (downloads automatically, ~4GB)
$ ollama run mistral
# Run a 70B model (needs ~40GB RAM/VRAM)
$ ollama run llama3:70b-instruct-q4_K_M
# Serve as an API endpoint (OpenAI-compatible)
$ ollama serve
$ curl http://localhost:11434/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "mistral",
"messages": [{"role": "user", "content": "Explain TCP handshakes"}]
}'

La comparativa de costos sin rodeos

Hagamos las cuentas que realmente importan. Supongamos que ejecutas un modelo de 70B y procesas alrededor de 1 millón de tokens al día (aproximadamente equivalente a analizar entre 50 y 100 documentos o atender unas cuantas cientos de conversaciones de chat).

Cloud API (approximate pricing for 70B-class model):
Input:  $0.50 per million tokens
Output: $1.50 per million tokens
Daily cost: ~$2.00
Monthly cost: ~$60
Yearly cost: ~$720
Local inference (2x RTX 4090 build):
Hardware: $4,200 (one-time)
Electricity: ~$30/month (assuming 700W, 8h/day, $0.15/kWh)
Break-even: ~5.5 years
Local inference (Mac Studio M2 Ultra 192GB):
Hardware: $5,800 (one-time)
Electricity: ~$3/month (60W)
Break-even: ~8 years

Con 1 millón de tokens al día, la API en la nube es más barata durante años. Pero ese cálculo cambia drásticamente si el volumen aumenta. Con 10 millones de tokens al día, la API cuesta 7.200 USD al año y el hardware local se amortiza en unos 7 meses. Con 50 millones de tokens al día, la inferencia local se paga sola en cuestión de semanas.

La comparativa de costos también ignora los factores no financieros: privacidad, latencia, disponibilidad y libertad para experimentar. Si alguno de ellos es un requisito (y no un simple extra), la comparación financiera pasa a un segundo plano.

Lo que se pierde en la cuantización

La cuantización es lo que hace posible la inferencia local de modelos grandes, pero no es gratis. Reducir la precisión implica perder algo de información, y la degradación no es uniforme entre tareas.

En mis pruebas, los modelos cuantizados a 4 bits rinden casi igual que la precisión completa en: generación de texto, resúmenes, preguntas y respuestas simples, traducción y generación de código para patrones comunes. La degradación aparece en: razonamiento complejo de varios pasos, cálculo matemático, tareas que requieren recordar con precisión datos de entrenamiento y seguimiento de instrucciones matizadas.

En la práctica: si usas un modelo local para autocompletado de código, resumen de documentos o IA conversacional, la cuantización de 4 bits es perfectamente válida. Si lo usas para razonamiento analítico complejo o tareas donde las diferencias sutiles de precisión importan, conviene probar con cuidado y quizás usar mayor precisión, a cambio de más memoria o de un modelo más pequeño.

Tomar la decisión

Después de un año ejecutando modelos en local, este es mi marco para decidir entre inferencia local y en la nube:

Usa APIs en la nube cuando: necesites la mejor calidad de modelo posible, tu volumen sea bajo o moderado, no tengas experiencia en hardware, necesites cambiar de modelo con frecuencia o la latencia no sea crítica (unos cientos de milisegundos están bien).

Ejecuta en local cuando: tus datos no puedan salir de tu red, necesites una latencia constante por debajo de 100 ms, tu volumen de tokens sea lo bastante alto como para justificar el hardware, quieras experimentar libremente sin costos por consulta o necesites disponibilidad de inferencia independiente del tiempo de actividad de terceros.

El panorama cambia rápido. Los modelos son cada vez más pequeños y eficientes. Las técnicas de cuantización mejoran. El hardware se abarata. El umbral de volumen a partir del cual la inferencia local tiene sentido económico baja cada año. Si hoy no te compensa, puede que dentro de dieciocho meses sí, y mientras tanto el stack de software solo se volverá más fácil de usar.