# Système d'évolution intelligente EvoX et pratique de la recherche scientifique AI Native — Support de cours

Durée : 1 · Pages du support : 16

## Navigation de lecture

- [Leçon 4｜Thème : Socle de calcul moderne et évolution parallèle tensorisée](#lecture-lesson-1)

---

<a id="lecture-lesson-1"></a>

## Leçon 4｜Thème : Socle de calcul moderne et évolution parallèle tensorisée

<a id="lecture-page-1"></a>

### Socle de calcul moderne et évolution parallèle tensorisée

*Page 1*

> **Objectif de la page :** Découvrir comment EvoX organise la population, l'évaluation et l'état en tenseurs calculables globalement, afin de dépasser les goulots d'étranglement de la sérialisation traditionnelle et d'obtenir une accélération à grande échelle.

> **Objectif de la page**
>
> Cette page ouvre la quatrième leçon en pointant le problème central à résoudre — lorsque la taille de la population, le nombre d'évaluations et les étapes d'itération des algorithmes évolutionnaires augmentent, le traitement sérialisé individu par individu et étape par étape devient un goulot d'étranglement évident. Le fil conducteur de cette leçon consiste à voir comment EvoX réorganise la population, l'évaluation et l'état en tenseurs pouvant participer globalement au calcul, afin d'obtenir une accélération substantielle dans des scénarios à grande échelle.

> **Ordre d'explication**
>
> On peut d'abord poser une question intuitive — « Si la population compte cent mille individus, que se passe-t-il si nous devons encore les traiter un par un en boucle ? » — pour amener les étudiants à prendre conscience du double gaspillage du traitement sérialisé en termes de temps et d'utilisation du matériel. Ensuite, on donne la direction de la réponse de cette leçon : considérer toute la population comme un lot de données, considérer la mise à jour d'une génération comme une opération par lots, et faire en sorte que le calcul puisse être déployé globalement sur du matériel parallèle. Enfin, on introduit le rôle de la couche Runtime, en expliquant qu'elle est responsable de l'ordonnancement de la puissance de calcul hétérogène tout en maintenant la composabilité des algorithmes.

**Points clés de l'enseignement**

- 1. Expression tensorisée — la population, l'évaluation de la fitness et l'état interne de l'algorithme ne sont plus des objets dispersés, mais sont organisés en tenseurs de forme unifiée, permettant d'exprimer une génération d'évolution comme quelques opérations par lots. L'avantage est un modèle de calcul régulier, facile à vectoriser, et la possibilité pour une même description d'algorithme de s'adapter à différentes tailles de population. 2. Dépassement du goulot d'étranglement sérialisé — dans les implémentations traditionnelles, l'évaluation et la mise à jour d'état se font souvent individu par individu ; à grande échelle, les frais de boucle et les attentes de synchronisation dominent le temps d'exécution
- après la mise en lots, ces frais sont amortis et le débit augmente significativement. 3. Rôle d'ordonnancement du Runtime — le Runtime se situe entre la description de l'algorithme et le matériel sous-jacent, et est responsable de la répartition des opérations par lots sur les puissances de calcul hétérogènes telles que CPU et GPU, afin que les auteurs d'algorithmes n'aient pas à réécrire la logique pour chaque type d'appareil. En même temps, il maintient la composabilité des composants de l'algorithme, permettant à différents opérateurs et stratégies de se combiner librement sans briser la capacité de parallélisation.

**Couverture des mots-clés**

- Tensorisation, calcul par lots, goulot d'étranglement sérialisé, accélération à grande échelle, ordonnancement de puissance de calcul hétérogène, composabilité des algorithmes.

**Vérification de la compréhension**

Demander aux étudiants d'expliquer avec leurs propres mots ce que « transformer la population en tenseur » change réellement — la réponse attendue doit porter sur « passer d'une boucle individu par individu à une opération par lots globale, permettant ainsi au matériel parallèle d'être réellement utilisé » ; si l'étudiant ne fait que répéter les termes sans expliquer la causalité, on peut lui suggérer de réorganiser son explication sous l'angle du nombre de calculs et du taux d'utilisation du matériel.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants ont établi la chaîne causale de base « tensorisation → calcul par lots → accélération parallèle », passer aux pages suivantes pour examiner concrètement comment la population et l'état sont organisés en tenseurs, et comment le Runtime réalise l'ordonnancement.

<a id="lecture-page-2"></a>

### Socle de calcul moderne et évolution parallèle tensorisée

*Page 2*

> **Objectif de la page :** Les apprenants doivent comprendre la contradiction entre les besoins massifs en puissance de calcul du calcul évolutionnaire moderne et l'architecture traditionnelle.

> **Objectif de la page**
>
> Comprendre la contradiction entre les besoins massifs en puissance de calcul du calcul évolutionnaire moderne et l'architecture sérialisée traditionnelle ; maîtriser l'approche consistant à organiser la population, l'évaluation et l'état en tenseurs pour faire avancer l'évolution en parallèle par lots ; reconnaître l'extension de la génération de candidats par les grands modèles et les compromis architecturaux au niveau système qui en découlent.

> **Ordre d'explication**
>
> On commence par pointer la contradiction centrale « diversité → nombre d'évaluations → coût de gestion d'état et d'ordonnancement », puis on explique pourquoi la boucle sérialisée atteint d'abord ses limites ; ensuite on déploie les trois niveaux de tensorisation — tenseur de population, tenseur d'évaluation, tenseur d'état — et on résume le terme central de « parallélisme par lots » ; puis on explique comment les grands modèles poussent la génération de candidats vers de nouvelles frontières ; enfin on aboutit aux exemples de scénarios EvoX et aux compromis au niveau système, et on traite les exercices et cas pratiques.

**Points clés de l'enseignement**

- L'évolution dépend de la diversité de la population, et cette diversité se traduit directement en nombre d'évaluations, en gestion d'état et en coût d'ordonnancement. Dans la boucle CPU traditionnelle individu par individu, chaque individu doit appeler séparément la fonction objectif, mettre à jour séparément l'état, enregistrer séparément les logs
- lorsque la population passe de quelques dizaines à des milliers, le nombre d'évaluations et le temps horloge augmentent de manière quasi linéaire ; une fois qu'une simulation unique est coûteuse, le débit global est verrouillé au « rythme monocœur ». Plus la diversité est élevée et plus l'évaluation est coûteuse, plus le goulot d'étranglement sérialisé est évident. L'approche de tensorisation consiste à réorganiser la population, l'évaluation et l'état en tenseurs calculables globalement. Le tenseur de population empile tous les paramètres candidats en un tenseur bidimensionnel « nombre d'individus × dimension », et un seul appel d'opérateur accomplit la mutation et la mise à jour de toute la population
- le tenseur d'évaluation regroupe les requêtes d'évaluation par lots et les envoie, le GPU ou le service de traitement par lots les exécute en parallèle puis fusionne les valeurs de retour
- le tenseur d'état maintient sous forme tensorielle les états intermédiaires tels que la fitness, la violation de contraintes, le classement, de sorte que la sélection, le tri et la mise à jour puissent tous être calculés globalement. Les trois ensemble constituent le « parallélisme par lots », qui transforme la charge de calcul issue de la diversité d'un fardeau en une échelle absorbable par le débit ; il ne s'agit donc pas d'un détail d'optimisation, mais d'un problème d'infrastructure du calcul évolutionnaire moderne. Une fois l'échelle de calcul ouverte, la question clé passe de « peut-on calculer » à « d'où viennent les candidats ». Les grands modèles peuvent comprendre le langage naturel, le code, les connaissances du domaine et le contexte du projet, et construire sur cette base des candidats structurellement complexes, étendant l'objet de l'évolution des paramètres numériques aux programmes, algorithmes et même à l'état complet du système
- les méthodes d'encodage et de mutation qui dépendaient auparavant de la conception manuelle peuvent désormais être partiellement générées par le modèle. Deux forces se rencontrent ainsi : le GPU permet d'explorer simultanément un grand nombre de possibilités, le grand modèle permet au système de produire des possibilités plus riches, et le mécanisme évolutionnaire est chargé d'envoyer les candidats vers des tâches réelles, déterminant par l'exécution et l'évaluation quels changements méritent d'être conservés. Pour les ingénieurs en algorithmes et les développeurs de systèmes, il ne s'agit pas d'une optimisation locale, mais d'un compromis architectural : il faut faire un arbitrage au niveau système entre la richesse de la génération de candidats, le débit du calcul par lots et la complexité d'ingénierie. La diversité est la condition préalable à l'efficacité de l'évolution, mais elle doit être absorbée par le débit. Dans le scénario EvoX, si l'on utilise encore une boucle CPU sérialisée pour évaluer individu par individu, la taille de la population sera limitée par le débit
- après passage au parallélisme par lots tensorisé, le même cycle peut simultanément organiser les paramètres, l'état d'évaluation et la mise à jour d'un grand nombre de candidats, rendant « maintien de la diversité » et « exploration à grande échelle » simultanément réalisables sur le plan de l'ingénierie.

**Couverture des mots-clés**

- Parallélisme par lots, tensorisation, tenseur de population, tenseur d'évaluation, tenseur d'état, goulot d'étranglement sérialisé, génération de candidats, compromis au niveau système.

**Traitement des exercices**

Cette page comporte 5 questions à choix multiples et 1 étude de cas, soit 2 questions au total. Les questions à choix multiples vérifient respectivement la contradiction centrale, le mode de réalisation du parallélisme par lots, le rôle des grands modèles, le compromis au niveau système après migration, et les changements directs dans le scénario EvoX. Pour répondre, s'appuyer sur deux fils conducteurs : premièrement la chaîne causale « diversité → charge de calcul → goulot d'étranglement sérialisé → parallélisme par lots » ; deuxièmement la division du travail « le grand modèle est responsable de générer des candidats plus riches, le mécanisme d'évaluation est responsable de juger quels candidats méritent d'être conservés ». La première question de l'étude de cas demande de diagnostiquer le goulot d'étranglement sérialisé et d'expliquer comment la tensorisation modifie l'organisation à trois niveaux : population, évaluation et état ; la deuxième question demande de fournir un jugement de compromis selon les dimensions richesse des candidats vs débit par lots, bénéfice d'exploration vs complexité d'ingénierie, débit par lots vs fidélité d'évaluation.

Une réponse correcte doit pouvoir relier les concepts de cette page et expliquer le raisonnement ; en cas d'erreur, revenir à la chaîne causale « diversité → nombre d'évaluations → coût de gestion d'état et d'ordonnancement », et distinguer « accélérer la même boucle sérialisée » de « changer l'organisation du calcul ».

**Vérification de la compréhension**

Demander à un étudiant choisi au hasard de résumer avec ses propres mots les points clés de cette page, en particulier comment la diversité se transforme en charge de calcul, pourquoi la sérialisation atteint ses limites, et comment le parallélisme par lots tensorisé organise la population, l'évaluation et l'état. Si l'étudiant ne peut que répéter les termes sans expliquer la causalité, on peut le guider vers la comparaison des pentes dans le graphique et le marqueur « goulot d'étranglement sérialisé : débit au maximum ».

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer la relation centrale de cette page — la diversité engendre la charge de calcul, l'exécution sérialisée atteint ses limites, le parallélisme par lots tensorisé absorbe l'échelle par le calcul global — passer aux exemples, applications ou résumés de la page suivante.

<a id="lecture-page-3"></a>

### Diversité évolutive et défis de l'échelle de calcul

*Page 3*

> **Objectif de la page :** Les apprenants doivent comprendre la pression de calcul engendrée par les compromis multi-objectifs et la diversité des candidats dans les problèmes réels.

> **Objectif de la page**
>
> Comprendre la pression de calcul engendrée par les compromis multi-objectifs et la diversité des candidats, maîtriser le front de Pareto, les relations de dominance, ainsi que la tension entre maintien de la diversité et coût d'évaluation.

**Points clés de l'enseignement**

- Ce n'est que lorsqu'un problème n'a qu'un seul objectif qu'il existe une solution optimale unique. Les problèmes d'ingénierie réels ont généralement plusieurs objectifs mutuellement contraignants (portance et traînée, précision et latence, performance et coût) ; dans ce cas, la « bonne réponse » est un ensemble de solutions de compromis mutuellement non dominées, c'est-à-dire le front de Pareto. Comparer terme par terme si A n'est pas pire que B sur tous les objectifs → si A est strictement meilleur sur au moins un objectif → A domine B seulement si les deux conditions sont remplies. Si A est pire sur un seul critère, les deux sont mutuellement non dominées et peuvent toutes deux rester sur le front. L'axe horizontal f1 et l'axe vertical f2 sont tous deux « plus petit est mieux »
- le groupe A penche vers un f1 faible, le groupe B est un compromis, le groupe C penche vers un f2 faible
- les points gris sont des solutions dominées. Le décideur a besoin de l'espace de compromis représenté par tout le front, et non d'un point unique choisi par l'algorithme. Désigne les différences structurées réparties le long de différentes directions de compromis sur le front de Pareto. Couverture des directions — remplir l'extrémité supérieure gauche, le segment médian et l'extrémité inférieure droite du front
- préservation des différences — des candidats presque identiques équivalent à un seul
- valeur décisionnelle — les préférences se précisent souvent après coup, conserver des candidats différenciés permet de rechoisir à coût nul. Plus la diversité est forte, plus l'espace de recherche est vaste, plus la taille de la population est grande, plus le nombre d'évaluations est élevé. Lorsque l'évaluation dépend de simulations haute fidélité (comme le calcul aérodynamique d'un profil supercritique qui prend des heures), le coût d'une évaluation unique est amplifié au point de devenir le goulot d'étranglement principal. Réponses courantes : remplacer la majorité des évaluations haute fidélité par un modèle surrogate
- allouer en priorité le budget limité de haute fidélité aux candidats qui étendent le plus la couverture du front
- répartir le budget entre taille de population et nombre de générations. Assimiler la diversité à du bruit aléatoire ou à « exécuter plusieurs fois ». La véritable diversité est une différence de direction structurée
- une simple perturbation aléatoire n'étendra pas la couverture du front et ne réduira pas la difficulté décisionnelle. Indices d'exercice (5 questions à choix multiples + 1 analyse de cas) : Le front de Pareto est un ensemble de solutions de compromis mutuellement non dominées, deux solutions quelconques ayant chacune des avantages et des inconvénients sur différents objectifs. A est meilleur sur f1, B est meilleur sur f2, les deux sont mutuellement non dominées et peuvent toutes deux rester sur le front. La diversité est une différence structurée répartie le long de différentes directions de compromis sur le front de Pareto, servant directement la décision. Une couverture plus large des directions de compromis nécessite un espace de recherche plus grand, une taille de population et un nombre d'évaluations d'objectifs plus importants ; donc plus la diversité est forte, plus le défi de l'échelle de calcul est grand. Utiliser un modèle surrogate pour assumer la majorité des évaluations et concentrer le budget limité de haute fidélité sur l'extension de la couverture du front peut atténuer la tension entre échelle et diversité. Conception de profil supercritique. Le livrable doit être un ensemble de solutions candidates situées sur le front de Pareto et couvrant différentes directions de compromis, et non une solution unique
- les mesures d'atténuation de la tension comprennent les modèles surrogate, l'allocation prioritaire du budget, l'ajustement du ratio population/générations, le filtrage multi-fidélité par étapes, etc.

