Skip to main content
osctrl
All solutions

GPU clouds

Find the bad node before it stalls the run

Compare driver, CUDA, NCCL, kernel, firmware, and package state across the fleet. Find the node that does not match before a customer workload finds it for you.

Self-hosted · Open source · No per-node license

Illustrative fleet check

gpu-east · driver baseline

48 answered

FLEET STANDARD

550.90.07
match drift

VERSION MISMATCH

gpu-east-032 · 535.129.03
review before admit

100s to 100,000s

Documented fleet scale

Self-hosted

Telemetry stays in your infrastructure

MIT licensed

Open source core with no per-node license

The failure pattern

Distributed training is only as healthy as its oddest node

Drivers, CUDA, NCCL, firmware, and kernel state all need to agree across a job. One value can drift while the node still looks healthy to your metrics and provisioning systems.

Drift has ordinary causes

  • A reimage stops halfway through
  • A rolling upgrade skips a rack
  • An RMA node returns on different firmware

GPU telemetry tells you a node is idle, hot, or unhealthy. Provisioning tells you what it tried to push. Neither is a live inventory of the host.

See the drift checks

Manual investigation

  1. A node rejoins on the previous driver

  2. Health checks pass and the node is scheduled

  3. The job stalls when the full collective starts

  4. The team compares hosts until the version mismatch appears

With osctrl in the loop

  1. The node enrolls into the right environment

  2. A scheduled inventory query returns live state

  3. The mismatched value lands in your existing data pipeline

  4. Your scheduler or operator decides whether the node is admitted

What you can ask

If it is on the node, you can query it

osquery covers the host directly. GPU and fabric details come through custom tables you deploy alongside it. osctrl schedules, scopes, and collects both through the same control plane.

Core osquery

Which nodes have a different CUDA or NCCL package installed?

Package drift after partial upgrades

Runs against the standard Linux package inventory available in osquery.

SELECT s.hostname, p.name, p.version
FROM system_info s
JOIN deb_packages p
WHERE p.name LIKE 'cuda%'
   OR p.name LIKE '%nccl%';
Core osquery

Which nodes loaded a GPU kernel module we did not expect?

Stray drivers and debug leftovers

Uses the built-in Linux kernel_modules table.

SELECT s.hostname, k.name, k.status, k.used_by
FROM system_info s
JOIN kernel_modules k
WHERE k.name LIKE 'nvidia%';
Core osquery

What else is running on a slow node?

Background work that competes with the job

Process inventory is available without a GPU-specific extension.

SELECT s.hostname, p.pid, p.name, p.path,
       p.user_time, p.system_time
FROM system_info s
JOIN processes p
ORDER BY (p.user_time + p.system_time) DESC
LIMIT 25;
Custom table

Which nodes are not on the approved driver, CUDA, and NCCL stack?

The version mismatch behind a stalled collective

GPU stack details require an osquery extension. This is an illustrative schema, not a built-in osquery table.

SELECT hostname, driver_version,
       cuda_version, nccl_version
FROM gpu_stack
WHERE driver_version != 'approved-version';
Custom table

Which GPU or NIC firmware differs from the rack baseline?

RMA returns and incomplete firmware rollouts

Firmware inventory requires a custom table backed by the tooling you already trust.

SELECT hostname, device, firmware_version
FROM accelerator_firmware
WHERE firmware_version != 'approved-version';
Custom table

Which InfiniBand ports are down or below the expected link rate?

Fabric conditions that present as slow jobs

InfiniBand state requires a custom table. osctrl can schedule and scope the query once that table is deployed.

SELECT hostname, device, state, rate
FROM infiniband_ports
WHERE state != 'ACTIVE'
   OR rate != 'expected-rate';

The distinction matters. osctrl does not create GPU data that the endpoint cannot expose. It gives your own tables the same fleet-wide execution, scope, and history as core osquery.

How it fits

Gate every node before it joins a job

osctrl supplies current state. Your scheduler, automation, or operator keeps ownership of the drain or admit decision.

  1. 01

    Bake in osquery

    Nodes enroll on boot with the environment secret included in your image process.

  2. 02

    Define the check

    Use core tables for host state and your own extension tables for GPU and fabric details.

  3. 03

    Query on a schedule

    Compare live node state at the cadence that fits your maintenance and admission workflow.

  4. 04

    Route the result

    Send results to Kafka, Splunk, S3, or another supported sink your automation already reads.

osctrl returns

Node state and query results

your system decides

admit review drain

Multi-tenant by design

Separate views for every cluster, region, and team

Each environment has its own enrollment secret, node scope, configuration, and log routing. Operators work inside the environments their role permits.

accepting nodes ENV 01

gpu-east

production · us-east

Enrollment
separate secret
Scope
cluster-a nodes
Results
Kafka · gpu-east topic
accepting nodes ENV 02

reserved-01

reserved capacity

Enrollment
separate secret
Scope
customer allocation
Results
S3 · dedicated bucket
accepting nodes ENV 03

gpu-west

production · us-west

Enrollment
separate secret
Scope
cluster-b nodes
Results
Splunk · west index

This is control-plane segmentation, not a promise that tenants receive their own portal. A reserved cluster can have a dedicated environment without exposing another customer's nodes or results in the same working scope.

Trust boundary

Read host state without instrumenting the training job

A GPU-cloud pilot should prove overhead on your image, query pack, and schedule. We will not publish a generic benchmark number before that test is repeatable.

Workload boundary

Host-side visibility

osquery reads operating-system state. osctrl does not instrument GPU kernels or your training code.

Resource boundary

Cadence you control

Set query schedules and osquery resource controls around the workload profile you operate.

Data boundary

Your control plane

Run osctrl in your infrastructure and route telemetry to destinations you manage.

Action boundary

No general remote shell

The node console is read-only and backed by osquery primitives instead of arbitrary command execution.

Built on osquery

MIT licensed osctrl core

Self-hosted data path

Start small

Run it on one rack this week

Keep the first test narrow. Enroll one environment, run the queries your team already needs, and measure the agent on a real workload before expanding.

A run is failing now

Start with live query and the node console to compare host state across the affected environment.

Open the usage docs

We want to pilot a rack

Map the image, environment, query pack, and result sink for a contained evaluation.

Plan the pilot

We are comparing options

Review the source, deployment model, and product boundaries before you involve the broader team.

Read the code

The core is open source. Your agents, data, and query definitions remain yours whether or not a commercial engagement continues.