Nvidia on lo0 — Blog Técnico

Entornos mixtos NVIDIA + Intel para inferencia LLM: del cluster H100 central al NUC en la sucursal

Tue, 02 Jun 2026 04:30:00 +0200

Este post complementa los de Capacity planning para inferencia LLM on-premise (que asumía cluster NVIDIA puro), Siete capas del stack (que tampoco entraba en heterogeneidad de hardware) y El router de inferencia LLM (donde el routing por capability cobra todo su sentido cuando hay hardware mixto). Es la pieza que faltaba para hablar de “soberanía de hardware” sin reducirla a “qué fabricante elegir”.

TL;DR

Un cluster productivo de inferencia LLM en 2026 puede dejar de ser monolítico NVIDIA si acepta heterogeneidad como decisión arquitectónica. La motivación no es teoría sino tres ventajas operativas medibles. (1) Coste: un Intel Xeon 6 con AMX (Advanced Matrix Extensions) entrega 7B INT4 a ~80 tok/s sirviendo embeddings y reranker a una fracción del coste de dedicar una H100 a esa tarea; el capacity planning cierra mejor con Intel CPU manejando lo barato e NVIDIA H100 el LLM grande. (2) Soberanía y diversificación de cadena de suministro: NVIDIA tiene ~94 % del mercado de AI accelerators (noviembre 2025), single-vendor dependency con todos sus riesgos; Intel fabrica en Europa (Leixlip operativa, Magdeburg planeada) frente a NVIDIA design-only con foundry TSMC, lo que para una organización española/europea con exigencia ENS / NIS2 / EU AI Act es un argumento de hedge real. (3) Edge: un Intel NUC con CPU Lunar Lake (NPU 48 TOPS) o Panther Lake (NPU 50 TOPS + Xe3 120 TOPS = 180 TOPS plataforma) corre modelos 7B INT4 a velocidad usable, lo que abre el patrón “sucursal con inferencia local + DC central para casos complejos”. Hardware Intel relevante en junio 2026: Intel Gaudi 3 (128 GB HBM2e, 1835 TFLOPS BF16/FP8, 3.67 TB/s; competidor directo a H100 — Intel reclama +20 % en Llama 2 70B pero Signal65 publicó H200 9× sobre Gaudi 3 en Llama 3.1 405B, hay que citar ambos; Falcon Shores cancelado enero 2025, Jaguar Shores 2026 como apuesta de reinicio, Gaudi 4 confirmado que no existirá); Intel Xeon 6 con AMX (hasta 288 cores E-core en Sierra Forest o 86 P-core en Granite Rapids, 1024 FLOPS BF16/ciclo/core con AMX, Intel reclama 2.7× tok/s vs EPYC 9965 en vLLM CPU backend); Intel Arc Pro B60 (Battlemage, 24 GB GDDR6, 456 GB/s, 197 TOPS INT8, lanzado septiembre 2025 — variante dual-GPU 48 GB y rack “Battlematrix” con 8× = 192 GB VRAM); Intel NUC con NPU (Lunar Lake 48 TOPS, Arrow Lake similar, Panther Lake 50 TOPS CES 2026; realista para 7-13B INT4, no para los 30-70B que Intel afirma en su marketing). Software: OpenVINO 2025.3 con GenAI API y vLLM-OpenVINO; IPEX-LLM con integraciones a llama.cpp, vLLM, HF, LangChain; vLLM CPU backend con AMX; llama.cpp SYCL (mejor que Vulkan en Arc). Cuatro patrones canónicos: embeddings + reranker en Intel al lado del LLM en NVIDIA; guardrails + PII redact en NUC near edge; speculative drafter en NUC cerca del usuario y target en H100; dev workstations NUC. Observabilidad unificada vía DCGM + habana-metric-exporter + intel-gpu-exporter + Intel PCM federados en Prometheus. Pitfalls: tokenizer mismatch entre engines, latencia round-trip edge↔central, FP8 Hopper ≠ INT8 AMX en calidad, sincronización de versiones. Aplicado a un cluster genérico: DC central 4×H100 SXM + sidecar Xeon 6 AMX + 6-12 NUCs Intel en sucursales. Disclaimer crítico: a junio 2026 no hay casos públicos verificables de despliegue mixto NVIDIA + Intel en banca o gobierno europeo; el patrón es arquitectura emergente y recomendable, no práctica establecida con histórico industrial.

Estás aquí: DEPLOY (con heterogeneidad como decisión)

La analogía: la fábrica con varias máquinas distintas

Una fábrica seria tiene varias máquinas con propósitos distintos, no una sola máquina universal. Una prensa hidráulica de 200 toneladas para troquelado pesado; un torno de banco para piezas de revolución; una impresora 3D para prototipos rápidos; un robot de pick-and-place para SMD. Cada máquina hace lo que hace mejor que las demás en su nicho, y el gerente de planta dimensiona el mix según el portfolio real de productos, no según moda. Comprar tres prensas hidráulicas porque “son las más impresionantes” cuando el 60 % del trabajo son piezas de revolución es derrochar capital — el torno es más barato, más rápido para su nicho y libera la prensa para lo que de verdad la necesita.

Un cluster de inferencia LLM con NVIDIA H100 dedicada a hacer embeddings de un corpus RAG está usando una prensa hidráulica para taladrar pernos. La H100 es magnífica para LLM 70B en BF16 con concurrencia 40+; para embeddings de un documento de 800 tokens en bge-m3, lo que necesitas es un Intel Xeon 6 con AMX a una fracción del coste y consumo eléctrico. Un cluster que quiera servir guardrails ligeros (Llama Guard 4 8B) en cada request, con presupuesto de 50 ms, tampoco necesita ese guardrail en una H100 — un Intel NUC con NPU 48 TOPS cubre el caso con margen.

La fábrica heterogénea no es elegancia teórica: es maximizar utilización útil del capital fijo. El cluster heterogéneo de inferencia LLM tampoco lo es.

Tres razones operativas para la heterogeneidad

Razón 1 — coste

Una H100 SXM 80 GB en operación 24/7 consume ~700 W (medición real al wall ~697 W con vLLM Llama 3.1 405B batch=4) y representa entre 25 000 € y 35 000 € de hardware amortizado. Un Intel Xeon 6 con AMX (Granite Rapids 86 cores o Sierra Forest 288 cores E) consume 350-500 W para el socket y cuesta una fracción. La operativa: la H100 está reservada para el LLM grande (Llama 70B BF16 o FP8, donde su HBM3 y FP8 tensor cores valen su peso); el Xeon AMX absorbe embeddings (bge-m3, e5-large), reranker (bge-reranker-v2-m3), modelos pequeños (Llama 3.2 1B / 3B INT4) y batch processing offline. Es la misma lógica del capacity planning llevada un paso más allá: en vez de presupuestar VRAM de KV cache solo en H100, presupuestar cada workload en el silicio donde su arithmetic intensity case mejor.

Razón 2 — soberanía y diversificación de la cadena de suministro

A noviembre 2025, NVIDIA tiene aproximadamente 94 % del mercado de AI accelerators. Esa concentración es riesgo. Para una organización con exigencia ENS / NIS2 / EU AI Act, depender de un único proveedor con foundry concentrada en Taiwán (TSMC) introduce vulnerabilidades de cadena de suministro que regulaciones recientes (NIS2, supply chain provisions) están empezando a exigir documentar y mitigar. Intel diversifica: tiene fabs propias en Europa (Leixlip operativa en Irlanda; Magdeburg planeada en Alemania, con financiación EU Chips Act), lo que para un cliente público español o europeo es argumento contractual real, no marketing.

