Es tentador usar siempre el modelo más grande y más caro disponible, "por si acaso rinde mejor". En la práctica, para una parte importante de lo que hago a diario, un modelo pequeño da el mismo resultado en menos tiempo y a menor coste, y el modelo grande no aporta nada que se note.

Dónde el tamaño del modelo casi no importa

Tareas con un espacio de respuestas correctas pequeño y bien definido: clasificar un texto en una de pocas categorías, extraer un dato con un formato claro, transformar un formato a otro siguiendo una regla fija. Ahí un modelo pequeño acierta prácticamente siempre, porque la dificultad real de la tarea es baja, no porque el modelo sea especialmente bueno.

Como referencia orientativa, no un benchmark formal: en una prueba informal clasificando un par de cientos de tickets de soporte en categorías fijas, un modelo pequeño acertó alrededor del 96% de los casos frente a un 97% del modelo grande, pero respondió en una fracción del tiempo —del orden de unos cientos de milisegundos frente a varios segundos— y a un coste por millón de tokens varias veces menor. Esa diferencia de un punto de precisión no se nota en el resultado final; la diferencia de coste y latencia sí, y mucho, cuando la tarea se repite miles de veces al mes.

Dónde el tamaño sí importa, y mucho

Tareas que requieren mantener coherencia sobre mucho contexto a la vez, razonar sobre varios pasos con dependencias entre ellos, o generar código en un dominio donde hay muchas formas plausibles pero solo unas pocas correctas. Ahí la diferencia entre modelos se nota de forma clara y consistente, y usar un modelo pequeño para ahorrar sale caro en revisión y correcciones.

Cómo decido en la práctica

  • Empiezo por el modelo pequeño, no por el grande. Cuando pruebo una tarea nueva, la primera pasada es siempre con el modelo más barato disponible que sea razonable para el tipo de tarea. Si el resultado es consistentemente bueno en varios casos de prueba, me quedo ahí.
  • Subo de modelo solo cuando veo fallos sistemáticos, no ocasionales. Un fallo puntual no es motivo para cambiar de modelo, la variabilidad existe en ambos tamaños. Un patrón de fallo que se repite en el mismo tipo de caso sí lo es.
  • Reservo el modelo más grande para lo irreversible o lo ambiguo. Decisiones de arquitectura, cambios que tocan mucho código a la vez, o tareas donde el criterio de "correcto" no es binario. Ahí el coste de un error es alto y el margen que da un modelo más capaz vale la diferencia de precio.

El error de usar siempre el modelo grande "para no pensar en ello"

Usar siempre el modelo más caro por defecto no es prudencia, es evitar una decisión que sí tiene coste real, solo que ese coste aparece en la factura en vez de en el resultado. Con el volumen de peticiones que hago en un día normal, la diferencia de precio entre usar el modelo adecuado y usar siempre el más grande es significativa acumulada en un mes.

La recomendación

No asumas que el modelo más grande es siempre la opción segura. Prueba con el modelo pequeño primero en tareas nuevas, y sube de tamaño solo cuando veas un patrón de fallo real, no una sospecha. Reserva el modelo más capaz para lo que de verdad lo necesita: ambigüedad alta o coste de error alto, no todo lo demás.

Relacionado: Costes reales de usar IA a diario: lo que nadie cuenta