vCPUs

Compute Engine weist Ihren virtuellen Maschinen (VMs) oder Bare-Metal-Instanzen vCPUs zu, wenn Sie sie erstellen. In diesem Dokument wird erläutert, wie vCPUs physischer Hardware zugeordnet werden, um die Leistung zu optimieren, Kosten zu verwalten und Softwarelizenzierungsanforderungen zu erfüllen.

vCPUs

Eine virtuelle CPU (vCPU) stellt eine Einheit der CPU-Leistung dar, die Ihrer Compute-Instanz zugewiesen ist. Je nach zugrunde liegender Prozessorarchitektur wird eine vCPU entweder auf einem einzelnen Hardware-Ausführungsthread oder auf einem gesamten dedizierten physischen CPU-Kern ausgeführt.

vCPUs sind Teil einer CPU-Plattform. Eine CPU-Plattform ist eine CPU-basierte Konfiguration, die Folgendes umfasst:

  • CPU-Prozessortyp
  • Befehlssätze (z. B. AVX2 und AVX-512)
  • Cache-Größen
  • Taktgeschwindigkeiten
  • NUMA-Aufteilungen
  • Suchzeiten für den Arbeitsspeicherzugriff
  • On-Chip-Beschleuniger

vCPUs einer Compute-Instanz zuweisen

Zum Erstellen einer VM- oder Bare-Metal-Instanz (zusammen als Compute-Instanz bezeichnet) verwenden Sie einen Maschinentyp. Der Maschinentyp bestimmt die Ressourcen, die Compute Engine der Instanz zuweist. Der Maschinentyp c4-standard-4 erstellt beispielsweise eine VM mit 4 vCPUs und 16 GB Arbeitsspeicher.

Damit Sie den richtigen Maschinentyp für Ihre Arbeitslast auswählen können, gruppiert Compute Engine Maschinentypen in Maschinenfamilien und Maschinenserien.

  • Maschinenfamilie: Eine ausgewählte Reihe von Prozessor- und Hardwarekonfigurationen, die für bestimmte Arbeitslasten optimiert sind, z. B. Für allgemeine Zwecke, Beschleunigeroptimiert oder Speicheroptimiert.

  • Maschinenserie: Eine bestimmte Kombination aus CPU-Prozessor, Hardware und Netzwerkfunktionen innerhalb einer Maschinenfamilie. Jede Serie konzentriert sich auf einen anderen Aspekt der Rechenleistung oder Leistung. Die E-Serie bietet beispielsweise effiziente VMs zu geringen Kosten, während die C-Serie eine bessere und konsistentere Leistung als die E-Serie bietet.

    • Eine Maschinenserie kann mehrere Generationen haben, z. B. C3 und C4. Eine höhere Generation oder Seriennummer weist auf neuere zugrunde liegende CPU-Prozessoren oder Technologien hin. Die M4-Serie, die auf Intel Xeon-Prozessoren der 5. Generation (auch als Emerald Rapids bezeichnet) ausgeführt wird, ist beispielsweise eine neuere Generation als die M3-Maschinenserie, die auf Intel Xeon-Prozessoren der 3. Generation (auch als Ice Lake bezeichnet) ausgeführt wird.
    • Die zugrunde liegende Architektur für eine Maschinenreihe und einen Maschinentyp wird durch einen nachgestellten Buchstaben im Namen der Maschinenreihe angegeben. Die C-Maschinenserie der 4. Generation ist beispielsweise als C4 (Intel), C4D (AMD), C4A (Arm) oder C4N (netzwerkoptimiert) verfügbar.

Physische Kernzuordnung und gleichzeitiges Multithreading

Bei den meisten x86-Prozessoren unterstützt jeder physische CPU-Kern zwei Hardware-Ausführungsthreads. Intel Xeon-Prozessoren verwenden Intel Hyper-Threading und AMD EPYC-Prozessoren verwenden simultanes Multithreading (SMT). Bei diesen Prozessoren implementiert Compute Engine jede vCPU als einzelnen Hardware-Thread, der auf einem physischen Kern ausgeführt wird. Zwei vCPUs teilen sich also einen einzelnen physischen CPU-Kern (Verhältnis von vCPUs zu physischen Kernen von 2:1). Eine VM mit 4 vCPUs verwendet beispielsweise 2 physische CPU-Kerne mit SMT.

