M4 Cloud-Mac: ein ganzer Mac für SieAb einem Tag mieten, Xcode sofort nutzen

Jede Bestellung umfasst einen dedizierten Apple-Silicon-Server, keine VM. CPU, GPU und Unified Memory stehen ausschließlich Ihnen zur Verfügung. macOS läuft nativ; Xcode und Simulatoren sind direkt startklar.

Für iOS- und macOS-Entwicklung, dauerhaft laufende CI und Apple-Silicon-Experimente. Abrechnung in US-Dollar, ohne Jahresbindung.

sg-01 · M4 zsh — xn@sg-01
~ % xn lease --plan core --node sg
✓ gemietet: sg-01 · Node Core M4 · 1d · $21.3 USD · dediziert
~ % sysctl -n machdep.cpu.brand_string
Apple M4
~ % xcodebuild -version
Xcode 16.4
Build version 16F6
~ % uptime
10:42 up 3 mins, 1 user, load averages: 0.21 0.34 0.18
~ %
Serverplakette · Node Core M4 Dediziert · physischer Server
ChipApple M4
Arbeitsspeicher16 GB Unified Memory
SSD256 GB
Standortsg-01 · Singapur
Laufzeit1 Tag · $21.3

Beispiel zur Prüfung nach der Bereitstellung. Standortkennung, Befehlsausgabe und Xcode-Version richten sich nach der tatsächlichen Bereitstellung. Zugangsdaten finden Sie in den Bestelldetails der Konsole.

Dedizierte MaschinePhysischer ServerMac mini M4Abrechnung in US-Dollar
Dedizierter physischer Server

Warum eine ganze Maschine?

Weniger Ressourcenkonflikte, mehr Reproduzierbarkeit. Während Ihrer Mietzeit gehört Ihnen die Maschine; Sie bestimmen, welche Workloads darauf laufen.

Dedizierte physische Maschine

Ein M4 wird jeweils nur einem Mieter zugewiesen. CPU, GPU und Unified Memory werden nicht mit anderen Mietern geteilt; auch der Host ist exklusiv. Fixieren Sie Build-Parameter, Cache und Parallelisierung und vergleichen Sie die Ergebnisse desselben Projekts.

Dedizierung garantiert nicht bei jedem Lauf exakt dieselbe Dauer. Inkrementeller Cache, Festplattenzugriffe, Downloads von Abhängigkeiten und eigene parallele Aufgaben beeinflussen die Ergebnisse weiterhin. Vergleichen Sie bei der Leistungsanalyse zunächst Clean Builds mit Builds, die den Cache nutzen.

macOS nativ

macOS mit vollständiger grafischer Oberfläche und Kommandozeile. Xcode, iOS-Simulatoren, Metal und Instruments laufen direkt auf echter Apple-Silicon-Hardware – die GPU liegt nicht hinter einer Virtualisierungsschicht.

Prüfen Sie nach der Übernahme zuerst die Xcode- und SDK-Versionen und installieren Sie dann die Projektabhängigkeiten. Halten Sie die Versionen Ihrer Toolchain im Repository fest, um Abweichungen zwischen lokalem und remote Build zu vermeiden.

Tage-, wochen-, monats- oder quartalsweise

Mindestlaufzeit: ein Tag. Für kurze Tests tageweise mieten, für eine konzentrierte Release-Phase wochenweise und für dauerhaft laufende CI monats- oder quartalsweise. Nach Projektende einfach nicht verlängern – ganz ohne Hardwarekauf oder Jahresbindung.

Die Laufzeit wird im Voraus bezahlt und nicht sekundengenau abgerechnet. Das Beenden von Aufgaben erstattet keinen bereits begonnenen Zeitraum. Exportieren Sie vor dem Ende Ihrer Nutzung Build-Artefakte, Projekte und wichtige Konfigurationen und prüfen Sie das Ablaufdatum Ihrer Bestellung.

Zwei Modelle

