סקירה כללית של ניתוב מודלים

ניתוב מודלים ל-API Gateway הוא שכבת ניהול תנועה מנוהלת שמקבלת בקשות להנחיות שתואמות ל-OpenAI, מבצעת טרנסקוד של הבקשות במהלך ההעברה ומנתבת אותן למודלים ספציפיים של Gemini Enterprise Agent Platform. ניתוב מודלים הוא חלופה מנוהלת לפרוקסי מצד הלקוח, כמו LiteLLM, והוא מספק תשתית מרכזית לניהול מחזור החיים של סוכני AI.

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

היקף ומסלולי משתמשים

ניתוב מבוסס-מודל תומך בתהליכי השימוש העיקריים הבאים:

  • בחירת מודל: מפתח AI משתמש במודלים פתוחים מ-Model as a Service‏ (MaaS) ב-Model Garden של Agent Platform. אלה מודלים של Gemini,‏ Anthropic Claude או OpenAI GPT.
  • יצירת מפרט: מפתח AI יוצר או מעדכן הגדרה של נתב מודלים במפרט OpenAPI 3.x כדי להפנות למודלים שנפרסו.
  • פריסת שער: מפתח AI פורס הגדרת API ומופע של API Gateway באמצעות מפרט OpenAPI שנוצר.
  • ניתוב הנחיות: אפליקציות לקוח שולחות בקשות להנחיות שתואמות ל-OpenAI אל שער הכניסה, שמנתב את הבקשות ומתרגם את המטען הייעודי (payload) על סמך שם המודל שצוין במטען הייעודי בפורמט JSON.

אנחנו מתכננים שגרסאות עתידיות של API Gateway יתמכו בתרחישי שימוש נוספים.

היתרונות של ניתוב לפי מודל

הטמעה של ניתוב מודלים ב-API Gateway מספקת את היתרונות הבאים:

  • ניהול ריכוזי: איחוד של ניהול תנועת ה-AI בשער מנוהל יחיד, במקום הגדרות ניתוב מפוצלות בצד הלקוח.
  • צמצום התקורה התפעולית: אין יותר צורך בעלויות התשתית ובנטל התחזוקה שקשורים לפריסת שרתי proxy עצמאיים.
  • ביצועים שעברו אופטימיזציה ב-Edge: בדיקת הנחיות וניתוב תנועה ב-Edge של הרשת, תוך שימוש בשילוב ישיר עם נקודות הקצה של Agent Platform Model Garden.
  • ממשק לקוח סטנדרטי: מאפשר לאפליקציות לקוח ליצור אינטראקציה עם ממשק REST אחיד שתואם ל-OpenAI, תוך שליחת בקשות באופן דינמי למודלים בסיסיים שונים.

פרסונות ותרחישים לדוגמה

ניתוב מודלים עונה על הדרישות של הדמויות הבאות:

  • מהנדסי פלטפורמה: הקצאת פתרון תשתית מנוהל להחלפת לוגיקת ניתוב בצד הלקוח בפריסות AI בארגון.
  • מפתחי AI: חשיפת נקודת קצה (endpoint) סטנדרטית של API שמנתבת בקשות באופן דינמי בין מודלים בסיסיים שונים (כמו Gemini Pro,‏ Gemini Flash או Anthropic Claude) על סמך פרמטרים של מטען ייעודי (payload) הבקשה.
  • אדמינים של ניהול: אדמינים כאלה יכולים לאכוף מדיניות גישה מרכזית (למשל, אימות ומכסות) ולעקוב אחרי נפח התנועה הכולל של AI בארגון.

תרחישי שימוש נתמכים

במהלך תקופת הטרום-השקה הפתוחה, ניתוב המודלים תומך בניתוח שמבוסס באופן בלעדי על תג המודל או על שם המודל (לדוגמה, "model": "gemini-3.5-flash-lite") שצוין במטען ה-JSON של בקשות לקוח שתואמות ל-OpenAI.

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

ניתוב המודלים פועל כשכבת ניהול ניתוב במישור הנתונים של API Gateway. כשאפליקציית לקוח שולחת בקשת הנחיה שתואמת ל-OpenAI אל השער, מתרחש רצף הפעולות הבא:

  1. יירוט בקשות: השער מיירט את בקשת POST הנכנסת (לדוגמה, POST /chat/completions).
  2. בדיקת המטען הייעודי (payload): נתב המודלים בודק את מאפיין model במטען הייעודי (payload) של JSON הנכנס (לדוגמה, {"model": "claude-opus-4-7", "messages": [...]}).
  3. הערכת הכלל: הנתב מתאים את המחרוזת model לכללי הניתוב שמוגדרים במפרט OpenAPI. אם אין התאמה לאף כלל, הנתב בוחר את המודל שמוגדר כברירת מחדל.
  4. טרנסקוד תוך כדי העברה: השער מבצע טרנסקוד של הבקשה שתואמת ל-OpenAI לתוך סכמת התחזית של Agent Platform ביעד.
  5. ‫Backend dispatch: השער שולח את הבקשה שעברה המרה לנקודת הקצה הייעודית של Model Garden בפלטפורמת הסוכנים, ומחזיר את תגובת המודל ללקוח.

