Comprendre les vCPU

Compute Engine attribue des vCPU à vos instances de machines virtuelles (VM) ou Bare Metal lorsque vous les créez. Ce document explique comment les processeurs virtuels sont mappés au matériel physique pour vous aider à optimiser les performances, à gérer les coûts et à respecter les exigences de licence logicielle.

Comprendre les vCPU

Un processeur virtuel (vCPU) représente une unité de puissance de processeur (CPU) attribuée à votre instance de calcul. Selon l'architecture du processeur sous-jacent, un vCPU est programmé pour s'exécuter sur un seul thread d'exécution matériel ou sur un cœur de processeur physique dédié entier.

Les processeurs virtuels font partie d'une plate-forme de processeur. Une plate-forme de processeur est une configuration basée sur un processeur qui inclut les éléments suivants :

  • Type de processeur
  • Ensembles d'instructions (tels que AVX2 et AVX-512)
  • Tailles de cache
  • Vitesses d'horloge
  • Divisions NUMA
  • Temps de recherche d'accès à la mémoire
  • Accélérateurs sur puce

Allouer des vCPU à une instance de calcul

Pour créer une VM ou une instance Bare Metal (collectivement appelées instance de calcul), vous utilisez un type de machine. Le type de machine détermine les ressources que Compute Engine alloue à l'instance. Par exemple, le type de machine c4-standard-4 crée une VM avec quatre vCPU et 16 Go de mémoire.

Pour vous aider à choisir le type de machine adapté à votre charge de travail, Compute Engine regroupe les types de machines en familles et séries de machines.

  • Famille de machines : ensemble organisé de configurations de processeur et de matériel, optimisé pour des charges de travail spécifiques, par exemple, Usage général, Optimisé pour les accélérateurs ou À mémoire optimisée.
  • Série de machines : combinaison spécifique de processeur, de matériel et de capacités réseau au sein d'une famille de machines. Chaque série se concentre sur un aspect différent de la puissance de calcul ou des performances. Par exemple, la série E propose des VM efficaces à faible coût, tandis que la série C offre des performances meilleures et plus cohérentes que la série E.

    • Une série de machines peut comporter plusieurs générations, comme C3 et C4. Un numéro de génération ou de série plus élevé indique des processeurs ou des technologies de processeur sous-jacents plus récents. Par exemple, la série M4, qui fonctionne sur des processeurs Intel Xeon de 5e génération (également appelés Emerald Rapids), est plus récente que la série de machines M3, qui fonctionne sur des processeurs Intel Xeon de 3e génération (également appelés Ice Lake).
    • L'architecture sous-jacente d'une série et d'un type de machine est indiquée par une lettre à la fin du nom de la série de machines. Par exemple, la série de machines C de 4e génération est disponible en tant que C4 (Intel), C4D (AMD), C4A (Arm) ou C4N (optimisée pour le réseau).

Mappage des cœurs physiques et multithreading simultané

Sur la plupart des processeurs x86, chaque cœur de processeur physique accepte deux threads d'exécution matériels. Les processeurs Intel Xeon utilisent la technologie Intel Hyper-Threading et les processeurs AMD EPYC utilisent le multithreading simultané (SMT). Pour ces processeurs, Compute Engine implémente chaque vCPU en tant que thread matériel unique s'exécutant sur un cœur physique. Ainsi, deux vCPU partagent un seul cœur de processeur physique (ratio de 2:1 entre les vCPU et les cœurs physiques). Par exemple, une VM avec quatre processeurs virtuels utilise deux cœurs de processeur physiques avec SMT.