Node Core M4 und Node Pro M4

Preise in US-Dollar, an allen vier Standorten gleich. Orientieren Sie sich zuerst an Arbeitsspeicher und Projektumfang, dann an der benötigten Laufzeit.

Node Pro M4

M4 Pro · 64 GB / 2 TB SSD

Mehr Arbeitsspeicher für parallele Aufgaben
$59.1/ Tag
Tag$59.1
Woche$159.6
Monat$295.6
Quartal$804
  • Parallele Simulator-Tests und große Swift-Projekte
  • Standort wählbar: Singapur / Tokio / Seoul / Hongkong
  • MLX-Inferenz, Modellexperimente und umfangreiche Arbeitsverzeichnisse

64 GB Unified Memory und 2 TB SSD bieten mehr Spielraum für parallele Aufgaben. Modellgewichte, KV-Cache, Eingabedaten und das System belegen gemeinsam den Arbeitsspeicher. Richten Sie sich bei der Auswahl also nicht nur nach der Dateigröße des Modells.

Node Pro M4 mieten Zugangsdaten in den Bestelldetails der Konsole

Beide Modelle sind mit einer zusätzlichen 1-TB-SSD, einer zusätzlichen 2-TB-SSD oder einer parallelen Thunderbolt-5-Erweiterung verfügbar. Preise und Kombinationsoptionen finden Sie im vollständigen Mietangebot. Die aktuelle Verfügbarkeit sehen Sie direkt in der Konsole.

Standorte in Asien-Pazifik

Vier Standorte, beide Modelle verfügbar

Singapur, Tokio, Seoul und Hongkong. Grenzen Sie die Auswahl zunächst anhand der Zeitzone Ihres Teams ein und testen Sie anschließend die Verbindung mit Ihrem eigenen Netzwerk.

SG

Singapur

Teams in Südostasien

Teamzeitzone
UTC+7 bis UTC+8
Richtwert für die Latenz
20–50 ms

Gut geeignet für Teams in Südostasien: tagsüber interaktiv entwickeln und debuggen, nachts Builds im Stapel ausführen. Halten Sie den Dependency-Cache auf dem Server, um wiederholte Übertragungen über das Netzwerk zu vermeiden.

Beide Modelle verfügbarStandort auswählen →
JP

Tokio, Japan

Teams in Ostasien

Teamzeitzone
UTC+9
Richtwert für die Latenz
30–60 ms

Gut geeignet für Teams mit einem Arbeitsrhythmus nach UTC+9. Wenn Sie längere Zeit mit der grafischen Oberfläche arbeiten, vergleichen Sie vor allem die Round-Trip-Latenz und Netzwerkschwankungen.

Beide Modelle verfügbarStandort auswählen →
KR

Seoul, Südkorea

Teams in Nordostasien

Teamzeitzone
UTC+9
Richtwert für die Latenz
30–50 ms

Gut geeignet für Teams in Nordostasien mit dauerhaft laufenden Runnern. Lassen Sie Abruf, Build und Tests auf demselben Server laufen und übertragen Sie nur die fertigen Artefakte zurück auf Ihre Workstation.

Beide Modelle verfügbarStandort auswählen →
HK

Hongkong

Teams in Südchina und Südostasien

Teamzeitzone
UTC+7 bis UTC+8
Richtwert für die Latenz
20–40 ms

Gut geeignet für Entwicklung und Releases rund um UTC+8. Prüfen Sie bei der Synchronisierung großer Repositories zuerst die Bandbreite: Eine niedrige Latenz bedeutet nicht automatisch schnellere Übertragungen großer Dateien.

Beide Modelle verfügbarStandort auswählen →

Die Latenzbereiche dienen als Orientierung bei der Standortwahl und sind keine Messwerte Ihrer aktuellen Verbindung. Das tatsächliche Nutzungserlebnis hängt vom Netzwerkpfad, Client und den Qualitätseinstellungen ab. Die aktuelle Verfügbarkeit sehen Sie direkt in der Konsole. Alle Standorte sind 365 Tage im Jahr in Betrieb.

