Elegir un modelo LLM: criterios, precios y benchmarks

Para elegir un modelo de lenguaje, seleccione el que alcance la calidad que necesita en sus tareas reales y respete sus límites de costo, tiempo y tratamiento de datos. Los benchmarks sirven para identificar candidatos; una prueba representativa permite decidir entre ellos. Compruebe el tamaño del contexto y la licencia de la versión exacta del modelo y de la modalidad de despliegue que vaya a utilizar.

Definir el trabajo antes de comparar modelos

Empiece por describir el resultado esperado sin mencionar ningún proveedor. Extraer referencias de facturas, redactar una respuesta comercial y corregir un programa requieren capacidades distintas. Una redacción fluida no demuestra por sí sola que el modelo sea fiel a los documentos ni que pueda ejecutar una acción de forma fiable.

Especifique qué recibirá el modelo: texto en francés, documentos escaneados, tablas, imágenes, historial de conversación o resultados de herramientas. Describa también la salida: un párrafo de texto libre, datos estructurados, un archivo modificado o una propuesta pendiente de validación. Esta distinción evita comparar modelos a partir de una demostración que tiene poco que ver con el trabajo previsto.

A continuación, deje por escrito las condiciones de aceptación. Un resumen debe conservar determinadas salvedades; una extracción debe dejar vacío un valor ausente; una corrección debe superar las pruebas sin eliminar ninguna funcionalidad. Defina también cuándo el sistema debe pedir una aclaración o derivar el caso a una persona.

Las fichas de modelos de lenguaje permiten preparar una primera selección. Mantenga, sin embargo, una distinción entre las características anunciadas y el rendimiento observado en su aplicación. Aunque una función figure en la documentación, debe comprobar cómo se comporta con sus archivos y sus restricciones.

Convertir su uso en criterios observables

Divida los criterios entre requisitos obligatorios y preferencias. Si un candidato es incompatible con sus documentos o con su política de datos, debe descartarlo, aunque responda bien en otros contextos. El estilo de redacción puede ayudar después a elegir entre los modelos que cumplen los requisitos.

Uso	Calidad que debe medir	Restricción operativa	Fallo que debe buscar
Redacción y traducción	Respeto del sentido, tono y terminología	Tiempo de revisión	Incorporación de una afirmación ausente
Extracción documental	Exactitud de los campos y gestión de datos ausentes	Formato utilizable	Valor inventado pero plausible
Búsqueda en documentos	Respuesta respaldada por los pasajes pertinentes	Acceso a las fuentes adecuadas	Cita que no demuestra lo afirmado
Desarrollo de software	Corrección funcional y conservación del comportamiento	Integración con las pruebas	Cambio que oculta un defecto
Agente con herramientas	Elección de la acción y argumentos correctos	Permisos, duración y presupuesto	Acción innecesaria o no autorizada

Para cada fila que corresponda a su uso, defina qué evidencia demostrará que la tarea se ha resuelto correctamente. Una valoración como «respuesta satisfactoria» depende demasiado de la impresión de quien la lee. Prefiera criterios verificables: referencias conservadas, campos exactos, ausencia de añadidos, pruebas superadas o decisión aplazada cuando corresponde.

Evalúe también las negativas y las solicitudes de aclaración. Un sistema que siempre responde puede parecer útil y, al mismo tiempo, cometer errores que pasan inadvertidos. En el extremo opuesto, un exceso de negativas puede volver inutilizable una herramienta para tareas que sí están autorizadas.

Interpretar los benchmarks según lo que evalúan

Un benchmark mide el rendimiento bajo un protocolo concreto. Antes de fijarse en la puntuación, identifique la tarea, el idioma, los datos y las condiciones de ejecución. Un buen resultado en resolución de problemas no demuestra que el modelo traduzca bien un texto especializado o extraiga correctamente una tabla.

La metodología HELM de Stanford propone evaluar varios escenarios y dimensiones, entre ellas la robustez y la eficiencia. También recuerda que toda evaluación sigue siendo incompleta. Para elegir, busque mediciones que aclaren lo que necesita, en lugar de basarse en una única posición en una clasificación general.

En programación, la clasificación oficial de SWE-bench distingue varios conjuntos de pruebas y condiciones de evaluación. Compruebe, en particular, si está comparando el modelo por sí solo o un sistema que incluye herramientas, instrucciones y un entorno de ejecución. Un cambio en ese conjunto puede alterar lo que permite concluir el resultado.

