Autoalojar Mistral Large 4: errores que cuestan caro

Cuando Mistral publicó los pesos de Mistral Large 4 (un modelo de aproximadamente 1 billón de parámetros, con unos 52 000 millones activos), mi bandeja de entrada se llenó con la misma pregunta: ¿podemos ejecutarlo nosotros mismos? Autoalojar pesos abiertos ya no es una fantasía de aficionados, sino una opción arquitectónica real, y eso significa que los equipos están a punto de cometer muchos errores caros. Ya he visto varios de ellos. Este artículo es la versión de lecciones aprendidas: las formas concretas en que los profesionales hacen mal el autoalojamiento y cómo se ve la solución en cada caso.

Error 1: Leer «pesos abiertos» como «gratis para usarlos como quieras»

El primer error ocurre antes de que alguien toque una GPU. Mistral Large 4 se distribuye bajo una licencia de tipo MIT modificada con una excepción importante: si tú o tus afiliados operan un negocio de modelo como servicio, necesitas una licencia comercial aparte de Mistral antes de usar el modelo comercialmente. Para una empresa que hace inferencia internamente (por ejemplo, resumir documentos o potenciar un asistente de código para empleados) probablemente no haya problema. Para una startup que planea revender inferencia, es un alto total hasta que les escribas.

Los equipos se equivocan en ambas direcciones. Algunos ven la palabra «abierto» en un comunicado de prensa y construyen un producto comercial sobre los pesos, descubriendo la restricción durante una auditoría de due diligence para una ronda de financiación, el peor momento posible. Otros hacen la corrección contraria y asumen que la licencia prohíbe todo uso comercial, cuando en realidad apunta a los proveedores de inferencia que compiten. La solución es aburrida y esencial: que tu equipo legal lea el texto real de la licencia, no la entrada del anuncio. Llámalo «pesos abiertos» o «pesos disponibles» (una distinción sobre la que la comunidad discute con fuerza, y no sin razón), la decisión de ingeniería debe basarse en lo que los términos permiten realmente a tu negocio.

Un matiz más: este patrón de licencias ya es la norma en las grandes publicaciones de pesos, no la excepción. Si tu arquitectura depende de cambiar entre Mistral, Qwen y otros modelos de pesos de frontera, necesitas una matriz de licencias, no una revisión puntual. Crea esa hoja de cálculo antes de montar el clúster.

Error 2: Dimensionar el hardware según la página de marketing en lugar de las cuentas

Aquí está el error que más dinero quema. Un ingeniero lee «1T parámetros», mira los cuatro H200 de la sala de servidores de la empresa y concluye que 540 GB de VRAM es suficientemente cerca. No lo es, y la razón es una aritmética que lleva noventa segundos y te ahorra un trimestre de bochorno.

En precisión BF16, un billón de parámetros necesita unos 2 TB de memoria solo para los pesos. Cuantizado a 8 bits, se acerca a 1 TB. A 4 bits, unos 500–560 GB, antes de añadir la caché KV, las activaciones y la sobrecarga de servicio. Ese servidor de 540 GB solo aloja un modelo de 4 bits si te conformas con una ventana de contexto corta y unos pocos usuarios concurrentes. La arquitectura de mezcla de expertos (52 000 millones activos por token) ayuda al cómputo por token, pero no hace nada por la memoria: todos los billones de parámetros deben estar en algún lugar direccionable, y en un MoE los pesos de los expertos se usan de forma impredecible, así que descargarlos a la RAM de la CPU destruye la latencia de una forma que no ocurre con modelos densos.

La solución es trabajar hacia atrás desde tus requisitos de servicio, no hacia adelante desde tu hardware. Define primero la longitud de contexto objetivo, la concurrencia y los tokens por segundo; luego deriva el nivel de cuantización que puedes permitirte; y después, el hardware. Si el resultado son ocho H200 o un par de nodos de clase NVL72, y ese número te hace estremecer, bien: ese estremecimiento significa que el modelo funciona como debe. Hemos cubierto el problema relacionado en qué hacer cuando tu GPU se queda sin VRAM, y las opciones de allí (descarga, cuantizaciones más pequeñas, modelos más pequeños) también aplican aquí, solo que a escala de centro de datos.

# The 90-second sizing check before you buy anything
params = 1_000e9
for bits in (16, 8, 4, 3):
weights_gb = params * bits / 8 / 1e9
# KV cache ballpark for MoE: ~0.5-1.5 GB per 32k-token session
kv_gb = 20 * 1.0          # 20 concurrent 32k sessions
overhead_gb = weights_gb * 0.05
total = weights_gb + kv_gb + overhead_gb
print(f"{bits}-bit: weights {weights_gb:.0f} GB, total ~{total:.0f} GB")
# 16-bit: weights 2000 GB, total ~2120 GB
#  8-bit: weights 1000 GB, total ~1070 GB
#  4-bit: weights  500 GB, total  ~545 GB
#  3-bit: weights  375 GB, total  ~414 GB

