El ecosistema de LLMs evoluciona a una velocidad vertiginosa: los modelos concretos que hoy lideran los rankings pueden estar superados dentro de unos meses. Por eso esta lección no pretende darte "el mejor modelo" (cualquier ranking que memorizaras caducaría enseguida), sino algo mucho más duradero: un marco de criterios para evaluar y comparar modelos, un mapa de los principales proveedores y familias, y una metodología de decisión que podrás aplicar hoy y dentro de dos años. Al final la aplicaremos al caso que nos ocupa: elegir el enfoque de modelo para DocuBot, el asistente de documentación de Nubelia.

1. Los cinco criterios para comparar modelos
2. Panorama de proveedores y familias de modelos
3. Modelos propietarios vía API vs. modelos abiertos autoalojados
4. Familias y tamaños: no hay "un" modelo por proveedor
5. Cómo elegir: metodología aplicada a DocuBot

Cuando evalúes cualquier modelo — actual o futuro — estas son las cinco dimensiones que debes mirar. Interiorízalas: las fichas técnicas de los proveedores se leen solas cuando sabes qué buscar.

¿Cómo de bien resuelve el modelo las tareas que te importan? Ojo al matiz: las tareas que te importan, no "en general". Un modelo puede ser brillante razonando sobre código y mediocre redactando en español, o viceversa.

• Los proveedores publican resultados en benchmarks estándar (exámenes de conocimiento, programación, razonamiento). Son útiles como primer filtro, pero saturan (muchos modelos rozan el máximo) y no reflejan tu caso concreto.
• La única evaluación fiable es probar el modelo con tus propios casos: en el caso de Nubelia, con preguntas reales de soporte y fragmentos reales de su documentación. En la lección 02-04 y en el módulo 6 veremos cómo sistematizar esta evaluación.

Cuánto texto (en tokens, como vimos en 01-02) puede manejar el modelo en una sola llamada, sumando entrada y salida. Determina cuánta documentación, historial de conversación o instrucciones puedes incluir. Las ventanas actuales van desde decenas de miles hasta millones de tokens según el modelo — pero cuidado: una ventana enorme no es gratis (más tokens = más coste y latencia) ni garantiza que el modelo use bien todo lo que le pases (lo matizaremos en 01-04).

Los modelos vía API se facturan por token, con precios distintos para tokens de entrada y de salida (la salida suele ser varias veces más cara). Los precios concretos cambian a menudo; lo que no cambia es la estructura:

Entre el modelo más capaz y el más económico de un mismo proveedor puede haber uno o dos órdenes de magnitud de diferencia de precio. Por eso la pregunta correcta nunca es "¿qué modelo es mejor?" sino "¿cuál es el modelo más barato que resuelve mi tarea con la calidad que necesito?". (La gestión operativa de costes — caching, optimización — se trata en detalle en la lección 03-04.)

Cuánto tarda el modelo en responder. Conviene distinguir dos métricas:

• Tiempo hasta el primer token: cuánto espera el usuario antes de ver algo. Crítico en interfaces conversacionales (por eso existe el streaming, que veremos en 03-02).
• Velocidad de generación (tokens por segundo): cuánto tarda en completarse la respuesta.

Regla general: los modelos más grandes y capaces son más lentos y caros; los pequeños, más rápidos y baratos. Para un chat interactivo como DocuBot la latencia importa mucho; para un proceso nocturno que resume tickets, casi nada.

Más allá de texto: ¿acepta imágenes o PDFs como entrada (visión)? ¿Audio? ¿Soporta function calling (módulo 5) y salidas estructuradas (02-03)? ¿Ofrece modos de razonamiento extendido para problemas complejos? No todos los modelos ofrecen todo, y si tu caso necesita, por ejemplo, interpretar capturas de pantalla adjuntas a tickets, esto se convierte en criterio eliminatorio.

Veamos los actores principales del ecosistema. Descripción deliberadamente atemporal: retén quién es quién y qué caracteriza a cada uno, y consulta sus webs para los detalles del momento.