In drei Schritten umziehen

Vom lokalen Mac in die Cloud: drei Schritte

Daten, Toolchain und CI jeweils einmal prüfen. Bringen Sie zuerst einen vollständigen Build zum Laufen und migrieren Sie dann Ihre automatisierten Aufgaben.

01 · Daten

Projekt und Signaturmaterial

Synchronisieren Sie das Projekt inkrementell mit rsync und verwalten Sie große Dateien im Repository mit Git LFS. Migrieren Sie Signaturzertifikate und Provisioning-Profile separat und importieren Sie die Zertifikate in den Schlüsselbund des Servers. Private Schlüssel gehören nicht ins Repository.

Legen Sie in Ihrer SSH-Konfiguration zunächst den tatsächlichen Host als sg-01fest und führen Sie dann das Beispiel aus. Prüfen Sie nach der ersten Synchronisierung versteckte Konfigurationen, Dateiberechtigungen und Lockfiles, damit nicht nur der Quellcode kopiert wurde.

rsync -az --progress ./App xn@sg-01:~/work/
02 · Toolchain

Versionen dokumentieren

Notieren Sie die Versionen von Xcode, SDK, Homebrew und Fastlane. Prüfen Sie die Umgebung zuerst mit xcodebuild -version und installieren Sie die Abhängigkeiten anschließend anhand von Brewfile und Gemfile.

Für dieses Beispiel müssen Homebrew und Bundler auf dem Server installiert sein und die entsprechenden Manifestdateien im aktuellen Verzeichnis liegen. Wenn Sie mehrere Xcode-Versionen nutzen, wählen Sie den Developer-Ordner ausdrücklich aus, statt sich auf die Standardversion des Systems zu verlassen.

brew bundle --file=Brewfile && bundle install
03 · CI einbinden

Dauerhaften Runner registrieren

Binden Sie einen self-hosted Runner für GitHub Actions oder GitLab CI ein. Den Registrierungsbefehl und ein kurzlebiges Token erhalten Sie in der Projektverwaltung. Speichern Sie das Token weder in einem Image noch in einer dauerhaft verwendeten Konfiguration.

Sobald der GitHub-Actions-Runner eingerichtet ist, können Sie den Dienst mit den folgenden Befehlen installieren und starten. Führen Sie Builds und Tests zunächst nacheinander aus und passen Sie die Parallelität anschließend anhand des maximalen Speicherbedarfs an. Bei UI-Tests muss außerdem die Sitzungsumgebung stimmen.

./svc.sh install && ./svc.sh start
Lokaler Mac · Projekt und ManifesteCloud-Mac · Builds und Artefakte

Erstellen Sie vor dem Umzug ein lokales Backup. Stellen Sie zunächst ein Archiv fertig, führen Sie Tests aus und laden Sie die Artefakte herunter. Erst danach sollten Sie geplante Aufgaben auf den neuen Server umstellen. Eine vollständige Anleitung zu SSH, grafischem Desktop und Runner finden Sie in der Verbindungsanleitung.

Anwendungsfälle

Drei Workloads, eine dedizierte Maschine

Die folgenden UI-Ausschnitte veranschaulichen die Organisation von Aufgaben und stellen keine gemessenen Laufzeiten oder Leistungsversprechen dar.

01 · Build und Release

iOS- und macOS-Builds mit TestFlight-Upload

Archivierung, Export und Upload laufen nacheinander auf derselben Maschine. Konsistente Projektversionen, Signaturmaterialien und Toolchains sind wichtiger als die Dauer eines einzelnen Builds.

Führen Sie zunächst einen sauberen Build aus und testen Sie danach einen inkrementellen Build mit Cache-Treffern. Archivieren Sie Archive, Logs und Exportdateien mit der jeweiligen Build-Nummer, um Fehler einem Build-, Signatur- oder Upload-Schritt zuordnen zu können.

