Skip to content

feat(airbender): draft from-scratch prover autoscaler - #4919

Draft
deniallugo-ml wants to merge 1 commit into
mainfrom
design-airbender-autoscaler
Draft

feat(airbender): draft from-scratch prover autoscaler#4919
deniallugo-ml wants to merge 1 commit into
mainfrom
design-airbender-autoscaler

Conversation

@deniallugo-ml

Copy link
Copy Markdown
Contributor

What ❔

A new standalone crate airbender_autoscaler/ — a from-scratch autoscaler for Airbender prover fleets. Own cargo workspace at the repo root (like airbender_prover_server), no zksync_* dependencies: it talks to chain proof data handlers over HTTP and to Kubernetes API servers directly via kube-rs. The legacy prover_autoscaler is untouched and keeps serving the old proof system.

Design

  • Single reconcile loop, no agents: observe (queue reports + deployments/pods per kubeconfig context) → plan → patch the Deployment scale subresource.
  • Pure planner (planner.rs): all policy is a side-effect-free function, unit-tested (10 tests); dry-run runs identical code and skips only the actuator. Drain-horizon control law:
    desired = clamp(ceil(work × duration_p95 / drain_window), min, max), then a hard per-group max_gpus budget (snark-only funded first, fri-only cut first).
  • Scarce machines, single GPU card class: spec.replicas counts as capacity already requested (Pending pods are never re-requested); a pod Pending beyond startup_p95 marks the cluster starved and the planner holds and says so — no pool racing, no aggressive mode. Scale-up needs consecutive confirmations (bypassed on latency-SLO breach); scale-down is one replica at a time after a stabilization window, only on a settled fleet.
  • Manual topology: the operator declares combined (fri-snark) or split (fri-only + snark-only) per compatibility group; multichain workers (feat(airbender): round-robin prover fetching across multiple chain job servers #4905) poll all the group's chains round-robin. Config validation rejects fri-only without SNARK-capable capacity. snark-only pre-warms from FRI jobs expected to finish within machine startup time.

Prerequisites tracked in the README (not in this PR)

  1. GET /airbender/queue_report on the proof data handler, with predicates mirroring the DAL locking queries (lock_batch_for_proving / lock_batch_for_snark).
  2. Prover server: SNARK lease on local wrap (submit_fri + will_wrap_locallypicked_for_snark, closing the duplicate-wrap race with snark-only claimers), idle SNARK fallback in fri-snark mode, SIGTERM drain that also submits the local SNARK follow-up.

Why ❔

The existing prover_autoscaler targets the previous proof system (agents, GPU-type ranking, aggressive pool racing, prover-job-monitor). The Airbender setup is different: few machines of a single GPU card class, FRI ~10–15 min + SNARK wrap, shared multi-chain fleets, and a hard cost objective. A small purpose-built controller is simpler than retrofitting the legacy one.

Checklist

  • PR title corresponds to the body of PR (we generate changelog entries from PRs).
  • Tests for the changes have been added / updated.
  • Documentation comments have been added / updated.
  • Code has been formatted via zk_supervisor fmt and zk_supervisor lint.

🤖 Generated with Claude Code

Standalone crate (own workspace, no zksync deps) that scales Airbender
prover deployments: polls per-chain /airbender/queue_report endpoints,
plans replica counts with a pure drain-horizon planner (confirmation
streaks, scale-down stabilization, pending-pods-as-requested-capacity,
starvation hold, snark-only pre-warm, group GPU budget), and patches
Deployment scale directly via kube-rs — no per-cluster agents, single
GPU card class, manual combined/split topology in config.

Ships with 10 planner unit tests, dry-run and --once modes, an example
config, and a README listing the external prerequisites (queue-report
endpoint, prover-server SNARK lease / idle fallback / SIGTERM drain).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@deniallugo-ml
deniallugo-ml marked this pull request as draft July 23, 2026 16:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant