Optimiser les tests de modèles d'IA Web: GPU Web, WebGL et Chrome sans interface graphique

François Beaufort
François Beaufort

Bonne nouvelle ! Vous avez créé une application d'IA Web intéressante qui exécute des modèles de machine learning directement sur l'appareil d'un utilisateur. Il s'exécute entièrement dans le navigateur Web côté client, sans passer par le cloud. Cette conception sur l'appareil renforce la confidentialité des utilisateurs, améliore les performances et réduit considérablement les coûts.

Cependant, il y a un obstacle. Votre modèle TensorFlow.js peut fonctionner à la fois sur des processeurs (WebAssembly) et sur des GPU plus puissants (via WebGL et WebGPU). La question est la suivante : comment pouvez-vous automatiser les tests des navigateurs de manière cohérente avec le matériel sélectionné ?

Il est essentiel d'assurer une certaine cohérence pour comparer les performances des modèles de machine learning au fil du temps, à mesure que vous itérez et améliorez ceux-ci avant de les déployer pour des utilisateurs réels sur leur appareil.

Configurer un environnement de test cohérent avec des GPU peut s'avérer plus difficile que prévu. Dans cet article de blog, nous allons vous présenter les problèmes que nous avons rencontrés et la façon dont nous les avons résolus, afin que vous puissiez améliorer les performances de votre application.

Ce n'est pas le cas pour les développeurs d'IA pour le Web. Si vous travaillez sur des jeux en ligne ou des graphiques, cet article est également précieux pour vous.

Que contient notre boîte à outils d'automatisation ?

Voici ce que nous utilisons:

  • Environnement: notebook Google Colab basé sur Linux et connecté à un GPU NVIDIA T4 ou V100 Si vous préférez, vous pouvez utiliser d'autres plates-formes cloud telles que Google Cloud (GCP).
  • Navigateur: Chrome est compatible avec WebGPU, un puissant succès de WebGL qui apporte sur le Web les avancées des API GPU modernes.
  • Automatisation: Puppeteer est une bibliothèque Node.js qui vous permet de contrôler les navigateurs de manière automatisée avec JavaScript. Avec Puppeteer, nous pouvons automatiser Chrome en mode headless, ce qui signifie que le navigateur s'exécute sans interface visible, sur un serveur. Nous utilisons le nouveau mode headless amélioré, et non l'ancien mode.

Vérifier l'environnement

Le meilleur moyen de vérifier si l'accélération matérielle est activée dans Chrome est de saisir chrome://gpu dans la barre d'adresse. Vous pouvez programmer l'exécution de l'équivalent avec Puppeteer avec console.log ou enregistrer le rapport complet au format PDF pour le vérifier manuellement:

/* Incomplete example.js */
import puppeteer from 'puppeteer';

// Configure launch parameters: Expands later
const browser = await puppeteer.launch({
  headless: 'new',
  args:  ['--no-sandbox']
});

const page = await browser.newPage();
await page.goto('chrome://gpu');

// Verify: log the WebGPU status or save the GPU report as PDF
const txt = await page.waitForSelector('text/WebGPU');
const status = await txt.evaluate(g => g.parentElement.textContent);
console.log(status);
await page.pdf({ path: './gpu.pdf' });

await browser.close();

Ouvrez chrome://gpu. Vous devriez obtenir les résultats suivants:

État des fonctionnalités graphiques
OpenGL: Désactivé
Vulkan: Désactivé
WebGL: Logiciel uniquement, accélération matérielle non disponible.
WebGL2: Logiciel uniquement, accélération matérielle non disponible.
WebGPU: Désactivé

Problèmes détectés.
WebGPU a été désactivé via la liste de blocage ou la ligne de commande.

Ce n'est pas un bon début. Il est assez clair que la détection matérielle a échoué. WebGL, WebGL2 et WebGPU sont désactivés ou uniquement logiciels. Nous ne sommes pas les seuls à régler ce problème. De nombreuses discussions en ligne font intervenir des personnes qui se trouvent dans une situation similaire, y compris sur les canaux d'assistance officiels de Chrome (1, 2).

Activer la compatibilité avec WebGPU et WebGL

