Problema
“Abierto” se usa como atajo para barato, portable y libre de restricciones. En realidad, dos modelos con pesos descargables pueden imponer obligaciones distintas y necesitar perfiles de hardware incompatibles.
Un modelo lidera el benchmark y cabe en memoria solo con una cuantización que degrada justo las tareas de código del equipo. Otro rinde algo menos, pero tiene licencia clara, runtime estable y latencia predecible. La tabla pública favorece al primero; la operación puede favorecer al segundo.
Tesis
La compra de open weights requiere una matriz de cuatro ejes: licencia, hardware, evaluaciones y operación. El benchmark solo ocupa una celda.
La idea incómoda: descargar pesos elimina una factura de API; no elimina procurement.
Framework
Poolside publica Laguna XS 2.1 con la licencia OpenMDW 1.1 y variantes cuantizadas para distintos runtimes. El ejemplo muestra que el artefacto técnico y el contrato de uso deben revisarse juntos.
La matriz debe responder cuatro preguntas. ¿Podemos usar, modificar y redistribuir bajo nuestro modelo comercial? ¿Qué calidad conserva en el hardware real? ¿Conocemos la procedencia de las evals? ¿Quién mantendrá serving, parches y observabilidad?
Añade escenarios, no una puntuación única: carga normal, pico, contexto largo y versión cuantizada. El modelo se compra como sistema desplegado, no como checkpoint ideal.
Señal medible: porcentaje de modelos desplegados con ficha de licencia, perfil de memoria, eval interna y plan de actualización.
Por que importa ahora
La oferta open weight crece más rápido que la capacidad de evaluación de los equipos. Sin un proceso de procurement, cada descarga crea una excepción técnica y legal difícil de mantener.
La portabilidad también tiene coste. Cambiar pesos puede obligar a recalibrar prompts, tool calling, guardrails y evals. Un formato abierto ayuda, pero la dependencia se desplaza hacia el runtime y el comportamiento.
Anti-ejemplo
“Tiene licencia open y cabe en nuestra GPU.” Eso no demuestra que permita tu distribución, que rinda con tus datos ni que el runtime conserve calidad.
Tampoco es suficiente comparar coste por token. Incluye utilización del hardware, ingeniería on-call y capacidad ociosa.
Protocolo (3 pasos)
- Lee la licencia. Registra obligaciones, restricciones y derivados.
- Prueba el sistema real. Mide memoria, latencia, calidad y throughput.
- Compara operación. Incluye observabilidad, parches y coste de servir.
Fija una fecha de reevaluación. En un mercado que cambia cada semana, una decisión sin caducidad se convierte en lealtad accidental.
| Eje | Evidencia | Decisión |
|---|---|---|
| licencia | revisión documentada | uso permitido |
| hardware | benchmark propio | despliegue viable |
| eval | casos del negocio | calidad suficiente |
Relacionado
- MiniMax M3: open weight baja el umbral de agentes largos
- IA local en 2026: perímetro, coste y latencia
Fuentes consultadas
Proximo paso
Elimina la columna única de benchmark de tu shortlist. Añade licencia, memoria real, eval propia y coste de actualización antes de elegir modelo.