Disclaimer obligatorio: el roadmap Intel post-Falcon Shores es inestable. Intel canceló Falcon Shores en enero 2025 y relegó Gaudi 4 a “no existirá”; la apuesta de re-arranque es Jaguar Shores en 2026 como plataforma rack-scale, todavía sin specs públicas confirmadas. La diversificación es estratégicamente correcta, pero asumir continuidad de roadmap Intel al nivel del de NVIDIA en 2026 sería ingenuo. La estrategia operativa: Intel para cargas donde el lock-in es menor (CPU para embeddings, NUC para edge ligero — sustituibles por AMD/Apple/SiFive si Intel pivot otra vez), NVIDIA para el LLM grande donde la madurez del software stack todavía no tiene rival.

Razón 3 — edge

El patrón de “todo viaja al DC central” rompe en tres casos: latencia (sucursal a 100+ ms del DC, inaceptable para chat), soberanía de datos (prompts con datos personales / clasificados que no deben salir del perímetro local), y operación offline (sucursal con conectividad intermitente). El Intel NUC con CPU moderna (Lunar Lake / Arrow Lake / Panther Lake) trae NPU 48-50 TOPS + iGPU Xe2/Xe3 100-180 TOPS en un equipo de 0.5-1.5 L de volumen y 30-65 W de consumo. Modelos 7B INT4 corren a velocidad usable; con quantization más agresiva (Q3_K) cabe Llama 13B. Para sucursales con RAG sobre corpus local + LLM 7B + guardrails, el NUC es perfecto.

Hardware Intel relevante (junio 2026)

Pieza	Memoria	Performance clave	Lanzamiento	Estado
Intel Gaudi 3	128 GB HBM2e, 3.67 TB/s	1835 TFLOPS BF16/FP8; 1200 GB/s networking	abr-2024	Activo; sucesor Jaguar Shores 2026 (no Gaudi 4)
Intel Xeon 6 (Granite Rapids)	DDR5 + MRDIMM	86 P-cores, AMX 1024 FLOPS BF16/ciclo/core	2024-2025	Activo
Intel Xeon 6 (Sierra Forest)	DDR5	288 E-cores	2024	Activo
Intel Arc Pro B60 (Battlemage)	24 GB GDDR6, 456 GB/s	197 TOPS INT8; 12.28 TFLOPS FP32	sep-2025	Activo; variante dual 48 GB, rack 8× = 192 GB
Intel Data Center GPU Max	128 GB HBM	sucesor de Ponte Vecchio	descontinuado	Descontinuado ene-2026
Intel NUC (Lunar Lake)	DDR5x	NPU 48 TOPS + Xe2 67 TOPS = 120 TOPS plataforma	2024	Activo
Intel NUC (Arrow Lake)	DDR5	NPU 13 TOPS + Xe iGPU	2024	Activo (menos NPU que Lunar)
Intel NUC (Panther Lake)	DDR5x	NPU 50 TOPS + Xe3 120 TOPS = 180 TOPS plataforma	CES ene-2026	En despliegue

Intel Gaudi 3 — la nota crítica sobre el marketing

Intel publica que Gaudi 3 entrega +20 % throughput vs H100 en Llama 2 70B inferencia y 2× price/performance. La cifra aparece en whitepaper oficial y en presentaciones de lanzamiento. Sin embargo, Signal65 (firma independiente) publicó en 2025 que H200 supera a Gaudi 3 por factor 9× en Llama 3.1 405B. La discrepancia es relevante: ambos números pueden ser ciertos para sus benchmarks específicos (Llama 2 70B FP16 vs Llama 3.1 405B FP8) pero la conclusión operativa cambia radicalmente según con cuál te quedes.

Recomendación de este post: tratar Gaudi 3 como opción válida para Llama-class 70B en BF16/FP8 donde Intel reclama paridad o ventaja, no para modelos de frontera 200B+ donde NVIDIA mantiene márgen claro. Y considerar el riesgo de roadmap: Gaudi 4 no existirá; el sucesor de la línea es Jaguar Shores 2026 con arquitectura rack-scale completamente nueva — discontinuidad, no evolución.

Intel Xeon 6 con AMX — el caballo de batalla CPU

Las Advanced Matrix Extensions (AMX) son la pieza no obvia. Cada core P-core de Granite Rapids ejecuta hasta 1024 FLOPS BF16 por ciclo vía AMX, lo que convierte un Xeon 6 con 64-86 cores en un acelerador de matriz respetable para modelos pequeños/medianos. Cifras reales reportadas: Llama 3.2 INT4 a ~57 tok/s con AMX vs 28 tok/s sin AMX (factor 2× clean). En servir 7B INT4 con vLLM CPU backend + AMX, Intel reclama 2.7× tok/s vs EPYC 9965, cifra con sesgo de Intel pero corroborada cualitativamente por LMSYS en su despliegue DeepSeek R1 671B sobre Xeon 6 + SGLang.

Caso de uso operativo: embeddings y reranker en un sidecar Xeon 6 al lado del cluster H100. Modelos como bge-m3 (embedding multilingüe) o bge-reranker-v2-m3 corren a throughput aceptable en CPU AMX; no merecen H100 dedicada. Liberar la H100 para el LLM 70B aumenta el RPS efectivo del cluster sin comprar más GPUs.

Intel Arc Pro B60 y Battlematrix

Lanzada en septiembre 2025, la Arc Pro B60 (Battlemage) trae 24 GB GDDR6 con 456 GB/s de bandwidth y 197 TOPS INT8 a 200 W. Variante de Maxsun con dual-GPU 48 GB. La configuración rack “Battlematrix” combina 8 unidades = 192 GB VRAM agregada — el punto interesante: a un coste muy inferior a una H100 SXM 80 GB, lo que la hace candidata para LLM 30-70B INT4-INT8 servidos vía OpenVINO o llama.cpp SYCL.

Phoronix verificó que en SYCL la Arc Pro B70 alcanza paridad con Radeon PRO W7900 (generación anterior AMD) en DeepSeek R1 Llama 8B pp512. Vulkan backend pierde fuerte (~1/4 del rendimiento de SYCL); para Arc Pro siempre SYCL.

Intel NUC con NPU — el edge node

Los Intel NUC con CPU Lunar Lake (Core Ultra Series 2) traen NPU 4 con 48 TOPS y total plataforma 120 TOPS sumando iGPU Xe2 y CPU AVX. Panther Lake (CES enero 2026) sube a NPU 5 = 50 TOPS + Xe3 120 TOPS = 180 TOPS plataforma.

Intel afirma que Panther Lake “ejecuta modelos 30-70B locales”. Comprobación realista: es marketing. El 30-70B INT4 cabe en RAM (DDR5x 32-64 GB) pero la velocidad sostenida con quant Q4_K_M en un NUC ronda 2-8 tok/s; cómodo para uso ocasional, no para servir tráfico. El sweet spot real del NUC es 7B INT4 a 20-40 tok/s sobre iGPU/NPU, perfecto para sucursal de cliente con consultas casuales.

Software Intel — la pila relevante

