ML פוקוס עובר לכיוון תוכנה

צומת המקור: 1600819

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

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

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

מעצבי מערכות למידת מכונה מתחילים לדרוש יותר מערכות פיתוח התוכנה ללימוד מכונה (SDK), וחלק מהספקים משתמשים בתוכנה שלהם כדי לקבור את פרטי החומרה. בסופו של דבר, חומרה פחות אופטימלית עם תוכנה טובה עשויה להצליח על פני חומרה טובה יותר עם פחות תוכנה.

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

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

שינוי גדול קרה עם הצגת לוגיקה ניתנת לתכנות של מערך, או PALs, על ידי Monolithic Memories. שני דברים הגבירו את תעשיית ה-PLD באופן כללי. ראשית היה שינוי אדריכלי שהפחית את העלות והגדיל את המהירות. אבל יותר השפעה, הוא ראה את השחרור הראשון של מה שנקרא PAL assembler, המכונה PALASM.

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

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

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

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

העסק היה עד אז נשלט על ידי חברות חומרה, כאשר AMD המובילה (שרכשה את Monolithic Memories). אבל חברות החומרה לא היו טובות בייצור תוכנה, והן לא אהבו לעשות את זה. אז במקום להיאבק בתוכנה, AMD העבירה את העבודה במיקור חוץ לחברת תוכנה קטנה. זו התבררה כטעות אסטרטגית, והחברה יצאה בסופו של דבר מהעסק, מכרה טכנולוגיה מסוימת לחברת הבת של AMD שנרקמה לאחרונה Vantis (שבסופו של דבר לא הצליחה), וחלק ל- Xilinx, אז עולה חדש בזירה עם FPGAs מפוארים (שהיו מוצלחים בטירוף).

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

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

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

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

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

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

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

"אנחנו מקבלים את מערך הנתונים הגדול והלא נקי הזה, וזה ייקח מספר שבועות של לעבור עליו באופן ידני, יישום כלים באופן ידני", אמר קית' שאוב, סגן נשיא לטכנולוגיה ואסטרטגיה ב-Advantest. "יש לך מאות תכונות, לפעמים 1,000 תכונות או יותר, ואתה מנסה להבין את התכונות החשובות ביותר שמתאימות לתחזית שלך. הם מגיעים עם אלה באמצעות שיטות רגרסיה ו[ניתוח רכיבים עיקריים]. ואז יש לך את הדגם הסטטי הזה עם 12 תכונות."

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

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

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

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

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

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

השלב הבא: שמירת החומרה בסוד
בשנה האחרונה ניכר שינוי בענף. בכנסים כמו כנסים של Linley Processor או Hot Chips, חברות הכריזו על הצעות חדשות עם דיון נוסף על התוכנה. ובמיוחד במקרים מסוימים, הם באמת לא מדברים על החומרה הבסיסית.

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

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

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

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

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

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

"אלא אם כן אתה מדבר בשפה שלהם, אין לך סיכוי", אמר ניק ני, מנהל שיווק מוצרים עבור AI ותוכנה ב- Xilinx. "כל ספק מדבר על תמיכת TensorFlow ו-Python כי אין להם דרך אחרת. תרצה או לא תרצה, אתה צריך לתמוך בזה. אבל כדי לתמוך במסגרת כל כך גבוהה, צריך לעשות כל מה שביניהם”.

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

איור 1: האבולוציה של כלי עיצוב, החל בעיצובים ידניים והתקדמות דרך ביטול הטיום, היכולת בפועל לתפעל עיצובים, ולבסוף, לייעל אותם. עם השלבים האחרונים, עיצוב משותף של חומרה/תוכנה הוא קריטי להצלחה. מקור: Bryon Moyer/Semiconductor Engineering

איור 1: האבולוציה של כלי עיצוב, החל בעיצובים ידניים והתקדמות דרך ביטול הטיום, היכולת בפועל לתפעל עיצובים, ולבסוף, לייעל אותם. עם השלבים האחרונים, עיצוב משותף של חומרה/תוכנה הוא קריטי להצלחה. מקור: Bryon Moyer/Semiconductor Engineering

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

"אחת מהנחות היסוד של החברה היא שצורכי התוכנה חייבים להניע את תכנון החומרה", אמר ה-CTO של Quadric.io Nigel Drago בכנס Linley Processor בסתיו האחרון.

באותו כנס, ראווי סטי, סגן נשיא בכיר של רוביירו, הזכיר את תפקיד התוכנה בהגדרת הארכיטקטורה של החברה. "הוספנו אולי 5% מורכבות בחומרה כדי להשיג משהו כמו 90% פשטות במהדר. החומרה אגנוסטית לחלוטין לכל מידע נטו עצבי. זה המהדר שיש לו את כל הידע. והחומרה - זה רק מנוע ביצוע".

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

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

זה יכול ליצור אתגר עבור תוכנה המכוונת לחומרה מיוחדת. "לכל ארכיטקטורה יתרונות ייחודיים והיא מותאמת למקרי שימוש ספציפיים", הסביר Anoop Saha, מנהל בכיר, אסטרטגיה וצמיחה בסימנס EDA. "אבל האתגר עבור המשתמש נשאר - איך הם יכולים להרכיב את הרשת שלו על ארכיטקטורת חומרה ספציפית? ואם הם מסוגלים לעשות את זה, איך הם יכולים לייעל את זה עבור החומרה המסוימת ולמנף את הרכיבים השונים הזמינים? האופטימיזציות והגמישות הספציפיים לחומרה צריכים להיות מטופלים על ידי תוכנה בצורה אוטומטית יותר."

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

נראה ש-ML הולך בדרך דומה. "חידושים בחומרה המספקים יתרונות משמעותיים בכוח ובמהירות עוטפים את עצמם מתחת למסגרת תוכנה או API נפוצה", אמרה אנגרה מ-Infineon. "זה אומר שהם מספקים רווחים משמעותיים בהפעלת ML ללא הכאב של תוכנה 'לא מתוחכמת'."

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

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

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

מקור: https://semiengineering.com/ml-focus-shifting-toward-software/

בול זמן:

עוד מ הנדסת מוליכים למחצה