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

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)

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:

1. Embedding del query (50 ms en H100, 80 ms en Xeon AMX, 30 ms en Arc Pro B60).
2. Búsqueda vectorial (Qdrant / Milvus / Chroma; latencia ~10-30 ms).
3. Reranker sobre top-k candidatos (60 ms en H100, 100-150 ms en Xeon AMX).
4. 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:

1. 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.
2. 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:

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.