OpenVINO 2025.3 (junio 2026) es la pieza central. Soporta deploy con un comando vía OVMS CLI con descarga automática desde HF Hub; integra OpenVINO GenAI con API C++/Python para pipelines generativas; expone API compatible con vLLM v1 (vLLM-OpenVINO). Soporte de modelos GGUF: DeepSeek Distill, Qwen 2/2.5, Llama 3. Optimizaciones: Sage Attention (primer token con prompts largos), KV-cache compression por canal.

Intel Extension for PyTorch (IPEX) — versión XPU 2.8.10+xpu — añade backends Intel a PyTorch. IPEX-LLM es el subproyecto que integra con llama.cpp, Ollama, HuggingFace, LangChain, LlamaIndex, vLLM y DeepSpeed. Mayo 2025: corrió DeepSeek V3/R1 671B y Qwen3MoE 235B en 1-2 Arc A770/B580 con FlashMoE.

vLLM CPU backend — el branch CPU de vLLM con optimizaciones AMX. Para 7B INT4 en Xeon 4ª gen con AMX: 12-50 tok/s; con Xeon Gold 6530 + INT4: ~80 tok/s. Cifras académicas (arXiv 2410.04466).

llama.cpp SYCL — el backend recomendado para Arc; Vulkan funciona pero ronda 1/4 del rendimiento SYCL en Arc B580. SYCL alcanza paridad con AMD generación anterior.

Habana SynapseAI — stack de Gaudi 3. PyTorch bridge habana_frameworks.torch registra device hpu; integración con torch.compile. No es port completo a oneAPI sino integración parcial via oneMKL. Implica que el ecosistema Gaudi mantiene cierta separación del oneAPI general de Intel — relevante de cara al hipotético Jaguar Shores y unificación futura.

Los cuatro patrones canónicos

Patrón 1 — embeddings + reranker en Intel

El más maduro y el más fácil de adoptar. En un sistema RAG típico, cada request del usuario invoca:

Embedding del query (50 ms en H100, 80 ms en Xeon AMX, 30 ms en Arc Pro B60).
Búsqueda vectorial (Qdrant / Milvus / Chroma; latencia ~10-30 ms).
Reranker sobre top-k candidatos (60 ms en H100, 100-150 ms en Xeon AMX).
LLM sobre prompt aumentado (200-500 ms TTFT, 30-50 ms/token).

Los pasos 1 y 3 son memory-bound + relativamente pequeños (modelos 100M-1B): Xeon 6 con AMX (Arc Pro B60 más rápida pero ya GPU dedicada) hace el trabajo a un coste de hardware una fracción del de una H100 dedicada. El paso 4 sigue en NVIDIA porque ahí es donde su arquitectura tensor + HBM3 + FP8 vale lo que cuesta.

Implicación operativa: un Xeon 6 sidecar (~40 cores, ~10-15 k€) sirviendo embeddings + reranker libera el equivalente de 1-2 H100 de carga “barata”, recuperando esa capacidad para el LLM grande. ROI en sizing claro.

Patrón 2 — guardrails + PII redact en NUC near edge

Una sucursal bancaria, un consultorio médico o una oficina jurídica genera prompts con datos personales o clasificados. Mandar esos prompts al DC central (aunque sea on-premise corporativo) puede chocar con políticas de retención local o con compliance específico (GDPR, secreto profesional).

Patrón: el NUC en la sucursal ejecuta dos pasos críticos antes del round-trip:

PII redact con Presidio (CPU-only, rápido) o Llama Guard 4 8B en NPU + iGPU del NUC. Reemplaza nombres, NIFs, números de cuenta por placeholders.
Guardrails ligeros (PromptGuard 2 86M, Llama Guard 4 8B) en NPU + iGPU. Filtra prompt injection, jailbreak, contenido prohibido.

Solo después, el prompt redacted viaja al DC central para que el LLM grande responda. La respuesta se devuelve al NUC, que re-hidrata los placeholders con los valores reales antes de mostrarla al usuario. Los datos sensibles nunca abandonan la sucursal.

Costes: NUC Panther Lake ~1500-2500 €/unidad, escalable a docenas de sucursales sin coste de GPU central adicional. Latencia: 50-150 ms del paso edge antes del round-trip de 200-500 ms del DC.

Patrón 3 — speculative decoding drafter en NUC

Speculative decoding usa un drafter pequeño que propone γ tokens y un target grande que los acepta/rechaza en un único forward pass. Si el drafter está geográficamente cerca del usuario (NUC en sucursal) y el target en el DC central, la latencia percibida del cliente cae aún más.

Setup: drafter Llama 3.2 1B INT4 en NUC + target Llama 3.1 70B FP8 en H100 central. El NUC genera γ=4 tokens en ~50 ms locales; el target los verifica en una pasada (40-80 ms incluyendo round-trip); si tasa de aceptación > 60 %, TTFT efectivo cae ~50 % vs Llama 70B sin speculative.

Restricción importante: drafter y target deben compartir tokenizer. Llama 3.2 1B y Llama 3.1 70B tienen tokenizer compatible. Mezclar Llama drafter con Qwen target rompe el patrón.

Patrón 4 — dev workstations NUC

El dev / CI iterando sobre prompts, evals, retrieval logic, no necesita GPU productiva para validar correctness. Un NUC con Llama 3.2 3B INT4 corre los tests funcionales end-to-end (incluyendo embeddings + retrieval + LLM + guardrails) en una décima parte del coste de iterar sobre una H100. Solo el último smoke test pre-prod usa el cluster productivo.

Patrón maduro en organizaciones con muchos desarrolladores y GPU productiva escasa. La iteración 10× más rápida y barata se traduce en velocidad de feature delivery.

Observabilidad unificada en cluster heterogéneo

El post de observabilidad GPU cubría DCGM Exporter para NVIDIA. En cluster mixto hace falta más:

Pieza hardware	Exporter	Métricas clave
NVIDIA H100/A100	`nvidia/dcgm-exporter`	DCGM_FI_DEV_* + DCGM_FI_PROF_*
Intel Gaudi 3	`HabanaAI/habana-metric-exporter`	habana_hpu_utilization, habana_hbm_used
Intel Arc Pro	`intel/intel-gpu-exporter` (no oficial; existen alternativas)	xe_engine_utilization, xe_memory_used
Intel Xeon CPU + AMX	`prometheus/node-exporter` + Intel PCM	cpu_amx_utilization (vía PCM)
Intel NUC (NPU+iGPU)	`intel/intel-gpu-exporter` + custom NPU exporter	npu_utilization, xe_iGPU

Todos federados en un único Prometheus + Grafana. Las dashboards se organizan por familia de hardware (NVIDIA, Intel server, Intel edge) más una vista agregada “cluster heterogéneo” con SLO por tenant que combina los cuatro.

Cardinalidad: ~1.5-2× la del cluster NVIDIA puro. Manejable con Thanos / Mimir para retención larga.

Routing por capability — del router L7 al heterogéneo

El router de inferencia LLM deja de ser un selector de versiones del mismo modelo para convertirse en un dispatcher por capability:

models:
 - name: "llama-70b-chat"
 endpoint: "vllm-llama70b.inference.svc:8000"
 backend: nvidia-h100
 capabilities: [chat, tool_use, json_mode]
 - name: "embedding-multilingual"
 endpoint: "ipex-bge-m3.inference.svc:8080"
 backend: intel-xeon-amx
 capabilities: [embeddings]
 - name: "reranker-multilingual"
 endpoint: "ipex-bge-reranker.inference.svc:8080"
 backend: intel-xeon-amx
 capabilities: [reranking]
 - name: "guardrail-prompt-injection"
 endpoint: "openvino-llama-guard.edge-suc01.local:8080"
 backend: intel-nuc-edge
 capabilities: [guardrails, redact-pii]
 region: sucursal-01
 - name: "llama-3b-draft"
 endpoint: "openvino-llama-3b.edge-suc01.local:8080"
 backend: intel-nuc-edge
 capabilities: [speculative-drafter]
 region: sucursal-01
 target_model: "llama-70b-chat"

