WebGPU ובינה מלאכותית במכשיר: הדפדפן הופך לזמן ריצה רציני

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

1~
2במשך שנים הדפדפן היה הפנים הנחמדות של האפליקציה והענן היה המקום שבו התרחשו הדברים הקשים. המשתמש כותב, לוחץ, מעלה קובץ; ה-frontend שולח הכל לשרת; השרת קורא למודל; התשובה חוזרת.
3~
4תכנית זו נשארת שימושית מאוד, אך היא אינה חינמית. כל שיחה מביאה שאלות חביון, עלות, תלות ברשת ופרטיות. אם המשתמש כותב משפט ורוצה הצעה, חצי שניה שוקלת. אם אתה מסווג אלפי תשומות קטנות, אגורות הופכות לכסף אמיתי. אם הטקסט רגיש, שליחתו מהמכשיר אינה בחירה ניטרלית.
5~
6זו הסיבה ש-WebGPU ו-AI במכשיר נמצאים בהייפ. לא בגלל שנפעיל מחר כל דגם בדפדפן. מכיוון שחלק מהתכונות החכמות יכולות להתקרב למשתמש.
7~
8## לא הכל חייב להיות מקומי
9~
10הגרסה הילדותית של הטיעון היא: "ענן מול מכשיר". הגרסה השימושית היא היברידית.
11~
12חלק מהמשימות נראות נהדר במכשיר: סיכומים קצרים, זיהוי שפה, שכתוב אור, סיווגים פשוטים, מסנני תמונות, דגמי ראייה קטנים, חוויות יצירתיות עם משוב מיידי.
13~
14משימות אחרות נשארות טובות יותר בענן: חשיבה מורכבת, מודלים חזיתיים, נתונים בצד השרת, ביקורת מרכזית, איכות אחידה, זרימת עבודה שבה אתה צריך לשלוט בקפידה בכל שלב.
15~
16הארכיטקטורה הבריאה מחליטה בזמן הריצה:
17~
18```mermaid
19flowchart TD
20    User[משתמש] --> Browser[דפדפנים]
21    Browser --> Detect[זיהוי תכונות]
22    Detect -->|נתמך| Local[מסקנות מקומיות]
23    Detect -->|לא נתמך| Cloud[נסיגה בענן]
24    Local --> UX[תגובה מהירה]
25    Cloud --> UX
26    UX --> Metrics[מדדים ואיכות]
27```
28~
29הדפדפן לא חייב לנצח מול הענן. זה חייב להציל את הענן מביצוע עבודה שלא צריך לעשות שם.
30~
31## למה WebGPU חשוב
32~
33WebGPU הוא API מודרני לשימוש ב-GPU מהדפדפן. זה לא מיועד רק לגרפיקה תלת מימדית יפה יותר. זה חשוב גם כי הוא חושף פרימיטיביים המתאימים למחשוב: עומסי עבודה מקבילים, הצללות, צינורות קרובים יותר למה שמעבדי GPU עושים טוב.
34~
35עבור AI, הדמיה מדעית, עורכי תלת מימד, מסנני וידאו וכלים יצירתיים, ההבדל הזה מורגש. WebGL עשה הרבה עבור האינטרנט, אבל WebGPU נולד עם דגם המתאים יותר להווה.
36~
37עם זאת, הדבר הראשון שצריך לכתוב הוא לא הצללה. זה זיהוי תכונה מפוכח:
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~
57תכונה זו אומרת דבר אחד חשוב: WebGPU אינה זכות המוענקת בכל מכשיר. זו יכולת לאימות. חלק מהדפדפנים לא תומכים בזה באופן מלא, לחלק מה-GPUs יש מגבלות, חלק מהסביבות הארגוניות משביתות תכונות, חלק מהמשתמשים משתמשים בחומרה צנועה.
58~
59## AI מובנה: כאשר הדפדפן מביא את הדגם
60~
61Chrome דוחף ממשקי API מובנים למשימות כמו הנחיות מקומיות, סיכום, כתיבה, שכתוב, תרגום, זיהוי שפות והגהה. הרעיון מאוד מעניין: הדפדפן מנהל מודל, זמינות ועדכונים; האפליקציה משתמשת ב-API קרוב יותר לפלטפורמה.
62~
63אם זה עובד טוב, זה ישנה הרבה:
64~
65- פחות קריאות שרת למשימות פשוטות;
66- נתונים שעלולים להישאר במכשיר;
67- חביון נמוך יותר;
68- חוויות לא מקוונות או חצי לא מקוונות;
69- UX טבעי יותר לכתיבה ותרגום.
70~
71אבל יש להתייחס אליו כעל שיפור מתקדם. כמה ממשקי API יציבים, אחרים בניסוי מקור או בתצוגה מקדימה, אחרים עדיין תלויים בגרסה, בשפה ובמכשיר.
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~
92הקוד הספציפי ישתנה, אבל הדפוס נשאר: אתה בודק זמינות, מסביר כל הורדה, מציע נפילות ומודד איכות.
93~
94## נפילה היא לא תוכנית עצובה ב'
95~
96נפילה בענן אינה תבוסה. זה חלק מהמוצר.
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~
126ארכיטקטורה זו מאפשרת לך להשתפר בהדרגה. אלה עם תמיכה מקומית מקבלים זמן אחזור ופרטיות טובים יותר. מי שאין לו עדיין משתמש בתכונה. אתה יכול למדוד אחוז של בקשות מקומיות, זמנים, שגיאות, זיכרון, איכות נתפסת ועלות.
127~
128ללא מדדים, AI במכשיר הופך לבחירה אסתטית. עם מדדים, זה הופך למנוף מוצר.
129~
130## ה-UX של הדגם חשוב
131~
132אם הדפדפן צריך להוריד דגם, המשתמש קולט אותו. אל תסתיר את זה מאחורי ספינר מעורפל. מוטב שיהיה ברור: "אנחנו מכינים את המודל להשתמש בפונקציה הזו מהר יותר ואפילו במצב לא מקוון."
133~
134חוויה טובה:
135~
136- מראה את מצב ההכנה;
137- אינו חוסם את כל העמוד;
138- מאפשר לך להמשיך ב-fallback בענן;
139- הימנע מהפתעות סוללה וזיכרון;
140- זכור את הדגם בכל פעם שאפשר;
141- להסביר את התועלת במשפט אחד קונקרטי.
142~
143הדבר הגרוע ביותר הוא תכונה "חכמה" שנראית שבורה כי היא מורידה משהו בשקט.
144~
145## פרטיות: טוב יותר, לא מאובטח אוטומטית
146~
147עיבוד נתונים במכשיר יכול להיות יתרון גדול. טיוטת דוא"ל, מסמך פנימי או הערה אישית לא חייבת לצאת מהדפדפן שלך כדי לקבל הצעה.
148~
149עם זאת, מקומי לא אומר אוטומטית בטוח. עם זאת, אתה צריך לחשוב על:
150~
151- XSS;
152- יומנים מקריים;
153- נתונים שנשמרו באחסון;
154- הזרקה מהירה מתוכן לא מהימן;
155- הרשאות שניתנו לדגם;
156- פלטים המשמשים בפעולות אוטומטיות.
157~
158אם מודל מקומי יכול לקרוא דף אינטרנט ולאחר מכן למלא טופס, דף זה יכול לנסות לתמרן אותו. אם הוא יכול להתקשר לכלי, יש צורך באישור. אם הוא מייצר פלט מובנה, יש לאמת אותו. העובדה שהוא פועל על המכשיר מפחיתה כמה סיכוני פרטיות, אך לא מבטלת את מודל האבטחה.
159~
160## איפה זה נהיה ממש מעניין
161~
162הטקסט הוא רק ההתחלה. WebGPU הופך חוויות אינטרנט לאמינות שעד לאחרונה נראו כמו אפליקציה מקורית:
163~
164- עורכי תלת מימד מורכבים;
165- התזת גאוס בדפדפן;
166- מסנני וידאו בזמן אמת;
167- CAD קל משקל;
168- הדמיות מדעיות;
169- כלים יצירתיים עם תצוגה מקדימה מיידית;
170- מסקנות ראייה ליד ממשק המשתמש;
171- משחקי דפדפן שאפתניים יותר.
172~
173כאן מתחילים להתערבב חזיתות, גרפיקה ולמידת מכונה. זה תחום קצת מביך, אבל גם פורה: הדפדפן חוזר להיות פלטפורמת אפליקציות רצינית, לא רק המקום שבו אנחנו שמים טפסים ודשבורדים.
174~
175## רשימת תיוג לפני הייצור
176~
177לפני שמציגים תכונה במכשיר בפני המשתמשים, הייתי בודק:
178~
1791. מקד לדפדפנים ומכשירים.
1802. ניצול ענן או השפלה אלגנטית.
1813. הורדת מטמון זמן ודגם.
1824. זיכרון וסוללה בחומרה ממוצעת.
1835. איכות בהשוואה לגרסת הענן.
1846. מדיניות פרטיות והודעות משתמשים.
1857. בדיקה עם תשומות עוינות.
1868. מדדים נפרדים עבור זמן ריצה מקומי וענן.
1879. תכנן לעדכן או להשבית את התבנית.
188~
189זו רשימה קונקרטית כי הבעיה היא קונקרטית. תכונת AI איטית, שבירה או אטומה לא הופכת לטובה יותר רק בגלל שהיא פועלת בדפדפן.
190~
191## הפשרה הנכונה
192~
193אני לא מאמין שהעתיד הוא "הכל במכשיר". ואני גם לא חושב שהענן יישאר המקום הסביר היחיד להסקת מסקנות. העתיד הסביר ביותר הוא שילוב: מקומי כאשר הוא משפר את השהייה, הפרטיות או העלות; ענן כאשר יש צורך באיכות, נתונים מעודכנים ובקרה מרכזית.
194~
195WebGPU, WebNN וממשקי AI מובנים אינם הופכים את הדפדפן לכל יכול. הם הופכים אותו למבוגר יותר. ועבור אלה שבונים מוצרי אינטרנט, אלו חדשות ענקיות.
196~
197## מקורות שימושיים
198~
199- [WebGPU API - MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API)
200- [מפרט WebGPU - W3C](https://www.w3.org/TR/webgpu/)
201- [AI מובנה - כרום למפתחים](https://developer.chrome.com/docs/ai/built-in)
202- [ממשקי API מובנים של AI - Chrome למפתחים](https://developer.chrome.com/docs/ai/built-in-apis)
203- [WebNN API](https://webnn.io/)
204~

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

2במשך שנים הדפדפן היה הפנים הנחמדות של האפליקציה והענן היה המקום שבו התרחשו הדברים הקשים. המשתמש כותב, לוחץ, מעלה קובץ; ה-frontend שולח הכל לשרת; השרת קורא למודל; התשובה חוזרת.

4תכנית זו נשארת שימושית מאוד, אך היא אינה חינמית. כל שיחה מביאה שאלות חביון, עלות, תלות ברשת ופרטיות. אם המשתמש כותב משפט ורוצה הצעה, חצי שניה שוקלת. אם אתה מסווג אלפי תשומות קטנות, אגורות הופכות לכסף אמיתי. אם הטקסט רגיש, שליחתו מהמכשיר אינה בחירה ניטרלית.

6זו הסיבה ש-WebGPU ו-AI במכשיר נמצאים בהייפ. לא בגלל שנפעיל מחר כל דגם בדפדפן. מכיוון שחלק מהתכונות החכמות יכולות להתקרב למשתמש.

8## לא הכל חייב להיות מקומי

10הגרסה הילדותית של הטיעון היא: "ענן מול מכשיר". הגרסה השימושית היא היברידית.

11~

12חלק מהמשימות נראות נהדר במכשיר: סיכומים קצרים, זיהוי שפה, שכתוב אור, סיווגים פשוטים, מסנני תמונות, דגמי ראייה קטנים, חוויות יצירתיות עם משוב מיידי.

13~

14משימות אחרות נשארות טובות יותר בענן: חשיבה מורכבת, מודלים חזיתיים, נתונים בצד השרת, ביקורת מרכזית, איכות אחידה, זרימת עבודה שבה אתה צריך לשלוט בקפידה בכל שלב.

15~

16הארכיטקטורה הבריאה מחליטה בזמן הריצה:

17~

18```mermaid

19flowchart TD

20 User[משתמש] --> Browser[דפדפנים]

21 Browser --> Detect[זיהוי תכונות]

22 Detect -->|נתמך| Local[מסקנות מקומיות]

23 Detect -->|לא נתמך| Cloud[נסיגה בענן]

24 Local --> UX[תגובה מהירה]

25 Cloud --> UX

26 UX --> Metrics[מדדים ואיכות]

27```

28~

29הדפדפן לא חייב לנצח מול הענן. זה חייב להציל את הענן מביצוע עבודה שלא צריך לעשות שם.

30~

31## למה WebGPU חשוב

32~

33WebGPU הוא API מודרני לשימוש ב-GPU מהדפדפן. זה לא מיועד רק לגרפיקה תלת מימדית יפה יותר. זה חשוב גם כי הוא חושף פרימיטיביים המתאימים למחשוב: עומסי עבודה מקבילים, הצללות, צינורות קרובים יותר למה שמעבדי GPU עושים טוב.

34~

35עבור AI, הדמיה מדעית, עורכי תלת מימד, מסנני וידאו וכלים יצירתיים, ההבדל הזה מורגש. WebGL עשה הרבה עבור האינטרנט, אבל WebGPU נולד עם דגם המתאים יותר להווה.

36~

37עם זאת, הדבר הראשון שצריך לכתוב הוא לא הצללה. זה זיהוי תכונה מפוכח:

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~

57תכונה זו אומרת דבר אחד חשוב: WebGPU אינה זכות המוענקת בכל מכשיר. זו יכולת לאימות. חלק מהדפדפנים לא תומכים בזה באופן מלא, לחלק מה-GPUs יש מגבלות, חלק מהסביבות הארגוניות משביתות תכונות, חלק מהמשתמשים משתמשים בחומרה צנועה.

58~

59## AI מובנה: כאשר הדפדפן מביא את הדגם

60~

61Chrome דוחף ממשקי API מובנים למשימות כמו הנחיות מקומיות, סיכום, כתיבה, שכתוב, תרגום, זיהוי שפות והגהה. הרעיון מאוד מעניין: הדפדפן מנהל מודל, זמינות ועדכונים; האפליקציה משתמשת ב-API קרוב יותר לפלטפורמה.

62~

63אם זה עובד טוב, זה ישנה הרבה:

64~

65- פחות קריאות שרת למשימות פשוטות;

66- נתונים שעלולים להישאר במכשיר;

67- חביון נמוך יותר;

68- חוויות לא מקוונות או חצי לא מקוונות;

69- UX טבעי יותר לכתיבה ותרגום.

70~

71אבל יש להתייחס אליו כעל שיפור מתקדם. כמה ממשקי API יציבים, אחרים בניסוי מקור או בתצוגה מקדימה, אחרים עדיין תלויים בגרסה, בשפה ובמכשיר.

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~

92הקוד הספציפי ישתנה, אבל הדפוס נשאר: אתה בודק זמינות, מסביר כל הורדה, מציע נפילות ומודד איכות.

93~

94## נפילה היא לא תוכנית עצובה ב'

95~

96נפילה בענן אינה תבוסה. זה חלק מהמוצר.

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~

126ארכיטקטורה זו מאפשרת לך להשתפר בהדרגה. אלה עם תמיכה מקומית מקבלים זמן אחזור ופרטיות טובים יותר. מי שאין לו עדיין משתמש בתכונה. אתה יכול למדוד אחוז של בקשות מקומיות, זמנים, שגיאות, זיכרון, איכות נתפסת ועלות.

127~

128ללא מדדים, AI במכשיר הופך לבחירה אסתטית. עם מדדים, זה הופך למנוף מוצר.

129~

130## ה-UX של הדגם חשוב

131~

132אם הדפדפן צריך להוריד דגם, המשתמש קולט אותו. אל תסתיר את זה מאחורי ספינר מעורפל. מוטב שיהיה ברור: "אנחנו מכינים את המודל להשתמש בפונקציה הזו מהר יותר ואפילו במצב לא מקוון."

133~

134חוויה טובה:

135~

136- מראה את מצב ההכנה;

137- אינו חוסם את כל העמוד;

138- מאפשר לך להמשיך ב-fallback בענן;

139- הימנע מהפתעות סוללה וזיכרון;

140- זכור את הדגם בכל פעם שאפשר;

141- להסביר את התועלת במשפט אחד קונקרטי.

142~

143הדבר הגרוע ביותר הוא תכונה "חכמה" שנראית שבורה כי היא מורידה משהו בשקט.

144~

145## פרטיות: טוב יותר, לא מאובטח אוטומטית

146~

147עיבוד נתונים במכשיר יכול להיות יתרון גדול. טיוטת דוא"ל, מסמך פנימי או הערה אישית לא חייבת לצאת מהדפדפן שלך כדי לקבל הצעה.

148~

149עם זאת, מקומי לא אומר אוטומטית בטוח. עם זאת, אתה צריך לחשוב על:

150~

151- XSS;

152- יומנים מקריים;

153- נתונים שנשמרו באחסון;

154- הזרקה מהירה מתוכן לא מהימן;

155- הרשאות שניתנו לדגם;

156- פלטים המשמשים בפעולות אוטומטיות.

157~

158אם מודל מקומי יכול לקרוא דף אינטרנט ולאחר מכן למלא טופס, דף זה יכול לנסות לתמרן אותו. אם הוא יכול להתקשר לכלי, יש צורך באישור. אם הוא מייצר פלט מובנה, יש לאמת אותו. העובדה שהוא פועל על המכשיר מפחיתה כמה סיכוני פרטיות, אך לא מבטלת את מודל האבטחה.

159~

160## איפה זה נהיה ממש מעניין

161~

162הטקסט הוא רק ההתחלה. WebGPU הופך חוויות אינטרנט לאמינות שעד לאחרונה נראו כמו אפליקציה מקורית:

163~

164- עורכי תלת מימד מורכבים;

165- התזת גאוס בדפדפן;

166- מסנני וידאו בזמן אמת;

167- CAD קל משקל;

168- הדמיות מדעיות;

169- כלים יצירתיים עם תצוגה מקדימה מיידית;

170- מסקנות ראייה ליד ממשק המשתמש;

171- משחקי דפדפן שאפתניים יותר.

172~

173כאן מתחילים להתערבב חזיתות, גרפיקה ולמידת מכונה. זה תחום קצת מביך, אבל גם פורה: הדפדפן חוזר להיות פלטפורמת אפליקציות רצינית, לא רק המקום שבו אנחנו שמים טפסים ודשבורדים.

174~

175## רשימת תיוג לפני הייצור

176~

177לפני שמציגים תכונה במכשיר בפני המשתמשים, הייתי בודק:

178~

1791. מקד לדפדפנים ומכשירים.

1802. ניצול ענן או השפלה אלגנטית.

1813. הורדת מטמון זמן ודגם.

1824. זיכרון וסוללה בחומרה ממוצעת.

1835. איכות בהשוואה לגרסת הענן.

1846. מדיניות פרטיות והודעות משתמשים.

1857. בדיקה עם תשומות עוינות.

1868. מדדים נפרדים עבור זמן ריצה מקומי וענן.

1879. תכנן לעדכן או להשבית את התבנית.

188~

189זו רשימה קונקרטית כי הבעיה היא קונקרטית. תכונת AI איטית, שבירה או אטומה לא הופכת לטובה יותר רק בגלל שהיא פועלת בדפדפן.

190~

191## הפשרה הנכונה

192~

193אני לא מאמין שהעתיד הוא "הכל במכשיר". ואני גם לא חושב שהענן יישאר המקום הסביר היחיד להסקת מסקנות. העתיד הסביר ביותר הוא שילוב: מקומי כאשר הוא משפר את השהייה, הפרטיות או העלות; ענן כאשר יש צורך באיכות, נתונים מעודכנים ובקרה מרכזית.

194~

195WebGPU, WebNN וממשקי AI מובנים אינם הופכים את הדפדפן לכל יכול. הם הופכים אותו למבוגר יותר. ועבור אלה שבונים מוצרי אינטרנט, אלו חדשות ענקיות.

196~

197## מקורות שימושיים

198~

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

200- [מפרט WebGPU - W3C](https://www.w3.org/TR/webgpu/)

201- [AI מובנה - כרום למפתחים](https://developer.chrome.com/docs/ai/built-in)

202- [ממשקי API מובנים של AI - Chrome למפתחים](https://developer.chrome.com/docs/ai/built-in-apis)

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

204~