Bei bestimmten Maschinenserien und Prozessorarchitekturen verwendet Compute Engine kein SMT. Stattdessen wird jede vCPU direkt einem dedizierten physischen CPU-Kern zugeordnet (Verhältnis von vCPUs zu physischen Kernen von 1:1):

  • Arm-Prozessoren: Auf Arm64-basierten Maschinenserien wie N4A, C4A oder A4X verwendet die Hardwarearchitektur Single-Thread-Kerne. Jede vCPU entspricht einem vollständigen physischen Kern.
  • Computing-optimierte Maschinenserien: Die Maschinenserien H4D und H3 unterstützen kein SMT. Jede vCPU stellt einen gesamten physischen CPU-Kern dar, was eine hohe Single-Thread-Leistung ermöglicht und Ressourcenkonflikte zwischen Threads verhindert.
  • Tau-Maschinenreihe: Für die Tau T2A-Maschinenreihe (mit Ampere Altra-Prozessoren) und die Tau T2D-Maschinenreihe (mit AMD EPYC Milan-Prozessoren der 3. Generation) deaktiviert Compute Engine SMT standardmäßig. Diese Compute-Instanztypen haben immer eine vCPU pro Kern.
  • Bare-Metal-Instanzen: Bei Bare-Metal-Instanzen entspricht eine vCPU einer CPU. Die Anzahl der für die Instanz verfügbaren vCPUs entspricht der Anzahl der Hardware-Threads auf dem Hostserver. Sie können die Threads pro Kern nicht manuell anpassen oder festlegen.

Um bestimmte Anforderungen an Arbeitslasten oder Softwarelizenzen zu erfüllen, können Sie anpassen, wie vCPUs für Ihr Gastbetriebssystem angezeigt werden. Weitere Informationen finden Sie unter Anzahl der sichtbaren CPU-Kerne anpassen. Eine Liste der Maschinenserien und Architekturen, die SMT nicht verwenden, finden Sie unter Anzahl der Threads pro Kern festlegen.

Dedizierte vCPUs im Vergleich zu vCPUs mit gemeinsam genutztem Kern

Wenn Sie einen Maschinentyp auswählen, werden Ihre vCPUs entweder einem CPU-Hardware-Thread zugeordnet oder verwenden ein Ressourcenmodell mit gemeinsam genutztem Kern:

  • Vollständige vCPUs: Standardmaschinentypen, Maschinentypen mit großem Speicher, Maschinentypen mit hoher CPU-Leistung und benutzerdefinierte Maschinentypen weisen jeder vCPU einen Hardware-Ausführungsthread oder einen physischen Kern zu.
    • Bei den Maschinenserien N4, N4A, N4D und E2 der Maschinenfamilie für allgemeine Zwecke sorgt das System zur dynamischen Ressourcenverwaltung (DRM) dafür, dass jede aktive vCPU von einem verfügbaren Hardware-Ausführungsthread unterstützt wird. Mit der dynamischen Ressourcenverwaltung kann die Compute Engine die verfügbaren physischen CPUs besser nutzen, da die Compute-Instanzen für Server anhand des Ressourcenbedarfs geplant werden. Außerdem wird durch das Planen von vCPU-Threads für physische CPUs die Wartezeit verkürzt. Die Maschinenserien N1, N2 und N2D in der Maschinenfamilie für allgemeine Zwecke verwenden die Standard-Hostplanung.
    • Bei den Maschinenserien C, M, G, Z und A werden vCPU-Ressourcen ausschließlich Ihrer Instanz zugewiesen und teilen sich nie Ausführungszyklen mit anderen Compute-Instanzen.

  • vCPUs mit gemeinsam genutztem Kern: Maschinentypen mit gemeinsam genutztem Kern sind e2-micro, e2-small, e2-medium, f1-micro und g1-small. Diese Maschinentypen teilen sich einen physischen CPU-Kern mithilfe von Kontextwechseln. Anstelle von dedizierten Hardware-Threads nutzen diese VMs mit gemeinsam genutztem Kern einen bestimmten Anteil der physischen Kernzeit:

    • e2-micro erhält 2 vCPUs mit jeweils 12,5 % der CPU-Zeit (insgesamt 25 %).
    • e2-small erhält 2 vCPUs mit jeweils 25 % der CPU-Zeit (insgesamt 50 %).
    • e2-medium erhält 2 vCPUs mit jeweils 50 % der CPU-Zeit (insgesamt 100 %).
    • f1-micro erhält 1 vCPU für bis zu 20 % der CPU-Zeit.
    • g1-small erhält 1 vCPU für bis zu 50 % der CPU-Zeit.

    Im Vergleich zu VMs mit vollständigen vCPUs bieten VMs mit vCPUs mit gemeinsam genutztem Kern eine kostengünstige Option für die Ausführung kleiner, nicht ressourcenintensiver Anwendungen, Mikrodienste oder Entwicklungs- oder Testarbeitslasten, die keinen kontinuierlichen CPU-Spitzendurchsatz erfordern.

vCPU-Leistungsmerkmale

Die Verarbeitungsleistung einer vCPU hängt von ihrer CPU-Plattform, der Taktgeschwindigkeit, der Cache-Hierarchie, der Multithreading-Dynamik und der Ressourcenplanung ab.

CPU-Plattformen und Befehlssätze

Die Compute Engine bietet Compute-Instanzen, die auf mehreren Generationen von Intel-, AMD-, Arm- und benutzerdefinierten Google-Prozessoren ausgeführt werden. Jede CPU-Plattform bietet Verbesserungen der Mikroarchitektur und spezielle Befehlssätze:

  • Advanced Vector Extensions (AVX-512): AVX-512 ist auf Intel-Plattformen (wie Ice Lake, Emerald Rapids und Sapphire Rapids) und AMD EPYC-Plattformen (Genoa und Turin) verfügbar und beschleunigt Vektormathematik, wissenschaftliches Computing und Datenkomprimierung.
  • AMX und VNNI: Diese Erweiterungen beschleunigen Deep-Learning-Inferenz und Matrixvorgänge direkt auf der vCPU.
    • Advanced Matrix Extensions (AMX) ist auf Intel-Prozessoren (Intel Xeon 4. Generation Sapphire Rapids und höher) verfügbar.
    • Vector Neural Network Instructions (VNNI) sind sowohl auf Intel- als auch auf AMD EPYC-Prozessoren (Genoa der 4. Generation und neuer) verfügbar.
  • Arm NEON und SVE: Arm NEON, verfügbar auf der Ampere Altra-CPU-Plattform, und Scalable Vector Extension (SVE), verfügbar auf den Google Axion- und NVIDIA Grace-CPU-Plattformen, bieten skalierbare Vektorausführung für cloudnative Web-Arbeitslasten.

Taktgeschwindigkeit und Turbofrequenz

Eine vCPU führt Anweisungen mit der Basistaktfrequenz des zugrunde liegenden physischen Prozessors aus. Wenn Arbeitslasten zusätzliche Verarbeitungsleistung erfordern und die thermische Reserve dies zulässt, erhöhen Prozessoren die Frequenz automatisch auf eine Turbofrequenz für alle Kerne oder eine Turbofrequenz für einen einzelnen Kern.

Bestimmte Maschinenserien arbeiten mit den höchsten dauerhaften Taktgeschwindigkeiten in Compute Engine. C4, das auf Granite Rapids ausgeführt wird, hat beispielsweise eine Turbofrequenz für alle Kerne von bis zu 3,9 GHz und A3 Mega oder A3 High haben eine Turbofrequenz für alle Kerne von bis zu 3,8 GHz. Wählen Sie vCPUs mit hoher Frequenz für Single-Thread-Anwendungen, elektronische Designautomatisierung (EDA) und Gameserver aus.

Die Frequenzen für die einzelnen von Compute Engine verwendeten CPU-Plattformen finden Sie unter CPU-Plattformen.

Multithreading-Ressourcenfreigabe

Bei Maschinentypen mit aktivem SMT (2 vCPUs pro Kern) teilen sich die beiden Hardwareausführungsthreads die Level-1-Anweisungs- und Datencaches (L1), den Level-2-Cache (L2), die Ausführungseinheiten und die Translation Lookaside Buffer (TLBs) des physischen Kerns.

  • E/A-gebundene und gleichzeitige Arbeitslasten: Bei Webservern, API-Gateways und Datenbankvorgängen mit häufigem Speicherzugriff erhöht SMT den Gesamtdurchsatz der Kerne, indem Anweisungen in einem Thread ausgeführt werden, während der andere Thread auf den Speicherabruf wartet.
  • Rechengebundene Arbeitslasten: Bei Anwendungen, die Gleitkommaeinheiten oder L1-/L2-Caches kontinuierlich auslasten, kann die gemeinsame Nutzung von Ausführungseinheiten durch zwei vCPUs zu Ressourcenkonflikten führen. Wenn es bei Ihrer Arbeitslast zu Konflikten auf SMT-fähigen Compute-Instanzen kommt, sollten Sie SMT deaktivieren, indem Sie die Anzahl der Threads pro Kern auf 1 setzen, oder zu einer Maschinenserie mit dedizierten physischen Kernen (z. B. C4A oder H4D) migrieren.

