Motor de inferencia CUDA para ejecutar modelos híbridos Qwen3.5/3.6 en tarjetas de minería (CMP 100-210)

Mientras pensaba si habría una forma barata de correr modelos grandes, encontré la CMP 100-210 y compré 4 tarjetas.
Como cada una tiene 16 GB de HBM2, me pareció una buena opción.

Pero NVIDIA realmente las bloqueó a propósito.

• Los Tensor Cores son 64 veces más lentos (latencia HMMA 8→512 ciclos)
• PCIe Gen1 x1 y sin P2P
• También bloquearon CUPTI, así que ni siquiera se puede usar torch.profiler
• Es un e-fuse grabado en el die, así que tampoco se puede desbloquear por firmware (ya probé de todo)

Por eso no funcionan vLLM, la ruta por defecto de llama.cpp, FA ni bnb.
Todo lo que toca Tensor Cores vía cuBLAS corre a 1/64 de velocidad o se cae.

Me daba pena ver GPUs por valor de 640 mil won rodando por el escritorio, así que escribí mi propio motor de inferencia.

Eligiendo solo rutas que no activan el throttle:

• GEMM con kernel propio DP4A (int8, 17 TFLOP)
• attention con FlashAttention propio + block-sparse estilo MInference
• Entre GPUs, hidden state bridge con pinned-host (porque no hay P2P)
• Contexto de 256K con KV cache de 3 bits (WHT + Lloyd-Max), de 17 GB → 3.5 GB

Por ahora, si es un modelo híbrido Qwen3.5/3.6 (GDN + Attention), funcionan tanto 27B como 9B.
También tiene API compatible con OpenAI, streaming, tool calls, vision (mmproj) y /no_think.

Benchmarks (vs llama.cpp build 8462, mismo GGUF Q8_0, mismo hardware):

• 9B prefill en una sola GPU: 1.22 ~ 2.99x
• 27B prefill en 3 GPU: 1.45 ~ 2.86x
• gen: +30 ~ 50%

Límites honestos:

• No funciona con MoE (solo híbridos densos)
• Si tienes una A100 / H100, usa vLLM. Es mucho más rápido.
• Cosas como DFlash están en el código pero no funcionan (drafter mismatch)
• Solo soporte oficial para Q8_0

Espero que le sirva a quienes están atrapados en un entorno parecido.
Como es un motor hecho por un estudiante de primer año de preparatoria usando Claude, puede tener bastantes bugs y código espagueti.
¡Issues y PR bienvenidos!