רישות לפרסום מודל היסק (inference) של AI בכל הבק-אנדים

Last reviewed 2026-05-20 UTC

במסמך הזה מוצגת ארכיטקטורת הפניה ליצירת חזית אחודה למספר מודלים של AI שמארחים אותם בפריסה מקומית או אצל ספק כלשהו, כולל צד שלישי ו- Google Cloud. אם כל שרתי ההסקה שלכם מאוחסנים ב-Google Kubernetes Engine ‏(GKE), כדאי לעיין במאמר Networking for AI inference model serving on GKE (רשתות להגשת מודלים של AI להסקה ב-GKE).

הארכיטקטורה הזו נועדה לאפשר למפתחים לבחור מודלים בלי צורך לציין כתובות IP נפרדות לכל מודל. במקום זאת, המפתחים שולחים בקשות ל-OpenAI API שכוללות את שם המודל לנקודת הקצה של הקצה הקדמי. המערכת בארכיטקטורה מנתבת את הבקשות לבק-אנד שמארח את המודל שצוין. מאזן העומסים (LB) של הקצה הקדמי בארכיטקטורה מספק את הפונקציות האדמיניסטרטיביות המרכזיות הבאות:

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

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

ארכיטקטורה

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

סקירה כללית של רשתות להסקת מסקנות מ-AI.

הארכיטקטורה בתרשים כוללת את הרכיבים הבאים:

  • נקודת קצה של Private Service Connect להסקת מסקנות: נקודת קצה מאוחדת לכל המודלים המתארחים. משתמש הקצה שולח בקשות להסקת מסקנות לכתובת ה-IP של נקודת הקצה. בתרשים מוצגת נקודת קצה של Private Service Connect ברשת VPC יחידה של צרכן. אפשר לארח נקודות קצה בכמה רשתות VPC או ברשת VPC של שירותים משותפים.
  • מאזן עומסים פנימי אזורי של אפליקציות (ALB): בארכיטקטורה הזו, מאזן העומסים של חזית האתר הוא מאזן עומסים פנימי אזורי של אפליקציות. מאזן העומסים של הקצה הקדמי מנתב את תעבורת הנתונים למאגרי רפליקות על סמך שם המודל שצוין בבקשה. בארכיטקטורה הזו, אפליקציית הלקוח מבצעת קריאות ל-OpenAI API כדי לאזן את העומס. אם שרת ההסקה של הקצה העורפי תואם ל-OpenAI API, הפעולה מתבצעת בצורה שקופה. אם שרת ההסקה לא תואם ל-OpenAI API, צריך להטמיע מתרגם API באמצעות Service Extensions. ארכיטקטורת ההפניה הזו לא כוללת את ההטמעה של מתרגם API.
  • קריאות ל-Service Extensions: אתם יכולים להשתמש בהפניות כדי להוסיף עיבוד נוסף למאזן עומסים של אפליקציות. הארכיטקטורה בעיצוב הזה כוללת את ההערות הבאות:
    • נתב מבוסס-גוף: הנתב מבוסס-הגוף נפרס ב-Cloud Run. הוא קורא את שם המודל מגוף בקשת ה-API של OpenAI וכותב אותו לשדה X-Gateway-Model-Name בכותרת. מפת ה-URL של מאזן העומסים משתמשת בשדה כדי להעביר את הבקשה לשירות לקצה העורפי המתאים. פריסת Terraform שמסופקת עם ארכיטקטורת ההפניה הזו כוללת את ההגדרה של הנתב מבוסס-הגוף.
    • ‫Apigee: כלי לניהול API שמספק אימות API, אבטחה, הגבלת קצב של יצירת בקשות, מעקב אחר מכסות ושירותים אחרים לניהול API. הארכיטקטורה הזו משתמשת ב-Apigee, אבל היא תומכת באפשרויות אחרות. כדי להתקשר ל-Apigee ממאזן העומסים, הארכיטקטורה ופריסת Terraform משתמשות בתוסף תעבורה של Service Extensions כדי להתקשר למעבד Apigee Extension.
    • ‫הגנה מוגברת על המודל: מערכת של אמצעי הגנה מבוססי-AI שמבצעת בדיקות בטיחות בהנחיות להיקש לפני שהן מגיעות לשרת היקש. לאחר מכן, הוא מבצע בדיקות בטיחות בתשובות היוצאות. בארכיטקטורה הזו נעשה שימוש ב-Model Armor לגידור AI, אבל היא תומכת גם באפשרויות אחרות כמו NVIDIA NeMo Guardrails. הפריסה של Terraform שמסופקת עם ארכיטקטורת ההפניה הזו כוללת הגדרה בסיסית של הגנה מוגברת על המודל.
  • שירותים לקצה העורפי: מאזן העומסים מעביר בקשות לשירותים לקצה העורפי על סמך שם המודל בבקשה. השירות לקצה העורפי מכיל קבוצה של נקודות קצה ברשת (NEG).
  • קבוצות של רפליקות של מודלים: רפליקה של מודל היא עותק של שרת הסקת מסקנות שנפרס ביחידת GPU אחת או יותר או ביחידת TPU אחת או יותר. שכפול של מודל יכול להיות עם צומת יחיד או עם כמה צמתים. קבוצת רפליקות היא קבוצה אחידה של רפליקות של מודלים, שמאזן עומסים נמצא בחזית שלה. באופן כללי, רפליקות של מודלים נמצאות באשכול Google Kubernetes Engine ‏ (GKE) מאחורי GKE Inference Gateway, ב-Vertex AI, ב-Cloud Run, במרכז נתונים מקומי או בענן אחר, ומאחורי נקודת קצה באינטרנט.