Fíjate en que la versión honesta de esa tabla incluye la caché KV y la sobrecarga. La versión deshonesta (solo pesos) es la forma en que los equipos acaban con un modelo que carga pero no puede atender a más de tres usuarios.

Error 3: Tratar la cuantización como un almuerzo gratis

Una vez que los equipos aceptan que necesitan cuantizar, el siguiente error es asumir que 4 bits es «básicamente el mismo modelo». A veces lo es. Con frecuencia no lo es, y los modos de fallo son justo los que más te importan.

El patrón que he visto repetidamente: un equipo evalúa su despliegue de 4 bits con preguntas de opción múltiple tipo MMLU, ve una caída del 1 % y lo lanza. Luego, los usuarios en producción reportan que las refactorizaciones largas de código entre varios archivos se descarrilan, o que el JSON de las llamadas a herramientas sale ligeramente mal formado con baja probabilidad pero alta frecuencia. La cuantización agresiva perjudica de forma desproporcionada las tareas de horizonte largo, estructuradas y de baja temperatura, justo las cargas agénticas y de programación que justifican un modelo de frontera en primer lugar. El promedio apenas se mueve; la cola se desmorona.

La solución es cuantizar hasta donde tolere tu evaluación de la tarea, no hasta donde te obligue la VRAM. Ejecuta los prompts de tu propia carga de trabajo contra versiones FP8, 4 bits y 3 bits y compáralas. Si 3 bits pasa tus evaluaciones, enhorabuena, tu factura de hardware se acaba de reducir a la mitad. Si falla, ningún promedio de benchmark te salvará. Y prefiere las versiones cuantizadas nativas cuando el laboratorio las publique: Mistral lanzó una variante NVFP4 junto a los pesos BF16, y una cuantización oficial con deltas de calidad medidos vence a una conversión GPTQ de la comunidad que validaste durante una tarde.

Un nivel de cuantización es un presupuesto de calidad, no un ajuste de compresión. Gástalo donde tu carga de trabajo pueda permitirse la pérdida.

Error 4: Comparar el precio de la API con el de la GPU y llamarlo análisis de TCO

La clásica hoja de cálculo: «la API cuesta 2,10 $ por millón de tokens de salida, un nodo de GPU reservado cuesta X $ por hora, por tanto, el autoalojamiento se amortiza a partir de Y tokens al mes». Esta hoja casi siempre está mal, y está mal en la dirección cara.

Lo que omite: la utilización. Una API te da el 100 % de utilización de la capacidad de otro, facturada por token. Tu clúster autoalojado te da la utilización que marque tu patrón de tráfico, y la mayoría de las cargas internas son irregulares: intensas en horario laboral, inactivas de noche y con picos en los lanzamientos. Un clúster dimensionado para el pico pasa medio vacío la mayor parte del día. Y después están los costes que nunca aparecen en la hoja: una guardia para una pila de servicio que ahora incluye actualizaciones de vLLM, incompatibilidades de drivers de CUDA y el aviso a las 2 de la madrugada cuando la caché KV se fragmenta; la rotación constante por nuevas versiones de modelos (¿vuelves a validar cada nueva publicación de pesos? tu suite de evaluación dice que sí); y el coste de oportunidad del ingeniero de ML que ahora es cuidador de GPUs en lugar de construir producto.

También hay un problema de objetivo móvil que nadie tiene en cuenta. Mistral redujo el precio de la API de este modelo casi a la mitad entre la vista previa y la versión final: los tokens de entrada pasaron de 1,36 $ a 0,70 $ por millón. Cualquier cálculo de ROI de autoalojamiento hecho con el precio antiguo es ahora ficción. La inferencia de frontera se abarata con una cadencia trimestral, y tu hardware se deprecia en un ciclo de varios años. Esa asimetría es el asesino silencioso de los casos de negocio del autoalojamiento.

La solución: autoaloja solo por razones que la API estructuralmente no puede ofrecer. Esas razones existen y son reales, pero «más barato a escala» rara vez es una de ellas en las escalas en las que opera la mayoría de las empresas.

Cuándo el autoalojamiento sí gana

Entonces, ¿cuándo compensa ejecutar pesos de clase Mistral en local frente a la API? Tras ver a equipos hacerlo bien y mal, los casos ganadores se agrupan en cuatro categorías:

