Mistral Large 4 en preview: evaluaciones, plan de contingencia, API o autoalojamiento

Una preview es una prueba de confianza, no una decisión de lanzamiento

Cuando llega una preview de un modelo, la tentación es tratar la lista de especificaciones como una decisión de producto. El número de parámetros recibe un protagonismo desmedido, la puntuación del benchmark se convierte en titular, y el equipo se pregunta si adoptarlo ahora o esperar al autoalojamiento. Ese orden está invertido. Los usuarios no confían en un modelo porque sea grande; confían porque el producto sabe qué hacer cuando falla.

Mistral abrió Mistral Large 4 como una API de preview pública el 6 de octubre de 2026 y anunció que los pesos abiertos llegarían a finales de octubre. La preview es un modelo granular de mezcla de expertos con 1,05 billones de parámetros totales, 49 mil millones de parámetros activos, un codificador de visión de 1,6 mil millones de parámetros y una ventana de contexto de 1M tokens. Esos números son impresionantes, pero no le dicen a un diseñador si la respuesta será segura, rápida o recuperable en su producto.

La ventana de preview es un presupuesto con fecha límite. El precio estándar de la preview era de $1,36 por 1M tokens de entrada, $0,14 por 1M tokens de entrada en caché y $4,18 por 1M tokens de salida. Durante las dos primeras semanas, los precios por token de Large 4 Preview se redujeron un 50 % hasta $0,68 y $2,09, y el coste de la tarea del Intelligence Index de Artificial Analysis bajó a $0,57. Usa ese presupuesto para responder a la pregunta que los usuarios realmente sienten: ¿qué pasa cuando el modelo se equivoca?

Ejecuta la evaluación que se ajusta a tu producto, no al ranking

Los benchmarks pueden orientarte, pero no pueden sustituir tus propios casos de fallo. Artificial Analysis, un rastreador de puntuaciones de modelos, otorgó a la preview una puntuación de 38 en el Intelligence Index, la misma que GPT-6 Luna max. Su puntuación en el Cyber Index fue de 50, la misma que GLM-5.3-Flash. Una evaluación privada de Artificial Analysis en DeepSWE v1.1, un benchmark de programación, situó a la preview en un 61,7 %. Esas puntuaciones son útiles para triaje, no para lanzamiento. Si tu producto es una bandeja de soporte, un agente de programación o un formulario multilingüe, el ranking puede pasar por alto exactamente cómo se verán perjudicados tus usuarios.

Haz que la preview pague su propia evidencia. Pon tus prompts reales, tus casos límite y tus fallos de seguridad en un pequeño conjunto de evaluación. Compara la puntuación de la preview con la del modelo que ya tienes en producción. Mantén los fallos visibles. Una preview que no puede sobrevivir al peor día de tu producto no está lista para tus usuarios, aunque gane un benchmark público.

La cobertura lingüística puede importar, pero solo si tus usuarios la necesitan. Los datos de entrenamiento eran multilingües, cubriendo más de 160 idiomas y todos los idiomas oficiales de la Unión Europea. Si tu producto atiende a esos usuarios, pruébalos. Si no, no dejes que una amplia afirmación lingüística sustituya a una prueba de producto concreta.

Diseña el plan de contingencia antes de elegir el modelo de alojamiento

La preview solo por API impone una restricción útil. Durante el período de preview, Large 4 solo podía accederse a través de la API de Mistral, y el modelo se trataba como propietario hasta que sus pesos se hicieran públicos. Esa restricción es buena para el diseño. Evita que el equipo pretenda que el autoalojamiento ya está disponible e impulsa al producto a definir qué ven los usuarios cuando el modelo no está disponible, es lento o no es seguro.

Un plan de contingencia fiable es un camino, no una disculpa. Para una respuesta con baja confianza, muestra al usuario una opción más estrecha: pedir más detalle, derivar a un humano o usar un modelo más pequeño para una tarea más segura. Cuando la API está caída, el producto debe permitir al usuario completar la tarea principal. Cuando la respuesta no es segura, el producto debe detenerse, explicar el límite y ofrecer un siguiente paso.

Una vez que los pesos sean descargables, los equipos de seguridad podrían alojar Large 4 en una nube privada o en las instalaciones bajo sus propias políticas. Es una opción real, pero no es lo mismo que una decisión de producto. Los detalles de arquitectura y la información de posentrenamiento necesarios para la planificación de despliegue interno aún no se habían proporcionado. Sin esos detalles, un plan de autoalojamiento sigue siendo un deseo. Decide en función de la licencia, el coste y la propiedad, no de la promesa de pesos.

Cuando los pesos se hagan públicos, los usuarios podrán descargar y ejecutar el modelo sin costes de API ni restricciones de acceso. Eso cambia el modelo de costes, no los requisitos de confianza: un modelo autoalojado aún puede equivocarse, ser lento o no ser seguro.

Tres comprobaciones convierten la preview en una decisión de confianza

Las comprobaciones son pequeñas porque la decisión depende del comportamiento del producto, no del tamaño del modelo. Ponen a prueba si el producto puede responder por el modelo cuando se equivoca, no está disponible o no es asequible.

• Ejecuta una evaluación de producto de dos semanas a precios de preview: define un pequeño conjunto de prompts reales, una rúbrica de aprobado/reprobado y una hoja de puntuación de la preview frente a tu modelo actual.
• Diseña la experiencia de usuario solo por API y el plan de contingencia para una respuesta de preview fallida, lenta o no segura, incluyendo la siguiente acción.
• Condiciona el autoalojamiento a una licencia, una estimación de costes de hardware y un responsable, no a los pesos.