**Vérification de la compréhension**

Demander aux étudiants d'expliquer avec leurs propres mots la relation de dominance et le front de Pareto, et d'illustrer par un exemple pourquoi la diversité engendre une pression de calcul. Si les étudiants confondent diversité et perturbation aléatoire, revenir à la « formule d'auto-vérification » — peu importe le nombre de candidats, s'ils s'entassent dans le même coin du front, il n'y a toujours pas de diversité.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent distinguer l'optimum ponctuel de l'ensemble de solutions de compromis, et qu'ils comprennent le coût de la diversité, passer au contenu de la page suivante sur l'évolution parallèle tensorisée.

<a id="lecture-page-4"></a>

### Goulot d'étranglement d'efficacité de la boucle CPU sérialisée traditionnelle

*Page 4*

> **Objectif de la page :** Les apprenants doivent prendre conscience des limites de performance de la boucle CPU sérialisée traditionnelle lors du traitement de dizaines de milliers d'évaluations de candidats.

**Points clés de l'enseignement**

- Nombre total d'évaluations ≈ taille de la population × nombre de générations ; temps d'évaluation sérialisé ≈ nombre total d'évaluations × temps d'une évaluation unique. Calculer d'abord ces deux quantités, puis juger si le goulot d'étranglement vaut la peine d'être transformé.
- La boucle au niveau de l'interpréteur, les vérifications de limites et la distribution de types individu par individu, les accès mémoire non contigus, les synchronisations et transferts de données fréquents s'accumulent en un surcoût constant sérialisé. Optimiser uniquement l'opérateur lui-même ne permet d'en éliminer qu'une petite partie.
- Tracer le temps horloge pour différentes tailles de population : une courbe quasi linéaire indique que l'exécution est encore sérialisée, une courbe en escalier indique qu'elle est déjà organisée par lots. La forme de la courbe est plus révélatrice de l'origine du goulot d'étranglement qu'un chiffre ponctuel.

> **Objectif de la page**
>
> Cette page vise à faire prendre conscience aux étudiants que lorsque les évaluations de candidats atteignent l'ordre de dizaines de milliers, la boucle CPU sérialisée traditionnelle devient le segment le plus étroit de tout le pipeline d'évolution ; ce goulot d'étranglement relève du modèle d'exécution, et non de l'écriture d'un opérateur individuel ou d'un défaut de code. Le traitement par lots, la tensorisation et l'ordonnancement parallèle ultérieurs sont précisément les directions de transformation ciblant ce goulot d'étranglement structurel.
>
> Ordre d'explication et points clés de l'enseignement :
>
> L'évolution dépend de la diversité, et la diversité entraîne une multiplication de la taille de la population et du nombre d'évaluations. Nombre total d'évaluations ≈ taille de la population × nombre de générations ; temps d'évaluation sérialisé ≈ nombre total d'évaluations × temps d'une évaluation unique. Lorsque le nombre d'évaluations atteint l'ordre de 10⁵, le temps horloge sérialisé croît de manière quasi linéaire.
>
> Le graphique compare le traitement sérialisé individu par individu et le traitement parallèle par lots. L'axe horizontal représente le nombre d'évaluations de candidats 10³, 10⁴, 10⁵, et l'axe vertical le temps horloge normalisé. La courbe sérialisée croît de manière quasi linéaire ; la courbe parallèle croît en escalier. Les segments foncés représentent les frais d'ordonnancement et de transfert de données. La conclusion clé est que, pour une charge de travail égale, la croissance du temps parallèle est principalement déterminée par le nombre de lots plutôt que par le nombre d'individus. La forme de la courbe est plus révélatrice de l'origine du goulot d'étranglement qu'un chiffre ponctuel.
>
> L'implémentation la plus naïve consiste à traiter toute la population comme une liste, à parcourir en boucle chaque individu → décoder en paramètres concrets → appeler la fonction d'évaluation → réécrire la fitness. Les itérations adjacentes ne peuvent presque pas se chevaucher : tant que le résultat d'évaluation n'est pas revenu, l'écriture ne peut pas avancer ; tant que l'écriture n'est pas terminée, l'individu suivant n'a nulle part où stocker son résultat. Ainsi, les unités parallèles telles que les multicœurs, SIMD, GPU restent inactives la plupart du temps.
>
> L'expansion linéaire du nombre d'évaluations ; l'exécution individu par individu au niveau de l'interpréteur, y compris la boucle individu par individu, les vérifications de limites et la distribution de types, entraîne un surcoût constant fixe mais élevé ; les accès mémoire non contigus et les transferts de données, les individus pris un par un étant souvent non contigus en mémoire, le taux de succès du cache est faible ; la synchronisation et l'ordonnancement, pour obtenir l'individu suivant, le flux d'exécution s'arrête et reprend de façon répétée. Optimiser uniquement l'intérieur de l'opérateur ne permet d'en éliminer qu'une petite partie.
>
> En prenant une population de 1000 et 100 générations comme exemple, le nombre total d'évaluations est d'environ 1000 × 100 = 10⁵. Si une évaluation unique prend en moyenne 1 ms, la seule étape d'évaluation sérialisée prend environ 100 secondes, sans compter le calcul des opérateurs et les frais d'ordonnancement ; si pour maintenir la diversité on passe le nombre de redémarrages de 1 à 5, le coût augmente de manière quasi linéaire jusqu'à environ 500 secondes. Pour une charge de travail égale, si elle est organisée par lots et traitée par du matériel parallèle, le temps horloge est principalement déterminé par le nombre de lots et le temps par lot.
>
> Lorsque l'évaluation unique est extrêmement bon marché (ordre de la microseconde) ou que la population est très petite (ordre de la centaine ou moins), les frais d'ordonnancement et de mémoire peuvent dépasser les frais de calcul, l'écart entre sérialisé et parallèle se réduit nettement, le bénéfice marginal de la tensorisation diminue, et le goulot d'étranglement se déplace vers la granularité d'ordonnancement et la bande passante mémoire. Par conséquent, l'opportunité de transformer le modèle d'exécution doit être évaluée conjointement en fonction du coût d'évaluation et de l'échelle.
>
> Le goulot d'étranglement d'efficacité de la boucle CPU sérialisée est structurel. Pour le résoudre véritablement, il faut restructurer l'individu par individu en lot par lot, c'est-à-dire le traitement par lots, la tensorisation et l'ordonnancement parallèle, ce qui constitue la motivation directe de la conception du graphe de calcul tensorisé ultérieur.

**Couverture des mots-clés**

- Boucle CPU sérialisée, parallélisme par lots, temps horloge, nombre d'évaluations de candidats, nombre de lots, surcoût au niveau de l'interpréteur, accès mémoire non contigus, synchronisation et ordonnancement, goulot d'étranglement structurel, tensorisation.

**Traitement des exercices**

Cette page comporte 5 questions à choix multiples. Il est recommandé de demander d'abord à l'étudiant d'énoncer le raisonnement, puis de donner un retour.

La question 1 porte sur la principale limitation du modèle d'exécution de la boucle sérialisée. La réponse est « les itérations adjacentes ne peuvent presque pas se chevaucher, les unités parallèles telles que les multicœurs, SIMD, GPU restent inactives la plupart du temps ». Points de retour : le flux d'exécution individu par individu « prendre l'individu → décoder → évaluer → réécrire » fait de chaque individu une étape sérialisée indépendante, le matériel manque de travail indépendant exécutable simultanément ; le goulot d'étranglement n'est pas l'incapacité à calculer la fitness, mais le fait qu'un seul individu est traité à la fois.

La question 2 demande le temps horloge sérialisé de la seule étape d'évaluation pour une population de 1000, 100 générations et une évaluation unique de 1 ms. La réponse est environ 100 secondes. Algorithme de guidage : nombre total d'évaluations ≈ 1000 × 100 = 10⁵, puis multiplier par 1 ms.

La question 3 demande quel élément ne fait pas partie des facteurs amplifiant le surcoût constant de la boucle sérialisée. La réponse est « l'ordonnancement du traitement par lots tensorisé ». Points de retour : le traitement par lots tensorisé est une direction de transformation pour atténuer le goulot d'étranglement, et non une source d'amplification du surcoût de la boucle sérialisée elle-même ; le surcoût sérialisé provient des accès mémoire non contigus, des vérifications de limites et de la distribution de types individu par individu, de la boucle au niveau de l'interpréteur, etc.

La question 4 demande ce qui détermine principalement le temps horloge pour accomplir une charge de travail totale égale en parallélisme par lots. La réponse est « le nombre de lots et le temps par lot ». Points de retour : le traitement par lots transforme l'individu par individu en lot par lot, le temps horloge croît en escalier avec le nombre de lots, et non de manière quasi linéaire avec le nombre d'individus.

La question 5 demande dans quel cas juger la boucle sérialisée comme goulot d'étranglement structurel est le plus susceptible d'être invalide. La réponse est « une évaluation unique descendue à l'ordre de la microseconde, et une taille de population de l'ordre de la centaine seulement ». Points de retour : dans ce cas, les frais d'ordonnancement et de mémoire peuvent dépasser les frais de calcul, l'écart entre sérialisé et parallèle se réduit ; le jugement du goulot d'étranglement doit être évalué conjointement en fonction du coût d'évaluation et de l'échelle.

**Activité en classe**

On peut utiliser le cas de cette page « Choix du modèle d'exécution sous cent mille évaluations ». Demander d'abord aux étudiants d'estimer, puis discuter des limites de la transformation.

Estimer le temps horloge de la seule étape d'évaluation de l'implémentation sérialisée actuelle, et expliquer le changement après passage du nombre de redémarrages de 1 à 5, pour juger la priorité d'optimisation. Réponse de référence : 1000 × 100 = 10⁵ évaluations, multiplié par 1 ms donne environ 100 secondes ; avec 5 redémarrages, environ 5 × 10⁵ évaluations, soit environ 500 secondes, le temps horloge augmentant de manière quasi linéaire. Cela montre que les micro-ajustements constants à l'intérieur de l'opérateur ont un bénéfice limité ; la priorité d'optimisation doit porter sur le modèle d'exécution, c'est-à-dire le traitement par lots, la tensorisation et l'ordonnancement parallèle, pour que le temps horloge soit déterminé par le nombre de lots plutôt que par le nombre d'individus.

Si l'on passe à un modèle d'exécution parallèle par lots, quelles conditions limites supplémentaires faut-il considérer pour juger si la transformation vaut la peine. Réponse de référence : premièrement, le coût d'évaluation et l'échelle — si l'évaluation unique descend à la microseconde, ou si la population se réduit à moins de la centaine, les frais d'ordonnancement et de transfert mémoire peuvent dépasser les frais de calcul, le bénéfice parallèle diminue ; deuxièmement, les contraintes sur le nombre de lots et la taille des lots — la taille des lots est limitée par la mémoire GPU, la bande passante mémoire et le temps de calcul par lot, un lot trop grand augmentant le temps par lot et le coût de synchronisation ; troisièmement, la disposition des données et les accès mémoire — si les individus candidats ne peuvent pas être organisés en tenseurs contigus et vectorisables, le traitement par lots sera encore réduit par les accès mémoire non contigus. Globalement, ce n'est que lorsque le nombre d'évaluations et le coût d'une évaluation unique sont tous deux suffisamment grands que le bénéfice de la transformation du modèle d'exécution est significatif.

**Vérification de la compréhension**

Demander à un étudiant choisi au hasard de résumer avec ses propres mots les points clés de cette page, par exemple « pourquoi la boucle sérialisée est un goulot d'étranglement structurel » et « ce qui détermine le temps horloge après parallélisation ». Si l'étudiant ne sait dire que « c'est lent », approfondir sur les deux dimensions : ordre de grandeur et nombre de lots. On peut ajouter la formule de calcul rapide : nombre total d'évaluations ≈ taille de la population × nombre de générations ; temps d'évaluation sérialisé ≈ nombre total d'évaluations × temps d'une évaluation unique. Rappeler de ne pas se concentrer uniquement sur l'intérieur de l'opérateur, et d'utiliser la forme de la courbe pour s'auto-vérifier : une courbe quasi linéaire indique que l'exécution est encore sérialisée, une forme en escalier indique qu'elle est déjà organisée par lots.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer « la sérialisation est un goulot d'étranglement du modèle d'exécution, et après organisation par lots en parallèle le temps horloge est déterminé par le nombre de lots », passer au contenu de conception du graphe de calcul tensorisé et de l'ordonnancement parallèle ultérieur.

**Références**

L'évolution dépend de la diversité, et la diversité implique une charge de calcul énorme. La boucle CPU sérialisée traditionnelle est inefficace pour traiter des dizaines de milliers d'évaluations de candidats.

<a id="lecture-page-5"></a>

### De la liste de candidats au graphe de calcul tensorisé

*Page 5*

> **Objectif de la page :** Les apprenants doivent maîtriser la transformation centrale consistant à passer d'une représentation en liste du processus évolutif à un graphe de calcul tensorisé.

> **Objectif de la page**
>
> Les apprenants doivent maîtriser la transformation centrale consistant à passer d'une représentation en liste du processus évolutif à un graphe de calcul tensorisé, et pouvoir expliquer pourquoi l'évolution nécessite un calcul tensoriel par lots, ainsi que la manière dont la tensorisation modifie l'expression du processus évolutif.

**Points clés de l'enseignement**