• Anthropic — familia Claude. Modelos propietarios accesibles vía API, con fuerte foco en fiabilidad, seguridad y capacidades de asistente para trabajo con código y documentos largos. La familia se organiza en escalones de capacidad/coste (tradicionalmente con nombres como Opus, Sonnet y Haiku, de mayor a menor).
• OpenAI — familia GPT (y derivados). El proveedor que popularizó los LLMs conversacionales. Modelos propietarios vía API, gama amplia que cubre desde modelos ligeros hasta modelos de razonamiento avanzado, y un ecosistema de herramientas muy extenso.
• Google (DeepMind) — familia Gemini. Modelos propietarios integrados en el ecosistema de Google Cloud, históricamente fuertes en multimodalidad (texto, imagen, audio, vídeo) y en ventanas de contexto muy grandes.
• Meta — familia Llama. El gran impulsor de los modelos de pesos abiertos: modelos que puedes descargar y ejecutar en tu propia infraestructura. Han creado un ecosistema enorme de variantes y afinados por parte de la comunidad.
• Mistral AI. Compañía europea (francesa) que combina modelos abiertos y modelos comerciales vía API. Relevante además por consideraciones de soberanía de datos europeas.
• Otros actores que conviene conocer: DeepSeek y Qwen (Alibaba) como familias abiertas muy competitivas de origen chino; Cohere, orientado a empresa; y los proveedores de plataforma — AWS Bedrock, Google Vertex AI, Azure AI Foundry — que no crean los modelos principales pero los ofrecen dentro de su nube, con la facturación, seguridad y cumplimiento normativo integrados en tu infraestructura existente.

Tres observaciones transversales más útiles que cualquier ranking:

1. Todos los grandes proveedores ofrecen una gama, no un modelo. Cada familia tiene escalones (grande/medio/pequeño) con el mismo estilo de API.
2. La frontera de calidad se mueve constantemente y converge. El líder de hoy es alcanzado en meses. Diseña tu aplicación para poder cambiar de modelo con facilidad (buena abstracción de la capa LLM, evaluaciones propias que re-ejecutar contra un modelo nuevo).
3. Las APIs son conceptualmente muy similares (mensajes con roles, parámetros como temperature, streaming, herramientas), de modo que lo que aprendas en este curso con un proveedor se transfiere casi directamente a los demás. Los detalles prácticos de integración los veremos en el módulo 3.

La decisión más estructural no es "qué proveedor" sino qué modelo de despliegue: ¿consumo un modelo propietario como servicio, o descargo un modelo abierto y lo ejecuto en mi infraestructura?

Matices importantes que la tabla no captura:

• "Abierto" casi siempre significa "de pesos abiertos" (puedes descargar y ejecutar el modelo), no que los datos de entrenamiento o el proceso sean públicos. Revisa siempre la licencia: algunas permiten uso comercial sin restricciones y otras imponen condiciones.
• Existe una vía intermedia muy popular: consumir modelos abiertos a través de un proveedor de inferencia que los sirve vía API. Obtienes precios a menudo bajos y cero infraestructura, a cambio de que los datos sí salen de tu perímetro. Y la vía de plataforma (Bedrock, Vertex, Azure) ofrece modelos propietarios dentro de tu marco de nube y cumplimiento.
• El coste del autoalojamiento se subestima sistemáticamente. No es solo la GPU: es la disponibilidad, las actualizaciones, la optimización de inferencia, la observabilidad y el personal que lo mantiene.

Regla práctica honesta: para la gran mayoría de equipos que empiezan, la API propietaria (o de plataforma) es el punto de partida correcto — iteras rápido, sin inversión, con la mejor calidad. El autoalojamiento se justifica con requisitos estrictos de residencia de datos, volúmenes muy altos y sostenidos, o necesidades de personalización profunda.

Merece sección propia porque es una decisión que tomarás constantemente: dentro del proveedor elegido, ¿qué escalón de la gama usas?

• Modelo grande (frontera): máxima capacidad de razonamiento y fiabilidad; más caro y lento. Para tareas complejas, ambiguas o donde el error es caro.
• Modelo medio: el caballo de batalla. Equilibrio calidad/coste/latencia adecuado para la mayoría de aplicaciones — chatbots, RAG, procesamiento de documentos.
• Modelo pequeño: muy rápido y barato. Para tareas simples y de gran volumen: clasificar, extraer campos, enrutar peticiones.

Y una idea de arquitectura que verás en sistemas maduros: no tienes que elegir uno solo. Un mismo producto puede combinar escalones según la subtarea:

