Montar un servidor de inferencia con 576 GB de VRAM: diario de puesta en marcha
La mayoría de las fichas de servidor describen la máquina que se encargó. Esta describe la máquina que se construyó — incluidos los dos fallos que tenía al encenderse por primera vez y el que nunca llegamos a explicar del todo.
Configuración: rack 7U · 2× AMD EPYC 7643 (96C/192T) · 512 GB DDR4 ECC · 6× NVIDIA RTX PRO 6000 Blackwell Max-Q, 576 GB GDDR7 · 2 TB + 4 TB NVMe
Montado y puesto en servicio: agosto de 2026, taller de Kentino, Praga · Estado: entregado
Creemos que ese es el artículo más útil. Copiar una lista de componentes puede hacerlo cualquiera.
Qué es
Seis tarjetas RTX PRO 6000 Blackwell Max-Q, de 96 GB cada una, sobre una plataforma EPYC Rome de doble socket con 512 GB de memoria ECC. 576 GB de VRAM en una sola caja, suficiente para alojar un modelo de 753 mil millones de parámetros a 4 bits y aún dejar sitio para un millón de tokens de contexto.
La variante Max-Q marca la diferencia. Con 300 W por tarjeta en lugar de 600, seis de ellas caben dentro de un margen térmico y eléctrico que un taller —y después una sala de servidores— puede ofrecer de verdad. El consumo en pared medido a plena carga fue de ~2.9 kW, alrededor del 80% de un único circuito de 16 A/230 V.
El chasis es de diseño propio, de 7U: dos bloques refrigerados de forma independiente con cuatro bahías de GPU cada uno, de modo que ninguna tarjeta queda en el escape de más de otras tres.
El primer fallo: dos GPU funcionando en silencio a media velocidad
El sistema arrancó, las seis tarjetas se enumeraron y nvidia-smi se veía perfecto.
Dos de ellas funcionaban a PCIe Gen4 x8 en lugar de x16.
Nada informó de ningún error. El controlador estaba conforme, las tarjetas funcionaban, la inferencia se ejecutaba. La única forma de verlo era medir el ancho de banda host-dispositivo de cada tarjeta y darse cuenta de que dos de ellas devolvían 13.9 GB/s donde las demás devolvían 27.7.
La causa era un fallo de capa física en dos conectores del chasis: ni las tarjetas, ni la placa, ni el diseño de los risers. Ambos enlaces se trasladaron a conectores de repuesto y las seis confirmaron entonces Gen4 x16 bajo carga. Los dos conectores sospechosos quedan registrados por su nombre en el expediente de montaje y sin usar durante toda la vida de la máquina.
Una GPU que entrena con la mitad de su ancho de carril no se anuncia. Si su proceso de puesta en servicio no mide el ancho de banda PCIe por tarjeta bajo carga, enviará este fallo sin enterarse nunca.
El segundo fallo: un patrón de ECC que no era la memoria
A mitad de la puesta en servicio, dos DIMM empezaron a registrar errores ECC corregibles . Corregible significa que el hardware los detectó y los corrigió: ninguna pérdida de datos, ninguna respuesta errónea, ningún efecto sobre los resultados. Pero dos módulos que notifican errores son, normalmente, dos módulos que hay que sustituir.
No los sustituimos, y la razón es la parte interesante.
Los eventos estaban separados 4 h 30 m y 4 h 01 m, y cada uno se activó en ambos módulos dentro del mismo segundo. Dos módulos de memoria marginales de forma independiente no fallan a intervalos casi fijos, y desde luego no fallan en el mismo segundo tres veces seguidas. No es el aspecto que tiene un silicio degradándose. Es la firma de algo externo y periódico.
El intervalo coincidía con una carga conmutada de alta potencia en el entorno de puesta en servicio. A continuación ejecutamos unas 20 horas de soak instrumentado bajo carga real sostenida, con telemetría por minuto de las seis GPU, la CPU, la memoria, el disco y el registro de eventos del BMC. Cero eventos ECC.
Así que los módulos se quedaron.
Lo que decimos con cuidado: nunca correlacionamos los eventos con un ciclo registrado de la fuente sospechosa. La atribución es una inferencia, no una prueba. Comunicamos al cliente la observación, el intervalo y la ventana de ensayo, y dijimos con claridad que no es una causa raíz demostrada. Si la causa era ambiental, no viaja con la máquina, y veinte horas de silencio bajo carga son una buena evidencia, no una garantía.
Una nota práctica que nos costó tiempo: esta plataforma usa gestión de errores firmware-first, de modo que los contadores ECC del lado de Linux marcan cero pase lo que pase. El estado de la memoria hay que leerlo en el registro de eventos del BMC. Si monitoriza edac y nada más, no está monitorizando nada.
Lo que hace realmente la máquina
Todas las cifras están medidas en este sistema concreto, no sacadas de una ficha técnica.
Cómputo y consistencia
| Medición | Resultado |
|---|---|
| Matmul denso FP16, por tarjeta | 291–302 TFLOPS (3.5% de dispersión entre las seis) |
| Ancho de banda de VRAM, por tarjeta | ~1,471 GB/s (uniforme hasta el 0.2%) |
| Inferencia con paralelismo de datos a seis vías | 3,859 tok/s · 90.8% de eficiencia de escalado |
| Dispersión por réplica entre las seis GPU | 0.45% |
Esa dispersión de medio punto porcentual entre seis tarjetas es la cifra que más nos importa. Significa que ninguna tarjeta rinde por debajo en silencio, y solo tiene sentido porque antes se encontró el fallo de PCIe.
Inferencia con modelos grandes
GLM-5.2 — 753 mil millones de parámetros (40 B activos), 4 bits, 341 GB residentes en las seis tarjetas:
| Peticiones simultáneas | 1 | 4 | 16 | 32 | 48 |
|---|---|---|---|---|---|
| Generación tok/s | 38.0 | 78.5 | 117–120 | 148.1 | 172.2 |
También carga el contexto nativo de 1,048,576 tokens del modelo en este hardware: 494 GiB de VRAM, dejando 6.6 GiB libres en la tarjeta más justa. Funciona, pero el margen es escaso y así lo dijimos.
Ajustar el micro-lote de prefill (-b/-ub 4096) elevó el procesamiento de prompts de 403 a
606 tok/s, un 50% más con un cambio de una sola línea. La decodificación especulativa aportó
+53% en flujo único pero costó un 6% en trabajo por lotes con prompts largos, así que se habilita por carga de trabajo y no de forma global.
Rodaje (burn-in)
810,033 matmuls en seis GPU al 100% de carga. Cero errores de cálculo. Pico de 88 °C, 300 W sostenidos por tarjeta, sin limitación térmica: clocks_event_reasons marcó
Not Active durante todo el ensayo.
Dónde va justa esta máquina, y lo dijimos
El margen térmico es de ~2 °C. Pico de 88 °C frente a un punto de throttling de ~90 °C, con una temperatura ambiente de 28–33 °C en un taller sin climatizar en agosto. En una sala por debajo de 25 °C hay margen de sobra. En una sala cálida, no. Las cargas reales sostenidas alcanzaron las mismas temperaturas que el rodaje sintético, así que no es una preocupación exclusiva de las pruebas sintéticas.
La palanca evidente es limitar la potencia de la GPU: 260 W en lugar de 300 W. No medimos cuánto cuesta eso en rendimiento en esta máquina, así que no lo recomendamos como si lo hubiéramos hecho. Compruébelo con su propia carga de trabajo.
La pila de software es específica y frágil. GLM-5.2 no funciona bajo vLLM ni SGLang en esta generación de GPU: tres limitaciones upstream distintas. llama.cpp es la vía que funciona. Por otro lado, la instalación de vLLM lleva un parche local que corrige un fallo con concurrencia y modelos cuantizados, y ese parche no sobrevive a pip install -U vllm. Fije las versiones.
Doble socket significa NUMA. El ancho de banda host-dispositivo se reparte por socket: las GPU 0–2 en uno y las 3–5 en el otro, con una penalización aproximada del 20% para los búferes de host asignados en el nodo equivocado. No es un fallo —es física—, pero hay que fijar la afinidad con numactl cuando importa el ancho de banda host↔dispositivo.
Una prueba está realmente incompleta. La etapa final combinada de carga máxima CPU+GPU se interrumpió por un fallo del equipo de distribución eléctrica del taller. Las ~20 horas de ensayo de resistencia con carga mixta cubren el caso real de funcionamiento, así que informamos de la laguna en lugar de reetiquetar discretamente los ensayos de resistencia como la prueba que faltaba.
Por qué publicamos los fallos
Un informe de puesta en servicio que dice que todo pasó no le cuenta nada sobre quienes lo escribieron. Toda máquina de esta complejidad tiene algo mal en el primer encendido. La cuestión es si se encuentra en nuestro banco o en su rack.
En este montaje fueron dos conectores que degradaban a media velocidad una cuarta parte del tejido de GPU, invisibles para todos los indicadores de estado del sistema. Hizo falta medir para encontrarlo y diez minutos para arreglarlo.
Para eso sirve la puesta en servicio.