El mercado de modelos de lenguaje ha cambiado tan radicalmente en el último año que el enfoque antiguo — elegir un modelo frontier y dejarlo hacer todo — ha dejado de funcionar. Hoy dispone de modelos open-weight con ventanas de contexto de un millón de tokens, API cloud con precios cercanos a cero, despliegue local en un solo servidor y arquitecturas MoE de decenas de miles de millones de parámetros que son más ligeras de lo que parecen. Al mismo tiempo, elegir modelo sin un marco de decisión es una lotería — no por la calidad de los modelos, sino porque la mayoría de las decisiones se toman sin un encargo claro.
Este artículo proporciona un marco de decisión concreto. Cuatro dimensiones — tarea, infraestructura, coste y privacidad — y para cada una una serie de filtros que reducen la lista de candidatos a dos o tres opciones. Los números concretos provienen de fuentes verificadas; donde los datos son inciertos, lo decimos directamente.
Paso 1 — Defina qué hace el modelo (y qué no hace)
Antes de elegir el modelo es necesario saber qué tipo de tarea va a resolver. Los modelos de lenguaje no son igual de buenos en todo, y el modelo que lidera en aritmética puede quedar atrás con documentos largos.
Tres categorías básicas de tareas:
- Extracción y clasificación: Extracción de datos de escaneos, etiquetado de tickets, resúmenes. Bastan modelos más pequeños. La latencia y el throughput son más críticos que la inteligencia bruta.
- Generación y razonamiento: Redacción de informes, análisis de contratos, codificación, planificación. Aquí importa la calidad en benchmarks — prefiera modelos frontier o modelos open-weight de las familias Llama, Qwen o Mistral.
- Contexto largo: Análisis de documentación extensa, archivos corporativos, resumen de actas. Aquí los modelos difieren drásticamente — no todos gestionan la recuperación en el interior de megabytes igual de bien, aunque la ventana de contexto exista nominalmente.
Una vez que conoce el tipo de tarea, sabe en qué benchmarks fijarse: MMLU, HumanEval y GSM8K para razonamiento general y código; IFEval para seguimiento de instrucciones; RULER o las pruebas needle-in-a-haystack para contexto largo. Sin embargo, lea los benchmarks con cautela — miden condiciones específicas, no la realidad en producción. Más sobre esto en Cómo leer benchmarks de LLM.
Paso 2 — Open-weight vs. API cloud: este es el eje real de la decisión
No «qué modelo», sino «dónde corre». Esta decisión condiciona el 80 % del resto de parámetros.
API cloud (Anthropic, OpenAI, Google, Mistral, DeepSeek)
Ventajas: - Cero sobrecarga de infraestructura — paga por tokens, no por GPU - Mayor rendimiento en todas las categorías (los modelos frontier lideran los benchmarks) - Ventanas de contexto sin límite de VRAM propio - El proveedor gestiona el SLA y la disponibilidad
Limitaciones: - Sus datos y prompts salen de su infraestructura - Los precios son variables; con grandes volúmenes, los costes mensuales pueden ser de cinco cifras - Los sectores regulados (sanidad, derecho, finanzas) tienen restricciones estrictas sobre el egreso de datos
Precios orientativos en 2026: los modelos frontier (Claude Opus, GPT-5.x) se mueven en el orden de $3–25 por millón de tokens de entrada según el tier. DeepSeek y modelos similares de origen chino vía API suelen ser entre 10 y 30 veces más baratos que el frontier estadounidense. Los precios han bajado significativamente en el último año, por lo que los cálculos antiguos ya no son válidos.
Despliegue on-prem / local (modelos open-weight)
Ventajas: - Los datos no salen de la red — única vía para operaciones sensibles bajo GDPR o de carácter confidencial - Costes predecibles (hardware + energía) tras la inversión inicial - Control total sobre el modelo, los logs de prompts y las versiones
Limitaciones:
- Inversión inicial en GPU y sobrecarga de IT
- Rendimiento inferior a los modelos cloud frontier (la brecha se estrecha, pero existe)
- Necesita una capa de serving — vLLM, SGLang u Ollama (para serving en producción descarte Ollama, más adelante explicamos por qué)
Si aborda esta decisión de forma sistemática, consulte el análisis detallado en LLM local vs. cloud. Para sectores regulados se aplican condiciones adicionales — eliminar el egreso de datos con on-prem no es suficiente para el cumplimiento normativo sin audit logs y accesos controlados, algo que aborda LLM on-prem para sectores regulados.
Paso 3 — Tamaño del modelo: más grande no siempre es mejor
El mercado open-weight en 2026 está repleto de arquitecturas MoE (Mixture of Experts). Lo que significa en la práctica: un modelo denominado «400 B de parámetros» puede activar solo ~17 000 millones en una sola solicitud de inference. El recuento de parámetros y los parámetros activos son dos cifras diferentes.
Consecuencias prácticas para la selección:
- Modelos MoE (p. ej. Llama 4 Maverick, variantes MoE de Qwen 3.x, Mixtral, DeepSeek V3): Menor cómputo en inference, pero hay que cargar el modelo completo en disco y en VRAM. Los modelos MoE grandes tienen cientos de miles de millones de parámetros, de los que solo una fracción está activa en cada token — la VRAM, sin embargo, se necesita para el modelo completo. La visión ingenua de los «parámetros activos» subestima por tanto los requisitos de hardware.
- Modelos densos (Gemma 3, Phi-4, Llama 3.x más antiguo): Despliegue más directo; recuento de parámetros ≈ cómputo. Phi-4 o los modelos más pequeños de Gemma 3 son excelentes para despliegues edge y casos embebidos.
Necesidades de VRAM orientativas (sin caché KV) para tamaños habituales:
- Modelo 7–9B: formato Q4_K_M ≈ 5–7 GB de VRAM; FP16 ≈ 16–19 GB
- Modelo 13B: Q4_K_M ≈ 8 GB; FP16 ≈ 26 GB
- Modelo 70B: Q4_K_M ≈ 35–40 GB; FP16 ≈ 140–168 GB
La cuantización (GGUF Q4_K_M, AWQ 4-bit) no es automáticamente mala — en la mayoría de benchmarks se sitúa en un margen de 5–8 % respecto a la calidad FP16. La degradación significativa comienza en Q2 o por debajo. Más sobre técnicas y diferencias en Cuantización de LLM (GGUF, AWQ, GPTQ).
Para la mayoría de casos de uso B2B: un modelo 13B bien ajustado supera a un modelo 70B genérico en un dominio estrecho. Antes de decidir el tamaño merece la pena valorar si hay suficientes datos para el fine-tuning — esto lo abordamos en RAG vs. fine-tuning.
Paso 4 — Latencia y throughput: ¿quién es su usuario?
Dos perfiles completamente distintos con requisitos diferentes:
Chat interactivo (user-facing) o copilot: La latencia es crítica. El primer token debe llegar en 1–2 segundos. Aquí es relevante el TTFT (Time to First Token). Un modelo más pequeño que responde rápido es mejor que uno grande que hace esperar.
Procesamiento por lotes (batch): El throughput es crítico. Lo que importa son los tokens por segundo a lo largo de todo el lote. Aquí merece la pena un modelo mayor a cambio de mayor latencia por solicitud, porque se procesan decenas de miles de documentos a la vez.
Para la infraestructura de serving: vLLM es la elección de producción para la mayoría de despliegues NVIDIA — PagedAttention reduce drásticamente la fragmentación de la caché KV (de un desperdicio típico del 60–80 % a menos del 4 %) y el continuous batching aumenta el throughput entre 2 y 3 veces respecto al batching estático. SGLang es más potente en cargas de trabajo con prefijos repetidos (RAG, agentes, multi-turn) — los benchmarks muestran un throughput ~29 % mayor en H100 y un TTFT ~23 % más rápido que vLLM.
Ollama es adecuado para un desarrollador individual en escritorio, no para despliegues multi-usuario en producción. Con varios usuarios paralelos, el throughput es significativamente inferior al de vLLM.
Paso 5 — Coste: dónde se paga realmente
El mercado de APIs cloud LLM es hoy mucho más favorable en precios que hace un año. Pero siguen existiendo trampas.
Ventana de contexto ≠ solución más barata. Un contexto de 1 M de tokens no significa que siempre envíe un millón de tokens — paga por cada token que envía. La caché KV crece linealmente con la longitud de la secuencia. Por ejemplo, un modelo 70B con un contexto de 128 K necesita ~40 GB de caché KV por sí sola; para cuatro solicitudes paralelas a 128 K son ~160 GB adicionales por encima del modelo en sí. La ventana de contexto es capacidad, no una constante.
El prompt caching es una herramienta importante para reducir costes con prompts de sistema que se repiten. Orientativamente: con una carga de trabajo bien optimizada puede ahorrar entre el 50 y el 70 % en costes de tokens de entrada. Pero los tokens de escritura de caché son en algunas plataformas entre 1,25 y 2 veces más caros que los normales — el ahorro se produce solo a partir de la segunda lectura del mismo prefijo. Las cargas de trabajo con prompts largos únicos no obtienen beneficio del caching. Más en Prompt caching y coste.
El routing (llamar a un modelo barato para preguntas simples y al caro solo para las complejas) puede, con una calibración correcta, mantener el 95 % de la calidad a una fracción del coste. Una investigación de Berkeley mostró que con un router adecuado el 75–90 % de las llamadas van al modelo más pequeño. Esto es fácil de implementar, pero requiere evals de referencia — sin medición no se sabe dónde está el límite.
Paso 6 — Licencias y condiciones de uso
Este aspecto se descuida hasta que se convierte en un problema.
Los modelos open-weight no son automáticamente libres para cualquier uso:
- Llama 4 (Meta): Licencia personalizada de Meta. Restricción para despliegues con más de 700 millones de usuarios activos mensuales. Para la mayoría de despliegues corporativos B2B la restricción no es relevante, pero es necesario leerla.
- Qwen 3.x: Apache 2.0 — uso comercial, modificación y distribución sin regalías. Mistral: los modelos más pequeños (p. ej. Mistral Small) son Apache 2.0, los más grandes (Mistral Large) tienen su propia licencia Mistral — verifíquela para cada modelo concreto.
- DeepSeek V3: Licencia MIT — máxima libertad, incluido fine-tuning y redistribución.
- Gemma 3 (Google): Licencia propia Gemma — permite uso comercial, pero no es una licencia open-source aprobada por la OSI. Lea detenidamente las condiciones.
- Phi-4 (Microsoft): MIT.
Para las API cloud de modelos cerrados (Claude, GPT-5.x, Gemini), las condiciones vienen dadas por el SLA y los términos de servicio — preste atención a la política de retención de datos y a la opción de exclusión del uso en datos de entrenamiento.
Los sectores regulados deberían tener firmado un DPA (Data Processing Agreement) antes de la primera llamada en producción.
Paso 7 — Ventana de contexto: cuándo ayuda 1 M y cuándo no
Casi todos los modelos flagship en 2026 tienen una ventana de contexto de al menos 128 K tokens. Llama 4 Scout alcanza los 10 M. Claude (tiers superiores), Gemini 2.5 y Llama 4 Maverick ofrecen 1 M; DeepSeek V3 tiene 128 K.
La pregunta no es «cuál tiene el contexto más largo», sino «¿lo necesito?».
Las investigaciones muestran que los modelos con contextos crecientes exhiben «context rot» — la precisión de la recuperación disminuye cuando el contenido relevante está rodeado de gran cantidad de texto irrelevante. Esto se aplica especialmente a las preguntas multi-hop, donde es necesario combinar información de distintas partes del documento.
Regla práctica: Si su caso de uso implica documentos largos (contratos, manuales técnicos, archivos), pero las consultas son de carácter puntual, RAG será más económico y preciso que introducir el documento completo en el contexto. El contexto largo tiene sentido cuando realmente necesita que el modelo lea el documento entero de una vez — generación de un resumen ejecutivo de un informe de 200 páginas, análisis de una base de código.
Árbol de decisión práctico
Este proceso le reducirá en la práctica el campo a dos o tres candidatos:
- 1.¿Pueden los datos salir de su red? → No: open-weight + serving local. Sí: continúe.
- 2.¿Es crítico el throughput o la latencia y el consumo es alto? → Sí: considere serving local. No: API cloud.
- 3.¿Cuál es la tarea? → Extracción/clasificación sencilla: modelo más pequeño (7–13 B o API barata). Razonamiento complejo: frontier o un 70B+ potente.
- 4.¿Tiene un dominio específico con suficientes datos? → Considere el fine-tuning de un modelo más pequeño antes de comprar uno mayor.
- 5.¿Cuál es la licencia? → Filtre por Apache 2.0 / MIT para despliegues comerciales en producción sin sobrecarga legal.
Preguntas frecuentes
¿Cuál es el mejor modelo open-weight hoy?
No existe uno único correcto. En 2026 lideran distintos benchmarks modelos como Llama 4 Maverick, Qwen 3.x, DeepSeek y Mistral Large — depende de la tarea. Para código y razonamiento destacan los modelos de la familia Qwen; para contexto largo sobresale Llama 4 Scout (ventana de contexto de 10 M). Pruebe siempre con sus propios datos, no solo con benchmarks públicos.
¿Es DeepSeek fiable para despliegues en Europa?
DeepSeek ofrece pesos abiertos con licencia MIT — puede descargar el modelo y operarlo localmente, sin ninguna llamada a servidores chinos. Desde el punto de vista del GDPR, un despliegue local de DeepSeek es igual de «limpio» que Llama o Mistral. La versión cloud vía los servidores de DeepSeek es otra cuestión — aquí se aplican las mismas consideraciones de egreso de datos que con los proveedores estadounidenses.
¿Qué es MoE y debo tenerlo en cuenta al elegir?
MoE (Mixture of Experts) es una arquitectura en la que el modelo activa solo una parte de los parámetros en cada token. Consecuencia práctica: menor cómputo en inference, pero mayor footprint total de VRAM. Si despliega localmente, debe cargar el modelo completo en memoria aunque solo se use una fracción en cada token. Para las API cloud este detalle no le afecta — paga por los parámetros activos.
¿Vale la pena el fine-tuning en lugar de un modelo más grande?
En muchos casos sí — pero solo si dispone de suficientes datos de calidad y un dominio claramente definido. Un modelo 13B bien ajustado puede superar a un 70B genérico en una tarea industrial estrecha. Si no dispone de suficientes datos (para SFT necesita del orden de miles de ejemplos de calidad), el fine-tuning empeorará los resultados en lugar de mejorarlos. Sobre la decisión entre RAG y fine-tuning escribimos en RAG vs. fine-tuning.
¿Cómo saber si he elegido correctamente?
La elección correcta se verifica mediante evaluaciones sobre sus propios datos y casos de uso — no solo comparando benchmarks. Defina 50–100 casos de prueba con la salida esperada, ejecútelos sobre los candidatos y compare. Este proceso lo describimos en detalle en Cómo medir la calidad de una aplicación LLM.
*En MP Industrial Solutions ayudamos a las empresas a abordar la selección de modelos de forma estructurada — desde el mapeo de casos de uso hasta la prueba de candidatos y el despliegue en producción sobre infraestructura propia. Si está tomando esta decisión y quiere evitar callejones sin salida caros, estaremos encantados de hablar.*