Mistral Large 4 con pesos abiertos: self-hosting, GPUs y licencia

El 29 de octubre de 2026, Mistral publicó los pesos de Mistral Large 4, el Mixture-of-Experts de ~1T de parámetros que servía como preview solo por API desde el 6 de octubre. En Hugging Face aparecieron dos checkpoints oficiales: FP8, de alrededor de 1,06 TB, y NVFP4 para GPUs Blackwell, de alrededor de 610 GB, bajo una licencia nueva, la Mistral Ecosystem Open-Weight License. Descargarlos es gratis. Correrlos requiere un nodo de datacenter.

Esta es la continuación de mi post sobre la preview: quién puede servirlo de forma realista, los comandos exactos de vLLM y SGLang, qué permite la licencia y cuándo conviene más la API. El 3 de noviembre de 2026 leí las dos model cards, el archivo LICENSE, el config.json, el reporte técnico de Mistral, la receta de vLLM y el cookbook de SGLang, y rehice yo mismo las cuentas de parámetros, memoria y caché KV. No descargué los pesos ni corrí el modelo, así que acá no hay afirmaciones propias de velocidad.

1. La ficha técnica

Mistral le dice “Le Chonk”. Todo lo que sigue sale de la model card, el config.json, la documentación de Mistral y la API de Hugging Face, revisados el 3 de noviembre de 2026.

Mistral Large 4 de un vistazo

Los conteos de parámetros son los de Mistral. Los recalculé a partir del config.json y me dieron ~1,05T en total, 49,8B activos por token y 52,3B sumando las capas de embedding y de salida.

Spec	Valor
Arquitectura	MoE granular: 72 capas, 128 expertos ruteados (4 por token) más 1 experto compartido; la primera capa es densa
Parámetros	~1T en total (1,05T en la documentación de Mistral); 49B activos por token, 52B con embeddings y capas de salida; encoder de visión Pixtral de 1,6B
Atención	Multi-head latent attention (MLA) con un indexador disperso estilo DeepSeek que elige 2.048 keys por query; 9 de las 72 capas reutilizan la caché KV de otra capa
Contexto	1.048.576 tokens en el config.json; vLLM validó hasta 256K
Entrada → salida	Texto e imágenes → texto; function calling, salida con JSON schema estricto, más de 160 idiomas según la card
Razonamiento	reasoning_effort low, medium o high (el default); no se puede apagar
Decodificación especulativa	Cabeza draft DSpark incluida (3 capas MLA en BF16 que proponen bloques de 3 tokens); Mistral midió hasta 1,9× de throughput
Checkpoints oficiales	FP8 con escalas por bloque (1.061 GB) y expertos en NVFP4 con capas lineales en FP8 (610 GB), según la API de Hugging Face
Formatos de la comunidad	GGUF de ggml-org y Unsloth (de 233 GB a 2,1 TB); MXFP4 de AMD Quark (578 GB)
Licencia	Mistral Ecosystem Open-Weight License, una MIT modificada (detalle en la sección 5)
API	mistral-large-4 (también aparece como mistral-large-4-0): USD 0,70 de entrada, 0,07 de entrada cacheada y 2,10 de salida por 1M de tokens

Cronología del lanzamiento

• 6 de octubre de 2026: preview pública en la API de Mistral y en Mistral Studio. El repo de Hugging Face era un placeholder vacío.
• 29 de octubre de 2026, 14:11 UTC: commits de “Initial release” en los dos repos oficiales, el mismo día del post de lanzamiento de Hugging Face y del anuncio de Mistral.
• Entre el 28 y el 29 de octubre: conversiones GGUF de ggml-org y Unsloth, más imágenes Docker con el tag mistral-large-4 para vLLM y SGLang.
• 2 de noviembre: Mistral suma un reporte técnico de 30 páginas al repo FP8.
• 3 de noviembre: la documentación de Mistral todavía marca el modelo de la API como “Public Preview” (versión v26.10).

