Agent-Native Rate Limiting — הגבלת קצב שמתחשבת בעלות חשיבה לא רק בבקשות

מאת צוות מדיה דיל · 12.08.2026 · Model Economics · 6 דק׳

מגבלה של 100 בקשות לדקה מתעלמת מכך שבקשה אחת יכולה לעלות פי אלף מאחרת. מדריך לבניית rate limiting ששוקל עלות חישוב בפועל, לא רק ספירת קריאות.

צוות תשתיות שהגדיר מגבלת 100 בקשות לדקה למשתמש גילה תקלה מוזרה: משתמש בודד "הצליח" להפיל את התקציב היומי כולו של הארגון תוך פחות משעה, בלי לחרוג ולו פעם אחת ממגבלת הבקשות לדקה. ההסבר התברר כשבדקו את הלוגים — המשתמש הזה לא שלח שאלות פשוטות; הוא הפעיל workflow שיצר עשרות תתי-משימות agentic, כל אחת עם budget חשיבה גבוה וסבבי tool calling ארוכים. מבחינת מונה קצב הבקשות, הוא היה בדיוק כמו כל משתמש אחר. מבחינת עלות בפועל, הוא היה שווה ל-200 משתמשים רגילים. rate limiting מסורתי סופר אירועים, לא עלות — וזו בדיוק הפירצה שמערכות agentic חושפות, כי הפער בין עלות בקשה זולה לבקשה יקרה יכול להגיע לפי אלף ומעלה.

למה ספירת בקשות פשוט לא מודדת את הדבר הנכון

rate limiting קלאסי (token bucket או sliding window על מספר קריאות) נבנה עבור עולם שבו כל קריאת API עולה בערך אותו דבר — קריאה ל-REST endpoint, שאילתת מסד נתונים. במערכת agentic ההנחה הזו פשוט לא מתקיימת: בקשה אחת יכולה להיות "מה השעה", ובקשה אחרת יכולה להיות ניתוח מסמך בן 50 עמודים עם עשרים סבבי תכנון ו-budget חשיבה של 64K טוקן. אם שתיהן נספרות כ"בקשה אחת" לצורך המגבלה, משתמש שמרבה בבקשות היקרות יכול לצרוך משאבים לא פרופורציונליים בלי להפעיל שום מנגנון הגנה, בעוד משתמש עם המון בקשות זולות נחסם בגלל מספר גבוה שלהן, גם שהעלות המצטברת שלו נמוכה בהרבה. זו בדיוק תופעת ה-noisy neighbor המוכרת מתשתיות multi-tenant, רק שבעולם ה-AI ההשפעה שלה על העלות חדה בהרבה מהשפעתה על עומס CPU רגיל.

מעבר ל-token bucket משוקלל לפי עלות

הפתרון המעשי הוא להחליף את יחידת המדידה: במקום לספור "בקשות", סופרים יחידות עלות משוערות (cost units), ולתת לכל בקשה משקל שמשקף את העלות הצפויה שלה, לא את עצם קיומה. זה דורש שלושה מרכיבים:

• אומדן עלות מראש (pre-flight estimation) — לפני הרצת הבקשה, שכבת ניתוב מסווגת אותה לקטגוריית עלות משוערת, בדומה למנגנון שמתואר ב-Semantic Model Router, כדי לדעת בערך כמה "עולה" הבקשה עוד לפני שהיא רצה בפועל.
• bucket שמתמלא ומתרוקן ביחידות עלות, לא בבקשות — כל משתמש או צוות מקבל תקציב יחידות עלות לפרק זמן נתון, וכל בקשה מנכה ממנו לפי האומדן שלה, לא לפי "אחד" קבוע.
• עדכון בדיעבד לפי עלות בפועל — לאחר שהבקשה הסתיימה, מתקנים את היתרה לפי העלות האמיתית שנמדדה (שיכולה לחרוג מהאומדן, למשל בגלל אסקלציית budget), כדי שהמערכת לא תסטה שיטתית מהיתרה האמיתית.

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

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

הגבלה היררכית עם התדרדרות חינה ולא חסימה קשה

מגבלת עלות טובה לא צריכה להיות בינארית (מותר/חסום). הגישה הבשלה יותר היא הגבלה היררכית עם התדרדרות מדורגת: כשמשתמש מתקרב למכסה, המערכת לא חוסמת אותו מיד אלא מורידה אותו למסלול זול יותר — מודל קטן יותר, budget חשיבה מוגבל יותר, ללא הרצה ספקולטיבית — ורק כשגם זה לא מספיק, חוסמת זמנית. ההיררכיה עצמה נבנית בשלוש רמות: מכסה למשתמש בודד (מונעת ניצול לרעה של חשבון יחיד), מכסה לצוות או פיצ'ר (מונעת מקרה שבו פיצ'ר באג הופך לחור שחור תקציבי), ומכסה כוללת לארגון (רשת ביטחון אחרונה מול חריגה קטסטרופלית). כל שלוש הרמות האלה נשענות על אותו נתוני ייחוס שנאספים ב-Agent Cost Attribution, כי בלי לדעת מי צורך מה, אי אפשר להטיל מגבלה הוגנת ברמת הפרט או הצוות.

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

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

תזמון קיבולת מול spike בעלות ולא רק בנפח

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

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

תגיות: Rate Limiting · Token Bucket · Cost-Aware Throttling · Load Balancing · Model Economics

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