El router resuelve model=embedding-multilingual → Intel Xeon; model=llama-70b-chat → H100; model=guardrail-prompt-injection con region=sucursal-01 → NUC local. Si el NUC de la sucursal cae, failover a una réplica equivalente en el DC central, asumiendo el coste de latencia.

LiteLLM Proxy, NVIDIA Dynamo y Envoy AI Gateway soportan este routing por capability. La pieza no obvia: el router debe conocer el tokenizer compatible entre drafter y target para el patrón 3, lo que se modela en metadata adicional del catálogo.

Pitfalls específicos

Tokenizer mismatch entre engines. OpenVINO con un GGUF de Llama 3.2 y vLLM con el mismo Llama 3.2 nominal pueden usar tokenizers ligeramente distintos (chat template, special tokens). Validar identidad de tokens con tokenizer.encode("hola") en ambos lados antes de asumir intercambiabilidad. Para speculative decoding, un solo token diferente rompe el patrón.

Latencia round-trip edge ↔ central. El patrón 2 y 3 asumen que el NUC y el DC están en la misma WAN corporativa con latencia controlada. Si la sucursal está sobre 4G/5G con jitter de 100-200 ms, el speculative drafter no compensa nada — al revés, añade latencia. Medir antes de prometer.

FP8 Hopper ≠ INT8 AMX en calidad de salida. El operador asume que una request que en H100 corre FP8 y en Xeon AMX corre INT8 producirá la misma salida. No es cierto: las dos quantizaciones tienen perfiles de degradación distintos. Si el sistema espera idempotencia (e.g., evals con golden output), validar offline que la versión Intel reproduce el comportamiento esperado dentro de tolerancia.

Sincronización de versiones de modelo entre sitios. El modelo en el DC central se actualiza, pero los NUCs de las sucursales mantienen la versión vieja del drafter o del guardrail durante semanas. Resultado: comportamiento divergente entre sucursales sin diagnóstico fácil. Política: modelo central y modelo edge avanzan juntos o con ventana documentada; el canary se extiende a la flota de NUCs.

Roadmap Intel inestable. Falcon Shores cancelado, Gaudi 4 no existirá, Jaguar Shores 2026 todavía sin specs públicas confirmadas. Comprar Gaudi 3 hoy es razonable si el caso de uso justifica los 18-24 meses de amortización; comprometer arquitectura a 5+ años sobre Intel accelerator es apuesta más arriesgada que la equivalente NVIDIA — al menos hasta que Jaguar Shores se materialice con software stack maduro.

Vacío de despliegues productivos públicos. A junio 2026, los despliegues Gaudi 3 confirmados son IBM Cloud, Dell AI Factory y un puñado de early adopters (Bharti Airtel, Bosch, Naver). No hay caso público verificable de cluster mixto NVIDIA + Intel en banca o gobierno europeo. Este patrón es arquitectura emergente recomendada, no práctica con histórico industrial. El primer adoptante asume coste de validación que un segundo adoptante evita.

Aplicado a un cluster on-premise genérico

Para una organización con un cluster genérico de inferencia LLM heterogéneo:

DC central: 4 nodos × 4×H100 SXM 80 GB con NVLink intra-nodo = 16 H100. Sirve LLM grandes (Llama 70B, Mixtral 8×22B, Qwen 72B) en BF16 o FP8.
Sidecar Xeon 6: 2-4 servidores Xeon 6 (Granite Rapids 64-86 cores) con AMX, 512 GB DDR5, en el mismo rack que el cluster H100. Sirve embeddings (bge-m3), reranker (bge-reranker-v2-m3), modelos pequeños (Llama 3.2 1B/3B) en vLLM CPU backend con AMX.
Sidecar Arc Pro (opcional): 1-2 servidores con 4-8× Arc Pro B60 24 GB cada uno (Battlematrix), para modelos 13-30B INT8 vía OpenVINO. Útil si el coste por LLM mediano debe bajar de la H100.
NUCs edge en sucursales: 1-2 NUCs Panther Lake por sucursal, con NPU 50 TOPS + Xe3 120 TOPS, sirviendo Llama Guard 4 + Presidio + drafter Llama 3.2 1B INT4 vía OpenVINO. Conectividad WAN corporativa con latencia < 80 ms hacia el DC.

Volumen estimado: cluster central ~120 kW de pico GPU + ~10-15 kW de sidecars Intel. Edge: ~50 W por NUC, despreciable comparado con coste de oficinas.

Observabilidad: Prometheus federado en el DC + scrape pull desde los NUCs (vía VPN corporativa). Dashboards “GPU NVIDIA fleet”, “Intel server fleet”, “Intel edge fleet” más una vista “SLO consolidado”.

Router: LiteLLM Proxy o NVIDIA Dynamo en el DC, con catálogo de modelos extendido para incluir backends Intel y regiones (sucursal-01, sucursal-02, …). Failover edge→central documentado.

Lo que no hemos cubierto (próximos posts)

Benchmarks reproducibles de Llama 70B en Gaudi 3 vs H100 SXM en hardware equivalente — el material que falta para tomar decisiones con datos propios, no de Intel ni de Signal65.
AMD ROCm en el mix: cómo entran MI300X / MI355X en este patrón heterogéneo y qué cambia el catálogo del router.
Apple Silicon como edge: M3/M4 Max con Neural Engine ~38 TOPS + GPU 40-core, hardware equivalente al NUC Panther Lake pero con software stack distinto (MLX).
Optimización de coste energético: cómo nvidia-smi -pl 500W + Intel TDP cap en Xeon 6 reduce factura un 25-30 % con 15-20 % de pérdida de throughput.
CI/CD de modelos para flota edge: cómo el rolling update de un Llama Guard llega a 50 NUCs de sucursales sin que ninguna pierda servicio.

Ver también

Capacity planning para inferencia LLM on-premise — el sizing que esta heterogeneidad permite optimizar tarea por tarea, no para todo en H100.
Siete capas del stack de inferencia LLM on-premise — las siete capas aplican igual sobre hardware heterogéneo; los backends son intercambiables si el contrato OpenAI-compatible se respeta.
El router de inferencia LLM — el router por capability es la pieza central del patrón heterogéneo.
Observabilidad GPU para inferencia LLM — extiende a Gaudi, Arc, Xeon AMX y NPU edge.
Quantization para inferencia LLM — FP8 Hopper, INT8 AMX, INT4 GGUF — la base de por qué los hardware mixtos exigen validación cruzada.
Speculative decoding — el patrón 3 del post; cómo el drafter near edge cierra latencia.
Guardrails y safety en LLMs y LLM Guard — los modelos que viven en el NUC del patrón 2.
Catálogo OSS para LLMOps — fichas de OpenVINO, IPEX-LLM, vLLM CPU backend.
OSS vs hyperscalers — el análisis paralelo de lock-in que sostiene el argumento de diversificación.

Referencias

Intel Gaudi 3