¿49B o 52B activos? Los dos, en la misma card

El nombre del repo dice A52B, el blog de Hugging Face dice 49B y la cobertura elige uno u otro. La model card da los dos: 49.000 millones de parámetros activos por token, 52.000 millones contando embeddings y capas de salida. Mi cuenta a partir del config.json coincide: 4 expertos ruteados más el compartido, la atención y la primera capa densa suman unos 49,8B, y las matrices de embedding y de salida de 204.800 tokens agregan 2,5B. Igual, para planificar memoria el número que importa es el total, porque todos los expertos tienen que estar en la memoria de la GPU.

2. Qué cambió desde la preview

Mi post de la preview cubrió la etapa solo-API a mediados de octubre. Con el lanzamiento cambiaron cuatro cosas. El anuncio de Mistral presenta el checkpoint publicado como un Mistral Large 4 “mejorado”, con más aprendizaje por refuerzo en código y ciberseguridad y un razonamiento más eficiente.

Los cuatro cambios que importan

📦

Pesos y una licencia con nombre

Checkpoints FP8 y NVFP4, más un texto de licencia que en octubre no existía. El self-hosting ahora es una cuestión de hardware, no una promesa.

🎚️

Tres niveles de razonamiento

low, medium y high (el default). Mistral dice que low reemplaza al “none” de la preview, y Hugging Face aclara que el razonamiento ya no se puede desactivar.

💶

Más o menos la mitad del precio de lista

La API ahora lista USD 0,70 / 2,10 por 1M de tokens (entrada cacheada a 0,07), frente al precio de lista de la preview, 1,36 / 4,18, y su oferta de lanzamiento, 0,68 / 2,09.

⚡

Un drafter dentro del checkpoint

La cabeza de decodificación especulativa DSpark viene con los dos checkpoints, y vLLM y SGLang la activan con un solo flag.

Cambios de puntaje, preview → lanzamiento (autorreportados)

• Terminal-Bench 4.0: 28,3% → 41%, con 30% menos tokens de salida, según el anuncio de Mistral.
• DeepSWE 1.1: 61,7% en la preview → 65,2% en el reporte técnico.
• Lakera B3 (seguridad de agentes): 93,3% → 97,1% de resistencia a ataques.
• Artificial Analysis Coding Agent Index: 48% en la card (48,3% en el reporte), “prácticamente empatado” con GLM-5.3, que saca 48,9%. En la propia tabla de Mistral queda segundo por poco, no primero. El post de Hugging Face todavía cita el 49,8% de la preview, pero el reporte etiqueta el índice como v2, así que no compares los dos números.

Si leíste el post de la preview

Su consejo (evaluar por la API y quedarse con Large 3 si había que hacer self-hosting) tenía sentido mientras no había nada para descargar. Ahora la ecuación es otra: Large 4 corre en un solo nodo Blackwell, pero bajo una licencia con una cláusula de Model as a Service que la Apache 2.0 de Large 3 nunca tuvo.

3. Las cuentas de hardware: quién puede correrlo de verdad

Empezá por el dato que lo decide todo. Un Mixture-of-Experts calcula solo unos 49B de parámetros por token, pero los ~1,05T tienen que estar en la memoria de la GPU, porque el router puede mandar cualquier token a cualquier experto. Los expertos ruteados son el 98% de los parámetros (1,029T), y por eso cuantizar solo los expertos achica tanto el archivo.

Pesos: bytes por parámetro × parámetros (mi cuenta)

• FP8 es 1 byte por peso. 1,029T de pesos de expertos ≈ 1.029 GB, más la atención, los embeddings, el encoder de visión y el drafter, algunos guardados en BF16: 1.061 GB en Hugging Face.
• NVFP4 son 4 bits por peso más una escala FP8 cada 16 pesos: 4,5 bits, o 0,5625 bytes. 1,029T × 0,5625 ≈ 579 GB de expertos, más ~30 GB de capas en FP8 y BF16: 610 GB en Hugging Face (606 GB en el reporte técnico).
• Por eso la regla rápida de la época de la preview, unos 525 GB a 4 bits, era demasiado optimista: las escalas y las capas sin cuantizar suman unos 85 GB.