Sur certaines séries de machines et architectures de processeur, Compute Engine n'utilise pas le SMT. Au lieu de cela, chaque processeur virtuel est directement mappé à un cœur de processeur physique dédié (un ratio de 1:1 entre les processeurs virtuels et les cœurs physiques) :

  • Processeurs Arm : sur les séries de machines basées sur Arm64, telles que N4A, C4A ou A4X, l'architecture matérielle utilise des cœurs monothread. Chaque processeur virtuel représente un cœur physique complet.
  • Séries de machines optimisées pour le calcul : les séries de machines H4D et H3 ne sont pas compatibles avec le SMT. Chaque processeur virtuel représente un cœur de processeur physique entier, ce qui offre des performances élevées pour un seul thread et élimine les conflits de ressources entre les threads.
  • Série de machines Tau : pour les séries de machines Tau T2A (alimentées par des processeurs Ampere Altra) et Tau T2D (alimentées par des processeurs AMD EPYC Milan de 3e génération), Compute Engine désactive le SMT par défaut. Ces types d'instances de calcul disposent toujours d'un vCPU par cœur.
  • Instances Bare Metal : pour les instances Bare Metal, un vCPU équivaut à un CPU. Le nombre de processeurs virtuels disponibles pour l'instance est équivalent au nombre de threads matériels sur le serveur hôte. Vous ne pouvez pas ajuster ni définir manuellement le nombre de threads par cœur.

Pour répondre à des exigences spécifiques de charge de travail ou de licence logicielle, vous pouvez personnaliser la façon dont les processeurs virtuels apparaissent dans votre système d'exploitation invité. Pour en savoir plus, consultez Personnaliser le nombre de cœurs de CPU visibles. Pour obtenir la liste des séries de machines et des architectures qui n'utilisent pas le SMT, consultez Définir le nombre de threads par cœur.

Processeurs virtuels dédiés ou à cœur partagé

Lorsque vous choisissez un type de machine, vos processeurs virtuels sont mappés à un thread matériel de processeur ou utilisent un modèle de ressource à cœur partagé :

  • Processeurs virtuels complets : les types de machines standards, à haute capacité de mémoire, à haute capacité de processeur et personnalisés allouent un thread d'exécution matériel ou un cœur physique pour chaque processeur virtuel.
    • Pour les séries de machines N4, N4A, N4D et E2 de la famille de machines à usage général, le système de gestion dynamique des ressources (DRM) garantit que chaque processeur virtuel actif est soutenu par un thread d'exécution matériel disponible. La gestion dynamique des ressources permet à Compute Engine de mieux utiliser les processeurs physiques disponibles en planifiant les instances de calcul sur les serveurs en fonction des besoins en ressources et en planifiant les threads des vCPU sur les processeurs physiques de manière à réduire le temps d'attente. Les séries de machines N1, N2 et N2D de la famille de machines à usage général utilisent la programmation d'hôte standard.
    • Pour les séries de machines C, M, G, Z et A, les ressources de vCPU sont exclusivement attribuées à votre instance et ne partagent jamais de cycles d'exécution avec d'autres instances de calcul.
  • vCPU à cœur partagé : les types de machines à cœur partagé sont e2-micro, e2-small, e2-medium, f1-micro et g1-small. Ces types de machines partagent un cœur de processeur physique à l'aide du changement de contexte. Au lieu de threads matériels dédiés, ces VM à cœur partagé exploitent une fraction spécifique du temps d'un cœur physique :

    • e2-micro gère deux processeurs virtuels, chacun pouvant atteindre 12,5 % du temps CPU (soit un total de 25 %).
    • e2-small gère deux vCPU, chacun pouvant atteindre 25 % du temps CPU (50 % au total).
    • e2-medium gère deux vCPU, chacun pouvant atteindre 50 % du temps CPU (100 % au total).
    • f1-micro gère un seul vCPU pendant une durée pouvant atteindre 20 % du temps CPU.
    • g1-small gère un seul vCPU pour une durée pouvant atteindre 50 % du temps CPU.

    Par rapport aux VM avec des processeurs virtuels complets, les VM avec des processeurs virtuels à cœur partagé constituent une option économique pour exécuter de petites applications, des microservices ou des charges de travail de développement ou de test qui ne nécessitent pas un débit de processeur maximal continu.