xcodebuildFastlaneTestFlight
sg-01 · release/2.8.0Ablaufbeispiel
xcodebuild archive -scheme AppArchivierung abgeschlossen
xcodebuild -exportArchiveExport abgeschlossen
bundle exec fastlane pilot uploadUpload läuft
Verarbeitung durch TestFlightWarten auf Rückmeldung

Bewahren Sie Exit-Codes und Logs für jeden Schritt auf. Ein erfolgreicher Upload bedeutet nicht, dass die Verarbeitung abgeschlossen ist.

02 · CI/CD

Dauerhafter Runner, Warteschlange nach Ihren Regeln

Mieten Sie eine Maschine für einen Monat oder ein Quartal und registrieren Sie sie als self-hosted Runner. Dependency-Cache und DerivedData bleiben lokal und reduzieren wiederholte Downloads. Der Cache-Schlüssel sollte trotzdem Toolchain- und Abhängigkeitsversionen enthalten.

Eine dedizierte Maschine verhindert nicht automatisch Konflikte zwischen Aufgaben. Sichern Sie den Release-Ablauf mit einer Sperre ab, damit nicht mehrere Aufgaben gleichzeitig Signaturkonfigurationen ändern. Planen Sie UI-Tests getrennt von Builds im Hintergrund und beobachten Sie Ihre Ressourcenspitzen.

GitHub ActionsGitLab CIlaunchd
runner · xn-sel-01Beispielwarteschlange
pr-1482 · unit-testsLäuft
pr-1479 · ui-testsWartet
nightly · archiveAbgeschlossen
main · lintAbgeschlossen

Warteschlange und Parallelität konfigurieren Sie selbst. Aufgaben anderer Mieter werden nicht mit Ihren vermischt.

03 · KI auf Apple Silicon

MLX-Experimente mit ausreichend Unified Memory

Node Pro M4 ist mit M4 Pro, 64 GB Unified Memory und einer 2-TB-SSD ausgestattet. CPU und GPU teilen sich den Unified Memory – ideal für MLX-Inferenz und Fine-Tuning-Experimente, ohne virtualisierte Aufteilung.

Um zu prüfen, ob ein Modell in den Speicher passt, berücksichtigen Sie neben den Gewichten auch den Kontext-Cache, den Trainingsstatus und den Speicherbedarf des Systems. Legen Sie zuerst Quantisierung, Kontextlänge und Batchgröße fest. Dokumentieren Sie anschließend Durchsatz und maximalen Speicherbedarf, damit die Ergebnisse vergleichbar bleiben.

mlx-lmMetal64 GB Unified Memory
hkg-01 · Node Pro M4Beispiel für die Speicherplanung
Budget für Unified Memory64 GB
ModellgewichteKontext-CacheSystem und Reserve
python -m mlx_lm.generateInferenzaufgabe
Maximalen Speicherbedarf und Tokens/s erfassenAm jeweiligen Modell messen

Die Farbbalken veranschaulichen die Speicheraufteilung, nicht den aktuellen Speicherverbrauch des Servers.

So arbeiten Sie

Die Maschine für Ihre Aufgaben, mehr Zeit für Entwicklung

Beispiele für die Arbeitsweise von drei Rollen, in der ersten Person erzählt. Es handelt sich nicht um echte Kundenbewertungen.

„Ich möchte, dass nächtliche Builds in der Warteschlange am Standort Seoul bleiben. Wenn ich meinen lokalen Rechner zuklappe, möchte ich am nächsten Tag Logs und Artefakte anhand der Build-Nummer wiederfinden.“

Unabhängiger iOS-Entwickler · Anwendungsszenario

„Ich möchte die Toolchain und den Cache meines Runners fest einstellen. Bei Regressionstests schließe ich zunächst parallele Aufgaben aus, bevor ich die Auswirkungen von Codeänderungen bewerte.“