Después viene la caché KV. Por cada token, cada una de las 63 capas que mantienen su propia caché guarda un latente comprimido de 576 valores (512 valores más una key RoPE de 64). En BF16 eso es 63 × 576 × 2 bytes ≈ 72,6 KB por token. La caché FP8 que viene por defecto la reduce más o menos a la mitad, unos 40 KB, más una caché chica para el indexador disperso. Una conversación completa de 1.048.576 tokens necesita entonces unos 76 GB en BF16, o unos 42 GB en FP8.

La trampa: con tensor parallelism simple, cada GPU guarda su propia copia de esa caché comprimida. El reporte técnico de Mistral lo dice sin vueltas (“naive tensor parallelism… suffers from KV replication across TP ranks”), y por eso el layout con decode context parallelism de la receta de vLLM (DCP8) entra 28,76M de tokens de KV en 8× GB300 en vez de 3,60M. Así que la memoria que importa es la que queda libre en cada GPU, no el total del nodo.

¿Entra? Presupuesto por GPU con --gpu-memory-utilization 0.85

Mi cuenta: tamaño del checkpoint ÷ cantidad de GPUs, contra el 85% de la memoria de cada GPU (H200 141 GB, B200 180 GB, B300 y GB300 288 GB). Las cifras por GPU de la propia receta (~128 GiB en FP8, ~76 GiB en NVFP4, con 8 GPUs) dan un poco más, porque algunas partes se replican. Lo “libre” todavía tiene que alojar activaciones, CUDA graphs y la caché KV. El estado sale de la receta de vLLM y del cookbook de SGLang.

Setup	Checkpoint	Pesos por GPU	Libre por GPU	Estado
8× H200	FP8 (1.061 GB)	132,6 GB	Nada (presupuesto de 119,9 GB)	La receta de vLLM dice que FP8 necesita dos nodos H200; la receta de Endpoints de Hugging Face afirma 8× H200 con 131K de contexto
2 × 8× H200	FP8	66,3 GB	~54 GB	Validado con TP16 + DCP8 (o PP2 × TP8); sin números de velocidad publicados
4× B200	NVFP4 (610 GB)	152,5 GB	~0,5 GB	No entra
8× B200	NVFP4	76,3 GB	~77 GB	Validado (vLLM)
8× B200	FP8	132,6 GB	~20 GB	No está en la lista validada; queda poco lugar para la caché KV
4× B300 / GB300	NVFP4	152,5 GB	~92 GB	Validado: el default de vLLM y el ejemplo TP4 de SGLang
8× B300	FP8	132,6 GB	~112 GB	Validado; SGLang midió un pool de caché KV FP8 de 2,49M de tokens
8× AMD MI350X	FP8, con los expertos recuantizados a MXFP4 al cargar (~578 GB)	—	—	Validado: dos réplicas TP4 por nodo con la imagen ROCm de vLLM

Qué significan los números de KV en la práctica

• 8× B300 con FP8: el pool de 2,49M de tokens que midió SGLang son unas dos conversaciones completas de 1M, o 19 de 128K. Con caché en BF16 baja a 1,34M.
• Las sesiones largas de agentes se quedan sin caché KV antes que sin cómputo. Si es tu caso, mirá los presets DCP de la receta antes de comprar más GPUs.

Setups más chicos: GGUF, con paciencia

