רישות לפרסום מודל היסק (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.
  • הפניות (callouts) של Service Extensions: אתם יכולים להשתמש בהפניות כדי להוסיף עיבוד נוסף למאזן עומסים של אפליקציות. הארכיטקטורה בעיצוב הזה כוללת את ההערות הבאות:
    • ‫Body-based router: הנתב מבוסס-הגוף נפרס ב-Cloud Run. הוא קורא את שם המודל מגוף בקשת ה-API של OpenAI וכותב אותו לשדה X-Gateway-Model-Name בכותרת. מיפוי כתובות ה-URL של מאזן העומסים משתמש בשדה כדי להעביר את הבקשה לשירות המתאים לקצה העורפי. פריסת Terraform שמסופקת עם ארכיטקטורת ההפניה הזו כוללת את הגדרות הנתב שמבוסס על גוף הבקשה.
    • ‫Apigee: כלי לניהול API שמספק אימות API, אבטחה, הגבלת קצב, מעקב אחר מכסות ושירותים אחרים לניהול API. הארכיטקטורה הזו משתמשת ב-Apigee, אבל היא תומכת באפשרויות אחרות. כדי להתקשר ל-Apigee ממאזן העומסים, הארכיטקטורה ופריסת Terraform משתמשות בתוסף תעבורה של Service Extensions כדי להתקשר למעבד Apigee Extension.
    • ‫הגנה מוגברת על המודל: מערכת AI guardrails שמבצעת בדיקות בטיחות בפרומפטים לפני שהם מגיעים לשרת ההיקש. לאחר מכן, הוא מבצע בדיקות בטיחות בתשובות היוצאות. בארכיטקטורה הזו נעשה שימוש ב-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. התצורה הזו תומכת בהתאמה אופקית של קבוצות Pod לעומס.
Cloud Run שרתי היקשים פועלים ב-Cloud Run. ‫Cloud Run מפרסם נקודת קצה שמאזן העומסים של הקצה הקדמי ניגש אליה באמצעות Serverless NEG. ‫Cloud Run משנה באופן אוטומטי את מספר הרפליקות בהתאם לתעבורה. היא מוגבלת רק לשכפולים של צומת יחיד.
מודל השתתפות היברידי שרתי ההסקה פועלים בארגון או בענן אחר. מגדירים מאזן עומסי רשת אזורי פנימי בשרת proxy ברשת VPC לניתוב. מאזן העומסים הזה מפרסם נקודת קצה (endpoint) של Private Service Connect, שמאזן העומסים של הקצה הקדמי ניגש אליה באמצעות Private Service Connect NEG. מאזן העומסים הפנימי ברשת ה-VPC של הניתוב כולל בק-אנד של Hybrid NEG שמפנה לכתובת ה-IP של מאזן עומסים בארגון או בענן אחר, שנמצא לפני שרתי ההסקה בארגון. מנגנון איזון העומסים של מאזן העומסים החיצוני מוגדר על ידי האדמינים של המתקן החיצוני.
אינטרנט שרתי הסקה שאפשר לגשת אליהם מכתובות IP באינטרנט הציבורי. למאזן העומסים של הקצה הקדמי יש בק-אנד של NEG באינטרנט שמפנה לכתובת ה-IP של מודל שמתארח באינטרנט. ספק השירות המנוהל מטפל בהרחבת הקיבולת.

תהליך הבקשה

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

  1. משתמש קצה שולח בקשת OpenAI API לנקודת הקצה של Private Service Connect. הבקשה הזו מכילה את הפרטים הבאים:
    • ההנחיה.
    • שם המודל, שחייב להיות זהה לשם המודל של אחד משרתי ההסקה המתארחים.
  2. נקודת הקצה של Private Service Connect מעבירה את הבקשה למאזן העומסים הפנימי של האפליקציה בחזית.
  3. מאזן העומסים מעביר את הבקשה ל-Service Extensions.
  4. הקוד של Service Extensions לניתוב מבוסס-גוף קורא את שם המודל מגוף הבקשה וכותב אותו בכותרת 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. שתי קבוצות העותקים לא צריכות להיות מאוחסנות באותו אופן. לדוגמה, אפשר לארח קבוצת שכפול אחת ב-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 שלא בנקודת הקצה של המודל, אפשר להשבית את הגנה מוגברת על המודל במאזן העומסים של קצה קדמי אם לא צריך אותו. אם אתם לא רוצים להשתמש ב-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.

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

  • כדי להוסיף הגנה מפני מתקפות מניעת שירות מבוזרות (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 (כמו roles/aiplatform.user) לכל משתמש קצה. Google Cloud

אמינות

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

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

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

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

פריסה

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

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

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

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

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

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