איך עובד שער LLM? מדריך מעשי לצוותי הנדסה

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

“כרגע זה ח**א אחד גדול”, כתב ב־Reddit בקהילה r/LLMDevs מהנדס אחד בספטמבר 2026.

“לכל אחד יש סט מפתחות משלו ל־Claude, ל־OpenAI, ל־AWS Bedrock ולכל שאר ספקי ההסקה (inference) שאנחנו משתמשים בהם.”

הסיקור של BigGo על llm-proxy-tk, שער FastAPI קליל, משווה את המערך להפיכת מודלי LLM ל“מי ברז ארגוניים”, כשהשער משמש כברז הראשי של הבניין.

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

מהו שער LLM?

שער LLM הוא פרוקסי הפוך (reverse proxy) לקריאות למודלים. האפליקציות שלכם שולחות בקשות אליו במקום ישירות ל־OpenAI, ל־Anthropic, ל־Google או לכל ספק LLM אחר שבו אתם משתמשים. השער מעביר את הבקשות האלה הלאה ומחיל עליהן את הכללים שלכם בדרך.

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

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

שערי LLM, AI, MCP ו־API: מה ההבדל?

איך עובד שער LLM?

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

1. הבקשה מגיעה לשער: האפליקציה שלכם שולחת בקשת צ׳אט שנראית רגילה, לרוב בפורמט תואם OpenAI, לנקודת הקצה של השער. מבחינת האפליקציה, זו הכתובת שאליה היא פונה כדי להגיע למודל.
2. השער בודק מי שואל ומה מותר לו לעשות: לפני שהוא מעביר את הבקשה הלאה, הוא מאמת את פרטי ההזדהות. לרוב מדובר במפתח וירטואלי שהונפק לצוות או למוצר. אם הגדרתם מעקות בטיחות (guardrails) לקלט, אפשר גם לסרוק את הפרומפטים ולחפש בהם מידע רגיש או ניסיונות לעקוף את ההוראות של המודל.
3. השער בודק אם כבר יש לו את התשובה: אם השמירה במטמון מופעלת, אפשר לענות על בקשה תואמת שעומדת בתנאים מתוך תשובה שמורה, בלי קריאה נוספת לספק. חלק מהשערים מציעים גם שמירה סמנטית במטמון, שמחפשת בקשות שנחשבות דומות מספיק ולא בהכרח זהות. זה יכול להתאים לתעבורה בסגנון שאלות נפוצות.
4. השער בוחר לאן הבקשה תלך: הבקשה עשויה לציין מודל מסוים או כינוי (alias). השער מחפש בתצורה שלכם את הנתיב המתאים. אפשר גם להגדיר נתיב גיבוי. אם ספק A לא מגיב בזמן, השער יכול לנסות את ספק B.
5. השער מכין את הקריאה ומחזיר את התשובה: השער ממיר את הבקשה שלכם לפורמט של הספק שנבחר ומאמת את הקריאה היוצאת. ברגע שהתשובה מתקבלת, היא מומרת לפורמט שהאפליקציה שלכם דורשת.
6. השער מתעד את מה שקרה: כשהרישום ביומן מופעל, השער מתעד פרטים כמו מי ביצע את הקריאה, איזה מודל טיפל בה, מספר הטוקנים, זמן ההשהיה והעלות. זה בדיוק היומן שלא היה למהנדס מ־Reddit שהזכרנו בפתיחה.

4 דברים שחשוב לדעת לפני שמכניסים שער לסביבת ייצור

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

השער הוא עכשיו הרכיב בעל הערך הרב ביותר בסטאק ה־AI שלכם

השער מרכז את הגישה, ולכן הוא גם שם הרבה פרטי הזדהות בהישג ידו של שירות אחד. צוות האבטחה של Microsoft מפרט מה פריסה של LiteLLM עשויה להחזיק או לאחזר: מפתחות API של ספקים, מפתח המאסטר שלה עצמה, רשומות של מפתחות וירטואליים, מחרוזות חיבור למסד נתונים, הגדרות ניתוב ומדיניות של דיירים (tenants).