El post de lanzamiento de Hugging Face dice que los GGUF de 2 bits (Q2_K de 381 GB, IQ2_XXS de 298 GB) entran en un solo Apple Silicon Ultra con 512 GB de memoria unificada. En un M3 Ultra con Q2_K, el equipo de HF midió unos 90 tokens/s de prefill y 15 tokens/s de generación. En 4× RTX 6000 Pro obtuvieron ~10 tokens/s con el GGUF NVFP4 a 32K de contexto, y entre 3 y 30 tokens/s con IQ2_XXS, según el largo del contexto. Sirve para evaluaciones privadas, no para producción.

4. Quickstart: vLLM y SGLang

Por ahora, los dos servidores necesitan imágenes Docker específicas para este modelo. La receta de vLLM dice que ninguna release ni wheel nightly de vLLM incluye todavía soporte para Mistral Large 4, así que usás vllm/vllm-openai:mistral-large-4; SGLang usa lmsysorg/sglang:mistral-large-4. Cada comando de serving de abajo está copiado de la receta o de una model card; solo agregué comentarios. Si todavía estás eligiendo entre los dos motores, mi guía de vLLM vs SGLang muestra cómo comparar los dos con tu propio tráfico.

Antes de empezar

Según la receta de vLLM, el cookbook de SGLang, las model cards y Docker Hub, revisados el 3 de noviembre de 2026.

Pieza	Qué usar	Notas
vLLM	vllm/vllm-openai:mistral-large-4 (la receta pide vLLM ≥ 0.34.0)	El servidor que recomienda Mistral; en AMD, vllm/vllm-openai-rocm:mistral-large-4
SGLang	lmsysorg/sglang:mistral-large-4	El cookbook cubre los dos checkpoints y suma --tokenizer-mode mistral como opción
Descarga	1.061 GB (FP8) o 610 GB (NVFP4)	A 1 GB/s el repo FP8 tarda unos 18 minutos; a 100 MB/s, unas 3 horas

vLLM: NVFP4 en 4× GB300 (el default de la receta)

Solo Blackwell. El timeout le da al engine hasta 100 minutos para cargar. En 8× B200, el comando de la receta es idéntico salvo por --tensor-parallel-size 8.

# vLLM recipe default: 4× GB300, NVFP4, tensor parallel 4
export VLLM_ENGINE_READY_TIMEOUT_S=6000
vllm serve mistralai/Mistral-Large-4-1T-A52B-NVFP4 \
  --tokenizer-mode mistral \
  --config-format mistral \
  --load-format mistral \
  --max-model-len 262144 \
  --max-num-batched-tokens 8192 \
  --max-num-seqs 128 \
  --gpu-memory-utilization 0.85 \
  --tensor-parallel-size 4 \
  --enable-auto-tool-choice \
  --tool-call-parser mistral \
  --reasoning-parser mistral \
  --speculative-config '{"method":"dspark","num_speculative_tokens":3}'

vLLM en Docker: NVFP4 en 8× B200

La versión Docker de la receta. Para FP8 en 8× B300, el comando de la receta es el mismo con mistralai/Mistral-Large-4-1T-A52B como modelo.

# Same recipe, Docker form, on 8× B200 (NVFP4, tensor parallel 8)
docker run --gpus all \
  --privileged --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e VLLM_ENGINE_READY_TIMEOUT_S=6000 \
  vllm/vllm-openai:mistral-large-4 mistralai/Mistral-Large-4-1T-A52B-NVFP4 \
  --tokenizer-mode mistral \
  --config-format mistral \
  --load-format mistral \
  --max-model-len 262144 \
  --max-num-batched-tokens 8192 \
  --max-num-seqs 128 \
  --gpu-memory-utilization 0.85 \
  --tensor-parallel-size 8 \
  --enable-auto-tool-choice \
  --tool-call-parser mistral \
  --reasoning-parser mistral \
  --speculative-config '{"method":"dspark","num_speculative_tokens":3}'

vLLM: FP8 en dos nodos 8× H200 (TP16 + DCP8)

El preset de contexto largo para H200 de la receta. Definí $HEAD_IP y $IFACE_NAME (la interfaz de red) en los dos nodos, y mandá los requests al nodo 0. Acá se validó la corrección, pero no se tomaron números de velocidad.

