6  El panorama y la elección

Cualquier lista de modelos escrita hoy caduca en meses. Lo que no caduca son los ejes sobre los que se elige, así que este capítulo va de eso, con los nombres de 2026 como ejemplo y no como recomendación.

6.1 Los dos bloques

El primer eje es si los pesos del modelo son públicos o no.

Los modelos cerrados (las familias de OpenAI, Anthropic o Google) se consumen por API. Marcan la frontera de capacidad, se actualizan solos y no requieren ninguna infraestructura. A cambio, los datos salen de casa, el proveedor puede cambiar o retirar el modelo, y el precio lo pone otro.

Los modelos de pesos abiertos (Llama, Qwen, DeepSeek, Mistral, Gemma, gpt-oss) se descargan y se ejecutan donde uno quiera. La brecha de capacidad con la frontera, que en 2023 era abismal, se ha estrechado hasta el punto de que para la mayoría de cargas productivas la pregunta ya no es si sirven, sino cuál encaja.

Nota“Abierto” no significa libre

Conviene mirar la licencia y no el titular. Conviven al menos tres regímenes:

• Permisivas de verdad (Apache 2.0, MIT): uso comercial sin condiciones relevantes.
• Con restricciones: la licencia de Llama, por ejemplo, impone condiciones sobre uso y atribución, y un umbral de usuarios por encima del cual hay que negociar.
• Solo investigación: descartadas para producción, aunque su ficha diga open.

Y en ningún caso hablamos de código abierto en sentido estricto: se publican los pesos, casi nunca los datos de entrenamiento ni la receta completa. El término correcto es pesos abiertos.

6.2 Mixture of Experts, o por qué el tamaño ya no dice nada

Casi todos los modelos punteros de 2026 son MoE (mixture of experts): en lugar de una red densa que se activa entera, tienen muchos bloques especializados y una red que decide cuáles se encienden para cada token. El resultado es que un modelo puede tener cientos de miles de millones de parámetros totales y activar solo unas decenas de miles de millones en cada paso.

La consecuencia práctica importa mucho a la hora de desplegar: los parámetros totales determinan la memoria que hace falta; los activos determinan la velocidad y el coste por token. Un modelo de 400.000 millones de parámetros totales y 17.000 millones activos es rápido como uno pequeño y voraz de memoria como uno enorme. Comparar dos modelos por su número de parámetros dejó de tener sentido.

6.3 Los ejes que sí decide uno

Al elegir modelo, en la práctica se negocian cinco cosas a la vez.

flowchart TD
    e["Elección de modelo"] --> c["Capacidad"]
    e --> l["Latencia"]
    e --> p["Coste"]
    e --> s["Soberanía del dato"]
    e --> ct["Control de versión"]

    classDef modelo fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
    classDef control fill:#d7eddc,stroke:#4a9463,stroke-width:1.5px,color:#1c4a2e
    class e modelo
    class c,l,p,s,ct control

Los tres primeros son el triángulo de siempre y se resuelven midiendo. Los dos últimos son los que suelen decidir de verdad en una empresa, y rara vez aparecen en los benchmarks:

• Soberanía del dato: si el caso de uso toca datos personales o secreto industrial, la conversación con quien lleva cumplimiento llega antes que la comparativa técnica. Un modelo abierto ejecutado dentro del perímetro convierte un problema legal en un problema de operaciones, que suele ser más fácil.
• Control de versión: con pesos propios, el modelo de dentro de un año es exactamente el mismo. Con API, no. Para un sistema regulado que hay que auditar, eso tiene un valor difícil de exagerar.

6.4 Dónde ejecutar los abiertos

Si se opta por pesos abiertos, hay tres perfiles de despliegue bien diferenciados y elegir mal es la causa más común de decepción.

Tres formas de ejecutar el mismo fichero de pesos

Herramienta	Para qué es	Para qué no
Ollama / llama.cpp	Portátil, prototipo, un usuario	Servir tráfico real
vLLM / TGI / SGLang	Servicio con concurrencia, lotes continuos	Trastear en un rato
API gestionada de abiertos	Modelos abiertos sin GPUs propias	Cuando el dato no puede salir

La tercera opción es la que más se olvida y la que más veces encaja: proveedores que sirven modelos de pesos abiertos por API. Se conserva la portabilidad (los mismos pesos se pueden traer a casa el día que convenga) sin comprar hardware. No resuelve la soberanía del dato, pero sí el bloqueo de proveedor.

AdvertenciaLa cuenta de la GPU

Es tentador comparar el precio por token de una API con el coste de una GPU y concluir que se ahorra. La comparación honesta incluye la GPU parada de noche, la persona que la mantiene, el modelo que hay que reevaluar cuando salga uno mejor y la capacidad que hay que sobredimensionar para el pico.

El punto de equilibrio existe y aparece con volumen alto y sostenido. Por debajo de eso, ejecutar en casa se justifica por soberanía o por control, no por precio. Que sean razones perfectamente válidas no las convierte en razones económicas.

6.5 Cuantización, o cómo hacer que quepa

Un modelo se entrena en 16 bits por parámetro pero puede servirse en 8, 4 o menos, redondeando los pesos. Es lo que permite meter un modelo grande en una GPU modesta.

La regla de bolsillo para estimar la memoria: parámetros totales × bits por parámetro / 8, más un margen generoso (30% o más) para la caché KV, que crece con el contexto y la concurrencia. Un modelo de 70.000 millones en 4 bits ronda los 35 GB solo de pesos.

La pérdida de calidad al bajar a 8 bits es casi imperceptible; a 4 bits es pequeña pero real y se concentra justo donde más molesta: razonamiento largo, código y seguimiento de instrucciones complejas. Si un modelo cuantizado “va peor sin saber por qué”, la cuantización es el primer sospechoso.

6.6 Una forma sensata de decidir

Reducido a lo esencial, y por este orden:

1. Prototipar con el mejor modelo disponible. Si el caso de uso no funciona con el mejor, no es un problema de modelo y bajar de gama solo confunde el diagnóstico.
2. Construir el conjunto de evaluación con casos reales antes de comparar nada. Sin él, la elección de modelo es una opinión. Es el capítulo de evaluación y es la pieza que más se salta.
3. Bajar de gama hasta que se rompa, midiendo con ese conjunto. Casi siempre se puede bajar más de lo que uno cree.
4. Aislar la decisión detrás de un gateway, para que cambiar de modelo sea una línea de configuración y no un proyecto.

TipEl ajuste fino casi nunca es la respuesta

Ante un resultado insuficiente, la reacción habitual es proponer un fine-tuning. Antes de eso conviene agotar el orden natural: mejor prompt, luego contexto recuperado, luego herramientas, y solo entonces ajuste fino.

El ajuste fino enseña forma, no hechos: es la herramienta correcta para fijar un formato de salida, un tono o un vocabulario propio, y la incorrecta para meter conocimiento que cambia, porque cada cambio obliga a reentrenar. Además congela el modelo base: cuando salga uno mejor dentro de seis meses, hay que rehacer el trabajo.

Y cuando, agotado ese orden, resulte que sí toca ajustar, el capítulo siguiente cuenta en qué consiste y cómo saber si ha servido.