AutoDL Research Pilot

AutoDL Research Pilot gibt Codex eine praktische Möglichkeit, zwei Fragen zu beantworten: Soll dieses Experiment jetzt eine GPU mieten, und welche verfügbare GPU ist es wert, gemietet zu werden?

Der Enterprise-Elastic-Workflow beginnt mit der offiziellen AutoDL-API. Er liest den Kontostand und den nach Region, CUDA, CPU, RAM und Preis gefilterten GPU-Bestand; Deployments und private Images werden hinzugefügt, wenn das Token darauf zugreifen kann. Der Scheduler verbindet diesen Live-Zustand mit workload-spezifischen Durchsatzbelegen, vergleicht die Gesamtlaufzeit und die Gesamtkosten und erstellt eine präzise Container-Deployment-Anfrage. Die Anfrage bleibt lokal, bis ein Forscher sie genehmigt.

Ein hoher Stundensatz ist nicht automatisch teuer. Wenn eine schnellere GPU eine 30-stündige Ausführung auf acht Stunden reduziert, ist sie möglicherweise früher fertig und kostet insgesamt weniger. Umgekehrt kann eine High-End-GPU die meiste Zeit auf einen DataLoader warten. Research Pilot modelliert die Ausführung, anstatt Produktnamen zu bewerten.

Was es tut

• Nutzt die offizielle API als Steuerungsebene. Enterprise-Discovery, -Planung, -Deployment-Erstellung, -Auflistung, -Stopp und -Löschung sind erstklassige CLI- und MCP-Operationen.

• Macht Verfügbarkeit ausführbar. Der Bestand wird mit denselben Region-, CUDA-, CPU/RAM-, GPU-Modell- und price_to-Filtern abgefragt, die in das Deployment eingetragen werden.

• Optimiert die gesamte Ausführung. Laufzeit, Einrichtung, Übertragung, Warteschlange, Workload-Durchsatz, Unsicherheit und bekannte Fixkosten fließen in einen Kosten/Zeit-Pareto-Vergleich ein.

• Versteht Forschungsbeschränkungen. VRAM, Budget, Termin, Inventar und Startbereitschaft sind harte Filter. Modell, Daten, Präzision, Seeds, Batch-Semantik und Bewertung ändern sich nicht stillschweigend, um eine günstigere Karte zu passen.

• Bietet klare Präferenzen. economy minimiert die konservativen Gesamtkosten; time minimiert die Abschlusszeit innerhalb des Budgets; balanced wählt einen Mittelpunkt; custom akzeptiert Ihre eigenen Gewichte.

• Hält kostenpflichtige Aktionen überprüfbar. Mutationen sind standardmäßig Anfragevorschauen. Ein bestätigtes Elastic-Create prüft unmittelbar vor dem API-Aufruf erneut die Wallet-Kapazität, doppelte Run-Namen, Zugriff/Vorhandensein privater Images, den vollständigen Kandidatenbestand und den Termin.

• Wird als CLI, MCP-Server und Codex-Skill ausgeliefert. Der Skill deckt auch GPU-Diagnose, Speicher, Images, Vordergrundbefehle, Checkpointing und den Unterschied im Lebenszyklus von Pro/Elastic ab.

Related MCP server: Run:AI MCP Server

Schnellstart: Enterprise Elastic

Installation

git clone https://github.com/chengxi271-commits/autodl-research-pilot.git
cd autodl-research-pilot
python -m venv .venv

Windows PowerShell:

.\.venv\Scripts\Activate.ps1
python -m pip install -e ".[mcp]"
$env:AUTODL_TOKEN = "YOUR_TOKEN"

Linux / macOS:

source .venv/bin/activate
python -m pip install -e '.[mcp]'
export AUTODL_TOKEN='YOUR_TOKEN'

Bewahren Sie das Token in der Prozessumgebung auf. Das Projekt benötigt es niemals in TOML, JSON, als Befehlsargument oder in der Versionskontrolle.

