El panorama de modelos de IA

Por qué la selección de modelo es una decisión arquitectónica

La selección de modelo es una de las decisiones de ingeniería con mayor retorno en sistemas de IA. Determina buena parte de lo que viene después: la estrategia de prompting, el enfoque de recuperación de información, el manejo de errores.

Este artículo ofrece un marco de decisión, no una tabla comparativa. Las tablas comparativas quedan obsoletas en cuestión de meses. Los marcos, no. Los precios de las APIs de LLM han caído con fuerza, y los modelos más nuevos y capaces suelen salir más baratos que los anteriores. Lo que ayer era caro, hoy puede ser barato. El mejor modelo del trimestre pasado puede ser el segundo mejor este trimestre.

El efecto cascada

La elección de modelo no es aislada. Se propaga por todo el sistema: estructura de costos, presupuesto de latencia, perfil de confiabilidad, postura de privacidad y techo de capacidad. Cambiar de modelo más adelante implica reevaluar todo eso.

El panorama avanza rápido

Reevalúa la selección de modelo cada trimestre, y cada vez que salga un modelo importante. Diseña tus sistemas para que cambiar de modelo sea fácil, no doloroso. Poder cambiar de modelo es en sí mismo una ventaja arquitectónica.

Las grandes familias de modelos en la nube

Un puñado de proveedores domina el panorama de modelos en la nube, cada uno con una identidad propia. Todos ofrecen ahora una estructura por niveles: modelos flagship para máxima capacidad, modelos balanceados para el trabajo de producción del día a día, y modelos económicos para tareas simples de alto volumen.

El patrón de tres niveles

Todo proveedor grande ofrece ahora modelos en al menos tres niveles de capacidad. La diferencia de precio entre niveles suele ser de 5-10x, pero en tareas simples el nivel económico a menudo rinde casi igual que el flagship.

Modelos open-weight (Llama / Qwen)

Los modelos open-weight pasaron de ser una solución de compromiso a una alternativa viable para muchas cargas de trabajo en producción. Según investigación de Epoch AI, la brecha de capacidad entre modelos abiertos y propietarios se redujo de años a unos tres meses. Para tareas estándar (clasificación, extracción, resumen, RAG básico), la brecha es casi nula.

APIs en la nube vs. inferencia local

Esta es una decisión de modelo de negocio tanto como técnica. Las APIs en la nube son OpEx (pagas por token, escalas al instante, cero infraestructura). La inferencia local es CapEx + OpEx (hardware + talento + mantenimiento continuo). La mayoría de los equipos debería empezar con APIs en la nube, y pasar a self-hosting solo cuando el volumen y los requisitos de cumplimiento lo justifiquen.

1. 1¿Los datos sensibles salen de tu entorno? Si no es aceptable, debes auto-hospedar.
2. 2Si es aceptable con un DPA, evalúa si el volumen es alto y sostenido o variable/bajo.
3. 3Volumen variable o bajo: usa APIs en la nube.
4. 4Volumen alto: calcula el TCO (costo de API vs. self-host) antes de decidir.
5. 5Si decides auto-hospedar, confirma que tienes ingenieros de infraestructura ML en el equipo; si no, contrata primero o usa endpoints de nube privada mientras tanto.

Modelos de razonamiento vs. modelos estándar

Los modelos de razonamiento son un enfoque de inferencia fundamentalmente distinto. Los modelos estándar generan la respuesta token por token en una sola pasada. Los modelos de razonamiento asignan cómputo adicional en el momento de inferencia, generando "tokens de pensamiento" internos antes de dar la respuesta final. Se entrenaron con aprendizaje por refuerzo para razonar de forma nativa.

Es un nivel de capacidad distinto, no simplemente "modelos mejores". Saber cuándo una tarea se beneficia de verdad del razonamiento extendido, y cuándo eso es tirar dinero y tiempo, es una habilidad arquitectónica clave.

Capacidades del modelo que definen la selección

La capacidad de un modelo no es unidimensional. Puede ser el mejor en razonamiento y mediocre siguiendo formatos de salida estructurados. Elegir bien significa cruzar capacidades específicas con requisitos específicos.

Benchmarks y cómo evaluar modelos

Los benchmarks son un punto de partida para comparar, no una decisión. La brecha entre el desempeño en benchmarks y el desempeño en tareas reales está bien documentada. Un modelo que lidera la tabla de MMLU puede fallar con tus documentos de cumplimiento específicos del dominio.

