Erst Antworten finden, dann bestellen

Jede Miete umfasst einen physischen Mac mini, der einem einzelnen Kunden zugewiesen ist – keine VM auf einem gemeinsam genutzten Host. CPU, GPU und Unified Memory stehen den Aufgaben auf diesem Gerät zur Verfügung. Das eignet sich für MLX-Modelldienste mit dauerhaftem Bedarf an Unified Memory und für CI-Pipelines, deren Builds nicht mit anderen Kunden um Ressourcen konkurrieren sollen.

Das bedeutet nicht, dass jede Aufgabe gleich schnell läuft: Modellgröße, Quantisierung, Build-Cache und Netzwerkverbindung beeinflussen weiterhin die Leistung. Berechnen Sie bei der Auswahl zuerst den Speicherbedarf der Modellgewichte und den Spitzenbedarf an Arbeitsspeicher. Vergleichen Sie anschließend die Technischen Daten der drei Modelle.

Nein. Nach der Bereitstellung stehen die lokale CPU, GPU, der Unified Memory und die gewählte Speicheroption dieses Mac mini dem aktuellen Kunden zur Verfügung. Das Netzwerk des Rechenzentrums gehört zur Infrastruktur; die Rechenressourcen des Geräts werden dadurch nicht mit anderen Kunden geteilt. Wenn Sie Build-Aufgaben und einen dauerhaft laufenden Inferenz-Endpunkt gleichzeitig ausführen, sollten Sie für beide Prozesse genügend Arbeitsspeicher einplanen und nicht den gesamten Unified Memory den Modellgewichten zurechnen.

In der bereitgestellten macOS-Umgebung können Sie lizenzkonforme Entwicklungstools, Paketmanager und Laufzeitabhängigkeiten installieren, darunter Xcode Command Line Tools, Homebrew, Python-Umgebungen und MLX-Software. Bevor Sie Einstellungen für den Fernzugriff, Netzwerk-Proxys oder den Dienststart ändern, sollten Sie die bisherigen Einstellungen für eine mögliche Wiederherstellung dokumentieren. Deaktivieren Sie insbesondere nicht den bestehenden Zugriffsweg, bevor Sie bestätigt haben, dass die Anmeldung per Schlüssel funktioniert.

Wählen Sie zuerst ein Modell und dann eine Vorauszahlungsperiode. Für jede der vier Laufzeiten gilt ein eigener Listenpreis – der Wochen- oder Monatspreis wird nicht aus dem Tagespreis hochgerechnet. XOps 16 kostet zum Beispiel $19.4 pro Tag, $52.3 pro Woche, $96.8 pro Monat und $263.3 pro Quartal. Erweiterungen des Speichers oder Thunderbolt 5 im Verbund werden je nach Laufzeit zusätzlich berechnet. Prüfen Sie vor der Bestellung die vollständige Preisübersicht.

Möchten Sie ein Modell nur kurzfristig testen, beginnen Sie am besten mit der Tagesmiete. Soll ein Inferenz-Endpunkt dauerhaft verfügbar sein, vergleichen Sie direkt die Listenpreise für Woche, Monat und Quartal. Dievollständige Preisübersicht mit Zusatzoptionenenthält die Preise für alle drei Konfigurationen und vier Laufzeiten.

Unterstützt werden USDT-TRC20 sowie Visa, Mastercard und Amex, abgewickelt über Stripe. Alle Listenpreise und Rechnungsbeträge sind in US-Dollar (USD) angegeben. Welche Zahlungsanbieter beim Bezahlvorgang verfügbar sind, zeigt das Kontrollpanel in Echtzeit an. Prüfen Sie vor der Zahlung, ob Netzwerk, Betrag und Bestelldaten übereinstimmen.

Prüfen Sie das Ablaufdatum Ihrer Bestellung im Kontrollpanel und verlängern Sie dort die Laufzeit. Gehen Sie nicht davon aus, dass sich die Laufzeit verlängert, nur weil eine Aufgabe noch läuft. Wird die Bestellung nicht rechtzeitig verlängert, wird das Gerät gemäß den Bestellbedingungen freigegeben. Lokale Dateien, Modellgewichte und Build-Caches auf einem freigegebenen Gerät stehen dann nicht mehr online zur Verfügung. Exportieren Sie benötigte Daten vor dem Ablauf und überprüfen Sie die Kopie. Bei Fragen zum Bestellstatus können Sie sichim Kontrollpanel anmelden und ein Supportticket erstellen.

