Problema
Un lanzamiento de un modelo pequeño, una preview por API y una promesa de pesos abiertos pueden aparecer en la misma comparación de mercado. Cada anuncio responde, sin embargo, a una pregunta diferente. Mezclarlos produce rankings que ayudan poco a decidir qué se puede probar, contratar o desplegar.
La capacidad del modelo es una dimensión. El acceso efectivo y el coste de resolver una tarea son otras. Una organización puede encontrar un candidato atractivo y no disponer todavía del artefacto, la región o la infraestructura que necesita.
Tesis
Organiza la compra por capacidad, acceso y operación. En los anuncios de octubre consultados, Mistral Large 4 se presenta como preview por API con liberación de pesos prevista; el anuncio inicial de Reflection anticipaba artefactos de Beam; Anthropic orienta Haiku 5.5 a cargas de alto volumen y sensibles al coste. Son posiciones de producto, no resultados comparables de una prueba independiente.
La revisión del 29 de octubre de 2026 añade una diferencia material: el repositorio oficial de Beam ya muestra archivos de pesos y ficha de modelo. Mistral Large 4 mantiene una página de lanzamiento próximo para sus pesos. Comprobar un anuncio y comprobar un artefacto son pasos diferentes; el estado observado aquí no sustituye la validación del despliegue propio.
Framework
Capacidad: define el trabajo aceptable
Escoge tareas del dominio y especifica qué error obliga a rechazar la salida. Incluye casos que requieran abstenerse, consultar una fuente o escalar. Una respuesta rápida que resuelve el caso habitual puede fallar justo donde el coste empresarial es mayor.
No traslades la posición en un benchmark a una promesa sobre tu operación. El entorno, las herramientas y el criterio de aceptación pueden ser distintos. Conserva el modelo y la configuración exactos de cada prueba.
Acceso: verifica lo que existe
Distingue página de anuncio, endpoint disponible y artefacto descargable con licencia. Para autogestión, añade requisitos de ejecución y compatibilidad. Para API, revisa condiciones del servicio, límites y tratamiento de datos. Ninguna de esas comprobaciones se resuelve con la palabra «abierto».
Operación: cuenta también la corrección
Compara el coste del recorrido completo: ejecución, recuperación, reintentos y revisión. Si un modelo pequeño resuelve una parte del trabajo, define cuándo se escala y evita cobrar dos veces el mismo esfuerzo por una clasificación defectuosa.
El objetivo es asignar cada carga a una configuración que satisfaga sus requisitos. No hace falta elegir un ganador universal para disponer de una cartera coherente.
Matriz de evidencia: qué puedes evaluar con cada candidato
| Candidato | Evidencia observada en la revisión | Decisión todavía pendiente |
|---|---|---|
| Mistral Large 4 | Anuncio de preview por API y pesos marcados como próximos | Verificar el endpoint de la cuenta; no presupuestar autogestión como disponibilidad acreditada |
| Beam | Ficha de Reflection, licencia Apache y archivos de pesos publicados | Comprobar integridad, compatibilidad y capacidad del entorno antes de prometer servicio |
| Haiku 5.5 | Oferta documentada para tareas de volumen y coste sensible | Validar calidad, configuración y acceso del servicio para la carga concreta |
La inspección de archivos de Beam no es una prueba de ejecución: no se han descargado sus pesos ni medido rendimiento en este trabajo. Tampoco se asignan precios a configuraciones que no hemos probado.
Aplicación a una carga de soporte documental
Supuesto: quieres clasificar solicitudes, redactar respuestas desde documentos autorizados y derivar excepciones. Conserva el mismo conjunto de entrada y una rúbrica que penalice inventar condiciones, usar una versión retirada o responder cuando falta evidencia. Una clasificación correcta no compensa un envío con información falsa.
Para cada configuración guarda resultado aceptado, reintentos, revisión y consumo facturado. Define el coste por caso aceptado como el gasto total atribuible al ensayo dividido entre los casos aceptados. Incluye los intentos fallidos en el numerador; si no hay casos aceptados, informa de que la métrica no puede calcularse. En autogestión, incorpora además la capacidad reservada y el trabajo operativo que puedas medir, sin equiparar automáticamente ese coste a una tarifa por tokens.
La decisión puede ser asignar clasificación y redacción a configuraciones diferentes, pero solo si el relevo conserva documentos, restricciones y estado. Primero compara cada ruta completa; después decide si el ahorro justifica introducir otra dependencia. Una cartera útil explica qué tarea asigna a cada modelo y qué resultado obliga a escalar.
Por qué importa ahora
La ampliación de la oferta permite ajustar mejor capacidad y carga. También hace más fácil comprar por una combinación de promesas que ningún producto entrega todavía. Separar los ejes ayuda a evaluar novedades sin rediseñar toda la política con cada lanzamiento.
Anti-ejemplo
Caso hipotético: compras aprueba un modelo anunciado como abierto y operaciones planifica alojarlo internamente. Cuando llega la prueba, solo existe una preview por API. El presupuesto no contemplaba esa dependencia y la fecha de entrega se había basado en un artefacto no verificado.
Protocolo (3 pasos)
| Paso | Evidencia | Uso en la decisión |
|---|---|---|
| Probar | Tareas y errores del dominio | Estimar capacidad útil |
| Comprobar | Endpoint o artefacto y condiciones | Determinar acceso real |
| Costear | Recorrido completo hasta aceptación | Asignar cargas y escalados |
Relacionado
- Open weights: la matriz de compra es licencia, hardware y evals
- Model Routing as Governance: la política que evita elegir modelo por intuición
Fuentes consultadas
- Mistral — Presentación de Mistral Large 4
- Reflection — Introducing Beam
- Reflection — Ficha y licencia de Beam
- Reflection — Archivos publicados de Beam
- Mistral — Estado de publicación de los pesos
- Anthropic — Claude Haiku 5.5
Próximo paso
Sustituye tu ranking de modelos por una matriz de tareas, acceso comprobado y coste completo. Cualquier casilla basada en una promesa debe quedar identificada antes de aprobar una dependencia.