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

Last reviewed 2026-05-20 UTC

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

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

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

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

ארכיטקטורה

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

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

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

  • נקודת קצה (endpoint) להסקת מסקנות ב-Private Service Connect: נקודת קצה מאוחדת לכל המודלים המתארחים. משתמש הקצה שולח בקשות להסקת מסקנות לכתובת ה-IP של נקודת הקצה. בתרשים מוצגת נקודת קצה של Private Service Connect ברשת יחידה של ענן וירטואלי פרטי (VPC) של צרכן. אתם יכולים לארח נקודות קצה בכמה רשתות VPC או ברשת VPC של שירותים משותפים.
  • מאזן עומסים פנימי אזורי של אפליקציות (ALB): בארכיטקטורה הזו, מאזן העומסים של חזית האתר הוא מאזן עומסים פנימי אזורי של אפליקציות. מאזן העומסים בחזית האפליקציה מנתב את התנועה למאגרי העתקים על סמך שם המודל שצוין בבקשה. בארכיטקטורה הזו, אפליקציית הלקוח מבצעת קריאות ל-OpenAI API למאזן העומסים. אם שרת ההסקה של הקצה העורפי תואם ל-OpenAI API, הפעולה מתבצעת בצורה שקופה. אם שרת ההסקה לא תואם ל-OpenAI API, צריך להטמיע מתרגם API באמצעות Service Extensions. ארכיטקטורת ההפניה הזו לא כוללת את ההטמעה של מתרגם API.
  • קריאות ל-Service Extensions: אתם יכולים להשתמש בהפניות כדי להוסיף עיבוד נוסף למאזן עומסים של אפליקציות. הארכיטקטורה בעיצוב הזה כוללת את ההערות הבאות:
    • מעבד מטען ייעודי (payload) של היקשים (לשעבר נתב מבוסס-גוף): מעבד מטען ייעודי (payload) של היקשים נפרס ב-Cloud Run. הוא קורא את שם המודל מגוף בקשת ה-API של OpenAI וכותב אותו לשדה X-Gateway-Model-Name בכותרת. מיפוי כתובות ה-URL של מאזן העומסים משתמש בשדה כדי להעביר את הבקשה לשירות המתאים לקצה העורפי. פריסת Terraform שמסופקת עם ארכיטקטורת ההפניה הזו כוללת את ההגדרה של מעבד המטען הייעודי (Payload) של ההיסק.
    • ‫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, ב-Gemini Enterprise Agent Platform, ב-Cloud Run, במרכז נתונים מקומי או בענן אחר, ומאחורי נקודת קצה באינטרנט.

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

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

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

תהליך הבקשה

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

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

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

רצף הפרומפטים להגדרת קבוצות משוכפלות לדוגמה.

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

  • ‫Gemma: כל ההנחיות מנותבות לקבוצת העותקים שמארחת את מודל Gemma.
  • ‫Llama: המערכת מאזנת את עומס ההנחיות האלה באופן שווה בין שני סטים של רפליקות, שכל אחד מהם מארח את מודל Llama. שני מערכי העותקים האלה לא חייבים להיות מאוחסנים באותו אופן. לדוגמה, אפשר לארח קבוצת שכפול אחת ב-Agent Platform ואת קבוצת השכפול השנייה ב-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 שלכם ובשימוש בהם. הוא מספק אבטחה, הגבלת קצב, אכיפת מכסות וניתוח נתונים.
  • ‫ הגנה מוגברת על המודל: שירות שמספק הגנה למשאבי AI גנרטיבי ו-AI אקטיבי מפני החדרת פרומפטים, דליפות של מידע אישי רגיש ותוכן פוגעני.

חלופות עיצוב

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

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

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

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

אם מטמיעים אמצעי בקרה של AI שלא בנקודת הקצה של המודל, אפשר להשבית את הגנה מוגברת על המודל במאזן העומסים של קצה קדמי אם לא צריך אותו. אם אתם לא רוצים להשתמש ב-הגנה מוגברת על המודל, אתם יכולים להשתמש בתוספים לתעבורת נתונים כדי לפרוס פתרונות אחרים להגנה, כמו 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 ל-Application Load Balancer פנימי אזורי בחלק הקדמי של האפליקציה.
  • כדי להוסיף שכבת אימות משותפת לכל השרתים העורפיים, מטמיעים שרת proxy לאימות זהויות (IAP) כדי לאמת את הזהות ולאכוף את מדיניות ההרשאות.
  • כשמנתבים תנועה מאפליקציית אינטרנט למודל של Agent Platform, צריך לבחור מודל זהויות לאימות:
    • זהות של חשבון שירות (מומלץ לאפליקציות אינטרנט כלליות): האפליקציה מאמתת את משתמש הקצה באמצעות IAP, אבל היא קוראת ל-Agent Platform באמצעות זהות של עומס עבודה של שירותים (כמו Cloud Run,‏ GKE או באמצעות זהות של צד שלישי). ההטמעה הזו מסתירה את ניהול הזהויות והרשאות הגישה (IAM) ממשתמש הקצה, אבל היא מחייבת רישום ביומן ברמת האפליקציה כדי לעקוב אחרי ההנחיה שכל משתמש יצר.
    • העברת זהות משתמש הקצה (מומלץ לביקורת קפדנית): האפליקציה מתעדת את אסימון הגישה של משתמש הקצה ל-OAuth של Google ומעבירה אותו ישירות ל-Agent Platform בכותרת Authorization: Bearer. ההטמעה הזו מספקת רישום מובנה ביומני הביקורת של Cloud של פעולות המשתמשים, אבל היא מחייבת הקצאת הרשאות IAM Google Cloud(כמו roles/aiplatform.user) לכל משתמש קצה.

אמינות

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

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

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

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

פריסה

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

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

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

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

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

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