Verwaltung dynamischer Ressourcen und Leistungsüberwachung

Compute Engine verwendet spezielle Hardware- und Softwareoptimierungen, um eine vorhersehbare vCPU-Latenz aufrechtzuerhalten:

  • Google Titanium-Architektur: Maschinenserien der nächsten Generation (einschließlich N4, N4D, N4A, C3, C3D und C4) verwenden Google Titanium-Offload-Karten, einen benutzerdefinierten CPU-Scheduler und eine leistungsorientierte Live-Migration. Die Verwaltung dynamischer Ressourcen erhält die NUMA-Affinität (Non-Uniform Memory Access) und minimiert Störungen durch andere Nutzer.
  • Dynamische Ressourcenverwaltung für E2: Bei E2-VMs ordnet der Hypervisor virtuelle CPUs und Arbeitsspeicher bei Bedarf dynamisch physischen Ressourcen zu. Diese dynamische Zuordnung erhöht die Kosteneffizienz, da die Nutzung physischer Ressourcen optimiert wird.
  • Performance Monitoring Unit (PMU): Sie können die PMU auf unterstützten Maschinenserien (z. B. C4, M4 und A4X) aktivieren, um auf Low-Level-Hardwarezähler zuzugreifen. Profiling-Tools verwenden PMU-Zähler, um Fehlvorhersagen von Verzweigungen, Cache-Fehler und Anweisungen pro Zyklus (IPC) zu verfolgen.
  • Ops-Agent: Sie können den Ops-Agent auf Ihren Compute-Instanzen installieren, um die CPU-Auslastung zu überwachen und Telemetriedaten auf Systemebene zu erfassen. Der Ops-Agent sendet diese Daten an Google Cloud Observability, damit Sie die vCPU-Leistung analysieren und optimieren können.

Kosten

Berücksichtigen Sie bei der Budgetierung und Planung der Kapazität für Ihre Arbeitslasten, wie Compute Engine vCPUs abrechnet und welche Rabattmodelle verfügbar sind.

Detaillierungsgrad der Ressourcenabrechnung

Bei den meisten Maschinenreihen rechnet Compute Engine vCPUs und Systemspeicher als separate dedizierte Ressourcen ab. Die Abrechnung erfolgt sekundengenau mit einer Mindestnutzungsdauer von einer Minute für jede gestartete Compute-Instanz. Nach der ersten Minute zahlen Sie nur für die genauen Sekunden, die Ihre Instanz ausgeführt wird.

Bei Maschinentypen mit gemeinsam genutztem Kern (z. B. E2 und N1 mit gemeinsam genutztem Kern) bündelt Compute Engine vCPUs und Arbeitsspeicher in einem einzigen kombinierten Stundensatz, anstatt sie als einzelne Ressourcen abzurechnen.

Die vCPU-Abrechnungssätze finden Sie auf der Seite Preise für VM-Instanzen.

Kostenoptimierung und Rabatte

