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 yasp-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 — but the token is major.minor only, so check the exact build in the table below against your runtime |
| 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>. If you plan to run the compiled engine anywhere other than this worker, match the TensorRT column to that machine's TensorRT build:
| Target host | <arch-spec> |
TensorRT |
|---|---|---|
| Ubuntu 20.04 dGPU | u2004-cu114-trt86-py311 |
8.6.13.3 — the DRIVE OS 6.0.10 x86 host build |
| Ubuntu 22.04 dGPU | u2204-cu126-trt104-py311 |
10.4.0.26 |
| Ubuntu 24.04 dGPU | u2404-cu129-trt1014-py311 |
10.14.1.48 |
| Jetson, JetPack 5.1.2 | jp512-cu122-trt85-py311 |
8.5.2.2 |
| Jetson, JetPack 6 (Orin) | jp61-cu126-trt103-py311 |
10.3.0.30 |
| Drive AGX (DriveOS 6.0.10) | dos6010-cu114-trt86-py311 |
8.6.13.3, mounted from the DRIVE host |
Engines are locked to the exact TensorRT build
The trt<ver> token in an arch_spec is only the major and minor version, so trt86 alone does
not tell you which 8.6.x built your engine. A serialized engine deserializes only under the
exact major.minor.patch.build that produced it — an engine from 8.6.13.3 will not load on
8.6.1.6, and vice versa. Match your runtime to the TensorRT column above before you compile.
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
routingtag) — the shared stable pool, where compiles route unless told otherwise. routing=<name>— a separate pool for testing; target it withyasp-toolkit embedded compile --routing <name>.
- default (no