Workflows aus der Praxis

Vier Teams, ein physischer Mac mini

Erledigen Sie Ihre Aufgaben auf einem dedizierten Cloud Mac: kompilieren Sie remote, führen Sie kontinuierlich Tests aus, betreiben Sie MLX-Inferenzdienste oder bearbeiten Sie Medien. Hier finden Sie die einzelnen Schritte und konkrete Empfehlungen für die passende Konfiguration.

Cloud Mac mieten Modelle und Preise vergleichen

Exklusiv für Sie – keine virtuelle Maschine. Wählen Sie einen Mietzeitraum von einem Tag, einer Woche, einem Monat oder einem Quartal. Die aktuelle Verfügbarkeit wird live in der Konsole angezeigt.

VMR / WORKBOOK Konfiguration nach Aufgabe
01Build & ReleaseXcode → TestFlight
02Continuous IntegrationPR → eigener Runner
03ModelldienstMLX → SSH-Tunnel
04MedienproduktionMedien → Transcodierung & Sichtung
Workflows ansehen

Erst die Aufgabe, dann den Mietplan wählen

Die folgenden Beispiele zeigen wiederverwendbare Workflows, keine Kundenstimmen oder Leistungsbenchmarks. Jede Karte beschreibt, wie eine Aufgabe auf dem Server ausgeführt wird, welches Ergebnis entsteht und wo die Grenzen der Konfiguration liegen.

01 / DEVIndie-Entwickler

Tagsüber entwickeln, abends releasen

Verbinden Sie sich per SSH oder über die grafische Oberfläche mit demselben Cloud Mac. Passen Sie tagsüber Ihre App in Xcode an und testen Sie sie im Simulator. Prüfen Sie vor dem Release die Signiermaterialien und führen Sie abends fastlane beta aus, um den Build an TestFlight zu übermitteln.

Für kurze Release-Sprints bieten sich Tages- oder Wochenmieten an. Projektdateien, Build-Cache und Release-Skripte bleiben auf dem Server – so müssen Sie Ihre Arbeitsumgebung bei der nächsten Verbindung nicht neu einrichten.

Wichtige ToolsXcode · fastlane
02 / CICI-Team

Jeder PR durchläuft dieselbe Testumgebung

Registrieren Sie einen selbst gehosteten Runner auf einem monatlich gemieteten physischen Server. Sobald ein PR im Repository eingeht, startet xcodebuild test. Die Testergebnisse fließen in Ihren bestehenden CI-Prozess zurück. Der Build-Cache bleibt auf demselben Rechner und erleichtert die Analyse wiederkehrender Probleme.

Prüfen Sie zunächst die Zahl paralleler Jobs und den Speicherbedarf Ihres Projekts. Anders als bei gemeinsam genutzten virtuellen Maschinen konkurrieren Sie nicht mit anderen Mietern um Ressourcen. Die Job-Warteschlange auf einem einzelnen Server muss Ihr Team jedoch selbst verwalten.

Wichtige ToolsRunner · xcodebuild
03 / MLXKI-Experimente

Quantisierte Modelle direkt im Dienstprozess laden

Legen Sie die Modelldateien auf einem VMR Lab Pro mit M4 Pro, 64 GB gemeinsam genutztem Arbeitsspeicher und 2 TB SSD ab und starten Sie mlx_lm.server. Der Dienst läuft auf dem physischen Server. Teammitglieder greifen jeweils über ihren eigenen SSH-Tunnel darauf zu, ohne den Inferenz-Port direkt im Internet freizugeben.

Schätzen Sie für die Auswahl den Gesamtbedarf von Modellgewichten, Kontext und weiteren Prozessen ab. 64 GB bezeichnet den Arbeitsspeicher des gesamten Rechners und ist keine Garantie, dass diese Kapazität einem einzelnen Modell vollständig zur Verfügung steht.

Wichtige ToolsMLX · SSH-Tunnel
04 / MEDIAMedien-Workflow