Caractéristiques de performances des vCPU

Les performances de traitement d'un vCPU dépendent de sa plate-forme de processeur, de sa vitesse d'horloge, de sa hiérarchie de cache, de sa dynamique de multithreading et de la planification des ressources.

Plates-formes de processeur et ensembles d'instructions

Compute Engine propose des instances de calcul qui s'exécutent sur plusieurs générations de processeurs Intel, AMD, Arm et Google personnalisés. Chaque plate-forme de processeur introduit des améliorations de microarchitecture et des ensembles d'instructions spécialisés :

  • Advanced Vector Extensions (AVX-512) : disponible sur les plates-formes Intel (comme Ice Lake, Emerald Rapids et Sapphire Rapids) et les plates-formes AMD EPYC (Genoa et Turin), AVX-512 accélère les calculs mathématiques vectoriels, le calcul scientifique et la compression de données.
  • AMX et VNNI : ces extensions accélèrent l'inférence de deep learning et les opérations matricielles directement sur le vCPU.
    • Advanced Matrix Extensions (AMX) est disponible sur les processeurs Intel (Intel Xeon 4e génération Sapphire Rapids et versions ultérieures).
    • Les instructions de réseau de neurones vectoriels (VNNI) sont disponibles sur les processeurs Intel et AMD EPYC (Genoa 4e génération et versions ultérieures).
  • Arm NEON et SVE : Arm NEON, disponible sur la plate-forme de processeur Ampere Altra, et Scalable Vector Extension (SVE), disponible sur les plates-formes de processeur Google Axion et NVIDIA Grace, fournissent une exécution vectorielle évolutive pour les charges de travail Web cloud natives.

Vitesse d'horloge et fréquence turbo

Un vCPU exécute les instructions à la fréquence d'horloge de base de son processeur physique sous-jacent. Lorsque les charges de travail nécessitent une puissance de traitement supplémentaire et que la marge thermique le permet, les processeurs augmentent automatiquement la fréquence jusqu'à une fréquence turbo tout cœur ou une fréquence turbo monocœur.

Certaines séries de machines fonctionnent aux vitesses d'horloge soutenues les plus élevées dans Compute Engine. Par exemple, les machines C4 exécutées sur Granite Rapids ont une fréquence turbo tout cœur pouvant atteindre 3,9 GHz, et les machines A3 Mega ou A3 High ont une fréquence turbo tout cœur pouvant atteindre 3,8 GHz. Choisissez des vCPU haute fréquence pour les applications à thread unique, l'automatisation de la conception électronique (EDA) et les serveurs de jeux.

Pour connaître les fréquences de chaque plate-forme de processeur utilisée par Compute Engine, consultez Plates-formes de processeur.

Partage de ressources multithread

Sur les types de machines avec SMT actif (2 vCPU par cœur), les deux threads d'exécution matériels partagent les caches d'instructions et de données de niveau 1 (L1), le cache de niveau 2 (L2), les unités d'exécution et les TLB (Translation Lookaside Buffer) du cœur physique.

  • Charges de travail simultanées et liées aux E/S : pour les serveurs Web, les passerelles d'API et les opérations de base de données avec un accès fréquent à la mémoire, le SMT augmente le débit global des cœurs en exécutant des instructions sur un thread pendant que l'autre thread attend la récupération de la mémoire.
  • Charges de travail liées au calcul : pour les applications qui saturent en permanence les unités à virgule flottante ou les caches L1/L2, le partage des unités d'exécution entre deux processeurs virtuels peut entraîner des conflits de ressources. Si votre charge de travail subit des conflits sur des instances de calcul compatibles avec le SMT, envisagez de désactiver le SMT en définissant le nombre de threads par cœur sur 1 ou de migrer vers une série de machines avec des cœurs physiques dédiés (comme C4A ou H4D).

Gestion dynamique des ressources et surveillance des performances

