Alliance Doc

Allocations and compute scheduling/fr: Difference between revisions

Page Discussion

Allocations and compute scheduling/fr (view source)

Revision as of 12:50, 1 November 2024

8,303 bytes added ,  6 days ago
Updating to match new version of source page
(Created page with "Le renouvellement de l'infrastructure de 2025 permettra de planifier une fraction d'un GPU à l'aide de la technologie GPU multi-instances. Différents travaux, appartenant potentiellement à différents utilisateurs, pourront s'exécuter sur le même GPU en même temps. Selon la terminologie de NVidia, une fraction d'un GPU allouée à un seul travail est appelée une <i>instance GPU</i>, (parfois <i>instance MIG</i>)")
(Updating to match new version of source page)
 
(33 intermediate revisions by 3 users not shown)
Line 30: Line 30:
La performance des GPU a considérablement augmenté ces dernières années et continue sa progression. Par le passé et jusqu'au concours de 2023, nous considérions tous les GPU comme étant équivalents les uns aux autres. Ceci posait des problèmes à la fois dans le processus d'attribution et lors de l'exécution des tâches. Pour contrer ceci, nous avons créé pour l'année 2024 l'unité GPU de référence (UGR) qui permet de classer tous les modèles de GPU en production. Pour la période d'allocation de 2025-2026, nous devrons tenir compte de [[Multi-Instance GPU/fr|la technologie des GPU multi-instances]] qui rend la situation un peu plus complexe.
La performance des GPU a considérablement augmenté ces dernières années et continue sa progression. Par le passé et jusqu'au concours de 2023, nous considérions tous les GPU comme étant équivalents les uns aux autres. Ceci posait des problèmes à la fois dans le processus d'attribution et lors de l'exécution des tâches. Pour contrer ceci, nous avons créé pour l'année 2024 l'unité GPU de référence (UGR) qui permet de classer tous les modèles de GPU en production. Pour la période d'allocation de 2025-2026, nous devrons tenir compte de [[Multi-Instance GPU/fr|la technologie des GPU multi-instances]] qui rend la situation un peu plus complexe.


Parce qu'environ la moitié des tâches utilisent principalement des opérations à virgule flottante simple précision ([https://en.wikipedia.org/wiki/Single-precision_floating-point_format FP32]), que les autres utilisent des opérations à virgule flottante demi-précision ([https://en.wikipedia.org/wiki/Half-precision_floating-point_format FP16, matrices denses]), et que la plupart des utilisateurs sont limités par la quantité de mémoire des GPU, nous classons les modèles de GPU selon les critères d'évaluation avec leur poids correspondant&nbsp;:
Parce qu'environ la moitié des tâches utilisent principalement des opérations à virgule flottante simple précision ([https://en.wikipedia.org/wiki/Single-precision_floating-point_format FP32]), que les autres utilisent des opérations à virgule flottante demi-précision ([https://en.wikipedia.org/wiki/Half-precision_floating-point_format FP16]), et que la plupart des utilisateurs sont limités par la quantité de mémoire des GPU, nous classons les modèles de GPU selon les critères d'évaluation avec leur poids correspondant&nbsp;:


{| class="wikitable" style="margin: auto;"
{| class="wikitable" style="margin: auto;"
|-
|-
! scope="col"| Critère d'évaluation
! scope="col"| Critère d'évaluation
! scope="col"| Poids <br> (UGR)
! scope="col"| Poids
|-
|-
! scope="row"| Score FP32
! scope="row"| score FP32 <small>(matrices denses sur les cœurs GPU réguliers)</small>
| 40% * 4 = 1.6
| 40%
|-
|-
! scope="row"| Score FP16
! scope="row"| FP16 score <small>(matrices denses sur les <em>[https://www.techspot.com/article/2049-what-are-tensor-cores/| cœurs Tensor]</em>)</small>
| 40% * 4 = 1.6
| 40%
|-
|-
! scope="row"| Score mémoire GPU
! scope="row"| GPU memory score
| 20% * 4 = 0.8
| 20%
|}
|}


Line 94: Line 94:
|}
|}


