Jede VMCache-Miete umfasst einen dedizierten physischen Knoten. Prozessor, Unified Memory und lokaler Speicher werden nicht mit anderen Mietern geteilt. Die Hardware-Isolation ist die Grundlage, ersetzt aber weder Kontoverwaltung noch Credential-Schutz, Backups oder Zugriffskontrollen für Dienste.
Die folgenden Punkte sind unabhängig voneinander. Das Erfüllen eines Punkts bedeutet nicht, dass die übrigen automatisch erfüllt sind.
Dedizierte physische Knoten reduzieren Störungen durch gemeinsam genutzte Ressourcen. Die Sicherheit hängt jedoch weiterhin davon ab, wie Ihr Team Konten vergibt, Secrets speichert, Netzwerkdienste öffnet und Datenkopien aufbewahrt.
Die Bestellung liefert einen dedizierten physischen Rechner. Prozessor, Unified Memory und lokaler Speicher werden weder mit anderen Mietern geteilt noch als gemeinsame virtuelle Maschine bereitgestellt.
Zugangsdaten zeigen nur, wer den Knoten betreten kann. Welche Aktionen danach möglich sind, bestimmen weiterhin Systemkonten, Verzeichnisrechte, Aufgabenidentitäten und interne Teamfreigaben.
Die lokale Festplatte des Knotens ist Arbeitsbereich und darf nicht die einzige Kopie sein. Code, Modelle, Artefakte, Protokolle und Konfigurationen gehören in bestehende Versions-, Artefakt- oder Backup-Prozesse Ihres Teams.
Zugangsdaten ausschließlich über die Bestellverwaltung abrufen. Nicht in öffentliche Chatkanäle, Betreffzeilen von Tickets, Code-Repositorys, Build-Ausgaben oder ungeschützte Teamdokumente kopieren.
Zuerst Bestellkennung, Modell, Knoten und aktuellen Bereitstellungsstatus prüfen, damit Zugangsdaten eines anderen Rechners nicht in die Arbeitsdokumentation gelangen.
Über ein vertrauenswürdiges Netzwerk und ein verwaltetes lokales Gerät auf die Konsole zugreifen. Vollständige Zugangsdaten weder in Bildschirmfreigaben noch in Aufzeichnungen oder Livestreams zeigen.
Muss Ihr Team den Zugriff übergeben, verwenden Sie das eigene Secret-Management-Tool und begrenzen Sie Objekte, Gültigkeitsdauer und Prüfbereich.
Feldnamen, Fehlerphase und notwendigen Kontext beibehalten, aber Passwörter, private Schlüssel, Tokens, vollständige Verbindungszeichenfolgen und personenbezogene Daten entfernen.
Interaktive Anmeldung, CI/CD und Modelldienste sind unterschiedlichen Risiken ausgesetzt. Getrennte Identitäten, Verzeichnisrechte und Secret-Zugriffsbereiche begrenzen die Folgen von Fehlbedienung oder Credential-Leaks.
| Identitätszweck | Empfohlene Berechtigungen | Secret-Umfang | Protokollanforderungen |
|---|---|---|---|
| Interaktive Anmeldung Manuelle Konfiguration und Fehlersuche |
Nur die für die aktuelle Wartungsarbeit erforderlichen System- und Verzeichnisrechte vergeben | Tokens für automatisierte Aufgaben nicht dauerhaft speichern | Änderungszeit, betroffenes Objekt und Ergebnis protokollieren |
| CI/CD Abhängigkeiten abrufen, erstellen und archivieren |
Arbeitsverzeichnis, Build-Tools und Artefaktverzeichnis begrenzen | Erforderliche Signaturmaterialien und Repository-Tokens pro Pipeline abrufen | Aufgabennummer protokollieren, Umgebungsvariablen und Signaturinhalte filtern |
| Modelldienst Modelle laden und Anfragen verarbeiten |
Modellverzeichnis, Dienstprozess und Listener-Port begrenzen | Nur Modellquelle, Dienstauthentifizierung und erforderliche Speicher-Credentials lesen | Keine vollständigen Prompts, Tokens oder sensiblen Antworttexte protokollieren |
Neue Aufgaben starten ohne zusätzliche Berechtigungen und nur bei klarer Notwendigkeit eine prüfbare Autorisierung ergänzen.
Nach Änderungen an Personen, Pipelines oder Modelldiensten Konten, Tokens, Verzeichnisse und Netzwerkrechte erneut prüfen.
Jede Aufgabenidentität muss einzeln deaktivierbar sein, ohne den gesamten Knoten zu löschen oder andere Workloads zu unterbrechen.
Der Knoten eignet sich für Build- und Inferenzaufgaben, sollte aber nicht der einzige Speicherort für Code, Modelle oder Artefakte sein. Planen Sie den Ausstieg frühzeitig, damit am Ende der Mietdauer keine wiederherstellbare Kopie fehlt.
Unnötige Archive, alte Credentials, Produktionsdatenkopien und personenbezogene Daten zuerst entfernen. Inhalte, die ein Abhängigkeitsmanager erneut abrufen kann, müssen nicht in ein dauerhaftes Image.
Verzeichnisse nach Projekt oder Aufgabenbatch aufteilen. Build-Cache, Modelldateien, Ausgabe-Artefakte und Protokolle getrennt speichern, um Rechte, Speicherquoten und Bereinigungsregeln festzulegen.
Quellcode in die Versionsverwaltung, Build-Artefakte in den Artefaktprozess sowie Modelle und Daten an einen vom Team freigegebenen Speicherort übernehmen. Regelmäßig prüfen, ob die Kopie tatsächlich wiederhergestellt werden kann.
Erforderliche Artefakte, Konfigurationen und bereinigte Protokolle exportieren und Dateivollständigkeit sowie Empfangsort prüfen. Nicht mehr benötigte Daten erst danach im eigenen Teamprozess bereinigen.
Signaturdateien, Repository-Tokens, Dienstschlüssel und Umgebungsvariablen müssen aus dem eigenen Secret-Management-Prozess des Teams kommen. Build-Skripte verwenden nur Variablennamen oder kontrollierte Dateipfade und speichern keine echten Werte.
Echte Werte speichern, Leseberechtigte begrenzen und Änderungen sowie Widerrufe protokollieren.
Nur während der Aufgabenausführung die für die aktuelle Pipeline minimal erforderlichen Secrets lesen.
Aufgabenphase, Exit-Status und Artefaktort ausgeben, aber keine Secret-Inhalte zurückgeben.
Vor der Bereitstellung einer MLX-Inferenzschnittstelle Listener-Bereich, Zugriffskontrolle, Parallelitätsgrenzen, Protokollinhalte und Modellabhängigkeiten getrennt prüfen. Zunächst in einem eingeschränkten Netzwerk testen, dann den Zugriff erweitern.
Modellformat, Ladevorgang, Unified-Memory-Nutzung und grundlegende Antwort prüfen.
Nur für Testaufrufer öffnen und Authentifizierungsfehler, Zeitüberschreitungen sowie fehlerhafte Anfragen prüfen.
Anfragen schrittweise erhöhen und Speicher, Latenz, Fehlerrate sowie Modellladeprotokolle beobachten.
Endgültigen Listener-Bereich, aufrufende Identität, Protokollstrategie und Abschaltmethode dokumentieren.
| Prüfpunkt | Akzeptables Ergebnis | Signal für Anpassungsbedarf |
|---|---|---|
| Listener-Bereich | Nur an vorgesehene Schnittstellen gebunden, mit klarem Netzwerkzugriffspfad | Standardmäßig an alle Schnittstellen gebunden, ohne nachvollziehbare Aufruferquelle |
| Zugriffskontrolle | Aufruferidentität einzeln widerrufbar; fehlgeschlagene Anfragen geben keine internen Informationen preis | Gemeinsam genutztes dauerhaftes Token oder Tokens in Client und Protokollen |
| Anfrageprotokolle | Notwendige Zeit, Status und Aufgabenkennung werden bereinigt gespeichert | Sensible Prompts, Tokens oder Modelldaten vollständig protokolliert |
| Abhängigkeitsquellen | Modell- und Paketquellen nachvollziehbar, Versionen und Prüfinformationen eindeutig | Laufzeitabhängigkeiten unbekannter Quelle oder Version werden heruntergeladen |
Bei ungewöhnlichen Zugriffen, versehentlich übermittelten Credentials, unbekannten Prozessen oder offengelegten Diensten zunächst nach Teamprozess betroffene Identitäten und Dienste einschränken. Danach Bestellkennung, Zeitachse, Auswirkungsbereich und bereinigte Nachweise zusammenstellen.
Für den externen Support ausschließlich support@vmcache.com. Reichen Sie keine echten Schlüssel im E-Mail-Text oder als Anhang ein.
Bestätigen Sie zunächst Modell, Knoten und Mietdauer und nehmen Sie anschließend Konten, Secrets, Backups und Schnittstellenprüfungen in die eigene Team-Checkliste auf.