- L'évolution dépend de la diversité, nécessitant l'évaluation de dizaines de milliers voire de millions de solutions candidates. Si les candidats sont écrits comme un tableau d'objets ordinaires et évalués par une boucle élément par élément, la majeure partie du temps sera consommée par l'ordonnancement élément par élément et le flux de contrôle du langage hôte, plutôt que par les véritables opérations numériques. C'est là la cause racine de l'inefficacité de la boucle CPU sérialisée traditionnelle. L'ensemble des candidats, les résultats d'évaluation et l'état de l'algorithme sont organisés de manière unifiée en tenseurs. Toute une génération de candidats est écrite comme un tenseur de candidats de forme [taille de la population, dimension de la solution]
- un candidat n'est plus un objet indépendant, mais une tranche ou une ligne du tenseur. L'illustration de la page se déploie également dans cet ordre : à gauche la liste de candidats traitée élément par élément, au milieu le tenseur de candidats, à droite le graphe de calcul avec successivement mutation, évaluation, sélection, mise à jour d'état. Les opérations telles que la mutation agissent directement sur toute la population, un seul appel accomplissant la mise à jour de tous les candidats
- l'évaluation s'écrit evaluate(tenseur de candidats), obtenant en un appel les résultats de toute une génération, l'unité d'évaluation passant de « l'individu » au « lot ». La sélection et la mise à jour d'état ne sont plus seulement une logique de contrôle sérialisée, mais des nœuds du graphe, bénéficiant ainsi d'opportunités d'optimisation par compilation telles que la fusion d'opérateurs et l'ordonnancement parallèle. La logique de l'algorithme, comme la distribution de mutation et la pression de sélection, n'a pas été réécrite
- c'est le mode d'expression qui a été modifié. Il ne s'agit pas simplement de déplacer la boucle vers un appareil plus rapide, mais d'organiser les données et les opérateurs en prenant le tenseur comme unité de traitement minimale. Si l'on persiste à considérer « un candidat = un objet indépendant », même le matériel parallèle le plus large ne pourra être alimenté que de manière sérialisée. La transition clé de cette page peut être résumée par « de la liste de candidats au graphe de calcul tensorisé »
- voir un opérateur par lots, penser « calculer tout le groupe ensemble ».

**Couverture des mots-clés**

- Calcul tensorisé, tenseur de candidats, opérateurs par lots, évaluation par lots, graphe de calcul, optimisation par compilation, taille de la population, dimension de la solution.

**Traitement des exercices**

La réponse à la question à choix multiple 1 doit pointer vers les frais fixes d'ordonnancement élément par élément et de flux de contrôle du langage hôte, et non vers un manque de puissance de calcul ou de diversité. Lors du retour, souligner que plus les candidats sont nombreux, plus cette part de frais est élevée.

Une solution candidate correspond à une tranche du tenseur de candidats, par exemple une ligne ; elle n'est plus liée à un objet indépendant du langage hôte.

La sélection et la mise à jour d'état, une fois entrées dans le graphe de calcul, peuvent bénéficier d'opportunités d'optimisation par compilation telles que la fusion d'opérateurs et l'ordonnancement parallèle, réduisant les tenseurs intermédiaires et les frais de synchronisation.

La sortie d'évaluation est très probablement de forme [taille de la population] ou [taille de la population, nombre d'objectifs] ; l'évaluation produit un ou un ensemble d'indicateurs pour chaque candidat le long de la dimension de population.

EvoX, au niveau de l'expression, remplace le traitement en liste candidat par candidat par un graphe de calcul par lots où le tenseur est citoyen de première classe.

