AI Proxy Architecture: השכבה שיושבת בין הקוד שלכם לכל ספק מודל

מאת צוות מדיה דיל · 02.08.2026 · Enterprise AI · 6 דק׳

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

הדרך הכי מהירה לגלות למה צריך AI Proxy היא לנסות לענות על שאלה פשוטה בארגון עם עשרות שירותים שקוראים למודלי AI: "כמה עלה לנו השימוש ב-AI החודש, מפולח לפי צוות ולפי מודל?" בלי פרוקסי מרכזי, התשובה דורשת לחפור בלוגים של עשרות שירותים שונים, כל אחד מתעד (או לא מתעד) בצורה שונה. עם פרוקסי - כל קריאה, מכל שירות, עוברת דרך נקודה אחת שמתעדת, אוכפת מדיניות, ומדווחת בפורמט אחיד.

ה-proxy הוא reverse proxy קלאסי, בדיוק כמו Nginx או Envoy בעולם ה-HTTP הרגיל, אבל מותאם לסמנטיקה הספציפית של קריאות AI: streaming responses, טוקנים, וקונטקסט ארוך. הוא יושב בין קוד האפליקציה לבין ה-API של ספק המודל (או ספקים מרובים), מיירט כל בקשה ותשובה, ויכול להחיל עליה טרנספורמציות, מדיניות ובקרות - בלי ששום קוד קורא צריך לדעת שהוא שם בכלל.

הבעיה: כל שירות קורא ישירות ל-API של הספק

כשכל שירות בארגון מחזיק את מפתח ה-API של ספק המודל ישירות בקונפיגורציה שלו וקורא ישירות ל-endpoint החיצוני, כמה בעיות צצות מהר: אין נקודת אכיפה מרכזית למדיניות (rate limiting, תקציב, אבטחת מידע), רוטציית מפתחות הופכת לפרויקט מתואם בין עשרות שירותים, ואין דרך לראות תמונה מאוחדת של השימוש. מעבר לזה, כל שינוי בממשק הספק (breaking change ב-API) דורש עדכון בכל מקום שקורא ישירות, במקום במקום אחד. proxy פותר את כל אלו על ידי ריכוז נקודת המגע היחידה עם הספק החיצוני.

ארכיטקטורת הליבה: אינטרספציה, טרנספורמציה, ותיעוד

פרוקסי AI טוב פועל בשלושה שלבים לכל בקשה. שלב האינטרספציה מקבל את הבקשה מקוד האפליקציה, מזהה את הזהות (איזה שירות, איזה משתמש) ואת סוג המשימה. שלב הטרנספורמציה מחיל שינויים על הבקשה - הוספת system prompt סטנדרטי, redaction של PII, בחירת המודל בפועל (שיכול להיות שונה ממה שהקוד ביקש, בהתאם למדיניות ניתוב), והחלת timeout ו-retry policy. ולבסוף, השלב השלישי מעביר את הבקשה בפועל לספק, ומתעד את כל הפרטים - זמן תגובה, כמות טוקנים, עלות, קוד סטטוס - לפני שהתשובה חוזרת לקוד הקורא.

// דוגמה למבנה בקשה שעוברת דרך AI Proxy
POST /proxy/v1/chat/completions
Headers: { "X-Team-Id": "billing-service", "X-Task-Type": "invoice-summary" }
Body: { "messages": [...], "model": "auto" }  // "auto" - הפרוקסי בוחר בפועל

// הפרוקסי מתעד לוג מובנה לכל קריאה, ללא תלות בקוד הקורא
{
  "team": "billing-service", "model_used": "claude-haiku",
  "tokens_in": 420, "tokens_out": 180, "cost_usd": 0.0031,
  "latency_ms": 640, "status": "success"
}

Streaming דרך פרוקסי: אתגר שקל לפספס

הרבה קריאות AI, במיוחד בממשקי צ׳אט, משתמשות ב-streaming - התשובה מגיעה בחלקים (chunks) בזמן אמת במקום כגוש אחד בסוף. פרוקסי שלא בנוי נכון עבור streaming עלול להוסיף latency משמעותי (buffering של כל התשובה לפני העברתה הלאה) שהורג את חוויית המשתמש. הפתרון הנכון הוא פרוקסי שתומך ב-streaming מקצה לקצה - מעביר כל chunk הלאה ברגע שהוא מתקבל מהספק, תוך כדי שהוא עדיין אוסף metadata (טוקנים, עלות) ברקע לצורך הלוג הסופי בסיום הזרם. זה דורש תשומת לב מיוחדת בבחירת שכבת ה-HTTP (למשל שימוש נכון ב-Server-Sent Events או HTTP/2) כדי לא לפגוע ב-latency הנתפס.

