CPU, GPU et points de terminaison gérés

Leçon 10
40 min
Module 4 : Choisir l'infrastructure et mesurer

Leçon 10 sur 15 · Déployer des modèles d'IA pour de vrais utilisateursCPU, GPU et points de terminaison gérés

Aperçu du cours

1. Définir le contrat d'inférence

2. Choisir un mode de service

3. Créer le service de prédiction

4. Choisir l'infrastructure et mesurer

5. Mettre en production, surveiller et rétablir

6. Études de cas

Ce que vous saurez faire

Décidez où exécuter le modèle d’escalade. Choisissez un CPU ou un GPU, puis un endroit : une plateforme de conteneurs, un point de terminaison géré ou une tâche planifiée. Basez votre choix sur des mesures. Notez la décision pour que l’équipe puisse la vérifier plus tard.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 40 minutes

Ce que vous devez savoir

Le travail au démarrage, le travail par requête et la mémoire d’un processus, vus dans Charger et initialiser : une copie par processus.
Le service et son en-tête Server-Timing, vus dans Connecter l’API : routes.py.
Les modes de service, vus dans Inférence par lots et Inférence en ligne.
Ce qu’une plateforme de conteneurs facture, la réduction à zéro et le quota gratuit, vus dans Connaître les coûts : ce qui peut entraîner des frais du cours L’essentiel de Docker et du nuage pour les développeurs en IA.

Ce qu’il vous faut sur votre ordinateur

Le projet ~/projects/escalation-service à la fin du module 3, avec son .venv. S’il manque ou ne fonctionne plus, copiez l’instantané end-of-m03, comme dans Utiliser un instantané.
Aucun compte infonuagique. Les prix viennent de l’Azure Retail Prices API : région canadacentral, dollars US, paiement à l’utilisation, Linux. Les prix changent : vérifiez les prix actuels avant de choisir.

Testé avec Python 3.14.6 et Docker Desktop (Docker Engine 29.6.1) sur macOS, avec une puce Apple. Les étapes pour Windows et Linux ne sont pas testées.

Une cuisine pour un seul plat

Personne ne loue une cuisine de restaurant avec vingt cuisiniers pour faire une seule rôtie. La taille de la cuisine dépend du plat et du nombre de clients. Une grande cuisine coûte de l’argent chaque heure, même quand personne ne commande.

C’est pareil pour un modèle. Avant de choisir où l’exécuter, mesurez deux choses : le travail nécessaire pour une prédiction et le nombre de prédictions reçues. Choisissez ensuite le plus petit environnement qui convient, et notez pourquoi.

La question : l’IA a-t-elle besoin d’un GPU?

Tomás a lu des articles sur les serveurs d’IA. « Tous les services d’IA utilisent des GPU. Louons-en un pour le modèle d’escalade. »

Amira ne discute pas. Elle mesure. Le service indique déjà où passe le temps, dans l’en-tête Server-Timing de Connecter l’API. Elle démarre le service avec fastapi dev. Dans un deuxième terminal, elle calcule trois fois le score du billet de soutien d’exemple. Elle affiche seulement les en-têtes (-D -) et garde la troisième réponse. La première requête après un démarrage peut être plus lente :

macOS et Linux
Windows

curl -s -D - -o /dev/null http://127.0.0.1:8000/v1/score -H "Content-Type: application/json" -d '{"ticket_id":"T-120001","channel":"email","team":"payment","segment":"home","region":"west","priority":1,"order_value":89.5,"word_count":112,"customer_tenure_days":400,"prior_tickets_90d":2,"created_hour":10,"prior_escalations_90d":1}'

Ouvrez http://127.0.0.1:8000/docs, choisissez POST /v1/score, Try it out (essayer), puis Execute (exécuter) avec le billet d’exemple. La zone Response headers (en-têtes de réponse) affiche server-timing.

La sortie (abrégée) :

HTTP/1.1 200 OK
date: Thu, 08 Oct 2026 15:05:35 GMT
server: uvicorn
content-length: 119
content-type: application/json
server-timing: frame;dur=0.66, prepare;dur=1.38, model;dur=0.05
x-request-id: 1da326860017

Lisez les trois étapes. frame (table) construit une table à partir du billet. prepare (préparer) exécute le prétraitement du pipeline : encodage à chaud, remplacement des nombres manquants et mise à l’échelle. model (modèle) est la régression logistique elle-même : 0,05 ms. La requête entière prend environ 3 ms. Le modèle représente donc moins de 2 % de ce temps. Le prétraitement prend 28 fois plus de temps que le modèle. Le reste des 3 ms correspond à HTTP, à JSON et aux vérifications du contrat.

