Elige el tamaño de modelo adecuado para una tarea

La mayoría de los equipos recurren al modelo más grande que pueden pagar y dan por zanjado el asunto. Eso funciona, en el sentido de que un modelo capaz maneja casi cualquier cosa que le eches. Pero rara vez es la decisión correcta. El modelo más grande es la opción más lenta y cara, y muchas tareas no lo necesitan. Elegir un tamaño de modelo es un problema de emparejamiento: quieres el modelo más pequeño que haga el trabajo de forma fiable, no el más grande que puedas justificar.

Qué te compra realmente el "tamaño"

Los proveedores de modelos suelen ofrecer una familia: un nivel pequeño, rápido y barato y un nivel grande, lento y capaz, a menudo con algo intermedio. Los modelos más grandes son mejores en razonamiento difícil, instrucciones sutiles, consistencia a largo alcance y tareas donde los errores son sutiles en vez de obvios. Los modelos más pequeños son drásticamente más rápidos y baratos, y en tareas sencillas suelen ser igual de precisos.

La idea clave es que la capacidad no es un único dial que siempre quieras al máximo. Es un recurso que se gasta. Un modelo que es "más listo de lo que la tarea requiere" no aporta valor extra por ese excedente: solo cuesta más y responde más lento. El objetivo es encontrar dónde la dificultad de la tarea se encuentra con la capacidad del modelo, y detenerse ahí.

Empieza describiendo la tarea con honestidad

Antes de comparar modelos, describe lo que la tarea realmente exige. Unas pocas preguntas afinan esto rápido. ¿La tarea requiere razonamiento de varios pasos, o se acerca más a una búsqueda o una transformación? ¿Qué tan variados son los insumos: un formato estrecho y predecible, o texto desordenado y abierto? ¿Qué tan costosa es una respuesta equivocada: una molestia menor, o un fallo real? ¿Y qué tan visible es la latencia: hay una persona esperando la respuesta, o corre en segundo plano?

Clasificación, extracción, formateo, reescrituras breves y enrutamiento suelen ser fáciles en este sentido: insumos predecibles, respuestas claras, poca profundidad de razonamiento. El análisis abierto, la planificación de varios pasos, la escritura matizada y las tareas donde el modelo debe sostener muchas restricciones a la vez son difíciles. Sé honesto aquí. La tentación es llamar difícil a tu tarea porque se siente importante. Importancia y dificultad son cosas distintas: una tarea importante con mecánica simple sigue perteneciendo a un modelo pequeño.

El método de lo barato primero

La forma fiable de elegir es empezar pequeño y subir solo cuando te obliguen. Comienza con el modelo más pequeño de la familia y ejecútalo contra un conjunto de insumos reales y variados: no una demo, sino un puñado que cubra los casos fáciles y los espinosos. Lee las salidas. Si el modelo pequeño es fiablemente lo bastante bueno, has terminado, y tienes la opción más rápida y barata.

Si falla, observa cómo falla. A veces el arreglo es un mejor prompt, no un modelo más grande: instrucciones más claras, un ejemplo o dos, un modo de fallo nombrado. Prueba eso primero. Si el modelo pequeño sigue quedándose corto tras un prompt justo, sube al nivel medio y repite. Escala al modelo más grande solo cuando una evaluación real muestre que los más pequeños no pueden hacer el trabajo. Este enfoque de escalar desde abajo evita que sobrepagues por defecto, y saca a la luz problemas de prompt que un modelo grande habría enmascarado silenciosamente.

Empareja el modelo con el paso, no con la app

Un error común es elegir un solo modelo para toda una aplicación. La mayoría de los sistemas reales son pipelines con pasos de distinta dificultad. Enrutar una solicitud al manejador correcto es fácil. Redactar una respuesta cuidadosa a una pregunta compleja es difícil. Reformatear esa respuesta a JSON es fácil de nuevo. Usar tu modelo más grande para cada paso significa pagar tarifas premium por los triviales.

Un mejor diseño asigna un tamaño de modelo a cada paso. Los modelos baratos manejan clasificación, enrutamiento, extracción y formateo. Los modelos caros manejan el uno o dos pasos que genuinamente necesitan razonamiento profundo. Esto a veces se llama patrón de cascada o de enrutador: un modelo pequeño hace la mayor parte del trabajo y o bien responde directamente o pasa los casos difíciles a uno más grande. El resultado es un sistema que gasta su presupuesto de capacidad donde importa y ahorra en todo lo demás.

Sopesa costo y latencia, no solo precisión

La precisión es el titular, pero no es el único eje. La latencia moldea directamente la experiencia del usuario: una respuesta que tarda varios segundos se siente rota en un chat interactivo, pero está bien en un trabajo por lotes nocturno. Si hay una persona esperando, un modelo pequeño más rápido y algo menos pulido puede ganarle a uno grande más lento que es marginalmente mejor.

El costo se compone a escala. Una diferencia de precio entre niveles que parece trivial por solicitud se convierte en la diferencia entre un producto sostenible y uno insostenible una vez que la multiplicas por millones de llamadas. Cuando evalúes, anota juntas precisión, latencia y costo para cada candidato. La elección correcta suele ser el modelo más pequeño que supera tu umbral de precisión, porque gana decisivamente en los otros dos. Reserva el modelo grande para los casos donde la brecha de precisión es real y lo que está en juego justifica el sobreprecio.

Revisa la decisión con el tiempo

La elección de un modelo no es permanente. Los proveedores lanzan modelos nuevos con regularidad, y el nivel pequeño del próximo año a menudo iguala al nivel grande del año pasado. Una tarea que hoy necesitaba tu modelo más grande puede correr cómodamente en uno más barato tras el siguiente lanzamiento. Conserva tu conjunto de evaluación para poder volver a ejecutarlo contra modelos nuevos cuando salgan. El mismo conjunto que te ayudó a elegir al inicio te permite revisar la elección de forma barata, y la tendencia casi siempre favorece bajar un nivel, no subirlo.

Por eso también deberías evitar codificar de forma rígida suposiciones sobre un modelo específico en tus prompts y tu código. Mantén el modelo detrás de una pequeña abstracción para que cambiarlo sea un cambio de configuración, no una reescritura. Los equipos que más se benefician del progreso de los modelos son los que hicieron fácil el cambio.

En resumen

Elegir un tamaño de modelo es emparejar, no maximizar. Describe la dificultad real de la tarea, empieza con el modelo más pequeño y escala solo cuando una evaluación genuina te obligue. Asigna tamaños por paso en vez de por app, para que los modelos baratos hagan el trabajo fácil y los caros manejen las pocas partes difíciles. Sopesa latencia y costo junto con la precisión: el modelo más pequeño que supera tu umbral suele ganar en conjunto. Y revisa la elección a medida que salen modelos nuevos, porque la opción sensata por defecto se vuelve cada vez más barata.