Intel — Gaudi 3 AI Accelerator White Paper. https://cdrdv2-public.intel.com/817486/gaudi-3-ai-accelerator-white-paper.pdf
Intel — Hot Chips 2024 Gaudi 3 deep dive. https://hc2024.hotchips.org/assets/program/conference/day1/60_HC2024.Intel.RomanKaplan.Gaudi3-0826.pdf
Signal65 / DataCenterDynamics — NVIDIA H200 outperforms Intel Gaudi 3 by factor of 9× across first Llama 3.1 405B benchmark test. https://www.datacenterdynamics.com/en/news/nvidia-h200-outperforms-intel-gaudi-3-by-factor-of-nine-across-first-llama-31-405b-benchmark-test-exclusive/
IEEE Spectrum — Intel Gaudi 3 review. https://spectrum.ieee.org/intel-gaudi-3
Tom’s Hardware — Intel cancels Falcon Shores GPU; Jaguar Shores to be successor. https://www.tomshardware.com/tech-industry/artificial-intelligence/intel-cancels-falcon-shores-gpu-for-ai-workloads-jaguar-shores-to-be-successor

Intel Xeon 6 + AMX

Intel — Xeon 6 (Granite Rapids) Product Brief. https://www.intel.com/content/dam/www/central-libraries/us/en/documents/2025-02/xeon-6-granite-rapids-product-brief.pdf
OpenMetal — Intel AMX AI Inference Performance. https://openmetal.io/resources/blog/intel-amx-ai-inference-performance/
LMSYS — Intel Xeon 6 + SGLang for DeepSeek R1 671B. https://www.lmsys.org/blog/2025-07-14-intel-xeon-optimization/
arXiv 2410.04466 — CPU-LLM benchmarks with AMX.
Intel community blog — Accelerating vLLM Inference on Intel Xeon 6 Processor.

Intel Arc Pro Battlemage

Intel — Arc Pro B60 Graphics Specifications. https://www.intel.com/content/www/us/en/products/sku/243916/intel-arc-pro-b60-graphics/specifications.html
StorageReview — Intel Arc Pro B60 Battlematrix Preview: 192GB VRAM for On-Premise AI. https://www.storagereview.com/review/intel-arc-pro-b60-battlematrix-preview-192gb-of-vram-for-on-premise-ai
Phoronix — Intel Arc Pro B-series review. https://www.phoronix.com/review/intel-arc-pro-b-series

Intel NUC / NPU

HotHardware — Intel CES 2026 Panther Lake is a Go. https://hothardware.com/news/intel-ces-2026-panther-lake-is-a-go
TechPowerUp — Intel Panther Lake Technical Deep Dive.
arXiv 2412.11053 — NITRO: LLM inference on laptop NPU.
Intel — AI PC brings larger LLM development to your desk.

Software

OpenVINO — Release Notes 2025.3. https://www.intel.com/content/www/us/en/developer/articles/release-notes/openvino/2025-3.html
HuggingFace — Deploy with OpenVINO. https://huggingface.co/blog/deploy-with-openvino
Intel — Intel Extension for PyTorch XPU 2.8.10. https://intel.github.io/intel-extension-for-pytorch/xpu/latest/tutorials/releases.html
IPEX-LLM — github.com/intel/ipex-llm.
Habana — SynapseAI PyTorch Theory of Operations. https://docs.habana.ai/en/latest/PyTorch/PyTorch_Gaudi_Theory_of_Operations.html

Market context

MLCommons — MLPerf Inference v6.0 benchmark results. https://www.spheron.network/blog/mlperf-inference-v6-benchmark-results-2026/
Intel newsroom — Gaudi 3 Expanded Availability. https://newsroom.intel.com/artificial-intelligence/intel-gaudi-3-expands-availability-drive-ai-innovation-scale

Sources: las URLs completas están enlazadas en línea sobre cada referencia.

Observabilidad GPU para inferencia LLM: las doce métricas DCGM y vLLM que dictan la salud de tu producción

Mon, 01 Jun 2026 15:30:00 +0200

Este post complementa los de Tracing LLM con OpenTelemetry GenAI (la capa de tracing por encima de las métricas), Capacity planning (qué se dimensionó y qué se debe vigilar) y Continuous batching (el mecanismo que explica varias de las métricas del motor).

TL;DR

La observabilidad de un cluster de inferencia LLM se construye sobre dos fuentes complementarias: las métricas del hardware GPU expuestas por DCGM (Data Center GPU Manager) Exporter —parte del NVIDIA GPU Operator— y las métricas del motor de inferencia (vLLM, SGLang, TensorRT-LLM) expuestas en /metrics Prometheus-compatibles. Ninguna de las dos basta sola. La métrica clásica de nvidia-smi llamada GPU utilization es engañosa para LLMs: marca alto cuando hay cualquier kernel ejecutándose, sin distinguir tensor cores ardiendo de SMs esperando por HBM. La cabina de pilotaje completa tiene doce métricas DCGM en cuatro familias (compute: DCGM_FI_PROF_SM_OCCUPANCY, DCGM_FI_PROF_PIPE_TENSOR_ACTIVE, DCGM_FI_PROF_DRAM_ACTIVE; memoria: DCGM_FI_DEV_FB_USED, DCGM_FI_DEV_FB_FREE, DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL; térmico-energético: DCGM_FI_DEV_GPU_TEMP, DCGM_FI_DEV_POWER_USAGE, DCGM_FI_DEV_CLOCK_THROTTLE_REASONS; salud: DCGM_FI_DEV_XID_ERRORS, DCGM_FI_DEV_ECC_DBE_VOL_TOTAL, DCGM_FI_DEV_RETIRED_DBE) y cinco métricas del motor vLLM (vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds). Cada una tiene un umbral verde/ámbar/rojo defendible, una PromQL para alerta, y al menos una falsa lectura habitual que confunde al operador junior. Las seis alertas críticas que cualquier cluster productivo debe disparar son: HBM > 92 %, throttle por térmico o por power, XID error, ECC double-bit, KV cache pool > 95 %, y TTFT P95 fuera de SLO durante 5 minutos. El objetivo de tener este panel: que el operador de turno diagnostique el origen de una degradación en menos de cinco minutos, sin abrir consola SSH a las GPUs. Cuando esto se cumple, el cluster ha pasado a operación profesional; mientras no, se opera por intuición.

Estás aquí: OBSERVE (la otra mitad del tracing)

El tracing —ya cubierto en Tracing LLM con OpenTelemetry GenAI— responde qué pasó en esta request concreta. Las métricas responden qué está pasando en el cluster en agregado. Son complementarias: una alerta del lado de métricas te dice “el clúster está degradando”, el tracing te dice “y esta es la traza concreta que te lo demuestra”. Un cluster sin tracing pero con métricas opera; un cluster sin métricas pero con tracing no opera, debuggea.

La analogía: la cabina de un avión moderno

En un avión comercial moderno, el panel de instrumentos del piloto tiene más de 70 indicadores activos. Si solo hubiese uno —el altímetro, por ejemplo— el avión volaría hacia el suelo en el primer momento de baja visibilidad. Hace falta el altímetro y el indicador de actitud, y el de velocidad, y el de viraje, y el de combustible, y los de presión de aceite de cada motor, y las temperaturas de salida de turbina. Cada uno responde una pregunta distinta. Y todos juntos cubren la pregunta operacional: ¿está el avión sano, está donde debe, y va donde queremos?

