# Empieza por el modelo pequeño El reflejo es mandar cada tarea al modelo más grande y más listo. Los números dicen que eso casi siempre es la opción equivocada por defecto. Un modelo pequeño de 7 mil millones de parámetros sale entre 10 y 30 veces más barato que uno de 70–175B, el Phi de Microsoft iguala la calidad de la clase de GPT-3.5 con un 98% menos de cómputo, y más de dos mil millones de teléfonos ya corren modelos capaces de forma local, sin nube ninguna. Gartner espera que los modelos pequeños específicos para una tarea se usen tres veces más que los LLM generales para 2027. Aquí va por qué «pequeño primero» se está volviendo la opción inteligente por defecto, y cuándo todavía conviene tirar del grande. - **Author:** Fedor Chishchin - **Published:** 2026-06-13 - **Tags:** ai-native, business - **Source:** https://fedorthinks.com/es/blog/reach-for-the-small-model-first --- La mayoría de la gente que construye con IA tiene un solo reflejo: mandar la tarea al modelo más grande y más listo que tenga a mano. Da sensación de seguridad: ¿por qué darle el trabajo a un modelo más flojo? Pero los números de 2026 dicen que ese reflejo casi siempre es la opción equivocada por defecto, y que empezar por el modelo pequeño es la jugada que está ganando en silencio. Empecemos por la economía, porque no es nada sutil. Servir un modelo pequeño de 7 mil millones de parámetros es [entre 10 y 30 veces más barato que correr uno grande de 70–175B](https://iterathon.tech/blog/small-language-models-enterprise-2026-cost-efficiency-guide), y las empresas que mueven el trabajo adecuado a modelos pequeños están [recortando los costes de IA hasta en un 75%](https://iterathon.tech/blog/small-language-models-enterprise-2026-cost-efficiency-guide). Y esto no es sacrificar calidad a cambio de un descuento: el Phi-3.5-Mini de Microsoft [iguala el rendimiento de la clase de GPT-3.5 usando alrededor de un 98% menos de cómputo](https://iterathon.tech/blog/small-language-models-enterprise-2026-cost-efficiency-guide). La brecha entre «pequeño» y «suficientemente bueno» se cerró mientras todos miraban la frontera. Déjame defender por qué darle la vuelta a tu opción por defecto, porque cambia tanto tu factura como tu arquitectura. ## «Pequeño» dejó de significar «flojo» Hace un par de años, elegir un modelo pequeño significaba aceptar resultados visiblemente peores. Ese intercambio ya casi no existe para el trabajo que hacen la mayoría de las apps. Los modelos pequeños de hoy resuelven clasificación, extracción, enrutamiento, resúmenes, tareas con datos estructurados y código sencillo con una calidad difícil de distinguir de la del gigante, justo en el tipo de tareas que componen el grueso de un producto real. El modelo de frontera sigue siendo mejor en lo verdaderamente difícil: razonamiento profundo de varios pasos, problemas nuevos, la larga cola de casos extremos. Pero aquí está lo que la mayoría de las apps hace mal: lo difícil es una _minoría_ de las llamadas. Estás pagando precios de frontera para clasificar tickets de soporte y reformatear JSON. Es el mismo punto que [un modelo barato haciendo el 90% del trabajo](/blog/cheap-model-most-of-the-work): el modelo caro es la excepción a la que escalas, no el punto de partida por defecto. ## El nuevo superpoder: corre en el dispositivo Hay una segunda razón por la que «pequeño primero» importa, y no es solo el coste. Los modelos pequeños corren donde los grandes no pueden. Más de [dos mil millones de smartphones ya corren modelos locales capaces](https://iterathon.tech/blog/small-language-models-enterprise-2026-cost-efficiency-guide), y un modelo de mil millones de parámetros cabe en unos 650MB de RAM y corre en un teléfono a velocidad de lectura. Un modelo lo bastante pequeño significa _ningún viaje de ida y vuelta a la nube_. Eso desbloquea cosas que una API en la nube nunca podrá. Los datos jamás salen del dispositivo, lo cual es una respuesta de privacidad y cumplimiento, no solo de latencia. No hay factura por token, ni límite de peticiones, ni caída que aguantar, y funciona en un avión. Para toda una categoría de funciones (asistentes en el dispositivo, extracción privada, cualquier cosa sensible a la latencia o a la privacidad), el modelo pequeño local no es la opción económica: es la _única_ opción que tiene esas propiedades. Gartner espera que los modelos pequeños específicos para una tarea se usen [tres veces más que los LLM de propósito general para 2027](https://iterathon.tech/blog/small-language-models-enterprise-2026-cost-efficiency-guide), y esto es buena parte del porqué. ## Cuándo todavía conviene tirar del grande «Pequeño primero» es una opción por defecto, no una religión. Tira del modelo de frontera cuando la tarea realmente lo exija: - **Razonamiento difícil y abierto**: problemas de varios pasos, objetivos ambiguos, trabajo nuevo sin un patrón limpio que seguir. - **Amplitud que no puedes predecir**: un asistente general que responde cualquier cosa que un usuario pueda preguntar, donde no puedes acotar la tarea de antemano. - **Cuando aún no has medido**: prototipa con el modelo grande para aprender cómo es «bueno», y luego baja los caminos asentados y repetitivos a uno pequeño. El patrón que gana es [enrutar por dificultad](/blog/route-by-difficulty-not-by-default): modelo pequeño por defecto, escalar al grande solo cuando la tarea se lo gane. Lo que cambia es la suposición de partida: de «usa el mejor modelo y ahorra después» a «usa el modelo más pequeño que pase el listón y escala cuando no lo pase». ## En resumen El instinto de agarrar siempre el modelo más potente es una herencia de cuando los modelos pequeños eran genuinamente malos. Ya no lo son. Para el grueso de las tareas del mundo real, un modelo pequeño es entre 10 y 30 veces más barato, muchas veces corre en el dispositivo sin nube ninguna, y produce resultados que no distingues de los del gigante. Tirar de la frontera para todo por defecto es hoy, sobre todo, una forma de pagar de más y sobre-ingeniar. Así que dale la vuelta al reflejo. Empieza por el modelo pequeño, mide si pasa el listón (casi siempre lo hace) y guarda el modelo caro para la minoría de tareas que de verdad lo necesitan. Los equipos que hacen esto no están sacrificando calidad por coste. Están ajustando la herramienta al trabajo, y reciben como premio una factura más pequeña, menos latencia y mejor privacidad.