Sie können die vCPU-Abrechnungskosten mit den folgenden Preisoptionen senken:

  • Rabatte für zugesicherte Nutzung (CUDs): Wenn Ihre Arbeitslasten vorhersehbare, stabile vCPU-Anforderungen haben, können Sie Zusicherungen für ein oder drei Jahre erwerben, um Rabatte von bis zu 55 % bis 70 % auf On-Demand-Preise zu erhalten. Compute Engine bietet ressourcenbasierte Rabatte für zugesicherte Nutzung für bestimmte Maschinenreihen in einer Region und ausgabenbasierte flexible Rabatte für zugesicherte Nutzung, die für mehrere Maschinenreihen und Regionen gelten. Sie können Rabatte für zugesicherte Nutzung projektübergreifend in Ihrem Cloud-Rechnungskonto freigeben.
  • Rabatte für kontinuierliche Nutzung: Für infrage kommende Maschinenserien (z. B. N1, N2, N2D, C2, M1 und M2) wendet Compute Engine automatisch Rabatte für kontinuierliche Nutzung an, wenn Ihre vCPUs mehr als 25 % eines Abrechnungsmonats ausgeführt werden. Wenn Sie eine VM-Instanz den ganzen Monat über kontinuierlich ausführen, erhalten Sie je nach Maschinenserie einen Rabatt von bis zu 20 % oder 30 %. Maschinenserien mit niedrigeren On-Demand-Preisen (einschließlich E2, N4, C3, C4, Tau T2A und A3) bieten keine Rabatte für kontinuierliche Nutzung.
  • Spot-VMs: Für fehlertolerante, zustandslose oder Batch-Arbeitslasten bieten Spot-VMs bis zu 60 % bis 91 % Rabatt auf die Standard-On-Demand-vCPU-Preise. Die Compute Engine kann Spot-VMs jederzeit beenden oder zurückfordern, um Kapazitäten freizugeben.
  • Knoten für einzelne Mandanten und vCPU-Overcommit: Wenn Sie VM-Instanzen auf Knoten für einzelne Mandanten ausführen, zahlen Sie für den dedizierten physischen Hostserver und nicht für einzelne vCPUs. Auf Knoten für einzelne Mandanten können Sie CPU-Overcommit (bis zu einem Verhältnis von 2:1) konfigurieren, um mehr vCPUs auf Ihren VM-Instanzen zu planen, als der physische Host Kerne hat. Dadurch werden die Rechenkosten für Entwickler- oder Testumgebungen reduziert.
  • Dynamic Workload Scheduler (DWS): Für KI- oder ML-Arbeitslasten können Sie mit DWS die vCPU-Kosten optimieren und die Ressourcenverfügbarkeit verbessern.
    • Flex-Start-VMs: Verwenden Sie diese VMs für die kostengünstige und flexible Planung von Arbeitslasten, die bis zu 7 Tage lang ausgeführt werden.
    • Anfragen für vorausschauende Reservierungen im Kalendermodus: Reservieren Sie Ressourcen für bis zu 90 Tage zu einem bestimmten zukünftigen Datum und einer bestimmten Uhrzeit.
  • Empfehlungen zur Größenanpassung: Compute Engine analysiert historische vCPU-Auslastungsmesswerte und bietet automatisierte Empfehlungen für Maschinentypen und inaktive Compute-Instanzen. Wenn Sie diese Empfehlungen anwenden, können Sie die Größe überdimensionierter vCPUs anpassen oder inaktive Instanzen beenden.

Verfügbarkeit von Maschinenreihen

In der folgenden Tabelle sind vCPU-Architekturmodelle, Multithreading-Verhältnisse und maximale vCPU-Anzahlen für Compute Engine-Maschinenserien aufgeführt. Die maximale Anzahl von vCPUs entspricht dem größten Maschinentyp in jeder Serie, einschließlich Bare-Metal-Instanzen.

