NVIDIA DSX Exchange

NVIDIA DSX Exchange is an open-source software platform from NVIDIA for passing operational signals between the systems that run large AI data centers, which NVIDIA calls AI factories. It is one of the named software components of the NVIDIA DSX platform. NVIDIA's documentation says DSX Exchange includes three parts: the DSX Event Bus, a NATS-based message bus that speaks MQTT 3.1.1 to power, building management, cooling, grid and compute systems; AsyncAPI schemas that define the topics and payloads those systems exchange; and DSX Agent Gateway, an authenticated routing layer for Model Context Protocol (MCP) traffic between AI agents and the tools that operate the facility.^[1] The code is published on GitHub under the Apache License 2.0.^[2] As of 1 November 2026, NVIDIA's documentation labels DSX Exchange a developer preview and warns that its "APIs and behavior may change without notice"; NVIDIA announced DSX Agent Gateway as a developer preview on 30 October 2026.^[1][3]

Key facts

History

NVIDIA first used the name when it introduced the Omniverse DSX blueprint at its GTC Washington, D.C. keynote on 28 October 2025. The company's blog listed DSX Exchange, subtitled "Unified IT/OT Integration," as one of three pillars of DSX alongside DSX Flex and DSX Boost, and described it as the "secure data and control fabric" linking operational systems for power, cooling and safety with NVIDIA's software stack and Omniverse digital twins through real-time application programming interfaces and partner integrations.^[5]

At GTC on 16 March 2026, NVIDIA's announcement of the Vera Rubin DSX AI Factory reference design listed DSX Exchange among the software libraries for partners to build on, saying it "enables scalable and secure integration of compute, network, energy, power and cooling plant signals between IT, operational technology and operations agents."^[10] The press release for the unified DSX platform, dated 31 May 2026 and tied to GTC Taipei, repeated that description and listed DSX Exchange among NVIDIA's trademarks.^[11] In a technical blog post published with that announcement, Warren Barkley, NVIDIA's vice president of product management for DSX, described DSX Exchange as "an MQTT-based IT/OT communication hub" that makes facility signals such as grid events, thermal data and power anomalies visible to the software managing the rest of the AI factory. He added that DSX OS components would provide MCP servers so that AI agents could "discover the entire operational surface of the factory as a unified tool catalog."^[12]

The project's CHANGELOG.md file has not been updated since v2.5.11 and still lists the DSX Agent Gateway bridge, Helm chart, local deployment and end-to-end validation under "Unreleased";^[6] later changes are recorded in GitHub release notes, and the Agent Gateway chart has been included in tagged releases since v2.7.0 (30 July 2026).^[7] Some of NVIDIA's documentation and the Agent Gateway chart metadata still point to github.com/NVIDIA/dsx-exchange; as of 1 November 2026 that address redirects to the repository in the dsx-ai-factory GitHub organization.^[31][15][2]

Design: a stateless, asynchronous bus

NVIDIA's documentation argues that polling breaks down at gigawatt scale, because every application cannot ask every other application for updates every second. DSX Exchange instead uses a push model in which a producer publishes a signal once and every interested consumer receives it. The documentation lists four principles: push rather than poll, publish once and fan out to many consumers, decouple producers from consumers, and converge on current state.^[16]

Leak detection is NVIDIA's main example. When a liquid-cooled rack leaks, host management, workload migration, facility response, alerting and analysis may all need to react, and waiting for a one-minute or five-minute poll is too slow. In the bus model the building management system (BMS) publishes the leak state once when it changes, and the bus delivers it to every subscriber.^[16]

The bus is "stateless by default." Messages carry current values rather than deltas (a temperature message says the temperature is 24, not that it rose by 2), sources republish current state periodically even when nothing changed, and consumers apply messages idempotently. NVIDIA presents this as a way to get eventual consistency and self-healing: a missed message, a stale cache or a consumer bug is corrected by the next publication.^[16] The integrator guide states that DSX integration contracts use MQTT QoS 0, and that QoS 1 and QoS 2 remain available for MQTT clients that need them, but QoS 1, QoS 2 and retained messages "must not be required for correctness."^[17] Retained messages are meant only to help new consumers start up with slow-changing context such as BMS metadata, and the documentation tells integrators to assume retained data can eventually be lost.^[16]

