1. Distinga los pesos del 29 de octubre de la vista previa anterior
Mistral publicó los pesos mejorados de Large 4 el 29 de octubre, después de la vista previa pública del 6 de octubre. El anuncio describe más aprendizaje por refuerzo y cambios de razonamiento. Son etapas diferentes: disponer antes de una API de prueba no significa que aquel mismo conjunto de pesos ya pudiera descargarse. Registre la fecha de publicación, cuándo consultó la fuente y el artefacto exacto evaluado.
La ficha actual de la API sigue indicando Public Preview. Publicar pesos no convierte por sí solo todos los servicios alojados en servicios de disponibilidad general ni establece un compromiso de disponibilidad. Un alias cambiante, la fecha original de un modelo y una revisión descargada identifican cosas distintas. Un inventario útil conserva cada dato en lugar de utilizar una fecha como sustituto de todos.
La cuestión de ingeniería es qué permite operar el modelo y qué debe asumir la organización. A continuación separamos capacidades documentadas de nuestro diseño y criterios de prueba propuestos. No descargamos pesos, alquilamos aceleradores, llamamos a un modelo de pago ni medimos esta versión en producción. Los resultados del proveedor siguen siendo afirmaciones del proveedor, no nuestros resultados de aceptación.
Fuentes de esta sección: Mistral: publicación de los pesos mejorados de Large 4, 29 de octubre · Ficha de Mistral API y estado de vista previa
2. Lea la licencia antes de elegir cómo distribuir el producto
La versión utiliza Mistral Ecosystem Open-Weight License, una licencia MIT modificada. Concede amplios derechos de uso, modificación y distribución sujetos a condiciones. El texto exige conservar los avisos de derechos de autor y permiso. Llamarla simplemente MIT o código abierto sin restricciones elimina información necesaria para decidir cómo ofrecer un producto.
La condición distintiva afecta al licenciatario o sus afiliados que operen un negocio Model-as-a-Service. En esa situación exige una licencia comercial separada antes del uso comercial. La definición incluye acceso de terceros para inferencia o posentrenamiento con control significativo sobre entradas, parámetros o datos de entrenamiento. La descripción comercial de un producto no basta para resolver esa condición.
La definición excluye productos finales con capacidades del modelo integradas exclusivamente en funciones o entornos de orquestación concretos, y la mera retransmisión a modelos alojados por otros. Otra cláusula excluye de esa condición el uso interno sin poner el modelo a disposición de terceros y el acceso mediante productos oficiales de Mistral. Estas precisiones importan tanto como la restricción principal.
Para revisar un despliegue, conserve el archivo exacto de licencia y su revisión. Describa quién opera el modelo, quién accede y qué controla. Aclare con el titular los acuerdos dudosos antes de una publicación comercial. Estamos explicando los límites publicados, no determinando jurídicamente que una aplicación concreta cumpla una excepción.
Fuentes de esta sección: Texto de la licencia Mistral Ecosystem Open-Weight
3. Calcule la memoria con todos los pesos, no con los parámetros activos
Las fichas oficiales describen aproximadamente un billón de parámetros totales; la ficha de API especifica 1,05T. La de pesos distingue 49B activos por token de 52B si se incluyen las capas de embeddings y salida. Es un modelo de mezcla de expertos: el número activo describe una ruta de cálculo, no promete que el servicio solo necesite esa cantidad de parámetros en memoria.
Como estimación inicial transparente, multiplique los parámetros totales por los bytes ideales de cada peso. La tabla utiliza deliberadamente 1T redondeado, unidades decimales y ningún coste adicional. Es solo aritmética: no fija un mínimo de aceleradores, no demuestra que cualquier cuantización sea compatible ni estima el rendimiento de su equipo actual.
La capacidad real incluye escalas y metadatos de cuantización, componentes sin cuantizar, búferes, espacio de comunicación, replicación y estado de atención. La ficha oficial también enlaza un conjunto NVFP4 orientado a Blackwell. Es un artefacto y una ruta de hardware concretos, no prueba que toda conversión a cuatro bits conserve calidad o funcione en cualquier dispositivo. Evalúe el formato que realmente usará.
| Representación ideal | Aritmética con 1T redondeado | Qué excluye |
|---|---|---|
| 16 bits / 2 bytes | Unos 2 TB de pesos | Ejecución, caché KV, metadatos y replicación |
| 8 bits / 1 byte | Unos 1 TB de pesos | Los mismos requisitos adicionales |
| 4 bits / 0,5 bytes | Unos 0,5 TB de pesos | Empaquetado/escalas, capas no compatibles y sobrecarga de ejecución |
Fuentes de esta sección: Ficha oficial de pesos de Mistral: arquitectura, razonamiento y servicio · Ficha de Mistral API y estado de vista previa
4. Contexto de 1M y concurrencia son cuestiones de capacidad distintas
La ventana documentada de un millón de tokens es un límite del modelo, no una promesa de que cualquier configuración pueda atender esa longitud con concurrencia útil. Una solicitud corta y muchas largas exigen cosas distintas. La planificación debe fijar distribución real de entradas, presupuesto de salida, trabajos simultáneos y demora de cola aceptable.
Mida por separado preparación de instrucciones, prefill, latencia al primer token, generación y espera de herramientas. Quien espera una investigación de repositorio experimenta todo el recorrido. Una buena velocidad de generación medida después del prefill no describe cuánto tarda un documento grande en empezar a responder ni qué ocurre al llegar una segunda solicitud.
Las notas oficiales de servicio sugieren reducir contexto o concurrencia ante falta de memoria. Proponemos una matriz de entradas cortas, típicas y largas con carga creciente. Registre memoria, percentiles de latencia, errores y calidad. Defina rechazo o cola antes del agotamiento, en lugar de admitirlo todo y confiar en reintentos.
Recortar contexto también es una decisión de producto. Conserve instrucciones, evidencias relevantes y resultados anteriores necesarios; compare después la respuesta. Más contexto puede ampliar la cobertura, pero también aumenta el coste e introduce material irrelevante u hostil. Ni el máximo de longitud ni un acierto de caché garantizan que se utilice la evidencia correcta.
Fuentes de esta sección: Ficha oficial de pesos de Mistral: arquitectura, razonamiento y servicio
5. Una llamada a función propone una acción; no ejecuta la operación de negocio
Mistral documenta llamadas a funciones y salidas estructuradas. Sus ejemplos separan el analizador de llamadas a herramientas del de razonamiento. El primero debe conservar nombre, argumentos e identificadores; el segundo, mantener razonamiento y contenido visible en sus canales correctos. Aceptar una solicitud de forma familiar no demuestra que ninguno de los dos recorridos funcione.
Empiece con una herramienta inocua de solo lectura. Compruebe una llamada válida, fallos visibles de argumentos malformados, asociación del resultado con su llamada y continuación tras un error. Si permite llamadas paralelas o repetidas, pruébelas también. Controle el acceso a las trazas originales porque instrucciones y resultados pueden contener información confidencial.
La aplicación debe validar argumentos, resolver usuario y organización actuales, comprobar permisos, ejecutar y devolver un resultado explícito. Un identificador de cuenta generado no puede autorizar acceso entre organizaciones. Una frase de éxito no demuestra una escritura en base de datos, un pago ni un despliegue.
Antes de habilitar acciones irreversibles, defina aprobación y comprobante independiente. Nombres de herramientas y esquemas JSON son contratos de interfaz, no autorización. Son nuestros requisitos de integración, no prestaciones que atribuyamos automáticamente al modelo. Recuperación de lectura, vista previa y acción confirmada necesitan estados y registros separados.
Fuentes de esta sección: Ficha oficial de pesos de Mistral: arquitectura, razonamiento y servicio · Ficha de Mistral API y estado de vista previa
6. Fije los pesos y el nivel de razonamiento antes de comparar
El modelo mejorado documenta los niveles low, medium y high, este último predeterminado; low reemplaza al anterior none. No deduzca igual latencia, consumo o comportamiento de una etiqueta sin cambios. Registre explícitamente nivel, revisión de pesos, tokenizador, plantilla, motor de inferencia y analizadores.
Fije un conjunto de evaluación y reglas comunes antes de cambiar varias variables a la vez. Compare modificaciones rutinarias, solicitudes ambiguas, evidencias largas y errores de herramientas. Un intento satisfactorio más barato resulta útil, pero uno rápido con reparaciones repetidas puede gastar más recursos totales. La selección pertenece al flujo completo.
Conserve el artefacto anterior mientras prueba una actualización. Guarde la configuración de cada resultado para reproducir regresiones. Una mejora anunciada en un benchmark invita a investigar, no permite asumir que un idioma, repositorio o política interna mejoró en la misma proporción. No hemos reproducido los benchmarks del anuncio.
Fuentes de esta sección: Mistral: publicación de los pesos mejorados de Large 4, 29 de octubre · Ficha oficial de pesos de Mistral: arquitectura, razonamiento y servicio
7. Gemini API CLI distingue estado del cliente y almacenamiento del servidor
Google publicó el cliente beta gemini-api el 27 de octubre. Se dirige al shell, es distinto de Gemini CLI interactivo y puede utilizarse dentro de otro agente de programación. Documenta identificadores explícitos, trabajos en segundo plano, salida estructurada y archivos multimedia en disco. Son opciones de integración, no un entorno completo de agente de programación.
El CLI se llama sin estado porque sus comandos no conservan estado oculto del flujo local. Un identificador anterior, una URI de archivo subido o un identificador de trabajo explicitan la continuación. El llamante todavía debe persistirlos y decidir quién retoma el trabajo tras reiniciar. Imprimir una ruta evita llenar el contexto de binarios; no significa que el contenido nunca se enviara al servidor.
Google también cambió el almacenamiento predeterminado de Generate Content para nuevos proyectos de pago desde el 26 de octubre. Los anteriores conservan su configuración. El campo store por solicitud prevalece sobre el valor del proyecto; Interactions permite historial del servidor. Por tanto, cliente sin estado e interacción almacenada pueden coexistir. Revise la política vigente y el proyecto real, no un valor histórico.
La guía beta recomienda fijar versión porque cambios menores pueden romper compatibilidad. Soporta HTTP, SSE y sondeo, no WebSockets bidireccionales. Para tiempo real utilice la interfaz específica documentada. Aquí no ejecutamos comandos ni ejemplos de API: comparamos propiedad del estado y transporte, sin afirmar que todas las capacidades de Gemini acaben de publicarse.
Fuentes de esta sección: Google: notas de versión de Gemini API · Google: estado, tareas en segundo plano y límites de Gemini API CLI · Google: registros de Gemini API, almacenamiento y retención
8. Compare la inferencia propia con la capa gestionada que contrataría
La documentación actual de OpenAI Agents API describe un entorno de orquestación Codex gestionado: OpenAI administra sesiones, orquestación, compactación de contexto y recuperación; la aplicación aporta herramientas y elige entorno de ejecución. Comparamos el servicio documentado actualmente, sin afirmar que todas esas funciones se anunciaran el 29 de octubre.
Esta distribución difiere de servir pesos mediante un endpoint compatible. Tampoco equivale a ejecutar un SDK en su aplicación. Separe inferencia, bucle del agente, cómputo de ejecución e integración de negocio en la revisión arquitectónica. Alojar el entorno de ejecución no traslada automáticamente la orquestación gestionada ni todo su estado a sus servidores.
La guía de sesiones describe turnos asíncronos y advierte que una sesión inactiva no demuestra éxito; ni siquiera un turno completado garantiza todas las herramientas. Aplique la misma distinción al agente propio. Persista progreso e inspeccione resultados y artefactos antes de informar de finalización. Un evento de transporte ayuda, pero el producto necesita una regla de aceptación.
| Responsabilidad | Endpoint propio de modelo | Comparación gestionada |
|---|---|---|
| Inferencia y artefacto | Usted opera los pesos y el servicio elegidos. | El proveedor opera el servicio del modelo seleccionado. |
| Bucle y estado duradero | Los aporta su integración o marco elegido. | La orquestación documentada aporta una parte. |
| Herramientas y ejecución | Usted elige ejecutores y autoridad. | Funciones y entornos de la aplicación siguen importando. |
| Aceptación del negocio | Sus pruebas y comprobantes determinan el éxito. | Sus pruebas y comprobantes siguen determinando el éxito. |
Fuentes de esta sección: OpenAI: introducción a Agents API gestionada · OpenAI: sesiones, turnos asíncronos y recuperación
9. Separe la entrada de imágenes de un producto de voz completo
Large 4 admite texto e imágenes como entrada y texto como salida. Puede servir para gráficos, documentos y contexto visual de programación; multimodalidad nativa no significa que el conjunto de pesos aporte llamadas telefónicas, reconocimiento, síntesis e interrupciones. Confirme modalidades de entrada y salida sin extender una etiqueta comercial a un producto completo.
Mistral presentó Voxtral 3 el 20 de octubre como familia de audio y canalización de agentes de voz. El registro marca sus cuatro modelos como Public Preview. El anuncio describe reconocimiento, un modelo de razonamiento con herramientas y generación de voz dentro de un sistema en streaming. Es una actualización del intervalo ampliado y otra arquitectura, no audio añadido silenciosamente a los pesos de Large 4.
En voz, pruebe por separado fin de turno, interrupciones, errores de transcripción, espera de herramientas y confirmación hablada. Un número de cuenta mal transcrito puede generar una llamada perfectamente formada pero incorrecta. Evalúe consentimiento, retención de grabaciones y autoridad en cada sistema. Los ejemplos de latencia del proveedor no establecen su latencia integral ni su nivel contractual de servicio.
Fuentes de esta sección: Ficha oficial de pesos de Mistral: arquitectura, razonamiento y servicio · Mistral: anuncio de Voxtral 3 del 20 de octubre · Mistral: vista previa de Voxtral 3 y cambios de la API
10. Mida el coste por tarea aceptada y la frontera real de los datos
Mistral comunica mejoras de programación y menor consumo de tokens bajo tareas y condiciones concretas. Proponemos como denominador tareas aceptadas independientemente: sume modelo, reintentos, herramientas, cómputo, operaciones y revisión; divida después por los resultados que superen los controles acordados. Menos tokens de salida no demuestra menor coste total.
Mantenga tareas autorizadas y fijas con criterios explícitos: pruebas aprobadas, comportamiento solicitado, ausencia de cambios ajenos, evidencia que respalda las citas y ningún envío prohibido. Incluya casos sin resolver. Distinga errores de ejecución, rechazos, argumentos inválidos y resultados plausibles pero incorrectos. Una única tasa de fallo oculta lo que debe corregirse.
La soberanía de datos requiere límites concretos. Meta anunció apoyo a cinco universidades estadounidenses el 28 de octubre; los proyectos sanitarios descritos operan en entornos institucionales sin facilitar a Meta datos clínicos o de pacientes. Es un acuerdo de investigación acotado, no una API general nueva ni una promesa para cualquier uso de Muse. Ilustra la necesidad de precisar ubicación y alcance contractual.
Inventaríe instrucciones, documentos recuperados, respuestas de herramientas, trazas, temporales, copias y peticiones externas. Ejecutar pesos localmente no impide que una integración envíe evidencias a otro servicio. Un endpoint regional no resuelve toda retención o transferencia posterior. Revise cada componente real y no sustituya el diagrama de datos por una etiqueta de soberanía.
Fuentes de esta sección: Mistral: publicación de los pesos mejorados de Large 4, 29 de octubre · Meta: investigación universitaria y límites de datos, 28 de octubre · OpenAI: introducción a Agents API gestionada
11. Publique con aceptación gradual, registros duraderos y reversión
Empiece evaluando en aislamiento y solo lectura. Mantenga la ruta de producción hasta que el candidato satisfaga criterios escritos. La lista siguiente es nuestra propuesta, no un informe de pruebas ejecutadas. Comprueba deliberadamente la integración alrededor del modelo además de su texto.
Una solicitud interrumpida necesita conciliación. La aplicación debe saber si una herramienta fue propuesta, aprobada, iniciada, completada o fallida. Guarde identificador duradero y comprobante de las operaciones con efectos; consulte ese registro antes de repetir una acción incierta. Reintentar inferencia no equivale a reintentar una operación confirmada; deduplicar mensajes del proveedor no sustituye la idempotencia del negocio.
Amplíe tráfico solo tras comparar candidato y base sobre la misma aceptación y carga. Conserve evidencia redactada suficiente sin guardar secretos indefinidamente. Si hay regresiones, vuelva a la configuración conocida y concilie trabajos pendientes. Los pesos abiertos aportan otra opción de despliegue, útil cuando licencia, capacidad, ejecución y operación encajan con la tarea.
- Fije revisión de licencia, pesos, cuantización, tokenizador, motor y analizadores.
- Valide herramientas de lectura, salida estructurada, separación de razonamiento y errores explícitos.
- Mida entradas cortas y largas con concurrencia representativa, colas y falta de memoria.
- Pruebe reinicio, cancelación, respuestas perdidas y duplicados con casos inocuos.
- Verifique permisos por organización, aprobaciones, destinos externos, retención y comprobantes finales.
- Publique un canario pequeño con umbrales de parada; conserve artefacto y configuración anteriores y concilie trabajos antes de revertir o reintentar.
Fuentes de esta sección: Ficha oficial de pesos de Mistral: arquitectura, razonamiento y servicio · OpenAI: sesiones, turnos asíncronos y recuperación