Was ist verteilte Beschleunigung für Cloud-Speicher? (Vorschau)

Der verteilte Beschleuniger für Cloud-Speicher (DACS) ist ein verteilter Read-Through-Cache, der das Laden von Modellen aus Azure Blob Storage für KI-Inferenz auf dem Azure Kubernetes Service (AKS) beschleunigt. Es verwendet lokale NVMe-Festplatten über Cache-Knoten, um häufig gelesene Daten nahe an der GPU-Rechenleistung zu halten. DACS können auch das Laden von Datensätzen für Trainingslasten beschleunigen, die dieselben Daten wiederholt lesen. Azure Blob Storage bleibt die langlebige und autoritative Quelle für Modelldateien und Datensätze.

Sie aktivieren und verwalten DACS über Azure Container Storage, das die von DACS verwaltete Erweiterung installiert und deren Lebenszyklus auf AKS verwaltet. DACS ist kein persistentes Volume, keine StorageClass oder kein Ersatz für Azure Blob Storage. Informationen zum Erstellen persistenter Kubernetes-Volumes finden Sie unter Was ist Azure Container Storage?

Wann sollte man einen verteilten Beschleuniger für Cloud-Speicher verwenden

DACS ist für leseintensive KI-Inferenz-Workloads konzipiert, die wiederholt dieselben Modelldaten aus Azure Blob Storage laden. Betrachten Sie DACS, wenn Ihr Workload eine oder mehrere dieser Eigenschaften aufweist:

• Inferenzkapseln warten auf große Modelldateien, bevor sie Anfragen verarbeiten können.
• Das Hinzufügen von GPU-Knoten führt zu wiederholten Downloads von Modelldaten.
• Pod-Neustarts, das Ersetzen von Knoten oder rollende Upgrades rufen wiederholt dieselben Modelldaten ab.
• Multiple Inference Workloads nutzen erneut einen Arbeitssatz von Modelldateien, die in Azure Blob Storage gespeichert sind.
• Der AKS-Cluster hat einen Linux-Node-Pool mit lokalen NVMe-Festplatten, die man für Cache-Server reservieren kann.

Für das Training sollten DACS berücksichtigt werden, wenn Worker Datensätze über Epochen oder Jobs hinweg wiederverwenden. Die Vorteile des Caches hängen von der Wiederverwendung der Daten, der Größe des Arbeitssets und davon, ob die Lesezugriffe auf einen kalten oder warmen Cache stoßen.

DACS unterstützt Cluster mit bis zu 100 Knoten. Es bietet keinen dauerhaften Speicher für Trainingsausgaben oder Checkpoints. KV-Cache, Container-Image-Cache, allgemeiner Zugriff auf geteilte Dateien und nicht-Azure Blob-Origins sind nicht Teil dieser Vorschau.

Wie der verteilte Beschleuniger für Cloud-Speicher funktioniert

DACS fügt eine cluster-lokale NVMe-Cache-Schicht hinzu, auf die über eine unterstützte Client-Integration zugegriffen wird. Der Client kann Azure Blob Storage direkt bei Cache-Misses oder beim Fallback lesen.

Lesepfad

1. Eine Anwendung fordert einen Modell-Datenbereich über eine unterstützte DACS-Integration an.
2. Der Client entdeckt die Cache-Server und bestimmt, welcher Server den angeforderten Chunk besitzt.
3. Bei einem Cache-Treffer liest der Client den Chunk vom NVMe des besitzenden Cache-Servers.
4. Bei einem Cache-Miss liest der Client den Chunk aus Azure Blob Storage und füllt den Cache asynchron aus. Der Lesevorgang kann enden, bevor die Befüllung abgeschlossen ist, sodass auch ein sofortiger wiederholter Lesevorgang ebenfalls fehlschlagen kann.
5. Wenn der Cache nicht verfügbar ist, greift der Client auf Azure Blob Storage zurück.