Nuestro artículo Entender las clasificaciones de modelos explica cómo interpretarlas; el comparador de benchmarks ayuda a examinar las mediciones disponibles.

Antes de utilizar un resultado como referencia, compruebe:

el identificador exacto del modelo evaluado;
las herramientas y los documentos a los que tenía acceso;
la configuración del razonamiento y el presupuesto de ejecución;
la posibilidad de repetir intentos o seleccionar respuestas;
la similitud entre las tareas de la prueba y su uso previsto.

Una diferencia de posición en la clasificación no basta para justificar una migración. Debe corresponder a una mejora observable, reproducible y útil para su aplicación.

Preparar una prueba que permita detectar errores

Prepare un conjunto de casos representativos antes de ajustar las instrucciones. Incluya solicitudes habituales, entradas mal formadas, información incompleta y situaciones en las que todavía no conviene responder. Utilice datos que esté autorizado a tratar y elimine la información sensible que no sea necesaria.

Separe los ejemplos que utiliza para mejorar las instrucciones de los que reserva para la comparación final. De lo contrario, podría terminar eligiendo el modelo que mejor se adapta a los ejemplos ya trabajados. Conserve también casos difíciles basados en los errores descubiertos durante la prueba piloto.

Evalúe primero a los candidatos en condiciones comparables y permita después una adaptación documentada de las instrucciones para cada uno. Una instrucción común facilita la comparación inicial; una instrucción mejor ajustada muestra lo que puede ofrecer cada solución en la práctica. Guarde ambos resultados.

Siempre que sea posible, oculte el nombre del modelo a las personas que revisan las respuestas. Evalúe por separado la exactitud, la integridad y la presentación: una respuesta bien escrita puede disimular una omisión. Para los datos estructurados y el código, añada comprobaciones automáticas centradas en el resultado esperado.

La guía Evaluar un agente de IA desarrolla este método para los casos en que se encadenan varias llamadas y acciones. En ese contexto, registre también en qué paso aparece el primer fallo: la respuesta final rara vez permite explicar por sí sola qué ha salido mal.

Distinguir entre el contexto anunciado y el contexto útil

La ventana de contexto indica la capacidad para procesar el contexto proporcionado en una solicitud, según las reglas de cómputo del servicio. Compruebe por separado los límites de entrada, los de salida y los posibles límites compartidos. Una capacidad anunciada amplia no garantiza que el modelo pueda generar una respuesta larga.

El token es la unidad en la que el modelo divide el contenido; no equivale a una palabra. Un mismo documento puede dar lugar a un número de tokens distinto según el modelo. Para sus estimaciones, utilice el contador correspondiente al servicio elegido en vez de aplicar una conversión fija a partir del número de páginas o caracteres.

La documentación de Google sobre contexto largo distingue, entre otros casos, la búsqueda de un dato aislado de las solicitudes que requieren combinar varias informaciones. También señala que el rendimiento varía según el contenido. Por tanto, localizar correctamente un dato no demuestra que el modelo pueda elaborar una síntesis completa de los documentos.

Pruebe sus documentos con su extensión real. Sitúe la información necesaria en distintas partes, añada versiones contradictorias y pida una respuesta que relacione varios pasajes. Compruebe cómo se tratan las salvedades y las excepciones, que suelen ser decisivas para que el resultado sea útil.

Por último, compare el envío del documento completo con una selección de pasajes pertinentes. La primera opción puede simplificar el procesamiento; la segunda puede reducir el volumen transmitido. Mida también los errores de selección: el modelo no puede aprovechar un pasaje que su aplicación no le ha proporcionado.

Calcular el costo de una tarea aceptada

La tarifa por millón de tokens es una base de cálculo, no el costo final. Sume las entradas, las salidas, los posibles tokens de razonamiento facturados, las herramientas de pago y los nuevos intentos. Añada después el tiempo necesario para validar o corregir el resultado.

Como referencia fechada, Claude Sonnet 5.5 figura con un precio de 2 dólares de entrada y 10 dólares de salida por millón de tokens en el registro de precios del sitio de octubre de 2026. La tabla oficial de precios de Anthropic consultada el 24 de octubre de 2026 presenta esas mismas tarifas base. Estas no abarcan todas las opciones de facturación.

