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

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

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

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

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

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

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

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

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

למה WebGPU חשוב

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

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

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

export async function requestWebGpuDevice() {
  if (!('gpu' in navigator)) {
    return null;
  }

  const adapter = await navigator.gpu.requestAdapter({
    powerPreference: 'high-performance',
  });

  if (!adapter) {
    return null;
  }

  return adapter.requestDevice();
}

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

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

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

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

• פחות קריאות שרת למשימות פשוטות;
• נתונים שעלולים להישאר במכשיר;
• חביון נמוך יותר;
• חוויות לא מקוונות או חצי לא מקוונות;
• UX טבעי יותר לכתיבה ותרגום.

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

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

export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
  const SummarizerApi = (globalThis as any).Summarizer;

  if (!SummarizerApi?.availability) {
    return 'unsupported';
  }

  const availability = await SummarizerApi.availability();

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

  return 'unsupported';
}

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

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

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

interface AiRequest {
  task: 'summarize' | 'rewrite' | 'classify';
  input: string;
}

interface AiResult {
  output: string;
  runtime: 'local' | 'cloud';
}

export async function runAiTask(request: AiRequest): Promise<AiResult> {
  const local = await tryLocalAi(request);

  if (local) {
    return { output: local, runtime: 'local' };
  }

  const cloud = await fetch('/api/ai', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(request),
  }).then((res) => res.json());

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

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

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

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

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

חוויה טובה:

• מראה את מצב ההכנה;
• אינו חוסם את כל העמוד;
• מאפשר לך להמשיך ב-fallback בענן;
• הימנע מהפתעות סוללה וזיכרון;
• זכור את הדגם בכל פעם שאפשר;
• להסביר את התועלת במשפט אחד קונקרטי.

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

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

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

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

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

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

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

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

• עורכי תלת מימד מורכבים;
• התזת גאוס בדפדפן;
• מסנני וידאו בזמן אמת;
• CAD קל משקל;
• הדמיות מדעיות;
• כלים יצירתיים עם תצוגה מקדימה מיידית;
• מסקנות ראייה ליד ממשק המשתמש;
• משחקי דפדפן שאפתניים יותר.

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

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

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

1. מקד לדפדפנים ומכשירים.
2. ניצול ענן או השפלה אלגנטית.
3. הורדת מטמון זמן ודגם.
4. זיכרון וסוללה בחומרה ממוצעת.
5. איכות בהשוואה לגרסת הענן.
6. מדיניות פרטיות והודעות משתמשים.
7. בדיקה עם תשומות עוינות.
8. מדדים נפרדים עבור זמן ריצה מקומי וענן.
9. תכנן לעדכן או להשבית את התבנית.

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

הפשרה הנכונה

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

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

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

• WebGPU API - MDN
• מפרט WebGPU - W3C
• AI מובנה - כרום למפתחים
• ממשקי API מובנים של AI - Chrome למפתחים
• WebNN API