הגדרות של קבוצת עותקים זהים של מודל

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

סוג קבוצת העותקים הכפולים תיאור איזון עומסים של רפליקות
Vertex AI העתקים של המודל פועלים ב-Vertex AI. אתם מפרסמים נקודת קצה של Vertex AI כקבוצה של נקודות קצה ברשת (NEG) מסוג Private Service Connect. מאזן העומסים של חזית האתר משתמש ב-NEGs מסוג Private Service Connect כבק-אנדים לכל מודל נפרד, כאשר כל מודל מובנה כשירות בק-אנד. ‫Vertex AI מבצעת התאמה לעומס ואיזון עומסים באופן פנימי. ‫Vertex AI מבצעת איזון עומסים משוקלל שמבוסס על מדדים וניתוב שמבוסס על מטמון של קידומות, וכך מייעלת את השימוש במשאבים ומאיצה את ההסקת מסקנות. למידע נוסף, אפשר לעיין במאמר בנושא פריסת מודל לנקודת קצה.
GKE שרתי ההסקה פועלים כ-Pods באשכול GKE ברשת VPC של קבוצת העותקים של GKE. כמה רפליקות של מודלים ב-GKE יוצרות ביחד קצה עורפי יחיד מאחורי שער הסקת מסקנות. ה-Inference Gateway מפרסם נקודת קצה (endpoint) של Private Service Connect, שמאזן העומסים של הקצה הקדמי ניגש אליה באמצעות Private Service Connect NEG. Inference Gateway מספק איזון עומסים מודע-מודל עבור עורפי קצה של היקש באשכול GKE. ה-Inference Gateway משתמש בהתאמת קידומות כשזה רלוונטי. אם אין התאמת קידומות, ה-Inference Gateway מחלק את הבקשות על סמך מדדי GPU או TPU. ההגדרה הזו תומכת בהתאמה אופקית של קבוצות Pod לעומס.
Cloud Run שרתי היקשים פועלים ב-Cloud Run. ‫Cloud Run מפרסם נקודת קצה שמאזן העומסים של הקצה הקדמי ניגש אליה באמצעות Serverless NEG. ‫Cloud Run משנה באופן אוטומטי את מספר הרפליקות בהתאם לתעבורה. היא מוגבלת רק לשכפולים של צומת יחיד.
מודל השתתפות היברידי שרתי היקש פועלים בארגון או בענן אחר. מגדירים מאזן עומסי רשת פנימי אזורי ברשת VPC לניתוב. מאזן העומסים הזה מפרסם נקודת קצה (endpoint) של Private Service Connect, שמאזן העומסים של הקצה הקדמי ניגש אליה באמצעות Private Service Connect NEG. למאזן העומסים הפנימי ברשת ה-VPC לניתוב יש בתורו קצה עורפי (backend) של Hybrid NEG שמפנה לכתובת ה-IP של מאזן עומסים בארגון או בענן אחר, שנמצא לפני שרתי ההיקש בארגון. מנגנון איזון העומסים של מאזן העומסים החיצוני מוגדר על ידי האדמינים של המתקן החיצוני.
אינטרנט שרתי הסקה שאפשר לגשת אליהם מכתובות IP באינטרנט הציבורי. מאזן העומסים של הקצה הקדמי כולל בק-אנד של NEG באינטרנט שמפנה לכתובת ה-IP של מודל שמתארח באינטרנט. ספק השירות המנוהל מטפל בהרחבת הקיבולת.

