AutoGineer
Generated banner for Tao Run Dinov3 Ssl Deft
Generated logo for Tao Run Dinov3 Ssl Deft

Tao Run Dinov3 Ssl Deft

NVIDIAOfficialCreated by NVIDIA Corporation

  • Skill
  • Workflow
  • Data and AI
  • Apache-2.0
  • Medium risk
Download ZIP

From the author

Run iterative DINOv3 SSL DEFT data selection and retraining from an unlabeled pool, using GRIT or multi-task weakness and fixed-encoder retrieval. Use for active-learning-style DINOv3 mining, not plain pretraining/fine-tuning (tao-train-dinov3) or AOI/PAS DEFT.
— the description by NVIDIA Corporation

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a command-line interface for managing iterative DINOv3 SSL DEFT (Data-Efficient Fine-Tuning) workflows. It enables active-learning-style data mining from an unlabeled pool using GRIT or multi-task weakness scoring. The workflow relies on fixed-encoder retrieval and requires a specific Data Services container environment to handle data selection, retrieval, and retraining loops.

What it does

  • Initializes and validates DINOv3 mining recipes.
  • Manages iterative data selection and retraining rounds.
  • Supports GRIT scoring for target ranking.
  • Integrates with fixed-encoder embedding preparation.
  • Provides lifecycle commands for planning, running, and monitoring jobs.
  • Generates reports and tracks state across training rounds.

When to use it

  • When performing active-learning-style data mining for DINOv3 models.
  • When you need to select and retrain on data from an unlabeled pool.
  • When utilizing GRIT or multi-task weakness scoring strategies.
  • When working within an environment that supports the required Data Services container.

Advantages

  • Automates the iterative loop for data selection and model retraining.
  • Ensures consistency through immutable configuration and data contracts.
  • Provides structured monitoring and reporting for mining stages.
  • Decouples training logic from the orchestration controller.

Usage examples

“Initialize a new DINOv3 mining recipe using the grit-score strategy.”
Generates a run.yaml configuration file ready for path and resource customization.
“Validate the configuration for a DINOv3 DEFT workflow.”
Checks the configuration against the workflow schema and verifies container readiness.
“Start the mining workflow using the configured run directory.”
Executes the iterative selection and training rounds as defined in the plan.
“Check the status of an ongoing mining run.”
Returns the current progress, stage, and round information for the specified run directory.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/nvidia/tao-run-dinov3-ssl-deft/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip tao-run-dinov3-ssl-deft.zip -d .agents/skills

Documentation by NVIDIA Corporation

DINOv3 SSL DEFT

The DS-packaged Python controller owns the loop and durable state. This skill prepares and approves its inputs; it does not implement orchestration.

Instructions

  1. Resolve the DINOv3 model using the model resolver. Choose grit-score for unlabeled target ranking; its scorer is built in. Offer multi-task-round-robin only when the user already has a score adapter that meets the task scoring contract: DS ships no multi-task scorer, and validate rejects the recipe's placeholder. Read architecture.md for the scientific meaning, task weighting, and stopping policy.

  2. Read tao-container-integration.md. Check release readiness before offering a launch: the resolved images.tao_toolkit.data_services image must be a release build whose installed packages contain the reviewed DEFT modules and pass packaged validation. An older DS build is not sufficient. The placeholder rejection (step 1), the cohort checks and the canceled-run exit code 143 need a DS build that contains tao-data-services#59: the first DS 7.3.0 RC after rc-90. DS rc-90 and older accept the placeholder at validate, fail in round 1 with Missing configured inputs: [... 'score_implementation_0'], and exit 0 after a cancel. The release/7.3.0 cherry-pick of this skill must bump images.tao_toolkit.data_services in versions.yaml to that RC. The executable profile is one allocated DS container; no external runner ships with this application. For release QA, the repository script scripts/deft_container_handoff.py runs each repository's regression tests (--suite source) and the shipped package checks (--suite packaged) inside the approved images; the packaged suite also rejects a DS image that predates #59. Run it from clean checkouts of the release SHAs; the default --base-ref origin/main diffs each release from its merge base. It is a QA tool, not a launcher.

  3. Follow the selected platform's launch gate. For Docker, use the concrete allocation, preflight, and docker exec lifecycle in the integration reference. Inside that runtime, follow the preparation sequence in adapter-contracts.md: produce source/target embeddings with the same fixed encoder, register the source store with its payload contract, and write the target contract. No additional host/model package installation is needed. Generate a packaged recipe with init, fill paths/resources, then run validate <config>, preflight <config> --gpu in the launch runtime, and plan <config>. Read adapter-contracts.md when declaring a held-out benchmark (isolation), or configuring custom scoring/evaluation, indexed retrieval, or resource policies.

  4. Inspect the plan and present the approval contract below. Read references/skill_info.yaml:path_contract as the input-mount checklist: every applicable path must be visible in the allocated container, and output.run_dir must match the platform's durable results directory. Skill Bank resolves image keys on the host; DS accepts explicit image references only and never reads this repository at runtime.

  5. After approval, execute run <config> inside the allocated container. Monitor to a terminal result using the commands below. Do not modify controller state or locks manually.

