Strategic PartnersIssue 158 records
NVIDIA
This edition shifts from yesterday’s Pinterest Dynamo multimodal and AEMA/MaxLPS densification set toward three operator-facing threads: (1) Dynamo v1.4.2’s Dynamo Enterprise NGC support packaging under AI Enterprise; (2) NVIDIA’s internal AI-factory case study claiming large measured agent productivity on a NIM/NeMo/GPU Operator stack; and (3) grid-flexibility evidence spanning Emerald’s Hillsboro full-DSX Flex/Max-Q scenarios, arXiv:2606.25098’s 130 kW UK compliance and US geo-shift results, and NVIDIA’s Sep 15 Eos/SVP production flex narrative alongside Lambda MaxLPS densification. Independent scrutiny covers Phala’s Blackwell CC “serialized bridge” serving taxes and TechTarget’s multi-rack Vera Rubin ops reporting (504 GPUs), while Leidos+CoreWeave signals an intended sovereign federal AI cloud path. Patterns warn that flex is measured but still demo-to-low-MW scale, that CC overhead is bridge/runtime-shaped, and that multi-rack/sovereign capacity are operator–integrator products—not single-rack or press-release deliverables.
- Evidence records
- 8
- Cross-source patterns
- 3
- Evidence classes
- 5 vendor claim2 independent reporting1 academic research
- Outcomes
- 6 emerging1 mixed1 cautionary
- Source freshness
- 4 recent2 new this fortnight1 undated1 older, newly relevant
- Research completed
- 2026-09-21
Choose a role to see its takeaway beside every record in the ledger.
Patterns across the evidence
Synthesis · Lighthouse Advisory interpretation
Grid-flexible AI factories show measured compliance—but evidence remains sub-megawatt to low-MW
Emerald’s Hillsboro full-DSX Flex/Max-Q scenarios (20%/25%+/24h) and arXiv:2606.25098’s 130 kW UK 200+ event compliance (~30% in ~40s) plus NVIDIA’s Eos/SVP production narrative (>200 signals, 4→3 MW) collectively show software-orchestrated curtailment is real. They do not yet evidence the marketing-scale “100 GW unlock” or campus-gigawatt firmness. SLED sites should negotiate flex with utility-grade telemetry and explicit priority SLOs, not slogan capacity.
Operating questionWhat curtailment depth/duration and protected-job SLOs will your utility accept as evidence for interconnection—and at what cluster scale must you re-prove them?
Supporting evidenceEmerald AI (with NVIDIA, Portland General Electric, EPRI)Emerald AI, EPRI, National Grid, NVIDIA, Oracle (multi-affiliate authors)NVIDIA megawatts-to-tokens: Eos/SVP production Flex signals and Lambda MaxLPS densification
Blackwell confidential computing overhead is bridge- and runtime-shaped, not matmul-shaped
Phala’s independent synthesis shows near-native BF16 matmul under GPU-CC alongside ~5× host↔device bridge slowdowns and workload-dependent serving taxes, while NVIDIA’s internal AI-factory story pushes broad NIM/agent adoption without CC measurement. Regulated SLED deployments must benchmark CC-on serving defaults (async vs sync), loaders, and KV restore—not advertise microbenchmark parity as capacity planning truth.
Operating questionFor each production model, what is the CC-on tokens/s, TTFT, and cold-start budget versus CC-off on the exact serving stack?
Supporting evidencePhala (Hashforest Technology)NVIDIA internal AI factory: NIM/NeMo/GPU Operator stack with measured agent productivity claims
Multi-rack Rubin capacity and sovereign federal AI cloud are operator/integrator products
TechTarget’s independent account of CoreWeave’s seven-rack/504-GPU Vera Rubin production stresses scale-out networking, rack lifecycle, and storage locality as the operator’s product beyond NVIDIA’s single rack. Leidos+CoreWeave’s sovereign IC/DoW collaboration shows the federal path similarly depends on integrator accreditation and contracting—not GPU announcements alone. Dynamo Enterprise packaging likewise frames supportability as a curated pin set under NVAIE.
Operating questionWho owns the multi-rack fabric, rack lifecycle, and authorization boundary—and which artifact pins are actually support-eligible?
Supporting evidenceTechTarget (reporting on CoreWeave)Leidos / CoreWeaveNVIDIA / ai-dynamo (GitHub)
Evidence ledger
Full record · every source keeps its link and limitations
Dynamo v1.4.2 introduces Dynamo Enterprise NGC artifacts under AI Enterprise support
Dynamo v1.4.2 (Aug 29, 2026) is a patch on v1.4.1 that fixes NIXL loader-path resolution in Frontend and SGLang Runtime images (Rust bindings had silently used non-functional stubs), removes an unused Nsight EFA metrics plugin, and tightens dependency pins. The same release introduces Dynamo Enterprise: curated artifacts published with an -enterprise suffix in an NGC Dynamo Enterprise collection, eligible for NVIDIA Enterprise Support under an active NVIDIA AI Enterprise subscription, with no functional or binary differences from open-source counterparts. Backend pins stay at SGLang v0.5.16, TensorRT-LLM v1.3.0rc22, vLLM v0.26.0, NIXL v1.3.x, UCX v1.21.0.
Why it matters, evidence and limitations
- Why it matters
- Gives SLED platform teams a procurement-relevant support path for Dynamo (NVAIE subscription for cases) without claiming a separate product fork—useful when agencies require vendor-backed inference stacks rather than unsupported OSS tags. Does not itself prove FedRAMP/STIG readiness.
- Evidence and measured results
- Release summary states Enterprise artifacts start with v1.4.2 on NGC; bug fixes #13547/#13649 for NIXL dlopen path; dependency table lists Dynamo v1.4.2 with unchanged backends from v1.4.1; notes Enterprise has no functional/binary differences from OSS counterparts.
- Limitations and uncertainty
- Patch release dated Aug 29—included because Enterprise packaging is newly relevant to NVAIE procurement after recent Dynamo production narratives; experimental model snapshot builds remain pre-release and out of scope.
NVIDIA internal AI factory: NIM/NeMo/GPU Operator stack with measured agent productivity claims
NVIDIA describes consolidating shadow-AI pilots onto a unified AI factory on Blackwell-certified systems (HGX B200, RTX PRO Servers, Spectrum-X) with Run:ai, AI Enterprise, NIM, NeMo/Nemotron, GPU Operator, and Network Operator. IT uses GenAI-Perf for LLM throughput/latency baselines including NIM deployment profiling. Claimed outcomes: hardware-design agents completed >16 years of engineering work in one year (>100 workflows, >1M queries); software-engineering agents >18 years of work in just over a year; supply-chain agents (cuOpt) cut daily allocation planning from three hours to 10 minutes and weekly inventory from 15 hours to one hour (>95% daily planning-time reduction in key takeaways). Knowledge layer cites >1.1 billion internal documents via a customized RAG blueprint.
Why it matters, evidence and limitations
- Why it matters
- Useful reference architecture narrative for large SLED enterprises building governed on-prem agent platforms—but metrics are NVIDIA-internal and not independently audited; campuses should treat claimed “years of work” as vendor self-report, not transferable ROI.
- Evidence and measured results
- Key takeaways list 30+ combined engineering-years, >95% daily planning-time cut, hundreds of workflows onboarded; body details Blackwell hardware, GenAI-Perf NIM benchmarking, GPU/Network Operators, 1.1B-document RAG, and specific 3h→10min / 15h→1h supply-chain timings.
- Limitations and uncertainty
- Single-vendor autobiography; “years of work” equivalences lack external methodology; publicationDate not stated on page; not a public-sector deployment.
Emerald AI Hillsboro demo: full DSX Flex/Max-Q stack with utility dispatch scenarios
Emerald AI announced a Hillsboro, Oregon demonstration with NVIDIA, PGE, and EPRI integrating Emerald Conductor with the full NVIDIA DSX stack (including DSX Flex and DSX Max-Q) on Grace Blackwell Ultra clusters. PGE issued utility-style dispatch across scenarios: ~20% curtailment for freezing-rain/heating spikes; 25%+ curtailment across multi-day heat-dome re-enactments (6+ hour events over three days); a sustained 24-hour emergency response; and CAISO price-signal economic dispatch—while claiming priority workload performance was maximized under constraints. Positions the demo as the fifth live commercial-DC milestone toward a first commercial-scale DSX Flex deployment at NVIDIA’s planned 96 MW Vera Rubin AI Factory Research Center in Manassas, VA, and cites an aspirational “up to 100 GW” U.S. grid-capacity unlock.
Why it matters, evidence and limitations
- Why it matters
- Why now: prior Sep editions covered AEMA/Flex narratives and Lambda MaxLPS densification; this partner primary adds full-stack DSX Flex+Max-Q integration details and concrete curtailment percentages useful for SLED facilities/utility interconnection talks—without proving campus-scale results. Gov/Ed sites near constrained feeders may explore flex as interconnection strategy, not as guaranteed capacity.
- Evidence and measured results
- Dispatch scenarios with stated 20%, 25%+, and 24-hour responses; London precursor claimed >1/3 demand cut in under a minute on Blackwell Ultra; Nature Energy peer-reviewed Phoenix trial referenced; Manassas 96 MW commercial target named.
- Limitations and uncertainty
- Partner/vendor announcement; Hillsboro scale not MW-class in independent Volts commentary; 100 GW figure is system-level aspiration, not measured unlock; dated March 2026 but newly relevant to Sep Flex commercialization thread.
arXiv:2606.25098 — Power-flexible AI data centers: measured UK compliance and US geo-shifting
Preprint argues GPU AI data centers can act as grid-interactive assets via integrated grid signals, workload orchestration, and power telemetry. Experimental claims include: 100% compliance across 200+ distinct National Grid power events on a 130 kW NVIDIA Blackwell Ultra cluster; approximately 30% power reduction within 40 seconds in emergency load-reduction testing; and US geo-shifting that migrated 10% of live inference traffic from an Oracle H100 cluster in Virginia to Illinois during a Dominion Energy winter peak—while preserving priority service levels in the described trials.
Why it matters, evidence and limitations
- Why it matters
- Why now: supplies the academic primary behind Sep Flex/AEMA partner narratives with quantified response times and compliance rates SLED facilities/utilities can cite—while making clear trials are 130 kW-class / partial-traffic, not campus gigawatt proof. Transferability limited by utility protocols and workload mix.
- Evidence and measured results
- Abstract and intro summarize 130 kW deployment flexibility modes; contributions list UK 200+ event compliance and 10% Virginia→Illinois inference shift; body reports ~30% cut in ~40 seconds for emergency scenarios.
- Limitations and uncertainty
- Author set includes Emerald AI and NVIDIA; 130 kW vs commercial AI factories; preprint status; carbon-aware and multi-day claims need careful reading of methods sections.
NVIDIA megawatts-to-tokens: Eos/SVP production Flex signals and Lambda MaxLPS densification
Sep 15, 2026 NVIDIA blog ties DSX factory co-design to two measured threads: (1) Emerald Conductor on NVIDIA’s Eos AI factory in Silicon Valley Power’s Flexible Load Interconnect Program—automated 4 MW→3 MW reduction with high-priority jobs continuing, claiming >200 successful demand signals; (2) Lambda’s first DSX MaxLPS validation on HGX B200—19 nodes in a 16-node full-power budget, ~4M→5M tokens/s (+24%) and +23% perf/W, with up-to-40% more Vera Rubin NVL72 capacity projected in suitable environments. Clarifies Santa Clara is Conductor/production flex proof rather than a dedicated DSX Flex install, with Manassas 96 MW as the first dedicated DSX Flex commercial deployment target. Also notes ~120 kW heat per GB200 NVL72 liquid-cooled rack as a cooling constraint.
Why it matters, evidence and limitations
- Why it matters
- Fresh Sep 15 primary consolidating production Flex signal counts with MaxLPS densification—useful for SLED facilities comparing interruptible-load programs vs densification software. Still vendor-authored; SVP/Eos and Lambda contexts differ from typical campus halls.
- Evidence and measured results
- SVP >200 signals; 4→3 MW automated drop; Lambda +24% tokens/s and +23% perf/W; 40% Rubin projection; Manassas 96 MW named; GB200 ~120 kW heat callout.
- Limitations and uncertainty
- Vendor blog; MaxLPS and Flex overlap prior edition themes but this page adds Eos/SVP production signal volume and explicit non-DSX-Flex labeling for Santa Clara; Rubin +40% is projection.
Leidos + CoreWeave: intended sovereign AI cloud for IC and defense missions
Leidos and CoreWeave announced collaboration to deliver secure, sovereign AI cloud services for U.S. Intelligence Community and Department of War missions—combining CoreWeave’s AI-native cloud (infrastructure, networking, storage, orchestration for training/inference) in SCIF-accredited facilities with Leidos mission integration, accreditation support, cyber ops, data engineering, and delivery. Envisioned features include classified training/inference environments, intel analyst augmentation, cyber AI ranges, synthetic data/simulation, and edge-to-cloud orchestration. Builds on CoreWeave Federal; forward-looking statements warn definitive agreements are not assured and compute architecture depends on mission requirements and appropriations.
Why it matters, evidence and limitations
- Why it matters
- Direct federal/SLED-adjacent signal: NVIDIA-accelerated commercial AI clouds moving toward classified/sovereign delivery via integrators. Relevant to agency buyers evaluating FedRAMP/IL paths—but this is intent, not an awarded system or measured ATO. State/local/education should not over-read mission-classified features into civilian procurements.
- Evidence and measured results
- Dated Jul 30, 2026 Reston/Livingston announcement; feature list; SCIF-accredited DC plan; CoreWeave Federal reference; explicit forward-looking / definitive-agreement caveats.
- Limitations and uncertainty
- No measured performance, no contract award, NVIDIA stack implied via CoreWeave platform but not benchmarked in this release; older than last run but newly relevant alongside Sep multi-rack Rubin production reporting for federal-path context.
Phala: Blackwell GPU-CC is fast on compute but gated by a serialized VM–GPU bridge
Phala summarizes “The Serialized Bridge” measurements on Blackwell GPU Confidential Computing: BF16 matmul ~0.998× and long CUDA graphs ~1.0012× vs non-CC, while same-context H2D/D2H fall to ~0.20–0.21× with ~330 µs setup per call. Serving taxes are workload-shaped (example rows: ~1.1% MLPerf-shaped online loss vs 13–28% dense/MoE decode penalties; KV restore warm TTFT +131%). Default vLLM async scheduling can worsen CC; sync policy closed much of the gap (~1% residual in a cited B300 run). CC-aware loader cut GPT-OSS-120B load from 287.09 s to 8.36 s on B300. Also notes confidential multi-GPU tenants on B300 with fabric control-plane attestation remaining a trust gap.
Why it matters, evidence and limitations
- Why it matters
- Why now: independent operationalization of Blackwell CC beyond archived academic HTML—actionable for SLED regulated deployments that assumed “near-zero CC overhead.” Emphasizes runtime policy and bridge scheduling, not just GPU SKU choice.
- Evidence and measured results
- Stated CC-on/off ratios for matmul, transfers, serving rows, KV restore, and loader times; operational rules for batching bridge crossings and CC-aware defaults.
- Limitations and uncertainty
- Vendor-platform blog summarizing a paper (affiliate interest in confidential AI products); results are configuration-specific; paper itself may already be partially archived under versioned arXiv URL.
TechTarget: CoreWeave production multi-rack Vera Rubin (504 GPUs) and operator-scale networking
TechTarget reports CoreWeave has put seven NVIDIA Vera Rubin NVL72 racks into production across two regions (504 GPUs), framing multi-rack as an operator product beyond NVIDIA’s single-rack NVL72. Networking is highlighted: two-tier non-blocking scale-out with dual ConnectX-9 SuperNICs per GPU (up to 1.6 Tbps/GPU cited); architectural scale target ~128,000 GPUs/rail (not a deployed cluster size). Ops stack mentions Racky rack manager, Valvey liquid-cooling valves, and Rack LifeCycle Controller. Storage adds LOTA local object cache claiming up to 8× lower latency vs direct object reads and up to 7 GBps/GPU under right conditions, plus cross-region checkpoint write acceleration (remote copy typically ≤72 hours). Analysts stress failure noise at scale and checkpoint/recovery software criticality.
Why it matters, evidence and limitations
- Why it matters
- Independent Sep 16 ops-focused account complements earlier partner posts on 504-GPU bring-up—useful for SLED HPC/cloud buyers planning multi-rack Rubin domains. Not a government deployment; transfer lessons are about networking, cooling valves, and storage locality rather than campus-ready SKUs.
- Evidence and measured results
- Seven racks / 504 GPUs / two regions; 1.6 Tbps/GPU scale-out figure; LOTA 8× latency / 7 GBps/GPU claims attributed to CoreWeave; analyst quotes on cabinet-as-API and failure background noise.
- Limitations and uncertainty
- Company-sourced metrics via reporter; LOTA gains conditional; overlaps CoreWeave’s own multi-rack announcement already covered elsewhere but adds independent ops/storage detail.
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.
- Vendor claim
- A supplier-provided assertion that has not been upgraded to independent evidence.
- Independent reporting
- Independent reporting with attributable sources but without a formal evaluation design.
- Academic research
- Research produced through an academic institution or peer-reviewed venue.