באוקטובר 2026 חשפה Check Point Research שתי פגיעויות בסיכון גבוה ב־LiteLLM:

• CVE-2026-35029 אפשרה למשתמשים מאומתים, כולל משתמשים עם הרשאת קריאה בלבד, לגשת לפונקציות ניהול ולהשתלט על המופע.
• CVE-2026-59823 אפשרה למשתמשים להפנות בקשות לשרת שבשליטתם וללכוד מפתחות של ספקים.

שתיהן תוקנו בגרסה 1.83.9. אפליקציה שמשתמשת בשער לא אמורה להיות מסוגלת לשנות את ההגדרות שלו.

מעקות הבטיחות שלכם צריכים מדיניות למקרה של כשל

סקירה של Pillar Security מ־4 באוקטובר 2026 מתעדת שילובים של מעקות בטיחות של צד שלישי בשערים המובילים, כולל LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management ו־Apigee. (Pillar מוכרת מעקות בטיחות, אז כדאי לזכור את זה כשקוראים את ההמלצות שלה.)

הוק (hook) הוא נקודה בנתיב הבקשה, בדרך כלל לפני שהפרומפט נשלח למודל או אחרי שהתשובה חוזרת, שבה השער יכול להעביר את התוכן לסורק חיצוני לקבלת הכרעה. בדיקה חוסמת ממתינה להכרעה הזו לפני שהיא מאפשרת לתעבורה להמשיך. התיעוד של Portkey קורא להם before_request_hooks ו־after_request_hooks; TrueFoundry מריצה ארבעה, ומוסיפה בדיקות לפני קריאות לכלי MCP ואחריהן.

עכשיו, שני דברים שכדאי לבדוק:

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

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

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

צריך לדעת איפה נגמרת השליטה של השער

Forkast News מזהה שלוש שושלות שמגיעות לשער מכיוונים שונים:

• שערים ממוקדי LLM: LiteLLM ו־Portkey התחילו מקריאות למודלים: תרגום בין ספקים, ניתוב בקשות ומעקב אחר טוקנים. עכשיו הם מוסיפים בקרות לקריאות לכלים.
• פלטפורמות לניהול API: Kong, Apigee של Google ו־Azure API Management התחילו מאימות, הרשאות וניהול תעבורה, ואז הוסיפו תמיכה במודלים ובכללים ייעודיים ל־AI.
• תשתית שנבנתה מלכתחילה לסוכנים: agentgateway, למשל, נבנה סביב סוכנים שמתקשרים עם מודלים, כלים וסוכנים אחרים, בין היתר דרך MCP ו־A2A.

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

• רק קריאות למודלים? שער שמתמקד קודם כול ב־LLM הוא נקודת התחלה טובה.
• קריאות למודלים בתוך ארגון שכבר מלא בכללי API? התחילו עם הפלטפורמה שכבר יש לכם.
• סוכנים שקוראים לכלים שקוראים למודלים? ודאו שגם החיבורים האלה מכוסים.

אתם יוצרים נקודת כשל משותפת

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

זה באמת קרה. שיעור השגיאות של AI Gateway של Cloudflare הגיע לשיא של 97% במהלך ההשבתה ב־12 ביוני 2025. השער הסתמך על שירות האחסון Workers KV של Cloudflare לצורך ההגדרות, והשירות הזה כשל.

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

התכונות המרכזיות שכדאי לחפש בשערי LLM

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