Requests that would normally be synchronous are modeled as published intent. A requester publishes the value it wants, and the owner of that state applies its own rules and publishes the result on its normal state stream, so the requester confirms the outcome by reading the same stream as every other consumer. In NVIDIA's coolant distribution unit (CDU) example, an integration publishes a requested liquid temperature setpoint; the BMS may apply it, ignore it, clamp it to a configured range or fall back to a local default, and the BMS-published target setpoint shows what it actually chose. NVIDIA recommends direct APIs instead of the bus when a caller needs an immediate answer from one known owner, such as provisioning a machine, rebooting a known host or creating a virtual private cloud.^[16]

DSX Event Bus architecture

Components

The event bus supports a three-node high-availability cluster with automatic failover, JetStream-backed persistent messaging, multi-cluster federation through leaf-node connections and declarative deployment with Helm charts that are compatible with ArgoCD.^[1] The repository README describes the bus itself as schema agnostic: the schemas document externally visible contracts, while NATS and the auth-callout service enforce routing, federation and authorization.^[2]

NVIDIA says it chose MQTT 3.1.1 rather than MQTT 5 because a major integration surface is building management and industrial operational technology (OT), where the industry "overwhelmingly ships MQTT 3.1.1 clients," and because NATS implements MQTT 3.1.1 only.^[1] Synadia's analysis made the same point and noted that the auth-callout service is NVIDIA's own Go service built on the standard NATS Auth Callout hook.^[13]

Cluster topology and topic spaces

An AI factory deployment has one Common Services Cluster (CSC) and one or more Control Plane Clusters (CPCs). Each is a separate Kubernetes cluster running its own NATS event bus, and the CPCs federate to the CSC over NATS leaf-node connections through a controller compatible with the Kubernetes Gateway API. The reference deployment uses Envoy Gateway, though NVIDIA says any conformant controller works.^[1] The default components per cluster are three main NATS replicas, one optional mTLS NATS instance, one auth-callout instance, one NACK controller for declarative JetStream stream management and one Surveyor Prometheus exporter.^[1]

There are two kinds of topic space. The CSC topic space is a unified namespace visible in every cluster, with CPC prefixes in topic paths (for example cpc.1.telemetry.temp); each CPC also has a local namespace with unprefixed names. Three Helm configuration lists (cpcExports, cscExports and cscPrefixedExports) control which topics are copied between layers. The documentation warns that a subject pattern appearing in more than one list creates cyclic NATS imports that crash the NATS pod with no error at install time.^[1]

MQTT topic separators (/) are mapped to NATS subject tokens (.), so the MQTT topic telemetry/temp becomes the NATS subject telemetry.temp.^[1]

Authentication

Every client connection is authenticated by the auth-callout service, a NATS Auth Callout that issues topic-level publish and subscribe permissions at connect time.^[18]

Each permissions entry places a client into a NATS account and lists the subjects it may publish and subscribe to. The service needs three NKey seeds, supplied as Kubernetes Secrets, for connecting to NATS, signing user JWTs and optionally encrypting callout responses.^[18] Metrics come from Surveyor and the auth-callout service in Prometheus format, traces go through OpenTelemetry to Tempo, and dashboards use Grafana.^[1]

Signal paths NVIDIA describes

The architecture page lists four signal paths that NVIDIA says the bus enables:^[1]

• BMS to Dynamic Power Software (DPS): real-time power telemetry so that DPS can close the DSX MaxLPS dynamic power allocation loop, which NVIDIA says recovers "up to 40% stranded capacity."
• BMS to the NVIDIA Infra Controller (NICo)^[12]: coolant leak events so that NICo can cordon nodes and migrate workloads "in seconds, not minutes."
• Grid to DSX Flex to the scheduler: demand-response curtailment signals so that the factory can shed load within seconds.
• GPU telemetry to thermal optimization agents: real-time thermal data so that predictive agents can adjust cooling setpoints before temperature spikes.

NVIDIA's MaxLPS documentation says DSX Exchange "carries the signals" between the grid, DSX Flex, facility systems and MaxLPS, but that Exchange and Flex integration is not a prerequisite for deploying MaxLPS; for a new site it recommends planning all three together.^[19] The DPS 0.10 release candidate added support for DSX Exchange integration, DSX Flex integration through DSX Exchange, and OAuth2 client-credentials authentication for the DSX Agent's MQTT connection to DSX Exchange.^[14]

Schemas and BMS integration

AsyncAPI contracts

