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

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

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

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

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

  • בחירת מודל: מפתח AI משתמש במודלים פתוחים מ-Model as a Service‏ (MaaS) ב-Vertex AI Model Garden. אלה מודלים של 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 של הרשת, תוך שימוש בשילוב ישיר עם נקודות קצה של Vertex AI Model Garden.
  • ממשק לקוח סטנדרטי: מאפשר לאפליקציות לקוח ליצור אינטראקציה עם ממשק REST אחיד שתואם ל-OpenAI, תוך שליחת בקשות באופן דינמי למודלים בסיסיים שונים.

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

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

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

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

במהלך תקופת ה-Public Preview, הניתוב של המודלים תומך בניתוב שמבוסס באופן בלעדי על תג המודל או על השם שלו (לדוגמה, "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 לסכימת החיזוי של Vertex AI.
  5. שליחה לעורף: השער שולח את הבקשה שעברה המרה לנקודת הקצה המיועדת של Vertex AI Model Garden ומחזיר את תגובת המודל ללקוח.

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

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

  • אילוצים של המארח: ניתוב מודלים תומך בניתוח רק למודלים של MaaS שהופעלו מראש ומאוחסנים ב-Vertex AI Model Garden, שבהם כל המודלים שמקושרים לנתב יחיד חולקים את אותו שם מארח (לדוגמה, נקודת הקצה הגלובלית 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): אם מופעלת התאמה אוטומטית של מספר העותקים של שער הגישה לאפס בתקופות של חוסר פעילות, יכול להיות שהבקשה הראשונית תיתקל בזמן הטעינה של הפעלה מההתחלה. זה עלול להשפיע על נתיבי הסקת מסקנות מ-AI שרגישים לזמן האחזור.
    • נתיבי כתובות URL שמורים: אי אפשר להשתמש בנתיבי כתובות URL שמורים כמו /eventlog, נתיבים שמתחילים ב-/_ah/ או נתיבים מסוימים שמסתיימים ב-z (כדי למנוע התנגשויות, מומלץ לא להשתמש בשמות נתיבים שמסתיימים ב-z).
    • פענוח תווים בכתובת URL: השער מפענח באופן אוטומטי תווים מקודדים מסוימים בכתובות URL של בקשות לפני עיבוד הבקשה (לדוגמה, %41 מפוענח ל-A).

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