Kronos workers (embedded)

A Kronos worker is the container that actually compiles your model. It runs on the hardware you compile for (a Jetson, Drive AGX, or dGPU box), detects that hardware, registers with the router, and builds an engine for every compile routed to it. Deploy one before your first compile — it stays up and serves all of them.

It's two steps: pick the image that matches your hardware, then deploy it — on a single host with Docker, or on a Kubernetes cluster with Helm.

Fastest path: let the agent do it

From your reference machine, launch yasp and say "deploy an embedded worker to <host>" — the deploy-embedded-worker skill detects the arch_spec, version, and GPU flags and runs everything for you. The Docker guide is the manual equivalent, run on the target machine (SSH in first): it needs Docker, the NVIDIA Container Toolkit, and curl — not yasp-agent.

Step 1 — Pick the image for your hardware

An arch_spec reads left to right as OS · CUDA · TensorRT · Python. For example u2404-cu129-trt1014-py311 = Ubuntu 24.04, CUDA 12.9, TensorRT 10.14, Python 3.11.

SSH into the target machine and read off each part, in that order:

Part	Example	How to check on the target
OS	u2404 (Ubuntu 24.04), jp512 (JetPack 5.1.2), dos6010 (DriveOS 6.0.10)	dGPU: grep PRETTY_NAME /etc/os-release · Jetson: dpkg-query --show nvidia-jetpack · Drive AGX: your DriveOS version
CUDA	cu129 (12.9)	dGPU: nvidia-smi → "CUDA Version" (the driver's max) · Jetson/AGX: fixed by JetPack/DriveOS — no need to check
TensorRT	trt1014 (10.14)	pre-installed in the image — nothing to check
Python	py311 (3.11)	pre-installed in the image — nothing to check

Jetson and Drive AGX

nvidia-smi isn't present on these — identify the platform by its JetPack / DriveOS version, which alone determines CUDA, TensorRT, and Python (e.g. JetPack 5.1.2 → jp512-cu122-trt85-py311).

CUDA, TensorRT, and Python come bundled in the image — pick the published combo that matches your target host and copy its <arch-spec>:

Target host	<arch-spec>
Ubuntu 20.04 dGPU	u2004-cu114-trt86-py311
Ubuntu 22.04 dGPU	u2204-cu126-trt104-py311
Ubuntu 24.04 dGPU	u2404-cu129-trt1014-py311
Jetson, JetPack 5.1.2	jp512-cu122-trt85-py311
Jetson, JetPack 6 (Orin)	jp61-cu126-trt103-py311
Drive AGX (DriveOS 6.0.10)	dos6010-cu114-trt86-py311

The full image path is docker.yasp.ai/yasp-inference/backend/<arch-spec>:v<version> — the deploy guides below resolve the newest <version> for you.

No arch_spec matches your hardware?

Request one from support@yasp.ai with:

• Target hardware — e.g. Jetson Orin AGX, Drive AGX, or dGPU model
• OS / platform version — Ubuntu, JetPack, or DriveOS version
• CUDA and TensorRT versions
• Python version

Step 2 — Deploy the worker

Pick the path that fits your infrastructure — each guide is self-contained (it mints the registry key, resolves the latest image, and starts the worker):

	Use when	Guide
Docker	one host — a single Jetson / AGX / dGPU box	Deploy with Docker
Helm	a Kubernetes GPU cluster or fleet	Deploy with Helm

When the worker is up, it appears in yasp-toolkit embedded workers with its advertised arch_spec — the value you pass to --arch-spec when you compile.

Image arch_spec ≠ advertised arch_spec

The string in the image path is not what the worker advertises. On registration it prepends the CPU and detected GPU arch — e.g. image u2404-cu129-trt1014-py311 registers as amd64-sm120-u2404-cu129-trt1014. Always copy the advertised value from embedded workers, not the image name.

Tags & routing

The worker authenticates with your API key (YASP_API_KEY) or a worker key scoped just to registration, and can carry tags set at registration — --tag key=value (Docker) or worker.tags.* (Helm):

• host=<name> — target a specific box later when several workers share an arch_spec.
• routing — which pool the worker joins:
  • default (no routing tag) — the shared stable pool, where compiles route unless told otherwise.
  • routing=<name> — a separate pool for testing; target it with yasp-toolkit embedded compile --routing <name>.