La selección de modelo como gestión de riesgo

Confiabilidad significa desempeño consistente ante una amplia variedad de entradas, incluyendo casos límite y prompts adversariales. No es lo mismo que la precisión en un set de prueba. Muchos modelos parecen confiables en pruebas controladas, pero muestran otros modos de falla al integrarse en flujos de trabajo reales.

Las alucinaciones son una propiedad fundamental de los sistemas de predicción probabilística. Pero la tasa y el tipo de alucinación varía bastante entre modelos. En aplicaciones críticas para la seguridad o de alto riesgo, elegir un modelo más capaz no es solo cuestión de mejores respuestas: es cuestión de menos fallas.

Arquitecturas multi-modelo y enrutamiento

Los sistemas en producción no usan un solo modelo: orquestan varios. El model routing, donde algo como una "torre de control" despacha cada solicitud al modelo más adecuado, ya es una práctica estándar. Convierte la selección de modelo de una decisión única en una optimización continua.

1. 1La solicitud entrante llega primero al modelo económico (Haiku, Flash).
2. 2Se hace un chequeo de confianza: si es alta (~65% de los casos), se devuelve la respuesta directamente.
3. 3Si la confianza es baja, escala al modelo balanceado (Sonnet, GPT-4o) y vuelve a chequear confianza.
4. 4Si esa confianza es alta (~25% de los casos adicionales), se devuelve la respuesta.
5. 5Si sigue siendo baja, escala al modelo flagship (Opus, GPT-5), que resuelve el resto.

El marco de decisión para seleccionar modelo

Esta es la idea central: no se trata de qué modelo elegir hoy, sino de cómo evaluar y seleccionar modelos para cualquier proyecto, en cualquier momento. El panorama cambia rápido, pero el marco se mantiene.

1. 1Define los requisitos de la tarea: profundidad de razonamiento, latencia, presupuesto, requisitos de cumplimiento.
2. 2Empieza con el modelo más capaz: establece líneas base de calidad y arma tu conjunto de evals.
3. 3Construye tus propios evals: prueba contra tus casos de uso reales, no solo benchmarks.
4. 4Optimiza hacia abajo: prueba modelos más chicos/baratos, agrega caching, simplifica prompts.
5. 5Enruta por complejidad: nivel económico para la mayoría, nivel fuerte para lo difícil, razonamiento para frontera.
6. 6Reevalúa cada trimestre: los precios bajan, aparecen modelos nuevos, la elección de ayer puede quedar obsoleta.

Cómo desplegar un modelo nuevo con seguridad

1. 1Revisa los benchmarks relevantes para tus tareas cuando sale un modelo nuevo.
2. 2Corre el modelo contra tu propio conjunto de evals.
3. 3Haz un shadow deploy (0% de tráfico real) para validar que funciona en tu pipeline.
4. 4Pasa a un canary rollout (5% del tráfico) y observa las métricas de calidad.
5. 5Si pasa los criterios de calidad, avanza a un rollout progresivo; si no, quédate con el modelo actual.

Conceptos erróneos comunes

• "Existe el mejor modelo": no existe. Existe el mejor modelo para una tarea, un presupuesto y un conjunto de restricciones específicos. Los sistemas en producción suelen usar 3 o más modelos, cada uno elegido para un rol distinto.
• "Los modelos open-source son gratis": los pesos son gratis, correrlos no. El costo total de propiedad suele ser 5-10x la línea de infraestructura. El capital humano es el gasto oculto más grande.
• "El que lidera los benchmarks gana en producción": la brecha entre benchmark y producción está bien documentada. Un modelo que lidera MMLU puede complicarse con tus documentos específicos de dominio.
• "Los modelos de razonamiento son simplemente mejores": son un tipo distinto, con otro perfil de costo/latencia. En tareas simples pueden rendir peor que los modelos estándar.
• "Elige un modelo y quédate con él": una arquitectura agnóstica de modelo con routing es el estándar en producción. Atarte a un solo modelo genera un vendor lock-in más difícil de resolver que el del SaaS tradicional.
• "Los modelos open-weight siempre son peores": para la mayoría de las tareas estándar en producción, la brecha de capacidad hoy es casi nula. Solo persiste en las tareas de razonamiento de frontera más difíciles.