תהליך הבקשה

המערכת מנתבת בקשות להסקת מסקנות באופן הבא:

  1. משתמש קצה שולח בקשת OpenAI API לנקודת הקצה של Private Service Connect. הבקשה הזו מכילה את הפרטים הבאים:
    • ההנחיה.
    • שם המודל, שחייב להיות זהה לשם המודל של אחד משרתי ההסקה המתארחים.
  2. נקודת הקצה של Private Service Connect מעבירה את הבקשה למאזן העומסים הפנימי של האפליקציה בחזית.
  3. מאזן העומסים מעביר את הבקשה ל-Service Extensions.
  4. הקוד של התוסף body-based routing קורא את שם המודל מגוף הבקשה וכותב אותו לכותרת X-Gateway-Model-Name.
  5. מאזן העומסים משתמש בקריאה להרחבת התנועה של Service Extensions כדי לשלוח את הבקשה למערכת לניהול API עבור כל שירותי ניהול ה-API שנדרשים.
  6. מאזן העומסים משתמש בקריאה להרחבת תנועה של Service Extensions כדי לשלוח את ההנחיה ל-Model Armor לצורך סינון.
    • אם ההנחיה מכילה מידע רגיש שלא ניתן להסיר, ההנחיה נחסמת ו-הגנה מוגברת על המודל מחזיר תשובה שמציינת שנמצאה הפרת מדיניות.
    • אם ההנחיה מכילה מידע רגיש שאפשר לצנזר, או אם אין בה בעיות בכלל, הגנה מוגברת על המודל מצנזר את המידע הרגיש ומעביר את ההנחיה.
  7. אם הבקשה מאושרת על ידי Model Armor, מאזן העומסים בודק את מיפוי כתובות ה-URL ומעביר את הבקשה לשירות קצה עורפי על סמך הכותרת המותאמת אישית של שם המודל. במקרה הצורך, מפת URL משכתבת את כתובת ה-URL ואת הנתיב של הבקשה כדי להתאים למה שנדרש בשרת העורפי.
  8. השירות לקצה העורפי מעביר את הבקשה למאזן העומסים המשויך של קבוצת העותקים.
  9. מאזן העומסים של שירות ההסקות הספציפי מקצה את הבקשה לאחת מהרפליקות שלו.
  10. העותק המדויק מעבד את הבקשה ושולח תגובה.
  11. מאזן העומסים הפנימי האזורי של האפליקציות בחלק הקדמי שולח את התגובה ל-Model Armor לצורך סינון.
  12. מאזן העומסים של האפליקציה שולח את התגובה בחזרה לנקודת הקצה של Private Service Connect, ומשם היא מועברת למשתמש הקצה.

בתרשים הבא מוצגת תצוגת ניתוב של פריסה לדוגמה:

תהליך ההנחיות ליצירת קבוצות משוכפלות לדוגמה.

בדוגמה הזו, ההנחיות מטופלות בהתאם למודל שהמשתמש בוחר:

  • ‫Gemma: כל ההנחיות מנותבות לקבוצת העותקים המארחת את מודל Gemma.
  • ‫Llama: המערכת מבצעת איזון עומסים של ההנחיות האלה באופן שווה בין שתי קבוצות רפליקות, שכל אחת מהן מארחת את מודל Llama. שתי קבוצות הרפליקות האלה לא חייבות להיות מאוחסנות באותו אופן. לדוגמה, קבוצת רפליקות אחת יכולה להיות מאוחסנת ב-Vertex AI וקבוצת הרפליקות השנייה יכולה להיות מאוחסנת ב-GKE.
  • ‫LoRA-1-gemma או LoRA-2-gemma: המערכת שולחת את כל ההנחיות לאותו סט רפליקות, שיכול לטפל בשני המודלים.

המוצרים שהשתמשו בהם

