Ray in Workbench
SkillDev toolsChoose and operate the supported Ray paths in Nebius Physical AI: native Jobs/Core development, guarded Train V2, Cosmos3 native Serve, or Fleet KubeRay.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Ray in Workbench skill
What this skill tells your AI
The instructions your AI receives, as published by nebius/nebius-physical-ai in skills/tools/ray-workbench/SKILL.md and read by ahel’s review.
Start with the consolidated guide. Use this skill to route a Ray request to behavior that current code actually supports.
Route the request
- Native Jobs or Ray Core GPU development: use
docs/testing/fast-source-iteration.mdand the guarded CLIP application undernpa/workflows/workbench/ray-clip-development/. - Ray Train: load
skills/tools/ray-train-synthetic/SKILL.md. The shipped path is a synthetic Ray Train V2 application submitted through native Jobs, not an NPA Train service or workflow. - Ray Serve: load
skills/tools/cosmos3-ray-serve/SKILL.md. Only Cosmos3-Nano has a first-class native Ray Serve path. - KubeRay: load
skills/tools/fleet/SKILL.md. Fleet supports only the reviewed, fixed CPU RayCluster policy documented indocs/fleet-kuberay.md. - Ray Data or Ray Tune: state that no first-class Workbench recipe, CLI, service, workflow, or artifact contract exists. A trusted user may submit their own Ray application through a supported native Jobs environment; do not imply that this makes Data or Tune a supported Workbench capability.
There is no npa ray or NPA Jobs controller. Native ray job owns application
submission, list, status, logs, and stop. SkyPilot owns the CLIP and Train hosts
and long-running service task. Fleet owns KubeRay infrastructure. The Cosmos
client owns verified S3 batch publication. Keep these lifecycle identities
separate.
Operating rules
- Before provisioning, use
npa workbench health preflight --checks nebius --json; add the selected capability's storage and model-access checks. - For SkyPilot references, run
npa skypilot bootstrapand resolveNPA_SKYPILOT_BINfromnpa skypilot status --bin-path. Never use ambient management Ray discovery orskyfromPATH. - Keep Jobs and GCS on private networking behind an authenticated loopback tunnel. Ray accepts trusted code and a namespace is not a tenant boundary.
- Use unique native submission IDs.
ray job stopmust reach terminal status before hosting teardown. - Preserve the path-specific artifact boundary before cleanup: checksummed CLIP output, Train checkpoints/exports, verified Cosmos S3 publications, or explicitly copied KubeRay application output.
- Cancel exact application jobs before the exact SkyPilot service task or owned Fleet target. Preserve shared clusters, APIs, controllers, projects, and storage unless their ownership is separately established.
Do not add Ray Data/Tune examples, GPU KubeRay, RayService, a Jobs wrapper, or a
new npa.workflow surface without implementation and live evidence. Do not
describe multiple GPUs on one node as multi-node proof; require actual Ray node
and physical-host evidence.
Verify
npa/.venv/bin/python -m pytest npa/tests/guardrails/test_skills_index.py -q
npa/.venv/bin/python -m pytest --collect-only -q
Signals
- GitHub stars
- 28
- Forks
- 15
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
ray-workbench- Source
- github.com/nebius/nebius-physical-ai