Diesen Run beschreiben

Kopieren Sie die Enterprise-Beispiele und ersetzen Sie Image, Befehl, Regionen, Ressourcengrenzen, Workload-Leistungsfaktoren und Preisobergrenzen:

cp examples/elastic.project.toml my-run.project.toml
cp examples/elastic.catalog.toml my-run.catalog.toml

Der Katalog ist bewusst klein. Er listet die GPU-Profile auf, die Sie bereit sind zu verwenden, nicht jede GPU, die AutoDL je angeboten hat. Setzen Sie image_source auf private für ein Konto-Image oder auf public für eine UUID aus dem API-Anhang von AutoDL. Wenn dc_list mehrere Regionen umfasst, bereiten Sie den Eingabe- und Ausgabespeicher in jeder aufgeführten Region vor oder verengen Sie die Liste auf die vorbereitete Region. Jeder performance_factor sollte aus demselben Workload oder einer klar gekennzeichneten Schätzung stammen; jede price_ceiling_cny ist Ihr maximal akzeptabler Stundensatz, kein behauptetes Marktangebot.

Entdecken, planen, in der Vorschau anzeigen

autodl-pilot discover --catalog my-run.catalog.toml --output live-context.json

autodl-pilot live-plan --project my-run.project.toml --catalog my-run.catalog.toml --profile balanced --output run.plan.json

autodl-pilot apply-live-plan --plan run.plan.json

live-plan führt standardmäßig eine neue Discovery durch, daher ist der separate Befehl discover optional. Er ist nützlich, wenn Sie prüfen möchten, was die API zurückgegeben hat, oder eine schreibgeschützte Momentaufnahme für die Diskussion einfrieren möchten.

Die Vorschau enthält den eindeutigen Run-Namen, die exakte GPU, verfügbare Regionen, Image und Quelle, den Vordergrundbefehl, den CPU/RAM-Bereich und die Preisobergrenze. Sie führt keinen Mutationsaufruf aus. Prüfen Sie selected.execution_ready; wenn es false ist, benennt selected.needs_input den fehlenden Kontozugriff, das fehlende Image oder das fehlende Research-Gate. Nach der Prüfung einer ausführungsbereiten Anfrage:

autodl-pilot apply-live-plan --plan run.plan.json --confirm

Die Bestätigung liest erneut Wallet, aktive Deployments mit demselben Run-Namen, das ausgewählte private Image und jeden Katalog-Bestandsfilter. Sie prüft, ob die konservative Laufzeit weiterhin in den eingefrorenen Termin passt, und ruft dann POST /api/v1/dev/deployment auf. Wenn das ausgewählte Profil verschwindet oder ein zuvor nicht verfügbarer Kandidat auftaucht, kehrt sie zur Planung zurück, anstatt aus einem veralteten Ranking zu erstellen oder eine nicht genehmigte GPU einzusetzen.

Wie die Entscheidung funktioniert

Für das GPU-Profil g geht der Scheduler von einer Referenzlaufzeit aus und schätzt:

compute time = reference runtime / workload performance factor
total time   = queue + setup + transfer + compute time
total cost   = fixed cost + billed time × hourly price ceiling × GPU count

Leistungsbelege mit geringerer Konfidenz vergrößern die konservative Zeit und die Kosten. Kandidaten, die eine harte Beschränkung verfehlen, erreichen nie die Profilbewertung. Die Überlebenden bilden eine Pareto-Front: Kein Kandidat an der Front ist zugleich langsamer und teurer als ein anderer.

Die API-Bestandsantwort meldet die Anzahl freier Karten, nicht genaue Preise oder Benchmark-Geschwindigkeit. Research Pilot hält diese Fakten daher getrennt:

1. Der AutoDL-Bestand belegt die aktuelle Verfügbarkeit innerhalb einer Preisklasse.

2. Der Katalog erfasst VRAM- und Workload-Leistungsbelege.