The BMS integration guide

NVIDIA's companion guide for system integrators and BMS contractors calls DSX Exchange "NVIDIA's IT/OT integration layer within the NVIDIA DSX Software Suite," connecting BMS data to NVIDIA software such as the cluster manager, break-fix, power capping and optimization tools, digital twins and agentic AI applications.^[23] The guide's central point is that DSX Exchange defines the data contract at the MQTT layer rather than inside the BMS. The BMS can be any SCADA, PLC, DDC or controls platform suitable for a critical environment and can use any internal point naming, as long as what it publishes follows the AsyncAPI topic structure and payload format. The BMS does not have to run the broker.^[23]

Every point has two message types. A Value message carries the live reading as a numeric value, a Unix timestamp in milliseconds and a quality flag; it is published on change and republished every 100 seconds, uses QoS 0 and should not be retained. A Metadata message describes the point, including engineering units, the object it belongs to and its relationships; it is published at startup and then every 100 seconds, and the broker may retain it to speed up subscriber startup. Consumers must process metadata before they can interpret values.^[23] The last topic segment, {tagPath}, is vendor-defined and must be unique for each point; NVIDIA sets no format requirement for it.^[23]

The BMS publishes all metadata, including metadata for points whose values are written by IT integrations, and the guide says these rules are intended to be enforced through access control lists on the bus. In the guide's example, an AI agent called MEPAI computes an optimal CDU supply temperature and publishes a setpoint request on a topic derived from the BMS-published metadata. The guide says the BMS "is always the authority" on whether to apply such a request, recommends validating it against safety guardrails such as minimum and maximum limits and rate-of-change limits, and recommends reverting to a safe default if the integration stops publishing or sends an out-of-range value.^[23]

The guide defines 23 object types: Rack, PowerMeter, CDU, CoolingTower, HX (heat exchangers, including dry coolers), CRAH, CRAC, AHU, Chiller, Tank, Valve, Pump, Fan, Damper, Sensor, BESS, UPS, ATS, Generator, Shunt, Breaker, System and GenericObject. It calls Rack the most important, with standardized point types for rack liquid and power conditions such as supply and return temperature, flow, differential pressure, power, leak detection and isolation status. Two Rack point types, RackLiquidIsolationRequest and RackElectricalIsolationRequest, are actionable requests from IT systems that the BMS is expected to act on according to the NVIDIA Controls and Monitoring Reference Design.^[23] The guide treats that reference design plus the guide as covering about "99%" of a BMS publication, with the rest coming from specifications for each active integration on a deployment.^[23]

Deployment and validation

The DSX Event Bus is deployed per Kubernetes cluster with Helm, CSC first and then the CPCs. For evaluation, a make test target creates a local Kind cluster with a working event bus in about 10 minutes;^[24] NVIDIA estimates that the production path, including the secrets pipeline and certificates, takes 4 to 6 hours for a first-time deployment across one CSC and two CPCs.^[25] Production prerequisites include Kubernetes 1.27 or later, Envoy Gateway 1.5 or later (or a compatible Gateway API controller), MetalLB 0.13 or later (or a cloud load balancer), cert-manager, the Prometheus Operator, an OIDC provider such as Keycloak if OAuth2 is used, and a secrets pipeline that produces Kubernetes Secrets.^[24] The auth-callout container image is not published to a public registry, so operators build it from source and push it to their own registry.^[25] Release candidates of the charts and images are published to NVIDIA's NGC registry.^[26]

The repository's functional test suites cover MQTT 3.1.1 compliance, QoS 0, 1 and 2 delivery, retained and will messages, failover, CPC-to-CSC federation, OAuth2, mTLS and NKey authentication, and topic-based access control. The local environment also includes MQTT benchmark tooling; NVIDIA says these runs report the observed behavior of a given deployment and "do not define product targets."^[27]

DSX Agent Gateway

DSX Agent Gateway provides a single authenticated, tenant-aware /mcp endpoint through which MCP clients discover and call approved MCP servers.^[8] NVIDIA's documentation lists its uses as offering one endpoint for many MCP servers, deriving tenant identity from verified JSON Web Token (JWT) claims, limiting each tenant to an approved set of targets, applying per-tenant request limits, discovering MCP servers from Kubernetes Services or static HTTP endpoints, routing selected requests to remote gateway shards, and monitoring the whole path. The gateway does not replace authorization inside an MCP server: it forwards the caller's bearer token so that the server can enforce its own policy.^[8] Operators deploy the gateway; operators can reach every MCP server, while tenants reach the subset their policy allows.^[8]

Agent Gateway can be deployed without the DSX Event Bus when the gateway can reach every MCP target. The event bus becomes a runtime dependency only when the optional bridge is enabled.^[8]

Components

By default the chart runs three dataplane replicas, two rate-limit replicas, two replicas of an enabled bridge, one controller and a bundled Valkey with one primary and two replicas.^[29]

Request flow and tenant isolation

For a direct request, the edge forwards the HTTP request to the gateway's /mcp route. The dataplane verifies the JWT's issuer, audience, signature and validity against a configured provider, and a Common Expression Language (CEL) expression derives a nonempty tenant ID from the verified claims. The rate-limit service then applies that tenant's request budget, MCP authorization lets the operator tenant use all targets and limits every other tenant to configured target names, and the dataplane forwards the caller's original bearer token to the selected server, which applies its own authorization.^[28]

The chart rejects a tenant expression that reads request headers or does not reference verified jwt.* claims, so caller-supplied identity headers cannot set the tenant used for authorization or rate limiting. At least one JWT provider is required, each with a unique issuer, one or more allowed audiences, a JWKS URL and its own tenant expression.^[28] The gateway also strips caller-supplied internal identity and rate-limit headers, filters catalogs by tenant, and does not show target names to unauthenticated requests.^[30]

The default rate limit is 30 requests per second per tenant, with per-tenant overrides or unlimited tenants available. The default failure mode is FailOpen: if the rate-limit service or Valkey fails, requests continue without limit enforcement until the dependency recovers. Operators can choose FailClosed instead.^[31][30]

Target discovery

A selector target discovers Kubernetes Services by namespace and labels; each selected Service exposes a named port with appProtocol: agentgateway.dev/mcp, and the target name is formed from the Service name and port name (for example inventory-mcp). A static target points to a configured HTTP or HTTPS MCP endpoint and may use the Streamable HTTP transport or legacy Server-Sent Events (SSE).^[32][31] When the gateway aggregates several targets, tool and prompt names are published as <target>_<name>, and resource identifiers carry the target before the URI, as in inventory-mcp+inventory://servers/42. An unavailable target is omitted from catalogs while healthy targets stay available.^[30]

Bridge routing across shards

A shard is a deployment domain with its own Agent Gateway and MCP servers, typically a Kubernetes cluster or a logical site. With the optional bridge, an entry gateway routes to a bridge hub, and bridge leaves in each remote shard forward requests through their local gateway, using NATS request-reply traffic on the DSX Event Bus.^[8] Clients can call a bridge-provided dsx_bridge_list_shards tool to find reachable shards; the hub adds a required shard_id input to bridged tools and prompts and removes it before publishing the call to the chosen shard. The gateway in that shard repeats JWT verification, tenant derivation, authorization and rate limiting, and the bridge preserves the caller's Authorization header.^[28]

Bridged requests are stateless. The hub and leaves remove the Mcp-Session-Id header, the hub handles initialize and ping itself, and methods that need server-side MCP session state, client state or resource-path routing are unavailable.^[28] The bridge supports JSON and streamed SSE responses, and it does not retry an initial invocation after an ambiguous missing reply, which NVIDIA says prevents automatic replay of tool calls with side effects.^[30]

Network boundary and deployment

The chart creates a Kubernetes Gateway listener on plaintext HTTP port 80, with a ClusterIP Service by default and NodePort as the only other option. It does not create external certificates, cert-manager resources or a LoadBalancer Service: the operator owns the external edge, TLS termination and public address. Selector targets and bridge leaf-to-gateway traffic use HTTP inside the cluster, while HTTPS static targets get TLS from the gateway.^[28] Installation requires Kubernetes Gateway API v1.5.1 custom resource definitions and Agent Gateway v1.4.1 custom resource definitions, a reachable JWKS endpoint for each JWT provider, and an external edge that can route HTTPS to the gateway Service.^[33]

