Elegir el modelo correcto

Elegir un modelo es una función de tres entradas: tu presupuesto de
memoria, tu caso de uso y tu suelo de calidad. Los benchmarks solo
informan la tercera; las dos primeras son aritmética. Optimizar una
ignorando las demás es como la gente acaba con un modelo que puntúa
precioso en benchmarks y no puede hacer la tarea real del martes.

Las tres entradas

1. Presupuesto — VRAM en una GPU, memoria unificada en Apple Silicon.
   Regla rápida: pesos en Q4_K_M ≈ 0.6 GB por cada mil millones de
   parámetros, luego añade caché KV y sobrecarga — el método completo
   está en cálculo de VRAM.
2. Caso de uso — lo que el modelo debe hacer a diario; decodificado
   abajo.
3. Suelo de calidad — el nivel por debajo del cual la salida te sirve
   de nada. Un compañero de escritura tolera más slop que un generador de
   código cuya salida debe compilar.

El presupuesto también limita el contexto: un plan de contexto enorme en
una tarjeta pequeña solo significa trocar presión de la caché KV contra
calidad de pesos. Todo se negocia.

Ejemplo resuelto, GPU de 16 GB → ~13.5 GB utilizables tras el recorte del
sistema: un 14B en Q4_K_M (~8.5 GB de pesos) con contexto generoso, o un
8B en Q6_K (~6.6 GB) con contexto enorme. Ambos caben; el caso de uso
decide entre ellos.

Empieza por el caso de uso

• Chat general y escritura — un instruct de tamaño medio (clase
  8–14B) en Q5–Q6 cubre a la mayoría. Pasado ese nivel, la preferencia
  de estilo importa más que los puntos de benchmark.
• Asistente de código — favorece los linajes coder fuertes (Qwen
  Coder, descendientes de DeepSeek-Coder) y mantén el contexto largo: el
  valor está en rellenar en mitad del archivo con el contexto del repo
  alrededor. El código real también castiga antes las cuantizaciones
  descuidadas que el chat.
• Documentos largos — verifica que el contexto reclamado sea contexto
  utilizable. Muchos modelos «128k» atienden bien al principio y al
  final y hacen puré con el medio. Prueba antes de confiar; véase el
  protocolo de abajo.
• Coreano / multilingüe — Qwen primero, Gemma segundo. Ambos manejan
  el coreano respetablemente; las familias anglófilas muestran grietas en
  gramática y honoríficos. Detalles en familias de modelos.
• Trabajo intensivo en razonamiento — prefiere checkpoints afinados
  para razonamiento (modo thinking de Qwen3, destilados R1); trocan
  latencia por corrección en matemáticas y planificación, y la
  cuantización les duele más — mantén alta la cuantización.
• Extracción masiva barata — un instruct pequeño (1.5–3B) con
  salida estructurada vence a un modelo
  grande a varias veces el coste por documento. No gastes un 8B en
  trabajo con forma de regex.
• Agentes y uso de herramientas — el requisito real es seguimiento de
  instrucciones y disciplina de formato, no IQ en bruto. En la práctica
  eso significa clase ≥7–9B, más si te lo puedes permitir: una llamada a
  herramienta malformada puede arruinar toda una cadena. Véase
  agentes.

Leer benchmarks sin que te engañen

Hábitos que te mantienen honesto: prefiere deltas relativas en el mismo
banco sobre números absolutos; trata brechas de menos de 2 puntos como
ruido; desconfía de afirmaciones sin un montaje reproducible; y lee la
discusión de contaminación alrededor de un benchmark, que a menudo
informa más que la propia tabla de clasificación.

La defensa más barata es la triangulación: un modelo genuinamente bueno
lo muestra en señales independientes — evaluaciones de laboratorio,
arena, hilos comunitarios y tu propio conjunto de prompts. Cuando las
señales discrepan, confía en las más cercanas a tu carga de trabajo. Tus
20 prompts superan cualquier tabla de clasificación para tus propósitos,
porque muestrean tu distribución real.

Señal de la comunidad local

Los benchmarks corren con prompts de laboratorio. Tu mejor señal es gente
corriendo el mismo archivo que estás a punto de descargar:

