# Modelos pequeños vs. grandes: cuándo usar cada uno

> Un modelo grande razona mejor; uno pequeño responde antes y cuesta menos. Cómo elegir según la tarea, con las gamas de Anthropic, OpenAI y Google.

*Tags: ia, modelos, costos, arquitectura*

---


> [!info] Definición Rápida
> Un **modelo grande** tiene más parámetros, suele generalizar mejor y razonar más en tareas complejas, pero es más lento y caro. Un **modelo pequeño** es más rápido y barato, y en tareas acotadas puede dar resultados suficientes. La elección correcta depende de la tarea, no de la fama del modelo.


## ¿Qué significa "grande" y qué significa "pequeño"?

El tamaño de un modelo se mide sobre todo por su número de **parámetros**, los valores que se ajustan durante el entrenamiento. Más parámetros permiten capturar más patrones, pero exigen más memoria y más cómputo en cada respuesta.

La relación entre tamaño, datos y cómputo se ha estudiado formalmente. Kaplan y colaboradores (2020) encontraron que la pérdida de un modelo de lenguaje baja siguiendo una ley de potencia con el tamaño del modelo, el de los datos y el cómputo de entrenamiento, y que los modelos más grandes aprovechan mejor los datos. Dos años después, el trabajo de Chinchilla (Hoffmann y colaboradores, 2022) concluyó que los modelos de entonces estaban muy poco entrenados: por cada vez que se duplica el tamaño del modelo, también deberían duplicarse los tokens de entrenamiento. Su modelo de 70.000 millones de parámetros usó el mismo cómputo que Gopher, de 280.000 millones, pero cuatro veces más datos, y lo superó en una gran variedad de tareas.

La lección para ti es doble: el tamaño importa, pero no es el único factor, y un modelo más pequeño bien entrenado puede competir con uno mayor.

En los productos reales, "pequeño" y "grande" casi nunca son un número de parámetros: son **gamas** del mismo proveedor. Esto dice cada uno en sus páginas oficiales (consultadas el 2 de noviembre de 2026, descripción resumida):

| Proveedor | Gama baja | Gama alta |
|---|---|---|
| Anthropic | Haiku 5.5: el más rápido de la familia, para tareas de alto volumen y sensibles a la latencia, como clasificación, extracción y enrutamiento | Fable 5.1: para razonamiento exigente y trabajo de agentes de largo plazo. Sonnet 5.5 queda en medio, como la mejor combinación de velocidad e inteligencia |
| OpenAI | gpt-6-luna: el más eficiente, para tareas enfocadas y de alto volumen | gpt-6-astra: el más capaz, para el trabajo más exigente. gpt-6.1-sol promete rendimiento cercano al de Astra a menor costo |
| Google | Gemini 3.5 Flash-Lite: el más rápido y económico de la familia 3.5 | Gemini 3.8 Flash: su modelo Flash más inteligente (la página consultada no describe un Pro actual) |

Dos detalles. Esas páginas no publican el número de parámetros, así que no puedes comparar por tamaño real. Y la gama no determina el contexto: Haiku 5.5, Sonnet 5.5 y Fable 5.1 tienen todos una ventana de 1 millón de tokens, y los tres gpt-6 de la tabla, 1,05 millones. Ver [[ventana-de-contexto|ventana de contexto]].

## ¿Por qué le importa a un diseñador?

Porque la gama que elijas cambia la experiencia de cuatro maneras visibles:

- **Velocidad.** Anthropic etiqueta a Haiku 5.5 como el más rápido de su lineup y a Fable 5.1 como más lento, aunque aclara que la latencia real depende de la longitud del prompt, la longitud de la salida y el esfuerzo de razonamiento. Para autocompletado o clasificación, esa diferencia pesa más que la sofisticación. Ver [[latencia-en-llms|latencia y tokens por segundo]].
- **Costo.** Entre Haiku 5.5 y Fable 5.1 hay un factor de 100 en el precio de entrada: 0,10 frente a 10 dólares por millón de tokens, según la página de precios de Anthropic consultada el 2 de noviembre de 2026. Las tarifas de todos los proveedores están en [[costo-por-token|costo por token]].
- **Calidad percibida.** Un modelo grande maneja mejor los matices y las instrucciones complejas. Si tu interfaz depende de eso, el pequeño se nota.
- **Privacidad y despliegue.** Los modelos pequeños son más fáciles de correr en tu propia infraestructura. Ver [[ia-local|correr IA localmente]] y [[modelos-abiertos-vs-cerrados|modelos abiertos vs. cerrados]].

## ¿Cuándo NO conviene un modelo pequeño?

Cuando la tarea exige razonamiento de varios pasos, mucha información a la vez, o matices de tono y cultura que el usuario va a juzgar. Redactar respuestas delicadas a clientes puede pedir el modelo más capaz. Tampoco conviene si el equipo no puede medir la diferencia: sin evaluación no sabes si el ahorro se paga con calidad.

## ¿Cómo decides entre uno y otro?

