Runner bietet Cloud-Macs zur projektbezogenen Miete. Jede Bestellung umfasst einen dedizierten physischen Apple-Silicon-Server statt einer virtuellen Maschine – ideal für feste Toolchains, eine vollständige macOS-Oberfläche oder dauerhaft laufende Aufgaben.
Filtern Sie zunächst nach Laufzeit, Speicherauslastung, Bedarf an einer grafischen Oberfläche und Parallelität – ohne vorher ein Modell erraten zu müssen.
Der Anwendungstyp allein bestimmt nicht die Konfiguration. Prüfen Sie zuerst Laufzeit, Speicherspitzen, Bedarf an einer grafischen Oberfläche und die Zahl gleichzeitig gestarteter Builds oder Experimente.
Einmalige Tests lassen sich tageweise planen, Versions-Sprints wochenweise. Für Continuous Integration und dauerhaft laufende Experimente sind Monats- oder Quartalszeiträume sinnvoll, da Umgebungen seltener neu eingerichtet werden müssen.
Normale Xcode-Projekte und leichte Automatisierung können mit 16 GB beginnen. Bei gleichzeitig laufenden Simulatoren, mehreren Builds oder größeren Modellen sollten Sie 24 GB bevorzugen.
Für Skripte und Build-Befehle reicht meist SSH. Wenn Sie Xcode, Zeitleisten, Vorschaufenster oder Systemeinstellungen bedienen müssen, planen Sie zusätzlich eine Remote-GUI ein.
Halten Sie fest, ob Tests, Paketierung, Modellinferenz und Exporte gleichzeitig laufen. Parallele Aufgaben teilen sich Speicher, Festplatten-Cache und Bandbreite – wählen Sie daher nach dem Spitzenwert, nicht nach dem Durchschnitt.
Diese Szenarien schließen sich nicht gegenseitig aus. Ein Knoten kann zunächst zur Entwicklung und später in einer automatisierten Pipeline verwendet werden. Entscheidend sind klare Grenzen für Umgebung, Cache und Übergabe je Phase.
Öffnen Sie Xcode über die grafische Oberfläche, holen Sie den Code ab und wählen Sie die benötigte Toolchain. Führen Sie Tests aus, erstellen Sie einen signierten Build und übertragen Sie Archiv und Logs anschließend in Ihren eigenen Speicher.
Registrieren Sie den physischen Knoten für ein bestimmtes Projekt oder eine Organisation, begrenzen Sie den Auslöserbereich, pflegen Sie den Abhängigkeits-Cache und übertragen Sie Testberichte, Archive und Symboldateien in den Artefaktspeicher der Pipeline.
Prüfen Sie in der Apple-Silicon-Umgebung die Kompatibilität von Modellen, Frameworks und Abhängigkeiten. Schätzen Sie den Speicherbedarf anhand von Modellgewichten, Kontextlänge und parallelen Anfragen und verwalten Sie Daten und Ergebnisse getrennt.
Übertragen Sie zunächst Proxy-Dateien oder benötigte Assets und prüfen Sie Zeitleiste und Vorschau über die Remote-GUI. Planen Sie Cache, Quelldateien und Exportverzeichnisse getrennt und sichern Sie fertige Medien und Projektdateien zeitnah.
Entwicklungsaufgaben geraten besonders leicht ins Stocken, wenn etwas lokal läuft, aber remote nicht reproduzierbar ist. Dokumentieren Sie Versionen, Abhängigkeiten, Signaturmaterial und Artefaktpfade – so lässt sich der Knoten stabil zwischen Debugging und Build einsetzen.
ein einzelnes Projekt entwickelt wird, normale Unit-Tests und jeweils ein wesentlicher Build laufen und 16 GB RAM sowie 256 GB SSD für Code, Abhängigkeiten und notwendige Caches ausreichen.
Branches, Submodule, Abhängigkeitsquellen und Repository-Zugriff prüfen; langfristige Zugangsdaten nicht im Projektverzeichnis speichern.
Xcode und Kommandozeilen-Tools gemäß Projektanforderung festlegen, vor der Installation der Abhängigkeiten einmal die Umgebung prüfen.
Zunächst einen kleinen Testsatz ausführen, um Simulator, Zielplattform und Berechtigungen zu prüfen, dann auf die vollständige Testsuite erweitern.
Zertifikate und Signaturdateien aus einem kontrollierten Speicher einbinden und Archiv, Testbericht sowie notwendige Diagnose-Logs ausgeben.
Archiv und Logs in den Teamspeicher übertragen, die Vollständigkeit prüfen und erst danach temporäre Verzeichnisse und sensible Daten löschen.
Ein dedizierter physischer Server schafft klare Ressourcengrenzen. Dennoch müssen Auslöser, Projektumfang und Berechtigungen für Zugangsdaten begrenzt werden. Durch getrennte Verwaltung von Runner-Registrierung, Cache-Strategie, Aufgabenbereinigung und Artefaktübergabe sinkt das Risiko gegenseitiger Beeinflussung.
Wenn Kompilierung, Tests, Archivierung oder mehrere Projekte gleichzeitig laufen, dokumentieren Sie Spitzen-RAM und Cachegröße. Bei höherem Speicherbedarf und größerer lokaler SSD sollten Sie den Runner M4 Plus bevorzugen.
Binden Sie den Knoten an ein bestimmtes Projekt oder eine Organisation und legen Sie fest, welche Workflows ihn aufrufen dürfen.
Token, Zertifikate und Umgebungsvariablen werden über den Secret-Prozess Ihres Teams eingebunden; temporäre Berechtigungen werden nach Abschluss widerrufen.
Abhängigkeits-Cache, Build-Zwischendateien und fertige Artefakte in getrennten Verzeichnissen speichern und überprüfbare Bereinigungsregeln festlegen.
Testberichte, Archive, Symboldateien und Prüfinformationen in den Pipeline-Speicher übertragen; den Knoten nicht als einzige Kopie verwenden.
Beginnen Sie bei Experimenten auf Apple Silicon mit Framework-Version, Modellformat und Operatorunterstützung, statt Parameter aus anderer Hardware zu übernehmen. MLX und lokale Modelle teilen sich den Unified Memory – Modellgewichte, Kontext, parallele Anfragen und weitere Prozesse gehören daher gemeinsam ins Budget.
Wenn Modellgewichte, langer Kontext, Datenvorverarbeitung und mehrere Experimente gleichzeitig im Speicher bleiben müssen oder 16 GB häufig an ihre Grenzen kommen, bietet der Runner M4 Plus mehr Arbeitsraum.
Bei Remote-Audio-/Video-Aufgaben entsteht die Wartezeit nicht nur beim Export. Asset-Upload, Proxy-Erstellung, Qualität der Remote-Anzeige und Ergebnisdownload beeinflussen das Gesamterlebnis. Eine feste Renderdauer sollte daher nicht zugesagt werden. Verlässlicher ist die schrittweise Prüfung von Netzwerk, Speicher und Aufgabenstatus.
Planen Sie neben den Quelldateien Platz für Proxys, Render-Cache, automatische Projektsicherungen und den finalen Export ein. Reichen 256 GB dafür nicht aus, wählen Sie die Konfiguration m4-24-512 oder prüfen Sie auf der Tarifseite ein SSD-Upgrade.
Laden Sie bevorzugt die benötigten Assets oder Proxy-Dateien hoch, behalten Sie lokale Originale und prüfen Sie die Übertragung auf Vollständigkeit.
Passen Sie die Auflösung der grafischen Sitzung an die Netzwerkbedingungen an; eine flüssige Vorschau entspricht nicht der finalen Exportqualität.
Speichern Sie Cache und Quelldateien in getrennten Verzeichnissen und prüfen Sie den freien Speicher vor wichtigen Exporten.
Prüfen Sie nach dem Export Dateigröße und Abspielbarkeit, übertragen Sie die Datei in den Teamspeicher und entfernen Sie temporäre Kopien.
Beide Tarife bieten einen dedizierten physischen Server, SSH und eine grafische macOS-Oberfläche. Sie unterscheiden sich bei RAM, SSD-Kapazität und Preis – nicht durch unklare Multiplikatoren für gemeinsam genutzte Ressourcen.
Geeignet für Xcode-Entwicklung an einem Projekt, jeweils einen wesentlichen Build, einen leichten selbst gehosteten Runner, kurzfristige Kompatibilitätstests und Workflows ohne umfangreiche lokale Medien.
Geeignet für parallele Simulatoren und Builds, mehrere Automatisierungsaufgaben, größere MLX-Experimente, mehr Abhängigkeits-Cache sowie Workflows mit Proxy-Assets und Exportdateien auf dem Knoten.
Stellen Sie Projektgröße, Xcode-Version, Zahl paralleler Aufgaben, Cachegröße und geplante Mietdauer zusammen und senden Sie diese über die Kontaktseite an unser Team. Übermitteln Sie keine Passwörter, privaten Schlüssel oder vollständigen Zahlungsdaten.
Runner kann tage-, wochen-, monats- oder quartalsweise gemietet werden. Alle Beträge werden in US-Dollar abgerechnet; akzeptiert werden nur USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe). Welche Gateways tatsächlich verfügbar sind, zeigt die Konsole.