Este patrón de enrutado por complejidad reduce coste y latencia sin sacrificar calidad donde importa. Lo retomaremos al hablar de costes (03-04).

Cerremos con una metodología de cinco pasos, aplicándola a la decisión que Nubelia debe tomar para DocuBot.

Paso 1 — Define los requisitos del caso de uso. Para DocuBot:

• Usuarios: ~200 empleados internos (desarrolladores y soporte). Volumen moderado: quizá unos cientos de preguntas al día.
• Tarea: responder preguntas en español (y quizá otros idiomas) basándose en documentación técnica que se le pasará como contexto.
• UX: chat interactivo → latencia percibida importa.
• Datos: la documentación interna es confidencial, pero no contiene datos personales de clientes → una API con garantías contractuales adecuadas (no entrenar con los datos, retención limitada) es aceptable para Nubelia; no hay requisito duro de autoalojamiento.
• El error es tolerable pero molesto: una respuesta incorrecta hace perder tiempo, no dinero directamente.

Paso 2 — Filtra por criterios eliminatorios. Necesita: buen manejo del español, ventana de contexto suficiente para varios fragmentos de documentación más el historial, y (de cara a los módulos 4 y 5) buen soporte de salidas estructuradas y function calling. No necesita: visión, audio, ventana gigante.

Paso 3 — Decide el modelo de despliegue. Equipo pequeño, sin experiencia en servir modelos, volumen moderado, sin requisito de residencia estricta → API gestionada. Revisar los términos de tratamiento de datos del proveedor es parte de la decisión, no un trámite posterior (profundizaremos en 06-02).

Paso 4 — Elige el escalón, no solo el proveedor. Hipótesis inicial razonable: modelo medio de un proveedor principal para la generación de respuestas. Es una hipótesis, no un compromiso: la arquitectura debe permitir cambiarlo.

Paso 5 — Valida con una evaluación propia y deja la puerta abierta. Antes de comprometerse, el equipo de Nubelia debería preparar 30–50 preguntas reales con sus respuestas correctas conocidas y probar 2–3 modelos candidatos con ellas. Ese conjunto de evaluación, además, se convierte en un activo permanente: cada vez que salga un modelo nuevo, se re-ejecuta y la decisión de migrar se toma con datos. (Cómo construir estas evaluaciones se ve en 02-04 y 06-03.)

• Elegir modelo por titulares o rankings genéricos. Los benchmarks públicos no miden tu tarea. Un modelo mediano puede superar a uno puntero en tu caso concreto (por idioma, dominio o formato). La evaluación propia es insustituible.
• Empezar por el modelo más grande "para ir sobre seguro". Empieza probando el escalón medio; sube solo si tu evaluación demuestra que lo necesitas. La diferencia de coste y latencia es grande, y muchas tareas no la justifican.
• Acoplarse a un proveedor sin capa de abstracción. Si las llamadas al LLM están esparcidas por todo el código con detalles específicos del proveedor, cambiar de modelo será un proyecto en vez de un cambio de configuración. Centraliza el acceso al LLM desde el primer día (lo haremos así en el módulo 3).
• Confundir "modelo abierto" con "gratis". Los pesos son gratuitos; las GPUs, la operación y el personal, no. Calcula el coste total antes de decidir autoalojar.
• Ignorar la licencia y los términos de datos. Tanto en modelos abiertos (restricciones de uso comercial) como en APIs (¿entrenan con tus datos?, ¿cuánto los retienen?, ¿dónde se procesan?). Para una empresa como Nubelia, esto es criterio de selección de primer orden.
• Consejo: mantén una pequeña ficha comparativa propia (los 5 criterios × tus 2–3 candidatos) y actualízala cuando evalúes modelos nuevos. Es barato y convierte cada re-evaluación en rutina en lugar de debate.

Para cada escenario, indica cuál de los cinco criterios (capacidad, contexto, coste, latencia, modalidades) sería el más determinante y por qué:

1. Un proceso nocturno que clasifica 500.000 correos al mes en 10 categorías.
2. Un asistente que analiza contratos extensos (cientos de páginas) y responde preguntas sobre ellos.
3. Autocompletado de texto en tiempo real mientras el usuario escribe.
4. Una herramienta interna que recibe capturas de pantalla de errores y describe el problema.