Par défaut, Chrome sans interface graphique désactive le GPU. Pour l'activer sous Linux, appliquez tous les indicateurs suivants lors du lancement de Headless Chrome:

  • L'option --no-sandbox désactive le bac à sable de sécurité de Chrome, qui isole le processus du navigateur du reste du système. Il n'est pas possible d'exécuter Chrome en mode root sans ce bac à sable.
  • L'indicateur --headless=new exécute Chrome avec le nouveau mode headless amélioré, sans interface utilisateur visible.
  • L'option --use-angle=vulkan indique à Chrome d'utiliser le backend Vulkan pour ANGLE, qui traduit les appels OpenGL ES 2/3 en appels d'API Vulkan.
  • L'option --enable-features=Vulkan active le backend graphique Vulkan pour la composition et la rastérisation dans Chrome.
  • L'option --disable-vulkan-surface désactive l'extension d'instance Vulkan VK_KHR_surface. Au lieu d'utiliser une chaîne d'échange, Bit blit est utilisé pour le résultat du rendu actuel à l'écran.
  • L'option --enable-unsafe-webgpu active l'API WebGPU expérimentale dans Chrome sous Linux et désactive la liste de blocage des adaptateurs.

Nous combinons maintenant toutes les modifications que nous avons apportées jusqu'à présent. Voici le script complet.

/* Complete example.js */
import puppeteer from 'puppeteer';

// Configure launch parameters
const browser = await puppeteer.launch({
  headless: 'new',
  args: [
    '--no-sandbox',
    '--headless=new',
    '--use-angle=vulkan',
    '--enable-features=Vulkan',
    '--disable-vulkan-surface',
    '--enable-unsafe-webgpu',
  ]
});

const page = await browser.newPage();
await page.goto('chrome://gpu');

// Verify: log the WebGPU status or save the GPU report as PDF
const txt = await page.waitForSelector('text/WebGPU');
const status = await txt.evaluate(g => g.parentElement.textContent);
console.log(status);
await page.pdf({path: './gpu.pdf'});

await browser.close();

Exécutez à nouveau le script. Aucun problème WebGPU n'est détecté, et la valeur passe de "Désactivé" à "Logiciel uniquement".

État des fonctionnalités graphiques
OpenGL: Désactivé
Vulkan: Désactivé
WebGL: Logiciel uniquement, accélération matérielle non disponible.
WebGL2: Logiciel uniquement, accélération matérielle non disponible.
WebGPU: Logiciel uniquement, accélération matérielle non disponible.

Cependant, l'accélération matérielle n'est toujours pas disponible, le GPU NVIDIA T4 n'est pas détecté.

Installer les bons pilotes de GPU

Nous avons étudié de plus près la sortie de chrome://gpu avec l'aide de quelques experts en GPU de l'équipe Chrome. Nous avons détecté des problèmes au niveau des pilotes par défaut installés sur l'instance Colab pour Linux, ce qui entraînait des problèmes avec Vulkan, empêchant Chrome de détecter le GPU NVIDIA T4 au niveau GL_RENDERER, comme indiqué dans le résultat suivant. Cela entraîne des problèmes avec Headless Chrome.

La sortie par défaut ne détecte pas les GPU NVIDIA T4.
Informations sur le conducteur
GL_RENDERER ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (Subzero) (0x0000C0DE)), SwiftShader driver-5.0.0)

L'installation des pilotes compatibles appropriés résout donc le problème.

Résultat mis à jour après l'installation des pilotes.
Informations sur le conducteur
GL_RENDERER ANGLE (NVIDIA Corporation, Tesla T4/PCIe/SSE2, OpenGL ES 3.2 NVIDIA 525.105.17)

Pour installer les pilotes appropriés, exécutez les commandes suivantes lors de la configuration. Les deux dernières lignes vous permettent de consigner les résultats de ce que les pilotes NVIDIA détectent avec vulkaninfo.

apt-get install -y vulkan-tools libnvidia-gl-525

// Verify the NVIDIA drivers detects along with vulkaninfo
nvidia-smi
vulkaninfo --summary

Exécutez à nouveau le script. Nous obtenons le résultat suivant : 🎉

État des fonctionnalités graphiques
OpenGL: Activé
Vulkan: Activé
WebGL: Le matériel a accéléré, mais a réduit les performances.
WebGL2: Le matériel a accéléré, mais a réduit les performances.
WebGPU: Le matériel a accéléré, mais a réduit les performances.

En utilisant les pilotes et les indicateurs appropriés lors de l'exécution de Chrome, WebGPU et WebGL sont désormais compatibles avec le nouveau mode headless.

