השג אירוח עם אחזור נמוך עבור דגמי ML מבוססי עץ החלטות ב-NVIDIA Triton Inference Server ב-Amazon SageMaker

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

כאשר אתה מעריך את המטרות שלך ביחס להסקת מודל ML, ניתן לשקול אפשרויות רבות, אך מעטות יכולות ומוכחות כמו אמזון SageMaker עם שרת מסקנות טריטון. SageMaker עם Triton Inference Server הייתה בחירה פופולרית עבור לקוחות רבים מכיוון שהוא נבנה למקסימום התפוקה וניצול החומרה עם זמן השהייה נמוך במיוחד (אלפיות שניות חד ספרתיות). יש לו מגוון רחב של מסגרות ML נתמכות (כולל TensorFlow, PyTorch, ONNX, XGBoost ו-NVIDIA TensorRT) ותשתיות עורפיות, כולל NVIDIA GPUs, CPUs, ו Afer Inferentia. בנוסף, Triton Inference Server משולב עם SageMaker, שירות ML מנוהל מלא מקצה לקצה, המספק אפשרויות מסקנות בזמן אמת לאירוח דגמים.

בפוסט זה, אנו עוברים על פריסת עומס עבודה של אנסמבל זיהוי הונאה ל- SageMaker עם Triton Inference Server.

סקירת פתרונות

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

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

• תקציב השהייה בצד הלקוח – הוא מציין את זמן ההמתנה המקסימלי המקובל בצד לקוח הלוך ושוב לתגובת מסקנות, המבוטא בדרך כלל באחוזונים. עבור עומסי עבודה הדורשים תקציב השהייה קרוב לעשרות אלפיות השנייה, העברות רשת עלולות להיות יקרות, כך ששימוש במודלים בקצה יתאים יותר.
• גודל הפצת מטען נתונים - מטען, המכונה לעתים קרובות גוף ההודעה, הוא נתוני הבקשה המועברים מהלקוח למודל, כמו גם נתוני התגובה המועברים מהמודל ללקוח. לגודל המטען יש לרוב השפעה גדולה על זמן ההשהיה ויש לקחת אותו בחשבון.
• פורמט נתונים - זה מציין כיצד המטען נשלח למודל ML. הפורמט יכול להיות קריא לאדם, כגון JSON ו-CSV, אולם ישנם גם פורמטים בינארים, שלעתים קרובות הם דחוסים וקטנים יותר בגודלם. זהו פשרה בין תקורה של דחיסה לגודל העברה, כלומר מתווספים מחזורי CPU והשהייה לדחיסה או ביטול דחיסה, על מנת לחסוך בתים שהועברו ברשת. פוסט זה מראה כיצד להשתמש הן בפורמטים של JSON והן בפורמטים בינאריים.
• דרושים ערימת תוכנה ורכיבים - מחסנית היא אוסף של רכיבים הפועלים יחד כדי לתמוך ביישום ML, כולל מערכת הפעלה, זמני ריצה ושכבות תוכנה. Triton מגיע עם מסגרות ML פופולריות מובנות, הנקראות backends, כגון ONNX, TensorFlow, FIL, OpenVINO, Python מקורי ואחרים. אתה יכול גם לכתוב א אחורי מותאם אישית עבור רכיבים תוצרת בית משלך. פוסט זה עובר על מודל XGBoost ועיבוד מקדים של נתונים, אותם אנו מעבירים ל-NVIDIA המסופק ב-FIL ו-Python Triton, בהתאמה.

כל הגורמים הללו צריכים למלא תפקיד חיוני בהערכת ביצועי עומסי העבודה שלך, אך במקרה השימוש הזה אנו מתמקדים בעבודה הדרושה כדי להעביר את דגמי ה-ML שלך להתארח ב- SageMaker עם Triton Inference Server. באופן ספציפי, אנו משתמשים בדוגמה של אנסמבל זיהוי הונאה המורכב ממודל XGBoost עם לוגיקה של עיבוד מקדים שנכתב ב-Python.

NVIDIA Triton Inference Server

Triton Inference Server תוכנן מהיסוד כדי לאפשר לצוותים לפרוס, להריץ ולהתאים דגמי AI מאומנים מכל מסגרת בתשתית מבוססת GPU או CPU. בנוסף, הוא עבר אופטימיזציה כדי להציע הסקת ביצועים גבוהים בקנה מידה עם תכונות כמו אצווה דינמית, ריצות במקביל, תצורת מודל אופטימלית, מכלול מודלים ותמיכה בכניסות סטרימינג.

התרשים הבא מציג דוגמה לצינור אנסמבל NVIDIA Triton.

עומסי עבודה צריכים לקחת בחשבון את היכולות ש-Triton מספקת יחד עם אירוח SageMaker כדי למקסם את היתרונות המוצעים. לדוגמה, Triton תומך ב-HTTP וכן ב-a C API, המאפשרים גמישות וכן אופטימיזציה של מטען בעת ​​הצורך. כפי שהוזכר קודם, Triton תומך במספר מסגרות פופולריות מחוץ לקופסה, כולל TensorFlow, PyTorch, ONNX, XGBoost ו-NVIDIA TensorRT. מסגרות אלה נתמכות דרך קצה גחור של Triton, ובמקרה נדיר שקצה אחורי אינו תומך במקרה השימוש שלך, Triton מאפשר לך ליישם את שלך ולשלב אותו בקלות.