# Head (node 0)
export VLLM_ENGINE_READY_TIMEOUT_S=6000
export GLOO_SOCKET_IFNAME=$IFACE_NAME
export NCCL_SOCKET_IFNAME=$IFACE_NAME
vllm serve mistralai/Mistral-Large-4-1T-A52B \
  --tokenizer-mode mistral \
  --config-format mistral \
  --load-format mistral \
  --max-model-len 262144 \
  --max-num-batched-tokens 8192 \
  --max-num-seqs 128 \
  --gpu-memory-utilization 0.85 \
  --tensor-parallel-size 16 \
  --nnodes 2 \
  --node-rank 0 \
  --master-addr $HEAD_IP \
  --decode-context-parallel-size 8 \
  --enable-auto-tool-choice \
  --tool-call-parser mistral \
  --reasoning-parser mistral \
  --speculative-config '{"method":"dspark","num_speculative_tokens":3}'

# Node 1
export VLLM_ENGINE_READY_TIMEOUT_S=6000
export GLOO_SOCKET_IFNAME=$IFACE_NAME
export NCCL_SOCKET_IFNAME=$IFACE_NAME
vllm serve mistralai/Mistral-Large-4-1T-A52B \
  --tokenizer-mode mistral \
  --config-format mistral \
  --load-format mistral \
  --max-model-len 262144 \
  --max-num-batched-tokens 8192 \
  --max-num-seqs 128 \
  --gpu-memory-utilization 0.85 \
  --tensor-parallel-size 16 \
  --nnodes 2 \
  --node-rank 1 \
  --master-addr $HEAD_IP \
  --headless \
  --decode-context-parallel-size 8 \
  --enable-auto-tool-choice \
  --tool-call-parser mistral \
  --reasoning-parser mistral \
  --speculative-config '{"method":"dspark","num_speculative_tokens":3}'

SGLang: NVFP4 en 4 GPUs Blackwell (model card NVFP4)

Correlo dentro de la imagen. DSpark está activado y --max-running-requests queda fijo en 64 (sin el flag, SGLang vuelve a 48). Para FP8, la card principal usa mistralai/Mistral-Large-4-1T-A52B con --tp-size 8.

docker pull lmsysorg/sglang:mistral-large-4

sglang serve \
  --model-path mistralai/Mistral-Large-4-1T-A52B-NVFP4 \
  --tp-size 4 \
  --mem-fraction-static 0.85 \
  --speculative-algorithm DSPARK \
  --max-running-requests 64 \
  --reasoning-parser auto \
  --tool-call-parser auto \
  --host 0.0.0.0 \
  --port 30000

Llamalo con el cliente de OpenAI (adaptado de la model card)

max_completion_tokens también cuenta los tokens de razonamiento. El campo reasoning sale del ejemplo de vLLM de la card; con SGLang, imprimí el mensaje crudo una vez, porque los nombres de campo pueden cambiar entre servidores.

# pip install openai
from openai import OpenAI

# vLLM listens on port 8000; the SGLang command above uses 30000
client = OpenAI(api_key="EMPTY", base_url="http://localhost:8000/v1")
model = client.models.list().data[0].id

response = client.chat.completions.create(
    model=model,
    messages=[{"role": "user", "content": "Find the race condition in this handler: ..."}],
    reasoning_effort="medium",   # "low" | "medium" | "high" (default)
    temperature=1.0,
    top_p=0.95,
    max_completion_tokens=4096,  # counts reasoning tokens too
)

print(response.choices[0].message.reasoning)  # reasoning trace (vLLM)
print(response.choices[0].message.content)    # the answer

Mac Studio con 512 GB: un GGUF de 2 bits (post de Hugging Face)

Usa la CLI de Llama App de llama.app. Después, los ejemplos del post consultan el endpoint habitual /v1/chat/completions.

