Strategic PartnersIssue 178 records
NVIDIA
This edition pivots from yesterday’s DSX Ready launch/CDU shortlist and early Rubin claim set toward three operator threads: (1) Dynamo v1.5.0 GA (Sep 18) expands agent/tool-call serving and Kubernetes hardening while NIM Operator’s Dynamo path stays experimental and NIM LLM 3.0 docs remain 404; (2) independent ESS News naming of only three DSX Ready BESS vendors with PCS/AC-terminal scope, paired with NVIDIA’s BESS qualification overview Core island/black-start tests; and (3) Flex diligence pairing DSX Flex Exchange best_effort loadtarget semantics with Utility Dive’s warning that utilities may require binding interconnect terms and loadside breaker control. Signal65’s 1.64× Vera per-core agentic CPU study and RCR’s Sep 21 AgentX caveats add independent scrutiny on agentic efficiency marketing. Patterns warn that GA ≠ supported NIM Operator path, Ready BESS ≠ site certification, and Flex APIs ≠ interconnect contracts.
- Evidence records
- 8
- Cross-source patterns
- 3
- Evidence classes
- 3 standards or public-body guidance3 independent reporting1 vendor claim1 independent research
- Outcomes
- 4 cautionary3 emerging1 mixed
- Source freshness
- 4 new this fortnight4 undated
- Research completed
- 2026-09-23
Choose a role to see its takeaway beside every record in the ledger.
Patterns across the evidence
Synthesis · Lighthouse Advisory interpretation
Dynamo 1.5 is GA—but the NIM Operator path remains experimental
Dynamo v1.5.0’s Sep 18 GA expands agent/tool-call and Kubernetes hardening, yet NIM Operator 3.1.1 still labels its Dynamo integration experimental and not for production, while NIM LLM 3.0 Dynamo docs remain HTTP 404. SLED teams should upgrade on the supported Dynamo Platform/-enterprise track and treat NIM Operator Dynamo as lab-only until support language changes.
Operating questionWhich supported operator path and artifact pins will you accept for production Dynamo—and what stays explicitly preview?
Supporting evidenceDynamo v1.5.0 GA: custom router policies, v1beta1 CRDs, KVBM deprecationNIM Operator 3.1.1 Dynamo path is experimental and not production-supported
DSX Ready BESS is a thin PCS-AC-terminal list—not site certification
ESS News’ Sep 22 independent report names only Hitachi, LG Energy Solution, and Tesla for initial DSX Ready BESS, while NVIDIA’s qualification overview requires Core island/black-start tests at BESS AC terminals and keeps POI behavior in proxy/EMT space. Product qualification remains useful for BOM screening and still does not imply site-level stability or interconnect approval.
Operating questionWhich Core Requirements evidence will you require at AC terminals before treating a BESS SKU as DSX-aligned—and what site study still gates energization?
Supporting evidenceESS News / pv magazineDSX BESS Qualification Overview: AC-terminal tests and core island/black-start controls
Flex APIs are best-effort signals—utilities still want binding breaker terms
DSX Flex Exchange exposes loadtarget and breach events with strategy.best_effort shedding that may end non-compliant, while Utility Dive reports utilities such as SVP calling 100% loadside breaker control non-negotiable for faster interconnection. Software demos do not replace interconnect contracts that define enforcement, notice, and control authority.
Operating questionIf best_effort cannot meet a load target, what contractual enforcement—including possible breaker authority—have you already agreed with the utility?
Supporting evidenceDSX Flex Exchange: loadtarget commands, breach alerts, and best-effort shedding semanticsUtility Dive
Evidence ledger
Full record · every source keeps its link and limitations
Dynamo v1.5.0 GA: custom router policies, v1beta1 CRDs, KVBM deprecation
Dynamo v1.5.0 reached GA on Sep 18, 2026 as the 18th feature release (658 PRs, 123 contributors). It opens router worker selection to custom scoring/picking policies, extends KV indexing to Mooncake and disk tiers, deprecates KVBM (removal targeted for v1.6.0), streams guided tool calls by default, rejects over-context requests before the first token, and can decode images once at the Frontend for multimodal encode-prefill-decode. On Kubernetes, nvidia.com/v1beta1 becomes the CRD storage version, the Rust Endpoint Picker replaces the Go EPP, Dynamo Snapshot moves to a standalone operator, and TLS/mTLS cover TCP and NATS transports. Engine pins move to SGLang 0.5.18, TensorRT-LLM 1.3.0rc25, and vLLM 0.28.0. Sidecar, Triton backend, and SGLang RL rollout remain experimental.
Why it matters, evidence and limitations
- Why it matters
- Gives SLED platform teams a concrete upgrade checkpoint from Dynamo 1.4.x toward agent/tool-call serving and multimodal routing—but 44 breaking changes, experimental sidecars, and Enterprise support still attaching only to listed -enterprise artifacts mean campuses cannot treat GA as drop-in production for every path.
- Evidence and measured results
- GA date Sep 18, 2026; 658 merged PRs / 123 contributors; 44 breaking changes / 12 known issues; custom router policies; Mooncake/disk KV tiers; KVBM deprecated→v1.6.0 removal; Frontend guided tool-call streaming; over-context reject before first token; Frontend image decode; CRD storage v1beta1; Rust EPP default; Snapshot standalone; TCP/NATS TLS+mTLS; AISimulate package; engines SGLang 0.5.18 / TRT-LLM 1.3.0rc25 / vLLM 0.28.0; experimental Sidecar/Triton/RL.
- Limitations and uncertainty
- Vendor release notes, not independent production measurements. Nav chrome still labels Latest (v1.4.2) alongside v1.5.0 docs. Experimental paths may change without deprecation.
NIM Operator 3.1.1 Dynamo path is experimental and not production-supported
NIM Operator 3.1.1 documents a Dynamo integration enabled with dynamo.enabled=true that deploys Dynamo CRDs (noted as v0.9.0) and management pods. The page warns the feature is experimental, not fully supported, preview-oriented, and not recommended for production; APIs may change. Support is described for upstream-compatible Kubernetes, with OpenShift planned later. Install guidance requires NGC pull and API secrets plus an HF token secret, and notes the default kube-rbac-proxy image repository in the Dynamo v0.9.0 chart has been deprecated and must be overridden.
Why it matters, evidence and limitations
- Why it matters
- Warns SLED buyers that NIM Operator + Dynamo is not yet a supported production procurement path—useful when vendors pitch a unified NIM/Dynamo operator story after Dynamo 1.5 GA.
- Evidence and measured results
- Explicit experimental/not fully supported/not for production warning; dynamo.enabled=true Helm flag; deploys Dynamo CRDs v0.9.0; upstream Kubernetes only (OpenShift later); requires ngc-secret, ngc-api-secret, hf-token-secret; kube-rbac-proxy image deprecated and needs override; sample Qwen vLLM agg frontend curls on :8000.
- Limitations and uncertainty
- Docs page undated beyond version 3.1.1; CRD v0.9.0 may lag Dynamo 1.5.0 CRD story; example only, not measured campus outcomes.
ESS News: DSX Ready BESS launch names only Tesla, LG, Hitachi with PCS focus
On Sep 22, 2026 ESS News reported NVIDIA’s DSX Ready program for AI factory BESS and CDUs, emphasizing that only three BESS makers made the initial list: Hitachi Energy WD4 PCS + storage at 5 MW AC / 10 MWh; LG Energy Solution Vertech JF2 AC Link at 5 MW AC / 10 MWh; and Tesla Megapack 2XL at 1.93 MW AC / 3.85 MWh. Reporting stresses supplier self-test then NVIDIA review, PCS AC-terminal behaviors (dynamic P/Q, current limiting, ride-through, islanded operation, black start), and NVIDIA’s caveat that passing does not replace site-level engineering or imply site-level stability. Tesla had not commented at publication time.
Why it matters, evidence and limitations
- Why it matters
- Independent confirmation of a thin initial BESS shortlist and PCS-centric scope helps SLED facilities teams screen BOMs without mistaking DSX Ready for campus interconnect or fire-safety site acceptance.
- Evidence and measured results
- Publication Sep 22, 2026; three BESS vendors only; Hitachi 5 MW/10 MWh; LGES 5 MW/10 MWh; Tesla Megapack 2XL 1.93 MW/3.85 MWh; PCS AC-terminal focus; raw time-series evidence required; site equipment outside boundary; explicit site-stability caveat; Tesla no comment.
- Limitations and uncertainty
- Trade press summarizing NVIDIA program and partner quotes; not independent lab re-test of PCS results; CDU details lighter than BESS naming.
DSX BESS Qualification Overview: AC-terminal tests and core island/black-start controls
NVIDIA’s BESS Qualification Overview details a partner self-qualification packet: PRD line-by-line C/D/E responses with evidence references; materials/safety/compliance disclosures; a Core Requirements checklist; and test procedures. The qualification boundary is at BESS AC terminals; POI ramp needs are verified via approved POI proxy profiles and/or EMT models. Core controls include autonomous island operation, reactive power support within PCS limits, seamless grid/island transition, and black start. Instrumentation requirements apply across tests; all tests run at AC terminals unless marked model-only.
Why it matters, evidence and limitations
- Why it matters
- Gives SLED facilities and EPCs the actual control/test vocabulary behind DSX Ready BESS claims—especially islanding and black-start—so reviewers can demand packet evidence rather than logo slides.
- Evidence and measured results
- PRD Compliant/Non-compliant/Exception responses; Core Requirements checklist; CTRL-CORE-01 island mode; GRID-CORE-02 reactive support; MODE-CORE-01 grid/island transition; MODE-CORE-02 black start; AC-terminal test boundary; POI proxy/EMT for ramp; instrumentation table applies to all tests.
- Limitations and uncertainty
- Vendor standard, not third-party audited results for a specific SKU; undated page; distinct from the already-archived BESS self-qualification guidelines overview URL.
Signal65: Vera 1.64× per-core on agentic CPU tasks vs EPYC 9755 (not whole-server)
Signal65 validated NVIDIA Vera on agentic host CPU work using Terminal-Bench 2 oracle (reference-solution) runs that exclude the LLM. Across 69 matched tasks under full load (one sandbox per physical core), Vera’s geometric-mean per-core task lifecycle was 1.64× faster than AMD EPYC 9755; 61/69 tasks favored Vera. Signal65 reproduced NVIDIA’s Vera pass profile hands-on, but the 1.64× x86 comparison remains based on NVIDIA’s paired measurements. Explicitly not measured: whole-server throughput, power, price, or memory capacity (88 Vera cores vs 128 EPYC cores).
Why it matters, evidence and limitations
- Why it matters
- Newly relevant as SLED teams evaluate Vera Rubin agentic stacks: GPU AgentX headlines omit CPU-bound sandbox time—this study bounds per-core CPU gains while warning against socket-level capacity claims.
- Evidence and measured results
- Date Sep 15, 2026; Terminal-Bench 2.0 oracle agent; 69 matched tasks geo-mean 1.64×; 61/69 favor Vera; 34 tasks ≥2×; 8 favor x86; hands-on Vera pass-profile match; 1.64× vs x86 still NVIDIA paired data; no whole-server/power/cost; 88 vs 128 cores.
- Limitations and uncertainty
- Oracle agent removes model variance; NVIDIA provided hardware and paired x86 data; subsetting to most agent-like 20 tasks (1.87×) is author judgment; PINNACLE CPU suite still developing.
Utility Dive: flexibility needs binding interconnect agreements and utility breaker control
Utility Dive reports data centers and utilities still lack common operating guidelines for flexibility-for-speed interconnection. Stakeholders say EPRI DCFlex is missing standardized binding agreements. Silicon Valley Power’s Karwick states that for faster interconnection and added capacity, SVP must have 100% control of the loadside breaker as a non-negotiable part of the interconnection agreement, while Emerald AI provides software to translate utility curtailment signals. Analysts note breaker-level control is hard for data centers to accept because they lose operational control; gradual load reduction is preferred to protect hardware. Duke Nicholas Institute 2026 figures on small peak reductions and rate impacts are cited as context.
Why it matters, evidence and limitations
- Why it matters
- Newly relevant to NVIDIA DSX Flex/Emerald commercial narratives: public-power and investor-owned utilities may demand contractual breaker authority—not only DSX Flex agents—before accelerating SLED or campus interconnects.
- Evidence and measured results
- Missing binding agreement called out for EPRI DCFlex; SVP 100% loadside breaker control non-negotiable; Emerald AI secure interface for curtailment; data-center control-loss concern; Duke 2026 1–2% peak cut → 0.5–2.8% rate impact citation; Flex Connect / PGE visibility+dispatchability themes.
- Limitations and uncertainty
- Article synthesizes interviews and pilots; not a measured DSX Flex compliance study; publicationDate not stated as ISO date on page; SVP pilot details also appear in partner releases.
DSX Flex Exchange: loadtarget commands, breach alerts, and best-effort shedding semantics
DSX Flex Exchange docs define a CloudEvents-over-MQTT control plane for real-time power management. Key event types include grid.loadtarget.set.v1 (ISV fire-and-forget load target), grid.powerstate.status.v1, grid.powerbreach.alert.v1, and grid.powerbreach.enforcement.v1. Companion schemas describe load constraints in W/kW/MW with optional UTC intervals, and a strategy.best_effort flag where the Flex Agent sheds non-disruptively via DPM-enabled jobs and may leave the feed non-compliant if the target cannot be met. Shed hints are described as non-binding; enforcement outcomes include applied/failed/skipped.
Why it matters, evidence and limitations
- Why it matters
- Clarifies that DSX Flex is a signaling/enforcement API with best-effort modes—not a guarantee of utility-grade compliance—so SLED sites must map schema semantics to interconnect contract terms.
- Evidence and measured results
- MQTT CloudEvents binding; event types loadtarget.set / powerstate.status / powerbreach.alert / powerbreach.enforcement; load targets in watt|kilowatt|megawatt; interval start/end UTC; strategy.best_effort non-disruptive DPM shed with possible non-compliance; shed hints non-binding; enforcement codes applied|failed|skipped.
- Limitations and uncertainty
- Interface spec without measured field compliance rates; schemas page complements overview; not a utility tariff.
RCR: Vera Rubin 30× AgentX per-MW claim is narrow, vendor-led, coding-agent scoped
Sep 21, 2026 RCR coverage of NVIDIA’s Vera Rubin AgentX claim states the rack delivers up to 30× higher agentic-AI throughput per megawatt than GB300 NVL72 on SemiAnalysis AgentX, with an updated up-to-45× lower cost-per-million-tokens figure. The article stresses the result is a vendor claim on an open framework, measured at a high-interactivity operating point (160 tokens/s on DeepSeek V4 Pro coding-agent traffic), does not score output quality, and should not be blended with MLPerf (cited ~3.7×) or DSX MaxLPS densification claims. Production deployment by cloud partners is noted as context, not as independent verification of the 30× point.
Why it matters, evidence and limitations
- Why it matters
- Independent Sep 21 diligence useful for SLED buyers still seeing 30× marketing after prior-day editions: reinforces coding-corpus and operating-point limits before any campus efficiency procurement narrative.
- Evidence and measured results
- Date Sep 21, 2026; up to 30× AgentX tokens/MW vs GB300; up to 45× lower $/M tokens (updated from 35×); 160 TPS operating point; DeepSeek V4 Pro coding sessions; no output-quality scoring; MLPerf ~3.7× contrast; MaxLPS called separate; vendor claim pending broader confirmation language.
- Limitations and uncertainty
- Trade press summarizing NVIDIA and SemiAnalysis materials; not a new lab reproduction; model named in coverage may be superseded.
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.
- Standards or public-body guidance
- Normative or advisory guidance from a standards body or public institution.
- 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.
- Independent research
- Research conducted outside the implementing organization.