Strategic PartnersIssue 198 records
NVIDIA
Tonight’s edition pivots from yesterday’s HTX/GB300 and Dynamo-Enterprise-pin package to two fresh fronts: (1) NVIDIA’s Sep 23 Cluster Readiness Engine (NVCRE) workload-certification layer for GPU Kubernetes, read against independent vCluster and Rafay hands-on/operating-model write-ups that stress catalog GPU-count mismatches, missing default thresholds, and evidence-only remediation; (2) Sep 24 independent DSX Ready BESS coverage (pv magazine USA; Energy-Storage.News) plus LG’s 2.6 MW CDU Ready claim, still bounded by NVIDIA’s product≠site-stability caveat, with LavX lock-in analysis and GPU Operator 26.7.1 ops constraints (CUDA memory limits; H100 MIG upgrade footgun). NIM 3.0 docs remain 404; Dynamo Enterprise still pinned 1.4.2 per yesterday.
- Evidence records
- 8
- Cross-source patterns
- 3
- Evidence classes
- 5 independent reporting2 vendor claim1 standards or public-body guidance
- Outcomes
- 4 emerging4 cautionary
- Source freshness
- 6 new this fortnight1 recent1 undated
- Research completed
- 2026-09-25
Choose a role to see its takeaway beside every record in the ledger.
Patterns across the evidence
Synthesis · Lighthouse Advisory interpretation
Workload certification—not Kubernetes Ready—is the emerging GPU handoff gate
NVIDIA’s Sep 23 NVCRE blog and independent Sep hands-on/partner write-ups agree that node Ready, allocatable GPUs, and healthy GPU Operator do not prove multi-node AI readiness. NVCRE runs real NCCL/training jobs and names failed nodes, but early labs show catalog GPU-count mismatches, missing default thresholds, and evidence-only remediation—so SLED shared clouds should treat certification as policy-bound evidence, not an automatic SLA.
Operating questionWhich SKU-specific Certification thresholds and remediation owners are required before GPU capacity is handed to tenants or researchers?
Supporting evidenceNVIDIA Cluster Readiness Engine: workload-driven GPU cluster certification before productionvCluster LabsRafay
Sep 24 Ready coverage still: product qualification ≠ site stability
Fresh Sep 24 independent BESS coverage (pv magazine USA; Energy-Storage.News) plus LG’s 2.6 MW CDU Ready claim keep repeating NVIDIA’s boundary: AC-terminal/product qualification does not replace site engineering or imply site-level stability. Launch marketplaces remain thin (three BESS; limited CDU set), so BOM screening can use Ready lists without treating them as campus or interconnect certification.
Operating questionWhat site electrical/thermal acceptance evidence remains mandatory after a DSX Ready BESS or CDU is selected?
Supporting evidencepv magazine USAEnergy-Storage.NewsLG Electronics
DSX efficiency and Ready expansion deepen ecosystem dependence
LavX’s lock-in reading of MaxLPS/Flex—efficiency that best fits validated NVIDIA stacks—gains why-now force as Sep 24 Ready BESS reporting shows NVIDIA also defining how storage PCS must behave for AI factories. SLED buyers chasing tokens/MW and Ready BOMs should pair pilots with explicit portability and heterogeneous-accelerator gap analysis.
Operating questionIf DSX Ready and Flex/MaxLPS are adopted, what contractual portability and multi-accelerator exceptions remain enforceable?
Supporting evidenceLavX Newspv magazine USAEnergy-Storage.News
Evidence ledger
Full record · every source keeps its link and limitations
NVIDIA Cluster Readiness Engine: workload-driven GPU cluster certification before production
On Sep 23, 2026 NVIDIA published a technical blog introducing NVIDIA Cluster Readiness Engine (NVCRE), an open-source Kubernetes controller that runs real distributed workloads (NCCL variants, DCGM level-4, NeMo/Nemotron 5 8B/56B pretraining) across topology-aware node groups to prove GPU cluster readiness before production jobs land. The Certification/Workflow/Job CRD hierarchy attributes failures to specific nodes (HardwareFailureDetected, ThresholdViolation, WorkloadFailed). Adaptive diagnose mode splits failing groups. NVCRE records evidence but does not cordon/taint/drain; NVIDIA positions it with AICR configuration and NVSentinel telemetry as layers of DSX OS. Prerequisites include Kubernetes 1.29+, Helm 3.x, and GPU Operator; GB200/GB300 catalog entries need DRA Driver for ComputeDomain.
Why it matters, evidence and limitations
- Why it matters
- Campus and agency GPU Kubernetes platforms can treat NVCRE-style certification as a handoff gate before researchers/tenants receive capacity, without inventing SLED-specific use cases beyond shared HPC/AI clusters.
- Evidence and measured results
- Blog dated Sep 23, 2026; describes CRD hierarchy, catalog domains, CEL thresholds (none ship by default; GB200 NVL72 figures are illustrative), WorkloadRun API, and integration with NVSentinel Certification Monitor.
- Limitations and uncertainty
- Vendor tutorial; no independent campus measured outcomes in this post; default thresholds absent; catalog assumes multi-GPU node shapes that may not match SLED SKUs.
vCluster Labs: NVCRE v0.1.0 on Private Nodes—catalog mismatches, onprem detection, threshold gaps
Sep 2, 2026 vCluster Labs ran NVCRE v0.1.0 (published Sep 1) against two single-GPU A100 Private Nodes in a tenant cluster. NVCRE flagged that the A100 catalog assumes 8 GPUs/node and required gpusPerNode:1; platform showed as onprem because Private Node providerIDs are vcluster:// rather than gce://. Default NCCL sweeps were too long for a non-RDMA Flannel/Socket path (~0.60 GB/s at 128 MB); authors note the documented maxBytes knob is unusable in v0.1.0. Without thresholds a run can only Succeeded; they added a CEL busBandwidth gate to exercise pass/fail. GPU Operator 26.7.0 was used. Why now: Sep 23 NVIDIA NVCRE blog makes this early independent burn-in newly relevant for adoption caveats.
Why it matters, evidence and limitations
- Why it matters
- SLED shared research clusters and education neoclouds often use non-DGX node shapes; catalog overrides and threshold policy are mandatory before treating PASSED as handoff proof.
- Evidence and measured results
- Hands-on report with measured Socket path bandwidth, GPU Operator version pin, and explicit field notes on catalog mismatch, providerID detection, and threshold defaults.
- Limitations and uncertainty
- Lab on two Spot A100s over Flannel/Socket—not a representative InfiniBand/EFA campus fabric; partner blog promoting vCluster Private Nodes.
Rafay: NVCRE as Provision→Configure→Certify→Hand Off gate for neocloud GPU Kubernetes
Sep 12, 2026 Rafay describes NVCRE as addressing the gap where Kubernetes Ready, allocatable GPUs, and healthy GPU Operator still do not prove multi-node communication. It proposes embedding NVCRE in a neocloud blueprint: Provision → Configure → Certify → Hand Off, with Certification CRs as provider policy. On a two-node A10 cluster they note catalog assumes four GPUs/node for A10 and require gpusPerNode:1; a communication/nccl-all-reduce run PASSED in ~1m31s with ~1.50 GB/s bus bandwidth. NVCRE identifies failures but does not drain/repair—platform orchestration owns remediation. Why now: pairs with Sep 23 NVIDIA NVCRE launch messaging.
Why it matters, evidence and limitations
- Why it matters
- Useful operating-model pattern for state/education shared GPU clouds that hand capacity to agencies or departments; not itself a measured SLED outcome study.
- Evidence and measured results
- Partner blog with concrete A10 demo timings/bandwidth and explicit gpusPerNode override guidance.
- Limitations and uncertainty
- Vendor/partner advocacy; small A10 demo bandwidth not a campus fabric benchmark; success path emphasized.
pv magazine USA: DSX Ready BESS launch names only Tesla, LGES, Hitachi—PCS AC-terminal focus
Sep 24, 2026 pv magazine USA reports NVIDIA’s DSX Ready program initially qualifies BESS and CDUs for AI factory infrastructure. For BESS, suppliers run tests before NVIDIA reviews data, focusing on PCS behavior at AC terminals (dynamic active/reactive response, current limiting, ride-through, islanding, black start). Partners must supply time-series evidence and document grid/fire/cyber certifications. NVIDIA states passing does not replace site-level engineering or imply site-level stability. Launch BESS list: Hitachi Energy WD4 PCS 5 MW/10 MWh; LGES Vertech JF2 AC Link 5 MW/10 MWh; Tesla Megapack 2XL 1.93 MW/3.85 MWh.
Why it matters, evidence and limitations
- Why it matters
- Relevant where SLED entities site AI halls with on-site storage; Ready lists aid BOM screening but do not certify campus interconnect or emergency power designs.
- Evidence and measured results
- Independent trade piece dated Sep 24 with named MW/MWh figures and explicit qualification-boundary language.
- Limitations and uncertainty
- Trade press synthesizing NVIDIA program; not a lab retest of the three BESS products.
Energy-Storage.News: three DSX Ready BESS + three CDUs; NVIDIA restates site-stability limit
Sep 24, 2026 Energy-Storage.News covers NVIDIA DSX Ready launched Sep 21, naming BESS from Hitachi Energy, LG Energy Solution, and Tesla, and CDUs from LG Electronics, LiquidStack, and Vertiv. LGES emphasizes domestic content/LFP tax-credit advantages and grid-forming AC architecture meeting UL/NFPA; Hitachi highlights PCS/PPC capabilities after Eks Energy acquisition. NVIDIA again notes qualification does not replace site-level engineering or imply site-level stability. Additional Ready categories beyond BESS/CDU remain unspecified.
Why it matters, evidence and limitations
- Why it matters
- Helps SLED facilities track which storage/cooling vendors claim DSX alignment; domestic-content angles may matter for U.S. public procurement—still not site certification.
- Evidence and measured results
- Sep 24 independent trade article with vendor quotes and explicit NVIDIA site-stability caveat.
- Limitations and uncertainty
- Trade press; LGES/Hitachi quotes are vendor marketing; Tesla silent at time of writing in related coverage.
LG Electronics: 2.6 MW CDU qualifies as NVIDIA DSX Ready Large-Scale cooling product
Sep 22, 2026 LG Electronics announces its 2.6 MW Coolant Distribution Unit qualified as NVIDIA DSX Ready CDU, meeting applicable DSX reference-design requirements and listed on the DSX AI Factory Marketplace. LG states 600 kW and 1 MW models completed infrastructure qualification earlier, while the 2.6 MW model achieved additional requirements for DSX Ready and is categorized as Large-Scale. The release positions the CDU within LG’s Chip-to-Chiller portfolio (chillers, CRAHs, liquid cooling) for multi-rack high-density AI clusters and cites TrendForce liquid-cooling penetration rising toward ~60% by 2027.
Why it matters, evidence and limitations
- Why it matters
- Relevant to SLED facilities planning MW-class liquid cooling for dense GPU halls; vendor claim needs independent thermal acceptance—do not equate Ready with campus readiness.
- Evidence and measured results
- Primary vendor release with explicit 2.6 MW Ready claim and prior 600 kW/1 MW qualification path.
- Limitations and uncertainty
- Vendor PR; MW rating and Ready status not independently measured here; TrendForce forecast is secondary.
LavX: DSX MaxLPS/Flex efficiency push also deepens NVIDIA hardware ecosystem lock-in
Sep 17, 2026 LavX analyzes NVIDIA’s DSX efficiency narrative as a response to grid ceilings on GPU sales: MaxLPS targets stranded power (illustrative 100 MW facility with ~20 MW unused), citing Lambda densification (19 vs 16 nodes, +24% throughput / similar perf/W), while Flex enables utility reclaim during peaks with workload pause/migration. The catch emphasized is ecosystem lock-in—DSX works best with validated NVIDIA hardware; third-party accelerators (d-Matrix, SambaNova) complicate integration; AMD Instinct needs alternative management. Why now: newly relevant as Sep 24 Ready BESS/CDU coverage expands DSX into facilities BOM decisions.
Why it matters, evidence and limitations
- Why it matters
- Warns SLED buyers that power-flexibility and densification benefits may increase switching costs; evaluate portability clauses when adopting DSX-centric designs.
- Evidence and measured results
- Independent analysis citing summit messaging, Lambda figures, and heterogeneous-accelerator friction.
- Limitations and uncertainty
- Secondary analysis; Lambda metrics not independently reproduced; Register already covered related walled-garden theme.
GPU Operator 26.7.1: CUDA memory limits, driver 615.71.09, H100 MIG upgrade known issue
GPU Operator 26.7.1 release notes add soft/hard per-GPU CUDA memory limits via NVIDIA_GPU_MEMORY_REQUEST and NVIDIA_GPU_MEMORY_LIMIT (MiB; requires R615+ driver), support for Data Center driver 615.71.09, Confidential Computing Manager v0.4.4, and operand wait-for-driver-validation fixes. A known issue warns that on H100 nodes, upgrading drivers from 595.91.07 to 615.71.09 without reboot or GPU reset can break subsequent MIG reconfiguration (NVML ERROR_UNKNOWN / Xid 119), with documented reboot or nvidia-smi -r workarounds. 26.7.0 previously introduced GPUCluster DRA management mutually exclusive with ClusterPolicy. Newly relevant beside NVCRE blogs that list GPU Operator as a prerequisite.
Why it matters, evidence and limitations
- Why it matters
- Campus/agency Kubernetes GPU fleets need memory-limit controls and must plan H100 MIG driver upgrade downtime—operational constraint evidence, not a SLED outcome study.
- Evidence and measured results
- Primary release notes detailing 26.7.1 features/fixes and H100 MIG known issue steps.
- Limitations and uncertainty
- Vendor docs; publicationDate not stated on page; behavior depends on cluster runtime/CDI configuration.
How to read this edition
Source findings, measured results and limitations come from the cited publications. Patterns, operating questions, role takeaways and implementation considerations are Lighthouse Advisory interpretation, stated as questions to validate locally rather than guaranteed outcomes. Vendor and operator claims are labeled as claims. Full research method.
- Independent reporting
- Independent reporting with attributable sources but without a formal evaluation design.
- Vendor claim
- A supplier-provided assertion that has not been upgraded to independent evidence.
- Standards or public-body guidance
- Normative or advisory guidance from a standards body or public institution.