ביצועים ומגבלות

לפני שמטמיעים ניתוב של מודלים, חשוב לעיין במגבלות הטכניות הבאות:

  • מגבלות על המארח: ניתוב המודל תומך בניתוח רק למודלים של MaaS שהופעלו מראש ומאוחסנים ב-Model Garden של Agent Platform, שבו כל המודלים שמפנים אליהם באמצעות נתב יחיד חולקים את אותו שם מארח (לדוגמה, נקודת הקצה הגלובלית aiplatform.googleapis.com או נקודת קצה אזורית יחידה כמו us-central1-aiplatform.googleapis.com).
  • דרישות המפרט: ניתוב מודלים דורש מפרט OpenAPI 3.x ותוספים תואמים של API Gateway OpenAPI 3.x. אין תמיכה במפרטים של OpenAPI 2.0 ‏ (Swagger).
  • עדכוני שער: אי אפשר לעדכן שער קיים שנפרס ללא ניתוב מודלים כדי להפעיל ניתוב מודלים, ואי אפשר לעדכן שער שנפרס עם ניתוב מודלים כדי להשבית או להסיר את ניתוב המודלים. כדי להחליף בין מצבי ניתוב, צריך ליצור ולפרוס הגדרת API חדשה ומופע שער חדש.
  • הגדרות מעורבות: מפרט OpenAPI לא יכול להכיל שילוב של פעולות ניתוב מבוסס-מודל ופעולות ניתוב לא מבוסס-מודל. כל הפעולות במפרט צריכות להשתמש בניתוח מסלולים של מודלים או בניתוח מסלולים של שערים רגילים.
  • ‫VPC Service Controls: שערים לניתוב מודלים לא תומכים ב-VPC Service Controls. אי אפשר להשתמש בגבולות גזרה של VPC Service Controls עם מופעים של API Gateway שמאפשרים ניתוב מודלים.
  • סטרימינג ופרוטוקולים לא נתמכים: ניתוב המודלים תומך בסטרימינג של תגובות (אירועים שנשלחים מהשרת), אבל לא תומך בסטרימינג בצד הבקשה, ב-gRPC, ב-WebSockets או ב-Gemini Live.
  • אמצעי תקשורת נתמכים: במהלך תקופת ה-Public Preview, הניתוב של המודל מניח שמדובר בבקשות הנחיות מבוססות-טקסט בפורמט מטען ייעודי (payload) של JSON שתואם ל-OpenAI, והניתוב מתבסס באופן בלעדי על התג model או על השם במטען הייעודי.
  • שדות חובה במטען הייעודי: המטען הייעודי של בקשת ה-JSON הנכנסת חייב לכלול מאפיין model. במהלך תקופת הטרום-השקה, אם השדה model חסר במטען הייעודי (payload) של בקשת הלקוח, השער מעבד את הבקשה באופן שגוי במקום לדחות אותה עם שגיאה. חשוב לוודא שתמיד מצוין שדה model במטען הייעודי (payload) בפורמט JSON בבקשות של הלקוח.
  • מגבלות זמן ריצה: המגבלות וההתנהגויות של שירות אירוח שערים רגיל חלות על נקודות הקצה של ניתוב המודל:
    • זמן קצוב לתפוגה מקסימלי: השער אוכף זמן קצוב לתפוגה מקסימלי של 3,600 שניות (שעה אחת) לבקשות, והוא חל על בקשות סטרימינג ארוכות.
    • זמן הטעינה של הפעלה מההתחלה (cold startup): אם מופעלת התאמה אוטומטית של מספר העותקים של שער (gateway) לאפס בתקופות של חוסר פעילות, יכול להיות שהבקשה הראשונית תיתקל בזמן טעינה של הפעלה מההתחלה, מה שיכול להשפיע על נתיבי הסקת מסקנות מ-AI שרגישים לזמן האחזור.
    • נתיבי כתובות URL שמורים: אי אפשר להשתמש בנתיבי כתובות URL שמורים כמו /eventlog, נתיבים שמתחילים ב-/_ah/ או נתיבים מסוימים שמסתיימים ב-z (כדי למנוע התנגשויות, מומלץ לא להשתמש בשמות נתיבים שמסתיימים ב-z).
    • פענוח תווים בכתובת URL: השער מפענח באופן אוטומטי תווים מקודדים מסוימים בכתובות URL של בקשות לפני עיבוד הבקשה (לדוגמה, %41 מפוענח ל-A).

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