La tabla también distingue varias tarifas para Claude Haiku 5.5 según la longitud del prompt. Este ejemplo muestra por qué hay que leer un precio de partida junto con sus condiciones: el tramo de contexto, la caché, el procesamiento por lotes y los cargos adicionales pueden cambiar el cálculo.

Para comparar los candidatos, utilice esta relación:

Costo por tarea aceptada = costo total del lote, incluidas las correcciones, dividido entre el número de tareas aceptadas.

No presente este resultado sin indicar la tasa de éxito. De lo contrario, un modelo que abandona los casos difíciles podría parecer económico. Incluya también el consumo de los intentos fallidos y el tiempo que dedica una persona a retomar el trabajo.

La calculadora de precios de LLM ayuda a explorar presupuestos. Introduzca los volúmenes observados durante la prueba piloto y contemple después distintos niveles de actividad. Un historial que crece o unas respuestas más detalladas pueden hacer que la previsión inicial resulte demasiado optimista.

Medir la rapidez del servicio completo

Distinga entre el tiempo que tarda en aparecer el primer contenido y el que hace falta para obtener un resultado utilizable. Una respuesta que empieza enseguida, pero requiere una corrección prolongada, puede ser menos útil que otra más lenta que se puede aceptar de inmediato.

En un formulario, mida el tiempo que transcurre hasta obtener datos validados. En un agente, mida la tarea completa: planificación, llamadas a herramientas, esperas, comprobaciones y nuevos intentos. La velocidad de generación del texto solo representa una parte del proceso.

Observe también las solicitudes lentas, los errores temporales y los límites de capacidad. Un promedio puede ocultar esperas que perjudican a los usuarios. Realice las pruebas en la región y con el nivel de solicitudes simultáneas previstos, no solo desde un equipo de desarrollo.

Algunos ajustes permiten equilibrar calidad, costo y tiempo dentro de un mismo modelo. La documentación de Anthropic sobre la elección de un modelo recomienda evaluar también el esfuerzo de razonamiento. Compare, por tanto, configuraciones completas y documentadas, no solo nombres comerciales.

Defina, por último, cómo debe comportarse el sistema cuando el servicio no esté disponible. Esperar, reanudar el trabajo más tarde y pasar a otro modelo tienen consecuencias distintas. Pruebe la alternativa prevista antes de considerarla una garantía de continuidad.

Comprobar los formatos, las herramientas y las modalidades

La mención «salida estructurada» debe examinarse según las funciones que admite realmente el servicio. Compruebe los tipos de campos, las restricciones aceptadas, los valores ausentes y el tratamiento de las negativas. La aplicación debe poder detectar una respuesta que no se pueda utilizar.

La documentación de Google sobre salidas estructuradas describe una generación guiada por un esquema. Este mecanismo controla la forma, pero no demuestra que los valores se correspondan con el documento. Valide por separado la estructura y la exactitud de los datos.

En el caso de las herramientas, prepare situaciones en las que lo correcto sea no llamar a ninguna. Compruebe la elección de la función, sus argumentos y la reacción ante un error. Pruebe, en particular, los casos de identidad ambigua o falta de autorización antes de cualquier acción que tenga efectos fuera del sistema.

Para imágenes y documentos escaneados, utilice sus archivos reales: páginas inclinadas, tablas complejas, anotaciones pequeñas y escaneos deteriorados. Identifique las transformaciones que se realizan antes de la llamada. Un fallo en la conversión del documento puede explicar un error que se atribuya demasiado pronto al modelo.

La compatibilidad técnica sigue siendo un requisito previo. La aplicación debe imponer los permisos, las validaciones y los límites de actuación. Un buen rendimiento en las pruebas no sustituye esos controles.

Examinar la licencia y el entorno de ejecución

Los pesos abiertos permiten acceder a los parámetros distribuidos del modelo, de acuerdo con sus condiciones. No bastan para afirmar que todo el sistema sea de código abierto. La definición de IA de código abierto de la OSI también incluye requisitos relativos al código y a la información sobre los datos.

Para cada candidato que pueda desplegar, lea la licencia de la versión exacta. Compruebe los usos comerciales, la redistribución, las modificaciones y las obligaciones de atribución que se aplican a su proyecto. Conserve la licencia junto con los archivos desplegados y consulte las ambigüedades con una persona competente.