La observabilidad de un cluster de inferencia LLM funciona igual. Una sola métrica —“GPU utilization 99 %"— no responde nada útil. Es como mirar solo el cuentakilómetros del coche para diagnosticar por qué hace ruido el motor. La cabina completa es doce instrumentos del lado de hardware más cinco del lado del motor de inferencia, organizados en familias que responden preguntas distintas:

Compute y eficiencia: ¿están los tensor cores haciendo el trabajo que esperamos o están esperando?
Memoria: ¿queda VRAM para nuevas requests o estamos al borde del OOM?
Térmico y energético: ¿el hardware está sano o está limitando el throughput silenciosamente?
Salud y errores: ¿hay degradación del hardware en curso (ECC, XID, NVLink)?
Motor de inferencia: ¿la cola crece, el KV pool está saturado, el SLO se está cumpliendo?

Las cuatro primeras responden a “¿la GPU está bien?”. La quinta responde a “¿está dando el servicio que prometimos?”. Las dos preguntas son distintas y ambas deben tener respuesta a un golpe de vista.

Por qué `nvidia-smi` `GPU-Util` engaña en LLMs

La métrica clásica que aparece en nvidia-smi como GPU-Util corresponde a DCGM_FI_DEV_GPU_UTIL. Su definición oficial: “porcentaje del tiempo durante el cual uno o más kernels estuvieron ejecutándose en la GPU”. El problema en LLMs: la fase de decode es memory-bound, no compute-bound. Cuando el motor de inferencia hace decode token a token, la GPU pasa el 90 % del tiempo esperando que la HBM termine de entregar los pesos del modelo y el KV cache. Hay un kernel corriendo (lectura de HBM); por tanto GPU-Util reporta valores cercanos al 100 %. Pero los tensor cores están parados — el cuello de botella es la memoria, no el compute.

Resultado práctico: el operador ve “GPU-Util 99 %” en Grafana y asume “GPU saturada, no se puede meter más carga”. Pero la realidad puede ser “compute al 25 %, HBM saturada al 95 %”, lo que cambia las decisiones operativas (quantization, batch size, paralelismo). La métrica clásica miente por simplificación.

Lo correcto es mirar las tres métricas de profiling DCGM del subsistema _FI_PROF_*:

DCGM_FI_PROF_SM_OCCUPANCY — ratio de warps activos sobre máximos por SM. ¿Hay trabajo paralelo?
DCGM_FI_PROF_PIPE_TENSOR_ACTIVE — % de ciclos con tensor cores efectivamente activos. ¿Está el compute trabajando?
DCGM_FI_PROF_DRAM_ACTIVE — % de ciclos con la HBM transfiriendo. ¿Está la memoria saturada?

Una decode-bound GPU típica de Llama 70B en H100 muestra: SM occupancy 35–55 %, tensor active 15–30 %, DRAM active 80–95 %. Esa es la “GPU saturada” real para LLMs. Las tres juntas distinguen los regímenes; cada una sola no dice nada accionable.

Cómo se montan en producción

La parte de plataforma se cubre en Cinco niveles de madurez (nivel 4 — GPU plane) y Siete fases de despliegue (fase F5). Para el observador, las piezas clave son:

NVIDIA GPU Operator. Manifiestos Helm que despliegan en cada nodo GPU: drivers, container toolkit, MIG manager y DCGM Exporter. Este último expone /metrics en formato Prometheus con todos los DCGM_FI_* listados arriba. Se scrapea desde el Prometheus interno del cluster.

Motor de inferencia. vLLM expone /metrics en el puerto 8000 (default) con métricas vllm:*. SGLang lo expone también con prefijo sglang:. TensorRT-LLM lo expone vía Triton Inference Server con prefijo nv_inference:. La convención básica de nombres es similar entre los tres motores; los umbrales y queries de este post asumen vLLM, pero se traducen.

ServiceMonitor / PodMonitor. Recurso del operador de Prometheus que indica qué scrapear. Ejemplo mínimo:

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
 name: vllm-inference
spec:
 selector:
 matchLabels: { app: vllm }
 podMetricsEndpoints:
 - port: metrics
 interval: 15s

Dashboards. El operador de NVIDIA publica dashboards Grafana de referencia para DCGM en nvidia/dcgm-exporter (repo oficial). vLLM publica uno en vllm-project/vllm (carpeta examples/). Ambos sirven como base; cada equipo añade los paneles propios de su SLO.

Las doce métricas DCGM organizadas por familia

Familia 1 — Compute

DCGM_FI_PROF_SM_OCCUPANCY — Ratio de warps activos por SM sobre el máximo posible. Valor entre 0 y 1.

Verde: 0.30–0.70 (régimen típico LLM en decode).
Ámbar: < 0.20 sostenido (batch demasiado pequeño, GPU infrautilizada en paralelismo).
Rojo: 0.95 sostenido con DRAM_ACTIVE bajo (kernel patológico saturando SMs).

DCGM_FI_PROF_PIPE_TENSOR_ACTIVE — % de ciclos con tensor cores ejecutando. La métrica clave de “¿el compute está produciendo?”.

Verde en prefill: 50–80 %.
Verde en decode: 15–30 % (decode es memory-bound, no es síntoma de problema).
Rojo: < 5 % sostenido en prefill o el motor no usa los tensor cores (mala config, formato incompatible).

DCGM_FI_PROF_DRAM_ACTIVE — % de ciclos con HBM transfiriendo datos. Métrica clave para detectar saturación de memoria.

Verde en decode: 60–85 %.
Ámbar: > 90 % sostenido (HBM cuello de botella firme — explica la TPOT alta).
Rojo: > 95 % sostenido con KV cache pool < 70 % (algo está pidiendo HBM que no es el motor; investigar leaks).

Familia 2 — Memoria

DCGM_FI_DEV_FB_USED — Frame Buffer (HBM) usado en MiB.

Verde: 70–85 % del total.
Ámbar: 86–92 %.
Rojo: > 92 % (riesgo de OOM en el siguiente paged-attention allocation).

PromQL para porcentaje sobre cluster: 100 * sum(DCGM_FI_DEV_FB_USED) / sum(DCGM_FI_DEV_FB_TOTAL).

DCGM_FI_DEV_FB_FREE — Frame Buffer libre. Complementaria de la anterior; útil para alertas absolutas (< 4096 MiB libres).

DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL — Bandwidth NVLink agregado en MB/s. Para topologías TP (tensor parallel) que cruzan GPUs vía NVLink, esta métrica revela si el reparto de paralelismo está saturando el bus.

Verde: variable según topología. En 4×H100 SXM con NVLink 4.0, capacidad teórica 450 GB/s por GPU. Régimen TP=4 típico: 50–150 GB/s sostenido.
Rojo: > 90 % capacidad sostenido (revisar si el modelo cabría con TP menor o pipeline parallel).

Familia 3 — Térmico y energético

DCGM_FI_DEV_GPU_TEMP — Temperatura del die en °C.

Verde: < 75 °C.
Ámbar: 75–82 °C.
Rojo: > 83 °C (cerca del thermal throttle automático de H100; revisar ventilación, caudal de aire, temperatura de entrada al rack).

DCGM_FI_DEV_POWER_USAGE — Consumo en watts. Para H100 SXM, TDP nominal 700 W. Útil para tres cosas: detectar workload inusualmente bajo (sospechar idle o stall), facturar coste energético real, y disparar alertas si el draw se acerca al límite de la PDU.