Ces valeurs viennent d’une seule exécution. Dans Connecter l’API, une autre exécution de la même requête affichait frame;dur=1.07, prepare;dur=1.81, model;dur=0.07. Les valeurs changent un peu d’une exécution à l’autre, mais les proportions restent les mêmes. L’étape du modèle est toujours la plus courte.

CPU et GPU

Un ordinateur possède un CPU (unité centrale de traitement). Il contient quelques cœurs. Chaque cœur est rapide et peut faire tout type de travail : lire un fichier, vérifier un billet, construire une table. Imaginez quelques cuisiniers compétents.

Un GPU (processeur graphique) servait d’abord à dessiner des images. Il contient des milliers de petits cœurs qui font une chose simple en même temps : multiplier et additionner des nombres. Imaginez mille aides qui peuvent seulement couper des aliments, mais tous en même temps. Un GPU est rapide seulement quand le travail comporte un très grand nombre de multiplications identiques.

Combien en faut-il pour calculer un score d’escalade? Le pipeline transforme un billet en 28 nombres, et le modèle a un poids pour chacun. Le score demande donc 28 multiplications, 28 additions et une dernière étape qui transforme la somme en nombre entre 0 et 1. Un cœur de CPU le fait en bien moins d’une microseconde.

Un réseau de neurones pour les images est différent. ResNet-50, un modèle d’images courant, fait environ 4 milliards de multiplications et d’additions pour une photo. Les grands modèles de langage en font davantage. Pour ce travail, des milliers d’aides travaillant en même temps font vraiment gagner du temps. Vous découvrez ces modèles dans L’apprentissage profond et les transformeurs expliqués et Réglage fin et adaptation des modèles d’IA.

Voici maintenant l’exemple détaillé pour Larkfield. Supposons qu’un GPU réduise à zéro le temps de l’étape du modèle. La requête passe d’environ 3,0 ms à environ 2,95 ms. Personne au service de soutien ne voit la différence. Le GPU ajoute aussi du travail : les données doivent passer de la mémoire du CPU à celle du GPU, puis revenir. Et le GPU coûte plus cher chaque heure, comme le montrent les prochaines sections.

La règle est donc : utilisez un GPU quand une prédiction demande des millions ou des milliards de multiplications identiques. Les réseaux de neurones pour les images, le son ou le texte en sont des exemples. Utilisez un CPU pour les petits modèles tabulaires comme celui-ci, où le prétraitement et le serveur Web prennent l’essentiel du temps.

Le modèle est petit, pas le programme

Le fichier du modèle est petit : model.joblib fait 5 354 octets, et l’ensemble fait 45,1 ko. Le programme qui l’exécute n’est pas petit. Python avec scikit-learn, pandas, NumPy, SciPy et FastAPI utilise environ 190 Mio de mémoire dans chaque processus. La prochaine leçon mesure cette mémoire dans le conteneur. Presque toute cette mémoire sert aux bibliothèques, pas au modèle. Dans la prochaine leçon, l’image du conteneur montre la même chose sur disque : 461 Mo de bibliothèques pour un ensemble de 45 ko.

Pour ce modèle, les bibliothèques déterminent donc la taille de la machine : environ 200 Mio de mémoire par processus, plus une marge. Pour un grand réseau de neurones, c’est l’inverse. Le modèle lui-même peut demander plusieurs gigaoctets, et la taille de la machine dépend du modèle.

Trois endroits où exécuter un modèle

Il existe de nombreux produits, mais trois types d’endroits. Ils diffèrent par l’effort d’exploitation : le travail de votre équipe pour garder le service en marche. Moins d’effort pour vous signifie qu’un fournisseur fait le travail, et que vous le payez pour cela.

