22AI Research

Optimizer Design

#ModelScoreStepsIn tokOut tokAvg costAvg time
1GPT-5.6
0.2914
±0.047
488100.6M149k$84.0913.1h
2GLM-5.3
0.1715
±0.068
21735.5M208k$16.8618.8h
3Grok 4.6
0.1658
±0.064
32269.4M443k$69.5019.4h
4Claude Fable 5.1
0.1410
±0.075
16021.6M167k$14.8613.3h
5Kimi K3
0.1378
±0.110
26453.2M302k$22.8518.3h
6Qwen3.8-Max
0.0473
±0.038
24420.7M493k$8.3819.8h
7DeepSeek V4 Flash Exp
0.0448
±0.049
33467.4M251k$1.3219.2h
8Gemini 3.7 Flash
0.0427
±0.049
646170.1M153k$19.8313.4h
9Inkling
0.0000
±0.000
852.1M22k$2.122.3h
10Muse Spark 1.2
0.0000
±0.000
33286.7M398k$36.9613.9h

Background

Most published optimizers win on a narrow slice of architectures and lose elsewhere; a per-workload-tuned baseline is easy to beat on one model and very hard to beat on ten at once. This task asks for genuine optimization research: one optimizer class and one hyperparameter configuration that converge quickly across transformers, convolutional networks, plain MLPs, embedding-heavy recommenders, and contrastive encoders, and that generalize to architecture families it was never tuned on.

The bar is not vanilla AdamW. The frozen per-workload reference step counts were calibrated offline from a portfolio of strong controls (Nesterov SGD, normalized and shape-routed Muon hybrids, adaptive schedules, table-aware Muon/Adam variants, bounded SOAP and Shampoo, and Schedule-Free AdamW), with each denominator accepted only from repeated confirmation runs on the exact task hardware.

Task

The agent must create /app/custom_optimizer.py defining CustomOptimizer(torch.optim.Optimizer) and /app/optimizer_config.json, whose object is passed to the constructor as **kwargs. The frozen training loop drives it through the ordinary construct / zero_grad / step contract.

  • Seven visible workloads for development: nano-GPT on WikiText-103, ResNet-18 on CIFAR-100, a masked atom-set transformer for QM9 dipole-moment regression, next-item prediction on MovieLens-1M, a ViT and a 12-layer plain MLP on CIFAR-10, and a SimCSE contrastive encoder on AG News. Three held-out workloads from different architecture families are scored at verification.
  • One class and one config for all ten workloads. Branching on workload or model class names is forbidden; adapting behavior based on parameter shape is explicitly allowed; that is legitimate optimizer design.
  • The optimizer must be self-contained: imports limited to torch, numpy, scipy, and a fixed set of standard-library modules that deliberately excludes filesystem, network, and OS access.
  • The training infrastructure (train_workload.py, run_visible.py, workloads/) is read-only; runs against modified copies are rejected.

What The Agent Gets

A complete experiment loop on an H100: the seven visible workload definitions in /app/workloads/ (exact architectures, datasets, loss functions, and per-workload target losses), the frozen training loop, and python3 /app/run_visible.py to run one workload or all seven, saving per-step loss curves, speedups, and timing to /app/runs/ for comparison across experiments.

The starter custom_optimizer.py is a simple AdamW implementation provided only to demonstrate the interface; it is not the reference portfolio and has no promised speedup. Datasets are baked into the image from hash-pinned sources; the machine is offline for task purposes, and a sandbox-timer CLI reports the remaining budget.

Verification

