Vier reale Szenarien – findest du dich wieder?
Jedes Beispiel nennt genau das verwendete Modell, den Standort, die Kosten und das Ergebnis. Alle Zahlen sind real, und die nachvollziehbaren Schritte findest du weiter unten.
Regression vor dem Release: In 3 Tagen für $21,6 erledigt
Ein Solo-Entwickler mietet kurzfristig einen M4 am Standort Tokio, um Archivierung und Gerätetests vor der App-Store-Einreichung nachzuholen – ohne für einen einmal jährlichen Bedarf gleich einen ganzen Mac zu kaufen.
Runner an die US-Westküste verlegt: Builds rund 40 % schneller
Ein internationales 12-köpfiges Team verlegt seinen selbstgehosteten GitHub-Actions-Runner von einem alten Intel-Mac im Büro in die Cloud – die durchschnittliche Build-Zeit sinkt von rund 21 auf etwa 12,5 Minuten.
64 GB Unified Memory: Ein 32B-Modell auf der eigenen Maschine
Ein KI-Enthusiast mietet tageweise einen M4 Pro mit 64 GB, um quantisierte LLM-Inferenz und LoRA-Fine-Tuning zu testen – gebucht, wenn nötig, gekündigt, wenn fertig. Kein Geld für ungenutzten Speicher.
Musiker an fünf Standorten teilen sich eine Logic-Pro-Workstation in der Cloud
Ein Tonstudio mietet wochenweise einen M4 Pro an der US-Westküste. Projektdateien und Sample-Bibliotheken liegen nur an einem Ort, die Musiker wechseln sich per Bildschirmfreigabe im „Studio“ ab, und die Mixing-Zeit halbiert sich.
Solo-Entwickler: M4 tageweise gemietet für die letzte Meile vor dem Release
Ein Solo-Entwickler, der hauptsächlich unter Linux mit Flutter arbeitet, braucht einen Mac eigentlich nur zur Einreichungszeit: zum Signieren und Archivieren, zum Durchgehen der App-Store-Checkliste und für die Regression in einer echten macOS-Umgebung. Dafür einen Mac mini zu kaufen würde bedeuten, dass die Maschine 360 Tage im Jahr ungenutzt herumsteht.
Seine Lösung: Kurz vor der Einreichung bucht er bei HireVPS einen Zest M4 am Standort Tokio – von der Zahlung bis zu den SSH- und VNC-Zugangsdaten dauert es etwa 2 Minuten. Am ersten Tag installiert er Xcode und die Zertifikate und archiviert den Code, am zweiten Tag geht er die Checkliste durch und behebt zwei Layout-Probleme, die nur unter macOS auftreten, am dritten Tag reicht er bei App Store Connect ein und kündigt die Maschine, sobald die Regression bestanden ist.
- Dedizierte Dedicated hardware-Hardware ohne Virtualisierung – Xcode archiviert genauso schnell wie auf einem lokalen Gerät
- Referenzlatenz vom Standort Tokio zum Nutzer von rund 60 ms – VNC läuft flüssig ohne Nachziehen (abhängig von der tatsächlichen Verbindung)
- Nach der Kündigung wird die Festplatte vollständig gelöscht – Zertifikate und Quellcode bleiben nicht auf der Maschine zurück
„Früher musste ich mir für jede Einreichung ein MacBook von einem Freund leihen. Jetzt erledige ich das für $21,6, kündige nach der Regression und muss mir keine Gedanken mehr machen.“
Konfiguration im Überblick
- ModellZest M4 · 16GB · 256GB SSD
- StandortTokio (JP)
- Abrechnung$21,6/Tag, insgesamt 3 Tage für $21,6
- EinsatzzweckXcode-Archivierung + Regression vor der Einreichung
- BereitstellungZugangsdaten etwa 2 Minuten nach Zahlung
Internationales Team: Runner an die US-Westküste verlegt, keine Warteschlangen mehr bei Builds
Ein 12-köpfiges internationales App-Team hat seine iOS-Builds bisher auf einem 2018er Intel Mac mini in der Ecke des Büros laufen lassen: langsame Builds, Warteschlangen am Tag, und nachts konnte niemand die Maschine neu starten. Da das Team über zwei Zeitzonen verteilt ist, mussten Builds, die die US-Kollegen einreichten, oft warten, bis die asiatischen Kollegen zur Arbeit kamen und hängende Jobs neu starteten.
Die Migration hat nur einen Nachmittag gedauert: Sie buchen bei HireVPS einen Citrus M4 im Monatsabo am Standort US-Westküste, registrieren ihn als selbstgehosteten GitHub-Actions-Runner und ändern im Workflow runs-on auf ein benutzerdefiniertes Label. Die Build-Artefakte werden per fastlane direkt an TestFlight übergeben. Alle Standorte sind 365 Tage im Jahr durchgängig online – auch mitten in der Nacht eingereichte Builds werden pünktlich fertig.
Konfiguration im Überblick
- ModellCitrus M4 · 24GB · 512GB SSD
- StandortUS-Westküste (US-W)
- AbrechnungMonatsabo $198,2
- EinsatzzweckSelbstgehosteter GitHub-Actions-Runner
- PipelineXcode + fastlane → TestFlight
„Die deutlichste Veränderung: Niemand fragt mehr im Chat, wer gerade die Build-Maschine belegt.“
KI-Enthusiast: 64 GB Unified Memory – jedes Modell läuft, das er will
Ein KI-Enthusiast wollte systematisch vergleichen, wie sich die Ausgabequalität großer Sprachmodelle bei unterschiedlichen Quantisierungsstufen verändert – wollte dafür aber nicht extra ein High-End-Gerät für ein paar Wochenend-Experimente kaufen. Die Unified-Memory-Architektur von Apple Silicon kommt lokaler Inferenz sehr entgegen: 64 GB Arbeitsspeicher bedeuten, dass ein 32B-Modell in 4-Bit-Quantisierung vollständig im Speicher gehalten werden kann, ohne beim VRAM Kompromisse eingehen zu müssen.
Er mietet tageweise einen Blaze M4 Pro an der US-Westküste und testet abwechselnd mit llama.cpp und MLX: Die Inferenz des 32B-4-Bit-Modells läuft mit etwa 11–14 Token/s, ein LoRA-Fine-Tuning-Experiment mit einem 7B-Modell ist über Nacht abgeschlossen (Richtwerte, abhängig von Modell, Kontextlänge und Parametern – maßgeblich sind die tatsächlichen Messwerte). Auf der 2-TB-SSD ist Platz für ein Dutzend Modellgewichte gleichzeitig; nach Abschluss der Experimente exportiert er die Ergebnisse und kündigt die Maschine.
- Dedizierte Dedicated hardware-Hardware – niemand teilt sich die Rechenleistung während der Inferenz, weil es schlicht keine Mitnutzer gibt
- Root-Zugriff für freie Framework-Installation und Kernel-Extension-Abhängigkeiten
- Tagesabrechnung: Ein Wochenend-Experiment kostet $43,2 statt eine Maschine für über $3000
Konfiguration im Überblick
- ModellBlaze M4 Pro · 64GB · 2TB SSD
- StandortUS-Westküste (US-W)
- Abrechnung$21,6/Tag
- EinsatzzweckLokale LLM-Inferenz + LoRA-Fine-Tuning
- Durchsatz-Richtwert32B 4-Bit ca. 11–14 Token/s
Tonstudio: Logic-Pro-Projekt in die Cloud verlegt, Musiker an fünf Standorten wechseln sich im „Studio“ ab
Ein kleines Tonstudio übernimmt ein internationales Projekt: Der Produzent sitzt in Los Angeles, das Arrangement entsteht in Taipeh, das Mixing in Tokio. Bisher wurden Projektdateien hin- und hergeschickt, Versionskonflikte waren an der Tagesordnung, und allein das Warten auf Dateien kostete pro Song zwei bis drei Tage.
Jetzt mieten sie wochenweise einen Blaze M4 Pro an der US-Westküste: Das Logic-Pro-Projekt, die Plug-ins und die Sample-Bibliothek liegen nur einmal in der Cloud, die 1-TB-SSD bietet genug Platz für das gesamte Sample-Material des Projekts. Alle drei wechseln sich zeitlich ab und greifen per Bildschirmfreigabe auf dieselbe Maschine zu – Änderungen wirken sofort, Streit darüber, welche Version die aktuelle ist, gibt es nicht mehr. Die Plug-in-Lizenzen werden gemäß den jeweiligen Herstellerbedingungen auf diese Maschine übertragen und aktiviert; vor Projektende werden alle Projektdateien exportiert und die Maschine anschließend gekündigt.
- Der Standort US-Westküste bietet für den Musiker in Los Angeles nahezu lokale Latenz; Tokio und Taipeh arbeiten per Bildschirmfreigabe, was für Schnitt und Mixing gut funktioniert (Echtzeitaufnahmen sollten weiterhin lokal erfolgen und anschließend hochgeladen werden)
- Die wochenweise Abrechnung passt zum projektbasierten Rhythmus – zwischen Projekten fallen keine Kosten an
- Kostenlose Neuinstallation: Nach Projektende macOS mit einem Klick zurücksetzen, das nächste Projekt startet mit einer sauberen Umgebung
„Gespart haben wir nicht in erster Linie Geld, sondern die Nächte, in denen wir zu dritt ein 80-GB-Projektpaket hin- und herschicken mussten.“
Konfiguration im Überblick
- ModellBlaze M4 Pro · 64GB · 2TB SSD
- StandortUS-Westküste (US-W)
- AbrechnungWochenmiete (Tagespreis $21,6, Wochenpreis siehe Preisseite)
- EinsatzzweckRemote-Zusammenarbeit und Mixing in Logic Pro
- ZugriffVNC / macOS-Bildschirmfreigabe
Zum Nachbauen: Zwei zentrale Konfigurationen aus den Beispielen
Die wichtigsten Schritte aus Beispiel 2 und Beispiel 1 sind in diesen beiden Konfigurationen zusammengefasst. Öffne auf deinem Cloud Mac das Terminal, ersetze die Platzhalter in den spitzen Klammern – fertig. Eine ausführlichere Anleitung findest du im Support-Center.
GitHub-Actions-Runner registrieren
# 1. On your cloud Mac, create a runner directory
mkdir ~/actions-runner && cd ~/actions-runner
# 2. Download the macOS arm64 runner package —
# copy the exact command from your repo:
# Settings -> Actions -> Runners -> New self-hosted runner
# 3. Register the runner against your repository
./config.sh --url <your-repo-url> \
--token <runner-token> \
--labels macos,arm64,hirevps --unattended
# 4. Install as a service so it survives reboots
./svc.sh install && ./svc.sh start
Setze im Workflow runs-on auf [self-hosted, macos, hirevps], damit der Job auf dieser Maschine landet.
Build mit fastlane und direkter Übergabe an TestFlight
# fastlane/Fastfile — archive & upload from your cloud Mac
default_platform(:ios)
lane :release do
setup_ci # temporary keychain on the runner
match(type: "appstore", readonly: true)
build_app(
scheme: "<YourScheme>",
export_method: "app-store"
)
upload_to_testflight(
skip_waiting_for_build_processing: true
)
end
Zertifikate werden zentral über match verwaltet – nach Kündigung und Neustart der Maschine reicht ein einmaliger Abruf, um die Build-Fähigkeit wiederherzustellen.
Erzähl uns von deinem Workflow und erhalte einen Gutschein über $20
Hast du auf einem Cloud Mac einen Workflow umgesetzt, der hier noch nicht vorkommt? Schreib uns: welches Modell und welchen Standort du genutzt hast, welches Problem du damit gelöst hast und worauf man achten sollte. Wird dein Beitrag veröffentlicht, erhält dein Konto einen Gutschein über $20, einlösbar für jeden Abrechnungszeitraum.
- Jede Form ist willkommen: ein paar hundert Wörter, eine bebilderte Anleitung oder eine Sammlung von Terminal-Befehlen
- Namensnennung nach Wunsch: mit Pseudonym oder komplett anonym
- Zahlen sollen stimmen: Angaben zu Zeit und Kosten bitte auf Basis realer Messwerte – wir sprechen sie vor der Veröffentlichung mit dir ab
Kurzanleitung für deinen Beitrag
Ein guter Beitrag enthält in der Regel vier Elemente:
- Ausgangslage: Wer du bist und welches Problem du hattest
- Lösung: Modell, Standort, Abrechnungszeitraum und die Gründe für diese Wahl
- Ergebnis: Die entscheidenden Zahlen im Vorher-Nachher-Vergleich
- Stolperfallen: Ein oder zwei Dinge, die du gern früher gewusst hättest
Bitte gib im Betreff „Praxisbeitrag“ an, damit wir ihn vorrangig bearbeiten können.