Une tâche planifiée. Un programme démarre, calcule les scores d’un fichier et s’arrête, par exemple chaque nuit. C’est le calcul de scores par lots de Inférence par lots. Vous payez seulement pendant son exécution. Personne n’attend une réponse, donc un démarrage lent ne pose pas de problème.
Un conteneur sur une plateforme de conteneurs. Vous construisez l’image, et la plateforme l’exécute, comme dans le cours sur Docker avec Azure Container Apps. Vous choisissez la taille, le nombre de copies et les sondes. La plateforme peut réduire à zéro : arrêter toutes les copies quand aucune requête n’arrive. La première requête attend alors un démarrage à froid : le temps nécessaire pour qu’une nouvelle copie soit prête.
Un point de terminaison en ligne géré. Vous fournissez au fournisseur le modèle et son environnement, ou votre propre image de conteneur. Le fournisseur crée les machines, met à jour leur système d’exploitation, ajuste leur nombre et ajoute la surveillance et des règles de trafic. Les points de terminaison en ligne gérés d’Azure Machine Learning, les points de terminaison en temps réel d’Amazon SageMaker et la prédiction en ligne de Google Vertex AI en sont des exemples. Sur Azure, vous payez chaque machine pour chaque heure où le déploiement existe. Un point de terminaison en ligne ne peut pas être réduit à zéro.

Trois colonnes, une par endroit où exécuter le modèle : une tâche planifiée, un conteneur sur une plateforme de conteneurs et un point de terminaison en ligne géré. Chaque colonne contient les cinq mêmes couches, de haut en bas : l'ensemble du modèle; le code de calcul des scores et l'API; l'image et ses paquets; la mise à l'échelle et le trafic; les machines et leur système d'exploitation. Pour la tâche et la plateforme de conteneurs, votre équipe gère les trois premières couches et la plateforme gère les deux dernières. Pour le point de terminaison géré, votre équipe gère l'ensemble et le code de calcul des scores. Le fournisseur peut fournir l'image et gère la mise à l'échelle, le trafic et les machines, avec la surveillance, la répartition du trafic et la duplication du trafic. Sous chaque colonne, ce que vous payez : la tâche, seulement pendant son exécution; la plateforme de conteneurs, pendant qu'une réplique fonctionne, avec une réduction à zéro possible; le point de terminaison géré, chaque machine pour chaque heure, sans réduction à zéro possible. — Qui fait le travail à chaque endroit. Les couches pleines représentent le travail de votre équipe; les couches pâles, celui du fournisseur. Moins de travail pour vous coûte généralement plus cher chaque heure.

Omar pose la question qui détermine la plupart des choix : « Combien coûte chaque option par mois? »

Le coût de chaque endroit

Amira compare 30 jours (720 heures) pour chaque endroit. Elle utilise les prix de l’Azure Retail Prices API (canadacentral, dollars US, paiement à l’utilisation) :

Azure Container Apps : 0,000034 $ US par vCPU-seconde en activité, 0,000004 $ US au repos et 0,000004 $ US par Gio-seconde. Chaque mois, les premières 180 000 vCPU-secondes et 360 000 Gio-secondes sont gratuites (Connaître les coûts : ce qui peut entraîner des frais dans le cours sur Docker).
Un point de terminaison en ligne géré sur Azure Machine Learning n’ajoute aucuns frais propres : vous payez ses machines virtuelles. Standard_D2as_v4 (2 vCPU, 8 Gio, sans GPU) coûte 0,107 $ US l’heure. Standard_NC4as_T4_v3 (4 vCPU et un GPU NVIDIA T4) coûte 0,584 $ US l’heure.

L’exemple détaillé pour l’application conteneurisée : une réplique avec 0,5 vCPU et 1 Gio fonctionne tout le mois, toujours en activité. C’est le pire cas.

Étape	vCPU	Mémoire
Utilisation : taille × 2 592 000 secondes	0,5 × 2 592 000 = 1 296 000 vCPU-s	1 × 2 592 000 = 2 592 000 Gio-s
Moins le quota gratuit	1 296 000 − 180 000 = 1 116 000	2 592 000 − 360 000 = 2 232 000
Multiplié par le prix	1 116 000 × 0,000034 = 37,94 $ US	2 232 000 × 0,000004 = 8,93 $ US

Au total : environ 46,87 $ US par mois. Si la réplique reste au repos la plupart du temps, le tarif du vCPU descend au tarif au repos. Le mois coûte alors environ 13,39 $ US. Pour le point de terminaison, c’est plus simple : 720 heures × 0,107 $ US = 77,04 $ US pour une machine CPU. Une machine GPU coûte 420,48 $ US. Microsoft recommande au moins trois instances en production, pour que les autres répondent pendant qu’Azure en met une à jour. Trois machines CPU coûtent 231,12 $ US.

Calcul pour 30 jours aux tarifs à l'utilisation (canadacentral, paiement à l'utilisation). Le registre, le stockage et les journaux s'ajoutent. Vérifiez les prix actuels avant de choisir.