Punto de comparación	API alojada	Despliegue bajo su control
Operación	El proveedor se encarga de la infraestructura	Debe organizar la capacidad y el mantenimiento
Datos	Debe examinar los flujos y las condiciones del servicio	Debe comprobar los flujos locales y los servicios auxiliares
Evolución	Depende del ciclo de disponibilidad del proveedor	Puede conservar la versión según sus condiciones
Presupuesto	Consumo y opciones contractuales	Hardware, alojamiento y operación
Responsabilidades	Debe aclarar el contrato y el reparto de responsabilidades	Debe encargarse de la seguridad y el seguimiento

La ejecución local no garantiza por sí sola la confidencialidad. Examine la telemetría, los registros, las copias de seguridad y las herramientas conectadas. Si utiliza una API, compruebe las condiciones de conservación, el posible uso de los datos y los compromisos contractuales correspondientes al plan contratado.

La guía Ejecutar un LLM en local detalla los requisitos de hardware. Una versión cuantizada debe evaluarse con su configuración real: el resultado obtenido con otra variante no es suficiente.

Decidir, documentar y volver a evaluar

Descarte primero los candidatos que incumplen algún requisito obligatorio. Compare después las soluciones restantes según la calidad, el costo por tarea aceptada, el tiempo y la carga operativa. Evite una puntuación global que permita compensar un error crítico con un precio bajo.

Un solo modelo puede ser suficiente. Si contempla distribuir las tareas entre varios modelos, defina condiciones observables: formato inválido, comprobación fallida o categoría de tarea identificada. La confianza que declara el propio modelo no constituye, por sí sola, una regla fiable para pasar a otro.

Conserve una ficha de decisión con el identificador del modelo, el proveedor, la configuración, las instrucciones, el conjunto de evaluación y los límites observados. Anote las razones de la elección y las circunstancias que justificarían revisarla. Este registro facilita las migraciones y las conversaciones sobre el presupuesto.

Repita la evaluación cuando cambien el modelo, el contrato, los documentos o las herramientas. Una prueba piloto satisfactoria permite pasar a un uso supervisado; no demuestra una fiabilidad permanente. Mantenga una forma de volver a una configuración conocida cuando las condiciones lo permitan.

Puntos clave

Defina sus tareas, los errores críticos y las condiciones de aceptación antes de seleccionar modelos.
Utilice los benchmarks para orientar las pruebas y compare después los resultados con sus propios datos.
Mida conjuntamente la calidad, el costo por tarea aceptada y el tiempo total.
Compruebe el contexto útil, la licencia y las condiciones de tratamiento de datos para la configuración exacta.
Documente la elección y repita la evaluación cuando cambien el sistema o su uso.

Páginas relacionadas

Preguntas frecuentes

¿Cuál es el mejor modelo de lenguaje para trabajar en francés?

Una clasificación general no basta para responder. Compare los candidatos con sus documentos en francés e incluya abreviaturas, expresiones propias de su sector y requisitos de tono. Evalúe por separado la fidelidad a la información y la calidad de la redacción.

¿La suscripción a un asistente incluye las llamadas a la API?

No lo dé por hecho: la suscripción a una aplicación y el consumo de la API corresponden a ofertas distintas. Compruebe qué derechos de uso y créditos incluye expresamente su contrato. Para comparar presupuestos, separe las licencias de los usuarios de las llamadas que realiza su software.

¿Conviene elegir el modelo con más parámetros?

El número de parámetros no mide directamente la utilidad del modelo para su tarea. Los datos, el entrenamiento, la configuración y las herramientas disponibles también influyen en el resultado. Si lo ejecuta en un entorno local, el tamaño también afecta a los requisitos de hardware.

¿Se puede cambiar de modelo sin modificar la aplicación?

Una interfaz común puede facilitar el cambio, pero no garantiza un comportamiento idéntico. Los esquemas admitidos, los límites de salida y las llamadas a herramientas pueden variar. Prevea una validación funcional antes de cada migración.

¿Un modelo puede conocer la información publicada hoy?

La generación de texto por sí sola no garantiza el acceso a publicaciones recientes. Para obtener una respuesta actualizada, prevea una búsqueda o una fuente documental que se mantenga al día. Compruebe después que las referencias citadas respalden las afirmaciones.

Elegir un modelo de lenguaje para su uso: criterios, benchmarks, precios, contexto y licencia