A clean-room verifier runs in a fresh container on the captured /app, first checking every frozen training file against a SHA-256 manifest, then training all ten workloads (seven visible plus three held-out) with the submitted optimizer. The scorer never imports candidate code: submitted optimizer code runs alone in a chrooted, privilege-dropped, seccomp-confined process that sees only mirrored parameters and gradients, while trusted root-owned processes own the models, data, forward/backward passes, step counting, checkpoints, and all scored quantities.

  • Per workload, the verifier records the first validation checkpoint at which the EMA validation loss crosses the unchanged target: a crossing earns baseline_steps / candidate_steps against the frozen reference denominator; a miss earns capped loss-ratio partial credit (at most 1.0). Reference optimizers are not re-run; only the frozen scalars are read.
  • The ten speedups combine by geometric mean G, mapped asymptotically to reward: 0 at or below the 1.0x reference baseline, 1 − 1/G above it. G = 2 (half the aggregate optimizer updates) maps to 0.5, with no finite full-credit target.
  • A crashed or diverged workload is floored near zero before the geometric mean, dragging the aggregate down hard: uniform gains beat one dramatic outlier.
  • Disallowed imports, tampered frozen files, and branching on workload identity are rejected outright; candidate stdout is diagnostic only and cannot influence the score.

Environment

Base imagenvidia/cuda:12.4.1-devel-ubuntu22.04
Tools availableCUDA, PyTorch, C/C++ toolchain, Python 3
Compute8 CPUs · 128 GB RAM
GPU1× H100
Time limit20h

Changes From V1

This task is an improved revision of Optimizer Design from FrontierSWE V1.

  • The reward changed from the raw geometric-mean speedup G to an asymptotic map: 0 at or below the 1.0x reference baseline and 1 − 1/G above it, so matching the references earns nothing and there is no finite full-credit speedup.
  • The reference denominators were recalibrated from per-workload-tuned AdamW to a much stronger frozen control portfolio (Nesterov SGD, normalized and table-aware Muon hybrids, bounded SOAP and Shampoo, Schedule-Free AdamW), each accepted only from three-repeat confirmation on the exact task hardware; references are no longer re-run at verification; only frozen scalar step counts are read.
  • Candidate isolation was rebuilt: V1 imported custom_optimizer.pydirectly into the verifier's training process, while V2 runs it in a chrooted, privilege-dropped, seccomp-confined worker per workload that sees only mirrored parameters and gradients, with the import allowlist now enforced rather than stated.
  • Verification moved to a separate clean-room container on the captured /app, with frozen training files checked against a SHA-256 manifest and datasets pinned by digest in an OCI lock.
  • The first-EMA-crossing scoring rule is now applied identically to submissions and to the offline baseline calibration, and the /app/.timer daemon files were replaced by the sandbox-timer CLI under the new harbor schema.

References

  • WikiText-103 / WikiText-2 (CC BY-SA 3.0): Training data for the nano_gpt workload and a held-out character-level language model (Merity et al. 2016).
  • CIFAR-10 / CIFAR-100 (Research use): Image-classification data for the vit, deep_mlp, and resnet workloads, via torchvision (Krizhevsky 2009).
  • QM9 (CC0 / public domain): Dipole-moment regression data for the graph_transformer workload (Ramakrishnan et al. 2014, via PyTorch Geometric); atomic numbers only, unnormalized target index 0, source-order 80/20 split.
  • MovieLens 1M (GroupLens research-use terms): Next-item prediction data for the next_item workload; only a derived tensor of remapped integer IDs and next-item targets is stored in the private evaluation registry.
  • AG News (Academic / research use): Text data for the contrastive workload and a held-out classifier.
  • Multi30k (CC BY-NC-SA 4.0): Data for a held-out sequence-to-sequence workload.
  • PyTorch + torchvision (BSD-3-Clause): PyTorch 2.5.1 and torchvision 0.20.1, installed from pinned package locks together with NumPy and SciPy (BSD-3-Clause).
  • Muon (MIT): Primary source informing the offline calibration controls (not vendored; first-party ports and hybrids only).
  • SOAP (MIT): Primary source for the bounded SOAP calibration control (not vendored, and not a claim of full upstream equivalence).
  • Distributed Shampoo (BSD-3-Clause): Primary source for the bounded Shampoo calibration control (not vendored).
  • Schedule-Free AdamW (Apache-2.0): Primary source for the Schedule-Free AdamW calibration control (not vendored).