Un 27B de 'Cold Fusion' contra mi MoE de producción: DFlash2, suites de calidad y qué ganó de verdad

La configuración#

Mi servidor de inferencia casero es una sola AMD RX 7900 XTX (24 GB) corriendo llama.cpp compilado para ROCm/HIP. Atiende un bot de WhatsApp las 24 horas: un modelo Mixture-of-Experts de 35B parámetros (~3.5B activos por token, el finetune "BigBang" de una base Qwen3.5 MoE) con decodificación especulativa block-diffusion — un drafter DFlash v1 que predice un bloque completo de tokens futuros en una sola pasada paralela y es verificado por el modelo objetivo. Sin pérdidas por construcción: la salida greedy es idéntica a correr el modelo grande solo, solo que llegas ahí aproximadamente 30% más rápido en cargas mixtas.

La alternativa densa es un finetune de Qwen3.8-27B, que además tiene un drafter DFlash2 disponible — la segunda generación de la misma idea, con un selector de rutas candidatas que elevó las longitudes de aceptación publicadas por encima de los drafters MTP oficiales.

El contendiente#

DavidAU publicó Qwen3.8-27B-Cold-Fusion-GAIN-V1.1 — un entrenamiento "COLD FUSION" (su método GAIN más los trainers de Unsloth) sobre la misma base Qwen3.8-27B, distribuido como quants imatrix NEO-MAX (el tensor de salida se queda en 16 bits) con una cabeza MTP embebida. La card asegura 99% de la calidad BF16 en 4 bits, y un ARC-C de 0.655 contra 0.591 para el modelo stock.

Las afirmaciones son afirmaciones. La única forma de saber qué hace un modelo en tu hardware, tu runtime y tus cargas de trabajo es medir — así que bajé el archivo MTP Q4_K_M exacto (18.5 GB), verifiqué los metadatos del GGUF (misma arquitectura qwen35 que mi modelo denso, contexto de 256k, tensores MTP presentes) y lo pasé por el mismo harness que uso para todo lo demás.

Ronda 1: velocidad de decodificación#

Mismo binario, mismas flags, misma API de benchmark, mismos ajustes de contexto que cada baseline en esta máquina — la única forma justa de comparar. Todos los números son tokens/segundo a contexto de 64k, KV cache q4_0:

| Prueba | Cold-Fusion | + MTP n3 | + DFlash2 n7 | Qwen3.8-U + DFlash2 | BigBang MoE (prod) | |---|---:|---:|---:|---:|---:| | decode 256 | 28.6 | 46.8 | 64.9 | 57.2 | 99.1 | | decode 512 | 28.5 | 48.6 | 68.3 | 51.1 | 125.6 | | mixto 2k-in/256-out | 27.8 | 39.2 | 37.5 | 39.0 | 164.6 | | prefill 16k | 873 | 819 | 743 | 749 | 1827 |

Tres hallazgos que valen la pena conservar:

1. 65–68 t/s es la decodificación densa de 27B más rápida que he medido en esta GPU. Lo interesante es el porqué: la decodificación especulativa amplifica la verificación barata. El finetune Cold-Fusion apenas dañó el acuerdo con el drafter — la aceptación de DFlash2 se mantuvo en 4.6–5.2 tokens promedio contra un baseline con objetivo coincidente de 4.6–6.7. El drift de finetune, que me costó ~10% de throughput al emparejar un drafter con un finetune distinto de la misma base, aquí es esencialmente inexistente. Y a diferencia del modelo stock, cuya decodificación decae en generaciones largas (57.2 → 51.1 t/s), este se sostiene y hasta mejora (64.9 → 68.3).

2. La decodificación especulativa es demostrablemente sin pérdidas aquí, no solo en teoría. Corrí prompts greedy idénticos por las configuraciones plain, MTP y DFlash2: salidas idénticas byte a byte, mismos conteos de tokens. El drafter nunca cambia lo que dice el modelo — solo la velocidad con la que lo dice.

