Architecture
Wingsmith picks clusters; each cluster picks its own devices. An operator in every cluster dials out, renders NVIDIA Dynamo deployments, and reports what it observes. Inference takes a separate path through the gateway.
01 / Topology
The control path and the request path share no process, and every connection is opened from inside the cluster.
An operator runs in every cluster, opens a single WebSocket to the hub, receives Wingsmith's own domain objects, renders them into a Dynamo graph with vLLM, SGLang or TensorRT-LLM as the engine, and reports what it observes back up. The plane holds no kubeconfigs.
The gateway takes OpenAI-compatible requests and forwards them over an HTTP/2 tunnel that the agent in each cluster dials out to, using a routing table the plane derives and the gateway caches.
Clusters keep serving when the control plane is down, and a running gateway keeps routing from its cached table. A gateway that restarts during the outage cannot load a table and stays down until the plane is back.
02 / Principles
Declared objects are written by the plane and obeyed by the cluster. Observed objects are written by the cluster and read by the plane. Operations are imperative, long-running, and able to fail.
Drain is not a field on a node. It is cordon, evict, wait for in-flight requests, confirm, and possibly time out. It has a lifecycle, an actor, a reason, and a failure mode.
The plane sends Wingsmith's own Deployment, Pool, and Operation. The operator in each cluster expands them into whatever Kubernetes objects it currently favors.
All knowledge of Kubernetes stays on the cluster side. That is what lets the fleet be non-uniform: the operator absorbs the differences.
Cluster selection is global, coarse, and infrequent: capacity, device class, region, residency, cost. It lives in the plane.
Device selection is local, hot, and frequent: bin-packing and topology. It stays with the scheduler inside the cluster.
If it did, the control plane's availability would become the availability of every model it manages.
The gateway is the one process in the request path. It keeps serving from its last routing table when the plane is unreachable, but needs the plane to start.
03 / Object model
The console and hgr are two clients of the same HTTP API over these objects.
| Group | Objects | Owner |
|---|---|---|
| Supply What capacity exists | Cluster, Node, Device, TopologyDomain, Pool | Cluster observes; Cluster and Pool are also declared |
| Demand What should be running | Artifact, Workload, Deployment, Replica, Endpoint | Plane declares; Replica is observed |
| Binding Where supply and demand meet | Tenant/Project, Quota, PriorityClass, Policy, Allocation | Plane declares; Allocation is observed |
| Machinery What makes it operable | Component, Operation, Event, CacheEntry, Credential | Mixed |
The schedulable unit is the accelerator, not the node. Topology (NVLink, NVSwitch, PCIe, NUMA) is an object rather than an annotation, and heterogeneity across the fleet is a placement constraint.
04 / Lifecycle
What you serve, how you serve it, where it runs, and the name clients call are four separate objects.
Immutable, content-addressed weights with their format, digest, license, and storage locations. Kept separate from how they are served.
Models already running in a cluster are discovered and observed first. Bringing one under management is an explicit decision, and it does not restart the model.
05 / Components
Paths and binary names are from the current pre-release codebase, which still uses its original names.
| Path | Language | What it is |
|---|---|---|
libs/plane | Python | The control plane: the HTTP API, the hub that terminates operator streams, and the reactor that derives alerts. One package, three processes, one Postgres. |
libs/operator | Go | hangar-operator, one per cluster. Syncs desired state from the hub into CRDs, renders each deployment as an NVIDIA Dynamo graph, and reports observed state. |
libs/gateway | Go | The data plane. One OpenAI-compatible hop that routes on model, terminates the agents' tunnels, and identifies tenants. |
libs/agent | Go | hangar-agent, one per cluster. Dials out to every gateway replica and proxies inference to the model's frontend inside the cluster. |
libs/console | TypeScript | The web console. Talks to the plane's HTTP API only, and runs against built-in fixtures with no backend. |
libs/cli | Go | hgr, the command line. Same API as the console, with stable JSON output and an offline --fake backend. |
libs/chart | Helm | cluster-setup: the operator, the agent, CRDs, the NVIDIA Dynamo platform, the DCGM exporter, and optional monitoring. |
libs/packages/contract | Markdown, JSON | The plane-operator wire protocol, the HTTP API conventions and OpenAPI schema, the device-class table, and a shared fixture corpus. |
libs/packages/tunnel | Go | Both ends of the gateway-agent tunnel, in its own module because neither side owns it. |
libs/benchmarking | Python | hgrbench. Four load generators against one OpenAI-compatible endpoint, reported side by side. |
libs/transit | Go | hgrtransit. Measures the request path on one host, with no GPU and no cluster. |
libs/conformance | Python | hgrconform. Probes an OpenAI-compatible endpoint and diffs its behavior against a reference provider. |
07 / Scope
Standalone, inference-only for now, NVIDIA Dynamo inside each cluster, and built for an organization that owns every cluster it manages.
Status
Wingsmith is pre-release. The first public release, and everything after it, will be under Apache 2.0.
Multi-cluster placement and routing, Dynamo deployments, device inventory, endpoints and quotas, the console, the CLI, and three measurement tools.
Published images and charts, per-user roles and SSO, batch and training workloads, and a Helm chart for the control plane.
Pre-release. No tagged release, images, or charts yet, and APIs and protocols can change.