Modelldaten werden in Chunks unterteilt und über Cache-Server verteilt. Ein Consistent-Hash-Ring ordnet Datenblöcke Servern zu, ohne von einem zentralen Datenpfad abhängig zu sein. Cache-Server können Daten über Ethernet oder InfiniBand übertragen, abhängig von der gewählten Größe der Azure-Virtual-Machine (VM) und der Clustertopologie.

Verwaltete Bereitstellung

Aktivieren Sie DACS über Azure Container Storage, indem Sie die Azure CLI mit dem Wert distributedAccelerator verwenden. Dieser Schritt installiert die separate distributedaccelerator verwaltete Erweiterung. Die Erweiterung stellt den DACS-Controller und das NVMe-Voraussetzungs-DaemonSet in kube-system bereit und registriert die Definition der benutzerdefinierten Ressource „Cache“. Die Voraussetzungen erkennen, formatieren und mounten lokale NVMe-Laufwerke auf beschrifteten Cache-Knoten. Verwenden Sie Festplatten, die dem Cache zugeordnet sind; installieren Sie kein separates Prerequisite-Chart. Die Erweiterung erstellt keine Cache-Server-Pods automatisch.

Nachdem überprüft wurde, dass die verwalteten NVMe-Voraussetzungen auf jedem beschrifteten Cache-Knoten bereit sind, erstellen Sie eine Cache-Ressource, um Serveranzahl, Kapazität, Ressourcenlimits und berechtigte Knoten zu definieren. Der Controller stimmt die Cache-Server-Pods ab und veröffentlicht Discovery-Informationen für die Clienten. Der Controller verwaltet Ressourcen; er ist kein Proxy für Lesezugriffe auf Anwendungsdaten. Siehe den Quickstart für Installation und Cache-Provisionierung.

Die wichtigsten Vorteile

• Schnelleres Laden von warmen Modellen: Häufig lesen Sie Modellabschnitte aus lokalen oder Peer-NVMe, anstatt sie wiederholt aus Azure Blob Storage abzurufen.
• Schnellere Skalierung und Wiederherstellung: Neue oder Ersatzknoten können bereits im Cluster zwischengespeicherte Modelldaten wiederverwenden.
• Reduzierte wiederholte Blob-Reads: Behalten Sie das aktive Modell im Cache und verwenden Sie Prefetch vor geplanten Skalierungsereignissen.
• Bereichsbasiertes Caching: Cachen Sie nur die Chunks, die die angeforderten Byte-Bereiche abdecken, anstatt jede Modelldatei vollständig zu materialisieren.
• Flexible Anwendungsintegration: Verwenden Sie BlobFuse2, den nativen Python-Client, oder Run:ai Model Streamer, um die Arbeitslast mit dem Cache zu verbinden.
• Sichere Ausweichlösung: Behalte Azure Blob Storage als maßgebliche Datenquelle bei, wenn Daten nicht zwischengespeichert sind oder der Cache nicht verfügbar ist.

Client-Integrationen

Der Umfang der Anwendungsänderung hängt von der Integration ab:

Für Dateisystem-Einrichtung und gemessene Standardspeicherergebnisse siehe Verteilten Beschleuniger für Cloudspeicher mit BlobFuse2 verwenden. Für die Python-Client-Einrichtung und Beispiele siehe Verwenden des verteilten Beschleunigers für Cloudspeicher mit dem Python-Client.

Der direkte Hugging Face Origin-Zugriff wird nicht unterstützt. Speichern Sie die Modelldaten in Azure Blob Storage, bevor Sie den verteilten Beschleuniger für Cloud-Speicher verwenden.

Cache-Semantik

Verstehen Sie diese Verhaltensweisen, bevor Sie Distributed Accelerator für Cloud-Speicher einsetzen:

