Erst Aufgaben, dann Ressourcen zuweisen
Vier Workloads auf der Build-Spur
Legen Sie zuerst die Hauptaufgabe des Rechners fest und wählen Sie danach Arbeitsspeicher und Speicherplatz. Entwicklerarbeit, Release-Archivierung und Modellversuche können auf vergleichbaren Rechnern laufen, sollten aber nicht unbeschränkt um dieselbe Maschine konkurrieren.
Szenario 1 · PR-Checks
Build und Unit-Tests bei jedem Commit
Geeignet für CI einzelner Projekte, kleine SwiftUI-Apps und Teams, die ihren Build-Rechner aus dem Büro verlagern möchten. Bei jedem PR werden Code ausgecheckt, Abhängigkeiten wiederhergestellt und Unit-Tests ausgeführt; die Ergebnisse gehen zurück an Ihre bestehende CI-Plattform.
Starten Sie mit Merge M4 S: Apple Silicon M4, 16 GB RAM / 256 GB SSD. Der gesamte Rechner steht einem Kunden zur Verfügung; Build-Aufgaben teilen sich keine Kerne mit anderen Mietern. Begrenzen Sie dennoch die Parallelität Ihrer Teamaufgaben, damit gleichzeitige Builds den Arbeitsspeicher nicht überlasten.
Die erste Pipeline erledigt drei Aufgaben
- Repository-Commit, Lockdatei der Abhängigkeiten und Xcode-Version festlegen.
- Zunächst Build und Unit-Tests für ein Scheme ausführen.
- Warte-, Build- und Testphase getrennt erfassen, um Engpässe zu finden.
Grenzen abwägen: Wenn mehrere Targets oder parallele Simulator-Tests den Arbeitsspeicher deutlich stärker beanspruchen, prüfen Sie die 24-GB-Konfiguration. Leiten Sie die benötigte Rechnerzahl nicht direkt aus der Teamgröße ab.
Merge M4 S mieten
Szenario 2 · Tägliche Releases
Nightly-Archive dem Release-Runner überlassen
Geeignet für Teams, die täglich Test-Builds erstellen, Archive nach Zeitplan erzeugen und Builds mit Fastlane automatisieren. Nutzen Sie Ihre bestehenden Lanes weiter und verbinden Sie Archivierung, Export und Upload zu TestFlight zu einem Release-Workflow.
Empfehlung: Merge M4 L mit Apple Silicon M4, 24 GB RAM / 512 GB SSD. Gegenüber der Einstiegskonfiguration bietet sie mehr Arbeitsspeicher und lokalen Speicherplatz, um Abhängigkeiten mehrerer Projekte und benötigte Simulator-Runtimes vorzuhalten. Der tatsächliche Build-Gewinn hängt vom Projekt und vom Cache-Status ab.
Release-Aufgaben separat absichern
- Verwenden Sie ein eigenes Runner-Tag, damit normale PRs keine Archivierungszeit belegen.
- Zertifikate, Provisioning-Profile und benötigte Zugangsdaten über CI-Secrets bereitstellen.
- Nach erfolgreicher Archivierung Logs und Build-Artefakte speichern und lokale Dateien anschließend nach Ihren Regeln bereinigen.
Zu beachten: Der Knoten läuft 365 Tage im Jahr. Ob zeitgesteuerte Aufgaben starten und Uploads erfolgreich sind, muss weiterhin mit Fehlerbenachrichtigungen und Wiederholungen in der CI-Plattform abgesichert werden.
Merge M4 L mieten
Szenario 3 · Remoteentwicklung
Xcode auch ohne eigenen Mac nutzen
Nutzen Sie die grafische macOS-Oberfläche per VNC, um Projekte in Xcode anzusehen, Build-Fehler zu untersuchen und Simulatoren auszuführen. Per SSH können Sie Builds über die Kommandozeile starten, Dateien synchronisieren und Runner verwalten.
Wenn Sie Xcode, Simulator und weitere Tools gleichzeitig öffnen müssen, empfiehlt sich zunächst Merge M4 L. GUI und CI-Aufgaben nutzen die Ressourcen desselben physischen Rechners. Planen Sie interaktives Debugging und automatische Archivierung daher zu unterschiedlichen Zeiten ein oder verteilen Sie sie auf getrennte Knoten.
Erst die Verbindung testen, dann das ganze Projekt übertragen
- Rufen Sie die Verbindungsdaten Ihrer Instanz im Control Panel ab und prüfen Sie zuerst SSH- und VNC-Zugriff.
- Verringern Sie die Auflösung der Remoteanzeige und prüfen Sie, ob Eingaben und Fensteraktionen reaktionsschnell sind.
- Testen Sie Xcode und Simulator zunächst mit einem kleinen Projekt und synchronisieren Sie danach das eigentliche Projekt.
Wichtig: Die Cloud eignet sich für Builds, Signierung und Simulator-Tests, bietet aber keinen direkten Zugriff auf das iPhone neben Ihnen. Schritte, die eine lokale Geräteverbindung erfordern, müssen separat ausgeführt werden.
SSH- und VNC-Verbindung einrichten
Szenario 4 · KI-Experimente
Ressourcenbudget für MLX-Experimente festlegen
Führen Sie lokale MLX-Inferenz auf Apple Silicon aus und testen Sie quantisierte Modelle sowie die Feinabstimmung kleiner Modelle. Erstellen Sie zunächst mit einem kleineren Modell eine funktionsfähige Basis und erhöhen Sie dann schrittweise Kontextlänge, Batchgröße und Umfang der Trainingsdaten.
Empfehlung: Merge M4 L mit zusätzlicher 2-TB-SSD. Nutzen Sie den erweiterten Speicherplatz für Modellgewichte, Datensätze und Checkpoints. 24 GB RAM sind das Budget für den Arbeitsspeicher; eine zusätzliche SSD erweitert den Dateispeicher – beides ist nicht austauschbar.
Spitzenwerte prüfen, nicht nur die Modellgröße
- Erfassen Sie die Arbeitsspeicher-Spitzenwerte beim Laden des Modells, bei der Inferenz und beim Fine-Tuning.
- Planen Sie zusätzlichen Speicherplatz für Downloads, entpackte Dateien und Checkpoints ein.
- Pausieren Sie parallele CI-Aufgaben auf derselben Maschine, damit Ressourcenengpässe die Experimente nicht verfälschen.
Zu beachten: Ob ein Modell in den Arbeitsspeicher passt, hängt auch von Quantisierung, Kontextlänge und Ausführungsart ab. Eine zusätzliche 2-TB-SSD erweitert nicht den Arbeitsspeicher und garantiert nicht, dass jedes Modell ausgeführt werden kann.
Merge M4 L mit zusätzlichem Speicher konfigurieren
Ein exklusiver Rechner bedeutet nicht unbegrenzt viele parallele Aufgaben.Begrenzen Sie zuerst die Parallelität auf dem einzelnen Rechner und beobachten Sie dann Arbeitsspeicher-Spitzen, freien Speicherplatz und Aufgaben-Wartezeiten. Wenn Release-Aufgaben ein stabiles Zeitfenster brauchen, teilen Sie die Runner-Aufgaben auf, statt alles in dieselbe Warteschlange zu legen.