• API אחד מול כמה ספקים: הקוד שלכם מדבר בפורמט אחד, לרוב פורמט תואם OpenAI, והשער מתרגם. גם ספקי LLM באים לקראתו באמצע הדרך. לדוגמה, Agent API של Perplexity תומך בממשק Responses API של OpenAI, כך שצוותים יכולים להשתמש מחדש בספריות לקוח קיימות של OpenAI.
• מפתחות וירטואליים עם כללים מצורפים: כל צוות או מוצר מקבל מפתח משלו, עם כללים שקובעים אילו מודלים מותרים, מהן מגבלות הבקשות ומהי תקרת ההוצאות.
• ניתוב וגיבוי (fallback): השער שולח בקשות למודלים לפי ההגדרות שלכם, שעשויות להעדיף עלות, מהירות או ספק מסוים. אם קריאה נכשלת, הוא יכול לנסות מודל אחר. Agent API של Perplexity מאפשר לכם לרשום עד חמישה מודלים, כולל מודלים מספקים שונים, לפי סדר ההעדפה שלכם.
• שמירה במטמון: תשובה שמורה יכולה לחסוך לכם קריאה נוספת לספק. חלק מהשערים מתאימים בקשות זהות; אחרים יכולים להתאים גם בקשות בעלות משמעות דומה. בדקו אם אפשר להפריד תשובות שמורות לפי משתמש או צוות, ואם אפשר לכבות את השמירה במטמון עבור תשובות מותאמות אישית או תלויות זמן.
• הזרמה ושגיאות עקביות: התשובות מגיעות תוך כדי יצירתן, ושגיאות של ספקים מתורגמות לפורמט שהאפליקציה שלכם יודעת לטפל בו. בדקו מה קורה כשאתם מוסיפים מעקות בטיחות ל־AI.
• רישום ביומן ושיוך עלויות: השער מתעד מי ביצע קריאה, איזה מודל טיפל בה, כמה טוקנים היא צרכה, כמה זמן היא נמשכה ואת העלות המשוערת שלה. בדקו אם היומנים כוללים פרומפטים ותשובות, וכמה זמן הם נשמרים.
• הוקים למעקות בטיחות: אלה נקודות בנתיב הבקשה שבהן השער יכול לשלוח תוכן לסורק חיצוני לקבלת הכרעה. בדרך כלל הם ממוקמים לפני בקשה למודל או אחרי התשובה שלו. בדקו אם בקשות נעצרות או ממשיכות כשהסורק נכשל, ואם אפשר לחבר סורק אחר.
• ממשק ניהול שאפשר לנעול: השער מנהל את הגישה לפרטי ההזדהות של הספקים ולכללים שכולם משתמשים בהם. ודאו שאפשר להגביל את הגישה לממשק הניהול בנפרד מתעבורת האפליקציות, ושמשתמשים עם הרשאת קריאה בלבד לא יכולים לשנות הגדרות. הברז הראשי צריך מנעול.

באילו כלים אפשר להשתמש כדי לבנות שער LLM?

רשימות התכונות חופפות בכל השוק. בשרשור אחד ב־Reddit על גישה פנימית למודלים, מי שפתח את השרשור שאל: איזה שער לא ידרוש מהנדס ייעודי?

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

לכתוב אותו בעצמכם

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

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

בשרשור ב־r/LLMDevs על השאלה אם שער מוריד עלויות, u/QuanTradin כתב שרישום של טוקנים ושל דגל cache-hit בכל קריאה עזר לו לגלות שתי משימות ששילמו מחיר מלא על פרומפטים זהים.

“...התיקון של זה היה שווה יותר מכל מה ששכבת ניתוב כלשהי הייתה יכולה לתת.”

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

לארח בעצמכם שער בקוד פתוח

LiteLLM הוא בחירה נפוצה כאן: הוא תואם OpenAI, תומך במגוון רחב של ספקים ויש לו קהילה גדולה. Bifrost הוא חלופה שנבנתה לתקורה נמוכה לכל בקשה. כדאי לבדוק את Helicone אם נראות (observability) נמצאת בראש רשימת התכונות שלכם.

ל־LiteLLM, כמו לכל מוצר, יש מגבלות עבור צוותים מסוימים. בשרשור ב־r/aiagents על חלופות לבנייה עצמית, u/Own_Bar_920 כתב ש־LiteLLM טיפל היטב בניתוב, אבל לא סיפק מענה לצרכים שלו בניהול גרסאות של פרומפטים בין צוותים ובהערכות (evals) רציפות בעת החלפת מודלים, מה שדחף אותו לכלי נפרד.

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

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