Recherche de 50000 profils d'aile candidats. Le goulot d'étranglement de l'implémentation originale se situe principalement au niveau de l'organisation des données et de l'ordonnancement : accès objet par objet, appels de fonction élément par élément, comparaisons et mises à jour manuelles d'état, et traitement d'un seul candidat à la fois, incapable de remplir la largeur de parallélisme du matériel. La transformation tensorisée ne modifie pas la pression de sélection ni la distribution de mutation, mais unifie les candidats, les résultats d'évaluation et l'état de l'algorithme en tenseurs, permettant à la mutation et à l'évaluation d'agir en une fois sur toute la population. Si l'on souhaite que la sélection et la mise à jour d'état bénéficient également de l'optimisation par compilation, il faut définir le tenseur de candidats comme [50000, 48] ; la sortie d'évaluation comme [50000] ou [50000, nombre d'objectifs] ; la mutation s'applique à tout le tenseur de candidats ; la sélection utilise l'indexation tensorielle ou le masque ;

la mise à jour d'état s'écrit comme un nœud de réduction le long de la dimension de population, comme prendre le minimum ou calculer la moyenne.

**Vérification de la compréhension**

Quelle est la forme du tenseur de candidats ? Quelle est la forme de la sortie d'une évaluation ? Quels sont les deux éléments passés de la logique de contrôle sérialisée à des nœuds de graphe de calcul ? Si les trois points peuvent être répondus, cela indique que la transition clé de cette page est maîtrisée.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent expliquer avec leurs propres mots le changement « de la liste de candidats au graphe de calcul tensorisé », passer aux applications, exemples ou résumés de la page suivante.

<a id="lecture-page-6"></a>

### Organisation tensorisée de la population, de l'évaluation et de l'état

*Page 6*

> **Objectif de la page :** Les apprenants doivent comprendre comment mapper de manière unifiée les données de population, l'évaluation de fitness et les variables d'état en structures tensorielles.

> **Objectif de la page**
>
> Comprendre comment mapper de manière unifiée les données de population, l'évaluation de fitness et l'état d'exécution de l'algorithme en structures tensorielles, formant un contrat de données unifié calculable par lots, résident sur appareil et reproductible.

> **Ordre d'explication**
>
> On commence par trois questions — qu'est-ce que la population, comment est l'évaluation, où en est-on dans l'exécution ; puis on correspond à trois types de conteneurs — tenseur de population [N, D], matrices d'évaluation et de contraintes [N, M] et [N, K], conteneur d'état unifié ; enfin on explique comment l'évaluation par lots et la résidence d'état transforment la boucle individu par individu en opération sur tout le lot.

**Points clés de l'enseignement**

- Organiser les N solutions candidates en un tenseur d'encodage [N, D]. N est la dimension de lot, D est la dimension de caractéristiques ; on place généralement N à l'extérieur pour qu'un même opérateur puisse agir en une fois sur tout le lot. Si un individu est composé de plusieurs segments de paramètres, on peut le diviser en blocs de champs [N, D1] + [N, D2] + …
- les individus de longueur variable sont traités par remplissage avec masque ou par compartimentage, pour éviter que des structures hétérogènes ne brisent le calcul sur tout le lot. Une évaluation par lots produit une matrice de fitness [N, M]
- les objectifs multiples, les contraintes multiples et les indicateurs supplémentaires peuvent être placés côte à côte en [N, M+K] ou stockés dans des tableaux séparés ; l'essentiel est d'éviter les appels en boucle individu par individu à la fonction d'évaluation. Le numéro de génération, l'état du générateur aléatoire, les hyperparamètres de stratégie, la meilleure solution, le cache d'historique, le classement ou l'état d'échantillonnage entrent également dans des tenseurs ou un conteneur d'état structuré, garantissant la reproductibilité, la traçabilité et la mise à jour par lots. Le tenseur unifié permet de réduire les allers-retours entre l'hôte et l'appareil, de diminuer les frais de boucle et de fournir une base de données pour le parallélisme ultérieur des opérateurs
- mais il faut faire attention à la validité des masques, au gaspillage du remplissage, à l'élargissement de la matrice d'évaluation dû à l'augmentation du nombre d'objectifs, et au coût de synchronisation d'état.

> **Indices sur les supports**
>
> - Le diagramme de disposition mémoire place le tenseur de population, la matrice d'évaluation, la matrice de contraintes et le conteneur d'état unifié sous la même sémantique de mémoire d'appareil. On peut rappeler aux apprenants de prêter attention à la flèche « évaluation par lots » qui indique qu'un seul appel traite tout le lot, plutôt qu'un appel individu par individu. Lorsque N=1024, D=50, M=2, la population est [1024, 50], les valeurs d'évaluation sont [1024, 2], les contraintes sont [1024, K]. generation peut être stocké comme scalaire, best_x comme tenseur unidimensionnel [D], rng_state comme tenseur d'entiers de longueur appropriée. Chaque mise à jour de génération peut être accomplie globalement sur la même dimension de lot.

**Traitement des exercices**

La compréhension centrale est « la population, l'évaluation et l'état sont mappés de manière unifiée en structures tensorielles ». Si le choix est correct, cela indique que cette compréhension est cohérente avec le fil conducteur de cette page ; si le choix est incorrect, revenir au début de la page pour revoir le contrat de données unifié.

L'énoncé raisonnable doit souligner que l'évaluation par lots génère [N, M] et [N, K], et non une boucle individu par individu. Il suffit de pouvoir relier la forme matricielle et la base de l'évaluation par lots pour juger.

L'énoncé raisonnable doit indiquer que le numéro de génération, l'état du générateur aléatoire, la meilleure solution, etc. sont également intégrés dans le conteneur d'état unifié, facilitant les points de contrôle et la reproductibilité. Si la réponse se limite à « mettre les données dans un tenseur », rappeler qu'il faut aussi prêter attention à la gestion d'état et à la reproductibilité.

Pour le scénario N=2048, D=100, M=3, K=5, il est recommandé d'utiliser population [2048, 100], évaluation [2048, 3], contraintes [2048, 5] ; les variables d'état comme generation utilisent un tenseur scalaire, best_x utilise [100], rng_state utilise un tenseur d'entiers, le cache d'historique peut utiliser [T, 2048, 100] ou un stockage compressé. Lors de l'évaluation par lots, vectoriser la fonction d'évaluation pour qu'elle accepte [N, D] et retourne [N, M] et [N, K] ; les individus de longueur variable utilisent le remplissage avec masque ou le compartimentage, en ignorant les parties invalides selon le masque après calcul.

**Vérification de la compréhension**

Demander à un apprenant d'expliquer en une phrase pourquoi N doit être la dimension de lot la plus externe, et de citer au moins une variable d'état et pourquoi elle doit être tensorisée. Si la réponse se limite à « mettre les données dans un tenseur », compléter : l'essentiel est le contrat de données unifié et l'exécution des opérateurs sur tout le lot.

> **Indication de transition**
>
> Après avoir confirmé que les apprenants peuvent distinguer les quatre types de conteneurs — population, évaluation, contraintes et état — passer aux exemples, applications ou résumés de la page suivante.

<a id="lecture-page-7"></a>

### Parallélisme des opérateurs et optimisation par compilation

*Page 7*

> **Objectif de la page :** Les apprenants doivent comprendre les mécanismes d'optimisation par compilation sous-jacents lorsque des opérations telles que la mutation et le croisement agissent sur toute la population.

> **Objectif de la page**
>
> Comprendre que dans le socle de calcul moderne d'EvoX, l'unité d'exécution minimale des opérateurs évolutionnaires passe de « l'individu » au « tenseur de population » ; maîtriser comment les opérateurs tensorisés et la compilation du graphe de calcul améliorent le débit de l'évolution par lots, tout en maintenant la sémantique de l'algorithme inchangée.

> **Ordre d'explication**
>
> On commence par établir le jugement « sur qui agit l'opérateur », puis on compare les différences d'exécution entre la boucle individu par individu et les opérateurs au niveau tensoriel, ensuite on explique comment la compilation du graphe de calcul optimise la séquence d'opérateurs en plan d'exécution, et enfin on consolide le principe « l'efficacité change, la sémantique ne change pas » par des cas et des exercices.

**Points clés de l'enseignement**

- 1. La forme du tenseur de population est [N, D], N est la taille de la population, D est la dimension des variables de décision. Les opérateurs tels que la mutation, le croisement, la sélection peuvent agir directement sur tout le tenseur de population, un seul appel couvrant les N individus
- la dimension individuelle sert de dimension de lot, l'appareil peut exécuter massivement en parallèle, le débit augmente avec la taille de la population. 2. L'écriture individu par individu comme for ind in population: ind = mutate(ind) divise chaque opérateur en N petits appels, entraînant des ordonnancements de framework et des lancements de noyaux fréquents
- chaque lot ne valant que 1, les unités parallèles de l'appareil sont difficiles à remplir, et la création et libération répétées de résultats intermédiaires augmentent encore les frais d'allocation de mémoire GPU et de transfert de données. La clé de la transformation est population = mutate(population_tensor), faisant exécuter l'opérateur à l'unité du tenseur de population. 3. La compilation du graphe de calcul organise « mutation → croisement → sélection » en un graphe de calcul, effectuant une optimisation globale sur tout le graphe : la fusion d'opérateurs peut combiner plusieurs opérations élément par élément en moins de noyaux, réduisant les tenseurs intermédiaires et les lectures/écritures
- la génération de noyaux et l'ordonnancement accomplissent toute une génération d'évolution avec moins de lancements de noyaux
- la réutilisation de mémoire pré-planifie des tampons pour les résultats intermédiaires, réduisant les coûts d'allocation et de transfert. L'optimisation ne change que « comment calculer », pas « quoi calculer ». Le nombre de noyaux, la taille des tenseurs intermédiaires, la mémoire et la stratégie d'ordonnancement peuvent changer, mais la signification logique de la mutation, du croisement et de la sélection, l'ordre de combinaison des opérateurs et le mode d'utilisation des nombres aléatoires doivent rester cohérents
- avec la même graine aléatoire, les trajectoires génération par génération et les résultats avant et après optimisation doivent être identiques. Confondre la tensorisation avec un changement d'algorithme évolutionnaire, ou croire que l'optimisation par compilation rend l'algorithme « plus intelligent ». La tensorisation ne fait qu'appliquer le même opérateur à tout le tenseur de population
- l'optimisation par compilation ne porte également que sur la couche d'exécution. Si l'on ne fait pas de validation par régression après optimisation, il est facile de prendre une différence d'implémentation pour une amélioration algorithmique.

> **Indices sur les supports**
>
> - Dans le graphique, à gauche se trouvent le tenseur de population [N, D] et tous les individus, au milieu le graphe de calcul des opérateurs évolutionnaires « mutation → croisement → sélection », à droite la comparaison avant compilation « boucle individu par individu, multiples lancements de noyaux, dimension de lot = 1 » et après compilation « graphe de calcul fusionné, peu de noyaux GPU efficaces, une passe avant par lots accomplissant toute une génération d'évolution ». Ce flux peut aider les étudiants à relier tensorisation et optimisation par compilation.

**Traitement des exercices**

Les exercices de cette page portent sur la granularité d'exécution et la préservation de la sémantique.

Un appel de l'opérateur de mutation agit généralement sur tout le tenseur de population [N, D] ; ce n'est ni le vecteur de valeurs de la fonction objectif, ni le vecteur de décision d'un individu unique.

La boucle Python/CPU individu par individu est lente parce que de nombreux appels de petite taille entraînent des frais d'ordonnancement et de framework, et que la dimension de lot vaut 1, le taux d'utilisation de l'appareil étant faible.

Le principal bénéfice de la fusion d'opérateurs est de combiner plusieurs opérations élément par élément en moins de noyaux, réduisant les tenseurs intermédiaires et le nombre de lancements de noyaux ; elle ne modifie pas la distribution de probabilité ni la signification des opérateurs.

Ne changer que le mode d'exécution, sans modifier la signification logique et l'ordre de combinaison de la mutation, du croisement et de la sélection.

La transformation de population[i] = mutate(ind) doit être remplacée par population = mutate(population_tensor), et la séquence d'opérateurs confiée à l'optimisation par compilation du graphe de calcul ; réduire N, changer la syntaxe de boucle ou utiliser uniquement le multithreading CPU ne résout pas le problème de granularité d'exécution.

En prenant une stratégie d'évolution avec une taille de population N = 4096 et une dimension D = 128 comme exemple, l'implémentation initiale a un taux d'utilisation de l'appareil inférieur à 30%, le temps par génération croît approximativement linéairement avec N, et l'occupation mémoire GPU est élevée. Le diagnostic doit porter sur la granularité d'exécution : la boucle individu par individu amplifie les frais fixes par N, la dimension de lot dégénère à 1, les unités parallèles ne sont pas remplies, les résultats intermédiaires sont créés et libérés de façon répétée. La transformation se fait en trois étapes : première étape, tensoriser les opérateurs pour que la mutation, le croisement et la sélection agissent directement sur le tenseur [N, D] ; deuxième étape, activer la compilation du graphe de calcul pour la fusion d'opérateurs, la génération de noyaux, la réutilisation de mémoire et l'optimisation de l'ordonnancement ; troisième étape, fixer la graine aléatoire pour une validation par régression, comparant les courbes de meilleure fitness par génération et les statistiques de population avant et après optimisation.

Si les courbes se superposent essentiellement, cela indique qu'il ne s'agit que d'un changement de mode d'exécution ; si elles divergent, vérifier d'abord si l'ordre des opérateurs, le nombre d'utilisations des nombres aléatoires ou les règles de sélection ont été modifiés.

**Vérification de la compréhension**

Un opérateur évolutionnaire doit-il agir sur un individu unique ou sur tout le tenseur de population ? Quelle est la chaîne d'équivalence de la fusion d'opérateurs au taux d'utilisation de l'appareil ? Comment vérifier que l'optimisation n'a pas modifié la sémantique de l'algorithme ? Réponse attendue : agir sur le tenseur de population [N, D] ; plus la fusion est importante, moins il y a de lancements de noyaux, moins il y a de lectures/écritures de tenseurs intermédiaires, plus le taux d'utilisation de l'appareil est élevé ; utiliser la même graine aléatoire pour comparer les courbes de meilleure fitness par génération et les statistiques de population avant et après optimisation.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent distinguer tensorisation et compilation de graphe de calcul, et peuvent valider par régression avec la même graine que la sémantique est inchangée, passer aux exemples, applications ou résumés de la page suivante.

<a id="lecture-page-8"></a>

### Conception d'architecture de socle ouverte et découplée

*Page 8*

> **Objectif de la page :** Les apprenants doivent comprendre les principes de conception découplée et la division des composants centraux de l'architecture du socle EvoX.

> **Objectif de la page**
>
> Comprendre les principes de conception du socle ouvert et découplé d'EvoX et la division des responsabilités des cinq modules centraux, et pouvoir utiliser les « frontières de modules » pour déterminer où placer un besoin.

> **Ordre d'explication**
>
> On commence par donner le jugement central — les chercheurs ne doivent pas passer leur temps sur la communication parallèle, l'allocation d'appareils et la tolérance aux pannes distribuée ; puis on introduit les cinq modules de premier niveau, et enfin on utilise le diagramme d'architecture pour expliquer la relation en couches entre la logique évolutive supérieure et l'ordonnancement unifié inférieur.

**Points clés de l'enseignement**

- Le module d'algorithme définit « comment évoluer »
- le module de problème fournit une interface d'évaluation unifiée
- le flux de travail organise l'évolution par étapes
- le module de surveillance observe le processus évolutif
- le planificateur Runtime sert de couche d'exécution unifiée, répondant à « où calculer, comment calculer efficacement ». Formule mnémotechnique : « la logique évolutive en haut, l'ordonnancement de la puissance de calcul en bas », dans l'ordre algorithme → module de problème → flux de travail → module de surveillance → planificateur Runtime. Le module d'algorithme ne décrit que la logique de recherche telle que la sélection, le croisement, la mutation, la mise à jour, sans se lier à un problème spécifique, ni savoir sur quelle carte se trouve le tenseur
- le module de problème encapsule la simulation, la fonction objectif ou l'environnement en une interface d'évaluation unifiée
- le flux de travail détermine l'ordre des étapes telles que l'initialisation, l'évolution itérative, la détermination de convergence
- le module de surveillance collecte les indicateurs, enregistre l'état de la population et les courbes de convergence
- le planificateur Runtime masque les différences entre GPU, appareils d'accélération et clusters distribués, prenant en charge les détails du calcul par lots, du parallélisme et de la communication. L'algorithme et le problème sont mutuellement indépendants, le problème et la puissance de calcul sont mutuellement indépendants. Lors de l'ajout d'un opérateur de mutation, il suffit de modifier le module d'algorithme
- le module de problème continue de fournir l'interface d'évaluation unifiée, le flux de travail et le module de surveillance conservent leur organisation d'origine, le planificateur Runtime accomplit automatiquement le calcul tensoriel par lots et l'allocation d'appareils, le code d'exécution sous-jacent n'a pas besoin d'être modifié. Ainsi, le même socle peut prendre en charge des scénarios tels que l'apprentissage par renforcement, la programmation génétique et l'optimisation combinatoire, évitant la reconstruction répétée d'infrastructures d'ingénierie parallèles, d'ordonnancement et distribuées. Le découplage ne signifie pas nécessairement une baisse de performance. Ce qui affecte réellement la performance est la manière dont le planificateur Runtime traite le calcul par lots et l'utilisation des appareils, et non le nombre de modules. Pour juger si la stratification est efficace, il faut comparer le temps de bout en bout, le taux d'utilisation des appareils et la proportion de communication
- si les frais d'ordonnancement augmentent, il faut optimiser la stratégie de calcul par lots et d'utilisation des appareils du planificateur Runtime, et non réécrire le code parallèle dans le module d'algorithme. Utiliser « faut-il modifier » pour vérifier le découplage. Changer de matériel ou d'échelle de cluster ne doit modifier que le planificateur Runtime
- changer de problème ne doit modifier que le module de problème
- changer d'opérateur ne doit modifier que le module d'algorithme. Si une petite modification affecte plus de trois couches, cela indique que l'implémentation est déjà trop couplée. Le découplage économise l'ingénierie répétitive, pas le temps de calcul ; il faut encore valider par des expériences de référence si les frais d'ordonnancement sont acceptables.

**Traitement des exercices**

L'exclusion parmi les cinq modules centraux (la réponse est « chercheur d'hyperparamètres », qui relève de la configuration expérimentale ou de la stratégie algorithmique, et non d'un module de premier niveau du socle) ; la manifestation précise de la haute cohésion et du faible couplage (la réponse est que la logique interne du module d'algorithme est cohérente et ne se lie pas à un problème spécifique, et que le module de problème ne perçoit pas non plus la puissance de calcul sous-jacente) ; la responsabilité centrale du planificateur Runtime (la réponse est de masquer les différences entre GPU, appareils d'accélération et clusters distribués et d'unifier l'ordonnancement de l'exécution) ; la portée des modifications lors de l'ajout d'un opérateur de mutation (la réponse est qu'il suffit d'implémenter la nouvelle logique dans le module d'algorithme, le problème, le flux de travail, la surveillance et le Runtime restant inchangés) ; la signification la plus directe de l'accès ouvert unifié (la réponse est que chaque domaine réutilise la même infrastructure d'ingénierie).

Lors du retour, demander d'abord aux étudiants de revenir aux « frontières de responsabilité des cinq modules » pour trouver des preuves, puis expliquer pourquoi les autres options brisent les frontières ou confondent les responsabilités.

Dans l'extension d'un cluster GPU multi-nœuds, le module d'algorithme, le module de problème, le flux de travail et le module de surveillance doivent rester inchangés, car leurs responsabilités sont indépendantes de la forme de la puissance de calcul ; ce qui doit être modifié ou reconfiguré est le planificateur Runtime. Si le débat porte sur « écrire manuellement l'allocation d'appareils et la communication dans l'opérateur » ou « dépendre entièrement du planificateur Runtime », l'évaluation clé est de savoir sur quelle couche porte la modification : l'allocation d'appareils et la communication relèvent de la couche d'exécution, les écrire dans l'opérateur couplerait les détails de puissance de calcul dans le module d'algorithme. Le plan de validation consiste à comparer, sur le même problème d'optimisation combinatoire, le temps de bout en bout, le taux d'utilisation des appareils et la proportion de frais de communication entre l'ordonnancement purement Runtime et l'ordonnancement manuel, et à enregistrer le coût de migration vers un autre type de matériel ou une tâche d'apprentissage par renforcement ;

on n'envisage une descente locale que lorsque des bénéfices significatifs et reproductibles peuvent compenser les coûts de couplage et de migration.

**Vérification de la compréhension**

Demander aux étudiants de reformuler avec leurs propres mots les cinq modules et la question à laquelle chacun répond, puis de choisir un besoin et de déterminer quelle couche modifier. Indication de transition : après avoir confirmé que les étudiants peuvent distinguer « logique évolutive » et « ordonnancement de puissance de calcul », passer aux détails d'implémentation de l'évolution parallèle tensorisée ultérieure.

<a id="lecture-page-9"></a>

### Division des modules algorithme et problème

*Page 9*

> **Objectif de la page :** Les apprenants doivent comprendre les responsabilités et les modes d'interaction des modules algorithme et problème dans l'architecture du socle.

> **Objectif de la page**
>
> Comprendre les frontières de responsabilité, le contrat d'interface entre le module d'algorithme et le module de problème dans le socle ouvert et découplé d'EvoX, ainsi que la signification de cette division pour les problèmes multi-objectifs, avec contraintes et à retour coûteux.

> **Ordre d'explication**
>
> On ancre d'abord la division du travail en une phrase — le module d'algorithme répond à « comment rechercher », le module de problème répond à « quoi évaluer, comment l'environnement renvoie le retour ». Puis on déploie les entrées et sorties des deux, et enfin on aboutit à l'extension indépendante, la composabilité et la migrabilité apportées par la stabilité du contrat d'interface.

**Points clés de l'enseignement**

- 1. Le module d'algorithme encapsule la stratégie de recherche et le mécanisme évolutif. Il est responsable de la génération de solutions candidates, de l'initialisation de la population, de la mutation, du croisement, de la sélection, de la préservation des élites, ainsi que du contrôle de recherche tel que le nombre d'itérations, la taille de la population, le redémarrage et les critères de convergence, l'ordonnancement des paramètres d'opérateurs. Le point clé est qu'il ne dépend que du préalable abstrait « les solutions candidates seront évaluées », sans se soucier de la signification physique et de la forme concrète de la fonction objectif. 2. Le module de problème définit les critères d'évaluation et le retour de l'environnement. Il transforme les solutions candidates en retours comparables, tels que valeurs d'objectifs, fitness, violations de contraintes ou résultat d'une interaction avec l'environnement
- il déclare également les dimensions des variables, les plages de valeurs et les règles du domaine réalisable, pour que l'algorithme sache où générer les solutions candidates. Le module de problème donne une évaluation cohérente pour le même lot de solutions candidates, permettant une comparaison transversale entre différents individus, différentes générations voire différents algorithmes. Le module d'algorithme soumet un lot de solutions candidates, le module de problème retourne des résultats d'évaluation structurés (vecteur d'objectifs, violations de contraintes et informations de diagnostic optionnelles), le module d'algorithme met à jour la population et fait avancer la génération suivante sur cette base. Un aller-retour « soumission — retour » constitue une génération d'évolution. L'orientation est importante : le côté algorithme soumet les solutions candidates à évaluer, le côté problème retourne les résultats d'évaluation. Extension indépendante — ajouter ou remplacer un algorithme n'affecte pas la définition du problème, modifier ou ajouter un problème ne nécessite pas de réécrire le module d'algorithme
- composabilité — le même module de problème peut être connecté à différents algorithmes évolutionnaires, le même module d'algorithme peut basculer vers différents modules de problème
- migrabilité — tant que le contrat est stable, les deux côtés peuvent être réutilisés, remplacés et migrés entre tâches. Les problèmes d'ingénierie réels tels que la conception de profil supercritique ont souvent simultanément plusieurs objectifs mutuellement contraignants, des contraintes imbriquées et des retours coûteux et épars. Le module de problème convertit de manière unifiée les objectifs multiples et les contraintes en résultats d'évaluation comparables, en ayant recours si nécessaire à des modèles surrogate pour réduire les coûts
- le module d'algorithme maintient un ensemble de solutions candidates diversifiées, permettant aux experts de faire des compromis de préférence entre portance, traînée et marge de sécurité. Par conséquent, le contrat ne peut pas se contenter de porter une fitness scalaire unique, il doit également porter le vecteur d'objectifs et les violations de contraintes, sinon les informations multi-objectifs et de contraintes seront définitivement perdues au niveau de l'interface.

**Couverture des mots-clés**

- Module d'algorithme, module de problème, lot de solutions candidates, résultats d'évaluation, vecteur d'objectifs, violations de contraintes, contrat d'interface, extension indépendante, composabilité, migrabilité, modèle surrogate. Écrire la fonction objectif, le traitement des contraintes ou les règles heuristiques propres au problème dans le module d'algorithme, ou implémenter la sélection et la mise à jour de la population dans le module de problème, recouplera les deux côtés. La question d'auto-vérification est : « Si je ne modifie que le modèle physique, dois-je seulement remplacer le module de problème ? » La réponse doit être affirmative. L'interface doit être « étroite et complète » : étroite signifie peu de champs et stables, ne transmettant que deux types d'informations — le lot de solutions candidates et les résultats d'évaluation
- complète signifie que les informations clés ne doivent pas être incomplètes, le vecteur d'objectifs, les violations de contraintes, les dimensions des variables et les bornes doivent être préservés. Ne retourner qu'une fitness scalaire unique est le défaut de conception le plus difficile à corriger après coup.

> **Indices d'exercice**
>
> - Les cinq questions à choix multiples vérifient respectivement — qui est responsable de la recherche, la responsabilité centrale du module de problème, la direction du flux de données du contrat, l'extension indépendante après découplage, les conséquences d'une fitness scalaire unique. Les réponses correctes pointent successivement vers : le module d'algorithme génère les solutions candidates et met à jour la population
> - le module de problème transforme les solutions candidates en valeurs d'objectifs, violations de contraintes ou résultats d'interaction avec l'environnement
> - le module d'algorithme produit un lot de solutions candidates, le module de problème retourne les résultats d'évaluation
> - tant que le contrat est inchangé, remplacer l'un des côtés ne nécessite pas de réécrire l'autre
> - la perte d'informations de contraintes empêche l'algorithme d'obtenir un retour de contraintes, les problèmes avec contraintes étant difficiles à traiter correctement. Lors du retour, si l'étudiant répond correctement, lui demander d'expliquer le raisonnement
> - en cas d'erreur, le guider vers « qui recherche, qui évalue » et « le contrat est-il complet » pour rejuger. Lors de la migration d'une optimisation aérodynamique de profil vers l'allègement structurel d'une aile, changer d'algorithme évolutionnaire ne nécessite pas de réécrire le module de problème, car le module de problème ne promet que « entrée : lot de solutions candidates, sortie : résultats d'évaluation », indépendamment du mécanisme interne de sélection, de mise à jour ou de tri de l'algorithme. Pour réutiliser le même algorithme pour la minimisation du poids structurel, le module de problème doit retourner au moins trois types d'informations : valeurs d'objectifs (poids structurel, ou vecteur d'objectifs s'il y a des indicateurs de rigidité), violations de contraintes (degré de dépassement des contraintes de rigidité et de faisabilité géométrique), dimensions des variables et plages de valeurs de l'espace de recherche. Aucune n'est omissible, car l'algorithme n'est responsable que de la recherche, il a besoin des valeurs d'objectifs pour juger la qualité, des violations de contraintes pour distinguer faisable et infaisable, et de bornes cohérentes pour générer des solutions candidates légales.

**Activité en classe**

Demander aux étudiants de reformuler à l'aide des ancres mnémotechniques — module d'algorithme = comment rechercher (génération, mutation, croisement, sélection, contrôle d'itération) ; module de problème = quoi évaluer (valeurs d'objectifs, violations de contraintes, retour de l'environnement). Puis demander à un étudiant de répondre : « Si je ne modifie que le modèle physique, quel côté doit être remplacé ? »

**Vérification de la compréhension**

Demander à un étudiant choisi au hasard d'énoncer avec ses propres mots le flux de données « lot de solutions candidates ⇄ résultats d'évaluation », et d'expliquer pourquoi ne retourner qu'une fitness scalaire unique briserait le traitement des problèmes avec contraintes.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent distinguer recherche et évaluation, et peuvent expliquer que le contrat doit être « étroit et complet », passer aux exemples, applications ou résumés de la page suivante.

<a id="lecture-page-10"></a>

### Gestion des modules de flux de travail et de surveillance

*Page 10*

> **Objectif de la page :** Les apprenants doivent comprendre le rôle du flux de travail et du module de surveillance dans la gestion du processus évolutif.

> **Objectif de la page**
>
> Après cette page, les apprenants doivent pouvoir distinguer les responsabilités du module de flux de travail et du module de surveillance, et expliquer comment ils transforment la boucle évolutive d'une « boîte noire inconnue » en un processus contrôlé, observable, déterminable, intervenable et reproductible.

> **Ordre d'explication**
>
> On établit d'abord la division en une phrase — le flux de travail répond à « dans quel ordre exécuter », la surveillance répond à « où en est-on, est-ce bon, faut-il agir ». Puis on déploie l'ordre, les arêtes de retour et les frontières d'étapes du flux de travail, puis on explique comment la surveillance collecte l'état, expose les indicateurs et pilote les décisions. Enfin on conclut sur les trois frontières de responsabilité et le coût de l'observabilité, et on relie toute la logique avec un exemple d'évolution tensorisée sur GPU.

**Points clés de l'enseignement**

- 1. Le module de flux de travail orchestre les étapes et les dépendances, et non la logique de l'algorithme elle-même. Il définit l'ordre, les arêtes de retour et les frontières d'étapes de « initialisation → évaluation (par lots) → sélection → mutation/croisement → mise à jour d'état → détermination de fin », et relie le module d'algorithme et le module de problème via une interface unifiée. La clé de l'orchestration réside dans la granularité et les frontières : considérer « une évaluation par lots » comme une étape ordonnançable globalement, et non avancer individu par individu
- les frontières d'étapes sont en même temps les points d'échantillonnage de surveillance et les points de basculement d'ordonnancement. 2. Le module de surveillance est la couche de collecte et d'exposition de l'état d'exécution, suivant en continu des indicateurs tels que la taille de la population, le nombre d'évaluations, la distribution de fitness, la convergence et la diversité, le temps par génération, la mémoire GPU et le débit. Mais le but de l'observation n'est pas l'enregistrement, c'est la décision : les indicateurs servent à déclencher la terminaison, l'arrêt précoce, le redémarrage, le changement de paramètres ou de stratégie, formant ainsi une boucle fermée « surveillance → détermination → intervention ». 3. La contrôlabilité exige également que l'état soit sérialisable. La sauvegarde et la restauration de points de contrôle permettent à une évolution longue d'être interrompue et reprise, aux défaillances d'être localisées, aux expériences d'être reproduites. En même temps, le découplage exige que la surveillance soit montée sous forme de rappels ou de hooks, sans intrusion dans les modules d'algorithme et de problème ; ainsi, différents backends de surveillance tels que console, journaux, panneaux de courbes peuvent être interchangeés, sans modification de l'algorithme central. Le flux de travail gère « l'ordre et les étapes », la surveillance gère « l'état et les indicateurs », le planificateur d'exécution gère « les ressources et le mapping parallèle ». L'erreur courante est d'incorporer le mapping des ressources ou la logique de l'algorithme dans le flux de travail, ou d'incorporer le contrôle d'ordre dans la surveillance, entraînant couplage et non-reproductibilité. L'observabilité a aussi un coût : un échantillonnage à haute fréquence et un retour synchrone peuvent interrompre le pipeline parallèle, donc la fréquence d'échantillonnage, le mode d'agrégation des indicateurs et la stratégie d'écriture asynchrone sur disque doivent être pesés selon l'objectif expérimental. Le flux de travail ordonnance « l'évaluation par lots » comme une étape globale
- le module de surveillance enregistre par génération au sein de la même étape la meilleure fitness et la fitness moyenne, la diversité de la population et le temps par génération
- lorsque les indicateurs stagnent pendant N générations consécutives, déclencher la détermination de fin ou basculer vers une stratégie à perturbation plus importante, et synchroniser l'écriture d'un point de contrôle sur disque, rendant cette évolution reproductible et reprenable depuis le point d'interruption.

**Couverture des mots-clés**

- Module de flux de travail, module de surveillance, étapes et dépendances, frontières d'étapes, arêtes de retour, évaluation par lots, observabilité, surveillance→détermination→intervention, point de contrôle, rappel/hook, frontières de responsabilité, coût d'échantillonnage.

> **Indices d'exercice**
>
> - Les exercices de cette page portent sur cinq jugements. L'objet direct de l'orchestration du flux de travail est les étapes et les dépendances, et non les formules d'opérateurs, le mapping mémoire GPU ou l'encodage de la fonction objectif
> - considérer l'évaluation par lots comme une étape globale est plus approprié en termes de granularité et de frontières, les frontières d'étapes assumant simultanément l'échantillonnage de surveillance et le basculement d'ordonnancement
> - le but fondamental de la surveillance est la décision, et non l'archivage a posteriori
> - le montage par rappel ou hook vise le découplage, permettant l'interchangeabilité des backends de surveillance
> - l'observabilité nécessite de peser la fréquence d'échantillonnage, l'agrégation des indicateurs et la stratégie d'écriture sur disque, car un échantillonnage à haute fréquence peut perturber le pipeline parallèle. En cas de bonne réponse, souligner que le raisonnement provient des deux axes « ordre et étapes » et « surveillance→détermination→intervention »
> - en cas d'erreur, revenir aux frontières de responsabilité, en distinguant les quatre types de responsabilités : logique d'algorithme, mapping de ressources, contrôle d'ordre et collecte d'état.

**Vérification de la compréhension**

On peut utiliser le cas « Pause suspecte dans une évolution tensorisée de longue durée » pour vérifier la maîtrise. D'abord utiliser les frontières d'étapes pour décomposer les temps respectifs de l'évaluation par lots, de la sélection, de la mutation et de la mise à jour d'état, et déterminer de quelle étape provient l'augmentation du temps par génération ; puis superposer les deux courbes de stagnation de la fitness moyenne et de baisse de la diversité, pour juger s'il s'agit d'une convergence vers la stabilité ou d'un piège dans un optimum local. Le plan de traitement est organisé selon « surveillance → détermination → intervention » : la couche de surveillance collecte le nombre de générations de stagnation de la fitness, la diversité et le temps par génération ; la couche de détermination fixe « N générations consécutives d'amélioration inférieure au seuil et diversité en dessous de la borne inférieure » comme stagnation, et « temps par génération dépassant le seuil » comme anomalie de ressources ; la couche d'intervention déclenche un changement de stratégie, un arrêt précoce ou un redémarrage, et ajuste la taille des lots ou le mapping parallèle pour l'anomalie de temps.

Avant le traitement, écrire d'abord un point de contrôle sur disque, garantissant la reproductibilité de l'expérience, la localisation des défaillances et la reprise d'une évolution longue depuis le point d'interruption.

> **Indication de transition**
>
> Après avoir confirmé que les apprenants peuvent énoncer « le flux de travail gère l'ordre et les étapes, la surveillance gère l'état et les indicateurs, le planificateur gère les ressources et le mapping parallèle », passer à la page suivante.

<a id="lecture-page-11"></a>

### Planificateur Runtime et gestion de la puissance de calcul hétérogène

*Page 11*

> **Objectif de la page :** Les apprenants doivent maîtriser le rôle central du planificateur Runtime dans l'allocation de matériel hétérogène et la composabilité des algorithmes.

> **Objectif de la page**
>
> Maîtriser la position du planificateur Runtime dans EvoX — c'est le centre d'exécution reliant la logique algorithmique au matériel physique, responsable du mapping des algorithmes évolutionnaires supérieurs, de la définition des problèmes et du flux de travail vers des ressources de calcul hétérogènes telles que GPU, appareils d'accélération (TPU/NPU) et clusters distribués, tout en masquant les différences matérielles et en maintenant la composabilité efficace des modules d'algorithme.

> **Ordre d'explication**
>
> 1. Distinguer d'abord la couche algorithme et la couche exécution. La couche algorithme se concentre sur « quoi faire », le Runtime sur « où le faire, comment le faire ». Cette séparation est la clé pour comprendre l'architecture d'EvoX.
>
> Ordonnancement de puissance de calcul hétérogène, gérant de manière unifiée GPU, appareils d'accélération et clusters distribués, répartissant les tâches, les opérateurs et les graphes de calcul tensoriels vers les backends appropriés ; coordination des dépendances et de l'état, garantissant la synchronisation correcte des relations de dépendance entre tâches et de l'état d'exécution ; interface d'ordonnancement unifiée, permettant à la couche algorithme de soumettre des tâches sans se lier à un appareil spécifique ou à une forme de cluster ; composabilité des modules, supportant la combinaison, le remplacement et la réutilisation modulaires des algorithmes, problèmes, opérateurs et backends d'exécution.
>
> Lors du passage du même ensemble d'algorithmes évolutionnaires d'un GPU monocarte à un cluster multi-machines, le code de la couche algorithme reste inchangé, le Runtime remappant les tâches de calcul et les backends d'exécution. Les chercheurs peuvent ainsi se concentrer sur l'innovation algorithmique, sans réécrire le code pour chaque type de matériel.
>
> La couche supérieure est la couche algorithme et flux de travail (module d'algorithme, définition de problème, flux de travail), au milieu se trouve le planificateur Runtime et l'interface d'ordonnancement unifiée, la couche inférieure est la couche de calcul hétérogène (GPU, TPU/NPU, clusters distribués) ; les tâches, opérateurs et graphes de calcul sont transmis vers le bas, l'état et les résultats sont renvoyés vers le haut.

**Points clés de l'enseignement**

- Le Runtime n'implémente pas la logique de l'algorithme évolutionnaire, ni ne définit la fonction objectif du problème
- sa responsabilité est l'ordonnancement et le mapping. Les ressources d'exécution qu'il gère sont des ressources matérielles, telles que GPU, appareils d'accélération et clusters distribués
- le code source du module d'algorithme appartient à la couche algorithme, ce n'est pas un objet ordonnancé par le Runtime. La couche algorithme n'a qu'à décrire ce qu'il faut faire, sans se soucier du matériel sur lequel le faire, permettant ainsi au même ensemble d'algorithmes de migrer vers un environnement monocarte, multi-cartes ou inter-clusters. La composabilité signifie que les algorithmes, problèmes, opérateurs et backends d'exécution peuvent être librement combinés, remplacés et réutilisés, sans être verrouillés sur un backend matériel unique.

**Couverture des mots-clés**

- Planificateur Runtime, ordonnancement de puissance de calcul hétérogène, coordination des dépendances et de l'état, interface d'ordonnancement unifiée, composabilité des modules, GPU, appareils d'accélération, TPU/NPU, clusters distribués, couche algorithme, couche exécution.

> **Indices sur les supports**
>
> - Cette page est accompagnée d'un diagramme d'architecture du planificateur Runtime reliant les appareils matériels à l'algorithme supérieur. Dans le diagramme, la couche supérieure est la couche algorithme et flux de travail, au milieu le planificateur Runtime et l'interface d'ordonnancement unifiée, la couche inférieure la couche de calcul hétérogène
> - les flèches indiquent la distribution vers le bas des tâches/opérateurs/graphes de calcul, et le retour vers le haut de l'état/résultats. Lors de l'explication du diagramme, on peut demander aux étudiants de reformuler en suivant les flèches « ce que la couche supérieure soumet, ce que le Runtime fait, ce que la couche inférieure retourne ».

**Traitement des exercices**

La réponse correcte à la question à choix multiple 1 est de mapper les algorithmes et flux de travail vers des ressources de calcul hétérogènes et de masquer les différences matérielles. Points de retour : le Runtime est le centre d'exécution, il n'implémente pas la logique algorithmique et ne définit pas le problème.

Le Runtime gère les ressources d'exécution matérielles, le code source appartient au contenu de la couche algorithme.

La réponse correcte à la question à choix multiple 3 est que via l'interface d'ordonnancement unifiée, la couche algorithme n'a pas besoin de se lier à un appareil ou une forme de cluster spécifique. Points de retour : réduire le couplage signifie que la couche algorithme n'a pas besoin d'écrire un code différent pour chaque type de matériel.

La réponse correcte à la question à choix multiple 4 est la combinaison, le remplacement et la réutilisation modulaires des algorithmes, problèmes, opérateurs et backends d'exécution. Points de retour : la composabilité se manifeste par la libre combinaison et le remplacement des composants.

La réponse correcte à la question à choix multiple 5 est de remapper les tâches de calcul et les backends d'exécution, le code de la couche algorithme restant inchangé. Points de retour : le Runtime ajuste dynamiquement le mapping des tâches, la couche algorithme n'a pas besoin d'être modifiée.

Dans le scénario de conception multi-objectifs de profil d'aile, l'équipe optimise simultanément le coefficient de portance et le rapport portance/traînée en croisière, et migre le même code d'algorithme entre un GPU monocarte et un cluster distribué. Pour répondre, s'appuyer sur deux points : premièrement, le Runtime mappe les tâches, opérateurs et graphes de calcul vers les backends matériels concrets via l'interface d'ordonnancement unifiée ; lorsque le matériel change, le code de la couche algorithme reste inchangé, le Runtime remappe et divise le graphe de calcul, et coordonne les dépendances entre tâches et la synchronisation d'état. Deuxièmement, lors de l'ordonnancement, il faut considérer les caractéristiques de calcul et les relations de dépendance des tâches, les capacités matérielles (comme le degré de parallélisme GPU, les frais de communication du cluster), l'exécution parallèle de l'évaluation multi-objectifs et la synchronisation sous retour épars, ainsi que le retour d'état, garantissant un déploiement efficace sur différents matériels sans briser la composabilité.

**Vérification de la compréhension**

Demander aux étudiants d'expliquer avec leurs propres mots « la couche algorithme se concentre sur quoi faire, le Runtime sur où le faire et comment le faire », et d'illustrer par un exemple quelle couche change et quelle couche reste inchangée lors du passage d'un GPU à un cluster. Si les étudiants ne retiennent que les noms de matériel sans expliquer la relation d'ordonnancement et de mapping, les guider vers les relations de flèches du diagramme d'architecture.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer le rôle d'ordonnancement et de mapping du Runtime, et peuvent expliquer la migration inter-matérielle par l'interface unifiée et la composabilité, passer aux exemples, applications ou résumés de la page suivante.

<a id="lecture-page-12"></a>

### Applications multi-domaines supportées par le socle unifié

*Page 12*

> **Objectif de la page :** Les apprenants doivent comprendre comment ce socle unifié supporte un large éventail de tâches telles que l'apprentissage par renforcement, la programmation génétique et l'optimisation combinatoire.

> **Ordre d'explication**
>
> On commence par une phrase pour pointer « socle unifié = accès ouvert + exécution tensorisée + ordonnancement Runtime. Face à "applications multi-domaines", s'auto-vérifier par ces trois questions : par quoi la tâche est-elle接入e ? Comment les solutions candidates sont-elles évaluées par lots ? Qui gère de manière unifiée la puissance de calcul et l'état ? », puis on explique pourquoi c'est important en s'appuyant sur les exemples, illustrations ou mots-clés de la page.

**Points clés de l'enseignement**

- Socle unifié = accès ouvert + exécution tensorisée + ordonnancement Runtime. Face à « applications multi-domaines », s'auto-vérifier par ces trois questions : par quoi la tâche est-elle接入e ? Comment les solutions candidates sont-elles évaluées par lots ? Qui gère de manière unifiée la puissance de calcul et l'état ?
- Le parallélisme des pas d'environnement, l'évolution de structures d'arbres de programmes et le mapping tensoriel discret relèvent de la couche d'adaptation
- le flux d'évaluation, la gestion d'état, l'organisation des opérateurs et l'ordonnancement relèvent de la couche partagée. Si l'on écrit directement une structure propre à un domaine dans la logique d'ordonnancement partagée, cela indique que le niveau d'abstraction choisi est erroné.
- Cette page ne répond qu'à « ce que le socle unifié peut supporter ». Face à des questions telles que le débit, les frais d'ordonnancement, les détails d'implémentation des tenseurs par lots, les placer d'abord dans le champ d'apprentissage ultérieur sur l'efficacité de calcul et les méthodes tensorielles par lots, sans s'y attarder ici.

Applications multi-domaines supportées par le socle unifié

11

AI999

Socle de calcul moderne et évolution parallèle tensorisée

Les tâches de contrôle et de décision nécessitent une interaction continue avec un environnement en constante évolution, les tâches de conception structurelle nécessitent une recherche dans un espace de programmes et d'expressions de longueur variable, et les tâches d'allocation de ressources et de planification de trajectoire nécessitent une résolution dans des permutations et contraintes discrètes. Si l'on reconstruit un système séparé pour chaque type de problème, l'interface d'évaluation, le stockage d'état, la bibliothèque d'opérateurs et l'ordonnancement de puissance de calcul devraient tous être réimplémentés, le coût de migration d'ingénierie étant extrêmement élevé. L'idée centrale du socle unifié est de porter ces tâches hétérogènes avec la même infrastructure évolutionnaire, permettant aux applications multi-domaines de partager l'évaluation, l'état, les opérateurs et la gestion de la puissance de calcul.

Accès ouvert (accéder aux tâches via une spécification d'enregistrement et d'interface unifiée), exécution tensorisée (organiser les solutions candidates en lots, évaluation parallèle par lots), ordonnancement à l'exécution (répartir les tâches sur la puissance de calcul hétérogène et maintenir l'état). Les trois garantissent ensemble la réutilisation inter-domaines, et expliquent aussi pourquoi la capacité « fournit un socle d'accès ouvert unifié pour l'apprentissage par renforcement, la programmation génétique et l'optimisation combinatoire » mérite une discussion séparée.

Applications multi-domaines supportées par le socle unifié Même socle d'accès ouvert · Partage du flux d'évaluation, de la gestion d'état, de l'organisation des opérateurs et de l'ordonnancement de puissance de calcul Capacités du socle / Domaines de tâches Apprentissage par renforcement Programmation génétique Optimisation combinatoire Accès ouvert Interface d'accès à l'environnement Accès à la structure de programme Accès aux solutions et contraintes Interaction parallèle avec l'environnement Échantillonnage par lots de multiples environnements — — Évolution de structures d'arbres de programmes — Mutation / croisement — Résolution tensorisée Évaluation par lots de stratégies Tensorisation de structures Lots de candidats et contraintes Ordonnancement Runtime et gestion d'état Ordonnancement et état partagés Ordonnancement et état partagés Ordonnancement et état partagés Couche d'adaptation : absorber les différences de domaine — Parallélisme des pas d'environnement · Évolution de structures d'arbres de programmes · Mapping tensoriel discret Socle unifié : accès ouvert · exécution tensorisée · ordonnancement Runtime et gestion d'état Comment trois types de tâches typiques se ramènent au même socle Apprentissage par renforcement : le socle fournit une capacité d'interaction parallèle avec l'environnement, supportant l'échantillonnage par lots de multiples instances d'environnement, l'évaluation parallèle par lots de stratégies candidates, et formant une boucle fermée avec l'optimisation évolutionnaire.

Le socle supporte l'évolution de structures à longueur variable et hiérarchiques telles que les arbres de programmes, pouvant traiter la représentation structurelle et ses mutations, croisements dans un flux unifié de population et d'évaluation. Optimisation combinatoire : adapter les décisions discrètes, sélections, permutations et objectifs de contraintes en résolution tensorisée, améliorant le débit de recherche par lots de candidats et évaluation parallèle. Ce qui est partagé, ce qui est adapté Les différences de domaine sont absorbées par la couche d'adaptation : l'apprentissage par renforcement met l'accent sur le parallélisme des pas d'environnement, la programmation génétique sur l'évolution de structures d'arbres de programmes, l'optimisation combinatoire sur le mapping des décisions discrètes vers les tenseurs. Les trois partagent l'ordonnancement Runtime et la gestion d'état sous-jacents — partage du flux d'évaluation, du support d'état, du mode d'organisation des opérateurs et de la gestion de la puissance de calcul, plutôt que de reconstruire un système pour chaque type de problème.

Si l'on écrit directement une structure propre à un domaine dans la logique d'ordonnancement partagée, cela indique que le niveau d'abstraction choisi est erroné. Portée de cette page Cette page se concentre sur « ce que le socle unifié peut supporter », sans développer les comparaisons de performance concrètes ni les détails d'implémentation du planificateur ; ces derniers sont laissés à la discussion ultérieure sur l'efficacité de calcul et les méthodes tensorielles par lots.

Quelle est la valeur première d'un socle d'accès ouvert unifié ?

Permettre à différents domaines de réutiliser l'évaluation, l'état, les opérateurs et la gestion de la puissance de calcul, réduisant significativement le coût de migration d'ingénierie

Remplacer l'apprentissage par renforcement, la programmation génétique et l'optimisation combinatoire par un algorithme unifié

Compresser toutes les tâches en une même représentation vectorielle de longueur fixe

Reconstruire un système et une chaîne d'outils indépendants pour chaque nouveau type de problème

Les formes de tâches diffèrent, mais la spécification d'accès, l'évaluation par lots, la gestion d'état et l'ordonnancement de puissance de calcul peuvent être partagés ; un nouveau problème n'a qu'à décrire ses différences dans la couche d'adaptation.

« Reconstruire un système pour chaque type de problème » est précisément le problème que le socle veut résoudre ; en même temps, le socle n'exige pas que toutes les tâches partagent le même algorithme ou la même représentation, les différences étant absorbées par la couche d'adaptation.

Correct. Cette réponse peut relier les concepts de cette page et expliquer le raisonnement.

Revenir à l'explication de cette page, trouver les preuves ou exemples clés avant de juger.

Dans le scénario d'apprentissage par renforcement, quelle capacité clé le socle unifié fournit-il principalement ?

Les opérateurs de mutation et croisement d'arbres de programmes

Le pas sérialisé ne supportant qu'une seule instance d'environnement

L'échantillonnage par lots de multiples instances d'environnement avec collecte de trajectoires, et l'évaluation parallèle par lots de stratégies candidates

L'interface de modélisation des permutations et contraintes discrètes

Plusieurs instances d'environnement avancent simultanément, les trajectoires sont collectées par lots, les stratégies candidates évaluées en parallèle, formant ainsi une boucle fermée avec l'optimisation évolutionnaire.

L'évolution de structures d'arbres de programmes est un point d'adaptation de la programmation génétique, la modélisation de contraintes discrètes un point d'adaptation de l'optimisation combinatoire ; la clé de l'apprentissage par renforcement est le parallélisme par lots de l'interaction avec l'environnement, et non le pas sérialisé sur une seule instance.

Lorsqu'une tâche de programmation génétique accède au socle unifié, quelle caractéristique clé le socle doit-il supporter ?

Ne traiter que des vecteurs de réels de longueur fixe

La représentation et l'évolution de structures à longueur variable et hiérarchiques telles que les arbres de programmes, y compris la mutation et le croisement structurels

Devoir encoder de force les arbres de programmes en chaînes binaires de longueur fixe avant l'évolution

Ne pouvoir traiter que des fonctions objectifs continues sans contraintes

Les solutions candidates de la programmation génétique sont des structures de programmes à longueur variable et hiérarchiques ; le socle doit accueillir cette représentation dans un flux unifié de population et d'évaluation, et supporter les mutations et croisements correspondants.

Les vecteurs de longueur fixe sont la représentation typique de l'optimisation continue ; la caractéristique centrale de la programmation génétique est précisément la structure d'arbre de programme à longueur variable et hiérarchique, ainsi que les opérations d'évolution ciblant cette structure.

Lorsqu'une tâche d'optimisation combinatoire accède au socle unifié, quel est le travail d'adaptation le plus critique ?

Supprimer toutes les contraintes et ne garder qu'un seul objectif

Réécrire le problème en une tâche d'entraînement de réseau de neurones continu et différentiable

Compiler un solveur dédié séparé pour chaque instance de problème

Adapter les décisions discrètes, sélections, permutations et objectifs de contraintes en résolution tensorisée

Les solutions candidates et les contraintes sont organisées en lots, réutilisant ainsi la capacité de candidats par lots et d'évaluation parallèle du socle.

Compiler un solveur dédié par instance équivaut à revenir à l'ancienne voie de « reconstruire le système » ; abandonner les contraintes modifie aussi le problème lui-même, ni l'un ni l'autre n'étant l'adaptation exigée par le socle.

Concernant la division du travail entre couche partagée et couche d'adaptation, laquelle des compréhensions suivantes est correcte ?

La logique d'ordonnancement doit être écrite séparément pour l'apprentissage par renforcement, la programmation génétique et l'optimisation combinatoire

La couche d'adaptation ne fait que de l'affichage d'interface, sans participer à aucune conversion sémantique de tâche

La couche partagée est responsable de l'évolution de structures d'arbres de programmes, la couche d'adaptation du pas d'environnement

Les différences de domaine sont absorbées par la couche d'adaptation, les trois types de tâches partageant l'ordonnancement Runtime et la gestion d'état sous-jacents

Le parallélisme des pas d'environnement, l'évolution de structures d'arbres de programmes et le mapping tensoriel discret relèvent de la couche d'adaptation ; le flux d'évaluation, la gestion d'état, l'organisation des opérateurs et l'ordonnancement relèvent de la couche partagée.

Écrire une structure propre à un domaine dans la logique d'ordonnancement partagée, ou laisser la couche partagée traiter l'évolution structurelle propre à un domaine, sont des erreurs de division des niveaux.

Un même runtime porte trois types de tâches hétérogènes

Lire le scénario et répondre aux questions.

Une équipe d'algorithmes construit une plateforme de calcul évolutionnaire. Auparavant, elle maintenait trois systèmes indépendants pour le contrôle par apprentissage par renforcement, la régression symbolique (recherche de structure de programme) et la planification de trajectoire logistique : chacun avait sa propre interface d'évaluation, son stockage d'état et son ordonnancement de puissance de calcul, avec une duplication de code importante ; changer de tâche nécessitait de réécrire tout le flux. La nouvelle solution consiste à porter ces trois types de tâches sur un socle unifié : la tâche d'apprentissage par renforcement fait avancer en parallèle plusieurs instances d'environnement et collecte les trajectoires ; la tâche de programmation génétique évalue en parallèle des populations d'arbres de programmes ; la tâche d'optimisation combinatoire organise les solutions candidates et les contraintes en lots tensoriels, l'ordonnancement unifié répartissant la puissance de calcul hétérogène.

1. Pourquoi l'équipe abandonne-t-elle la maintenance de systèmes séparés pour chaque type de problème ? Expliquer du point de vue de la réutilisation et du coût de migration.

Accès aux tâches, évaluation par lots des solutions candidates, gestion d'état des candidats et de la population, organisation des opérateurs et ordonnancement de la puissance de calcul. Maintenir séparément signifie que ces capacités sont implémentées trois fois de manière répétée, toute nouvelle tâche devant reconstruire tout le flux, le coût de migration d'ingénierie étant très élevé. Le socle unifié permet aux trois types de tâches de réutiliser le même flux d'évaluation, support d'état, mode d'organisation des opérateurs et gestion de la puissance de calcul ; une nouvelle tâche n'a qu'à décrire ses propres différences dans la couche d'adaptation pour être接入e.

2. Indiquer les différences que les trois types de tâches absorbent respectivement dans la couche d'adaptation, et expliquer ce qu'elles réutilisent dans la couche partagée.

L'apprentissage par renforcement met l'accent sur le parallélisme des pas d'environnement (échantillonnage par lots de multiples instances d'environnement, collecte de trajectoires et évaluation par lots de stratégies) ; la programmation génétique sur la représentation et l'évolution de structures à longueur variable et hiérarchiques telles que les arbres de programmes (mutation et croisement structurels) ; l'optimisation combinatoire sur le mapping des décisions discrètes, sélections, permutations et objectifs de contraintes en résolution tensorisée. Réutilisation par la couche partagée : spécification d'accès ouvert, exécution tensorisée par lots, ordonnancement Runtime et gestion d'état, ainsi que l'allocation unifiée de puissance de calcul hétérogène. C'est précisément parce que les différences sont rassemblées dans la couche d'adaptation et les points communs enfouis dans la couche partagée qu'il n'est pas nécessaire de reconstruire un système pour chaque type de problème.

Retenir d'abord les trois piliers

Socle unifié = accès ouvert + exécution tensorisée + ordonnancement Runtime. Face à « applications multi-domaines », s'auto-vérifier par ces trois questions : par quoi la tâche est-elle接入e ? Comment les solutions candidates sont-elles évaluées par lots ? Qui gère de manière unifiée la puissance de calcul et l'état ?

Distinguer couche partagée et couche d'adaptation

Le parallélisme des pas d'environnement, l'évolution de structures d'arbres de programmes et le mapping tensoriel discret relèvent de la couche d'adaptation ; le flux d'évaluation, la gestion d'état, l'organisation des opérateurs et l'ordonnancement relèvent de la couche partagée. Si l'on écrit directement une structure propre à un domaine dans la logique d'ordonnancement partagée, cela indique que le niveau d'abstraction choisi est erroné.

Les limites de cette page

Cette page ne répond qu'à « ce que le socle unifié peut supporter ». Face à des questions telles que le débit, les frais d'ordonnancement, les détails d'implémentation des tenseurs par lots, les placer d'abord dans le champ d'apprentissage ultérieur sur l'efficacité de calcul et les méthodes tensorielles par lots, sans s'y attarder ici.

step-1

Les apprenants doivent comprendre comment ce socle unifié supporte un large éventail de tâches telles que l'apprentissage par renforcement, la programmation génétique et l'optimisation combinatoire.

lesson_4

lesson_4_slide_11

Extrait du brouillon EvoClass

Fournit un socle d'accès ouvert unifié pour l'apprentissage par renforcement, la programmation génétique et l'optimisation combinatoire

lesson_id_distribution

67ee25ab22558e4ae0e13f24b7c34c2da1218107cceb1cd331b38fc3521a9743

**Références**

Extrait du brouillon EvoClass (page 4-4)

> **Indices sur les supports**
>
> - Fournit un socle d'accès ouvert unifié pour l'apprentissage par renforcement, la programmation génétique et l'optimisation combinatoire

**Activité en classe**

Demander de reformuler le contenu de cette page à l'aide d'un exemple proche de l'expérience des étudiants, et leur faire expliquer la relation entre cet exemple et « socle unifié = accès ouvert + exécution tensorisée + ordonnancement Runtime. Face à "applications multi-domaines", s'auto-vérifier par ces trois questions : par quoi la tâche est-elle接入e ? Comment les solutions candidates sont-elles évaluées par lots ? Qui gère de manière unifiée la puissance de calcul et l'état ? ».

> **Objectifs correspondants**
>
> - Maîtriser la méthode d'expression du processus évolutif en calcul tensoriel par lots
> - Comprendre le rôle du Runtime dans l'ordonnancement de la puissance de calcul hétérogène et le maintien de la composabilité des algorithmes

**Vérification de la compréhension**

Demander à un étudiant choisi au hasard de résumer avec ses propres mots les points clés de cette page, l'enseignant complétant les mots-clés manquants selon la réponse.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer la relation centrale de cette page, passer aux exemples, applications ou résumés de la page suivante.

<a id="lecture-page-13"></a>

### Pratique d'analyse comparative de l'efficacité de calcul

*Page 13*

> **Objectif de la page :** Les apprenants doivent comprendre par une comparaison pratique la différence d'efficacité entre le parcours sérialisé CPU et le traitement par lots tensoriel GPU.

> **Objectif de la page**
>
> Ancrer la comparaison d'efficacité de calcul dans une pratique reproductible, comprendre la différence d'efficacité de bout en bout entre le parcours sérialisé individu par individu sur CPU et le traitement par lots tensoriel sur GPU, et clarifier d'où vient l'accélération, quel en est le coût et où sont les limites.

> **Ordre d'explication**
>
> On donne d'abord les deux lignes de base sur la même tâche d'évolution, puis on examine le diagramme à barres de comparaison d'efficacité, ensuite on présente le protocole de mesure reproductible, et enfin on résume les sources de gain, les conditions de contrainte et les conclusions pratiques.

**Points clés de l'enseignement**

- Utiliser une boucle pour appeler la fonction d'évaluation individu par individu, chaque génération nécessitant N ordonnancements indépendants, mises à jour d'état et agrégations de résultats. Le contrôle de boucle, les frais d'interpréteur et les accès mémoire dispersés diluent la puissance de calcul effective
- plus les individus sont nombreux, plus la part de ces coûts non calculatoires est élevée. Organiser la population, les entrées d'évaluation et l'état d'exécution en tenseurs, exécuter en lots l'évaluation et les opérateurs sur GPU, un seul appel couvrant tout l'ensemble de candidats, réduisant considérablement les boucles sérialisées et les ordonnancements. Dans les conditions de même problème, même population, même graine aléatoire, et après préchauffage et synchronisation d'appareil avant chronométrage, la boucle sérialisée CPU est la référence 1.0×, le traitement par lots GPU b=64 environ 2.2×, b=256 environ 4.5×, b=1024 environ 7.1×. Le graphique montre les valeurs relatives du temps par génération ; plus la taille de lot est grande, plus les frais fixes sont faciles à amortir. Problème, taille de population, nombre de générations et graine aléatoire fixés
- enregistrer le temps réel par génération, le temps total, le débit (évaluations/seconde), le ratio d'accélération, le taux d'utilisation GPU et l'occupation mémoire GPU. Pré Lacunaire : Pré Lacunaire.
- le point de chronométrage doit effectuer une synchronisation d'appareil
- les temps de calcul et de transfert de données hôte—appareil sont comptés séparément. Sans l'un ou l'autre de ces éléments, le ratio d'accélération peut être faussé. Le gain provient du parallélisme par lots, des opérateurs tensorisés et du parallélisme interne à l'appareil, permettant à un seul appel de traiter tout l'ensemble de candidats
- les contraintes comprennent la taille de lot, la dimension du problème, le degré de vectorisabilité de la fonction d'évaluation, les frais de copie hôte—appareil et les frais de lancement de noyaux. Un lot trop petit verra ses gains absorbés par les frais de lancement
- si la fonction d'évaluation ne peut pas être vectorisée, le traitement par lots ne peut presque pas s'exprimer. L'ordre correct est de vérifier d'abord si la fonction d'évaluation peut être traitée par lots, puis de comparer les implémentations CPU et GPU. L'avantage d'efficacité doit finalement se traduire par « obtenir plus de générations ou plus de solutions candidates sous le même budget de calcul », et c'est sur cette base que l'on décide du mode de déploiement et de la conception expérimentale, plutôt que de poursuivre uniquement le chiffre du ratio d'accélération.

**Traitement des exercices**

La réponse correcte à la question 1 est « les frais d'ordonnancement, d'interpréteur et d'accès mémoire dispersés entraînés par l'appel indépendant de la fonction d'évaluation pour chaque individu ». La ligne de base sérialisée génère N ordonnancements et mises à jour d'état indépendants par génération, le contrôle de boucle, les frais d'interpréteur et les accès mémoire dispersés diluent la puissance de calcul effective ; à ce stade il n'y a pas encore de lancement de noyaux GPU ni de copie.

La réponse correcte à la question 2 est d'organiser la population, les entrées d'évaluation et l'état d'exécution en tenseurs, un seul appel couvrant tout l'ensemble de candidats. Le cœur de l'accélération est le parallélisme par lots et la tensorisation, et non un changement de précision, de taille de population ou de nombre de graines.

Le protocole normatif de la question 3 est de fixer le problème, la taille de population, le nombre de générations et la graine, de préchauffer et d'effectuer une synchronisation d'appareil avant le chronométrage, et de distinguer le temps de calcul du temps de transfert de données.

Le GPU exécute souvent de manière asynchrone ; sans synchronisation, le chronométrage peut manquer des calculs non encore terminés, entraînant une sous-estimation du temps et un ratio d'accélération gonflé ; la synchronisation elle-même n'augmente pas la puissance de calcul et n'élimine pas le transfert de données.

Lorsque la fonction d'évaluation est peu vectorisable, l'avantage du traitement par lots GPU diminue nettement, et peut même être limité par les frais de copie et de lancement de noyaux ; l'accélération n'est pas constante et n'augmente pas sans limite avec la taille de lot.

Pratique du cas :

1. Le ratio d'accélération d'environ 9× obtenu sans synchronisation d'appareil est très probablement non fiable. L'hôte, après avoir envoyé le noyau, ne l'attend pas pour continuer l'exécution ; si le point de chronométrage n'est pas synchronisé, le temps mesuré peut ne couvrir que la phase d'envoi du noyau, manquant le calcul réel encore en cours, entraînant une grave sous-estimation du temps GPU et un ratio d'accélération gonflé. La correction consiste à : appeler la synchronisation d'appareil à chaque point de chronométrage, pour s'assurer que tout le travail envoyé est réellement terminé avant de lire l'horodatage ; effectuer d'abord des itérations de préchauffage, et compter séparément le temps de transfert de données hôte—appareil et le temps de calcul pur. Seuls le temps par génération et le temps total mesurés à graine fixe, avec préchauffage et synchronisation, peuvent servir de base fiable.

2. Un ratio d'accélération d'environ 1,2× avec un petit lot b=8 n'est pas contradictoire. Le gain du traitement par lots est contraint conjointement par la taille de lot, les frais de lancement de noyaux et les frais de transfert de données ; lorsque le lot est trop petit, la charge de travail parallélisable sur l'appareil est insuffisante, les frais fixes représentant une proportion importante du temps par génération, le degré de parallélisme effectif ne peut amortir ces coûts, et le ratio d'accélération se rapproche naturellement de 1. Il est recommandé d'augmenter la taille de lot dans la limite de la mémoire GPU, de vectoriser autant que possible l'ensemble de la fonction d'évaluation et de la logique de post-traitement, et de remesurer selon le protocole normatif, en rapportant séparément le temps par génération, le temps total, le débit et le ratio d'accélération, afin de juger si le gain se traduit réellement par l'obtention de plus de générations ou plus de candidats sous le même budget.

**Vérification de la compréhension**

Demander à un étudiant choisi au hasard d'expliquer avec ses propres mots pourquoi il faut d'abord vérifier que la fonction d'évaluation est vectorisable avant de comparer CPU et GPU ; et d'expliquer ce que le préchauffage et la synchronisation d'appareil résolvent respectivement.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent distinguer les sources de gain et les conditions de contrainte, et peuvent convertir l'accélération en gain de budget, passer aux exemples, applications ou résumés de la page suivante.

<a id="lecture-page-14"></a>

### Méthodes centrales du calcul tensoriel par lots

*Page 14*

> **Objectif de la page :** Les apprenants doivent consolider les méthodes centrales d'expression du processus évolutif en calcul tensoriel par lots.

> **Objectif de la page**
>
> Consolider les méthodes centrales d'expression du processus évolutif en calcul tensoriel par lots, comprendre la relation entre la dimension de lot, les opérateurs par lots, l'optimisation du graphe de calcul et les indicateurs de débit, et pouvoir identifier la pseudo-tensorisation par lots.

> **Ordre d'explication**
>
> Le tenseur de candidats X est [N × D], les objectifs et contraintes F sont [N × M], la sortie d'évaluation Y est [N × M] ; la dimension de lot N est toujours à l'extérieur, D et M décrivent le nombre de variables et le nombre de termes objectifs d'un seul candidat.
>
> Mapper de manière unifiée la population, les objectifs/contraintes, la sortie d'évaluation et l'état évolutif en tenseurs avec dimension de lot, les quantités d'état étant maintenues par des scalaires ou de petits tampons tensoriels, plutôt qu'enregistrées individu par individu dans des objets Python.
>
> Mutation X′ = X + σ·randn(X), croisement par appariement et recombinaison le long de la dimension N, sélection idx = topk(F, k), évaluation Y = fθ(X). L'important n'est pas l'expression individuelle, mais que tous les candidats partagent le même graphe d'opérations tensoriel, un seul appel par lots remplaçant N appels par candidat unique ; les contraintes et dépassements peuvent être traités dans le même calcul par lots avec un tenseur de masque.
>
> La fusion d'opérateurs réduit les lancements de noyaux, le parallélisme intra-lot fait exécuter tous les candidats simultanément, l'exécution asynchrone chevauche calcul et transfert, la réutilisation de mémoire réduit les allocations de tenseurs intermédiaires.
>
> Passer de la latence par étape aux candidats/seconde ou générations/seconde, car un seul appel par lots porte tout le lot de candidats, et c'est le débit global qui reflète l'efficacité de la recherche.
>
> Intégrer des opérateurs par lots dans une boucle Python individu par individu réintroduit les frais d'interpréteur et de lancement de noyaux, la dimension de lot devenant purement nominale. Méthode d'auto-vérification : dans une étape d'évolution, le niveau d'ordonnancement ne doit comporter que le « lot », pas l'« individu ».

**Points clés de l'enseignement**

- La dimension de lot N est le nombre de candidats ; lorsque les formes correspondent, la mutation, le croisement, la sélection et l'évaluation peuvent tous s'exécuter directement par lots le long de la dimension N. Le gain direct de la tensorisation provient de la réduction du nombre d'appels et des frais d'ordonnancement, et non d'un changement du nombre de candidats ou d'une amélioration de la précision ponctuelle. randn(X) génère un tenseur de perturbation aléatoire de même forme que X, la perturbation étant élément par élément, σ contrôlant l'intensité. topk(F, k) sélectionne le long de la dimension de lot N les indices des k premiers candidats, l'objet de la sélection étant les candidats et non les variables ou les termes objectifs. L'exécution par lots modifie la position du goulot d'étranglement de performance ; la latence reste mesurable, mais l'efficacité à l'échelle se mesure par le nombre de candidats ou de générations accomplis par unité de temps.

**Couverture des mots-clés**

- Calcul tensoriel par lots, dimension de lot N, contrat de forme, opérateurs par lots, optimisation du graphe de calcul, débit, candidats/seconde, générations/seconde, pseudo-tensorisation par lots.

> **Indices sur les supports**
>
> - L'illustration de cette page a pour thème « processus évolutif → graphe de calcul tensoriel par lots », en trois colonnes : ① organisation tensorisée, ② opérateurs par lots, ③ optimisation par compilation et débit. Le tableau noir ou la carte mentale peut se déployer selon ces trois colonnes, en mettant en avant dans la troisième colonne l'indicateur de débit « candidats/seconde · générations/seconde ».

> **Indices d'exercice**
>
> - 5 questions à choix multiples vérifient respectivement le contrat de forme, le gain de performance de la tensorisation, la signification de l'expression de mutation, la sémantique de la sélection topk, la raison du changement d'indicateur. Le retour de réponse peut souligner : en cas de bonne réponse, relier le contrat de forme ou le mode d'appel pour expliquer le raisonnement
> - en cas d'erreur, revenir à l'explication de cette page, trouver les preuves clés avant de juger. L'étude de cas « Migrer une boucle d'évolution individu par individu vers une exécution tensorielle par lots » demande d'expliquer comment organiser candidats, objectifs et état en tenseurs et traiter par lots le long de N, ainsi que le compromis entre optimisation du graphe de calcul et mémoire GPU insuffisante. Les points de réponse comprennent X:[N×D], F:[N×M], Y=fθ(X), état en scalaires ou petits tampons tensoriels
> - mutation, croisement, sélection, évaluation exécutés par lots le long de la dimension N
> - l'optimisation peut faire fusion d'opérateurs, parallélisme intra-lot, exécution asynchrone, réutilisation de mémoire
> - en cas de mémoire GPU insuffisante, on peut utiliser un découpage en blocs ou une exécution par petits lots, réduire la précision numérique, raccourcir le cycle de vie des tenseurs intermédiaires, mais tous les candidats d'une même génération doivent conserver un critère de comparaison cohérent.

**Activité en classe**

Demander aux étudiants d'expliquer avec leurs propres mots « pourquoi la dimension de lot N doit être à l'extérieur », et de donner un exemple simple, comme N=4, D=3, M=2, en écrivant les formes de X, F, Y, et en expliquant comment un seul appel par lots remplace plusieurs appels par candidat unique.

**Vérification de la compréhension**

Demander aux étudiants de résumer le contrat de forme, d'indiquer une écriture de pseudo-tensorisation par lots, et d'expliquer pourquoi l'indicateur passe de la latence par étape au débit. Si les étudiants ne peuvent que répéter les termes sans expliquer le changement du nombre d'appels et du niveau d'ordonnancement, revenir à la partie sur les opérateurs par lots et les erreurs courantes.

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent énoncer la relation entre contrat de forme et exécution par lots, passer aux applications, résumés ou discussions plus complexes sur l'optimisation du graphe de calcul de la page suivante.

<a id="lecture-page-15"></a>

### Ordonnancement Runtime et composabilité des algorithmes

*Page 15*

> **Objectif de la page :** Les apprenants doivent consolider la compréhension centrale du Runtime dans l'ordonnancement de la puissance de calcul hétérogène et la composabilité des algorithmes.

> **Objectif de la page**
>
> Établir la position de couche intermédiaire du Runtime — ce n'est pas un algorithme concret, mais une couche d'ordonnancement et d'abstraction faisant le lien : vers le haut, elle supporte la combinaison flexible des algorithmes, problèmes et flux de travail, vers le bas, elle gère la puissance de calcul hétérogène telle que CPU et GPU, maintenant ainsi la composabilité des algorithmes et l'indépendance matérielle.

> **Ordre d'explication**
>
> On donne d'abord le jugement de « couche intermédiaire » ; puis on décompose les objets d'ordonnancement, les ressources hétérogènes et les mécanismes de découplage ; ensuite on explique les gains et les coûts de la composabilité ; enfin on vérifie la compréhension par un exemple de remplacement d'algorithme et des exercices.

**Points clés de l'enseignement**

- Selon l'état du flux de travail et du module de surveillance, ordonnancer les tâches telles que la population, l'évaluation et les opérateurs vers les appareils appropriés, gérant de manière unifiée l'exécution parallèle et l'utilisation des ressources. Il reprend les modules d'algorithme, de problème et de flux de travail, et appelle vers le bas CPU, GPU, accélérateurs. Les algorithmes, problèmes et opérateurs se combinent via des interfaces modulaires, sans se lier directement au matériel sous-jacent, aux stratégies parallèles ou aux détails de compilation. Ainsi, remplacer des algorithmes tels que DE, PSO ou changer de problème d'optimisation ne nécessite pas de réécrire le code parallèle GPU/CPU sous-jacent. Les différences d'appareils, l'exécution tensorisée et l'optimisation par compilation sont absorbées par le Runtime, la couche algorithme restant indépendante de l'appareil, facilitant le remplacement et la réutilisation. L'abstraction entraîne des frais d'ordonnancement et de transfert de données, nécessitant un équilibre entre flexibilité, performance et complexité d'ingénierie, par exemple en utilisant le traitement par lots, l'exécution asynchrone ou la mise en cache pour réduire les transferts de données. Le même Runtime peut supporter des applications multi-domaines, et fournit également un environnement d'exécution stable pour l'évolution des méthodes et le remplacement des algorithmes.

> **Indices sur les supports**
>
> - L'illustration de cette page peut être lue en trois couches. La couche supérieure est la couche algorithme, comprenant le module d'algorithme, la définition de problème et le flux de travail, les trois étant接入s via une interface unifiée
> - la couche intermédiaire est la couche d'ordonnancement Runtime, responsable de l'ordonnancement des tâches, de l'exécution parallèle, de la gestion des ressources et de l'isolation des interfaces
> - la couche inférieure est la puissance de calcul hétérogène, comprenant CPU, GPU, accélérateurs. Les indications des deux côtés soulignent respectivement « algorithme remplaçable, indépendant du matériel » et « compromis : flexibilité·performance·complexité », l'indication du bas « le même Runtime supporte les applications multi-domaines ». Lors de l'explication, on peut suivre les flèches de haut en bas : la couche algorithme ne touche pas directement le matériel, c'est le Runtime qui ordonnance l'exécution selon le flux de travail.

**Couverture des mots-clés**

- Ordonnancement de puissance de calcul hétérogène, composabilité des algorithmes, interface unifiée, ordonnancement du flux de travail, abstraction indépendante du matériel, isolation des interfaces, frais d'ordonnancement, frais de transfert de données.

**Traitement des exercices**

Les cinq questions à choix multiples peuvent servir de vérification rapide. La direction correcte de la question 1 est « fournir une couche d'ordonnancement et d'abstraction, gérer la puissance de calcul hétérogène et maintenir la composabilité des algorithmes » ; si l'étudiant choisit par erreur « implémenter directement l'algorithme d'optimisation », il faut souligner que le Runtime n'implémente pas d'algorithme concret. La direction correcte de la question 2 est « se combiner via des interfaces modulaires, sans se lier au matériel sous-jacent et aux stratégies parallèles » ; si l'étudiant choisit par erreur l'API CUDA ou l'écriture manuelle de code parallèle, expliquer que cela briserait le découplage. La direction correcte de la question 3 est « absorber les différences d'appareils, l'exécution tensorisée et l'optimisation par compilation, rendant la couche algorithme indépendante de l'appareil ». La direction correcte de la question 4 est « l'abstraction entraîne des frais d'ordonnancement et de transfert de données, nécessitant un compromis entre flexibilité, performance et complexité d'ingénierie ».

La direction correcte de la question 5 est « le même Runtime peut supporter des applications multi-domaines et fournir un environnement d'exécution stable pour l'évolution des méthodes ». Lors du retour, revenir uniformément à trois preuves : couche intermédiaire et non implémentation d'algorithme, la composabilité exige le découplage matériel, l'abstraction n'est pas sans coût.

Le Runtime, en tant que couche intermédiaire, combine les modules d'algorithme, de problème et de flux de travail via une interface unifiée, et ordonnance les tâches telles que la population, l'évaluation et les opérateurs vers CPU ou GPU pour exécution ; la couche algorithme ne se lie pas directement au matériel, aux stratégies parallèles ou aux détails de compilation, donc lorsque l'équipe remplace DE, PSO ou ajuste la taille de la population, il n'est pas nécessaire de réécrire le code parallèle sous-jacent. Réponse à la deuxième question : l'abstraction entraîne des frais supplémentaires d'ordonnancement et de transfert de données, pouvant affecter la performance de bout en bout ; en même temps, la maintenance et le débogage du Runtime lui-même augmentent la complexité d'ingénierie. L'équipe peut réduire les transferts de données par le traitement par lots, l'exécution asynchrone ou la mise en cache, équilibrant flexibilité, performance et complexité d'ingénierie.

**Vérification de la compréhension**

Demander aux étudiants d'expliquer en une phrase pourquoi le Runtime permet au remplacement d'algorithme de ne pas toucher au code matériel ; puis de citer chacun un objet d'ordonnancement et une ressource hétérogène, confirmant qu'ils ne confondent pas « population, évaluation, opérateurs » avec « CPU, GPU, accélérateurs ».

> **Indication de transition**
>
> Après avoir confirmé que les étudiants peuvent distinguer objets d'ordonnancement et ressources hétérogènes, et peuvent énoncer les gains et coûts de la composabilité, passer aux exemples, applications ou résumés de la page suivante.

<a id="lecture-page-16"></a>

### Fondement de l'exploration évolutive parallèle à haute intensité

*Page 16*

> **Objectif de la page :** Les apprenants doivent résumer de manière complète la valeur globale et la signification pratique du socle de calcul EvoX et de l'évolution parallèle tensorisée.

> **Objectif de la page**
>
> Résumer de manière complète la valeur globale et la signification pratique du socle de calcul EvoX et de l'évolution parallèle tensorisée. Les apprenants doivent pouvoir expliquer la transformation de la liste de candidats au graphe de calcul tensorisé, maîtriser les trois types d'objets tensorisés — population, évaluation et état — et comprendre comment le Runtime unifié et l'architecture découplée supportent l'exploration évolutive parallèle à haute intensité.

> **Ordre d'explication**
>
> On pointe d'abord le goulot d'étranglement du flux sérialisé traditionnel, puis on introduit la pierre angulaire du graphe de calcul tensorisé, ensuite on déploie les trois grands objets tensorisés, puis on parle de la graphe de calculisation et de l'architecture unifiée, et enfin on aboutit aux gains, à la signification pratique et au cas du profil supercritique.

**Points clés de l'enseignement**

- 1. Les expériences évolutives traditionnelles traitent chaque individu comme un objet Python indépendant, modélisé et évalué un par un. Lorsque l'échelle des candidats s'étend à des milliers voire des dizaines de milliers, le véritable goulot d'étranglement n'est souvent plus l'algorithme lui-même, mais les frais d'ordonnancement, de synchronisation et d'E/S candidat par candidat. La pierre angulaire d'EvoX peut être résumée ainsi : de la liste de candidats au graphe de calcul tensorisé. Il réorganise la population, l'évaluation et l'état d'exécution en tenseurs calculables globalement, puis les ordonnance vers GPU et puissance de calcul hétérogène via un Runtime unifié pour une exécution par lots, supportant ainsi la recherche évolutive à grande échelle, multi-objectifs et multi-solutions parallèles. 2. Les trois grands objets tensorisés : les paramètres d'individus, les gènes ou les stratégies ne sont plus des objets Python en boucle un par un, mais organisés en tenseurs selon la dimension de lot, les différences entre individus étant portées par une dimension du tenseur. La fitness, les contraintes, les indicateurs multi-objectifs ainsi que les résultats d'évaluation de simulation ou de modèle peuvent être calculés par lots, les candidats d'un même lot partageant un seul appel d'appareil, réduisant considérablement les frais d'ordonnancement et d'E/S candidat par candidat. Le numéro de génération évolutive, la graine aléatoire, le cache et les indicateurs de surveillance sont gérés de manière unifiée, rendant l'expérience reproductible et traçable même après accélération parallèle. La tensorisation n'est pas une optimisation locale d'un endroit précis, mais traverse les trois niveaux de la boucle évolutive. Si un niveau revient à une boucle objet par objet, le parallélisme sera bloqué à ce niveau. Après avoir élevé la liste de candidats au graphe de calcul tensorisé, le parallélisme des opérateurs et l'optimisation par compilation ont un espace pour s'exprimer, la taille de la population et le degré de parallélisme d'évaluation peuvent s'étendre avec la puissance de calcul, plutôt que d'être verrouillés par la boucle de l'interpréteur. Cela s'accompagne d'une architecture unifiée — modules d'algorithme, de problème, de flux de travail et de surveillance, planificateur Runtime mutuellement découplés, rendant les algorithmes composables, les problèmes enfichables et la puissance de calcul hétérogène gérée de manière unifiée. L'utilisateur n'a pas à se soucier simultanément de l'ordonnancement sous-jacent lors de l'écriture d'algorithmes. Remplacer la boucle sérialisée CPU traditionnelle, réaliser une accélération à grande échelle sur GPU et puissance de calcul hétérogène, fournir une base de débit stable pour l'exploration à haute intensité
- dans le même temps hor