התרשים הבא מציג דוגמה לארכיטקטורת NVIDIA Triton.

NVIDIA Triton על SageMaker

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

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

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

תמיכה בקצה האחורי של NVIDIA FIL

עם מהדורת גרסה 22.05 של Triton, NVIDIA תומכת כעת בדגמי יער שהוכשרו על ידי מספר מסגרות ML פופולריות, כולל XGBoost, LightGBM, Scikit-learn ו-cuML. בעת שימוש ב-FIL backend עבור Triton, עליך לוודא שהפריטים המודלים שאתה מספק נתמכים. לדוגמה, FIL תומך model_type xgboost, xgboost_json, lightgbm, או treelite_checkpoint, המציין אם המודל שסופק הוא בפורמט בינארי XGBoost, פורמט XGBoost JSON, פורמט טקסט LightGBM או פורמט בינארי Treelite, בהתאמה.

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

בנוסף להבטחת התבנית המתאימה של הדגם, יש לקחת שיקולים נוספים. הקצה האחורי של FIL עבור Triton מספק אפשרויות הניתנות להגדרה עבור מפתחים כדי לכוונן את עומסי העבודה שלהם ולמטב את ביצועי ריצת המודל. התצורה dynamic_batching מאפשר ל-Triton להחזיק בקשות מצד הלקוח ולצרף אותן באצווה בצד השרת, על מנת להשתמש ביעילות בחישוב המקביל של FIL כדי להסיק את כל האצווה יחד. האפשרות max_queue_delay_microseconds מציע שליטה בטוחה בכשל של כמה זמן טריטון ממתין ליצירת אצווה. FIL מגיע עם Shapley explainer, אותו ניתן להפעיל על ידי התצורה treeshap_output; עם זאת, עליך לזכור שתפוקות Shapley פוגעות בביצועים בשל גודל הפלט שלה. היבט חשוב נוסף הוא storage_type על מנת לבצע פשרה בין טביעת זיכרון לזמן ריצה. לדוגמה, שימוש באחסון כ-SPARSE יכול להפחית את צריכת הזיכרון, בעוד ש-DENSE יכול להפחית את ביצועי הריצה של המודל שלך על חשבון שימוש גבוה יותר בזיכרון. ההחלטה על הבחירה הטובה ביותר עבור כל אחד מאלה תלויה בעומס העבודה שלך ובתקציב האחזור שלך, לכן אנו ממליצים לבדוק לעומק את כל האפשרויות ב- שאלות נפוצות של FIL backend ו רשימת התצורות הזמינות ב-FIL.

שלבים לאירוח דגם על טריטון

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

זהה את עומס העבודה שלך

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

זהה מדדי ביצועים נוכחיים ויעדים ויעדים אחרים שעשויים לחול

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

עבוד אחורה כדי לקבוע אם Triton יכול לארח את עומס העבודה שלך בהתבסס על הדרישות שלך

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

כפי שהוזכר קודם לכן, זה גם קריטי לקבוע אם Triton תומך ב-backend שיכול לשרת את החפצים שלך. טריטון תומך במספר backends המותאמים לתמיכה במסגרות שונות כמו PyTorch ו-TensorFlow. בדוק כדי לוודא שהדגמים שלך נתמכים ושיש לך את פורמט הדגם המתאים לו מצפה טריטון. כדי לעשות זאת, בדוק תחילה באילו דגמים פורמטים תומך הקצה האחורי של Triton. במקרים רבים, זה לא מצריך שינויים בדגם. במקרים אחרים, המודל שלך עשוי לדרוש שינוי לפורמט אחר. בהתאם למקור ולפורמט היעד, קיימות אפשרויות שונות, כגון שינוי א קובץ החמוצים של Python לשימוש בפורמט נקודת המחסום הבינארית של Treelite.

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

צור תוכנית והעריך את המאמץ הנדרש כדי להשתמש בטריטון לאירוח

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

• חפצי מודל הנדרשים על-ידי הקצה האחורי של Triton
• קבצי תצורה של טריטון
• תיקיית מאגר מודלים עם המבנה המתאים

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

הפעל את התוכנית ואמת את התוצאות

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

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

יישום

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

המחברת הראשונה מציגה מחברת קיימת שיש לארגון שלך המשתמשת ב- אֶשֶׁד חבילת ספריות וקרנל RAPIDS Conda. מופע זה פועל על סוג מופע G4DN המסופק על ידי AWS, אשר מואצת GPU באמצעות מעבדי NVIDIA T4.

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

המחברת הראשונה מסתיימת באימון דגם XGBoost שלנו ושמירת החפצים בהתאם.

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

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

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

• עיבוד מוקדם של חפצים (model.py, label_encoders.pkl)
• חפצי דגם XGBoost (xgboost.json)

ה-Python backend ב-Triton מחייב אותנו להשתמש בסביבת Conda כתלות. במקרה זה, אנו משתמשים ב-backend של Python כדי לעבד מראש את הנתונים הגולמיים לפני הזנתם למודל XGBoost המתנהל ב-FIL backend. למרות שבמקור השתמשנו בספריות RAPIDS cuDF ו-cuML כדי לבצע את עיבוד הנתונים המקדים (כפי שהוזכר קודם לכן באמצעות ה-GPU שלנו), כאן אנו משתמשים ב-Pandas וב-Skikit-learn כתלות בעיבוד מקדים לזמן ההסקה (באמצעות המעבד שלנו). אנו עושים זאת משלוש סיבות:

• כדי להראות כיצד ליצור סביבת Conda עבור התלות שלך וכיצד לארוז אותה ב- פורמט צפוי על ידי ה-Python Backend של Triton.
• על ידי הצגת מודל העיבוד המקדים הפועל ב-Python backend במעבד בעוד שמודל XGBoost פועל על ה-GPU ב-FIL backend, אנו ממחישים כיצד כל דגם בצינור האנסמבל של טריטון יכול לרוץ ב-framework backend שונה, ולרוץ על חומרה שונה עם שונה תצורות.
• זה מדגיש כיצד ספריות RAPIDS (cuDF, cuML) תואמות למקבילות המעבד שלהן (Pandas, Scikit-learn). כך נוכל להראות כיצד LabelEncoders נוצר ב-cuML ניתן להשתמש ב-Skikit-learn ולהיפך. שים לב שאם אתה מצפה לעבד כמויות גדולות של נתונים טבלאיים במהלך זמן ההסקה, אתה עדיין יכול להשתמש ב-RAPIDS כדי להאיץ את ה-GPU.

נזכיר שיצרנו את label_encoders.pkl קובץ במחברת הראשונה. אין יותר מה לעשות עבור קידוד קטגוריות מלבד לכלול אותה בקידוד שלנו model.py קובץ לעיבוד מקדים.

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

עבור דגם XGBoost, אין צורך לעשות דבר נוסף. אימנו את הדגם במחברת הראשונה וה-FIL backend של Triton אינו דורש מאמץ נוסף עבור דגמי XGBoost.

לאחר מכן, אנחנו צריכים את קבצי התצורה של Triton. כל דגם באנסמבל טריטון דורש א config.pbtxt קוֹבֶץ. בנוסף, אנו יוצרים גם א config.pbtxt קובץ עבור האנסמבל כולו. קבצים אלה מאפשרים לטריטון לדעת מטא נתונים על האנסמבל עם מידע כגון הקלט והפלטים שאנו מצפים להם וכן לעזור בהגדרת ה-DAG המשויך לאנסמבל.

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

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

כעת נוכל ליצור מודל של SageMaker ממאגר הדגמים שהעלינו לאמזון S3 בשלב הקודם.

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

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

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

לבסוף, אנו משתמשים בתצורת נקודת הקצה הקודמת כדי ליצור נקודת קצה חדשה של SageMaker ומחכים לסיום הפריסה. הסטטוס משתנה ל InService לאחר שהפריסה תצליח.

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

<br> סיכום

בפוסט זה, הדרכנו אותך בפריסת עומס עבודה של אנסמבל XGBoost ל- SageMaker עם Triton Inference Server. העברת עומסי עבודה ל-Triton ב- SageMaker יכולה להיות החזר מועיל על ההשקעה. כמו בכל אימוץ טכנולוגיה, תהליך בדיקה ותוכנית הם המפתח, ופירטנו תהליך בן חמישה שלבים כדי להדריך אותך במה לשקול בעת העברת עומסי העבודה שלך. בנוסף, צללנו עמוק לתוך השלבים הדרושים לפריסת אנסמבל שמשתמש בעיבוד מקדים של Python ובמודל XGBoost על Triton ב- SageMaker.

SageMaker מספקת את הכלים להסיר את ההרמה הכבדה הבלתי מובחנת מכל שלב במחזור החיים של ה-ML, ובכך מאפשרת את הניסויים והחקירה המהירים הדרושים למיטוב מלא של פריסות המודל שלך. תמיכת אירוח SageMaker עבור Triton Inference Server מאפשרת עומסי עבודה עם אחזור נמוך, עסקאות גבוהות בשנייה (TPS).

תוכל למצוא את המחברות המשמשות לדוגמה זו ב- GitHub.

---

על הסופר

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

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

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

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

אליוט טריאנה הוא מנהל קשרי מפתחים ב-NVIDIA. הוא מחבר בין מובילי מוצר, מפתחים ומדענים של אמזון ו-AWS עם טכנולוגים ומובילי מוצר של NVIDIA כדי להאיץ את עומסי העבודה של אמזון ML/DL, מוצרי EC2 ושירותי AI של AWS. בנוסף, אליוט הוא רוכב הרים נלהב, גולש סקי ושחקן פוקר.