Cómo elegir el modelo de código abierto y el hardware adecuados

Desplegar un LLM privado comienza con dos decisiones profundamente interconectadas: qué modelo ejecutar y en qué hardware ejecutarlo. Si el emparejamiento falla, o bien gastas de más en capacidad que no utilizas, o bien suministras insuficiente cómputo para lo que tu caso de uso realmente necesita. La buena noticia es que el ecosistema de código abierto ha madurado hasta el punto en que existe un modelo contrastado para casi cualquier presupuesto y tarea — si sabes cómo emparejarlos.

Empieza por el caso de uso, no por el benchmark

El error más común en la selección de modelos es partir de las puntuaciones de los benchmarks en lugar de los requisitos de la tarea. Un modelo que obtiene resultados de vanguardia en un benchmark de programación puede ser excesivo para resumir tickets de soporte, e introducir una latencia que lo haga inadecuado para uso en tiempo real. Antes de elegir un tamaño de modelo, define tu caso de uso con precisión: ¿Cuántos tokens tiene de media la entrada? ¿La tarea requiere razonamiento en múltiples pasos o es principalmente clasificación y extracción? ¿Cuántos usuarios concurrentes atenderá el sistema? ¿Cuál es la latencia de respuesta aceptable? ¿Qué idiomas debe dominar el modelo? Estas preguntas restringen tu espacio de búsqueda de forma mucho más útil que cualquier tabla de clasificación.

Niveles de tamaño de modelo: 7–8B, 32–70B y 405B+

El panorama de modelos de código abierto se ha consolidado en torno a tres niveles prácticos de tamaño. Los modelos en el rango de 7–8B parámetros — como Mistral 7B, Llama 3.1 8B y Qwen2.5 7B — son notablemente capaces para tareas enfocadas: clasificación de documentos, extracción, resumen y preguntas y respuestas estilo FAQ sobre un corpus de recuperación. Se ejecutan cómodamente en una única GPU de consumidor o prosumidor y ofrecen baja latencia incluso sin optimización intensiva. El nivel de 32–70B — Llama 3.3 70B, Qwen2.5 32B, Mixtral 8x7B — es donde el razonamiento de propósito general, la fluidez multilingüe y la calidad de seguimiento de instrucciones mejoran sustancialmente. Estos modelos pueden manejar tareas analíticas complejas, contextos más largos y una generación más matizada. Requieren GPUs de grado profesional pero siguen siendo alcanzables en un despliegue de servidor único. Por encima de los 70B, modelos como Llama 3.1 405B ofrecen capacidad de frontera pero exigen configuraciones multi-GPU y una planificación cuidadosa de la infraestructura; están reservados para casos de uso donde la calidad es la restricción principal y el presupuesto no lo es.

• Modelos de 7–8B: ideales para tareas enfocadas y de alto rendimiento — clasificación, extracción, RAG sobre datos estructurados. Una sola GPU, menor coste.
• Modelos de 32–70B: razonamiento general sólido, soporte multilingüe, contextos más largos. Una sola GPU de alta gama o un nodo multi-GPU pequeño.
• Modelos de 405B+: calidad de frontera para las tareas más exigentes. Multi-GPU obligatorio; planifica la infraestructura con cuidado.
• Las arquitecturas de mezcla de expertos (MoE) (p. ej. Mixtral) pueden ofrecer calidad de nivel 70B a un coste de parámetros activos más cercano a 13B — merece la pena evaluarlos si el rendimiento importa.

Emparejar modelos con GPUs: la VRAM es la restricción determinante