Description textuelle du graphique

Un graphique à colonnes du coût du calcul pour 30 jours, en dollars US. « Tâche » : une tâche nocturne qui fonctionne quelques secondes, environ 0, dans le quota gratuit. « Conteneur » : une application conteneurisée avec 0,5 vCPU et 1 Gio, une réplique, toujours en activité, 47. « CPU ×1 » : un point de terminaison en ligne géré avec une machine Standard_D2as_v4, 77. « CPU ×3 » : le même point de terminaison avec trois machines, comme recommandé pour la production, 231. « GPU ×1 » : un point de terminaison géré avec une machine GPU Standard_NC4as_T4_v3, 420.

La machine GPU coûte environ 5,5 fois plus cher que la machine CPU. Pour Larkfield, elle ferait gagner environ 0,05 ms par requête.

Le choix de Larkfield

Passons à la charge. Larkfield reçoit environ 45 nouveaux billets par jour : 1 400 en juillet, surtout de 7 h à 22 h. Le service calcule le score de chaque billet pendant qu’un agent l’ouvre. Quelqu’un attend donc la réponse : c’est un service en ligne. Dans Inférence en ligne, Grace a réservé 50 ms au service sur les 300 ms de sa page de billet. Le p95 doit rester sous 50 ms, réseau compris. Quarante-cinq billets par jour, c’est environ trois pendant l’heure la plus occupée. Un processus répond à une requête en environ 3 ms.

Tomás : « Alors, il nous faut presque rien. Pourquoi ne pas réduire à zéro et ne rien payer? » Parce qu’un agent attend le premier score après chaque période calme, et la plupart des périodes sont calmes. Dans le cours sur Docker, la première requête après une réduction à zéro attendait 18 secondes pour l’image ticket-api de 73 Mo. L’équipe du cours a déployé l’image de ce service sur Azure Container Apps, avec 0,5 vCPU et 1 Gio. L’image à télécharger fait 166 Mo. La première requête à partir de zéro réplique a pris 26,4 secondes (mesure réelle). Avec 1 vCPU, elle prenait encore 23,9 secondes. C’est 500 fois le temps alloué. Si le score n’est pas disponible, la page s’ouvre sans lui. Le traitement par lots nocturne calcule le score du billet plus tard.

Omar : « Et le point de terminaison géré? Il en fait plus pour nous. » Oui, et la répartition et la duplication du trafic aident lors des mises en production. Mais il coûte au moins 77 $ US par mois pour une machine, bien plus grande que nécessaire pour ce modèle. Et il ne réduit jamais à zéro. Pour un modèle de 5 ko et 45 requêtes par jour, c’est la cuisine de restaurant pour une seule rôtie. Si Larkfield sert plus tard plusieurs modèles, ou un grand modèle, le point de terminaison peut devenir le meilleur choix.

Amira note donc la décision : CPU seulement; un conteneur sur Azure Container Apps, comme dans le cours sur Docker; 0,5 vCPU et 1 Gio; un processus; au moins une réplique pendant les heures de travail. Un court document qui consigne une décision, ses raisons et les chiffres qui l’appuient est une fiche de décision. Il permet à l’équipe de vérifier la décision plus tard, quand un chiffre change.

Exemple détaillé : docs/infrastructure.md

Amira crée le dossier docs dans le projet et écrit le fichier :

# Infrastructure decision: escalation-service

Where Larkfield's escalation model runs, and why. Written by Amira
(C17 Module 4), with Priya (model), Grace (help desk) and Omar (product).
Change this file when one of its numbers changes.

## What the model needs

- Model: logistic regression with preprocessing, 28 weights. `model.joblib` is 5,354 bytes; the bundle is 45.1 kB.
- Time for one warm request on a laptop (Server-Timing): frame 0.66 ms, prepare 1.38 ms, model 0.05 ms. The whole request takes about 3 ms. The model is less than 2% of it.
- Memory: about 190 MiB for each worker (Python, scikit-learn, pandas, NumPy, SciPy, FastAPI). The libraries, not the model, set the size.
- A GPU would make only the model step faster (0.05 ms). Not needed.

## The load

- About 45 tickets a day (July: 1,400 tickets in 31 days), mostly from 07:00 to 22:00. The busiest hour had about 3 tickets on an average day.
- Online: an agent waits for the score when the ticket opens. Budget: p95 under 50 ms, network included (Online inference). Without an answer, the page opens without a score, and the nightly batch scores the ticket.