3. La física sigue ganando. Incluso a 68 t/s, un modelo denso de 27B es ~2x más lento que el MoE de 3.5B activos en la misma tarjeta de 24 GB. Ningún drafter cierra una brecha de 8x en parámetros activos.

Ronda 2: calidad — y qué se puede siquiera medir en GGUF#

Antes de puntuar modelos, tuve que puntuar las suites. En un stack puro de llama.cpp/GGUF hay un muro duro: el servidor no devuelve logprobs de tokens del prompt, que es lo que todo benchmark de opción múltiple necesita (MMLU, ARC, HellaSwag, GPQA — la batería clásica de leaderboards) para el scoring por loglikelihood. Lo que sí funciona, limpio, a través de la API compatible con OpenAI:

• lm-evaluation-harness con tareas generativas: IFEval, GSM8K-CoT, BBH, TruthfulQA-gen
• LiveBench (scoring objetivo, sin modelo juez, resistente a contaminación)
• EvalPlus (HumanEval+/MBPP+ con ejecución sandboxeada)

Pasé ambos modelos por la misma batería — condiciones idénticas: greedy, peticiones en serie, modo de respuesta directa (razonamiento apagado), mismos límites. El resultado:

| Benchmark (n) | Métrica | BigBang MoE | Cold-Fusion + DFlash2 | Δ | |---|---|---:|---:|---:| | GSM8K-CoT 8-shot (150) | exact match | 0.960 | 0.933 | −2.7 | | GSM8K-CoT | strict match | 0.940 | 0.847 | −9.3 | | IFEval (150) | prompt-level strict | 0.773 | 0.673 | −10.0 | | IFEval | instruction-level strict | 0.853 | 0.752 | −10.1 | | BBH boolean expressions (100) | exact match | 0.95 | 0.93 | −2 | | BBH date understanding (100) | exact match | 0.76 | 0.81 | +5 | | BBH web of lies (100) | exact match | 1.00 | 1.00 | 0 |

El MoE de producción gana cinco de siete, empata uno, pierde uno. La brecha en modo estricto de GSM8K es mayormente cumplimiento de formato (el modelo nuevo suele omitir el marcador #### respuesta — su caída de flexible a estricto es de 8.7 puntos contra 2 del MoE), pero la brecha en IFEval es seguimiento de instrucciones real. Y una afirmación del proveedor se invirtió bajo prueba: la eficiencia de "menos tokens de razonamiento" no sobrevivió al modo de respuesta directa, donde el modelo nuevo de hecho escribió 15–32% más que el MoE en prompts idénticos.

Veredicto#

Producción se queda con el MoE. Esta ronda ganó en ambos ejes — aproximadamente 2x el throughput y puntajes más altos en cada suite generativa que puedo correr localmente. El archivo Cold-Fusion se ganó un lugar en el disco de todos modos: es ahora el mejor payload para las ocasiones raras en que cambio el servidor a modo denso-27B, donde su emparejamiento con DFlash2 es genuinamente el estado del arte que he medido en hardware AMD de consumo.

Dos lecciones operativas que valen más que los números del benchmark:

1. Nunca hagas benchmark contra un servicio en vivo. Mi primer intento corrió el eval contra producción; las peticiones concurrentes del eval atascaron un slot de peticiones, el watchdog de salud hizo exactamente su trabajo y reinició el servidor en mitad del eval, y me tocó redescubrir por qué toda medición seria se hace en una ventana aislada con el watchdog aparcado.
2. Verifica la plomería antes de confiar en un puntaje. El mismo modelo puntuó 0.45 y 0.77 en IFEval en la misma sesión — la diferencia fue truncamiento por modo thinking, no inteligencia. Un puntaje bajo de un buen modelo normalmente significa que el harness te está mintiendo.

Todo esto corre sobre tooling de código abierto de extremo a extremo: llama.cpp para servir, los drafters DFlash de z-lab, el harness de EleutherAI para calidad. Esa es la parte que más me gusta — sin facturas de API, sin dashboards de proveedores, solo una GPU, un filesystem y números que puedes reproducir.