Your first passing run, step by step.

The starter kit is a complete, known-correct submission: an optional environment Dockerfile plus a small example program that runs the official EVA‑02‑L checkpoint with the exact reference settings. It exists to take every mystery out of your first run, from build and upload to score and pass, so that from your second run on, the only question left is speed. It is deliberately slow, and every part of it may be replaced.

One submission, two uploads

• Every run is assembled from two parts you control: an environment and a submission.
• The environment is an immutable ARM64 container image built once from a Dockerfile you paste into the site. Its build may download from the public internet and is never timed.
• The submission is a small source archive whose build.sh runs on top of a ready environment in a second untimed step and must produce one executable, /submission/run.
• Only that executable is timed: offline, on the frozen host, against the private 10,000-image cohort.
• Put slow dependency installation and model weights into the Dockerfile; put preparation you want off the clock into build.sh. Everything /submission/run does is on the clock: interpreter startup, model loading, JPEG decoding, inference, and output.
• Neither untimed step ever sees the private cohort — images, manifest, and answers exist only inside the scored run — so the clock can exclude preparation, never the work itself.
• The split is also the cost model. An environment build consumes no attempt: retry a slow download freely, then reuse the ready image for every submission after it. build.sh runs inside each charged attempt, and a build failure or timeout consumes it — so weights belong in the Dockerfile and build.sh is best kept trivial.

1. Build the environment

Sign in and open New environment. The form comes pre-filled with this checked-in starter Dockerfile; give it a name such as EVA-02 FP32 starter and queue the build:

# Optional known-correct ARM64 starter: Python 3.12, PyTorch 2.13.0+cu130,
# torchvision 0.28.0, Pillow, safetensors, and timm. You may replace the FROM line
# with any permitted ARM64 image if another stack suits you better.
FROM imagenet-contest-base:cu130-torch213

# build.sh must create an executable that the judge invokes as:
#   /submission/run MANIFEST IMAGE_ROOT OUTPUT
# Nothing in this starter is attested. Other images must provide /bin/sh, and
# their GPU software must be compatible with the host NVIDIA driver.
#
# Build limits: public internet only; no ADD; external stages only from
# docker.io, ghcr.io, or nvcr.io; final environment image at most 16 GiB.
# See the Rules & ABI page for the complete policy.

• The FROM line names a CUDA-enabled image already present on the host with Python 3.12, PyTorch 2.13.0, torchvision 0.28.0, timm, Pillow, and safetensors: everything the starter program imports.
• Nothing about it is required or attested. Any ARM64 image from an allowed public registry may replace it, as long as it provides /bin/sh for the untimed build and GPU software compatible with the host driver.
• Builds reach the public internet only, ADD is rejected, and the finished image may be at most 16 GiB.
• You may keep 2 environments at a time; remove a dead experiment before starting another.
• Environment builds never cost an official attempt: if a download stalls or the build fails, fix it and queue it again. Up to 2 builds run concurrently, pausing only while a score holds the machine.
• Wait for the build status to become ready.

2. Download the source archive

Download eva02-python.zip

• The ZIP holds three root-level files: build.sh, main.py, and README.md.
• build.sh is the untimed build hook. Here it simply installs main.py as the executable /submission/run.
• main.py is one example predictor: a short, commented Python program that reads the manifest, labels every image with the official checkpoint in the exact reference settings, and writes one int32 answer per row. Its comments explain each step.
• Nothing about Python is required. build.sh may compile or install anything; the scorer only ever runs /submission/run.
• README.md restates the contract.

Verify your download’s SHA-256:

2dffc1dbd158cd2e523fb7c2e68dc28fccb70c733c237202ebf59451d75b9e20

3. Submit it

• Open Submit code, choose the ready environment, name the submission, and upload the ZIP unchanged.
• The platform builds it, still untimed, by running build.sh inside your environment, and fails the run if no executable /submission/run appears.
• Unlike environment builds, this step runs inside your exclusive scoring turn, one submission at a time, under a 30-minute cap. Keep build.sh minimal — slow work there risks the attempt on a timeout and holds up everyone behind you in the queue.
• Submit deliberately: the attempt is charged the moment the upload is accepted, and a build failure, crash, timeout, malformed output, or missed agreement gate all consume it.
• Only a platform-side infrastructure failure or an administrator cancellation refunds one.

4. Watch the clock

• The run-detail page follows your run live from queued through building and running to its verdict.
• When your turn comes, the host quiesces for you alone: one scoring container, no network, read-only inputs, and the same cohort JPEGs, checkpoint, and runtime files prewarmed into the page cache for every entrant.
• A trusted monotonic timer starts immediately before your process is forked and stops only after its last descendant exits. Startup, model loading, decoding, transfers, inference, and output writing are all on the clock; queue waiting, both untimed builds, cohort staging and prewarming, container creation, and post-run scoring are not.
• You get back the result, measured wall time, aggregate agreement, immutable digests, and the runner log. Per-image answers are never disclosed.
• The Runner log on the run page is your own code’s output: whatever build.sh and /submission/run write to stdout or stderr is captured there as a size-limited tail. A simple print() is all it takes; just remember that anything printed during the scored run spends wall time.
• The run must finish within 16 minutes — the starter itself fits with only a sliver to spare, so treat its pace as the minimum bar, not the target.
• At least 9,900 of 10,000 exact top-1 matches passes; among passing runs, only wall time ranks.

Rehearse before you spend an attempt

• The practice tab takes the same environment Dockerfile and the same archive and runs them on a second, identically configured DGX Spark against a public 1,000-image cohort with published per-image answers.
• A practice run costs no official attempt and never touches the leaderboard: the cheap way to learn whether your build works, and roughly how fast it is, before spending one of your 2 daily attempts.
• You can also download the cohort bundle there and score candidates on your own machine.
• Evaluation is its one sanctioned use: never train on, distill from, or embed practice data in a submission.

Open the practice tab

Now make it faster

• The baseline is honest about what it is: batch size eight, FP32 end to end, no compilation. Each of those is a lever.
• Larger batches amortize streaming the 1.2 GB of weights across more images.
• Lower precision shrinks the bytes themselves, as long as at least 9,900 of 10,000 answers still agree exactly; that slack is your accuracy budget.
• Compilation fuses kernels so activations stay on chip, and nineteen CPU cores are available to decode JPEGs while the GPU works.
• The machine explains why a naive FP32 loop on this host is bandwidth-bound long before it is compute-bound; the model details the 24 transformer blocks those levers apply to. None of it is required reading, but it is where the leaderboard will be decided.

Or ignore all of it

• The starter is a floor, not a template. Keep the environment and rewrite the program; keep the program and swap the model; distill the reference into something smaller that answers like it; or bring a different stack in a different language entirely.
• The scorer only ever sees /submission/run. Any approach consistent with the contest rules and their validation-data boundary is fair game.