DSX Agent Gateway is built on the open-source Agentgateway project: its controller and dataplane come from the upstream agentgateway chart, which NVIDIA's chart wraps. The dsx-agent-gateway Helm chart (version 0.3.0 as of 1 November 2026) describes itself as an "Agentgateway deployment chart with optional dsx-agentgateway-bridge routing, rate limiting, observability, and defaults." It pins the agentgateway chart v1.4.1 from the cr.agentgateway.dev registry and the Valkey chart 0.9.4 as dependencies.^[15] The repository README says "Upstream Agentgateway routes authenticated MCP requests to local MCP servers," while NVIDIA's own dsx-agentgateway-bridge adds remote discovery and request routing over the DSX Event Bus.^[2]

For clients, NVIDIA's quickstart uses the Streamable HTTP transport at /mcp with a bearer token from a configured JWT provider, and suggests MCP Inspector for interactive testing.^[9] The supported observability profile includes health endpoints, Prometheus metrics, structured logs, OpenTelemetry trace propagation and optional alert rules.^[30]

Limitations and caveats

• Preview status. DSX Exchange is a developer preview, and NVIDIA says its APIs and behavior may change without notice.^[1] NVIDIA's DSX press release also says many of the products and features it describes "will be offered on a when-and-if-available basis."^[11]
• Rate limits can lapse. With the default FailOpen setting, tenant limits go unenforced while the rate-limit service or Valkey is down.^[30]
• Authorization is shared. The gateway authorizes access to MCP targets, but the selected MCP server remains responsible for operation-level authorization.^[30]
• The bridge is a subset of MCP. Resource methods and anything that depends on server-side session state are unavailable on bridged requests.^[30]
• Delivery guarantees. Integrations are expected to use QoS 0 and periodic republishing; higher QoS levels and retained messages are not meant to guarantee correctness.^[17]
• Configuration hazards. Overlapping cross-layer export lists crash the NATS pod without an install-time error, and missing JWKS settings on a cluster cause its auth-callout to reject all OAuth2 connections silently.^[1][18]

Continue reading

• KubernetesKubernetes, often abbreviated K8s, is an open-source system for deploying and managing containerized applications across a cluster of machines.Mentioned 14 times above
• MMCP serverAn MCP server is a program that implements the Model Context Protocol (MCP) to expose tools, resources, and prompts to MCP clients running inside an AI application or AI agentMentioned 10 times above
• NNVIDIA DSXNVIDIA DSX is a platform from NVIDIA for designing, simulating, building and operating large-scale data centers that the company calls AI factories.Mentioned 4 times above
• NVIDIA OmniverseNVIDIA Omniverse is a scalable, multi-GPU real-time 3D graphics collaboration and simulation platform developed by NVIDIA for building and operating industrial digital twins and physical AI applications.Mentioned 4 times above
• NNVIDIA DSX MaxLPSNVIDIA DSX MaxLPS is a set of chip, thermal, system and software technologies from NVIDIA intended to get more AI throughput out of a data center whose power supply is fixed.Mentioned twice above
• Model Context ProtocolModel Context Protocol (MCP) is an open protocol for exchanging context and invoking capabilities between applications that use large language models and external programs or data sources.Listed in See also

More from See also

• NVIDIA DSX POD

More to read

• Nvidia
• AI Agents
• Data Center
• OpenTelemetry
• NVIDIA B200

Topics:AI AgentsAI InfrastructureData CentersNVIDIA

References

1. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11 ^12 ^13 ^14 ^15 ^16 ^17 ^18 ^19 ^20 ^21 ^22 ^23 ^24NVIDIA. "Architecture." DSX Exchange documentation (developer preview). Accessed November 1, 2026. docs.nvidia.com/...architecture
2. ^1 ^2 ^3 ^4 ^5 ^6NVIDIA (dsx-ai-factory). "dsx-exchange" GitHub repository and README. Accessed November 1, 2026. github.com/...dsx-exchange
3. ^1 ^2NVIDIA AI Infrastructure (@NVIDIAAIInfra). Post announcing DSX Agent Gateway. X, October 30, 2026. x.com/...2116225660246986976
4. ^NVIDIA. "NVIDIA DSX Platform." Product page. Accessed November 1, 2026. nvidia.com/...dsx
5. ^1 ^2 ^3James Mills. "NVIDIA Launches Omniverse DSX Blueprint, Enabling Global AI Infrastructure Ecosystem to Build Gigawatt-Scale AI Factories." NVIDIA Blog, October 28, 2025. blogs.nvidia.com/...omniverse-dsx-blueprint
6. ^1 ^2 ^3NVIDIA (dsx-ai-factory). "CHANGELOG.md." dsx-exchange repository. Accessed November 1, 2026. github.com/...CHANGELOG.md
7. ^1 ^2 ^3 ^4 ^5 ^6NVIDIA (dsx-ai-factory). "Releases." dsx-exchange repository (v2.10.0, October 2, 2026; v2.11.0, October 31, 2026). Accessed November 1, 2026. github.com/...releases
8. ^1 ^2 ^3 ^4 ^5 ^6NVIDIA. "DSX Agent Gateway Overview." DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...agent-gateway
9. ^1 ^2NVIDIA. "MCP Client Quickstart." DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...client-quickstart
10. ^1 ^2NVIDIA Newsroom. "NVIDIA Releases Vera Rubin DSX AI Factory Reference Design and Omniverse DSX Digital Twin Blueprint With Broad Industry Support." March 16, 2026. nvidianews.nvidia.com/...th-broad-industry-support
11. ^1 ^2 ^3NVIDIA Newsroom. "NVIDIA DSX Gives Infrastructure Builders the Playbook for AI Factories." May 31, 2026. nvidianews.nvidia.com/...infrastructure-ai-factory
12. ^1 ^2Warren Barkley. "NVIDIA DSX OS Delivers Open, Modular Software for Operating AI Factories at Scale." NVIDIA Technical Blog, May 31, 2026. developer.nvidia.com/...ting-ai-factories-at-scale
13. ^1 ^2Andrew Connolly. "NVIDIA Built Its AI Factory Event Bus on NATS." Synadia blog, June 1, 2026. synadia.com/...lt-its-ai-factory-event-bus-on-nats
14. ^1 ^2NVIDIA. "DPS 0.10 Release Notes." NVIDIA Dynamic Power Software documentation. Last updated October 20, 2026. docs.nvidia.com/...0.10.x
15. ^1 ^2NVIDIA (dsx-ai-factory). "deploy/dsx-agent-gateway/Chart.yaml." dsx-exchange repository. Accessed November 1, 2026. github.com/...Chart.yaml
16. ^1 ^2 ^3 ^4 ^5NVIDIA. "Why a Message Bus - Stateless Async." DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...stateless-async-bus
17. ^1 ^2 ^3NVIDIA. "Integrator Quickstart." DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...integrator-quickstart
18. ^1 ^2 ^3 ^4 ^5 ^6 ^7NVIDIA. "Authentication." DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...authentication
19. ^NVIDIA. "NVIDIA DSX MaxLPS Overview." NVIDIA DSX documentation. Accessed November 1, 2026. docs.nvidia.com/...overview
20. ^NVIDIA. "BMS Event Bus 1.0.0" (AsyncAPI schema overview). DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...overview
21. ^NVIDIA. "DSX Flex 1.7.0" (AsyncAPI schema overview). DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...overview
22. ^NVIDIA. "NICo Managed Host State Event Bus 1.0.0" (AsyncAPI schema overview). DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...overview
23. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10NVIDIA. "BMS Integration Companion Guide." DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...bms-integration
24. ^1 ^2NVIDIA. "Deployment." DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...deployment
25. ^1 ^2NVIDIA. "Pre-Deployment." DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...pre-deployment
26. ^NVIDIA. "Deploying Release Candidates." DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...release-candidates
27. ^NVIDIA. "Validation." DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...validated-capabilities
28. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11 ^12 ^13 ^14NVIDIA. "DSX Agent Gateway Architecture." DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...architecture
29. ^NVIDIA. "Operate DSX Agent Gateway." DSX Exchange documentation. Accessed November 1, 2026. docs.nvidia.com/...operations
30. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11 ^12 ^13NVIDIA. "Supported Capabilities." DSX Agent Gateway documentation. Accessed November 1, 2026. docs.nvidia.com/...supported-capabilities
31. ^1 ^2 ^3NVIDIA. "Configuration Reference." DSX Agent Gateway documentation. Accessed November 1, 2026. docs.nvidia.com/...configuration-reference
32. ^NVIDIA. "Publish an MCP Server." DSX Agent Gateway documentation. Accessed November 1, 2026. docs.nvidia.com/...publish-mcp-server
33. ^NVIDIA. "Deploy DSX Agent Gateway." DSX Agent Gateway documentation. Accessed November 1, 2026. docs.nvidia.com/...deployment

Show all 33 references