• Residencia de datos y soberanía. Sectores regulados, trabajo relacionado con defensa y organizaciones europeas con requisitos jurisdiccionales estrictos. Una restricción real que vi: una empresa que tenía prohibido usar modelos de origen chino por motivos de cumplimiento; los pesos abiertos de un laboratorio europeo con procedencia auditable resolvieron un problema que ningún contrato de API podía resolver.
• Entornos aislados o con conexión intermitente. Si no se puede confiar en que la red exista, los pesos locales son toda la arquitectura. Exploramos este patrón en cómo construir un LLM que funcione sin conexión.
• Cargas de trabajo sostenidas, predecibles y de alto volumen. El procesamiento por lotes de documentos las 24 horas, a un rendimiento constante, puede superar de verdad el precio por token, porque resuelve el problema de la utilización por diseño.
• Ajuste fino y modificación. No puedes ajustar finamente la API de otro más allá de lo que permite su endpoint de fine-tuning. Ser dueño de los pesos significa ser dueño del bucle de entrenamiento: preentrenamiento continuo con corpus de dominio, alineamiento personalizado y destilación en despliegues más pequeños.

Fíjate en lo que no aparece en la lista: la latencia. Autoalojar un MoE de un billón de parámetros no te dará menor latencia que una API bien aprovisionada, salvo que estés dispuesto a gastar mucho en decodificación especulativa y en servicio optimizado para batch 1. Y fíjate también en lo que tampoco está: «evitar la dependencia de un proveedor». Los pesos que descargas hoy estarán dos generaciones por detrás en un año, y volverás al mismo punto de decisión. Eso, por cierto, es un buen argumento para el instinto de archivo que tienen algunos profesionales de guardar copias locales de las publicaciones de pesos importantes. El almacenamiento es barato; las opciones son valiosas.

El enfoque honesto es que los pesos abiertos y las APIs son complementos, no competidores. Varios equipos que conozco usan un modelo híbrido: la API para el tráfico interactivo irregular, y pesos locales para la porción regulada o intensiva en lotes. Las habilidades se transfieren: tu configuración de vLLM, tu harness de evaluación y tus plantillas de prompts funcionan en ambos mundos. Si quieres los fundamentos operativos antes de comprometerte con la escala de frontera, nuestra guía sobre cómo ejecutar modelos de lenguaje grandes en tu propio hardware cubre la pila de servicio de principio a fin.

Error 5: Evaluar con benchmarks en lugar de con tu carga de trabajo

El último error es el que deshace todos los demás. Un equipo hace todo bien (revisa la licencia, dimensiona el hardware, prueba la cuantización con benchmarks públicos) y luego lanza un modelo que los usuarios odian, porque las evaluaciones nunca midieron nada de lo que hacen de verdad.

Los benchmarks públicos responden a la pregunta «¿este modelo es capaz en general?». No responden «¿este modelo clasifica nuestros tickets de soporte con el tono y el formato que necesitamos, a 4 bits, bajo nuestra carga de concurrencia?». Ya hemos escrito sobre por qué los benchmarks de IA no captan el 90 % del trabajo real, y el autoalojamiento hace la brecha más evidente, no menos: ahora eres responsable de cada variable que antes gestionaba el proveedor de la API. La pila de despliegue, la configuración del muestreador y las convenciones de prompt del sistema con las que se entrenó el modelo son todas tuyas para equivocarte.

La solución es una evaluación de tres capas que construyas antes de comprometerte con el hardware:

1. Un conjunto dorado de producción. Unos cientos de prompts reales con salidas ideales revisadas, que cubran tu distribución real de tareas, incluidos los casos largos, desordenados y de varios turnos.
2. Un arnés de regresión. Cada candidato (API frente a local, FP8 frente a 4 bits, pesos antiguos frente a una nueva versión) ejecuta el conjunto dorado de forma automática. Puntúa con un modelo juez sólido más revisión humana puntual; no confíes ciegamente en el juez para las salidas estructuradas.
3. Un periodo de sombra. Ejecuta el despliegue local junto a la API con tráfico real durante dos semanas, comparando salidas y midiendo la latencia real bajo carga real. Aquí es donde afloran de verdad los errores de dimensionamiento de la caché KV y los fallos en la cola de la cuantización.

Este arnés se paga solo la primera vez que sale una nueva versión de pesos y puedes responder «¿deberíamos actualizar?» con datos en una tarde, en lugar de con intuiciones en una reunión.

La lección real: los pesos abiertos cambiaron la pregunta, no la respuesta

Hace un año, «¿deberíamos autoalojar un modelo de frontera?» era una hipótesis: la frontera no era descargable. Mistral Large 4, junto con la oleada de otros lanzamientos de billones de parámetros, ha convertido eso en una decisión real con dinero real de por medio. Pero el marco de decisión no ha cambiado; simplemente se ha vuelto obligatorio.

Autoaloja cuando la soberanía, la conectividad, el volumen sostenido o la necesidad de modificar el modelo lo exijan. Paga por la API cuando tu tráfico sea irregular, tu equipo sea pequeño y tu diferencial sea el producto y no la pila de inferencia. Y elijas lo que elijas, haz las cuentas de memoria de noventa segundos, lee la licencia y construye el arnés de evaluación antes de firmar nada. Los pesos ya están abiertos. Los errores, por desgracia, también.