En coulisses: l'enquête de notre équipe

Après de nombreuses recherches, nous n'avons pas trouvé de méthodes de travail pour l'environnement que nous devions exécuter dans Google Colab. Toutefois, certains posts prometteurs ont fonctionné dans d'autres environnements. Au final, nous n'avons pas pu reproduire leur succès dans l'environnement Colab NVIDIA T4, car nous avons rencontré deux problèmes principaux:

  1. Certaines combinaisons d'indicateurs permettent la détection du GPU, mais ne vous permettent pas de l'utiliser réellement.
  2. Des exemples de solutions fonctionnelles de tiers utilisaient l'ancienne version sans interface graphique de Chrome, qui, à un moment donné, sera abandonnée au profit de la nouvelle version. Nous avions besoin d'une solution compatible avec la nouvelle version de Chrome headless, qui soit mieux pérenne.

Nous avons confirmé la sous-utilisation du GPU en exécutant un exemple de page Web TensorFlow.js pour la reconnaissance d'image, dans lequel nous avons entraîné un modèle à reconnaître des échantillons de vêtements (une sorte de "hello world" en machine learning).

Sur une machine standard, 50 cycles d'entraînement (époques) doivent s'exécuter en moins d'une seconde chacun. En appelant Chrome sans interface graphique dans son état par défaut, nous avons pu enregistrer la sortie de la console JavaScript dans la ligne de commande Node.js côté serveur pour voir à quelle vitesse ces cycles d'entraînement prenaient réellement.

Comme prévu, chaque époque d'entraînement a pris beaucoup plus de temps que prévu (plusieurs secondes), ce qui suggère que Chrome est revenu à une ancienne exécution de processeur JavaScript au lieu d'utiliser le GPU:

Les époques d'entraînement évoluent à un rythme plus lent.
Figure 1: Capture en temps réel montrant la durée d'exécution de chaque époque d'entraînement (en secondes).

Après avoir corrigé les pilotes et utilisé la bonne combinaison d'indicateurs pour Chrome sans interface graphique, la réexécution de l'exemple d'entraînement TensorFlow.js accélère beaucoup les époques d'entraînement.

La vitesse augmente pour les époques.
Figure 2: Capture en temps réel illustrant la vitesse d'accélération des époques

Résumé

L'IA Web a connu une croissance exponentielle depuis sa création en 2017. Grâce aux technologies de navigateur telles que WebGPU, WebGL et WebAssembly, les opérations mathématiques d'un modèle de machine learning peuvent être encore accélérées côté client.

En 2023, TensorFlow.js et MediaPipe Web ont enregistré plus d'un milliard de téléchargements de modèles et de bibliothèques, une étape historique qui montre que les développeurs et les ingénieurs Web s'orientent vers l'IA dans leurs applications Web de nouvelle génération pour créer des solutions vraiment incroyables.

Une utilisation réussie implique de grandes responsabilités. À ce niveau d'utilisation dans les systèmes de production, il est nécessaire de tester des modèles d'IA basés sur un navigateur côté client dans un véritable environnement de navigateur, tout en étant évolutifs, automatisables et dans une configuration matérielle standardisée connue.

En exploitant la puissance combinée des fonctionnalités Headless Chrome et Puppeteer, vous pouvez tester en toute confiance ces charges de travail dans un environnement standardisé et reproductible, et ainsi garantir des résultats cohérents et fiables.

Conclusion

Un guide par étapes est disponible dans notre documentation pour vous permettre de tester vous-même la configuration complète.

Si vous avez trouvé cela utile, n'hésitez pas à le mentionner sur LinkedIn, X (anciennement Twitter) ou tout autre réseau social que vous utilisez avec le hashtag #WebAI. N'hésitez pas à nous faire part de vos commentaires afin que nous puissions écrire davantage d'éléments de ce type à l'avenir.

Activez le suivi dans le dépôt GitHub pour recevoir les futures mises à jour.

Remerciements

Un grand merci à tous les membres de l'équipe Chrome qui ont aidé à déboguer le pilote et les problèmes WebGPU que nous avons rencontrés dans cette solution. Nous tenons à remercier tout particulièrement Jecelyn Yeen et Alexandra White pour leur aide à la rédaction de cet article de blog. Grâce à Yuly Novikov, Andrey Kosyakov et Alex Rudenko, qui ont joué un rôle déterminant dans la création de la solution finale et fonctionnelle.