Prüfen Sie vor der Bestellung die Zusatzoptionen, Laufzeit und Gesamtsumme in US-Dollar in der Konfigurationsübersicht. Bestellungen und Abrechnungsbelege finden Sie anschließend im Kontrollpanel. Bevor Sie Zusatzoptionen ändern oder beenden, prüfen Sie, welche Aktionen für Ihre aktuelle Bestellung verfügbar sind. Löschen Sie nicht einfach Dateien auf dem Laufwerk, um ein Abonnement zu beenden. Fügen Sie Supporttickets zu Zahlungsvorgängen die Bestellnummer und die Transaktionskennung bei. Senden Sie niemals vollständige Kartendaten oder private Schlüssel.

Sie können zwischen Singapur, Tokio, Seoul und Hongkong wählen. Für XOps 16, XOps 24 und XOps Pro 64 sind alle vier Standorte im Angebot enthalten. Welche davon bei Ihrer Bestellung verfügbar sind, zeigt das Kontrollpanel in Echtzeit an. Berücksichtigen Sie neben dem Standort Ihres Teams auch die Netzverbindung für den Upload von Modellgewichten, die Synchronisierung von Code-Repositories und den Fernzugriff per Remote Desktop.

Messen Sie zuerst von den Orten aus, an denen Sie hauptsächlich Inferenz-Endpunkte aufrufen oder den Remote Desktop bedienen, statt sich nur an der Entfernung auf der Karte zu orientieren. Messen Sie die Round-Trip-Latenz zu den infrage kommenden Standorten und testen Sie anschließend einen Upload mit derselben Dateigröße. Bei CI-Builds sollten Sie auch die Verbindung für Code- und Abhängigkeitsdownloads vergleichen. Als ersten Anhaltspunkt können Sie dieLatenztabelle der Standorte im Verbindungsleitfadennutzen und anschließend mit Ihrem eigenen Netzwerk erneut messen.

Die Tabelle im Leitfaden zeigt den Durchschnitt von 100 ICMP-Tests über einen privaten Breitbandanschluss an einem Werktagabend. Sie dient nur zum ersten Vergleich der Standorte. Die Werte garantieren weder die Reaktionszeit von SSH-Befehlen noch die Bildrate in VNC oder die Geschwindigkeit bei der Übertragung großer Dateien. Routing durch den Internetanbieter, Paketverluste, Dateigröße und Client-Einstellungen wirken sich auf die tatsächliche Nutzung aus. Wenn Sie den Remote Desktop langfristig verwenden möchten, testen Sie die Verbindung über Ihren eigenen Internetzugang.

16 GB eignen sich für den Einstieg mit kleineren quantisierten Modellen und für Experimente allein. Mit 24 GB lässt sich ein dauerhaft laufender Dienst mit häufig verwendeten 7B- bis 8B-Modellen in 4-Bit-Quantisierung erproben. 64 GB eignen sich besser für größere Modelle, mehrere Modelle gleichzeitig oder parallel laufende Build-Workloads. Das sind Richtwerte für die Planung, keine Garantie, dass ein Modell einer bestimmten Parametergröße auf jeden Fall geladen werden kann.

Berücksichtigen Sie bei der Schätzung die Modellgewichte, den KV-Cache, die Kontextlänge, parallele Anfragen und den Speicherbedarf von macOS und planen Sie zusätzliche Reserven ein. Ein Modell laden zu können, bedeutet nicht automatisch, dass der gewünschte Durchsatz erreicht wird. Testen Sie die Leistung daher vor der Auswahl mit realistischen Anfragen auf der passenden Konfiguration.

Ja. Beide lassen sich installieren und ausführen, doch ihre Modellgewichte, Caches und parallelen Anfragen beanspruchen gemeinsam die Ressourcen des Geräts. Prüfen Sie zunächst den maximalen Ressourcenbedarf jedes Dienstes einzeln und testen Sie anschließend den gleichzeitigen Betrieb. Wenn der Arbeitsspeicher knapp wird oder die Antwortzeiten deutlich steigen, helfen weniger parallele Anfragen, zeitversetzte Starts oder ein Modell mit mehr Arbeitsspeicher meist besser als eine Änderung des Ports.

Starten Sie mlx_lm.server für einen OpenAI-kompatiblen Endpunkt zunächst so, dass der Dienst nur auf der lokalen Loopback-Adresse lauscht. Gewähren Sie kontrollierten Clients im Team anschließend über einen SSH-Tunnel Zugriff. Wenn Sie den Zugriff über einen Reverse Proxy benötigen, richten Sie Authentifizierung, Transportverschlüsselung und Zugriffsbeschränkungen separat ein. Stellen Sie einen ungeschützten Inferenz-Port niemals direkt ins öffentliche Internet.