# Llama App CLI (llama.app); Q2_K is a ~381 GB download
llama serve -hf ggml-org/Mistral-Large-4-1T-A52B-GGUF:Q2_K

Flags que conviene entender

• --tool-call-parser mistral y --reasoning-parser mistral (vLLM), o auto (SGLang): necesarios para las tool calls y para separar el razonamiento de la respuesta.
• --tokenizer-mode, --config-format y --load-format mistral: están en la receta y faltan en el comando Docker más simple de la model card. La receta dice que sus comandos tienen prioridad, así que dejalos.
• --speculative-config con dspark (vLLM) o --speculative-algorithm DSPARK (SGLang): activa el drafter incluido. El checkpoint fija la profundidad en 3.
• --kv-cache-dtype fp8_ds_mla: la card NVFP4 lo define explícitamente, mientras que la receta dice que la caché latente FP8 ya es el default. De una forma u otra, terminás con la caché FP8.
• --decode-context-parallel-size 8: reparte la caché KV entre ranks para contexto largo, en vez de copiarla en cada GPU.

Configuración de la model card

temperature 1.0 y top_p 0.95 en todos los niveles de razonamiento. Usá reasoning_effort high para agentes y prompts difíciles, medium para el trabajo del día a día y low para chat rápido. Mantené el set de tools chico y bien definido, y escribí un system prompt que describa el entorno.

5. Límites honestos

Que los pesos estén publicados no lo vuelve un modelo fácil de correr. Estos son los límites que le pondría adelante a un equipo.

Dónde tendría cuidado

• Necesita un nodo Blackwell o dos nodos Hopper. FP8 no entra en un solo servidor 8× H200 con la configuración de la receta, y NVFP4 requiere Blackwell.
• El soporte tiene días. Ninguna release de vLLM lo incluye todavía, y los dos servidores corren desde imágenes específicas. Esperá cambios a medida que el soporte pase a upstream.
• La mayoría de los benchmarks son de Mistral, y los harnesses independientes pueden no coincidir. Vals midió 26,26% en Terminal-Bench 4.0 contra el 41% de Mistral, con razonamiento en high a través de la API de Mistral.
• En inteligencia agregada queda detrás de los mejores modelos abiertos: Artificial Analysis le da 26 en su Intelligence Index, contra 32 de DeepSeek V4.1 Flash y GLM-5.3. La apuesta de Mistral es código, ciberseguridad y eficiencia de tokens.
• El contexto de 1M está anunciado, pero vLLM validó 256K (su --max-model-len 262144), y las sesiones largas de agentes chocan con los límites de KV por GPU de la sección 3.
• El razonamiento no se puede apagar, y en high es verborrágico. Medí tokens por tarea, no solo tokens por segundo.
• Mistral dice que está “modifying our guardrails” después de ver “a potential for uplift to conduct real attacks”. Esos guardrails viven en su servicio hosteado; una copia propia tiene solo lo que quedó entrenado en los pesos, así que el filtrado corre por tu cuenta.
• Mistral también se cubre: las dos model cards recomiendan su API “if local serving is subpar”.

La licencia en palabras simples

La Mistral Ecosystem Open-Weight License es el texto de la MIT con tres condiciones numeradas. Podés usar, copiar, modificar, hacer fine-tuning, distribuir y vender copias del modelo y de sus derivados, siempre que conserves el aviso de copyright y de permiso. No hay umbral de facturación, ni lista de usos aceptables, ni cláusula contra entrenar modelos competidores; la model card solo agrega que no podés infringir derechos de terceros. La trampa es el Model as a Service. Si vos o cualquier empresa afiliada le dan a terceros acceso de inferencia o post-entrenamiento al modelo o a un derivado “in a manner that allows such third party to exercise meaningful control over the inputs, parameters, or training data” (una API, un endpoint hosteado, fine-tuning como servicio), necesitás una licencia comercial aparte con Mistral antes de usarlo con cualquier fin comercial. Quedan exentos: el uso interno, los productos para usuarios finales donde el modelo está integrado en funciones específicas, reenviar requests a modelos hosteados por otros y el uso a través de los productos de Mistral. Una función dentro de tu SaaS o un agente de código interno están bien; revender tokens de Large 4 no, sin un acuerdo. No soy abogado, así que hacé que alguien de legales lea el texto, que entra en una página, antes de salir a producción.

