Qwen3.6 35B + DFlash (código)
concurrencia plena
FP8 + MTP γ=4 (aula)
en 66,8 GB de pool
1. Entorno
- Hardware: NVIDIA DGX Spark — SoC GB10 Grace Blackwell (sm_121), 128 GB de
memoria unificada (119 usables), ARM64, DGX OS 7.4, CUDA 13.x. Endpoint de servicio:
http://10.100.22.128:8000/v1. - Software: vLLM v0.20.2rc1 (nightly cu130 aarch64) · sparkrun 0.2.31 (orquestación del clúster simarro-128) · Docker 28.5.1 con NVIDIA Container Toolkit.
- Metodología: prompt fijo en castellano con
temperature=0,seed=42; 1 warm-up + 3 runs cronometradas; métricacompletion_tokens / wall_timemedida desde localhost. Concurrencia conThreadPoolExecutora 1/2/4/8/16 peticiones simultáneas sobre 3 escenarios de aula: chat corto (256 tok), Q&A medio (512 tok) y RAG (prompt 4K → 256 tok de salida). - Presupuesto de memoria: con
gpu_memory_utilization=0.8el motor pre-reserva ~87 GB (modelo int4 19,8 GB + pool KV 66,8 GB + CUDA graphs), capacidad de ~1,3 M tokens de KV — 9,9× peticiones simultáneas con contexto completo de 131K. El límite operativo de 4 peticiones en vuelo lo imponemax_num_seqs=4, no la memoria.
2. Qwen 3.6-35B-A3B — comparativa de decodificación especulativa
Diez configuraciones medidas sobre la misma máquina. El cuello de botella del Spark es el ancho de banda de memoria, no el cómputo: por eso la decodificación especulativa (proponer varios tokens por paso de verificación) es la palanca de velocidad más potente en esta plataforma.
| # | Modelo | Especulativo | Prompt | tok/s | Nota |
|---|---|---|---|---|---|
| A | Qwen3.6-35B-FP8 | MTP num=2 | cuento ES | 47,1 | Peor que sin spec |
| B | Qwen3.6-35B-FP8 | sin spec | cuento ES | 52,9 | Baseline FP8 |
| C | Qwen3.6-35B-FP8 | MTP num=1 | cuento ES | 57,9 | Ganador FP8 (+9,5 %) |
| D₁ | Qwen3-Coder-Next-FP8 (80B) | MTP num=1 | cuento ES | 29,1 | 2× más lento por tamaño |
| D₂ | Qwen3-Coder-Next-FP8 (80B) | MTP num=1 | código | 27,9 | Acceptance no compensa |
| E | Qwen3-Coder + Aurora | EAGLE3 num=5 | dashes | — | No arranca en v0.20.1 |
| F | Qwen3.6-35B-NVFP4 | MTP num=1 | cuento ES | 50,9 | NVFP4 −12 % vs FP8 |
| G | Qwen3.6-35B-NVFP4 | MTP num=1 | cuento ES | 51,7 | Backend MoE no es el cuello |
| H1 | Qwen3.6-35B int4-mixed | DFlash k=8 | cuento ES | 63,0 | +9 % vs C |
| ★ H2 | Qwen3.6-35B int4-mixed | DFlash k=8 | código | 107,6 | +85 % vs C · spec brilla en código |
| H3 | Qwen3.6-35B int4-mixed | DFlash k=8 | long-ctx (8K→400) | 96,2 | Overall (incluye prefill ~1 s) |
Configuración productiva: Intel/Qwen3.6-35B-A3B-int4-mixed-AutoRound +
speculative decoding DFlash (k=8) lanzada vía sparkrun. Hallazgos: γ=2 es peor que no
especular (el verificador paga más de lo que ahorra), NVFP4 rinde un 12 % peor que FP8 en
el GB10 (a diferencia del Titán SM120), y el salto real viene del drafter externo DFlash sobre pesos
int4 mixed: +85 % en código frente al mejor MTP FP8.
3. Concurrencia — 3 escenarios de aula × 5 niveles
Comportamiento del servicio actual (Qwen 3.6 int4-mixed + DFlash, max_num_seqs=4) con
varios alumnos preguntando a la vez:
Chat corto (256 tokens)
| Usuarios | 1 | 2 | 4 | 8 | 16 |
|---|---|---|---|---|---|
| Σ agregado (tok/s) | 83,4 | 98,7 | 194,1 | 200,0 | 212,7 |
| tok/s por usuario | 83,5 | 50,4 | 50,5 | 40,2 | 28,8 |
| Latencia p50 / p95 (s) | 3,1 / 3,1 | 5,0 / 5,2 | 5,2 / 5,3 | 9,1 / 10,2 | 16,5 / 19,2 |
Q&A medio (512 tokens)
| Usuarios | 1 | 2 | 4 | 8 | 16 |
|---|---|---|---|---|---|
| Σ agregado (tok/s) | 97,7 | 145,6 | 238,6 | 237,4 | 229,1 |
| tok/s por usuario | 97,8 | 73,2 | 62,2 | 46,2 | 31,1 |
| Latencia p50 / p95 (s) | 5,2 / 5,2 | 6,9 / 7,0 | 8,2 / 8,6 | 15,2 / 17,3 | 30,0 / 35,2 |
RAG (prompt 4K → 256 tokens)
| Usuarios | 1 | 2 | 4 | 8 | 16 |
|---|---|---|---|---|---|
| Σ agregado (tok/s) | 87,5 | 149,7 | 202,9 | 210,2 | 184,6 |
| tok/s por usuario | 87,5 | 75,8 | 51,1 | 37,9 | 25,5 |
| Latencia p50 / p95 (s) | 2,9 / 2,9 | 3,3 / 3,4 | 4,9 / 5,0 | 9,1 / 9,7 | 19,5 / 21,9 |
Lectura: el agregado sube con la concurrencia hasta saturar el batch (n=4) y luego se
mantiene plano (continuous batching sirviendo colas); el throughput por usuario cae al repartir — con
4 usuarios cada uno ve ~1/4 del agregado; la latencia p95 pasa de ~3 s a ~20 s al saltar de 1 a 16
usuarios por efecto de la cola. Para un aula de 30 alumnos en modo interactivo, el límite operativo
sigue siendo max_num_seqs: está identificado como pendiente de re-test.
4. Gemma 4 — el banco del servicio de aula
El servicio didáctico multilingüe (castellano/valenciano) se decidió sobre este banco, con un prompt
estándar de explicación académica (temperature=0, 350 tokens de salida, medida sobre la
segunda ejecución). Todas las variantes sobre el mismo Spark:
| # | Modelo objetivo | Cuantización | Aceleración | Acept. media | tok/s |
|---|---|---|---|---|---|
| 0 | Gemma 4 31B | NVFP4 (modelopt) | n-gram γ=5 | 1,4–2,3 / 5 | 7,5 |
| 1 | Gemma 4 31B | NVFP4 (modelopt) | MTP γ=7 | 2,5–3,2 / 7 | 13,7 |
| ★ 2 | Gemma 4 31B | FP8 (compressed-tensors) | MTP γ=4 | 2,4–2,8 / 4 | 16,0 |
| 3 | Gemma 4 26B-A4B (MoE) | FP8 (compressed-tensors) | MTP γ=4 | 2,2–2,5 / 4 | 48,6 |
Dos saltos importantes: pasar de la heurística n-gram al drafter MTP oficial de Google sobre el mismo modelo (7,5 → 13,7 tok/s, casi el doble) y cambiar NVFP4→FP8 ajustando γ (→16,0). Sobre γ: la curva de aceptación por posición cae del 77 % en posición 0 al 15 % en la 3ª y al 6 % en la 4ª — γ=4 es el punto donde la última posición incluida aún aporta más de lo que cuesta; alargar a γ=7-8 no daba velocidad extra, al contrario. La variante MoE 26B-A4B (~3× más rápida que el denso 31B por el mismo motivo que en el Titán: solo 4 B parámetros leídos por token) queda preparada para talleres masivos y demos donde manda la velocidad.
Decisión de cuantización (Gemma 4 31B)
| Formato | Bits/peso | Tamaño | Calidad relativa |
|---|---|---|---|
| bf16 (sin cuantizar) | 16 | ≈ 62 GB | Referencia |
| FP8 (compressed-tensors) ✓ | 8 | ≈ 31 GB | Pérdida típica < 0,5 % |
| NVFP4 (modelopt) | 4 | ≈ 17 GB | Pérdida típica 1–2 % |
Con 128 GB unificados el bf16 cabría pero deja poco margen para KV + drafter; el FP8 con
compressed-tensors (RedHatAI/gemma-4-31B-it-FP8-block) es el punto de equilibrio
elegido: pérdida < 0,5 %, lectura de memoria a mitad que bf16 — y en el GB10, que es
ancho-bandera-limited, eso es velocidad directa.
5. Límites caracterizados: el incidente del 397B
Documentamos también lo que no funciona: se intentó servir un modelo de ~397 B
(MoE, cuantizado) en un clúster dual-Spark (2× 128 GB unificados, tp=2 via gloo).
Los pesos entran en disco, pero el reparto del estado entre dos GB10 por la interconnect del clúster
colapsó la memoria del host: fallo del group gloo, OOM, reintentos conservadores, SIGTERM, y
finalmente cuelgue del host sin recuperación limpia. Conclusión práctica para cualquier centro:
el límite de un dual-Spark no son los pesos — es el overhead de paralelización del
estado; para modelos de esa talla hace falta un nodo con GPU discreta de 288+ GB
(nuestro caso: el Titán) o context parallelism real, no gloo sobre ConnectX.
6. Conclusiones
En el GB10 manda el ancho de banda
Con ~270 GB/s de memoria unificada, el single-stream es memory-bound: cuantizar y especular dan más velocidad que cualquier ajuste de cómputo. Y attention: NVFP4 (que gana en el SM120 discreto) rinde un 12 % peor que FP8 aquí — el formato óptimo depende del chip, no del marketing.
Un Spark sirve una clase entera
238,6 tok/s
agregados a concurrencia 4 con latencias de ~8 s: con 30 alumnos la cola media es de 25–40 s
por turno — viable para dinámica de aula asincrónica, y queda margen subiendo
max_num_seqs (pendiente de re-test) porque la memoria no es el límite.
Speculative decoding: +85 % donde encaja
DFlash k=8 sobre int4-mixed: 107,6 tok/s en código. La palanca es el drafter externo y la tarea predecible (código, plantillas); en prosa creativa el acceptance cae y γ alto es peor que no especular (fila A). Medir siempre el acceptance por posición antes de elegir γ.
Publicamos los fallos
El 397B tumbando un host y EAGLE3 sin arrancar en la nightly también son resultados. Un centro de excelencia que solo publica picos no dimensiona a nadie: esta sección existe para que el siguiente centro no pierda el fin de semana que perdimos nosotros.
Sobre este documento
Volcado público del banco de pruebas interno del array DGX Spark (documentos técnicos "info-tecnica" del servicio vLLM del centro, mayo–junio 2026, y la bitácora MTP del servicio Gemma 4). Métricas del servidor con decodificación greedy y protocolo de 3 runs. IES Dr. Lluís Simarro, Centro de Excelencia Nacional en IA y Big Data. Repositorio: aulaenlanube/pp1-simarro.