Le [[infrastructure renewal/fr|renouvellement de l'infrastructure ]] de 2025 permettra de planifier une fraction d'un GPU à l'aide de la technologie GPU multi-instances. Différents travaux, appartenant potentiellement à différents utilisateurs, pourront s'exécuter sur le même GPU en même temps. Selon la terminologie de NVidia, une fraction d'un GPU allouée à un seul travail est appelée une <i>instance GPU</i>, (parfois <i>instance MIG</i>)   
Le [[infrastructure renewal/fr|renouvellement de l'infrastructure ]] en 2025 permettra de planifier une fraction d'un GPU à l'aide de la [[Multi-Instance GPU/fr|technologie GPU multi-instances]]. Différents travaux, appartenant potentiellement à différents utilisateurs, pourront s'exécuter sur le même GPU en même temps. Selon la terminologie de NVidia, une fraction d'un GPU allouée à un seul travail est appelée une <i>instance GPU</i>, (parfois <i>instance MIG</i>).  


The following table lists the GPU models and instances that can be selected in the CCDB form for RAC 2025. RGU values for GPU instances have been estimated from whole-GPU performance numbers and the fraction of the GPU which comprises the instance.
Le tableau suivant montre les modèles de GPU ou instances que vous pouvez sélectionner sur le formulaire dans CCDB pour votre demande d'allocation pour la période 2025-2026. Les valeurs UGR des instances sont estimées à partir des valeurs de performance d'un GPU entier et de la fraction du GPU qu'occupe l'instance.


{| class="wikitable" style="margin: auto; text-align: center;
{| class="wikitable" style="margin: auto; text-align: center;
|+ GPU models and instances available for RAC 2025
|+ Modèles et instances disponibles pour la période d'allocations 2025-2026
|-
|-
! Model or instance !! Fraction of GPU !! RGU
! Modèle / Instance !! Fraction du GPU !! UGR
|-
|-
! scope="row"| A100-40gb
! scope="row"| A100-40gb
| Whole GPU ⇒ 100% || 4.0
| GPU entier ⇒ 100% || 4.0
|-
|-
! scope="row"| A100-3g.20gb
! scope="row"| A100-3g.20gb
Line 113: Line 113:
|-
|-
! scope="row"| H100-80gb  
! scope="row"| H100-80gb  
| Whole GPU ⇒ 100% || 12.2
| GPU entier ⇒ 100% || 12.2
|-
|-
! scope="row"| H100-1g.10gb  
! scope="row"| H100-1g.10gb  
Line 128: Line 128:
|}
|}


Note: a GPU instance of profile <b>1g</b> is worth 1/7 of a A100 or H100 GPU. The case of <b>3g</b> takes into consideration the extra amount of memory per <b>g</b>.
Remarque : Une instance GPU ayant le profil <b>1g</b> vaut un septième (1/7) d'un GPU A100 ou H100. Le profil <b>3g</b> tient compte de la quantité de mémoire additionnelle par <b>g</b>.


==Choisir des modèles de GPU pour votre projet==
==Choisir les modèles de GPU pour votre projet==


Les scores relatifs du précédent tableau devraient vous aider à sélectionner les modèles les plus convenables. Les exemples suivants présentent des cas extrêmes.
Les scores relatifs du précédent tableau devraient vous aider à sélectionner les modèles les plus convenables. Les exemples suivants présentent des cas extrêmes.
Line 137: Line 137:
* Si vos applications font surtout des opérations FP16 (ce qui est le cas en intelligence artificielle et avec les opérations à précision mixte ou utilisant [https://en.wikipedia.org/wiki/Bfloat16_floating-point_format d'autres formats à virgule flottante]), l'utilisation d'un A100-40gb sera calculée comme utilisant quatre fois les ressources d'un P100-12gb, mais pourra faire ~30 fois plus de calculs dans la même période, ce qui vous permettrait d'exécuter ~7.5 fois plus de calculs.
* Si vos applications font surtout des opérations FP16 (ce qui est le cas en intelligence artificielle et avec les opérations à précision mixte ou utilisant [https://en.wikipedia.org/wiki/Bfloat16_floating-point_format d'autres formats à virgule flottante]), l'utilisation d'un A100-40gb sera calculée comme utilisant quatre fois les ressources d'un P100-12gb, mais pourra faire ~30 fois plus de calculs dans la même période, ce qui vous permettrait d'exécuter ~7.5 fois plus de calculs.


<div class="mw-translate-fuzzy">
==Constance des allocations en UGR==
==À compter du concours de 2024==
</div>


<div class="mw-translate-fuzzy">
* Dans le cadre du concours pour l'allocation de ressources, toute demande de GPU doit spécifier le modèle de GPU préféré pour le projet. Ensuite, dans le formulaire CCDB, la quantité d'unités GPU de référence (UGR) sera automatiquement calculée à partir de la quantité demandée de GPU-année par année de projet.
* Pour le concours d'allocation de ressources de 2024, votre demande de GPU doit indiquer le modèle de GPU que vous préférez. Le nombre d’UGR sera automatiquement calculé sur la base des GPU-années par année du projet et enregistré dans le formulaire électronique dans CCDB.
** Par exemple, si vous sélectionnez la ressource <i>narval-gpu</i> et demandez 13 GPU-année du modèle A100-40gb, la quantité correspondante en UGR serait de 13 * 4,0 = 52. Le comité d’allocation des ressources attribuerait alors jusqu'à 52 UGR en fonction du score de la proposition. Si votre allocation doit être déplacée vers une autre grappe, le comité attribuera des GPU-année à cette autre ressource tout en conservant la même quantité en UGR.
** Par exemple, si vous sélectionnez la ressource <i>narval-gpu</i> et demandez 13 GPU-années du modèle A100-40gb, le nombre d’UGR sera 13&nbsp;*&nbsp;4.0&nbsp;=&nbsp;52. Le comité d’administration du concours vous allouerait un maximum de 52&nbsp;UGR, dépendant de la note attribuée à votre demande. Dans le cas où votre allocation serait déplacée sur Cedar, le comité vous allouerait jusqu’à 20&nbsp;GPU-années, puisque chaque GPU V100-32gb vaut 2.6&nbsp;UGR (et 52&nbsp;/&nbsp;2.6&nbsp;=&nbsp;20).
</div>


=Effet détaillé de l'utilisation des ressources sur la priorité=
=Effet détaillé de l'utilisation des ressources sur la priorité=
Line 204: Line 200:
|-
|-
! scope="col"| Grappe
! scope="col"| Grappe
! scope="col"| Modèle GPU
! scope="col"| Modèle ou instance
! scope="col"| UGR par GPU
! scope="col"| UGR par GPU
! scope="col"| Bundle par UGR
! scope="col"| Bundle par UGR
! scope="col"| Bundle par GPU
! scope="col"| Bundle par GPU
! scope="col"| Ratios physiques
|-
|-
! scope="row"| [[Béluga#Caractéristiques_des_nœuds|Béluga]]
! scope="row"| [[Béluga#Caractéristiques_des_nœuds|Béluga]]*
| V100-16gb
| V100-16gb
| 2.2
| 2.2
| 4.5 cœurs / 21 Go
| 4.5 cœurs, 21 Go
| 10 cœurs / 46.5 Go
| 10 cœurs, 46.5 Go
| 10 cœurs / 46.5 Go
|-
|-
! rowspan="3"| [[Cedar/fr#Caractéristiques_des_nœuds|Cedar]]
! rowspan="3"| [[Cedar/fr#Caractéristiques_des_nœuds|Cedar]]*
| P100-12gb
| P100-12gb
| 1.0
| 1.0
| rowspan="3"|3.1 cœurs / 25 Go
| rowspan="3"|3.1 cœurs, 25 Go
| 3.1 cœurs / 25 Go
| 3.1 cœurs, 25 Go
| 6 cœurs / 31.2 Go
|-
|-
| P100-16gb
| P100-16gb
| 1.1
| 1.1
| 3.4 cœurs / 27 Go
| 3.4 cœurs, 27 Go
| 6 cœurs / 62.5 Go
|-
|-
| V100-32gb
| V100-32gb
| 2.6
| 2.6
| 8.0 cœurs / 65 Go
| 8.0 cœurs, 65 Go
| 8 cœurs / 46.5 Go
|-
! rowspan="5"| Fir
| <b>H100-80gb</b>
| <b>12.2</b>
| rowspan="5"| 0.98 cœur, 20.5 Go
| <b>12 cœurs, 250 Go</b>
|-
| H100-1g.10gb
| 1.7
| 1.6 cœurs, 34.8 Go
|-
| H100-2g.20gb
| 3.5
| 3.4 cœurs, 71.7 Go
|-
| H100-3g.40gb
| 6.1
| 6 cœurs, 125 Go
|-
| H100-4g.40gb
| 7.0
| 6.9 cœurs, 143 Go
|-
|-
! rowspan="5"| [[Graham/fr#Caractéristiques_des_nœuds|Graham]]
! rowspan="5"| [[Graham/fr#Caractéristiques_des_nœuds|Graham]]*
| P100-12gb
| P100-12gb
| 1.0
| 1.0
| rowspan="5"| 9.7 cœurs / 43 Go
| rowspan="5"| 9.7 cœurs, 43 Go
| 9.7 cœurs / 43 Go
| 9.7 cœurs, 43 Go
| 16 cœurs / 62 Go
|-
|-
| T4-16gb
| T4-16gb
| 1.3
| 1.3
| 12.6 cœurs / 56 Go
| 12.6 cœurs, 56 Go
| {4, 11} cœurs / 46.8 Go
|-
|-
| V100-16gb*
| V100-16gb
| 2.2
| 2.2
| 21.3 cœurs / 95 Go
| 21.3 cœurs, 95 Go
| 3.5 cœurs / 23.4 Go
|-
|-
| V100-32gb*
| V100-32gb
| 2.6
| 2.6
| 25.2 cœurs / 112 Go
| 25.2 cœurs, 112 Go
| 5 cœurs / 47.1 Go
|-
|-
| A100-80gb*
| A100-80gb
| 4.8
| 4.8
| 46.6 cœurs / 206 Go
| 46.6 cœurs, 206 Go
| {8, 16} c. / {62, 248} Go
|-
! rowspan="5"| Graham II
| <b>H100-80gb</b>
| <b>12.2</b>
| rowspan="5"| 1.3 cœurs, 15.3 Go
| <b>16 cœurs, 187 Go</b>
|-
| H100-1g.10gb
| 1.7
| 2.2 cœurs, 26 Go
|-
| H100-2g.20gb
| 3.5
| 4.5 cœurs, 53.5 Go
|-
| H100-3g.40gb
| 6.1
| 8 cœurs, 93.5 Go
|-
| H100-4g.40gb
| 7.0
| 9.1 cœurs, 107 Go
|-
! rowspan="3"| [[Narval#Caractéristiques_des_nœuds|Narval]]
| <b>A100-40gb</b>
| <b>4.0</b>
| rowspan="3"| 3.0 cœurs, 31 Go
| <b>12 cœurs, 124.5 Go</b>
|-
| A100-3g.20gb
| 2.0
| 6 cœurs, 62.3 Go
|-
| A100-4g.20gb
| 2.3
| 6.9 cœurs, 71.5 Go
|-
! rowspan="5"| Rorqual
| <b>H100-80gb</b>
| <b>12.2</b>
| rowspan="5"| 1.3 cœurs, 10.2 Go
| <b>16 cœurs, 124.5 Go</b>
|-
| H100-1g.10gb
| 1.7
| 2.2 cœurs, 17.4 Go
|-
| H100-2g.20gb
| 3.5
| 4.5 cœurs, 35.8 Go
|-
| H100-3g.40gb
| 6.1
| 8 cœurs, 62.3 Go
|-
|-
! scope="row"| [[Narval#Caractéristiques_des_nœuds|Narval]]
| H100-4g.40gb
| A100-40gb
| 7.0
| 4.0
| 9.1 cœurs, 71.5 Go
| 3.0 cœurs / 31 Go
| 12 cœurs / 124.5 Go
| 12 cœurs / 124.5 Go
|}
|}


(*) Ces modèles sont offerts par un petit nombre de nœuds GPU fournis par contribution. Ils peuvent être utilisés, mais ne sont pas alloués par la voie du concours annuel d'allocation des ressources.
(*) Toutes les ressources GPU de cette grappe ne sont pas allouées par la voie du concours annuel d'allocation des ressources.


<b>Remarque :</b> Si l'ordonnanceur établit la priorité sur la base de l'utilisation calculée avec les bundles, une demande de plusieurs GPU sur un même nœud doit aussi tenir compte des ratios physiques.
<b>Remarque :</b> Si l'ordonnanceur établit la priorité sur la base de l'utilisation calculée avec les bundles, une demande de plusieurs GPU sur un même nœud doit aussi tenir compte des ratios physiques.


=Viewing resource usage in the portal=
[[File:Slurm portal land edit.png|thumb|alt=usage portal landing view|Usage portal landing view. (Click on the image for a larger version.)]]
[https://portal.alliancecan.ca/slurm portal.alliancecan.ca/slurm] provides an interface for exploring time-series data about jobs on our national clusters. The page contains a figure that can display several usage metrics. When you first log in to the site, the figure will display CPU days on the Cedar cluster for you across all project accounts that you have access to. If you have no usage on Cedar, the figure will contain the text <i>No Data or usage too small to have a meaningful plot</i>. The data appearing in the figure can be modified by control panels along the left margin of the page. There are three panels:
* Select system and dates
* Parameters
* SLURM account
<br clear=all>
==Displaying a specified account==
[[File:Slurm portal account usage edit.png|thumb|alt=usage display of a specified account|Usage display of a specified account]]
If you have access to more than one [[Running_jobs#Accounts_and_projects|Slurm account]], the <i>Select user’s account</i> pull-down menu of the <i>SLURM account</i> panel lets you select which project account will be displayed in the figure window. If the <i>Select user’s account</i> is left empty the figure will display all of your usage across accounts on the specified cluster during the selected time period. The <i>Select user’s account</i> pull-down menu is populated by a list of all the accounts that have job records on the selected cluster during the selected time interval. Other accounts that you have access to but do not have usage on the selected cluster during the selected time interval will also appear in the pull-down menu but will be grayed out and not selectable as they would not generate a figure. When you select a single project account the figure is updated and the summary panel titled <i>Allocation Information</i> is populated with details of the project account. The height of each bar in the histogram figure corresponds to the metric for that day (e.g. CPU-equivalent days) across all users in the account on the system. The top eight users are displayed in unique colors stacked on top of the summed metric for all other users in gray. You can navigate the figure using [https://plotly.com/graphing-libraries/ Plotly] tools (zoom, pan, etc.) whose icons appear at the top-right when you hover your mouse over the figure window. You can also use the legend on the right-hand side to manipulate the figure. Single-clicking an item will toggle the item's presence in the figure, and double-clicking the item will toggle off or on all the other items in the figure.
<br clear=all>
==Displaying the allocation target and queued resources==
[[File:Slurm portal account usage queued edit.png|thumb|alt=Allocation target and queued resources displayed on usage figure|Allocation target and queued resources displayed on usage figure]]
When a single account has been selected for display, the <i>Allocation target</i> is shown as a horizontal red line. It can be turned off or on with the <i>Display allocation target by default</i> item in the <i>Parameters</i> panel, or by clicking on <i>Allocation target</i> in the legend to the right of the figure.
You can toggle the display of the <i>Queued jobs</i> metric, which presents a sum of all resources in pending jobs at each time point, by clicking on the words <i>Queued jobs</i> in the legend to the right of the figure.
<br clear=all>
==Selecting a specific cluster and time interval==
[[File:Slurm portal select sys date.png|thumb|alt=Select a specific cluster and time interval|Select a specific cluster and time interval]]
The figure shows your usage for a single cluster over a specified time interval. The <i>System</i> pull-down menu contains entries for each of the currently active national clusters that use Slurm as a scheduler. You can use the "Start date (incl.)" and "End date (incl.)" fields in the "Select system and dates" panel to change the time interval displayed in the figure. It will include all jobs on the specified cluster that were in a running (R) or pending (PD) state during the time interval, including both the start and end date. Selecting an end date in the future will display the <i>projection</i> of currently running and pending jobs for their requested duration into the future.
<br clear=all>
==Displaying usage over an extended time period into the future==
[[File:Slurm portal account use duration edit.png|thumb|alt=Displaying usage over and extended period into the future|Displaying usage over and extended period into the future]]
If you select an end time after the present time, the figure will have a transparent red area overlaid on the future time labelled <i>Projection</i>. In this projection period, each job is assumed to run to the time limit requested for it. For queued resources, the projection supposes that each pending job starts at the beginning of the projected time (that is, right now) and runs until its requested time limit. This is not intended to be a forecast of actual future events!
<br clear=all>
==Metrics, summation, and running jobs==
[[File:Slurm portal parameter panel.png|thumb|alt=Parameters of the usage series histogram|Parameters of the usage series histogram]]
Use the <i>Metric</i> pull-down control in the <i>Parameters</i> panel to select from the following metrics: CPU, CPU-equivalent, RGU, RGU-equivalent, Memory, Billing, gpu, and all specific GPU models available on the selected cluster.
The <i>Summation</i> pull-down allows you to switch between the daily <i>Total</i> and <i>Running total</i>. If you select <i>Total</i>, each bar of the histogram represents the total usage in that one day.  If you select "Running total", each bar represents the sum of that day's usage and all previous days back to the beginning of the time interval. If the <i>Allocation Target</i> is displayed, it is similarly adjusted to show the running total of the target usage. See the next section for more.
If you set <i>Include Running jobs</i> to <i>No</i>, the figure shows only data from records of completed jobs. If you set it to <i>Yes</i> it includes data from running jobs too.
<br clear=all>
==Display of the running total of account usage==
[[File:Slurm portal account use cumulative edit.png|thumb|alt=Display of the  running total of account usage|Display of the  running total of account usage]]
When displaying the running total of the usage for a single account along with the <i>Allocation target</i> the usage histogram displays how an account deviates from its target share over the period displayed. The values in this view are the cumulative sum across days from "total" summation view for both the usage and allocation target. When an account is submitting jobs that request more than the account’s target share, it is expected that the usage cumulative sum will oscillate above and below the target share cumulative sum if the scheduler is managing fair share properly. Because the scheduler uses a decay period for the impact of past usage, a good interval to use to inspect the scheduler’s performance in maintaining the account's fair share is to display the past 30 days.
<br clear=all>
<div class="mw-translate-fuzzy">
=Visionner les données d’utilisation par le groupe=
=Visionner les données d’utilisation par le groupe=
</div>


[[File:Select view group usage fr edit.png|thumb|Onglet <i>Mon compte</i>, option <i>Utilisation par le groupe</i>]]
[[File:Select view group usage fr edit.png|thumb|Onglet <i>Mon compte</i>, option <i>Utilisation par le groupe</i>]]
Line 303: Line 410:
<br clear=all>
<br clear=all>


<div class="mw-translate-fuzzy">
==Utilisation des GPU en unités GPU de référence (UGR)==
==Utilisation des GPU en unités GPU de référence (UGR)==
[[File:rgu_fr.png|thumb|Sommaire de l'utilisation des GPU et le détail en unités GPU de référence (UGR) par modèle.]]
[[File:rgu_fr.png|thumb|Sommaire de l'utilisation des GPU et le détail en unités GPU de référence (UGR) par modèle.]]
Pour chaque projet (RAPI) ayant une utilisation de GPU, le détail d'utilisation par modèle de GPU est donné en GPU-années et en UGR-années dans une table située au bas de la page.
Pour chaque projet (RAPI) ayant une utilisation de GPU, le détail d'utilisation par modèle de GPU est donné en GPU-années et en UGR-années dans une table située au bas de la page.
<br clear=all>
<br clear=all>
</div>


==Utilisation par utilisateur==
==Utilisation par utilisateur==
FuzzyBot
Bots
38,760

edits

Retrieved from "https://docs.alliancecan.ca/wiki/Special:MobileDiff/160468...163832"