Approval contract

Populate these six items from preflight and the plan, not from assumptions:

  • Loop: chosen strategy, maximum rounds, stops, evaluation scope and patience. For multi-task-round-robin, the user's score adapter command and its implementation_files.

  • Data: immutable target/source versions, verified row/shard counts, parent history, storage capacity and mount locations. For any held-out benchmark, the identity sidecar and its declared columns, even with evaluation disabled, and preflight's contracts.benchmark_isolation (at least 1; otherwise stop) (held-out benchmark isolation).

  • Sampling: fixed target budget, resolved integer task quotas, neighbors, radius/floor and duplicate thresholds; index, audit, probes/depth for ANN.

  • Training: passes, resolution, resources/update floor and immutable original checkpoint. Every candidate starts from that checkpoint, never its predecessor. Check the per-round update budget against LR warm-up and last-layer freeze; follow short-round schedule sizing.

  • Cache/output: read-only images/embeddings, any platform cache, node-local TAO_LOCAL_SCRATCH, cumulative locator manifests, checkpoint retention, and durable results directory.

  • Monitoring: cadence, stage/round updates, retry/failure handling and final reason.

Do not request launch approval while any of these items is unknown.

Lifecycle and monitoring

All commands below follow python -m nvidia_tao_ds.mining.dinov3.workflow inside the same allocated DS runtime:

  • preflight [<config>] [--gpu] (with the config, also checks the allocation)

  • init --recipe grit-score --output run.yaml (or multi-task-round-robin, which needs the user's score adapter; see step 1)

  • validate <config>, plan <config>, run <config>, resume <config>

  • status <run_dir> [--config <config>]

  • logs <run_dir> <client_job_id> [--cursor <cursor>] [--config <config>]

  • cancel <run_dir> [--config <config>]

  • report <run_dir> [--config <config>]

  • adopt-training <continuation_config> only for an explicitly approved continuation into a new run directory.

Read the job ID from status before requesting logs. Resume takes the config path, not the run directory. Cancellation is terminal for that run: run and resume then exit with code 143, not 0. Use an explicit new-run continuation when appropriate.

Keep monitoring attached until the workflow is terminal. Use the user's cadence, otherwise about five minutes for short stages and 20–30 minutes for long search/training stages. Report stage/round transitions, mining yield, metrics, retries, failures, and the final stop reason. Submission is not success. If the container has exited, use the integration reference's read-only inspection recipe rather than attempting docker exec against it.

Related Skills

  • tao-train-dinov3: ordinary DINOv3 training without a mining loop.

  • tao-launch-workflow, tao-run-on-docker, tao-data-io: launch and storage.

  • tao-run-deft-aoi, tao-run-deft-pas: different supervised DEFT workflows.

Files

references/tao-container-integration.md

DINOv3 SSL DEFT container lifecycle

Data Services owns the controller and includes TAO PyTorch/Core. No host TAO installation, nested Docker, Dockerfile change, or startup package replacement is required by the single-container design.

Release readiness

This application uses the release-managed images.tao_toolkit.data_services image from versions.yaml, selected by skill_info.yaml. There is no separate DEFT image or DINOv3-specific image key. Use the supported release checkout; main is development source and its default image need not contain pending changes. Resolve the image from that checkout, never copy a tag from prose.

The release team builds DS with the reviewed DS/PyTorch packages and updates the release image pins. Before rollout, validate that exact image's installed packages with workflow preflight, packaged regression tests and GPU smoke tests. In particular, verify held-out benchmark exclusion, rejection before materialization seals, and fresh-start training with auto-resume disabled. An image built before the fixes must not be reported as containing them merely because its tag is newer or because source-overlay tests pass. Record the resolved digest and test results in the release evidence; do not patch packages at container startup. A rebuild and pin update belong to the release handoff, not to a parallel application-specific image lifecycle.

Source-overlay QA demonstrates source compatibility only. It is not evidence that the published image contains these modules. The ANN path additionally requires an approved CUDA-compatible cuVS dependency; the exact-search profile does not. Never silently change an approved search backend.

Docker: preparation and execution

Read the Docker platform skill for its host preflight, secure registry login, job-record opening, UID/GID mapping, cache variables and GPU selection. Resolve the approved application image on the host with:

DEFT_TAG=$(python scripts/resolve_tao_image.py --skill-bank . --application tao-run-dinov3-ssl-deft \
  --action run --format json | python -c 'import json, sys; print(json.load(sys.stdin)["image"])')

Run it from the Skill Bank checkout; without --skill-bank the resolver reads $TAO_SKILL_BANK_PATH or ~/tao-skill-bank, which can be a different bank.

Show DEFT_TAG to the user and accept an explicit override. Then pin the digest, because a tag can move between preflight and launch:

docker pull "$DEFT_TAG"
DEFT_IMAGE=$(docker image inspect --format '{{index .RepoDigests 0}}' "$DEFT_TAG")

RepoDigests is empty for an image that was never pulled from a registry; stop in that case. Every docker run below takes $DEFT_IMAGE. DS does not read Skill Bank or versions.yaml.

The example below assumes the platform has prepared these reviewed bindings: DEFT_IMAGE is the tested image digest, DEFT_ROOT contains config, data, checkpoints and outputs, DEFT_SCRATCH is a writable node-local directory, and DEFT_GPU is the allocated host GPU identifier. The GRIT score action writes its work files to $TAO_LOCAL_SCRATCH; without it the first score stage fails. All paths in the YAML use the container's /deft namespace. DEFT_IDENTITY_ARGS and DEFT_CACHE_ARGS are the Docker skill's non-root identity and writable cache arguments. Do not inline credentials.

DEFT_MOUNTS=(-v "$DEFT_ROOT:/deft" -v "$DEFT_SCRATCH:/scratch")
DEFT_RUNTIME=(--gpus "device=$DEFT_GPU" --shm-size=8g -e CUDA_VISIBLE_DEVICES=0 -e TAO_LOCAL_SCRATCH=/scratch)
DEFT_COMMAND=(python -m nvidia_tao_ds.mining.dinov3.workflow)

docker run --rm "${DEFT_RUNTIME[@]}" "${DEFT_IDENTITY_ARGS[@]}" "${DEFT_CACHE_ARGS[@]}" "${DEFT_MOUNTS[@]}" "$DEFT_IMAGE" "${DEFT_COMMAND[@]}" preflight --gpu
docker run --rm "${DEFT_IDENTITY_ARGS[@]}" "${DEFT_CACHE_ARGS[@]}" "${DEFT_MOUNTS[@]}" "$DEFT_IMAGE" "${DEFT_COMMAND[@]}" init --recipe grit-score --output /deft/run.yaml
# Fill reviewed paths/resources and set execution.backend: local.
docker run --rm "${DEFT_IDENTITY_ARGS[@]}" "${DEFT_CACHE_ARGS[@]}" "${DEFT_MOUNTS[@]}" "$DEFT_IMAGE" "${DEFT_COMMAND[@]}" validate /deft/run.yaml
# With the config, preflight also checks each action's scratch, GPU count and,
# when execution.capabilities.gpu_faiss is set, GPU FAISS.
docker run --rm "${DEFT_RUNTIME[@]}" "${DEFT_IDENTITY_ARGS[@]}" "${DEFT_CACHE_ARGS[@]}" "${DEFT_MOUNTS[@]}" "$DEFT_IMAGE" "${DEFT_COMMAND[@]}" preflight /deft/run.yaml --gpu
docker run --rm "${DEFT_IDENTITY_ARGS[@]}" "${DEFT_CACHE_ARGS[@]}" "${DEFT_MOUNTS[@]}" "$DEFT_IMAGE" "${DEFT_COMMAND[@]}" plan /deft/run.yaml

Do not request approval until the config preflight passes: validate and plan do not check the runtime allocation.

After approval, the Docker platform opens the job-record and binds output.run_dir to its results directory. Its returned JOB_ID names the detached controller container. Preserve the platform's record-then-launch order:

docker run -d --name "$JOB_ID" --label "tao-job=$JOB_ID" "${DEFT_RUNTIME[@]}" "${DEFT_IDENTITY_ARGS[@]}" "${DEFT_CACHE_ARGS[@]}" "${DEFT_MOUNTS[@]}" "$DEFT_IMAGE" "${DEFT_COMMAND[@]}" run /deft/run.yaml
docker exec "$JOB_ID" "${DEFT_COMMAND[@]}" status /deft/results
# Obtain CLIENT_JOB_ID from status, then:
docker exec "$JOB_ID" "${DEFT_COMMAND[@]}" logs /deft/results "$CLIENT_JOB_ID"

The status/logs commands are explicit docker exec operations against the running controller, not separate submissions to the platform. Use the platform's Docker inspect/log verbs as well: a persisted workflow state is not proof that the container is alive. Cancel through workflow cancel /deft/results while the container is alive; SIGTERM to its main process also records cancellation.

After exit, docker exec is unavailable. Inspect the retained container with the platform verbs and inspect durable state using the same image and a read-only mount (with separately writable temporary caches):

docker run --rm "${DEFT_IDENTITY_ARGS[@]}" -e USER=tao -e LOGNAME=tao -e HOME=/tmp -v "$DEFT_ROOT:/deft:ro" "$DEFT_IMAGE" "${DEFT_COMMAND[@]}" status /deft/results
docker run --rm "${DEFT_IDENTITY_ARGS[@]}" -e USER=tao -e LOGNAME=tao -e HOME=/tmp -v "$DEFT_ROOT:/deft:ro" "$DEFT_IMAGE" "${DEFT_COMMAND[@]}" logs /deft/results "$CLIENT_JOB_ID"

For a failed (not canceled) workflow, submit a new container/job-record with the same image, mounts and resources and resume /deft/run.yaml. Do not restart the old container concurrently. The application data stays in the durable mount; removing an inspected terminal container does not remove those results.

Allocation, storage and recovery

Use execution.backend: local, omit container_images, and pin CUDA_VISIBLE_DEVICES to the assigned allocation. GPU-consuming actions must request exactly that visible GPU count; the controller does not discover or claim unallocated devices. The recipe's one-GPU torch_exact scoring avoids a GPU FAISS dependency. Explicit faiss_exact must pass a GPU FAISS probe.

The run directory must support reliable POSIX flock, atomic rename and fsync (including directories). Do not use CIFS with nobrl, or NFS mounts without working cross-client locks. Inputs are immutable and mounted read-only where practical; outputs and scratch are separate writable locations.

Cancellation is terminal; resume adopts failed/interrupted work, not a canceled run. When a dead local session leader has live descendants, the runner reports UNKNOWN and does not signal unverified process identities. Inspect the recorded PID/start time, descendants and allocation on the host, stop only verified survivors, then confirm termination before retrying. Never remove a lock file to force recovery. Config or native action-code changes require a new run and the explicit adopt-training handoff where appropriate.

External execution boundary

The DS runtime retains its four-verb external adapter interface, but neither DS nor Skill Bank ships a Slurm/Kubernetes/separate-image runner executable for this application. That deployment is unsupported until a named, tested runner is supplied and reviewed. Do not present a placeholder executable as a runnable recipe. The interface and attestation requirements remain in adapter-contracts.md for integrators.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Needs Python, Needs Node.js

The author says: Requires the selected platform's native launcher and a TAO Data Services image containing the DINOv3 SSL DEFT modules; no host TAO or Python data-stack installation.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
NVIDIA Corporation
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/tao-run-dinov3-ssl-deft · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA Corporation or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download tao-run-dinov3-ssl-deft.zip