Una de las decisiones más subestimadas en un proyecto con IA es qué modelo usar. La mayoría de los equipos la resuelve por defecto: "usamos GPT porque es lo que todos usan" o "probamos Claude porque alguien lo mencionó en LinkedIn". Después descubren, dos meses más tarde, que ese default les cuesta diez veces lo que deberían pagar, o que su caso no requería un modelo frontier para nada.
Este post explica cómo pensamos nosotros la decisión. No es un benchmark abstracto; es el criterio que usamos con clientes reales.
La pregunta correcta no es "cuál es mejor"
Si buscás "cuál es el mejor LLM" en Google vas a encontrar diez artículos comparando resultados en MMLU, HumanEval y otros benchmarks. Son interesantes pero casi irrelevantes para decisiones de producción. Te dicen qué modelo es mejor en promedio, no qué modelo es mejor para tu caso específico, con tu presupuesto, tu latencia tolerada y tu dataset.
La pregunta correcta es: dado mi caso de uso, ¿cuál es el modelo más barato que resuelve el problema con calidad suficiente? "Barato" y "suficiente" son las dos palabras clave, y las dos dependen de tu contexto.
Los 4 ejes que miramos
Para cada proyecto evaluamos el modelo contra cuatro dimensiones. No todas pesan lo mismo en cada caso.
1. Calidad de razonamiento requerida
Es la pregunta más fácil de hacer y la más difícil de estimar. ¿Tu tarea requiere razonamiento multi-paso, manejo de ambigüedad, síntesis de información contradictoria? ¿O es clasificación, extracción estructurada, reformulación, resumen?
La mayoría de los casos reales de PyMEs que vemos están en la segunda categoría. Tareas de extracción ("sacame estos 8 campos de esta factura"), clasificación ("este ticket es urgente, normal o bajo"), generación acotada ("escribí un mail de confirmación basado en estos datos"). Para estas tareas, GPT-4o-mini, Claude Haiku o un Llama 3.3 70B corriendo en Groq dan resultados indistinguibles de los modelos frontier, a una fracción del costo.
Los casos que sí necesitan frontier son: decisiones de negocio con alto impacto donde un error cuesta caro, tareas de razonamiento encadenado sin structured output, creatividad donde la diferencia de calidad se nota. Son una minoría.
2. Costo por ejecución y a volumen
El costo del token es solo el punto de partida. Lo que importa de verdad es el costo por ejecución de tu workflow, multiplicado por el volumen esperado.
Un número que nos ha salvado muchas veces: calculá el costo asumiendo 10 veces tu volumen actual. Si a 10x el presupuesto explota, el workflow está sostenido por un modelo demasiado caro y se va a volver insostenible el día que el negocio crezca. Mejor elegir un modelo más barato ahora y tener margen que optimizar bajo presión cuando los usuarios ya dependen del sistema.
Orden de magnitud aproximado (abril 2026, precios API oficiales):
- Frontier (GPT-4o, Claude 4.6 Opus, Gemini 2.5 Pro): 10 a 30 USD por millón de tokens de input.
- Mid (GPT-4o-mini, Claude 4.6 Sonnet, Gemini 2.5 Flash): 0.5 a 3 USD por millón.
- Open-source via provider (Llama 3.3 70B en Groq, DeepSeek V3): 0.2 a 0.8 USD por millón.
- Open-source self-hosted: costo fijo de GPU, económico solo a muy alto volumen.
La brecha entre frontier y mid es de 10x a 30x. Justificar un modelo frontier requiere mostrar que la diferencia de calidad genera ese ratio de valor. Rara vez lo hace.
3. Latencia tolerada
Para un workflow asíncrono (procesar facturas, generar reportes nocturnos, clasificar tickets en batch), la latencia del modelo importa poco. Si tarda 3 segundos o 15 segundos, es igual.
Para un workflow síncrono que afecta UX (chatbot, autocomplete, generación en tiempo real), la latencia es lo primero que miramos. Un modelo frontier que tarda 8 segundos en dar la primera palabra arruina la experiencia. Un modelo mid que responde en 600ms puede ser peor en calidad pura pero mejor en la experiencia total.
Groq y Cerebras cambiaron la conversación acá. Un Llama 3.3 corriendo en Groq da latencias de 100-200ms a primera palabra que ningún modelo cerrado iguala. Para casos sensibles a latencia, es la opción que primero evaluamos.
4. Residencia y privacidad de datos
Para clientes en rubros regulados (salud, finanzas, legales) o con clientes europeos, la residencia de datos no es negociable. Algunas opciones:
- OpenAI API estándar: los datos no se usan para entrenar, pero se procesan en infraestructura de OpenAI en US. Para la mayoría de los casos alcanza.
- Azure OpenAI: mismo modelo, infraestructura de Microsoft con compliance más fuerte. La opción estándar para corporate.
- Claude via Bedrock: Claude corriendo en infraestructura AWS, buena para clientes ya en AWS.
- Self-hosted open-source: datos nunca salen de tu infraestructura. Es la única opción cuando el cliente literalmente no puede mandar nada afuera.
Esta dimensión puede descartar modelos enteros antes de evaluar calidad. Si el cliente no puede mandar datos a US, Gemini sale de la mesa. Si no puede mandarlos a Anthropic, Claude vía API directa sale. El trabajo es conocer las restricciones antes de prototipar.
Quick matrix
Simplificación útil para empezar la conversación:
| Tipo de caso | Primera opción | Justificación | |---|---|---| | Extracción estructurada alta volumen | GPT-4o-mini o Claude Haiku | Costo bajo, calidad suficiente | | Clasificación de tickets o intent | GPT-4o-mini con structured output | Rápido, barato, predecible | | Chatbot con latencia crítica | Llama 3.3 70B en Groq | Sub-200ms primera palabra | | Razonamiento complejo sobre documentos | Claude Sonnet 4.6 | Mejor con contextos largos | | Generación creativa de contenido | GPT-4o o Claude Opus | Los frontier sí importan acá | | Sensibilidad de datos extrema | Llama self-hosted en tu infra | Único camino |
La tabla es punto de partida, no regla. Cada caso real tiene matices que pueden mover la decisión.
Casos donde frontier es overkill
Algunas señales de que estás pagando de más:
El output siempre encaja en un schema fijo. Si tu tarea siempre devuelve el mismo JSON con los mismos 5 campos, no necesitás un modelo que pueda resolver problemas de olimpíada. Necesitás un modelo que siga instrucciones y llene campos.
Los usuarios no notarían si bajás un escalón. Si podés hacer una prueba ciega entre GPT-4o y GPT-4o-mini con 50 casos reales y el equipo no distingue, estás tirando plata.
El error tiene costo bajo y es detectable. Si cuando el modelo se equivoca el error es obvio y se corrige con revisión humana barata, un modelo más barato con más error total puede ser económicamente mejor.
Casos donde open-source se rompe
Al revés, hay lugares donde los modelos open-source todavía no son la elección correcta:
Instrucciones complejas en múltiples idiomas mezclados. Los modelos open-source más chicos pueden alucinar cuando el system prompt es largo y mezcla idiomas (pasa mucho en contextos LATAM con términos técnicos en inglés).
Function calling / tool use. Los modelos cerrados son notablemente mejores en estructurar llamadas a herramientas. Los open-source están mejorando rápido pero todavía requieren más tuning.
Edge cases en prompts largos. Con contextos de más de 30k tokens, los open-source empiezan a perder información del medio del prompt. Los modelos frontier son más robustos acá.
Cómo cambiar de modelo si descubrís que elegiste mal
La buena noticia: si diseñaste bien, cambiar de modelo es barato. La clave es no hardcodear el cliente del modelo en todas partes. Abstraé la llamada detrás de una interfaz propia que reciba mensajes y devuelva estructuras. Cuando querés probar otro modelo, reemplazás una implementación y no tocás el resto.
Lo que sí hace falta repetir cada vez que cambiás de modelo es el testing. Tené un set de 30 a 50 casos reales con outputs esperados y comparalos antes de aprobar el cambio. Sin eso, estás adivinando.
Criterio final
Nuestro default en 2026 para un proyecto nuevo:
- Arrancamos con un modelo mid (GPT-4o-mini o Claude Sonnet). Es el equilibrio costo/calidad para el 80% de los casos reales.
- Si la calidad no alcanza, subimos a frontier y medimos la diferencia antes de quedarnos.
- Si el costo duele a volumen proyectado, evaluamos open-source en Groq para ese workflow específico.
- Self-hosting solo cuando las restricciones de datos lo exigen.
La regla general: gastá caro donde importa, barato donde no. Pero primero necesitás saber dónde importa, y eso se mide contra casos reales de tu negocio, no contra benchmarks públicos.