DCGM_FI_DEV_CLOCK_THROTTLE_REASONS — Bitmap codificado con las razones de throttle activas. Es la métrica que silenciosamente explica las degradaciones de TPOT.

Bits relevantes:

0x0000000000000001 — Idle (no es problema).
0x0000000000000002 — App clocks setting.
0x0000000000000004 — SW Power Cap (límite de software, p. ej. por nvidia-smi -pl).
0x0000000000000008 — HW Slowdown.
0x0000000000000010 — Sync Boost (NVIDIA Sync).
0x0000000000000020 — SW Thermal Slowdown (límite térmico de software).
0x0000000000000040 — HW Thermal Slowdown (límite térmico de hardware — emergencia).
0x0000000000000080 — HW Power Brake Slowdown (caída de tensión PSU).
0x0000000000000100 — Display Clock Setting.

Cualquier throttle salvo Idle con valor > 0 sostenido es alerta. La degradación de TPOT con DRAM_ACTIVE ya alto y throttle térmico activo es el clásico “el rack está mal ventilado, no es problema del motor”.

Familia 4 — Salud

DCGM_FI_DEV_XID_ERRORS — Contador acumulado de XID errors del driver. Los XID son códigos de evento crítico que NVIDIA documenta exhaustivamente (XID 13: graphics engine exception; XID 31: GPU memory page fault; XID 43: reset channel verif error; XID 79: GPU has fallen off the bus; XID 95: uncontained ECC error; etc.). Cualquier incremento es alerta inmediata: muchos XID requieren reset del nodo o RMA de la GPU.

DCGM_FI_DEV_ECC_DBE_VOL_TOTAL — Errores ECC double-bit volátiles (no corregibles). A diferencia de los single-bit (que ECC corrige silenciosamente y se contabilizan en DCGM_FI_DEV_ECC_SBE_*), los double-bit corrompen datos. Cualquier valor > 0 es alerta crítica: la GPU debe ser drenada y revisada.

DCGM_FI_DEV_RETIRED_DBE — Páginas físicas de HBM retiradas por double-bit errors acumulados. NVIDIA retira páginas defectuosas automáticamente para prevenir corrupción futura. Más de 4–8 páginas retiradas en una GPU sugiere degradación del silicio: documentar y planificar reemplazo en próxima ventana de mantenimiento.

Las cinco métricas del motor de inferencia (vLLM)

Las métricas DCGM responden “¿está sana la GPU?”. Las del motor responden “¿está el servicio cumpliendo el SLO?”. Sin ellas, sabes que el hardware funciona pero no sabes si los clientes están contentos.

vllm:num_requests_running — Requests actualmente en el batch. Si llega al --max-num-seqs configurado y no baja, el motor está saturado en concurrencia (revisar VRAM y rebalancear vía autoscaler — ver Autoscaling LLM en Kubernetes).

vllm:num_requests_waiting — Requests en cola, sin entrar al batch. Cualquier valor > 0 sostenido durante minutos indica que el cluster no escala con la carga. Esta es la métrica primaria para HPA.

vllm:gpu_cache_usage_perc — % del KV cache pool usado.

Verde: 50–80 %.
Ámbar: 80–92 %.
Rojo: > 92 % (riesgo de preempt-on-OOM: vLLM tirará requests para liberar memoria, lo que aumenta TTFT visiblemente).

vllm:time_to_first_token_seconds — Histograma de TTFT por request. Se consume como histogram_quantile(0.95, sum by(le)(rate(vllm:time_to_first_token_seconds_bucket[5m]))). Comparado contra el SLO de TTFT P95 dispara la alerta primaria de servicio.

vllm:time_per_output_token_seconds — Histograma de TPOT. Equivalente al anterior pero para fluidez de streaming. Comparado contra el SLO de TPOT P95 dispara la alerta secundaria.

Las seis alertas que deben pagear en producción

Cualquier cluster productivo serio dispara estas seis alertas a un canal con rotación de guardia. Sin estas, el SLO se cumple por suerte, no por proceso.

groups:
 - name: gpu-llm-critical
 rules:
 - alert: GpuHbmNearOom
 expr: 100 * (DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL) > 92
 for: 2m
 labels: { severity: critical }
 annotations:
 summary: "HBM de {{ $labels.gpu }} en {{ $value }}% — riesgo OOM"

 - alert: GpuThermalOrPowerThrottle
 expr: (DCGM_FI_DEV_CLOCK_THROTTLE_REASONS != 0) and ignoring(reason) (DCGM_FI_DEV_CLOCK_THROTTLE_REASONS != 1)
 for: 1m
 labels: { severity: warning }
 annotations:
 summary: "GPU {{ $labels.gpu }} en throttle (reasons={{ $value }})"

 - alert: GpuXidErrorDetected
 expr: increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0
 labels: { severity: critical }
 annotations:
 summary: "XID error en GPU {{ $labels.gpu }} — investigar inmediatamente"

 - alert: GpuEccDoubleBit
 expr: DCGM_FI_DEV_ECC_DBE_VOL_TOTAL > 0
 labels: { severity: critical }
 annotations:
 summary: "ECC double-bit en GPU {{ $labels.gpu }} — drenar nodo"

 - alert: VllmKvCachePoolNearFull
 expr: vllm:gpu_cache_usage_perc > 0.95
 for: 3m
 labels: { severity: warning }
 annotations:
 summary: "KV cache pool > 95% en {{ $labels.instance }}"

 - alert: VllmTtftP95OutOfSlo
 expr: histogram_quantile(0.95, sum by(le, instance)(rate(vllm:time_to_first_token_seconds_bucket[5m]))) > 1.5
 for: 5m
 labels: { severity: warning }
 annotations:
 summary: "TTFT P95 sobre SLO ({{ $value }}s > 1.5s)"

Estas seis cubren el 80 % de los incidentes que afectan a SLO. El 20 % restante exige investigación con tracing (ver Tracing LLM con OpenTelemetry GenAI).

Tabla maestra: umbrales y queries

Métrica	Verde	Ámbar	Rojo	Query base (PromQL)
SM occupancy	0.30–0.70	0.15–0.30	< 0.10 sostenido	`DCGM_FI_PROF_SM_OCCUPANCY`
Tensor active (decode)	15–30 %	< 10 %	< 3 %	`DCGM_FI_PROF_PIPE_TENSOR_ACTIVE`
DRAM active	60–85 %	85–95 %	> 95 % con KV bajo	`DCGM_FI_PROF_DRAM_ACTIVE`
FB used	70–85 %	86–92 %	> 92 %	`100 * DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL`
NVLink BW	< 70 % cap	70–90 % cap	> 90 % cap	`DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL`
GPU temp	< 75 °C	75–82 °C	> 83 °C	`DCGM_FI_DEV_GPU_TEMP`
Power usage	< 90% TDP	90–98 % TDP	> 98 % TDP	`DCGM_FI_DEV_POWER_USAGE`
Throttle reasons	0 o Idle	App/SW	HW Therm/Power	`DCGM_FI_DEV_CLOCK_THROTTLE_REASONS`
XID errors	sin cambio	—	cualquier delta	`increase(DCGM_FI_DEV_XID_ERRORS[5m])`
ECC DBE	0	—	> 0	`DCGM_FI_DEV_ECC_DBE_VOL_TOTAL`
Retired pages	< 4	4–8	> 8	`DCGM_FI_DEV_RETIRED_DBE`
KV cache used	50–80 %	80–92 %	> 92 %	`vllm:gpu_cache_usage_perc`
Requests waiting	0	1–5 sostenido	> 10 sostenido	`vllm:num_requests_waiting`
TTFT P95	< SLO	80–100 % SLO	> SLO	ver query alerta arriba
TPOT P95	< SLO	80–100 % SLO	> SLO	`histogram_quantile(0.95, sum by(le)(rate(vllm:time_per_output_token_seconds_bucket[5m])))`