יש גם היבט טכני שקל לפספס: כשה-proxy מיישם retry logic על כשל, retry על בקשת streaming שכבר החלה לזרום תשובה חלקית ללקוח הוא בעייתי - אי אפשר "לחזור אחורה" ולשלוח מהתחלה בלי שהלקוח יקבל כפילות. הפתרון המקובל הוא ש-retry logic חל רק לפני שהזרם התחיל בפועל; ברגע שה-byte הראשון של תשובה יצא ללקוח, כשל באמצע חייב להיות מטופל כשגיאה מפורשת ולא retry שקוף.

Caching ברמת הפרוקסי

מיקום טבעי נוסף לפרוקסי הוא caching - שמירת תשובות לשאילתות זהות או דומות מאוד, כדי לחסוך קריאה חוזרת יקרה. מכיוון שהפרוקסי רואה את כל התעבורה מכל השירותים, הוא יכול לזהות הזדמנויות caching שאף שירות בודד לא היה רואה לבד - למשל שני שירותים שונים ששואלים בעצם את אותה שאלה. יישום caching נכון דורש מפתח (cache key) שמתחשב לא רק בטקסט הבקשה אלא גם בפרמטרים שמשפיעים על התשובה (temperature, system prompt, גרסת מודל), אחרת אפשר להחזיר תשובות לא עקביות ממקור cache שגוי.

אבטחה: מקום אחד למפתחות ולמדיניות

ריכוז הגישה החיצונית דרך פרוקסי אחד פותר בעיית אבטחה מהותית: מפתחות ה-API של ספקי המודל חיים במקום אחד בלבד (הפרוקסי עצמו), ולא מפוזרים בקונפיגורציה של עשרות שירותים - כל אחד עם רמת אבטחה שונה. שירותים פנימיים מזוהים מול הפרוקסי בעזרת mTLS או service tokens פנימיים, והפרוקסי הוא היחיד שמחזיק credentials אמיתיים לעולם החיצון. זה גם מפשט משמעותית רוטציית מפתחות - מספיק לעדכן אותם במקום אחד כדי שכל המערכת תמשיך לעבוד ללא הפרעה.

ניהול Timeouts ו-Retries במקום מרכזי

אחת התועלות הגדולות של ריכוז קריאות AI דרך פרוקסי היא אפשרות לנהל timeout ו-retry policy במקום אחד, במקום שכל שירות יממש אותם (או ישכח לממש) בעצמו. פרוקסי טוב מגדיר timeout ברירת מחדל הגיוני (למשל 30 שניות לקריאה רגילה, ארוך יותר למשימות שידועות כאיטיות), עם אפשרות override ברמת בקשה בודדת כשצריך. retry logic חכם מבחין בין שגיאות שכדאי לנסות שוב (rate limit זמני, timeout רשת) לשגיאות שאין טעם לחזור עליהן (בקשה לא תקינה, אימות נכשל) - ומיישם exponential backoff עם jitter כדי לא להציף את הספק בגל retries סינכרוני מכמה שירותים בו-זמנית אחרי כשל משותף.

נקודה חשובה: retry אוטומטי על בקשות non-idempotent (כמו קריאה שיש לה תופעת לוואי, למשל תיעוד פעולה במסד נתונים חיצוני דרך tool call) מסוכן - אם הבקשה הראשונה בפועל הצליחה אבל התשובה אבדה בדרך, retry עלול לגרום לביצוע כפול. פרוקסי בשל מסמן בקשות כאלה ומונע מהן retry אוטומטי שקוף, ומחזיר שגיאה מפורשת לקוד הקורא במקום להסתכן בכפילות שקטה.

תמיכה במספר פורמטים וגרסאות SDK בו-זמנית

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

Transformation Middleware: נרמול קלט ופלט בין ספקים

מעבר לתיעוד ואכיפת מדיניות, פרוקסי הוא המקום הטבעי לנרמל הבדלים בין ספקי מודל שונים - כל ספק מצפה למבנה בקשה מעט שונה, מחזיר שגיאות בפורמט שונה, ותומך בסט tools מעט שונה. שכבת ה-transformation middleware בפרוקסי ממירה בין הפורמט הפנימי האחיד שהקוד הארגוני משתמש בו לבין הפורמט הספציפי שכל ספק דורש בפועל, כך שקוד האפליקציה כותב בקשה בפורמט אחיד אחד, והפרוקסי דואג לתרגם אותה נכון בהתאם לספק היעד שנבחר. זו למעשה אותה שכבת abstraction שנדונה במדריך Multi-Model AI Architecture, רק שכאן היא ממומשת בפועל ברמת התשתית ולא רק כעיקרון תכנוני.

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

Trade-offs: Latency נוסף ונקודת כשל יחידה

כל בקשה שעוברת דרך פרוקסי סופגת latency נוסף - hop רשת נוסף, זמן עיבוד המדיניות והתיעוד. ברוב הפריסות התקורה הזו נמדדת במילישניות בודדות ולא משמעותית ביחס לזמן התגובה הכולל של קריאת LLM (שיכול לקחת שניות), אבל בתרחישי real-time קריטיים היא כן שיקול. הבעיה השנייה היא נקודת כשל יחידה - אם הפרוקסי נופל, כל התעבורה נחסמת, גם אם ספקי המודל עצמם תקינים לחלוטין. הפתרון הוא פריסת הפרוקסי במספר instances מאחורי load balancer, עם health checks שמוציאים instance כושל מהמעגל אוטומטית, כך שאין תלות ב-single point of failure יחיד ברמת התהליך.

טעויות נפוצות בפרודקשן

• פרוקסי בלי תמיכת streaming אמיתית - הופך כל תשובה לחוויית "המתנה" במקום זרימה חלקה כמו שהמשתמשים מצפים.
• הרצת instance בודד ללא redundancy - הופך תשתית שאמורה לשפר אמינות לנקודת כשל חדשה.
• caching בלי מפתח שמתחשב בכל הפרמטרים הרלוונטיים - מחזיר תשובות לא נכונות מ-cache שגוי.
• הזנחת ניטור latency שהפרוקסי עצמו מוסיף - קשה להבחין בין latency של הספק לבין תקורה של הפרוקסי בלי מדידה נפרדת לכל שלב.

ניהול הסכמת (consent) ומדיניות שימור נתונים

פרוקסי מרכזי הוא גם המקום הנוח ביותר לאכוף מדיניות שימור נתונים (data retention) על תוכן הבקשות והתשובות שעוברות דרכו. ארגונים רבים צריכים להבטיח שתוכן שיחות עם AI לא נשמר מעבר לתקופה מוגדרת, או שנתונים מסוימים (כמו מספרי כרטיס אשראי) לעולם לא נכתבים ללוג בכלל, גם לא זמנית. אכיפת מדיניות כזו במקום אחד - הפרוקסי - הרבה יותר אמינה מהסתמכות על כך שכל שירות בארגון יזכור בעצמו לא לתעד שדות רגישים בלוגים שלו.

מתי פרוקסי מוצדק

ארגון עם שירות בודד שקורא ל-AI לא צריך פרוקסי נפרד - זו תקורה מיותרת. פרוקסי משתלם ברגע שיש כמה שירותים שצריכים גישה למודלים, כשיש דרישת ניטור ותיעוד מרכזי, או כשיש כוונה עתידית להחליף ספקים בלי לגעת בקוד הקורא. הוא גם הבסיס הטבעי לבניית שכבות מתקדמות יותר כמו Enterprise Model Gateway שמוסיף עליו יכולות ניהול API מלאות.

סיכום

AI Proxy הוא רכיב תשתית קטן יחסית לבנייה אבל בעל השפעה גדולה על נראות, אבטחה ותחזוקתיות. הוא לא מחליף שכבות אחרות כמו control plane או ניתוב חכם בין מודלים - הוא התשתית ההנדסית שמאפשרת להן להתקיים במקום אחד ברור. במדיה דיל אנחנו כמעט תמיד ממליצים על שכבת פרוקסי כבר בשלב מוקדם יחסית, כי העלות הראשונית נמוכה יחסית לתועלת המצטברת בנראות ובגמישות שהיא נותנת בהמשך. בניגוד לשכבות מתקדמות יותר כמו גייטוויי מלא או service mesh, פרוקסי בסיסי הוא השקעה קטנה יחסית שכמעט תמיד משתלמת, ולכן הוא הצעד הראשון הטבעי בכל מסע לבניית תשתית AI ארגונית מסודרת, גם לפני שברור אילו שכבות נוספות יידרשו בהמשך הדרך.

תגיות: AI Proxy · reverse proxy · LLM gateway · streaming · API security · caching · בינה מלאכותית ארגונית

← חזרה לבלוג · צור קשר