אבל הקצו תקציב לאדם שיהיה אחראי לזה. אחד החששות בשרשור ב־r/LLMDevs על שערים לגישה פנימית היה תחזוקה. u/Informal-Writer9685 רצה משהו ש“לא דורש מהנדס ייעודי לתחזוקה”, ושאל אם חוסר היציבות בשדרוגים של LiteLLM, שדווח עליו, הוא בעיה אמיתית בהיקף שלו או חשש שרלוונטי רק לסביבת ייצור.

להשתמש בשער מנוהל

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter והשער המאוחסן של Portkey מפעילים את השירות בשבילכם. באפליקציה תואמת, ייתכן שכדי להעביר את הבקשה הראשונה לא יידרש הרבה יותר משינוי כתובת URL ומפתח API.

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

לדוגמה, ב־17 וב־19 בפברואר 2026 חוותה OpenRouter השבתות שנמשכו 38 ו־35 דקות, בהתאמה, לאחר שרכיב שמירה במטמון שהיא תלויה בו כשל. חלק מהלקוחות קיבלו שגיאות “User not found” ובזבזו זמן על ניפוי באגים במפתחות API תקינים לחלוטין. התקלה הייתה בתשתית של השער.

אבל לזכותה ייאמר ש־OpenRouter פרסמה ניתוח מפורט לאחר התקרית (postmortem) והוסיפה הגנות שמונעות מכשל במטמון להציף את מסד הנתונים שלה. שער מנוהל כמו OpenRouter יכול לפשט את הגישה, אבל כפי ש־u/QuanTradin מציין ב־r/LLMDevs, איחוד החשבוניות לא מפחית את ההוצאות באופן אוטומטי.

להרחיב את שער ה־API שכבר יש לכם

אם Kong, Apigee או Azure API Management כבר עומדים בחזית השירותים שלכם, לכל אחד מהם יש יכולות ייעודיות ל־AI: Kong AI Gateway, מדיניות שער ה־AI של Apigee ושער ה־AI של Azure API Management. אפשר לבנות על האימות, כללי הרשת ונהלי התפעול שכבר יש לכם, ולהוסיף בקרות למודלים באמצעות תוספים או מדיניות.

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

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

שער פותר את הבעיה הזו בכך שהוא מעביר את המפתחות האלה לשליטה מרכזית – מה שדווקא מעלה את המחיר של השארת המגירה פתוחה. צריך לדעת של מי המגירה.

שאלות נפוצות על שערי LLM

האם שער ה-LLM חינמי?

אם הכוונה לקטגוריה, לחלק משערי ה-LLM יש גרסאות חינמיות.

שערי LLM נעים בין תוכנת קוד פתוח חינמית לבין תוכניות בתשלום שמתחילות בסביבות 50 דולר לחודש, עם תמחור מותאם אישית לפריסות ארגוניות. יש גם כאלה שגובים במקום זאת אחוז; לדוגמה, תוכנית Standard של OpenRouter מוסיפה 5.5% לרכישת קרדיטים.

איזה שער LLM הוא הטוב ביותר?

איזו עבודה אתם מוכנים לקחת על עצמכם?

• כדאי לבדוק את Bifrost או את Helicone אם אתם רוצים לארח בעצמכם ולשלוט בהגדרות.
• אפשרות מנוהלת כמו OpenRouter או Vercel AI Gateway מתאימה לצוותים שמעדיפים שמישהו אחר יפעיל את השירות.
• אם אתם כבר משתמשים ב-Kong או ב-Azure API Management, בדקו קודם את יכולות ה-AI שלהם.

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

האם ל-AWS יש שער LLM?

כן. Amazon Bedrock AgentCore Gateway תומך בקריאות למודלים באמצעות מה ש-AWS מכנה ״יעדי הסקה״ (inference targets). הם מאפשרים לאפליקציות להשתמש בנקודת קצה אחת כדי להגיע לספקים כמו Amazon Bedrock,‏ OpenAI ו-Anthropic, כשהשער מטפל בפרטי הגישה של הספקים ובניתוב.