בארכיטקטורת ההפניה שבמסמך הזה נעשה שימוש במוצרים הבאים: Google Cloud

  • ‫ Cloud Load Balancing: חבילה של מאזני עומסים גלובליים ואזוריים, בעלי ביצועים גבוהים וניתנים להתאמה.
  • ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות של רשתות גלובליות וניתנות להרחבה עבור עומסי העבודה שלכם ב- Google Cloud . ‫VPC כולל קישור בין רשתות VPC שכנות (peering),‏ Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
  • ‫ Private Service Connect: תכונה שמאפשרת לצרכנים לגשת לשירותים מנוהלים באופן פרטי מתוך רשת ה-VPC שלהם.
  • ‫ Cloud Run: פלטפורמת מחשוב ללא שרת שמאפשרת להריץ קונטיינרים ישירות על גבי התשתית הניתנת להרחבה של Google.
  • ‫ Apigee: כלי לניהול ממשקי API שמאפשר לכם שליטה מדויקת באופן הגישה לממשקי ה-API והשימוש בהם. הוא מספק אבטחה, הגבלת קצב של יצירת בקשות, אכיפת מכסות וניתוח נתונים.
  • ‫ Model Armor: שירות שמספק הגנה למשאבי AI גנרטיבי ו-AI מבוסס-סוכנים מפני החדרת הנחיות, דליפות של מידע אישי רגיש ותוכן מזיק.

חלופות עיצוב

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

שכבות הגנה מבוססות-AI

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

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

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

ניהול API

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

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

התחברות לרשתות אחרות

הארכיטקטורה שמתוארת במסמך הזה משתמשת ברשת VPC אחת של צרכן. עם זאת, אפשר לשתף את נקודת הקצה של Private Service Connect עם רשתות רבות אחרות באמצעות רשת VPC של גישה לשירותים בפריסת Cross-Cloud Network.

שיקולים לגבי העיצוב

כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי לעיין בשיטות המומלצות ובהמלצות שבGoogle Cloud מסגרת Well-Architected Framework.

אבטחה, פרטיות ותאימות

  • כדי להוסיף הגנה מפני מתקפות מניעת שירות מבוזרות (DDoS), פונקציונליות של חומת אש לאפליקציות אינטרנט (WAF) ובדיקה של כתובות IP לפריסה, מוסיפים את Cloud Armor למאזן העומסים האזורי הפנימי של האפליקציה בחלק הקדמי.
  • כדי להוסיף שכבת אימות משותפת לכל השרתים העורפיים, מטמיעים שרת proxy עם מודעות להקשר הזהות (IAP) כדי לאמת את הזהות ולאכוף את מדיניות ההרשאות.
  • כשמנתבים תנועה מאפליקציית אינטרנט למודל Vertex AI, צריך לבחור מודל זהויות לאימות:
    • זהות של חשבון שירות (מומלץ לאפליקציות אינטרנט כלליות): האפליקציה מאמתת את משתמש הקצה באמצעות IAP, אבל היא קוראת ל-Vertex AI באמצעות זהות של עומס עבודה של שירותים (כמו Cloud Run,‏ GKE או באמצעות זהות של צד שלישי). ההטמעה הזו מסתירה את ניהול הזהויות והרשאות הגישה (IAM) ממשתמש הקצה, אבל היא מחייבת רישום ביומן ברמת האפליקציה כדי לעקוב אחרי ההנחיה שכל משתמש יצר.
    • העברת זהות משתמש הקצה (מומלץ לשיפור יכולת הביקורת): האפליקציה מקבלת את אסימון הגישה של משתמש הקצה ל-Google OAuth ומעבירה אותו ישירות ל-Vertex AI בכותרת Authorization: Bearer. ההטמעה הזו מספקת רישום מובנה ביומני הביקורת של Cloud של פעולות המשתמש, אבל היא מחייבת הקצאת הרשאות ב-IAM (כמו roles/aiplatform.user) לכל משתמש קצה. Google Cloud

אמינות

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

יעילות תפעולית

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

אופטימיזציה של הביצועים

פריסה

כדי לפרוס יישום לדוגמה של הארכיטקטורה הזו, אפשר להשתמש בדוגמת הקוד Networking for AI Inference Model Serving שזמינה ב-GitHub.

למידע על פריסת מודלים של AI, אפשר לעיין במקורות המידע הבאים:

המאמרים הבאים

שותפים ביצירת התוכן

מחבר: ויקטור מורנו | מנהל מוצר, Cloud Networking

תורמי תוכן אחרים: