WebGPU et IA sur appareil : le navigateur devient un runtime sérieux

spinny:~/writing $ vim webgpu-on-device-ai-browser.md

1~
2Pendant des années, le navigateur était le joli visage de l’application et le cloud était le lieu où se déroulaient les tâches difficiles. L'utilisateur écrit, clique, télécharge un fichier ; le frontend envoie tout au serveur ; le serveur appelle un modèle ; la réponse revient.
3~
4Ce dispositif reste très utile, mais il n’est pas gratuit. Chaque appel soulève des questions de latence, de coût, de dépendance au réseau et de confidentialité. Si l’utilisateur écrit une phrase et souhaite une suggestion, une demi-seconde compte. Si vous classez des milliers de petits intrants, les centimes deviennent de l'argent réel. Si le texte est sensible, l’envoyer depuis l’appareil n’est pas un choix neutre.
5~
6C'est pourquoi le WebGPU et l'IA sur appareil sont à la mode. Non pas parce que nous exécuterons tous les modèles dans le navigateur demain. Parce que certaines fonctionnalités intelligentes peuvent se rapprocher de l’utilisateur.
7~
8## Tout ne doit pas nécessairement devenir local
9~
10La version enfantine de l’argument est la suivante : « cloud contre appareil ». La version utile est hybride.
11~
12Certaines tâches s'affichent parfaitement sur l'appareil : courts résumés, détection de langue, réécritures légères, classifications simples, filtres d'image, petits modèles de vision, expériences créatives avec retour immédiat.
13~
14D'autres tâches restent meilleures dans le cloud : raisonnement complexe, modèles frontières, données côté serveur, audit centralisé, qualité uniforme, workflow où il faut contrôler soigneusement chaque étape.
15~
16L'architecture saine décide au moment de l'exécution :
17~
18```mermaid
19flowchart TD
20    User[Utilisateur] --> Browser[Navigateurs]
21    Browser --> Detect[Détection de fonctionnalités]
22    Detect -->|Pris en charge| Local[Inférence locale]
23    Detect -->|Non pris en charge| Cloud[Repli sur le cloud]
24    Local --> UX[Réponse rapide]
25    Cloud --> UX
26    UX --> Metrics[Métriques et qualité]
27```
28~
29Le navigateur n'a pas besoin de gagner contre le cloud. Cela doit éviter au cloud d'effectuer un travail qui n'a pas besoin d'être effectué là-bas.
30~
31## Pourquoi WebGPU est important
32~
33WebGPU est une API moderne permettant d'utiliser le GPU depuis le navigateur. Ce n'est pas seulement pour de plus beaux graphismes 3D. C’est également important car il expose des primitives adaptées au calcul : charges de travail parallèles, shaders, pipelines plus proches de ce que font bien les GPU.
34~
35Pour l’IA, la visualisation scientifique, les éditeurs 3D, les filtres vidéo et les outils de création, cette différence se fait sentir. WebGL a fait beaucoup pour le web, mais WebGPU est né avec un modèle mieux adapté au présent.
36~
37Cependant, la première chose à écrire n’est pas un shader. C'est une détection de fonctionnalité sobre :
38~
39```typescript
40export async function requestWebGpuDevice() {
41  if (!('gpu' in navigator)) {
42    return null;
43  }
44~
45  const adapter = await navigator.gpu.requestAdapter({
46    powerPreference: 'high-performance',
47  });
48~
49  if (!adapter) {
50    return null;
51  }
52~
53  return adapter.requestDevice();
54}
55```
56~
57Cette fonctionnalité dit une chose importante : WebGPU n'est pas un droit accordé sur chaque appareil. C'est une capacité à vérifier. Certains navigateurs ne le prennent pas entièrement en charge, certains GPU ont des limitations, certains environnements d'entreprise désactivent des fonctionnalités, certains utilisateurs utilisent un matériel modeste.
58~
59## IA intégrée : lorsque le navigateur apporte le modèle
60~
61Chrome propose des API intégrées pour des tâches telles que les invites locales, le résumé, la rédaction, la réécriture, la traduction, la détection de langue et la relecture. L'idée est très intéressante : le navigateur gère le modèle, la disponibilité et les mises à jour ; l'application utilise une API plus proche de la plateforme.
62~
63Si ça marche bien, ça change beaucoup :
64~
65- moins d'appels au serveur pour des tâches simples ;
66- les données pouvant rester sur l'appareil ;
67- latence inférieure ;
68- expériences hors ligne ou semi-hors ligne ;
69- UX plus naturelle pour la rédaction et la traduction.
70~
71Mais cela doit être traité comme une amélioration progressive. Certaines API sont stables, d'autres en version d'essai ou en avant-première, d'autres encore dépendent de la version, de la langue et de l'appareil.
72~
73```typescript
74type LocalCapability = 'available' | 'downloadable' | 'unsupported';
75~
76export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
77  const SummarizerApi = (globalThis as any).Summarizer;
78~
79  if (!SummarizerApi?.availability) {
80    return 'unsupported';
81  }
82~
83  const availability = await SummarizerApi.availability();
84~
85  if (availability === 'available') return 'available';
86  if (availability === 'downloadable') return 'downloadable';
87~
88  return 'unsupported';
89}
90```
91~
92Le code spécifique changera, mais le modèle demeure : vous vérifiez la disponibilité, expliquez les téléchargements, proposez des solutions de secours et mesurez la qualité.
93~
94## Le repli n’est pas un triste plan B
95~
96Le repli sur le cloud n’est pas une défaite. Cela fait partie du produit.
97~
98```typescript
99interface AiRequest {
100  task: 'summarize' | 'rewrite' | 'classify';
101  input: string;
102}
103~
104interface AiResult {
105  output: string;
106  runtime: 'local' | 'cloud';
107}
108~
109export async function runAiTask(request: AiRequest): Promise<AiResult> {
110  const local = await tryLocalAi(request);
111~
112  if (local) {
113    return { output: local, runtime: 'local' };
114  }
115~
116  const cloud = await fetch('/api/ai', {
117    method: 'POST',
118    headers: { 'Content-Type': 'application/json' },
119    body: JSON.stringify(request),
120  }).then((res) => res.json());
121~
122  return { output: cloud.output, runtime: 'cloud' };
123}
124```
125~
126Cette architecture vous permet de vous améliorer progressivement. Ceux qui bénéficient d’un support local bénéficient d’une meilleure latence et d’une meilleure confidentialité. Ceux qui ne l’ont pas utilisent toujours cette fonctionnalité. Vous pouvez mesurer le pourcentage de demandes locales, les délais, les erreurs, la mémoire, la qualité perçue et le coût.
127~
128Sans métriques, l’IA intégrée aux appareils devient un choix esthétique. Avec les métriques, cela devient un levier produit.
129~
130## L'UX du modèle compte
131~
132Si le navigateur a besoin de télécharger un modèle, l'utilisateur le perçoit. Ne le cachez pas derrière une vague roulette. Mieux vaut être clair : "Nous préparons le modèle pour utiliser cette fonction plus rapidement et même hors ligne."
133~
134Une bonne expérience :
135~
136- affiche l'état de préparation ;
137- ne bloque pas la page entière ;
138- vous permet de continuer avec le repli sur le cloud ;
139- évitez les surprises liées à la batterie et à la mémoire ;
140- mémorisez le modèle autant que possible ;
141- expliquez le bénéfice en une phrase concrète.
142~
143Le pire, c'est une fonctionnalité "intelligente" qui semble cassée car elle télécharge quelque chose en silence.
144~
145## Confidentialité : meilleure, pas automatiquement sécurisée
146~
147Le traitement des données sur l'appareil peut être un grand avantage. Il n'est pas nécessaire qu'un brouillon d'e-mail, un document interne ou une note personnelle quitte votre navigateur pour recevoir une suggestion.
148~
149Cependant, local ne signifie pas automatiquement sécurité. Cependant, vous devez penser à :
150~
151- XSS ;
152- journaux accidentels ;
153- données enregistrées en stockage ;
154- injection rapide à partir de contenu non fiable ;
155- autorisations accordées au modèle ;
156- sorties utilisées dans les actions automatiques.
157~
158Si un modèle local peut lire une page Web puis remplir un formulaire, cette page peut tenter de la manipuler. S'il peut appeler l'outil, une confirmation est nécessaire. S’il produit une sortie structurée, il doit être validé. Le fait qu’il s’exécute sur l’appareil réduit certains risques liés à la vie privée, mais n’élimine pas le modèle de sécurité.
159~
160## Où ça devient vraiment intéressant
161~
162Le texte n'est que le début. WebGPU rend crédibles les expériences Web qui, jusqu'à récemment, ressemblaient à une application native :
163~
164- éditeurs 3D complexes ;
165- Éclaboussures gaussiennes dans le navigateur ;
166- filtres vidéo en temps réel ;
167- CAO légère ;
168- visualisations scientifiques;
169- outils créatifs avec aperçu instantané ;
170- inférence de vision à proximité de l'interface utilisateur ;
171- des jeux par navigateur plus ambitieux.
172~
173Ici, le frontend, les graphiques et l'apprentissage automatique commencent à se mélanger. C'est un domaine un peu délicat, mais aussi fertile : le navigateur redevient une plate-forme d'application sérieuse, et pas seulement l'endroit où l'on met des formulaires et des tableaux de bord.
174~
175## Liste de contrôle avant la production
176~
177Avant de proposer une fonctionnalité sur l'appareil aux utilisateurs, je vérifierais :
178~
1791. Ciblez les navigateurs et les appareils.
1802. Repli du cloud ou dégradation élégante.
1813. Temps de téléchargement et cache du modèle.
1824. Mémoire et batterie sur matériel moyen.
1835. Qualité par rapport à la version cloud.
1846. Politique de confidentialité et messages des utilisateurs.
1857. Test avec des entrées hostiles.
1868. Métriques distinctes pour l’exécution locale et cloud.
1879. Prévoyez de mettre à jour ou de désactiver le modèle.
188~
189C'est une liste concrète parce que le problème est concret. Une fonctionnalité d’IA lente, fragile ou opaque ne s’améliore pas simplement parce qu’elle s’exécute dans le navigateur.
190~
191## Le bon compromis
192~
193Je ne crois pas que l'avenir réside dans "tout sur l'appareil". Et je ne pense pas non plus que le cloud restera le seul endroit raisonnable pour faire des déductions. L'avenir le plus probable est un mélange : local lorsque cela améliore la latence, la confidentialité ou le coût ; cloud lorsque la qualité, les données mises à jour et le contrôle centralisé sont nécessaires.
194~
195WebGPU, WebNN et les API d'IA intégrées ne rendent pas le navigateur omnipotent. Ils le rendent plus adulte. Et pour ceux qui créent des produits Web, c’est une énorme nouvelle.
196~
197## Sources utiles
198~
199- [API WebGPU - MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API)
200- [Spécification WebGPU - W3C](https://www.w3.org/TR/webgpu/)
201- [IA intégrée – Chrome pour les développeurs](https://developer.chrome.com/docs/ai/built-in)
202- [API d'IA intégrées – Chrome pour les développeurs](https://developer.chrome.com/docs/ai/built-in-apis)
203- [API WebNN](https://webnn.io/)
204~

NORMAL · webgpu-on-device-ai-browser.md [readonly]204 lines · :q to close

2Pendant des années, le navigateur était le joli visage de l’application et le cloud était le lieu où se déroulaient les tâches difficiles. L'utilisateur écrit, clique, télécharge un fichier ; le frontend envoie tout au serveur ; le serveur appelle un modèle ; la réponse revient.

4Ce dispositif reste très utile, mais il n’est pas gratuit. Chaque appel soulève des questions de latence, de coût, de dépendance au réseau et de confidentialité. Si l’utilisateur écrit une phrase et souhaite une suggestion, une demi-seconde compte. Si vous classez des milliers de petits intrants, les centimes deviennent de l'argent réel. Si le texte est sensible, l’envoyer depuis l’appareil n’est pas un choix neutre.

6C'est pourquoi le WebGPU et l'IA sur appareil sont à la mode. Non pas parce que nous exécuterons tous les modèles dans le navigateur demain. Parce que certaines fonctionnalités intelligentes peuvent se rapprocher de l’utilisateur.

8## Tout ne doit pas nécessairement devenir local

10La version enfantine de l’argument est la suivante : « cloud contre appareil ». La version utile est hybride.

11~

12Certaines tâches s'affichent parfaitement sur l'appareil : courts résumés, détection de langue, réécritures légères, classifications simples, filtres d'image, petits modèles de vision, expériences créatives avec retour immédiat.

13~

14D'autres tâches restent meilleures dans le cloud : raisonnement complexe, modèles frontières, données côté serveur, audit centralisé, qualité uniforme, workflow où il faut contrôler soigneusement chaque étape.

15~

16L'architecture saine décide au moment de l'exécution :

17~

18```mermaid

19flowchart TD

20 User[Utilisateur] --> Browser[Navigateurs]

21 Browser --> Detect[Détection de fonctionnalités]

22 Detect -->|Pris en charge| Local[Inférence locale]

23 Detect -->|Non pris en charge| Cloud[Repli sur le cloud]

24 Local --> UX[Réponse rapide]

25 Cloud --> UX

26 UX --> Metrics[Métriques et qualité]

27```

28~

29Le navigateur n'a pas besoin de gagner contre le cloud. Cela doit éviter au cloud d'effectuer un travail qui n'a pas besoin d'être effectué là-bas.

30~

31## Pourquoi WebGPU est important

32~

33WebGPU est une API moderne permettant d'utiliser le GPU depuis le navigateur. Ce n'est pas seulement pour de plus beaux graphismes 3D. C’est également important car il expose des primitives adaptées au calcul : charges de travail parallèles, shaders, pipelines plus proches de ce que font bien les GPU.

34~

35Pour l’IA, la visualisation scientifique, les éditeurs 3D, les filtres vidéo et les outils de création, cette différence se fait sentir. WebGL a fait beaucoup pour le web, mais WebGPU est né avec un modèle mieux adapté au présent.

36~

37Cependant, la première chose à écrire n’est pas un shader. C'est une détection de fonctionnalité sobre :

38~

39```typescript

40export async function requestWebGpuDevice() {

41 if (!('gpu' in navigator)) {

42 return null;

43 }

44~

45 const adapter = await navigator.gpu.requestAdapter({

46 powerPreference: 'high-performance',

47 });

48~

49 if (!adapter) {

50 return null;

51 }

52~

53 return adapter.requestDevice();

54}

55```

56~

57Cette fonctionnalité dit une chose importante : WebGPU n'est pas un droit accordé sur chaque appareil. C'est une capacité à vérifier. Certains navigateurs ne le prennent pas entièrement en charge, certains GPU ont des limitations, certains environnements d'entreprise désactivent des fonctionnalités, certains utilisateurs utilisent un matériel modeste.

58~

59## IA intégrée : lorsque le navigateur apporte le modèle

60~

61Chrome propose des API intégrées pour des tâches telles que les invites locales, le résumé, la rédaction, la réécriture, la traduction, la détection de langue et la relecture. L'idée est très intéressante : le navigateur gère le modèle, la disponibilité et les mises à jour ; l'application utilise une API plus proche de la plateforme.

62~

63Si ça marche bien, ça change beaucoup :

64~

65- moins d'appels au serveur pour des tâches simples ;

66- les données pouvant rester sur l'appareil ;

67- latence inférieure ;

68- expériences hors ligne ou semi-hors ligne ;

69- UX plus naturelle pour la rédaction et la traduction.

70~

71Mais cela doit être traité comme une amélioration progressive. Certaines API sont stables, d'autres en version d'essai ou en avant-première, d'autres encore dépendent de la version, de la langue et de l'appareil.

72~

73```typescript

74type LocalCapability = 'available' | 'downloadable' | 'unsupported';

75~

76export async function getLocalSummarizerCapability(): Promise<LocalCapability> {

77 const SummarizerApi = (globalThis as any).Summarizer;

78~

79 if (!SummarizerApi?.availability) {

80 return 'unsupported';

81 }

82~

83 const availability = await SummarizerApi.availability();

84~

85 if (availability === 'available') return 'available';

86 if (availability === 'downloadable') return 'downloadable';

87~

88 return 'unsupported';

89}

90```

91~

92Le code spécifique changera, mais le modèle demeure : vous vérifiez la disponibilité, expliquez les téléchargements, proposez des solutions de secours et mesurez la qualité.

93~

94## Le repli n’est pas un triste plan B

95~

96Le repli sur le cloud n’est pas une défaite. Cela fait partie du produit.

97~

98```typescript

99interface AiRequest {

100 task: 'summarize' | 'rewrite' | 'classify';

101 input: string;

102}

103~

104interface AiResult {

105 output: string;

106 runtime: 'local' | 'cloud';

107}

108~

109export async function runAiTask(request: AiRequest): Promise<AiResult> {

110 const local = await tryLocalAi(request);

111~

112 if (local) {

113 return { output: local, runtime: 'local' };

114 }

115~

116 const cloud = await fetch('/api/ai', {

117 method: 'POST',

118 headers: { 'Content-Type': 'application/json' },

119 body: JSON.stringify(request),

120 }).then((res) => res.json());

121~

122 return { output: cloud.output, runtime: 'cloud' };

123}

124```

125~

126Cette architecture vous permet de vous améliorer progressivement. Ceux qui bénéficient d’un support local bénéficient d’une meilleure latence et d’une meilleure confidentialité. Ceux qui ne l’ont pas utilisent toujours cette fonctionnalité. Vous pouvez mesurer le pourcentage de demandes locales, les délais, les erreurs, la mémoire, la qualité perçue et le coût.

127~

128Sans métriques, l’IA intégrée aux appareils devient un choix esthétique. Avec les métriques, cela devient un levier produit.

129~

130## L'UX du modèle compte

131~

132Si le navigateur a besoin de télécharger un modèle, l'utilisateur le perçoit. Ne le cachez pas derrière une vague roulette. Mieux vaut être clair : "Nous préparons le modèle pour utiliser cette fonction plus rapidement et même hors ligne."

133~

134Une bonne expérience :

135~

136- affiche l'état de préparation ;

137- ne bloque pas la page entière ;

138- vous permet de continuer avec le repli sur le cloud ;

139- évitez les surprises liées à la batterie et à la mémoire ;

140- mémorisez le modèle autant que possible ;

141- expliquez le bénéfice en une phrase concrète.

142~

143Le pire, c'est une fonctionnalité "intelligente" qui semble cassée car elle télécharge quelque chose en silence.

144~

145## Confidentialité : meilleure, pas automatiquement sécurisée

146~

147Le traitement des données sur l'appareil peut être un grand avantage. Il n'est pas nécessaire qu'un brouillon d'e-mail, un document interne ou une note personnelle quitte votre navigateur pour recevoir une suggestion.

148~

149Cependant, local ne signifie pas automatiquement sécurité. Cependant, vous devez penser à :

150~

151- XSS ;

152- journaux accidentels ;

153- données enregistrées en stockage ;

154- injection rapide à partir de contenu non fiable ;

155- autorisations accordées au modèle ;

156- sorties utilisées dans les actions automatiques.

157~

158Si un modèle local peut lire une page Web puis remplir un formulaire, cette page peut tenter de la manipuler. S'il peut appeler l'outil, une confirmation est nécessaire. S’il produit une sortie structurée, il doit être validé. Le fait qu’il s’exécute sur l’appareil réduit certains risques liés à la vie privée, mais n’élimine pas le modèle de sécurité.

159~

160## Où ça devient vraiment intéressant

161~

162Le texte n'est que le début. WebGPU rend crédibles les expériences Web qui, jusqu'à récemment, ressemblaient à une application native :

163~

164- éditeurs 3D complexes ;

165- Éclaboussures gaussiennes dans le navigateur ;

166- filtres vidéo en temps réel ;

167- CAO légère ;

168- visualisations scientifiques;

169- outils créatifs avec aperçu instantané ;

170- inférence de vision à proximité de l'interface utilisateur ;

171- des jeux par navigateur plus ambitieux.

172~

173Ici, le frontend, les graphiques et l'apprentissage automatique commencent à se mélanger. C'est un domaine un peu délicat, mais aussi fertile : le navigateur redevient une plate-forme d'application sérieuse, et pas seulement l'endroit où l'on met des formulaires et des tableaux de bord.

174~

175## Liste de contrôle avant la production

176~

177Avant de proposer une fonctionnalité sur l'appareil aux utilisateurs, je vérifierais :

178~

1791. Ciblez les navigateurs et les appareils.

1802. Repli du cloud ou dégradation élégante.

1813. Temps de téléchargement et cache du modèle.

1824. Mémoire et batterie sur matériel moyen.

1835. Qualité par rapport à la version cloud.

1846. Politique de confidentialité et messages des utilisateurs.

1857. Test avec des entrées hostiles.

1868. Métriques distinctes pour l’exécution locale et cloud.

1879. Prévoyez de mettre à jour ou de désactiver le modèle.

188~

189C'est une liste concrète parce que le problème est concret. Une fonctionnalité d’IA lente, fragile ou opaque ne s’améliore pas simplement parce qu’elle s’exécute dans le navigateur.

190~

191## Le bon compromis

192~

193Je ne crois pas que l'avenir réside dans "tout sur l'appareil". Et je ne pense pas non plus que le cloud restera le seul endroit raisonnable pour faire des déductions. L'avenir le plus probable est un mélange : local lorsque cela améliore la latence, la confidentialité ou le coût ; cloud lorsque la qualité, les données mises à jour et le contrôle centralisé sont nécessaires.

194~

195WebGPU, WebNN et les API d'IA intégrées ne rendent pas le navigateur omnipotent. Ils le rendent plus adulte. Et pour ceux qui créent des produits Web, c’est une énorme nouvelle.

196~

197## Sources utiles

198~

199- [API WebGPU - MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API)

200- [Spécification WebGPU - W3C](https://www.w3.org/TR/webgpu/)

201- [IA intégrée – Chrome pour les développeurs](https://developer.chrome.com/docs/ai/built-in)

202- [API d'IA intégrées – Chrome pour les développeurs](https://developer.chrome.com/docs/ai/built-in-apis)

203- [API WebNN](https://webnn.io/)

204~