3. Elastic price_to begrenzt, was das Deployment akzeptieren darf; der Planer verwendet diese Grenze für eine konservative Rechnung.

Der aktuelle Live-Planer erstellt absichtlich Ein-GPU-Container-Deployments. AutoDL dokumentiert den Bestand als Ein-Karten-Abfrage und warnt davor, dass zwei freie Karten auf verschiedenen Hosts liegen können. Multi-GPU-Scheduling sollte einem Skalierungstest mit identischem Workload und expliziten Same-Host-Belegen folgen, nicht einer optimistischen Inventarsumme.

Die GPU-Wahl intelligenter treffen

Die offizielle Leistungstabelle von AutoDL ist eine nützliche A-priori-Information, aber ihre Läufe sind Ein-Karten-Läufe, verwenden synthetische In-Memory-Eingaben und lassen CPU-Vorverarbeitung und zusätzliche E/A außen vor. Bevorzugen Sie einen kurzen Ausschnitt des echten Modells, der Präzision, der Batch-Semantik und der Daten-Pipeline.

Der gebündelte Skill folgt einer einfachen Engpassregel:

• GPU bei 0 %: Gerätenutzung und Framework-/CUDA-Kompatibilität prüfen.

• GPU konstant über etwa 90 %: Eine schnellere GPU oder ein gemessener Ein-Host-Multi-GPU-Lauf kann helfen.

• GPU niedrig oder oszillierend: Zuerst CPU, DataLoader-Worker, Speicher und Synchronisierung untersuchen.

• CUDA OOM: Prüfen Sie alte Prozesse und Batch-Größe 1, bevor Sie sich für größeren VRAM entscheiden.

• Prozess nahe dem RAM-Limit beendet: Mehr Container-Speicher anfordern, nicht mehr VRAM.

Nach einem vergleichbaren erfolgreichen Lauf führen Sie dessen Rechenzeit, Einrichtungs-/Übertragungsaufwand, tatsächliche Container-Rate und gemessenen Engpass zurück in das passende Katalogprofil. Diese Workload-Historie – statt einer generischen Benchmark-Tabelle – verbessert spätere Entscheidungen.

Es behandelt Speicher auch als Teil des Schedulings. Heiße Daten gehören nach /root/autodl-tmp; dauerhafte Checkpoints und Ergebnisse gehören auf persistenten Speicher wie /root/autodl-fs, bevor ein Elastic-Befehl beendet wird. Weitere quellenverknüpfte Betriebsregeln finden Sie im AutoDL-Feldhandbuch.

Persönliche Pro-Konten

Die offizielle Pro-API kann Wallet, Instanzen, Status, Snapshots und private Images lesen sowie Instanzen erstellen, ein-/ausschalten und freigeben. Sie veröffentlicht keinen Vorab-Marktkatalog oder Bestands-Endpunkt. Verwenden Sie für eine neue Pro-Miete ein frisches Konsolenangebot mit dem Offline-Planer:

autodl-pilot api wallet
autodl-pilot api instances
autodl-pilot api images
autodl-pilot plan --project project.toml --offers current-offers.toml --output pro.plan.json
autodl-pilot apply-plan --plan pro.plan.json

Die aktuelle Pro-Snapshot-Dokumentation legt rohe payg_price-Felder offen, ohne deren Einheit anzugeben, daher bewahrt der Client sie roh auf. Verifizieren Sie den zugewiesenen Preis in der Konsole, bevor Sie einen langen Lauf starten. Die Pro-API-Erstellung ist Pay-as-you-go, akzeptiert ein bis vier GPUs und bietet eine Systemfestplatten-Erweiterung; API-Einschalten unterstützt den GPU-Modus, nicht den Kartenlos-Modus der Konsole.

Das ursprüngliche Offline-Beispiel bleibt nützlich, um den Scheduler ohne Token zu testen:

autodl-pilot plan --project examples/project.toml --offers examples/offers.toml --profile balanced