Una empresa financiera quiere un asistente interno que trabaje con documentos que, por política interna estricta, no pueden salir de su centro de datos bajo ninguna circunstancia. Tiene un equipo de plataforma con experiencia en Kubernetes y GPUs, y un volumen previsto alto y sostenido. Justifica qué modelo de despliegue recomendarías y menciona dos costes ocultos que deberían presupuestar.

En la reunión de decisión de DocuBot, un directivo de Nubelia propone: "Usemos el modelo más potente del mercado para todo; así seguro que funciona". Escribe una respuesta argumentada (5–8 líneas) usando la metodología de la lección: qué está mal en el planteamiento y qué propondrías en su lugar.

Solución 1:

1. Coste. Volumen enorme y tarea simple: la diferencia de precio por token multiplicada por 500.000 llamadas domina la decisión. Un modelo pequeño probablemente clasifica igual de bien; la capacidad extra sería dinero tirado.
2. Contexto. Cientos de páginas son muchos tokens: necesitas una ventana grande (o técnicas de troceado, como veremos en el módulo 4). Si el documento no cabe, el resto de criterios ni se aplica.
3. Latencia. El autocompletado debe aparecer en fracciones de segundo o estorba en lugar de ayudar. Apunta a modelos pequeños y rápidos.
4. Modalidades. Necesitas entrada de imagen (visión); cualquier modelo que no la soporte queda eliminado, por barato o capaz que sea.

Solución 2:

Recomendación: modelo abierto autoalojado. El requisito de que los datos no salgan del centro de datos es eliminatorio para las APIs externas (incluso con garantías contractuales, los datos saldrían del perímetro), y la empresa tiene justo el perfil que hace viable el autoalojamiento: equipo de plataforma experimentado y volumen alto y sostenido que amortiza la infraestructura. Dos costes ocultos a presupuestar (valen otros razonables): (a) la operación continua — actualizaciones de modelos, optimización de inferencia, alta disponibilidad, observabilidad — que requiere dedicación permanente de personal, no solo el despliegue inicial; (b) el coste de oportunidad de la calidad: los modelos abiertos pueden ir por detrás de la frontera, así que necesitarán evaluación propia continua y quizá fine-tuning para alcanzar la calidad objetivo.

Solución 3 (ejemplo de respuesta):

"Usar el modelo más potente para todo optimiza un solo criterio (capacidad) e ignora los otros cuatro. Pagaríamos el precio por token más alto y la mayor latencia del mercado para tareas donde un modelo medio da la misma calidad: la mayoría de preguntas a DocuBot son consultas directas sobre documentación que le pasaremos como contexto, no problemas de razonamiento profundo. Propongo lo contrario: definir 30–50 preguntas reales de nuestros equipos con sus respuestas correctas, evaluar con ellas un modelo medio y uno grande de 2–3 proveedores, y elegir el modelo más económico que alcance la calidad objetivo, dejando la arquitectura preparada para cambiar de modelo si la evaluación futura lo justifica. Así la decisión se basa en datos nuestros, no en rankings genéricos, y el conjunto de evaluación nos sirve para siempre."

En esta lección has adquirido lo que de verdad perdura en un ecosistema que cambia cada pocos meses: los cinco criterios de comparación (capacidad, contexto, coste, latencia, modalidades), el mapa de proveedores y familias (Anthropic/Claude, OpenAI/GPT, Google/Gemini, Meta/Llama y el ecosistema abierto, Mistral y otros, más las plataformas de nube), la disyuntiva API propietaria vs. autoalojamiento con sus matices, y una metodología de cinco pasos que hemos aplicado a DocuBot: Nubelia opta como hipótesis inicial por un modelo medio vía API gestionada, validado con una evaluación propia y con la arquitectura preparada para cambiar. La lección de fondo: aprende a evaluar, no memorices rankings.

Pero antes de construir nada, falta la otra cara de la moneda. Hemos hablado de lo que los modelos ofrecen; en la próxima lección, "Limitaciones y riesgos: alucinaciones, contexto y costes", veremos lo que puede salir mal: por qué DocuBot podría inventarse con total seguridad una funcionalidad de Nubelia que no existe, qué implica realmente la ventana de contexto, y qué otros riesgos — corte de conocimiento, no determinismo, sesgos, costes — debes tener en el radar desde el diseño. Es la lección que separa a quien integra LLMs con criterio de quien se lleva sorpresas en producción.