• Haltbarkeit: Zwischengespeicherte Daten sind flüchtig und werden nicht aus Langlebigkeit repliziert. Der Verlust eines Cache-Knotens kann die auf diesem Knoten gespeicherten Chunks entfernen; fehlende Daten werden erneut aus Azure Blob Storage abgerufen.
• Wahrheitsquelle: Azure Blob Storage bleibt maßgeblich. Verwende DACS nicht als einzige Kopie von Modelldateien oder Datensätzen. Bevorzuge unveränderliche, versionierte Blob-Pfade für Modell-Upgrades.
• Verdrängung: Der Cache verdrängt Daten, wenn die Kapazitätsschwellenwerte erreicht sind. Verdrängte Daten werden bei Bedarf erneut abgerufen.
• Rückfall: Fehlende Discovery-Konfiguration oder ein nicht verfügbarer Cache kann dazu führen, dass der Client direkt aus Azure Blob Storage liest. Überprüfen Sie die Treffer des Client-Caches und die Erhöhung des erfolgreichen Serveranforderungszählers, anstatt eine erfolgreiche Blob-Lesung als Beweis für Caching zu behandeln. Siehe Den DACS-Anfragepfad überprüfen.
• Identität: Workloads verwenden Microsoft Entra-Identitäten oder eine Shared Access Signature (SAS), um auf Azure Blob Storage zuzugreifen. Nutze die für den Workload erforderliche Rolle mit den geringsten Privilegien.
• Netzwerk: Der Cache-Verkehr bleibt im AKS-Netzwerk. Der Zugriff auf den Azure Blob-Endpunkt muss für Cache-Misses und Fallbacks erlaubt sein.
• Vertrauensgrenze: Verwenden Sie DACS innerhalb eines vertrauenswürdigen Clusters. Der Cache isoliert nicht gegenseitig nicht vertrauenswürdige Mandanten.

Open-Source-Projekt

DACS ist ein Open-Source-Projekt, das in Zusammenarbeit zwischen Azure AI Platform und Azure Storage entwickelt wurde. Das Projekt stellt seine Cache-Implementierung für Inspektion, Experimente und Community-Beiträge zur Verfügung, um wiederholte Datenlesungen zu reduzieren, ohne den dauerhaften Speicher zu ersetzen.

Das Azure DACS-Repository enthält den Cache-Server, einen nativen C/C++-Client, Python-Adapter, einen Rust-Wrapper, Kubernetes-Charts und -Controller sowie Bereitstellungsbeispiele. Konsultieren Sie das Repository README für Open-Source-Kompatibilität und Konfigurationsratschläge und nutzen Sie dessen Beitragsleitlinien, um reproduzierbare Probleme, Workload-Messungen und Verbesserungen zu teilen.

Das Open-Source-Projekt und die von Azure verwaltete Vorschau haben unterschiedliche Bereitstellungs- und Unterstützungsumfange. Für das Managed-AKS-Erlebnis folgen Sie dem Azure-Quickstart; Repository-Deployment-Optionen sind nicht automatisch unterstützte Funktionen der verwalteten Bereitstellung.

Vorschauunterstützung und Einschränkungen

Die folgende Tabelle fasst den Umfang der anfänglichen Vorschau zusammen.

Wann sollte man eine andere Speicheroption verwenden

Verwenden Sie eine weitere Azure-Speicheroption, wenn Ihre Arbeitslast Funktionen außerhalb des DACS-Bereichs benötigt:

• Für Kubernetes-persistente Volumes auf lokalem NVMe siehe Azure Container Storage mit lokalem NVMe verwenden.
• Für langlebige Blockvolumina siehe Azure Container Storage mit Elastic SAN verwenden.
• Für ein verwaltetes paralleles Dateisystem siehe Was ist Azure Managed Lustre?.
• Für direkten Objektzugriff ohne verteilten Cache verwenden Sie eine Client-Bibliothek von Azure Blob Storage.

Nächste Schritte

• Starten Sie mit Distributed Accelerator für Cloud Storage auf AKS.
• Verwenden Sie verteilte Beschleunigung für Cloud-Speicher mit BlobFuse2.
• Verwende Distributed Accelerator für Cloud-Speicher mit dem Python-Client.
• Verwalten Sie den verteilten Accelerator für Cloud-Speicher.
• Überwachen Sie den verteilten Accelerator für Cloud-Speicher.
• Fehlerbehebung eines verteilten Beschleunigers für Cloud-Speicher.