MLX-Schnellstartzeigt die Reihenfolge für Installation, Start und Verbindung. Prüfen Sie vor dem Produktivbetrieb Arbeitsspeicher und Durchsatz mit den tatsächlichen Modellen und Anfragen Ihres Teams.

Ja. Sie können je nach Projektbedarf mehrere Versionen installieren und behalten. Prüfen Sie dabei den verfügbaren Speicher, die Kompatibilität mit der jeweiligen macOS-Version und die Softwarelizenzen. Legen Sie vor dem Start automatisierter Aufgaben die benötigte Version fest und dokumentieren Sie den Pfad der verwendeten Command Line Tools. So verhindern Sie, dass ein Runner beim Build eines anderen Branches versehentlich die Toolchain des vorherigen Jobs verwendet. Übertragen Sie Signaturmaterial ausschließlich mit den vom Team autorisierten Export- und Importverfahren.

Prüfen Sie zunächst per SSH, ob Code-Repository, Xcode und Build-Abhängigkeiten verfügbar sind. Fügen Sie das Gerät anschließend über den Registrierungsprozess Ihrer CI-Plattform zum Team hinzu. Verwenden Sie für den Runner am besten ein eigenes Arbeitsverzeichnis und minimale Berechtigungen. Legen Sie außerdem fest, wie der Cache bereinigt wird und wie viele Jobs gleichzeitig laufen dürfen. Lassen Sie beim ersten Pipeline-Lauf nur die Umgebung prüfen. Sobald Toolchain und Signaturkonfiguration stimmen, können Sie reguläre Archivierungsaufgaben einbinden.

Die vollständige Reihenfolge für die Einrichtung der Umgebung und die CI-Anbindung finden Sie imEinstiegsleitfaden.

Auf einem Cloud-Mac können Sie den Xcode-Simulator ausführen, Builds und automatisierte Tests durchführen und die für die Verteilung benötigten Build-Artefakte erstellen. Er ersetzt jedoch kein physisches iOS-Testgerät, das Ihrem Team vor Ort zur Verfügung steht. Tests, die von Kamera, Bluetooth, Sensoren, Mobilfunk oder anderer Hardware abhängen, müssen weiterhin auf echten Geräten durchgeführt werden. Sie können Regressionstests im Simulator in CI ausführen und hardwareabhängige Prüfungen den Tests auf physischen Geräten überlassen.

Nach der Freigabe wird das gesamte Laufwerk gelöscht und das Gerät für die spätere Bereitstellung neu eingerichtet. Verlassen Sie sich für Modellgewichte, Projektdateien, Schlüssel und Build-Artefakte nicht auf ein freigegebenes Gerät als einzige Kopie. Exportieren Sie benötigte Daten vor der Freigabe an einen von Ihnen verwalteten Speicherort und prüfen Sie, ob sich das Archiv tatsächlich öffnen lässt. Ein gestarteter Synchronisierungsvorgang allein bedeutet nicht, dass eine Sicherung abgeschlossen ist.

Während der Mietdauer können Sie selbst verwaltete Daten per SSH mit einer für die Dateigröße geeigneten Methode exportieren. Prüfen Sie bei großen Dateien zunächst den verfügbaren Speicherplatz und den Zielpfad. Synchronisieren Sie die Daten dann in mehreren Schritten und überprüfen Sie das Ergebnis. Build-Caches lassen sich in der Regel neu erstellen. Behalten Sie bei der Migration daher vor allem Projektdateien, Konfigurationen und Modellgewichte, die sich nicht wiederherstellen lassen. Die genaue Reihenfolge für die rsync Migration finden Sie imLeitfaden zu Verbindung & Migration.

Verwenden Sie für das Kontrollpanel eigene, sichere Zugangsdaten. Greifen Sie bevorzugt mit SSH-Schlüsseln auf das Gerät zu und beschränken Sie Speicherort und Zugriffsrechte des privaten Schlüssels. Verbinden Sie sich mit dem VNC-Remote-Desktop am besten über einen SSH-Tunnel und geben Sie den Dienst-Port nicht direkt öffentlich frei. Prüfen Sie bei Änderungen im Team zeitnah bestehende Berechtigungen, Runner-Zugangsdaten und Deployment-Schlüssel. Wenn Sie verdächtige Zugriffe bemerken, können Sie sichim Kontrollpanel anmelden und ein Supportticket erstellen.