Verantwortlicher für Mobile CI · Anwendungsszenario

„Ich rechne Modellgewichte, Kontext-Cache und Systembedarf gemeinsam auf mein 64-GB-Budget an. Damit sich Experimente vergleichen lassen, speichere ich jedes Mal die verwendeten Parameter.“

Machine-Learning-Forscher · Anwendungsszenario

Abrechnung in US-Dollar, zwei Zahlungsarten

Wir akzeptieren USDT-TRC20 und Visa, Mastercard sowie Amex über Stripe. Welche Zahlungsoptionen verfügbar sind, zeigt die Backend-Schnittstelle. Zahlungs- und Bereitstellungsstatus prüfen Sie in der Konsole.

USDT-TRC20Visa / Mastercard / Amex · über Stripe
So setzt sich die Rechnung zusammen →

Ihre Rechnung umfasst die Mietdauer des gewählten Modells und ausgewählte Erweiterungen. Prüfen Sie vor der Zahlung Standort, Laufzeit, Speichererweiterung und Anzahl paralleler Verbindungen. Bei Zahlung on-chain kontrollieren Sie Netzwerk und Betrag; bei Kartenzahlung das Ergebnis der Bankautorisierung. Senden Sie über Supportkanäle niemals Passwörter, private Schlüssel oder vollständige Kartennummern.

Häufige Fragen

Antworten auf die vier häufigsten Fragen

Erst Bereitstellung, Verbindung und Datengrenzen klären, dann entscheiden, ob Sie mieten möchten.

Ist das eine VM?

Nein. Jede Bestellung umfasst einen Apple-Silicon-Server, der vollständig einem einzelnen Mieter zugewiesen wird. Es gibt keinen gemeinsam genutzten Host. Ihre Aufgaben, Systemeinstellungen und Projektabhängigkeiten verwalten Sie weiterhin selbst; dedizierte Ressourcen ersetzen keine Kapazitätsplanung für Ihr Projekt.

Wie stelle ich nach der Zahlung eine Verbindung her?

Zahlungs- und Bereitstellungsstatus finden Sie in den Bestelldetails der Konsole. Die Zugangsdaten erhalten Sie mit der tatsächlichen Bereitstellung. Prüfen Sie zuerst Hostadresse und SSH-Schlüssel und verbinden Sie sich dann mit dem grafischen Desktop. Verbinden Sie sich nicht anhand einer Beispielkennung auf der Startseite. Die vollständige Anleitung finden Sie in der Verbindungsanleitung.

Was sollte ich vor dem Ende der Mietzeit tun?

Laden Sie zuerst Archive, Testergebnisse und wichtige Projektdaten herunter und prüfen Sie anschließend Verlängerung und Ablaufdatum. Nach Ende der Mietzeit werden die Daten durch Löschen der Festplatte und Neuinstallation des Systems entfernt. Nutzen Sie den Server daher nicht als einziges Backup. Details zum Ablauf und zu den Bestellbedingungen finden Sie in den Nutzungsbedingungen.

Kann ich meine vorhandene CI direkt anbinden?

Ja. Registrieren Sie den Server als self-hosted Runner für GitHub Actions oder GitLab CI. Registrierungsrechte und Token kommen aus Ihrem Projekt; der Server führt die Aufgaben aus. Testen Sie die Einrichtung zunächst mit einer Pipeline und konfigurieren Sie danach Autostart, Cache und Parallelität. Bei Verbindungs- oder Build-Problemen finden Sie Hilfe in den Supporthinweisen.

Mieten Sie noch heute einen M4

Wählen Sie Modell, Standort und Laufzeit. Testen Sie zuerst einen echten Build und entscheiden Sie dann über die passende Langzeitkonfiguration.

Node Core M4 ab $21.3/Tag · gleicher Preis an allen vier Standorten · aktuelle Verfügbarkeit in der Konsole prüfen