Developer guide on TauGrid

Run your first target

Mon, 01 Jan 0001 00:00:00 +0000

Prerequisites:

The Tau CLI is installed.
The repository contains a workspace connection and a checked-in target, such as tau/train.yaml.
The platform workspace reports Ready.

tau run is the config-first entry point. Its optional positional TARGET argument resolves to a checked-in tau/<target>.yaml file. See the direct run config reference for the full tau.yaml field set. tau run automatically discovers the checked-in workspace connection.

Validate before submitting a real workload:

Share research with a teammate

Mon, 01 Jan 0001 00:00:00 +0000

Researchers working from different machines can use the same cluster and workspace to view and compare the same runs, logs, and charts.

Access model used in this guide

This guide describes the current interim admin-access workflow. The cluster owner gives each researcher their own cluster-admin kubeconfig. Each researcher keeps those credentials on their own machine and uses a separate port-forward to the shared Portal Service.

Serve a trained model

Mon, 01 Jan 0001 00:00:00 +0000

tau serve turns a project-owned image and optional durable checkpoint into a service. Choose:

--kind=rayservice (default) for a Ray Serve application; KubeRay must be installed and the image must expose the specified Python import path.
--kind=deployment for a plain Kubernetes Deployment such as a raw vLLM, TGI, Triton, or custom HTTP server.

You need a platform-provided serving profile, a pinned image, the target namespace/context, and a checkpoint visible from the serving PVC when the endpoint loads model state.