Veredicto: ¿self-hosting o API?

Mistral cumplió lo que prometió en octubre: pesos de verdad, dos checkpoints prácticos, imágenes de vLLM y SGLang desde el primer día y una licencia permisiva para casi todos menos los proveedores de inferencia. Un modelo de un billón de parámetros entrenado en Europa ahora corre en un solo nodo Blackwell que controlás vos.

Para la mayoría de los equipos, igual, la API sigue siendo el mejor negocio. A USD 0,70 / 2,10 por 1M de tokens, necesitás un nodo ocupado, prompts largos sin caché o una exigencia fuerte de residencia de datos para que tener el hardware convenga. Hacé self-hosting cuando el control es el requisito, no cuando esperás ahorrar plata.

Cuenta de equilibrio (mi cuenta, solo como ilustración)

Tomá el mejor layout de B200 que midió vLLM (8 GPUs de prefill + 8 de decode, NVFP4, entradas de 32K tokens): 164,4 tokens de salida por segundo por GPU, o 591.840 por hora de GPU. Al precio de la API, USD 2,10 por 1M de tokens de salida, eso son USD 1,24 por hora. Ahora suponé 1.000 tokens de salida por request (supuesto mío; la receta no lo dice): cada hora de GPU también procesa unos 19M de tokens de entrada, que valen USD 13,26 sin caché a 0,70/M, o 1,33 con caché a 0,07/M. Lambda lista una HGX B200 a USD 6,69 por hora de GPU on demand. Entonces un nodo a plena carga con prompts sin caché produce ~USD 14,50 por hora en tokens a precio de API, y conviene si está ocupado más de ~46% del tiempo. Con prompts que aprovechan la caché son ~USD 2,57, y gana la API. El prefix caching también acelera tu propio servidor, así que tomá ese segundo caso como una cota aproximada, y hacé la cuenta con tu propia mezcla de tokens.

Quién debería hacer qué

4× B300/GB300 u 8× B200

Equipos que ya corren Blackwell, necesitan que los datos queden adentro o quieren hacer fine-tuning. Empezá con NVFP4 y el comando default de la receta.

Dos nodos 8× H200

Funciona con FP8 y TP16 + DCP8, pero nadie publicó números de velocidad. Hacé una prueba de carga antes de mandarle tráfico.

Proveedores de inferencia y nubes de GPU

Ofrecer Large 4 como API o endpoint hosteado es Model as a Service: conseguí primero la licencia comercial de Mistral.

Todos los demás

Usá la API: USD 0,70 / 2,10 por 1M de tokens, sin hardware y con los guardrails hosteados de Mistral incluidos.

Checklist de self-hosting

1. Primero pasá tus propios prompts por la API en low, medium y high, y registrá calidad y tokens por tarea. Esa es tu línea de base.
2. Elegí el checkpoint según la GPU: NVFP4 en Blackwell, FP8 en Hopper o AMD.
3. Revisá las cuentas por GPU de la sección 3 contra tu contexto real más largo, no contra el titular de 1M.
4. Bajá la imagen Docker específica del modelo y empezá desde el comando de la receta, no desde una instalación vieja de vLLM.
5. Volvé a correr la línea de base de la API contra tu servidor, con y sin DSpark, y rehacé la cuenta de equilibrio con tu utilización real.
6. Si alguien de afuera de tu empresa va a llamar al modelo, leé la cláusula de Model as a Service con alguien de legales.