Anthropic describe dos puntos de partida. El primero es **eficiencia primero**: empiezas con Haiku 5.5, pruebas a fondo y subes de gama solo si hay una carencia concreta; sirve para prototipos, latencia exigente y tareas simples de alto volumen. El segundo es **capacidad primero**: empiezas con un modelo fuerte para tareas complejas y optimizas hacia modelos más eficientes después. En ambos casos, su guía insiste en que el paso más importante es un buen conjunto de evaluación propio.

Un método práctico:

1. Define la tarea y el criterio de éxito con ejemplos reales.
2. Prueba el modelo pequeño primero, con un conjunto de casos.
3. Si falla en un tipo de caso concreto, prueba el grande solo para ese tipo.
4. Mide calidad, latencia y costo por respuesta.
5. Antes de cambiar de gama, prueba el **esfuerzo de razonamiento**. Anthropic señala que ajustarlo suele ser una mejor palanca que cambiar de modelo, y OpenAI documenta que gpt-6-luna admite niveles de esfuerzo desde ninguno hasta máximo. Ver [[modelos-de-razonamiento|modelos de razonamiento]].

## ¿Se pueden combinar un modelo pequeño y uno grande?

Sí, pero con cuidado. En sus pruebas internas, Anthropic encontró que delegar trabajo a modelos más baratos ahorró dinero en solo dos situaciones: trabajo rutinario con una cola larga de costo, y trabajo mayor que una ventana de contexto. Con un orquestador Opus 5.5 y subagentes de Haiku 5.5 en una tarea de programación, el costo por intento bajó un 32 %, pero la tasa de éxito también bajó unos 4 puntos porcentuales; eso equivalía a lo que se logra bajando el esfuerzo sin subagentes. Cuando el trabajo es una sola cadena de pasos dependientes, o cabe en un solo contexto, el modelo principal solo y con menos esfuerzo salió mejor en todos los casos medidos. Son cifras internas y orientativas: mídelo en tu caso. Ver [[orquestador-trabajador|orquestador y trabajador]] y [[subagentes|subagentes]].

## Ejemplo

Ejemplo ilustrativo: una herramienta de diseño etiqueta comentarios de usuarios en cinco categorías, un millón de veces al mes. Cada petición lleva unos 500 tokens de entrada y 20 de salida (cifras supuestas). Con los precios de la página de Anthropic del 2 de noviembre de 2026, sin caché ni lote, el costo mensual sería de unos 60 dólares con Haiku 5.5, 1.200 con Sonnet 5.5 y 6.000 con Fable 5.1.

El equipo prueba los tres con 200 comentarios reales ya etiquetados a mano. Supón que Haiku acierta en 90 % y Sonnet en 92 %. Si los usuarios no notan esos dos puntos, el equipo etiqueta en tiempo real con Haiku y reserva el modelo grande para el resumen semanal, donde la redacción importa más. Los porcentajes son hipotéticos; lo que sirve es el método: calcular el costo con precios reales y medir la calidad antes de decidir.

## Errores comunes

- Elegir el modelo más grande "por si acaso" sin probar el pequeño.
- Comparar modelos solo con resultados generales publicados cuando tu tarea es específica.
- Asumir que el costo depende solo de la gama: también cuenta la longitud de la entrada y la salida, y Haiku 5.5 cobra más cuando el prompt supera los 100.000 tokens.
- Delegar a modelos baratos sin medir cuánta calidad se pierde.
- Cambiar de modelo sin volver a evaluar la experiencia completa.

## Fuentes

- Hoffmann et al., "Training Compute-Optimal Large Language Models" (2022): [https://arxiv.org/abs/2203.15556](https://arxiv.org/abs/2203.15556)
- Kaplan et al., "Scaling Laws for Neural Language Models" (2020): [https://arxiv.org/abs/2001.08361](https://arxiv.org/abs/2001.08361)
- Anthropic, "Models overview" (consultada el 2 de noviembre de 2026): [https://platform.claude.com/docs/en/about-claude/models/overview](https://platform.claude.com/docs/en/about-claude/models/overview)
- Anthropic, "Choosing the right model" (enfoques de partida y esfuerzo): [https://platform.claude.com/docs/en/about-claude/models/choosing-a-model](https://platform.claude.com/docs/en/about-claude/models/choosing-a-model)
- Anthropic, "Optimizing for cost and intelligence" (delegación): [https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence](https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence)
- Anthropic, "Pricing" (consultada el 2 de noviembre de 2026): [https://platform.claude.com/docs/en/about-claude/pricing](https://platform.claude.com/docs/en/about-claude/pricing)
- OpenAI, "Models" (consultada el 2 de noviembre de 2026): [https://developers.openai.com/api/docs/models](https://developers.openai.com/api/docs/models)
- OpenAI, "GPT-6 Luna" (esfuerzo): [https://developers.openai.com/api/docs/models/gpt-6-luna](https://developers.openai.com/api/docs/models/gpt-6-luna)
- Google, "Gemini models" (consultada el 2 de noviembre de 2026): [https://ai.google.dev/gemini-api/docs/models](https://ai.google.dev/gemini-api/docs/models)


---

Source: https://www.fernandoux.com/es/wiki/ia/modelos-pequenos-vs-grandes/