Medien und Transcodierung auf dem Server lassen

Speichern Sie Ihre Medien auf dem Cloud Mac und wählen Sie bei Bedarf die zusätzliche 2-TB-SSD. Erstellen Sie auf dem Server Proxy-Dateien, transcodieren Sie Dateien stapelweise und rendern Sie Projekte. Prüfen Sie das Material anschließend per Remote-Desktop. Kontrollieren Sie vor der Übergabe das Ausgabeformat und laden Sie das fertige Ergebnis herunter.

Berechnen Sie vorab den gleichzeitig benötigten Speicherplatz für Quelldateien, Cache und Ausgabedateien. Die Remote-Ansicht eignet sich zur Sichtung; die endgültige Bildqualität sollten Sie anhand der exportierten Originaldatei prüfen.

Wichtige ToolsRemote-Desktop · +2 TB SSD
Workflow 03 / KI-Experimente

Modell und Dienst auf demselben Mac betreiben

Beim Apple Silicon nutzen CPU und GPU den gemeinsamen Arbeitsspeicher. Für einen MLX-Dienst müssen Sie nicht jeweils einen separaten Speicherbedarf für GPU und Systemarbeitsspeicher einplanen. Lassen Sie dennoch ausreichend Kapazität für Kontext, Cache, System und parallele Anfragen frei.

Der Ablauf beginnt mit den Modelldateien: Prüfen Sie Format und Lizenz, installieren Sie mlx-lm und starten Sie den Dienst auf dem Server. Greifen Sie ausschließlich über eine lokale SSH-Portweiterleitung darauf zu. Ob das Modell in den Speicher passt und wie viele Anfragen parallel verarbeitet werden können, hängt vom Modell und den Laufzeitparametern ab – der Modellname allein sagt darüber nichts aus.

  1. VorbereitenPrüfen Sie Dateigröße, Quantisierung und verfügbaren Speicherplatz des Modells.
  2. StartenStarten Sie den Dienst auf dem physischen Server und protokollieren Sie den tatsächlichen Speicherverbrauch.
  3. VerbindenRufen Sie die Schnittstelle lokal über einen SSH-Tunnel auf.
MLX-Bereitstellung im Überblick
Schematische Darstellung des Ablaufs; keine Messwerte für Speicherverbrauch oder Durchsatz und kein öffentlich erreichbarer Dienst.
Workflow 01 / Versionsanpassung

Von der Simulator-Matrix bis zu TestFlight

Eine Anpassung an eine neue Version ist mehr als ein erfolgreicher Build. Erfassen Sie zunächst die tatsächlich unterstützten Gerätegrößen und Betriebssystemversionen. Führen Sie die entsprechenden Simulator-Tests auf dem Cloud Mac aus, werten Sie fehlgeschlagene Tests aus, beheben Sie Probleme und erstellen Sie einen neuen Build.

Automatisierte Tests lassen sich mit xcodebuild test ausführen. Für die manuelle Prüfung von Layouts, Berechtigungsabfragen oder Interaktionsabläufen wechseln Sie in die grafische Oberfläche. Anschließend reichen Sie den Build mit den vorhandenen Signiermaterialien und Release-Skripten bei TestFlight ein und prüfen den Verarbeitungsstatus in der Build-Liste.

  1. Matrix erstellenNur tatsächlich unterstützte Kombinationen aus System und Bildschirmgröße berücksichtigen.
  2. Tests ausführenFehlerprotokolle speichern und Umgebungsprobleme von Regressionen im Code unterscheiden.
  3. Release prüfenArchiv, Upload und Status des TestFlight-Builds kontrollieren.
Erste Verbindung einrichten
Schematische Übersicht der Simulator-Matrix und Build-Liste; die konkreten Geräte und Betriebssystemversionen richten sich nach dem Umfang der Projektunterstützung.
Release / Szenenablauf

Wie ein Server eine Release-Woche unterstützen kann