Maschinenfamilie Maschinenserie Prozessorarchitektur Verhältnis von vCPUs zu Kernen Max. vCPUs Option „mit gemeinsam genutztem Kern“
Für allgemeine Zwecke E2 Intel Xeon / AMD EPYC 2 vCPUs : 1 Kern (SMT) 32 vCPUs Ja (e2-micro, e2-small, e2-medium)
Für allgemeine Zwecke N1 Mehrere Generationen von Intel Xeon-Prozessoren 2 vCPUs : 1 Kern (SMT) 96 vCPUs Ja (f1-micro, g1-small)
Für allgemeine Zwecke N2 Intel Xeon (Cascade Lake / Ice Lake) 2 vCPUs : 1 Kern (SMT) 128 vCPUs Nein
Für allgemeine Zwecke N2D AMD EPYC (Rome / Milan) 2 vCPUs : 1 Kern (SMT) 224 vCPUs Nein
Für allgemeine Zwecke N4 Intel Xeon der 5. Generation (Emerald Rapids) 2 vCPUs : 1 Kern (SMT) 80 vCPUs Nein
Für allgemeine Zwecke N4D AMD EPYC der 5. Generation (Turin) 2 vCPUs : 1 Kern (SMT) 96 vCPUs Nein
Für allgemeine Zwecke N4A Google Axion (Arm64) 1 vCPU : 1 Kern (kein SMT) 64 vCPUs Nein
Für allgemeine Zwecke C3 Intel Xeon der 4. Generation (Sapphire Rapids) 2 vCPUs : 1 Kern (SMT) 176 vCPUs Nein
Für allgemeine Zwecke C3D AMD EPYC der 4. Generation (Genoa) 2 vCPUs : 1 Kern (SMT) 360 vCPUs Nein
Für allgemeine Zwecke C4 Intel Xeon der 5. Generation (Emerald Rapids) und Intel Xeon der 6. Generation (Granite Rapids) 2 vCPUs : 1 Kern (SMT) 288 vCPUs Nein
Für allgemeine Zwecke C4A Google Axion (Arm64) 1 vCPU : 1 Kern (kein SMT) 96 vCPUs Nein
Für allgemeine Zwecke C4D AMD EPYC der 5. Generation (Turin) 2 vCPUs : 1 Kern (SMT) 384 vCPUs Nein
Für allgemeine Zwecke Tau T2A Ampere Altra (Arm64) 1 vCPU : 1 Kern (kein SMT) 48 vCPUs Nein
Für allgemeine Zwecke Tau T2D AMD EPYC (Milan) der 3. Generation 1 vCPU : 1 Kern (SMT deaktiviert) 60 vCPUs Nein
Computing-optimiert C2 Intel Xeon (Cascade Lake) 2 vCPUs : 1 Kern (SMT) 60 vCPUs Nein
Computing-optimiert C2D AMD EPYC (Milan) 2 vCPUs : 1 Kern (SMT) 112 vCPUs Nein
Computing-optimiert H3 Intel Xeon der 4. Generation (Sapphire Rapids) 1 vCPU : 1 Kern (kein SMT) 88 vCPUs Nein
Computing-optimiert H4D AMD EPYC der 5. Generation (Turin) 1 vCPU : 1 Kern (kein SMT) 192 vCPUs Nein
Netzwerkoptimiert C4N Intel Xeon der 5. Generation (Emerald Rapids) 2 vCPUs : 1 Kern (SMT) 192 vCPUs Nein
Speicheroptimiert X4 Intel Xeon der 4. Generation (Sapphire Rapids) 2 vCPUs : 1 Kern (SMT) 1.920 vCPUs Nein
Speicheroptimiert M1 Intel Xeon (Skylake und Broadwell) 2 vCPUs : 1 Kern (SMT) 160 vCPUs Nein
Speicheroptimiert M2 Intel Xeon der 2. Generation (Cascade Lake) 2 vCPUs : 1 Kern (SMT) 416 vCPUs Nein
Speicheroptimiert M3 Intel Xeon der 3. Generation (Ice Lake) 2 vCPUs : 1 Kern (SMT) 128 vCPUs Nein
Speicheroptimiert M4/M4N Intel Xeon der 5. Generation (Emerald Rapids) 2 vCPUs : 1 Kern (SMT) 224 vCPUs Nein
Speicheroptimiert Z3 Intel Xeon der 4. Generation (Sapphire Rapids) 2 vCPUs : 1 Kern (SMT) 192 vCPUs Nein
Speicheroptimiert Z4D AMD EPYC der 5. Generation (Turin) 2 vCPUs : 1 Kern (SMT) 288 vCPUs Nein
Speicheroptimiert Z4M Intel Xeon der 5. Generation (Emerald Rapids) 1 vCPU : 1 Kern (kein SMT) 192 vCPUs Nein
Beschleunigungsoptimiert A4X Max NVIDIA Grace 1 vCPU : 1 Kern (kein SMT) 144 vCPUs Nein
Beschleunigungsoptimiert A4X NVIDIA Grace 1 vCPU : 1 Kern (kein SMT) 140 vCPUs Nein
Beschleunigungsoptimiert A4 Intel Xeon der 5. Generation (Emerald Rapids) in Kombination mit NVIDIA-GPUs 2 vCPUs : 1 Kern (SMT) 224 vCPUs Nein
Beschleunigungsoptimiert A3 Intel Xeon (Emerald Rapids und Sapphire Rapids) in Kombination mit NVIDIA-GPUs 2 vCPUs : 1 Kern (SMT) 224 vCPUs Nein
Beschleunigungsoptimiert A2 Intel Xeon der 2. Generation (Cascade Lake) in Kombination mit NVIDIA-GPUs 2 vCPUs : 1 Kern (SMT) 96 vCPUs Nein
Beschleunigungsoptimiert G4 AMD EPYC der 5. Generation (Turin) in Kombination mit NVIDIA-GPUs 2 vCPUs : 1 Kern (SMT) 384 vCPUs Nein
Beschleunigungsoptimiert G2 Intel Xeon der 2. Generation (Cascade Lake) in Kombination mit NVIDIA-GPUs 2 vCPUs : 1 Kern (SMT) 96 vCPUs Nein

Detaillierte Spezifikationen zum Arbeitsspeicher pro vCPU, zur Netzwerkbandbreite und zur Unterstützung lokaler Laufwerke für alle Serien finden Sie im Leitfaden zu Maschinenressourcen.

Nächste Schritte