Compute Engine utilise des optimisations matérielles et logicielles spécialisées pour maintenir une latence de vCPU prévisible :

  • Architecture Google Titanium : les séries de machines de nouvelle génération (y compris N4, N4D, N4A, C3, C3D et C4) utilisent des cartes de déchargement Google Titanium, un planificateur de processeur personnalisé et une migration à chaud tenant compte des performances. La gestion dynamique des ressources préserve l'affinité NUMA (Non-Uniform Memory Access) et minimise les interférences des voisins bruyants.
  • Gestion dynamique des ressources pour E2 : pour les VM E2, l'hyperviseur mappe de manière dynamique le processeur virtuel et la mémoire avec les ressources physiques à la demande. Ce mappage dynamique améliore la rentabilité en optimisant l'utilisation des ressources physiques.
  • Unité de surveillance des performances (PMU) : vous pouvez activer la PMU sur les séries de machines compatibles (telles que C4, M4 et A4X) pour accéder aux compteurs matériels de bas niveau. Les outils de profilage utilisent des compteurs PMU pour suivre les erreurs de prédiction de branche, les échecs de cache et les instructions par cycle (IPC).
  • Agent Ops : vous pouvez installer l'agent Ops sur vos instances de calcul pour surveiller l'utilisation du processeur et collecter des données de télémétrie au niveau du système. L'agent Ops envoie ces données à Google Cloud Observability pour vous aider à analyser et à optimiser les performances des processeurs virtuels.

Remarques sur les tarifs

Lorsque vous budgétisez et planifiez la capacité de vos charges de travail, tenez compte de la manière dont Compute Engine facture les processeurs virtuels et des modèles de remise disponibles.

Précision de la facturation des ressources

Pour la plupart des séries de machines, Compute Engine facture les processeurs virtuels et la mémoire système en tant que ressources dédiées distinctes. Vous payez les instances à la seconde, avec une durée de facturation minimale d'une minute pour chaque instance de calcul que vous démarrez. Après la première minute, vous ne payez que pour les secondes exactes pendant lesquelles votre instance reste en cours d'exécution.

Pour les types de machines à cœur partagé (tels que les types E2 et N1 à cœur partagé), Compute Engine regroupe les processeurs virtuels et la mémoire dans un tarif horaire combiné unique, plutôt que de les facturer en tant que ressources individuelles.

Vous pouvez consulter les tarifs de facturation des processeurs virtuels sur la page Tarifs des instances de VM.

Optimisation des coûts et remises

