Todo el trabajo
estudio de casoIA y Agentes

Plataforma de inferencia GPU autoalojada — MoE de 36B, voz IA y un farm de 70 GPUs

Un stack de IA completamente autoalojado: un modelo MoE de 36B servido de forma concurrente con embeddings, ASR y TTS en una sola GPU de 24 GB — escalado después a un farm de 70 GPUs en 10 nodos que un estado de reloj VBIOS defectuoso casi tumba.

Rol
Ingeniero de plataforma ML
Cronograma
En curso — en producción desde 2024
Stack
ROCm 7.14 / HIP (gfx1100) · llama.cpp · whisper.cpp · qwen3-tts.cpp · VFIO / IOMMU · Proxmox VE · ZFS · Qdrant · FastAPI · systemd · MikroTik RouterOS
Plataforma de inferencia GPU autoalojada — rack del farm y tarjeta aceleradora con overlays HUD
portada del proyectoIA y Agentes

Un sistema en operación diaria para la captura de boletas de basura — esta página incluye la demo en vivo.

Problema

Qué estaba roto

Una sola GPU de 24 GB tenía que servir a la vez un modelo MoE de 36B de parámetros, embeddings vectoriales, voz a texto y texto a voz. Además, el farm se estaba escalando a 70 GPUs en 10 nodos, y una inestabilidad generalizada anulaba el valor de cada tarjeta extra.

Enfoque

Cómo se resolvió

Presupuesté todo el stack contra un único techo de 25.7 GB de VRAM: el MoE de 36B cuantizado a IQ4_XS con caché KV en q4 y contexto de 64K, el ASR whisper-small y el modelo de embeddings anclados a la misma tarjeta, y el TTS al lado — todo medido en 25.3/25.7 GB con cada capa contabilizada. Cuando el farm empezó a fallar, traté el log como un rastro forense: los oops del kernel señalaron tormentas de reset de GPU, lo que llevó a descubrir que un VBIOS modificado ejecutaba la tarjeta a un estado de 3136 MHz que el silicio no podía sostener. Fijé el reloj en 2500 MHz, migré a ROCm 7.14, añadí snapshots de ZFS y reconstruí el stack para que un solo proceso sirva LLM, embeddings, ASR y TTS de forma concurrente. El farm creció a 10 nodos y 70 GPUs a ~10 kW con un delta térmico de +35 °C.

Restricciones

  • 24 GB de VRAM es el techo duro: cada modelo debe caber en una tarjeta o caer en una inferencia CPU lenta.
  • El farm es 100 % autoalojado: cero puertos públicos, todos los servicios se alcanzan a través del router.
  • La inestabilidad debía diagnosticarse a nivel de firmware y hardware, no parchearse con soluciones de software.
Stack

Herramientas del sistema

  • ROCm 7.14 / HIP (gfx1100)
  • llama.cpp
  • whisper.cpp
  • qwen3-tts.cpp
  • VFIO / IOMMU
  • Proxmox VE
  • ZFS
  • Qdrant
  • FastAPI
  • systemd
  • MikroTik RouterOS
Resultado

Qué cambió

Una sola tarjeta de 24 GB sirve ahora un modelo MoE de 36B, embeddings, ASR y TTS a la vez — con hasta 2,426 tok/s de prefill y 87–125 tok/s de decode en un bucle de voz en 10 idiomas. El farm de 70 GPUs funciona estable 24/7 desde la corrección de firmware: la respuesta era un estado de reloj en el VBIOS, no el stack de software.

25.3 / 25.7 GBHuella de VRAM
hasta 2,426 tok/sRendimiento prefill
87–125 tok/sRendimiento decode
70 GPU · 10 nodos · 10 kWFarm
Lecciones

Lo que se queda

  1. 01Cuando un número sale mal — decode a la mitad, caché thrashing — lee los registros del hardware antes que el archivo de configuración: la causa raíz era un estado de reloj VBIOS modificado, no un bug de software.
  2. 02Presupuesta todo el stack contra un único techo: el modelo de 36B, la caché KV, el ASR, el TTS y los embeddings caben en 25.3/25.7 GB porque cada capa se dimensionó contra el mismo presupuesto de VRAM.
  3. 03La estabilidad a escala de fleet es primero una cuestión de firmware y alimentación: fijar el reloj en 2500 MHz logró lo que días de ajustes de software no pudieron.
Todo el trabajo