• Tendencias y recuentos de descargas de Hugging Face — popularidad de
  movimiento lento, cara de manipular durante mucho tiempo.
• Qué lanzamientos cuantizan los cuantizadores comunitarios (bartowski,
  mradermacher) en toda la escalera — un filtro de importancia decente.
• Hilos de r/LocalLLaMA — busca el nombre del modelo, ordena por
  recientes; los elogios y quejas recurrentes son reales. Aplica «a
  fecha de redacción» doblemente aquí: el consenso local tiene una vida
  media de semanas.
• Informes específicos por cuantización — la calidad del modelo X en Q4
  es una pregunta distinta del modelo X en FP16, y ambas difieren de lo
  que reportó el laboratorio.

Matriz de recomendaciones

Puntos de partida a fecha de redacción por nivel de VRAM, asumiendo
aproximadamente cuantizaciones Q4_K_M y contexto moderado — contrasta
hardware en niveles de GPU:

Trata la matriz como punto de partida de búsqueda, no evangelio — el
campo se reordena cada trimestre. El consejo estable dentro de cualquier
nivel: prefiere generaciones más nuevas, y prefiere más-grande-en-Q4
sobre más-pequeño-en-Q8 hasta el suelo de Q4 (por debajo de eso, el daño
de la cuantización gana — véase cuantización).

Una regla estable más: cuando dos modelos empatan, elige la licencia más
amable. Apache-2.0 y MIT nunca vuelven a morder; las licencias
comunitarias a veces sí — véase abierto vs cerrado.

Prueba antes de comprometerte

30 minutos con disciplina vencen una semana de vibraciones:

1. Construye un conjunto fijo de 10–20 prompts — tus casos reales más
   difíciles: un correo en coreano para reescribir, un diff con bugs que
   arreglar, un resumen de documento con un dato verificable enterrado.
2. Corre cada candidato con los mismos prompts, mismos ajustes de
   muestreo, mismo nivel de cuantización. Varía una cosa a la vez.
3. A/B a ciegas: baraja las salidas y juzga sin saber qué modelo hizo
   cuál. Una hoja de cálculo y un amigo funciona; también tu modelo
   actual más fuerte como juez.
4. Comprueba el coreano en específico: consistencia de honoríficos
   (존댓말/반말), partículas naturales, sin calcos del inglés. Los modelos
   que «saben coreano» a menudo escriben inglés traducido en ropa coreana.
5. Comprueba el contexto largo: entierra un dato al 70% de profundidad en
   un pegado largo y pregúntale por él. Esa única prueba descalifica más
   modelos «128k» que cualquier tabla.
6. Repite los empates a temperatura 0 — el ruido de muestreo se disfraza
   de diferencias de modelo más a menudo de lo que nadie admite.

El arnés pueden ser cuatro líneas de shell contra un llama-server corriendo:

while IFS= read -r prompt; do
  curl -s http://localhost:8080/v1/chat/completions \
    -H 'Content-Type: application/json' \
    -d '{"messages":[{"role":"user","content":"'"$prompt"'"}],"temperature":0.7}' \
    >> out-model-a.jsonl
done < prompts.txt

Mismo bucle, un archivo de salida por modelo; luego léelos lado a lado
con las etiquetas ocultas.

Cuándo una API cerrada sigue ganando

Lo local va de control, privacidad y coste marginal en volumen — no de
capacidad de vanguardia. A fecha de redacción, las APIs cerradas más
fuertes todavía superan a los pesos abiertos más fuertes en razonamiento
difícil y cadenas agénticas largas, con configuración cero: sin VRAM, sin
afinar motores, sin matemáticas de cuantización.

En coste, números con reservas: un 8B local en Q4 es efectivamente gratis
por token una vez existe el hardware; una API de vanguardia cobra del
orden de unos pocos dólares por millón de tokens. A volumen de aficionado
ambos redondean a cero; a millones de tokens al día, lo local gana solo
en precio. La brecha de capacidad — no el precio — es la razón honesta
para conservar una clave de API.

Un patrón duradero es el híbrido: modelo local por omisión, API para los
pocos prompts que lo atascen. Pondera el intercambio conscientemente en
abierto vs cerrado.

Relacionados: Niveles de GPU · Familias de modelos · Agentes · Abierto vs cerrado