Ein beispielhafter Ablauf aus Entwicklersicht, kein echtes Nutzerinterview und keine Kundenbewertung. Der Zeitraum von einer Woche bündelt die Einrichtung, Regressionstests, den Build-Upload und die Prüfung nach dem Release. Ob eine Wochenmiete passt, hängt von Ihrem eigenen Zeitplan ab.

01

Umgebung vorbereitenImportieren Sie das Projekt und die benötigten Signiermaterialien sicher auf den Server und prüfen Sie die Xcode-Toolchain.

02

Regressionstests abschließenFühren Sie automatisierte Tests aus und prüfen Sie remote die Seiten, die manuell kontrolliert werden müssen.

03

Version einreichenArchivieren Sie den Build, laden Sie ihn hoch und prüfen Sie den Verarbeitungsstatus in TestFlight.

04

AbschlussExportieren Sie die Protokolle und Dateien, die Sie behalten möchten. Entscheiden Sie anschließend, ob Sie den Server weiter nutzen.

Diese Szenenkarte enthält kein abspielbares Video. Sie unterteilt einen Release-Ablauf in vier nachvollziehbare Schritte, damit die Darstellung nicht mit einer Nutzerstimme verwechselt wird.

Konfigurationsvergleich

Nach Auslastung, Laufzeit und Teamstandort auswählen

Die Tabelle dient als Orientierung, nicht als Leistungsversprechen. Beide Modelle sind an Standorten in Singapur, Tokio, Seoul, Hongkong oder im Westen der USA verfügbar. Wählen Sie zunächst den Standort in der Nähe der Hauptnutzer und prüfen Sie anschließend die Verbindung unter realen Team-Bedingungen.

Empfohlene Modelle, Mietzeiträume und Standortkriterien für vier Workflows
Workflow Empfohlenes Modell Empfohlener Zeitraum Standortwahl Vor der Buchung prüfen
Indie-Entwicklung & Release VMR Lab M4
M4 · 16 GB · 256 GB		 Für kurze Sprints Tages- oder Wochenmiete prüfen In der Nähe des Hauptentwicklers für bequemes Remote-Arbeiten Speicherbedarf für Projekt, Build-Cache und Signiermaterialien
Continuous Integration VMR Lab M4
M4 · 16 GB · 256 GB		 Für einen dauerhaft verfügbaren Runner Monatsmiete prüfen Standort des Code-Repositorys und Verbindungen des Teams berücksichtigen Job-Warteschlange auf einem Rechner, Spitzenbedarf des Projekts und Cache-Speicher
MLX-Inferenzexperimente VMR Lab Pro
M4 Pro · 64 GB · 2 TB		 Für Tests Wochenmiete, für Dauerbetrieb Monatsmiete prüfen In der Nähe der wichtigsten Nutzer; Zugriff über SSH-Tunnel Modellgewichte, Kontext, parallele Anfragen und Speicherreserve
Medienproduktion VMR Lab Pro
M4 Pro · 64 GB · 2 TB		 Wochen- oder Monatsmiete passend zum Projektzeitplan wählen In der Nähe des Teams für Upload und Sichtung der Medien Quelldateien, Cache, Ausgabedateien und möglicher Bedarf an einer zusätzlichen 2-TB-SSD

Weitere buchbare Kombinationen bleiben verfügbar. Preise, Zusatzoptionen und Mietzeiträume richten sich nach dem Mietplan; die aktuelle Verfügbarkeit wird live in der Konsole angezeigt.

Nächster Schritt / Server konfigurieren

Passendes Szenario wählen und Mietplan prüfen

Legen Sie zuerst den benötigten Arbeitsspeicher und Speicherplatz fest, wählen Sie dann Mietzeitraum und Standort. Beide Modelle sind dedizierte physische Mac minis. Wenn Sie noch unsicher sind, starten Sie mit dem Preis- und Konfigurationsvergleich.

Cloud Mac jetzt konfigurieren Mietpläne ansehen