El error más común al elegir un modelo de IA es ir directamente al que tiene más parámetros y la puntuación más alta en benchmarks. Parece obvio. Opus le gana a Haiku, así que usa Opus. En proyectos reales esa lógica suele estar al revés.
Un modelo más grande cuesta más, corre más lento y (lo menos intuitivo) piensa de más el trabajo simple. Pídele que limpie una frase y te devuelve un ensayo corto con tres alternativas y una nota sobre casos límite. El orden correcto es el inverso: pon el trabajo a funcionar en el modelo más pequeño que sea suficientemente bueno y sube solo cuando te topes con un techo de calidad.
Empieza por lo pequeño. Justifica al subir.
La trampa
Por qué "más grande es mejor" es una trampa
El tamaño del modelo es realmente una diferencia en el conteo de parámetros. Más parámetros significa más variables que el modelo puede sostener a la vez, lo que ayuda en problemas complejos, ambiguos y multi-paso. Esa capacidad tiene un precio, y en tareas simples nunca lo recuperas:
Coste
Dentro del mismo proveedor, un modelo insignia suele costar decenas de veces más por token que su versión ligera. A decenas de miles de llamadas al día, esa brecha decide si el proyecto es sostenible.
Latencia
Los modelos más grandes emiten tokens más lento. Para chat en tiempo real o autocompletado, "más listo" se anula con "más lento."
Pensar de más
El más tramposo. Dale a un modelo insignia un trabajo de clasificación de texto y puede devolverte razonamiento, una puntuación de confianza y notas sobre casos límite. Tú querías una etiqueta. La capacidad sobrante en una tarea simple no es una ventaja, es ruido.
La analogía del restaurante de fideos
Pregunta "qué hay para cenar" y un niño no sabe responder, pero un adulto te pregunta por tu presupuesto, tus alergias y qué tan picante lo quieres. El adulto es más fuerte, pero todo lo que necesitabas era "el sitio de fideos de abajo." La mayoría de las tareas de IA son tareas de sitio de fideos. No necesitan un experto.
Tres preguntas
Tres preguntas: resta dentro de un presupuesto
Pon primero un techo de coste: con tu volumen real de llamadas, cuánto es lo máximo que puedes gastar al mes. Esa línea acota tus candidatos. Luego, dentro de ella, haz tres preguntas:
| Dimensión | Ve más pequeño | Ve más grande |
|---|---|---|
| Complejidad de la tarea | Clasificación, resúmenes, formateo, extracción | Código complejo, razonamiento de cadena larga, juicio legal/médico |
| Volumen de llamadas | Alta frecuencia, batch (decenas de miles/día) | Baja frecuencia, puntuales (decenas/día) |
| Coste del error | Un reintento lo arregla | Un error es caro (cálculo erróneo, engañar a un usuario) |
Cuanto más caigas en la columna de "ve más grande", más se gana su sueldo un modelo más fuerte. En caso contrario, un modelo ligero es casi siempre la mejor respuesta. Fíjate que esto es resta: el valor por defecto es pequeño, y cada subida necesita una razón concreta, no "el más fuerte no puede hacer daño."
Algunas decisiones concretas: las respuestas de soporte al cliente son de alto volumen y tolerantes al error, así que un modelo ligero más un fallback basta. La revisión de código es compleja y poco tolerante, así que merece un insignia. El resumen de documentos largos no es complejo pero necesita una ventana de contexto grande, así que ve por un modelo barato de contexto largo en lugar del insignia más caro.
Acorta la lista rápido
La forma perezosa: deja que una herramienta de finder acote por ti
Puedes llevar todo esto en la cabeza: qué modelo es el más barato, cuál tiene el contexto más largo, cuál es el más fuerte en código. Pero con más de 100 modelos y precios que se mueven cada semana, la selección basada en memoria caduca rápido.
La ruta más fácil es una herramienta de finder de modelos. Varias gratuitas corren en el navegador, no necesitan registro y traen precios en vivo, así que no estás mirando un número de hace seis meses. Siguen las mismas tres preguntas y hacen el trabajo pesado por ti:
Tres pasos, cerca de un minuto:
Elige un caso de uso
Responde "qué estás construyendo": codificación, agentes de IA, RAG / documentos largos, chat general, escritura, extracción de datos, traducción, visión, roleplay, generación de imágenes, embeddings. Elige el más cercano.
Lee el ranking
Puntúa más de 100 modelos en calidad, precio y velocidad, y cubre listas populares: el mejor para código, el mejor para agentes, el mejor para RAG, el más barato, el más rápido, el mejor para contexto largo (100K+), y demás.
Copia la lista corta
Cada lista está ordenada. Si no quieres correr tus propias pruebas, prueba los dos o tres primeros con tus prompts reales.
Básicamente son las tres preguntas convertidas en una interacción de un minuto, que le gana a adivinar a partir de un leaderboard estático. FACTA es neutral respecto al proveedor — elige el finder o catálogo de proveedor en el que confíes; el punto es acotar el campo contra precios en vivo antes de probar.
Después de elegir
Un endpoint para cada modelo
Elegir es el paso uno. El patrón maduro es el routing por tiers: las tareas simples van a un modelo ligero, las intermedias a un tier medio y solo la porción más difícil llega a un insignia. Mantienes la calidad donde importa y empujas la mayor parte del coste a modelos baratos.
Eso solo funciona si cambiar de modelo es fácil. Registrar, recargar y cablear autenticación y facturación distintas para cada proveedor es un tipo especial de miseria. Un gateway neutral respecto al proveedor y compatible con OpenAI pone más de 100 modelos detrás de un endpoint y una clave, facturado por token sin cuota mensual. Apunta tu código existente a una sola URL base y cambiar de modelo se convierte en cambiar un string — así la configuración por tiers se mantiene barata de reequilibrar cuando los precios se mueven.
El routing por tiers solo compensa si cambiar el modelo es un cambio de un string, no una reintegración.
Conclusión
Construye hacia arriba desde lo suficientemente bueno
Volviendo a la línea de apertura: no elijas un modelo recortando desde el más fuerte, construye desde lo suficientemente bueno.
- Usa por defecto un modelo ligero y pon la lógica de negocio a funcionar.
- Usa las tres preguntas (complejidad / volumen / coste del error) para decidir qué partes merecen una mejora.
- Cuando dudes, abre una herramienta de finder, elige un caso de uso, lee el ranking, decide en diez minutos.
- Cablea todo detrás de un endpoint para que cambiar de modelo siga siendo barato.
El modelo más caro no es el que mejor te encaja. Ejecuta dos o tres candidatos con tus propios prompts reales y compara la salida. Eso te dice más que cualquier informe de benchmarks, y más rápido.
Referencias
Referencias
- AWS, "Bigger AI Models Aren't Always Better: Here's How to Actually Choose" (el encuadre que este artículo localiza)
- Catálogos de modelos de los proveedores y precios por token en vivo (consultados para las comparaciones de coste y latencia)
- Documentación de modelos de Anthropic (routing por tiers a lo largo de la línea Claude)
Sobre FACTA
FACTA es una consultora de IA. Ayudamos a los equipos a elegir el modelo adecuado para cada tarea, ruteear entre tiers y medir coste por resultado en lugar de coste por token.
Escribimos estas guías porque el reflejo por defecto — elegir el modelo más grande con el benchmark más alto — es el que hunde proyectos de IA en coste y latencia sin que nadie lo note. La disciplina es empezar por lo pequeño y justificar cada subida.
Si quieres una evaluación neutral respecto al proveedor de qué modelos encajan en qué porciones de tu carga, o ayuda para diseñar una configuración de routing por tiers, podemos ayudar.
Neutral respecto al proveedor por diseño. Empieza por lo pequeño, justifica al subir.