Tres pitfalls que confunden al operador junior

Pitfall 1 — “GPU-Util al 99 % = saturada”. Como se explicó al inicio: DCGM_FI_DEV_GPU_UTIL se enciende con cualquier kernel. Lo correcto es mirar las tres _PROF_* (SM occupancy, tensor active, DRAM active) juntas. GPU util 99 % + tensor active 8 % + DRAM active 92 % = “saturada por memoria, no compute”; GPU util 99 % + tensor active 75 % + DRAM active 50 % = “saturada por compute, prefill heavy”. Las dos situaciones piden palancas distintas.

Pitfall 2 — confundir ECC single-bit (SBE) con double-bit (DBE). Los single-bit se corrigen silenciosamente y son inevitables en cualquier HBM bajo carga (radiación cósmica, fluctuaciones de tensión). Un contador SBE creciendo lentamente no es alerta — es física. El DBE sí: corrompe datos. Distinguir las dos métricas evita falsas alarmas y falsos negativos a partes iguales.

Pitfall 3 — alertar sobre num_requests_waiting > 0 sin contexto. Un valor instantáneo de 1 o 2 durante un pico es normal. Lo que importa es la cola sostenida: usar for: 5m con umbral 3–5. Sin esa ventana, el sistema satura el canal de alertas con ruido.

Aplicado a hardware on-premise típico

Para un cluster genérico de 4×H100 SXM 80 GB con NVLink intra-nodo:

DCGM Exporter desplegado vía NVIDIA GPU Operator, un DaemonSet por nodo GPU.
Prometheus interno con retención 30 días para métricas de alta frecuencia, 1 año para downsampled (Thanos/Mimir si el volumen lo justifica).
Grafana con tres dashboards estándar: hardware GPU (DCGM), motor (vLLM), SLO (TTFT/TPOT/RPS contra objetivos escritos).
Alertmanager con rotación de guardia y rate-limiting por silencio agrupado por nodo.
Cardinalidad controlada: gpu (id local), node, pod, model — no añadir request_id ni labels de alta cardinalidad a métricas (eso es trabajo del tracing).

Volumen estimado para un cluster de 16 GPUs con scraping cada 15 s: ~2 millones de samples/min, ~25 GB/día de Prometheus crudo. Manejable con un Prometheus por cluster + retention; si el equipo escala a > 64 GPUs, considerar Thanos sidecar o VictoriaMetrics. Ver Catálogo de herramientas OSS LLMOps para alternativas equivalentes.

Lo que no hemos cubierto (próximos artículos)

Tracing de cargas LLM: ya cubierto en Tracing LLM con OpenTelemetry GenAI.
Autoscaling basado en estas métricas: ver Autoscaling LLM en Kubernetes.
Runbooks de incident response: cómo cada una de estas alertas se traduce a acción concreta (drain, restart, RMA, escalado, rollback).
Cost accounting: usar DCGM_FI_DEV_POWER_USAGE y vllm:request_success_total para showback de coste por tenant.
Monitorización de fairness multi-tenant: cuando varios tenants comparten cluster, qué métricas detectan que uno está acaparando el KV cache.

Ver también

Tracing LLM con OpenTelemetry GenAI — la otra mitad de la observabilidad.
Capacity planning para inferencia LLM on-premise — qué se dimensionó y, por tanto, qué umbrales son defendibles aquí.
Continuous batching — explica por qué num_requests_running, num_requests_waiting y gpu_cache_usage_perc son las métricas operativas del motor.
Cinco niveles de madurez — la observabilidad LLM-aware vive en el nivel 4.
Siete capas del stack de inferencia LLM on-premise — DCGM Exporter es pieza de la capa de plataforma.
Autoscaling LLM en Kubernetes — usa estas métricas como input.
Anatomía de las doce métricas DCGM y cinco vLLM — profundización con analogía y anomalía documentada en producción para cada métrica, con cifras de incidentes públicos (Meta Llama 3, Story of Two GPUs, issues vLLM, KBs Dell/Lenovo).
Runbooks de incident response para LLM con Keep + Kafka — la traducción de cada alerta crítica a acción concreta (drain, reset, RMA, rollback) con workflow YAML, schema Kafka WORM y encaje en ISO 27035, ENS, NIS2, EU AI Act art. 73.

Referencias

NVIDIA — DCGM Exporter (repo nvidia/dcgm-exporter, métricas y unidades documentadas).
NVIDIA — DCGM Field Identifiers reference (lista completa de DCGM_FI_*).
NVIDIA — XID Errors documentation (catálogo de códigos XID y procedimientos de remediación).
NVIDIA — NVIDIA GPU Operator (Helm chart oficial).
vLLM project — examples/production_monitoring/ (PromQL y dashboards Grafana de referencia).
Prometheus — Histogram and summary best practices (para construir queries de percentiles defendibles).
NVIDIA — H100 Tensor Core GPU datasheet (TDP, HBM bandwidth, NVLink capacities).

Nvidia on lo0 — Blog Técnico

Entornos mixtos NVIDIA + Intel para inferencia LLM: del cluster H100 central al NUC en la sucursal

TL;DR

Estás aquí: DEPLOY (con heterogeneidad como decisión)

La analogía: la fábrica con varias máquinas distintas

Tres razones operativas para la heterogeneidad

Razón 1 — coste

Razón 2 — soberanía y diversificación de la cadena de suministro

Razón 3 — edge

Hardware Intel relevante (junio 2026)

Intel Gaudi 3 — la nota crítica sobre el marketing

Intel Xeon 6 con AMX — el caballo de batalla CPU

Intel Arc Pro B60 y Battlematrix

Intel NUC con NPU — el edge node

Software Intel — la pila relevante

Los cuatro patrones canónicos

Patrón 1 — embeddings + reranker en Intel

Patrón 2 — guardrails + PII redact en NUC near edge

Patrón 3 — speculative decoding drafter en NUC

Patrón 4 — dev workstations NUC

Observabilidad unificada en cluster heterogéneo

Routing por capability — del router L7 al heterogéneo

Pitfalls específicos

Aplicado a un cluster on-premise genérico

Lo que no hemos cubierto (próximos posts)

Ver también

Referencias

Observabilidad GPU para inferencia LLM: las doce métricas DCGM y vLLM que dictan la salud de tu producción

TL;DR

Estás aquí: OBSERVE (la otra mitad del tracing)

La analogía: la cabina de un avión moderno

Por qué nvidia-smi GPU-Util engaña en LLMs

Cómo se montan en producción

Las doce métricas DCGM organizadas por familia

Familia 1 — Compute

Familia 2 — Memoria

Familia 3 — Térmico y energético

Familia 4 — Salud

Las cinco métricas del motor de inferencia (vLLM)

Las seis alertas que deben pagear en producción

Tabla maestra: umbrales y queries

Tres pitfalls que confunden al operador junior

Aplicado a hardware on-premise típico

Lo que no hemos cubierto (próximos artículos)

Ver también

Referencias

Por qué `nvidia-smi` `GPU-Util` engaña en LLMs