יש לי חדשות טובות: פיתחתם אפליקציה מגניבה של Web AI שמריצה מודלים של למידת מכונה ישירות במכשיר של המשתמש. היא פועלת רק בדפדפן האינטרנט בצד הלקוח, בלי להסתמך על הענן. העיצוב הזה במכשיר משפר את פרטיות המשתמשים, משפר את הביצועים ומפחית את העלויות משמעותית.
אבל יש מכשול. המודל TensorFlow.js יכול לפעול גם במעבדי CPU (WebAssembly) וגם במעבדי GPU חזקים יותר (דרך WebGL ו-WebGPU). השאלה היא: איך אפשר לבצע באופן עקבי אוטומציה של בדיקת הדפדפן באמצעות החומרה שנבחרה?
שמירה על עקביות היא חיונית להשוואת ביצועים של מודלים של למידת מכונה לאורך זמן כשחוזרים על עצמם ומשפרים אותם, לפני הפריסה למשתמשים בפועל במכשירים שלהם.
יכול להיות קשה מהצפוי להגדיר סביבת בדיקה עקבית עם מעבדי GPU. בפוסט הזה נשתף את הבעיות שבהן נתקלנו ואת האופן שבו פתרנו אותן, כדי שתוכלו לשפר את ביצועי האפליקציה שלכם.
המידע הזה לא מיועד רק למפתחי AI באינטרנט! אם אתם עובדים על משחקים באינטרנט או על גרפיקה, הפוסט הזה חשוב גם לכם.
מה כולל ארגז הכלים שלנו לאוטומציה
הנה מה שאנחנו משתמשים בו:
- סביבה: notebook של Google Colab מבוסס Linux שמחובר ל-GPU של NVIDIA או V100. אם רוצים, אפשר להשתמש בפלטפורמות ענן אחרות כמו Google Cloud (GCP).
- דפדפן: Chrome תומך ב-WebGPU, המשך עוצמתי של WebGL, שהופך את הפיתוחים של ממשקי API מודרניים ל-GPU לאינטרנט.
- Automation: Puppeteer היא ספרייה של Node.js שמאפשרת לשלוט בדפדפנים באופן פרוגרמטי באמצעות JavaScript. עם Puppeteer, אנחנו יכולים לבצע אוטומציה של Chrome במצב 'דפדפן ללא GUI', כלומר, הדפדפן פועל בשרת ללא ממשק גלוי. אנחנו משתמשים במצב החדש והמשופר של דפדפן ללא GUI ולא בגרסה מדור קודם.
אימות הסביבה
הדרך הטובה ביותר לבדוק אם ההגדרה 'שיפור מהירות באמצעות חומרה' מופעלת ב-Chrome היא להקליד chrome://gpu
בסרגל הכתובות. תוכלו להשתמש בפקודה לבצע את הפעולה המקבילה עם Puppeteer באמצעות console.log
או לשמור את הדוח המלא כקובץ PDF כדי לבדוק אותו באופן ידני:
/* 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();
פותחים את chrome://gpu
והתוצאות הבאות אמורות להתקבל:
הסטטוס של תכונת הגרפיקה | |
---|---|
OpenGL: | מושבת |
Vulkan: | מושבת |
WebGL: | תוכנה בלבד, שיפור המהירות באמצעות חומרה לא זמין. |
WebGL2: | תוכנה בלבד, שיפור המהירות באמצעות חומרה לא זמין. |
WebGPU: | מושבת |
זוהו בעיות. |
לא התחלה טובה. ברור למדי שזיהוי החומרה נכשל. WebGL, WebGL2 ו-WebGPU מושבתים למעשה, או שתוכנות בלבד. אנחנו לא לבד בבעיה הזו – יש מספר דיונים באינטרנט על אנשים שנמצאים במצב דומה, כולל בערוצי התמיכה הרשמיים של Chrome (1), (2).
הפעלת התמיכה ב-WebGPU וב-WebGL
כברירת מחדל, אפליקציית Headless Chrome משביתים את ה-GPU. כדי להפעיל אותו ב-Linux, יש להחיל את כל הדגלים הבאים כשמפעילים את דפדפן Chrome ללא ממשק גרפי:
- הדגל
--no-sandbox
משבית את ארגז החול לאבטחה של Chrome, שמבודד את תהליך הדפדפן משאר המערכת. אין תמיכה בהפעלת Chrome ברמה הבסיסית (root) בלי ארגז החול הזה. - הדגל
--headless=new
מפעיל את Chrome עם מצב 'דפדפן ללא GUI' החדש והמשופר, בלי ממשק משתמש גלוי. - הדגל
--use-angle=vulkan
מורה ל-Chrome להשתמש בקצה העורפי Vulkan עבור ANGLE, שמתרגם קריאות 2/3 של OpenGL ES לקריאות של Vulkan API. - הדגל
--enable-features=Vulkan
מפעיל את הקצה העורפי של Vulkan של הגרפיקה לצורך הרכבה ויצירת רסטר ב-Chrome. - הדגל
--disable-vulkan-surface
משבית את תוסף המכונה vulkanVK_KHR_surface
. במקום להשתמש ב-splacementchain, משתמשים ב-Bit blit לתוצאת העיבוד הנוכחית במסך. - הדגל
--enable-unsafe-webgpu
מפעיל את WebGPU API הניסיוני ב-Chrome ב-Linux ומשבית את רשימת החסימה של המתאמים.
עכשיו נשלב את כל השינויים שביצענו עד עכשיו. הנה התסריט המלא.
/* 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();
מריצים את הסקריפט שוב. לא זוהו בעיות ב-WebGPU והערך משתנה מ-מושבת לתוכנה בלבד.
הסטטוס של תכונת הגרפיקה | |
---|---|
OpenGL: | מושבת |
Vulkan: | מושבת |
WebGL: | תוכנה בלבד, שיפור המהירות באמצעות חומרה לא זמין. |
WebGL2: | תוכנה בלבד, שיפור המהירות באמצעות חומרה לא זמין. |
WebGPU: | תוכנה בלבד, שיפור המהירות באמצעות חומרה לא זמין. |
עם זאת, ההגדרה 'שיפור המהירות באמצעות חומרה' עדיין לא זמינה, ולכן ה-GPU של NVIDIA T4 לא מזוהה.
התקנת מנהלי ההתקנים הנכונים של GPU
חקרנו בצורה מעמיקה יותר את הפלט של chrome://gpu
עם כמה מומחי GPU בצוות Chrome. זיהינו בעיות במנהלי ההתקנים שמוגדרים כברירת מחדל במכונה של Linux Colab, שגרמו לבעיות ב-Vulkan, ולכן Chrome לא יכול לזהות את ה-GPU של NVIDIA T4 ברמת GL_RENDERER
כמו שמוצג בפלט הבא. הדבר גורם לבעיות עם דפדפן Chrome ללא ממשק גרפי.
פרטי הנהג/ת | |
---|---|
GL_RENDERER | ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (Subzero) (0x0000C0DE)), SwiftShader -5.0.0) |
לכן, התקנת מנהלי ההתקנים הנכונים שהותאמה תפתור את הבעיה.
פרטי הנהג/ת | |
---|---|
GL_RENDERER | ANGLE (NVIDIA Corporation, Tesla T4/PCIe/SSE2, OpenGL ES 3.2 NVIDIA 525.105.17) |
כדי להתקין את מנהלי ההתקנים הנכונים, מריצים את הפקודות הבאות במהלך ההגדרה. שתי השורות האחרונות עוזרות לתעד את הפלט של מה שמנהלי ההתקנים של NVIDIA מזהים יחד עם vulkaninfo
.
apt-get install -y vulkan-tools libnvidia-gl-525
// Verify the NVIDIA drivers detects along with vulkaninfo
nvidia-smi
vulkaninfo --summary
עכשיו מריצים שוב את הסקריפט ומקבלים את התוצאה הבאה. 🎉
הסטטוס של תכונת הגרפיקה | |
---|---|
OpenGL: | מופעל |
Vulkan: | מופעל |
WebGL: | החומרה האיצה את הביצועים, אבל הביצועים שלה ירדו. |
WebGL2: | החומרה האיצה את הביצועים, אבל הביצועים שלה ירדו. |
WebGPU: | החומרה האיצה את הביצועים, אבל הביצועים שלה ירדו. |
על ידי שימוש במנהלי ההתקנים ובדגלים הנכונים בזמן הפעלת Chrome, יש לנו עכשיו תמיכה ב-WebGPU וב-WebGL באמצעות מצב 'דפדפן ללא GUI' חדש ומבריק.
מאחורי הקלעים: החקירה של הצוות שלנו
אחרי מחקרים רבים, לא מצאנו שיטות עבודה שמתאימות לסביבה שהיינו צריכים להפעיל ב-Google Colab, אבל היו כמה פוסטים בתקווה שעבדו בסביבות אחרות, היו מבטיחות. בסופו של דבר, לא הצלחנו לשחזר את ההצלחה שלהם בסביבת Colab NVIDIA T4, כי היו לנו 2 בעיות עיקריות:
- חלק משילובי הדגלים מאפשרים זיהוי של ה-GPU, אבל לא מאפשרים להשתמש ב-GPU בפועל.
- דוגמאות לפתרונות פועלים על ידי צדדים שלישיים השתמשו בגרסה הישנה של Chrome ללא GUI, שבשלב מסוים תוצא משימוש לטובת הגרסה החדשה. אנחנו היינו צריכים פתרון שעבד עם הגרסה החדשה של Headless Chrome כדי לספק הגנה טובה יותר לעתיד.
אישרנו את השימוש ב-GPU על ידי הרצת דף אינטרנט לדוגמה של TensorFlow.js לזיהוי תמונות, שבו אימנו מודל לזהות דוגמיות בגדים (כמו 'hello world' של למידת מכונה).
במכונה רגילה, 50 מחזורי אימון (שנקראים תקופות אימון) צריכים לרוץ כל אחד פחות משנייה אחת. באמצעות קריאה ל-Chrome ללא GUI במצב ברירת המחדל שלו, יכולנו לתעד את הפלט של מסוף ה-JavaScript בשורת הפקודה בצד השרת של Node.js כדי לראות את המהירות של מחזורי האימון האלה בפועל.
כמצופה, כל תקופת אימון נמשכה הרבה יותר זמן מהצפוי (כמה שניות), מה שמרמז על כך ש-Chrome חזר להפעלת מעבד (CPU) ישנה של JS במקום להשתמש ב-GPU:
![תקופות האימון נעות בקצב איטי יותר.](https://developer.chrome.com/blog/supercharge-web-ai-testing/image/initial_epoch_timing.gif?authuser=5&hl=he)
אחרי תיקון מנהלי ההתקנים ושימוש בשילוב הנכון של דגלים ב-Headless Chrome, הרצה מחדש של הדוגמה לאימון TensorFlow.js מובילה לתקופות אימון מהירות הרבה יותר.
![יש עלייה במהירות בתקופות של זמן מערכת.](https://developer.chrome.com/blog/supercharge-web-ai-testing/image/epoch_timing_with_headless.gif?authuser=5&hl=he)
סיכום
הבינה המלאכותית באינטרנט (Web AI) גדלה בשיעור אקספוננציאלי מאז שהיא נוצרה ב-2017. בעזרת טכנולוגיות דפדפן כמו WebGPU, WebGL ו-WebAssembly, אפשר להאיץ עוד יותר את הפעולות המתמטיות של מודל למידת מכונה בצד הלקוח.
נכון ל-2023, TensorFlow.js ו-MediaPipe Web חצו יותר ממיליארד הורדות של מודלים וספריות – ציון דרך היסטורי וביטוי לאופן שבו מפתחי ומהנדסים עוברים להשתמש ב-AI באפליקציות האינטרנט של הדור הבא שלהם כדי ליצור פתרונות מדהימים.
אחרי הצלחה גדולה בשימוש, נדרשת אחריות גדולה. ברמה הזו של שימוש במערכות ייצור, עולה הצורך לבדוק מודלים של AI מבוססת-דפדפן בצד הלקוח בסביבת דפדפן אמיתית, ובמקביל גם להיות ניתנים להרחבה, יכולים לבצע אוטומציה ותוך כדי הגדרת חומרה סטנדרטית ידועה.
כך שתוכלו לבדוק עומסי עבודה כאלה בסביבה סטנדרטית שניתן לשכפל, וכך להבטיח תוצאות עקביות ואמינות.
סיכום
במסמכי התיעוד שלנו יש מדריך מפורט, כך שאתם יכולים לנסות את ההגדרה המלאה בעצמכם.
אם המאמר הזה עזר לכם, תוכלו להגיד תודה ב-LinkedIn, ב-X (לשעבר Twitter) או בכל רשת חברתית אחרת שבה אתם משתמשים עם ה-hashtag הבא: #WebAI. נשמח לקבל ממך משוב כדי שנוכל לכתוב עוד דברים כאלה בעתיד.
כדאי להוסיף כוכב במאגר GitHub כדי לקבל עדכונים עתידיים.
אישורים
תודה רבה לכל חברי צוות Chrome שעזרו לנפות את הבאגים שגרמו לבעיות של מנהל התקן ושל WebGPU בפתרון הבעיה, ותודה מיוחדת לג'סלין יין ולאלכסנדרה ווייט (Alexandra White) על העזרה לכתיבת הפוסט בבלוג. תודה ליולי נוביקוב, אנדריי קוסיאקוב ואלכס רודנקו שסייעו ביצירת הפתרון המוצלח הסופי.