La VRAM de la GPU es la restricción principal que determina qué modelos puedes ejecutar y a qué velocidad. Un modelo debe caber en la VRAM para la inferencia — con margen adicional para la caché KV, que crece con la longitud del contexto y el tamaño del batch. Como referencia aproximada: un modelo de 7–8B en precisión de 16 bits requiere alrededor de 14–16 GB de VRAM; un modelo de 32B necesita aproximadamente 64 GB; un modelo de 70B necesita alrededor de 140 GB. Por eso una única GPU de 24 GB (como la NVIDIA RTX 3090 o 4090) es el entorno natural para los modelos de 7–8B, una tarjeta de 48 GB (RTX 6000 Ada) u 80 GB A100/H100 cubre el rango de 32–70B en una sola tarjeta, y todo lo que supere ese tamaño requiere configuraciones multi-GPU con interconexiones NVLink o InfiniBand.

Cuantización: alcanzar más allá de tu presupuesto de VRAM

La cuantización reduce la precisión de los pesos del modelo — de floats de 16 bits a enteros de 8 bits (INT8) o de 4 bits (GPTQ, AWQ, GGUF Q4) — reduciendo drásticamente los requisitos de VRAM. Un modelo de 70B cuantizado a 4 bits puede caber en aproximadamente 35–40 GB de VRAM, haciéndolo accesible en una configuración de dos GPUs de 24 GB. La compensación en calidad depende del método de cuantización y de la tarea: para la mayoría de los casos de uso en producción, INT8 es casi sin pérdidas, y una cuantización de 4 bits bien implementada conserva la mayor parte de la calidad del modelo para tareas que no son muy sensibles a errores de razonamiento sutiles. La cuantización no es un parche — es una estrategia de despliegue de primera clase que Privonis utiliza habitualmente para maximizar la capacidad por euro de presupuesto de hardware.

La pregunta correcta no es "¿qué modelo es el mejor?" sino "¿qué modelo es suficiente para esta tarea, con el presupuesto de hardware que tenemos?" La cuantización cierra la brecha entre ambas respuestas más de lo que la mayoría de los equipos esperan.

Evaluar antes de comprar: el enfoque de evaluación primero

Ningún benchmark sustituye a la evaluación de un modelo sobre tus datos y tareas reales. Antes de comprometerte con el hardware, Privonis recomienda ejecutar una evaluación estructurada: define un conjunto representativo de entradas de tu caso de uso en producción, establece criterios de calidad (precisión, adherencia al formato, latencia a tu tamaño de batch objetivo) y prueba dos o tres modelos candidatos en instancias GPU cloud alquiladas. Esto cuesta unos pocos cientos de euros y normalmente lleva uno o dos días. El resultado es una especificación de hardware basada en evidencias en lugar de una conjetura — y a menudo revela que un modelo más pequeño y más rápido satisface tus necesidades, ahorrando un gasto de capital significativo.

• Define las entradas de evaluación a partir de datos reales de producción antes de elegir un modelo.
• Prueba primero en capacidad GPU alquilada — instancias cloud para la evaluación, on-premise para la producción.
• Mide lo que importa: precisión en la tarea, latencia p95, tokens por segundo a tu tamaño de batch esperado.
• Considera el fine-tuning de un modelo más pequeño antes de escalar a uno más grande — un 7B ajustado a menudo supera a un 70B genérico en tareas específicas.
• Planifica la caché KV: los contextos más largos consumen VRAM rápidamente; haz benchmarks a la longitud máxima de contexto esperada.

Cómo Privonis guía el proceso de selección

Elegir la combinación correcta de modelo y hardware es una de las decisiones de mayor impacto en un despliegue de IA privada. Un stack bien emparejado ofrece la calidad que necesitas a un coste que hace evidente el caso de negocio; uno mal emparejado o gasta de más en cómputo inactivo o rinde por debajo en tareas que importan. Privonis aporta experiencia práctica en la selección, cuantización, fine-tuning y evaluación de LLM de código abierto en una amplia gama de casos de uso empresariales europeos. Te ayudamos a evitar el costoso ciclo de prueba y error y a llegar a una configuración de despliegue que esté correctamente dimensionada desde el principio — y que siga siendo mantenible a medida que los modelos y tus casos de uso evolucionen.