Benchmarks Titán

1. El modelo y el entorno

2. La clave: jerarquía de memoria GPU → CPU para la KV cache

El cuello de botella de un MoE grande en concurrencia no es el decode —es la memoria donde vive el estado de atención. La estrategia del Titán reserva la VRAM para lo que necesita ancho de banda a 1.792 GB/s (pesos + KV residente) y descarga el resto de la KV cache y el estado PLE a la DDR5 ECC del servidor, que aporta ~100 GB de memoria de trabajo por instancia sin penalizar el cómputo:

# Command line de producción (idéntica en las 3 instancias)
vllm serve /model \
  --served-model-name qwen3.8-flash-next \
  --max-model-len 524288 \
  --gpu-memory-utilization 0.97 \
  --kv-cache-memory 15569256448   # 14,5 GiB de KV residente en GPU \
  --enable-prefix-caching \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder \
  --reasoning-parser qwen3 \
  --max-num-seqs 16 --tensor-parallel-size 1
# Offload del estado PLE (Per-layer Embedding/offload) a CPU:
env VLLM_PLE_CPU_OFFLOAD=1  VLLM_PLE_OFFLOAD_READY_TIMEOUT=1800

La arquitectura híbrida lineal/completa (36+12 capas) es lo que hace posible el truco: las capas de atención lineal mantienen un estado recurrente de tamaño fijo, así que la KV "que crece con el contexto" solo existe en 12 de las 48 capas. Con 14,5 GiB de KV residente en GPU caben 604.705 tokens —dieciséis sesiones de 32 K o una ventana completa de 512 K— y el paginado a RAM cubre las rachas sin tocar los pesos, que permanecen residentes en GDDR7.

3. Concurrencia: throughput agregado vs. peticiones activas

Curva medida en la instancia 0 a partir de 21.695 muestras de 10 s de los loggers de vLLM (5 días de producción real). Cada barra es el throughput medio de salida de la GPU con N peticiones simultáneas:

Medias por nivel de concurrencia (instancia 0; pico de 8 reqs tomado de la instancia 1). El crecimiento es casi lineal hasta ~5–6 secuencias: hasta ese punto cada petición viaja a ~85 tok/s individuales; a partir de ahí entra en juego el batching continuo de vLLM y el agregado sube mientras el coste por secuencia baja.

3.1 Picos por instancia y suma del clúster

Ventana: 6–13 de septiembre de 2026 (instancias 0–1) y desde el reinicio de la instancia 2. Fila del clúster: suma de las 3 instancias alineada por minuto (máximo de las muestras de 10 s de cada engine dentro del mismo minuto), sobre 2.330 minutos con actividad simultánea en las tres GPUs. 229 minutos superaron los 1.000 tok/s agregados.

3.2 Ráfagas simultáneas por encima de 1.000 tok/s

Las ocho mayores ráfagas medidas con actividad simultánea en las tres GPUs. El pico absoluto muestra a las tres instancias cerca de su máximo individual simultáneamente. Distribución completa de los 2.330 minutos alineados: P99 = 1.125 tok/s · P95 = 1.067 · mediana = 434 — es decir, en el 1 % del tiempo con uso intensivo concurrente el clúster supera los 1.100 tok/s, y en una de cada diez de esas ráfagas, los 1.000 con holgura.

4. Latencias: percentiles reales de producción

Extraídas de los histograms Prometheus de cada engine (/metrics) sobre miles de peticiones de producción real con ~82 % de aciertos de caché de prefijo:

TTFT = tiempo hasta el primer token (incluye prefill; los percentiles altos reflejan prompts de contexto largo —agentes con repositorios completos—, no degradación del decode). ITL = intervalo entre tokens: p50 ≈ 14,7 ms → un usuario individual percibe ~68 tok/s de escritura continua con la máquina cargada, y el p99 de ITL (25 ms) demuestra que el decode nunca se degrada por encima de 40 tok/s ni bajo concurrencia.

4.1 Single-stream controlado (sonda ignore_eos, 256 tokens de salida)

Sonda con prefijo frío (sin caché), prompt de ~500 tokens, temperature=0, con el resto de la carga de producción activa en las otras instancias. TTFT de ~120 ms en frío para un modelo de 171 GiB; ~85 tok/s de decode por secuencia es el suelo de calidad: ni un usuario, ni bajo la peor concurrencia, escribe más lento que en un MacBook con un 4B cuantizado.

5. Por qué Qwen 3.8 Flash Next y no el denso de 27 B

Nuestra carga tipo es la de un agente de código sobre repositorio: reenvía contexto masivo en cada paso (prompts medios de ~90 K tokens en esta máquina) y recibe respuestas cortas. Para ese patrón, el Flash Next nos da mejoras reales frente al Qwen 3.8 denso de 27 B, la referencia densa del fabricante:

La relación prompt:generación ≈ 53:1 de nuestra carga confirma el patrón: con agentes que reenvían todo el contexto en cada paso, la ventaja del Flash Next no es solo de velocidad punta — es estructural: menos FLOPs por token y KV solo en un cuarto de las capas. El denso de 27 B sigue siendo una opción excelente para calidad por euro en contexto corto; para concurrencia con repositorio completo, el MoE híbrido gana en nuestra máquina de forma clara.

6. Conclusiones

7. Limitaciones y validez