## The options (30 days, compute only)

Prices from the Azure Retail Prices API, canadacentral, USD, pay-as-you-go. Check again before deploying.

| Option | Cost for 30 days | Notes |
|---|---|---|
| Job on a schedule (batch) | about US$0 (free grant) | Nobody waits. Does not serve the help desk. Already used for the nightly file. |
| Azure Container Apps, 0.5 vCPU / 1 GiB, 1 replica | US$13.39 idle to US$46.87 always active | Scale to zero is possible, but the first request then waits for a cold start. |
| Azure ML managed online endpoint, 1 x Standard_D2as_v4 | US$77.04 | No scale to zero. Microsoft recommends 3 instances for production: US$231.12. |
| Managed endpoint with a GPU, 1 x Standard_NC4as_T4_v3 | US$420.48 | Saves about 0.05 ms per request. |

## The decision

- CPU only.
- One container on Azure Container Apps, as in C18: 0.5 vCPU and 1 GiB, one worker (`WORKERS=1`).
- At least one replica from 07:00 to 22:00, so that agents do not wait for a cold start.
- Revisit if: the load grows past what one worker serves inside the budget, the model becomes a neural network, or Larkfield serves several models (then compare a managed endpoint again).

## Check before we deploy

- [ ] Memory per worker in a container with a limit (Container resource settings).
- [ ] Cold start at 0.5 CPU (Container resource settings).
- [ ] p50, p95 and throughput with a fixed workload (Benchmark the service).
- [ ] The cold start and the latency in the cloud, with the network (to measure after the first deployment).

Chaque chiffre a une source : une mesure, une page de prix avec sa date, ou la charge fournie par Grace. La section Check before we deploy (vérifier avant de déployer) liste ce qui n’est pas encore mesuré. Les deux prochaines leçons le mesurent, et la dernière ajoute les résultats.

Exercice guidé : rédiger la fiche de décision

Dans ~/projects/escalation-service, avec .venv actif, démarrez le service avec fastapi dev.
Dans un deuxième terminal, envoyez le billet d’exemple trois fois, comme dans La question. Notez les trois valeurs de server-timing de la dernière réponse.
Arrêtez le service avec Ctrl+C.
Créez le dossier docs et le fichier docs/infrastructure.md.
Rédigez les sections What the model needs (besoins du modèle) et The load (charge). Incluez vos trois temps et le temps alloué dans Inférence en ligne.
Rédigez The options (options), avec un coût pour 30 jours pour chacune. Utilisez les prix du jour des pages officielles et notez la date.
Rédigez The decision (décision) et Check before we deploy.

Afficher les valeurs server-timing attendues à l’étape 2

Vos chiffres diffèrent, mais leur ordre de grandeur ressemble à ceci : frame sous 1 ms, prepare de 1 à 2 ms, model sous 0,1 ms. Sur l’ordinateur du cours, prepare prenait 20 à 30 fois plus de temps que model. Si model est la plus grande des trois valeurs, vérifiez que vous avez envoyé le billet d’exemple. Regardez ensuite une réponse ultérieure : la première requête après un démarrage peut être plus lente.

À vous de jouer : un modèle qui a besoin d’un GPU

Priya a une nouvelle idée : lire le texte de chaque billet avec un réseau de neurones pour le texte. Le modèle fait 400 Mo. Un billet prend environ 300 ms sur un CPU et environ 15 ms sur un GPU T4. Ces deux durées sont des hypothèses pour cet exercice, pas des mesures. La charge reste de 45 billets par jour, et l’agent attend toujours.

Modifiez une section de votre document de décision : La décision. Un GPU en vaut-il maintenant la peine? Que vérifiez-vous d’abord?

Afficher une réponse

Comparez d’abord les deux durées au budget d’Inférence en ligne : un p95 inférieur à 50 ms. Les 300 ms sur un CPU dépassent le budget, même sans le réseau. Les 15 ms sur un GPU respectent le budget. Le GPU rend maintenant le calcul du score en ligne possible. Son coût est le prix de cette fonctionnalité. L’autre choix consiste à garder le CPU et à utiliser le modèle de texte seulement dans le lot de nuit. Personne n’attend, et les 45 billets prennent environ 14 secondes. Avant de décider, mesurez les deux durées avec le vrai modèle et de vrais textes de billets. Vérifiez aussi la mémoire : un modèle de 400 Mo par processus dépasse le double de sa consommation actuelle.

Erreur courante

Passer à zéro instance pour un service dont les gens attendent la réponse

