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

מה נשבר ללא rate limiting בשירותי AI

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

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

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

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

מה נותן ניהול הגבלות: הפחתת עומס וסירובים

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

שיעור הסירובים מפסיק להיות תלוי בתעבורה של אחרים

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

השיא עובר בהדרדרות, לא בסירוב

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

השהיית התגובה מפסיקה "לנוע"

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

הקיבולת מוקצית באופן שווה

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

מצבי הגבלה: הגבלות בקשות, מכסות טוקנים, תורים

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

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

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

שלבי יישום: ממדידת עומס ועד לתקנון

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

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

1. פרופיל עומס. אוספים סטטיסטיקה על פני כמה שבועות, כולל לפחות תקופת שיא אחת. בנפרד מסמנים אילו פניות קריטיות לתהליך העסקי, ואילו ניתן לדחות לתור.
2. חישוב ספים. מגדירים הגבלות בשכבות — לפי מפתח, לפי משתמש, לפי השירות כולו — עם מרווח עד לרוויה של המודל, כך שהמגביל יפעל לפני שזמן התגובה יתחיל לעלות.
3. הגדרת המגביל. בוחרים אלגוריתם לפי אופי התעבורה (חלון מחליק או דלי מתמלא) ומנהיגים מכסות נפרדות למספר הבקשות ולנפח הטוקנים: קריאה קצרה והקשר ארוך צורכים משאב באופן שאינו דומה.
4. טיפול בסירובים. ההגבלה צריכה להיות צפויה: קוד תשובה ברור, ציון מתי לחזור, תור עדיפות לפעולות קריטיות.
5. בדיקה תחת שיא. מריצים פרופיל שחוזר על השיא האמיתי עם מרווח, ומקבעים באילו ערכים מופיעים סירובים והאם הם פוגעים בלקוחות תמימים.
6. תקנון תפעול. מוסרים מסמך: כיצד לשנות מכסות, היכן לצפות במדדים, באילו חריגות להעלות את ההגבלה, כיצד להעניק חריגה זמנית.

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

מה מוסרים ללקוח: תצורות, תרשימים, תקנונים

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

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

את הערכה מעדכנים יחד עם השירות: אחרת התקנון סוטה מהסביבה, ובאירוע אף אחד לא יודע היכן האמת.

מקרה בוחן: עומס שיא של משתמשים ללא סירובים

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

גם שליחות חוזרות בעת פסק זמן תרמו את חלקן: המשתמש לחץ על הכפתור שוב, האפליקציה הציבה משימה שנייה לאותו צוואר בקבוק. התוצאה — 7.8% תשובות עם שגיאה ו-p95 השהיה של 12 שניות, ובעשרים דקות השיא שיעור הסירובים הגיע ל-15%: אנשים עזבו בלי להמתין לתשובה.

מה הוצב בכניסה

הגבלת התדירות נעשתה דו-שלבית: token bucket לפי משתמש עם זכות לפרץ קצר וחלון מחליק של 60 שניות להחלקה. מעל — מכסת טוקנים יומית לפי כל תעריף ותור עדיפות לפניות בתשלום. נתיך כללי לספק נפתח בעת עלייה בשגיאות ומונע להשלים אותו עם חזרות.

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

מדדים לאחר מכן

• סירובים: 7.8% → 0.4% מכלל הבקשות.
• השהיית p95: 12 שניות → 2.6 שניות; פרץ של עד 60 בקשות בשנייה עובר ללא הדרדרות.
• שיעור התשובות מהמטמון בשיא: 22%.
• פירוק התור שהצטבר לאחר תקלת ספק — 90 שניות במקום העברה ידנית מחדש.

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

מה לעשות אם שער AI כבר נתקע בתקרה?

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

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

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

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

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

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

ספקות טכניים נפוצים לגבי הגבלות ומכסות

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

להלן — התנגדויות שמועלות לרוב בעת תיאום התרשים: הן עוסקות בהתנהגות משתמשים אמיתיים ובהיקף השינויים בקוד.

האם אפשר להגדיר כללים שונים לצוותים ולמוצרים?

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

האם קל לעקוף הגבלות?

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

האם יהיה צורך לכתוב מחדש את קוד האפליקציה?

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

נדון בעומס שלכם — נחזור עם הערכה ותוכנית

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

• פרופיל עומס: בקשות בשנייה בשיא ובממוצע, התפלגות לפי נתיבי API ולפי לקוחות.
• צריכת טוקנים: חציון ואחוזון 95 לבקשה ולתשובה, שיעור ההקשרים הארוכים.
• מפתחות והרשאות: לפיהם אנו מחשבים מכסה — מפתח, חשבון, צוות; כיצד הם מונפקים ומבוטלים.
• התנהגות בעת סירובים: האם יש שליחות חוזרות, השהיה ביניהן, כמה תעבורה חוזרת לאחר קוד 429.
• מה כבר נמצא בכניסה: שער, פרוקסי, מאזן עומסים, היכן נמצאים המונים — בזיכרון של צומת נפרד או במאגר משותף.
• עדיפויות: אילו תרחישים אסור להפיל, ואילו מותר לעכב בתור.

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

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

תארו את המשימה ושלחו את מה שיש לגבי עומס — נחזור עם הערכה ותוכנית.