Seine Preise sind Fixtures und können das Ausführungs-Gate für aktuelle Angebote nicht passieren.

Betrieb eines Deployments

autodl-pilot api deployments
autodl-pilot api containers --payload '{"deployment_uuid":"DEPLOYMENT_UUID","page_index":1,"page_size":10}'
autodl-pilot api events --payload '{"deployment_uuid":"DEPLOYMENT_UUID","page_index":1,"page_size":10,"offset":0}'

autodl-pilot deployment-stop DEPLOYMENT_UUID
autodl-pilot deployment-stop DEPLOYMENT_UUID --confirm

autodl-pilot deployment-delete DEPLOYMENT_UUID
autodl-pilot deployment-delete DEPLOYMENT_UUID --confirm

Elastic-Training sollte im Vordergrund laufen: Wenn cmd beendet wird, stoppt der Container. Ein Hintergrund-python train.py & kann das Abrechnungs- und Lebenszyklusverhalten vom Forschungsjob entkoppeln. Lokale Daten sind nach dem Stopp nicht persistent: Ohne Wiederverwendung werden sie sofort freigegeben; ein Wiederverwendungs-Cache kann Reste behalten, ist aber weder garantierter Speicher noch ein neu startbarer Container. cmd_before_shutdown hat nur ein Fünf-Sekunden-Fenster, daher gehört die Checkpoint-Persistenz in den Trainingsbefehl selbst.

Für lange Pro-Läufe, die über SSH gestartet werden, verwenden Sie screen, tmux oder ein Jupyter-Terminal und schreiben Sie Logs in eine benannte Datei. Rufen Sie Ergebnisse ab und verifizieren Sie sie vor release; das Stoppen der Rechenleistung und das Löschen des wiederherstellbaren Zustands sind getrennte Entscheidungen.

CLI-Referenz

Alle normalen Ergebnisse und kontrollierten Fehler sind JSON. Führen Sie autodl-pilot --help für Argumente aus.

Codex und MCP

Installieren Sie das mcp-Extra und laden Sie dieses Repository als lokales Codex-Plugin. .mcp.json zielt auf Windows; docs/mcp.unix.json ist das Unix-Manifest. MCP stellt dieselben Discovery-, Live-Planungs-, Vorschau-, Bestätigungs-, Lese- und Lebenszyklusoperationen bereit wie die CLI.

Der Codex-Skill liegt unter skills/autodl-research-pilot/SKILL.md. Ein nützlicher erster Prompt ist:

Verwenden Sie die AutoDL-API, um den Live-Elastic-Bestand zu prüfen, meine unterstützten GPU-Profile im balanced-Modus zu vergleichen und die genaue Deployment-Vorschau anzuzeigen. Warten Sie auf meine Genehmigung, bevor Sie es erstellen.

Umfang

Version 0.2.0 implementiert den API-first-Enterprise-Pfad für Einzel-GPU-Container und behält die Pro-/Offline-Planung bei. Der API-Client ist die Kontrollebene; SSH-Übertragung, Workload-Ausführung, Metriksammlung und Checkpoint-Abruf bleiben Arbeiten auf der Datenebene, die vom Skill koordiniert werden. Katalog-Feedback ist Skill-gesteuert und keine automatische Telemetrie. Die Laufzeitkosten enthalten Speicher nur, wenn er als fixed_cost angegeben wird. Gekaufte Guthaben für Elastic-Dauerpakete sind noch nicht modelliert, daher kann die Schätzung die marginalen Barkosten überschätzen, wenn ein solches angewendet wird.

Endpunkt- und Einheitengrenzen sind in AutoDL API Boundaries dokumentiert. Dies ist ein Community-Projekt und steht in keiner Verbindung zu AutoDL.

Entwicklung

python -m unittest discover -s tests -v

CI führt die Test-Suite auf Python 3.11, 3.12 und 3.13 aus. Siehe CONTRIBUTING.md, SECURITY.md und den Issue-Tracker.

Lizenz

Apache-2.0