Symptôme : le service réussit tous les tests. Le lundi matin, le premier agent ouvre un billet et attend plusieurs secondes pour obtenir le score. Les agents suivants obtiennent leurs scores immédiatement.

Cause : la plateforme a réduit le service à zéro instance pendant la nuit, comme le prévoyaient ses paramètres. La première requête a donc attendu un démarrage à froid. La plateforme trouve une machine, télécharge l’image et démarre le conteneur. Ensuite, le service importe ses bibliothèques et charge l’ensemble empaqueté. Pour ce service sur Azure Container Apps, cela a pris 26,4 secondes. Dans le cours sur Docker, cela a pris 18 secondes avec une image plus petite.

Solution : choisissez le nombre minimal de répliques selon les personnes qui attendent. Pour un service en ligne pendant les heures de travail, gardez au moins une réplique et acceptez le coût. Ici, il est d’environ 13 $ US à 47 $ US par mois. Pour une tâche de nuit, passez à zéro instance, car personne n’attend.

Pour un vrai service d’IA : le démarrage à froid s’allonge avec la taille de l’image et le travail au démarrage. La plateforme doit télécharger un gros modèle et le charger en mémoire avant la première réponse. Cela peut prendre plusieurs minutes. Passer à zéro instance économise de l’argent seulement si une première réponse lente est acceptable.

Vérifiez votre compréhension

Tomás dit : le service de transfert au niveau supérieur est lent, alors passons-le sur un GPU. Utilisez les durées mesurées côté serveur pour expliquer pourquoi un GPU n'aiderait pas.

Afficher la réponse

L’étape du modèle prend environ 0,05 ms dans une requête d’environ 3 ms. Le reste comprend HTTP, JSON, les vérifications du contrat et le prétraitement. Un GPU ne les accélère pas. Même si le GPU éliminait la durée de l’étape du modèle, la requête passerait d’environ 3,0 à 2,95 ms. Un GPU aide quand une prédiction exige des millions ou des milliards de multiplications, comme dans les réseaux de neurones. Ce modèle en exige 28.

Vérifiez votre compréhension

Une équipe recalcule les scores de 2 millions de polices d'assurance chaque mois. Personne n'attend le résultat. Lequel des trois environnements convient le mieux, et que paie l'équipe?

Afficher la réponse

Une tâche planifiée. Elle démarre une fois par mois, calcule les scores du fichier et s’arrête. L’équipe paie donc seulement pendant son exécution. Un conteneur qui attend des requêtes, ou un point de terminaison géré, coûterait de nombreuses heures pour une exécution mensuelle. Un démarrage lent n’a pas d’importance, car personne n’attend.

Vérifiez votre compréhension

Que fait un point de terminaison en ligne géré qu'un conteneur sur une plateforme de conteneurs ne fait pas? Comment Azure le facture-t-il?

Afficher la réponse

Le fournisseur crée et met à jour les machines, puis adapte leur nombre à la charge. Il ajoute la surveillance, la répartition du trafic entre les déploiements et la duplication du trafic. Vous pouvez lui fournir le modèle et un script de calcul des scores plutôt qu’une image complète. Azure facture chaque machine virtuelle du déploiement pour chaque heure. Il y a au moins une machine (Microsoft en recommande trois en production), et le nombre ne peut pas tomber à zéro. Une machine Standard_D2as_v4 coûtait environ 77 $ US pour 30 jours aux tarifs de cette leçon.

Récapitulatif

Mesurez avant de choisir. Pour Larkfield, l’étape du modèle prend 0,05 ms sur environ 3 ms. Les bibliothèques, et non le modèle de 5 ko, déterminent la mémoire nécessaire.
Un GPU effectue un très grand nombre de multiplications identiques en même temps. Il vaut la peine pour les réseaux de neurones, pas pour une régression logistique avec 28 poids.
Trois environnements : une tâche planifiée (paiement pendant son exécution), un conteneur sur une plateforme de conteneurs (paiement pendant l’exécution d’une réplique; zéro instance signifie un démarrage à froid) et un point de terminaison géré (moins de travail pour votre équipe; sur Azure, chaque machine est facturée chaque heure).
docs/infrastructure.md consigne la décision, chaque nombre avec sa source et les vérifications à faire avant le déploiement.

Ensuite, vous placez le service dans un conteneur et lui attribuez des ressources : CPU, mémoire et processus.

Leçon suivante : Paramètres de ressources du conteneur