Strategic PartnersIssue 138 records
NVIDIA
This edition centers on AI-factory power software and regulated packaging: NVIDIA’s Lambda DSX MaxLPS PoC (+24% tokens/s, +23% perf/W packing 19 HGX B200 nodes into a 16-node budget), the Aug 24 MaxLPS technical deep dive (DPS Developer Preview, 45°C cooling, up-to-40% Rubin projection), Sep 18 DataCenterNews separation of Emerald/DSX Flex curtailment (4→3 MW, >200 utility signals) from densification, LavX and SemiAnalysis caution that Rubin planning figures are estimates and MaxLPS/AgentX must not be conflated, NeoTeo’s Sep 17 read that CoreWeave’s 504-GPU Vera Rubin bring-up is network/cooling/ops-defined, plus Government Ready STIG/FIPS host prerequisites and AI Enterprise Infra 8.2 operator/driver pins.
- Evidence records
- 8
- Cross-source patterns
- 3
- Evidence classes
- 3 independent reporting2 vendor claim2 standards or public-body guidance1 independent research
- Outcomes
- 5 emerging3 cautionary
- Source freshness
- 3 undated3 recent2 new this fortnight
- Research completed
- 2026-09-19
Choose a role to see its takeaway beside every record in the ledger.
Patterns across the evidence
Synthesis · Lighthouse Advisory interpretation
MaxLPS densification is real in PoC—but not a universal site capacity grant
Lambda’s vendor case study shows +24% tokens/s and +23% perf/W by packing 19 HGX B200 nodes into a prior 16-node power budget, while LavX and SemiAnalysis stress that Rubin planning tables remain estimates, MaxLPS does not create utility megawatts, and AgentX curves must not be treated as MaxLPS measurements—so SLED plans need matched telemetry and adverse-profile proofs.
Operating questionWhich measured workloads, power policies, and latency holds were demonstrated on this site before counting densification as capacity?
Supporting evidenceNVIDIA / LambdaLavX NewsSemiAnalysis / InferenceXDSX MaxLPS technical deep dive: DPS Developer Preview and up-to-40% Rubin projection
Grid curtailment flexibility and MaxLPS densification are distinct power levers
Sep 18 DataCenterNews recounts Emerald AI/DSX Flex cutting a Santa Clara facility from 4 MW to 3 MW across >200 utility demand signals while keeping priority inference, alongside Lambda’s in-facility densification PoC—two mechanisms that must not be collapsed into one “NVIDIA solves power” claim in interconnect or capacity negotiations.
Operating questionAre we proving controllable-load curtailment for interconnection, reclaiming stranded rack power for densification, or both—with separate acceptance tests?
Supporting evidenceDataCenterNewsNVIDIA / LambdaDSX MaxLPS technical deep dive: DPS Developer Preview and up-to-40% Rubin projection
Regulated NVIDIA packaging still depends on host FIPS and matrix-pinned operators
Government Ready containers supply STIG Ubuntu 24.04 bases and FIPS libraries for FedRAMP High–class use cases but require FIPS-enabled host kernels and do not themselves constitute an ATO, while AI Enterprise Infra 8.2 gives the Production Branch pins (GPU Operator 26.3.3, NIM Operator 3.1.2, etc.) that regulated platforms should change-control as a matrix.
Operating questionAre Government Ready image tags paired with verified host FIPS and an 8.2-aligned operator/driver matrix inside the authorization boundary?
Supporting evidenceGovernment Ready containers: STIG Ubuntu 24.04 + FIPS libraries for FedRAMP High–class useAI Enterprise Infra 8.2 pins GPU Operator 26.3.3 and NIM Operator 3.1.2 on Production Branch
Evidence ledger
Full record · every source keeps its link and limitations
Lambda MaxLPS PoC: +24% token throughput and +23% perf/W inside fixed power
NVIDIA’s Lambda case study reports a five-rack, 19-node HGX B200 cluster under DSX MaxLPS: at an 85% power policy, 19 nodes fit the prior 16-node full-power budget, lifting cluster token throughput from ~4.04M to ~5M tokens/s (+24%) and performance per watt by 23%. Hybrid 80% policy runs (10 inference + 10 training) cite +20% inference and +17% training throughput by reclaiming stranded headroom. Lambda’s fleet narrative spans Ampere through Vera Rubin, but measured MaxLPS figures are B200-scoped.
Why it matters, evidence and limitations
- Why it matters
- Gives SLED facilities and AI-cloud buyers a concrete fixed-power densification datapoint—but PoC scale, MLPerf-like peaks, and vendor authorship mean campus/agency sites still need matched workload and telemetry proofs before budgeting “free” nodes.
- Evidence and measured results
- Key takeaways: +24% cluster-wide token throughput (19 vs 16 nodes same budget); +23% perf/W; +20% hybrid inference / +17% hybrid training at 80% policy; baseline ~4.04M tokens/s GPT-OSS-120B @ 40 QPS/node; DPS monitors GPU/rack draw; policies tested at 80%/85% of max; five-rack 19-node HGX B200 cluster.
- Limitations and uncertainty
- Vendor-published partner story; MLPerf-style peak loads may overstate recoverable headroom vs production mixed traffic; Vera Rubin fleet mention is not a measured MaxLPS result on Rubin.
DSX MaxLPS technical deep dive: DPS Developer Preview and up-to-40% Rubin projection
Aug 24, 2026 NVIDIA technical blog defines MaxLPS as Maximum Land Power Shell—dynamic power allocation via Dynamic Power Software (Developer Preview), workload-profile power solutions/APPM, and 45°C liquid-cooling inlet design. An illustrative 100 MW waterfall leaves ~60 MW for AI load after facility/rack/ops deductions. Vendor examples reclaim 170 kW stranded in a 540 kW static plan and show GB200/GB300 rack power cuts enabling roughly 35–39% more racks at preserved throughput; the post projects up to 40% more Rubin GPUs in a 100 MW factory. DPS does not change the site power envelope.
Why it matters, evidence and limitations
- Why it matters
- Newly relevant alongside today’s Lambda PoC: explains control-loop prerequisites and that Rubin “+40%” is a planning projection requiring early facilities design for 45°C and rack-position optionality—not a drop-in software toggle for SLED halls.
- Evidence and measured results
- DPS Developer Preview continuous control loop; DSX Exchange optional IT/OT bus also Developer Preview; Figure 4 GB200 125→90 kW and GB300-class 136→101 kW examples; Table 1 100 MW factory projections; guidance to validate before infrastructure is fixed; scoped NVL72 inference power pilot recommended.
- Limitations and uncertainty
- Vendor-authored; DPS/Exchange in Developer Preview; Rubin capacity gains are projections; illustrative waterfalls are not a specific customer site audit.
DataCenterNews: DSX Flex demand-response (4→3 MW) and Lambda MaxLPS densification
Sep 18, 2026 DataCenterNews reports NVIDIA’s dual power narrative: Emerald AI Conductor (early DSX Flex model) cut a Santa Clara AI facility from 4 MW to 3 MW on Silicon Valley Power demand signals while keeping higher-priority inference running—NVDA cites >200 successful automated responses in the utility’s Flexible Load Interconnect Program—and Lambda’s MaxLPS PoC (+24% tokens/s, +23% perf/W on a 19-vs-16 node B200 cluster). The piece also notes 800 VDC reference-design efficiency claims (3–5%) and up-to-40% Rubin densification projections.
Why it matters, evidence and limitations
- Why it matters
- Separates grid curtailment flexibility from in-facility densification for SLED/utility conversations; useful after yesterday’s AEMA policy coverage because it adds a counted demand-response operational example—still vendor-sourced numbers via trade press.
- Evidence and measured results
- 4→3 MW curtailment keeping priority inference; >200 SVP demand signals with successful automated response; Lambda five-rack 19-node figures restated; DSX described as OS/Sim/reference designs plus MaxLPS/Flex; Jensen quote that a 1 GW factory will never become 2 GW.
- Limitations and uncertainty
- Trade press summarizing vendor announcements; no independent meter data published; Emerald/Lambda results are early/large-scale-test and PoC respectively.
LavX Hot Chips read: MaxLPS densification useful; Rubin zettaflop figures remain estimates
Aug 27, 2026 LavX coverage of NVIDIA’s Hot Chips MaxLPS pitch states the operating principle—workload-aware rack controls plus 45°C cooling to raise compute density inside fixed megawatts—while stressing that ~40,000 Rubin GPUs / 2 zettaFLOPS NVFP4 inference / 1.4 zettaFLOPS training for a 100 MW site are planning estimates, not measured Rubin workload results. It restates the GB300 DeepSeek-R1 example (136→101 kW rack with reported no performance loss) and notes MaxLPS does not create new electrical capacity.
Why it matters, evidence and limitations
- Why it matters
- Independent counterweight to vendor densification slides for SLED procurement: keep the stranded-power idea, discount nameplate zettaflop planning tables until site-measured.
- Evidence and measured results
- Explicit “performance figures remain estimates”; communication/memory/software/utilization will lower real results; GB300 example 1,400 W→1,000 W GPU / 136→101 kW rack; chillers historically up to 40% of site power in some installs; MaxLPS does not create new utility capacity.
- Limitations and uncertainty
- Secondary reporting of a Hot Chips presentation; does not publish independent bench data.
SemiAnalysis InferenceX: MaxLPS reclaim depends on workload profiles—not unlimited utility power
InferenceX glossary defines DSX MaxLPS as dynamic power shifting that reclaims capacity left unused by conservative peak provisioning. It warns the opportunity depends on actual workload behavior and safe power-control policies; it does not make utility capacity unlimited or guarantee latency preservation under every demand pattern. It also states AgentX curves in the related Rubin article should not be presented as a direct measurement of MaxLPS contribution.
Why it matters, evidence and limitations
- Why it matters
- Independent definitional control for SLED buyers comparing MaxLPS marketing to AgentX/tokens-per-watt slides—especially after recent AgentX caveats in this stream.
- Evidence and measured results
- Plain-English and technical definitions; explicit non-guarantees on utility capacity and latency; note that MaxLPS is not isolated in displayed AgentX curves; related terms include tokens per megawatt and energy per token.
- Limitations and uncertainty
- Short glossary tied to SemiAnalysis Rubin article; not a full audit of Lambda or NVIDIA pilots.
NeoTeo: CoreWeave’s reported 504-GPU Vera Rubin bring-up makes network/cooling/ops first-class
Sep 17, 2026 NeoTeo analysis of CoreWeave’s reported seven Vera Rubin NVL72 racks (504 GPUs across two regions) argues the story is system ops, not GPU count: two-tier non-blocking scale-out up to 1.6 Tbps per GPU, failure tests that force traffic through the backend network, and software layers (Racky, Valvey, Rack LifeCycle Controller, Mission Control, LOTA) for rack management, liquid-cooling valves, lifecycle, and compute-local object cache. It explicitly separates the ~128,000-GPU-per-rail architectural target from the 504-GPU production report and notes NVIDIA serviceability/cooling claims are vendor-sourced.
Why it matters, evidence and limitations
- Why it matters
- Limited direct SLED deployment relevance (hyperscale cloud), but clarifies that multi-rack Vera Rubin success criteria are networking, cooling control, and data locality—useful framing if agencies evaluate neocloud capacity vs DIY racks.
- Evidence and measured results
- 7×72=504 GPUs; per-rack 72 Rubin/36 Vera/20.7 TB HBM4/1,400 TB/s; 1.6 Tbps scale-out per GPU via dual ConnectX-9; LOTA claims up to 8× lower latency vs direct object reads and up to 7 GBps/GPU under suitable cache conditions; cross-region migration typically ≤72 hours while local durable copy serves workloads.
- Limitations and uncertainty
- Secondary analysis of a Sep 16 report; locations undisclosed; some NVIDIA claims labeled as vendor presentation.
Government Ready containers: STIG Ubuntu 24.04 + FIPS libraries for FedRAMP High–class use
NVIDIA AI Enterprise Government Ready container docs (updated Aug 20, 2026) state images meet software security requirements for FedRAMP High or equivalent sovereign use cases while matching non–Government Ready functionality. Images use Canonical Ubuntu 24.04 STIG-hardened bases and FIPS-enabled crypto libraries (e.g., OpenSSL). FIPS mode requires a FIPS-enabled host kernel (/proc/sys/crypto/fips_enabled == 1); OPENSSL_FORCE_FIPS_MODE=0 is testing-only and must not be used in production FedRAMP/sovereign deployments.
Why it matters, evidence and limitations
- Why it matters
- Directly relevant to SLED/regulated buyers: clarifies packaging controls available for NVIDIA software stacks, while not asserting that NVIDIA products are themselves FedRAMP-authorized ATOs.
- Evidence and measured results
- Definition bullets for Government Ready; STIG and FIPS 140-3 explanations; deployment note on FIPS host kernel; verification via fips_enabled; explicit warning against force-disable in production regulated deployments; pointer to regulated-environments white paper.
- Limitations and uncertainty
- Vendor documentation; “meet requirements for use within FedRAMP High” is not the same as a product ATO; no performance overhead figures.
AI Enterprise Infra 8.2 pins GPU Operator 26.3.3 and NIM Operator 3.1.2 on Production Branch
NVIDIA AI Enterprise Infrastructure 8.2 release notes identify the Production Branch component set, including Data Center GPU Driver 595.91.07, DOCA networking 3.4.0, Container Toolkit 1.19.1, GPU Operator 26.3.3, Network Operator 26.4.1, DPU Operator 26.4.0, NIM Operator 3.1.2, and Run:ai 2.26. Fabric Manager remains integrated into AI Enterprise drivers since 8.0. The notes point operators to per-component release notes for features, fixes, and known limitations and to the lifecycle policy for PB vs LTSB choices.
Why it matters, evidence and limitations
- Why it matters
- Practical pinning guide for SLED platform teams standardizing Kubernetes GPU/NIM stacks—especially alongside Government Ready packaging—without implying a single “8.2 solves deployment” outcome.
- Evidence and measured results
- Table of supported infrastructure software with versions; PB cadence note; links expectation to lifecycle policy and per-component notes; Fabric Manager inclusion since 8.0 restated.
- Limitations and uncertainty
- Release notes inventory, not a measured deployment study; known limitations live in linked per-component notes not fully reproduced here.
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.
- Independent research
- Research conducted outside the implementing organization.