Vous pouvez réduire les coûts de facturation des processeurs virtuels en utilisant les options de tarification suivantes :

  • Remises sur engagement d'utilisation : si vos charges de travail ont des besoins en vCPU prévisibles et stables, vous pouvez souscrire des engagements d'un ou trois ans pour bénéficier de remises allant de 55 % à 70 % sur les tarifs à la demande. Compute Engine propose des remises sur engagement d'utilisation basées sur les ressources pour des séries de machines spécifiques dans une région, ainsi que des remises sur engagement d'utilisation flexibles basées sur les dépenses qui s'appliquent à plusieurs séries de machines et régions. Vous pouvez partager des remises sur engagement d'utilisation entre les projets de votre compte de facturation Cloud.
  • Remises pour usage soutenu (SUD) : pour les séries de machines éligibles (telles que N1, N2, N2D, C2, M1 et M2), Compute Engine applique automatiquement des remises pour usage soutenu lorsque vos vCPU s'exécutent pendant plus de 25 % d'un mois de facturation. L'exécution d'une instance de VM en continu pendant tout le mois permet de bénéficier d'une remise allant jusqu'à 20 % ou 30 %, selon la série de machines. Les séries de machines dont les tarifs à la demande sont réduits (y compris E2, N4, C3, C4, Tau T2A et A3) ne proposent pas de remises automatiques proportionnelles à une utilisation soutenue.
  • VM Spot : pour les charges de travail tolérantes aux pannes, sans état ou par lots, les VM Spot offrent jusqu'à 60 % à 91 % de réduction sur les prix des processeurs virtuels standards à la demande. Compute Engine peut arrêter ou récupérer des VM Spot à tout moment pour récupérer de la capacité.
  • Nœuds à locataire unique et sursollicitation de processeurs virtuels : lorsque vous exécutez des instances de VM sur des nœuds à locataire unique, vous payez pour le serveur hôte physique dédié plutôt que pour les processeurs virtuels individuels. Sur les nœuds à locataire unique, vous pouvez configurer la sursollicitation des processeurs (jusqu'à un ratio de 2:1) pour planifier plus de processeurs virtuels sur vos instances de VM que l'hôte physique n'a de cœurs, ce qui réduit les coûts de calcul pour les environnements de développement ou de test.
  • Dynamic Workload Scheduler (DWS) : pour les charges de travail d'IA ou de ML, vous pouvez optimiser les coûts des processeurs virtuels et améliorer la disponibilité des ressources à l'aide de DWS.
    • VM à démarrage flexible : à utiliser pour une planification économique et flexible des charges de travail qui s'exécutent pendant sept jours maximum.
    • Demandes de réservations futures en mode Agenda : permet de réserver des ressources pour une durée maximale de 90 jours à une date et une heure spécifiques.
  • Recommandations de redimensionnement : Compute Engine analyse l'historique des métriques d'utilisation des processeurs virtuels et fournit des recommandations automatisées de types de machines et d'instances de calcul inactives. L'application de ces recommandations vous aide à redimensionner les processeurs virtuels surprovisionnés ou à arrêter les instances inactives.

Disponibilité des séries de machines

Le tableau suivant met en correspondance les modèles d'architecture de vCPU, les ratios de multithreading et le nombre maximal de vCPU dans les séries de machines Compute Engine. Le nombre maximal de processeurs virtuels reflète le plus grand type de machine de chaque série, y compris les instances Bare Metal.

Famille de machines Série de machines Architecture du processeur Ratio vCPU/cœurs Nombre maximal de vCPU Option à cœur partagé
Usage général E2 Intel Xeon/AMD EPYC 2 vCPU : 1 cœur (SMT) 32 vCPU Oui (e2-micro, e2-small, e2-medium)
Usage général N1 Plusieurs générations de processeurs Intel Xeon 2 vCPU : 1 cœur (SMT) 96 vCPU Oui (f1-micro, g1-small)
Usage général N2 Intel Xeon (Cascade Lake/Ice Lake) 2 vCPU : 1 cœur (SMT) 128 vCPU Non
Usage général N2D AMD EPYC (Rome / Milan) 2 vCPU : 1 cœur (SMT) 224 vCPU Non
Usage général N4 Intel Xeon de 5e génération (Emerald Rapids) 2 vCPU : 1 cœur (SMT) 80 processeurs virtuels Non
Usage général N4D AMD EPYC de 5e génération (Turin) 2 vCPU : 1 cœur (SMT) 96 vCPU Non
Usage général N4A Google Axion (Arm64) 1 vCPU : 1 cœur (sans SMT) 64 vCPU Non
Usage général C3 Intel Xeon de 4e génération (Sapphire Rapids) 2 vCPU : 1 cœur (SMT) 176 vCPU Non
Usage général C3D AMD EPYC 4e génération (Genoa) 2 vCPU : 1 cœur (SMT) 360 vCPU Non
Usage général C4 Intel Xeon de 5e génération (Emerald Rapids) et Intel Xeon de 6e génération (Granite Rapids) 2 vCPU : 1 cœur (SMT) 288 vCPU Non
Usage général C4A Google Axion (Arm64) 1 vCPU : 1 cœur (sans SMT) 96 vCPU Non
Usage général C4D AMD EPYC de 5e génération (Turin) 2 vCPU : 1 cœur (SMT) 384 vCPU Non
Usage général Tau T2A Ampere Altra (Arm64) 1 vCPU : 1 cœur (sans SMT) 48 processeurs virtuels Non
Usage général Tau T2D AMD EPYC 3e génération (Milan) 1 vCPU : 1 cœur (SMT désactivé) 60 processeurs virtuels Non
Optimisé pour le calcul C2 Intel Xeon (Cascade Lake) 2 vCPU : 1 cœur (SMT) 60 processeurs virtuels Non
Optimisé pour le calcul C2D AMD EPYC (Milan) 2 vCPU : 1 cœur (SMT) 112 vCPU Non
Optimisé pour le calcul H3 Intel Xeon de 4e génération (Sapphire Rapids) 1 vCPU : 1 cœur (sans SMT) 88 vCPU Non
Optimisé pour le calcul H4D AMD EPYC de 5e génération (Turin) 1 vCPU : 1 cœur (sans SMT) 192 vCPU Non
Optimisé pour le réseau C4N Intel Xeon de 5e génération (Emerald Rapids) 2 vCPU : 1 cœur (SMT) 192 vCPU Non
Mémoire optimisée X4 Intel Xeon de 4e génération (Sapphire Rapids) 2 vCPU : 1 cœur (SMT) 1 920 vCPU Non
Mémoire optimisée M1 Intel Xeon (Skylake et Broadwell) 2 vCPU : 1 cœur (SMT) 160 vCPU Non
Mémoire optimisée M2 Intel Xeon 2e génération (Cascade Lake) 2 vCPU : 1 cœur (SMT) 416 vCPU Non
Mémoire optimisée M3 Intel Xeon de 3e génération (Ice Lake) 2 vCPU : 1 cœur (SMT) 128 vCPU Non
Mémoire optimisée M4/M4N Intel Xeon de 5e génération (Emerald Rapids) 2 vCPU : 1 cœur (SMT) 224 vCPU Non
Optimisé pour le stockage Z3 Intel Xeon de 4e génération (Sapphire Rapids) 2 vCPU : 1 cœur (SMT) 192 vCPU Non
Optimisées pour le stockage Z4D AMD EPYC de 5e génération (Turin) 2 vCPU : 1 cœur (SMT) 288 vCPU Non
Optimisées pour le stockage Z4M Intel Xeon de 5e génération (Emerald Rapids) 1 vCPU : 1 cœur (sans SMT) 192 vCPU Non
Optimisé pour les accélérateurs A4X Max NVIDIA Grace 1 vCPU : 1 cœur (sans SMT) 144 vCPU Non
Optimisé pour les accélérateurs A4X NVIDIA Grace 1 vCPU : 1 cœur (sans SMT) 140 vCPU Non
Optimisé pour les accélérateurs A4 Intel Xeon de 5e génération (Emerald Rapids) associé à des GPU NVIDIA 2 vCPU : 1 cœur (SMT) 224 vCPU Non
Optimisé pour les accélérateurs A3 Intel Xeon (Emerald Rapids et Sapphire Rapids) associé à des GPU NVIDIA 2 vCPU : 1 cœur (SMT) 224 vCPU Non
Optimisé pour les accélérateurs A2 Processeurs Intel Xeon de 2e génération (Cascade Lake) associés à des GPU NVIDIA 2 vCPU : 1 cœur (SMT) 96 vCPU Non
Optimisé pour les accélérateurs G4 AMD EPYC de 5e génération (Turin) associé à des GPU NVIDIA 2 vCPU : 1 cœur (SMT) 384 vCPU Non
Optimisé pour les accélérateurs G2 Processeurs Intel Xeon de 2e génération (Cascade Lake) associés à des GPU NVIDIA 2 vCPU : 1 cœur (SMT) 96 vCPU Non

Pour obtenir des spécifications détaillées sur la mémoire par processeur virtuel, la bande passante réseau et la compatibilité avec les disques locaux pour toutes les séries, consultez le guide des ressources de machines.

Étapes suivantes