ספירת טוקנים: היכן צריכת הבקשות יוצאת מכלל שליטה
כל בקשה למודל שפה מחויבת לא לפי משמעות התשובה, אלא לפי נפח ההקשר: ספירת הטוקנים נעשית לפי הוראת הקלט, היסטוריית השיחה והתשובה שנוצרה. כל עוד התרחיש אחד וההתכתבות קצרה, צריכת הבקשות צפויה ונכנסת לציפיות.
ברגע שמופיע הקשר שיחה ארוך, מסמכים מצורפים ושרשראות קריאות, המונה בצד השירות מפסיק להתאים למה שהצוות תכנן.
המנגנון הראשון של דליפה — הצטברות היסטוריה. כל צעד עוקב בשיחה שולח מחדש את כל ההתכתבות הקודמת יחד עם הוראת המערכת, לכן התגובה העשירית עולה פי כמה מהראשונה, אף שהמשתמש כתב שורה אחת. בלי ספירת טוקנים לכל צעד זה נעשה מורגש רק בתום התקופה.
השני — קריאות חוזרות למודל. חזרות בגלל פסק זמן, קריאות מקבילות ומפוצלות, שאילתה חוזרת על כל פעולה בממשק: אותו קטע הקשר משולם כמה פעמים. לכאן גם בלוקים מערכתיים קבועים, שמועברים בכל צעד ואינם נשמרים במטמון.
השלישי — היעדר מעקב לפי משתמשים ותרחישים. כשצריכת הבקשות מונחת כסכום כולל אחד, אי אפשר לענות איזו פונקציה או איזה חשבון לוקח את החלק העיקרי. פילוח לפי תרחישים, לקוחות וסוג פעולה הופך את החשבון לנתון ניתן לניהול.
אנחנו מפרקים איך זה נסגר: היכן לשים מונים, איך לקצץ הקשר בלי לאבד איכות ואיך להציב מגבלות לפני שהצריכה תזנק.
מה נותנת ספירת טוקנים: שליטה, מגבלות, דיווח
כל פנייה למודל שפה נספרת בטוקנים: קלט — פרומפט יחד עם היסטוריית השיחה, פלט — התשובה. אצל OpenAI וספקי מודלים אחרים התמחור בנוי בדיוק על זה, לכן צריכה בלי מעקב היא נגזרת של מי ובאיזו תדירות שאל. אנחנו מתעדים מונה בכל קריאה ומשייכים אותו למשתמש, לשירות ולסשן — מכאן זה לא לוג גולמי, אלא מדד.
מעקב צריכה בפילוח לפי משתמשים מראה היכן הולך הנפח העיקרי: מחלקה אחת נותנת פרומפטים כבדים וארוכים, ואילו בקשות קצרות תכופות ממדריך כמעט לא צורכות דבר. בנפרד רואים את שיעור הפגיעות במטמון: הקשר חוזר לא משולם פעמיים, וזה המנוף המהיר ביותר להורדת צריכה.
אנומליות — בקשה עם היסטוריה של עשרות אלפי טוקנים, חזרות מעגליות, סקריפט דיבאג נשכח — נמצאות בימים הראשונים, ולא בסוף התקופה.
מגבלות על בקשות מוצבות בנפרד לפי מספר קריאות ולפי נפח טוקנים בדקה — למשתמש, לצוות ולשירות. סף רך מעביר את הפנייה לתור או מקצר את התשובה, סף קשיח מחזיר סירוב; הבחירה תלויה בתרחיש. עומסי שיא מחליקים באמצעות תור, עיבוד באצוות ומטמון — הצריכה מפסיקה לגדול במדרגות.
דיווח — זה חתך יומי לפי שירותים ומשתמשים: נפח טוקנים, דינמיקה, מקור הזינוק. לפיו רואים מה לשנות: ניסוח הפרומפט, אורך ההקשר המועבר או את המודל עצמו.
מצבי מעקב: שכבת פרוקסי, עטיפת קריאות, יומני ספק
אפשר לספור צריכה בשלוש נקודות: במתווך רשת, בתוך קוד האפליקציה או לפי יומני ספק המודל עצמו. הנקודות נבדלות במה שכל אחת רואה: מתווך — רק גוף הבקשה והתשובה, עטיפה — גם את הקשר הקריאה, והיומנים מכילים ערכים שכבר נספרו.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| שכבת פרוקסי | נדרשת שליטה אחודה בכל השירותים בבת אחת, כולל אפליקציות זרות, בלי שינויים בקוד | מסיימת את החיבור ודורשת אמון בצומת; לא מכירה גבולות לוגיים של פעולה — משימה אחת מתפצלת לכמה קריאות |
| עטיפת קריאות | מעקב נדרש לפי פעולות ומשתמשים, עם מגבלות והערכת צריכה לפני שליחה | עובדת רק במקום שבו חיברו אותה; פניות ישירות בעקיפת העטיפה נופלות מהמעקב |
| יומני ספק | התאמה ושליטה: המספרים מגיעים מהספק, אין פערים מול החיוב | השהיה מדקות עד שעות; אין פילוח לפי פעולות פנימיות; ייתכן שחלק מהקריאות אינו מתויג |
שמירה במטמון של תשובות מוסיפה הסתעפות. פגיעה במטמון לא מבזבזת טוקנים, אבל אם לנכות אותה ממגבלת המשתמש — זו שאלת מדיניות: כשמנכים לפי פנייה בפועל, המטמון אוכל את התקציב בלי שימו לב, ובסירוב מלא לניכוי נוצר תמריץ לפצל בקשות זהות.
מעשי יותר לשלב מצבים: עטיפה נותנת מגבלה תפעולית והערכה לפני שליחה, פרוקסי מכסה שירותים בלי שינויים בקוד, ויומנים משמשים מקור אמת להתאמה. פער ביניהם — סימן שחלק מהתעבורה עובר מחוץ למעקב.
הטמעת מעקב צריכה: מביקורת קריאות ועד תקנון
סדר העבודה זהה גם לשירות חדש וגם לשירות שכבר פעיל: קודם מודדים, אחר כך מגבילים. מתחילים בביקורת קריאות — היא מראה היכן הצריכה נוצרת באמת, ולא במקום שבו מצפים לה. בהמשך תרשים מעקב, מגבלות, בדיקה בעומס ומסירה יחד עם תקנון.
- ביקורת קריאות. ספירת מלאי של זרימות: מי יוזם בקשה, כמה הקשר עובר למודל, אילו פניות כפולות, היכן נוצרת תשובה מלאה בגלל שורה אחת. התוצאה — מפה עם חלקו של כל תרחיש בנפח הכולל.
- תרשים מעקב. בוחרים נקודת מדידה: אפליקציה לפני שליחה או שכבת פרוקסי. קובעים מה אנחנו מייחסים לבקשה — הקשר, היסטוריית שיחה, תשובת המודל, פניות לכלים.
- ספירת טוקנים. טוקנייזר אחד למודל היעד, אחרת הדוח לא יתאם לספירת הספק. קלט ופלט סופרים בנפרד, עם חתך לפי תרחישים.
- הגדרת מגבלות. שלוש רמות: יומית לתרחיש, לסשן משתמש ועצירת חירום לכל השירות. עם מיצוי — ירידה צפויה בביצועים במקום חריגה שקטה.
- בדיקה בעומס. פרופיל פניות אמיתיות: איך המונים מתנהגים בבקשות מקבילות ובניתוקי חיבור, האם תשובות זורמות נכנסות למעקב. פער מול נתוני הספק באחוזים בודדים — תקין, יותר מעיד על שגיאה בנקודת המדידה.
- תקנון ומסירה. מוסרים לוח בקרה, כללים לעדכון מגבלות, סדר טיפול בפערים ובעלים לכל תרחיש. מכאן תיקוני פרומפטים עוברים באותו מסלול: שינוי → מדידה → מגבלה.
ערכת מסירה: תרשימי מעקב, מדיניות מגבלות, תקנונים
ההטמעה מסתיימת לא במונה עובד, אלא ברגע שבו צוות הלקוח בעצמו משנה מגבלות, מטפל בחריגות ומחבר שירות חדש בלעדינו. לכן אנחנו מוסרים לא דוח על העבודה שנעשתה, אלא ערכה עובדת: קונפיגורציות, תרשימים ותקנונים שנמצאים באותו מאגר קוד ומתעדכנים יחד עם השירות.
- תרשים זרימות נתונים: באיזו נקודה נספרת צריכת הטוקנים, לאן זורמים האגרגטים, איך הם מגיעים לדיווח, היכן נקודות הכשל ומי אחראי על כל קטע.
- מדיניות מגבלות: ספים ליחידה, לשירות ולמשתמש בודד, וגם התנהגות עם מיצוי — התראה, סירוב או מעבר למודל חסכוני יותר.
- תקנון הסלמה: באיזו סטייה מהפרופיל הרגיל של הצריכה מתריעים, מי ובאיזה פרק זמן מגיב, מי רשאי להעלות סף באופן זמני.
- תיעוד מסירה: סדר פריסה, עדכון מדריך התעריפים, חיבור מודל חדש ובדיקה שהמעקב לא התפצל מהצריכה.
- תרחישי התאמה: מערך בקשות עם צריכה ידועה מראש, שמורץ אחרי כל שינוי ותופס פער לפני שהוא מגיע לדיווח.
- דיווח וייצוא: צריכה לפי צוותים ותרחישים, שיעור בקשות חוזרות שנסגרו בלי פנייה למודל, דינמיקה לתקופה שרירותית.
הערכה נשארת עובדת בלעדינו: תיקוני מדיניות עוברים סקירה רגילה, ומהנדס חדש נכנס למסלול לפי התיעוד, ולא לפי סיפורי הקולגות.
מקרה בוחן: הצריכה של מודלי שפה הפסיקה לגדול בזמן גידול בעומס
מה היה
עוזר קו ראשון ניהל שיחות בצ'אט ובמייל: היסטוריית התכתבות, קטעים מבסיס הידע והוראות מערכת עברו למודל בבלוק אחד. הפניות גדלו פי שלושה בעונה, והצריכה של המודל חזרה על הגרף הזה כמעט ליניארית.
הזינוקים הוסיפו משלהם: עם מיצוי מגבלת הספק הבקשה נפלה עם שגיאה ועברה לחזרה, והחזרה חויבה כתשובה חדשה.
מה שינו
מעקב הטוקנים הועבר לשער לפני המודל — קלט ופלט נספרו בנפרד, עם פילוח לפי תרחיש, משתמש ומחלקת מודל; מדדים נלקחו דרך Langfuse. לפיהם התגלה ש-60% מהנפח נאכלים על ידי שלושה תרחישים מתוך שנים עשר, ויותר ממחצית מהיסטוריית השיחה המועברת המודל לא משתמש בה.
בהמשך — מגבלות במקום סירובים: קיצוץ ההיסטוריה להודעות האחרונות עם שמירת תקציר קצר, ניתוב בקשות קצרות למודל במחלקה צעירה יותר, מטמון לפרומפטים חוזרים בגבולות חלון השיחה. לכל תרחיש הוצב סף: התראה ב-80% וירידה הדרגתית בביצועים במקום שגיאה עם מיצוי.
מה נהיה
| מדד | לפני | אחרי |
|---|---|---|
| פניות בחודש | רמת בסיס | פי שלושה יותר |
| טוקנים לבקשה | הקשר מלא | פי שלושה פחות |
| שיעור חזרות אחרי שגיאה | 18% | 4% |
| סירובים בגלל מגבלת הספק | זינוקים קבועים | אפס |
הצריכה הפסיקה לעקוב אחרי העומס: פניות פי שלושה יותר, ונפח הטוקנים גדל רק בחמישית ונשאר ברמה הזו. הופיע גם אפקט שני — לפי הפילוח רואים מראש בכמה פעמים תרחיש חדש יגדיל את העומס, עוד לפני העלאה לפרודקשן.
מה לעשות אם המגבלות כבר נחצו, והצריכה ממשיכה לגדול?
חריגה ממגבלות כמעט אף פעם לא קשורה לעלייה בתעריפים — צריכת הטוקנים גדלה במסלול מסוים אחד: הקשר מנופח, לולאה בסוכן, חזרות אחרי תקלות או משימת רקע בלי תקרה. לכן סדר הפעולות הפוך לאינטואיציה: קודם לעצור את הגידול, אחר כך לחפש את הסיבה. אבחון על תעבורה חיה, שממשיכה לצרוך מכסה, לא יראה דבר.
הצעד הראשון — לחתוך תעבורה בעדיפות נמוכה: עיבוד באצוות, אינדוקס מחדש, העשרות רקע. זה מסיר חלק ניכר מהצריכה תוך דקות ולא פוגע בתרחישי משתמש. אחר כך הצריכה מפורקת לפי צירים: מפתח גישה, מודל, מתודה, שוכר, שעה ביום.
יומני בקשות של הספק — OpenAI והדומים מספקים פילוח כזה — משווים לקו הבסיס של השבוע שעבר ומוצאים את הנקודה שבה הגרף עלה.
ספי חירום מוצבים מראש: 70–80% מהמכסה היומית — התראה לאחראי, 100% — מעבר אוטומטי של תרחישים בעדיפות נמוכה למודל חסכוני יותר או סירוב שירות. אחרי התייצבות, הספים נבחנים מחדש לפי פרופיל העומס בפועל, אחרת ההגנה תתחיל לפעול בשיא תקין.
ספקות טכניים נפוצים לגבי מעקב צריכה ומגבלות
ספקות לגבי מעקב נוגעים בדרך כלל לא לנוסחה עצמה, אלא להתנהגות המונה בתעבורה אמיתית: האם הוא מתאים לחשבון שהוצג, מה קורה בתשובה זורמת, כמה עולה הבקרה עצמה. מפרקים שאלות שצוותי הנדסה מגיעים איתן בתדירות הגבוהה ביותר.
עד כמה ספירת הטוקנים מדויקת והיכן היא לא מתאימה לספק?
סופרים עם אותו טוקנייזר של מודל היעד, לכן הפער נוצר רק בעטיפות שירות ובהודעות מערכת. בדוח שומרים את שני הערכים — שלנו וזה שאושר בתשובת הספק — ומציגים את ההפרש בעמודה נפרדת. אם הפער חורג מהסף שהוגדר, זה סימן שהמודל עודכן ויש לבדוק מחדש את הסימון.
איך נספרים טוקנים בהזרמה, כשהתשובה מגיעה בקטעים?
המונה צובר את הקטעים בהדרגה עם הגעתם ומקבע את הסיכום ברגע סיום הזרם — ערכי ביניים לא נכתבים להיסטוריה, אחרת נקבל עשרות רשומות שגויות לקריאה אחת. עבור חיבורים שנקטעו שומרים הערכה לפי הפרומפט והטקסט שכבר הגיע, עם סימן נפרד, כדי שרשומות כאלה לא יתערבבו עם רשומות מלאות.
עד כמה הספירה מאטה את התשובה — האם ההשהיה גדלה?
שכבת הבקרה נמצאת בנתיב הבקשה ומוסיפה לזמן התגובה הכולל אחוזים בודדים, ולא ערך קבוע. בהזרמה, הקטע הראשון עובר ללקוח לפני שכל התשובה נספרת, לכן המשתמש לא מבחין בהבדל. אם השכבה הופכת לצוואר בקבוק, מוציאים אותה מהנתיב הראשי וסופרים באופן א-סינכרוני, עם סיום הקריאה.
מה בדיוק נשמר בהיסטוריית הקריאות ואיך היא לא מתפשטת?
כותבים רשומות קומפקטיות: מזהה בקשה, מודל, מונים, סימן זרם, חתימת זמן ותוצאת בדיקת המגבלה. טקסטים של פרומפטים ותשובות נשמרים אופציונלית, עם תקופת שמירה ניתנת להגדרה וניקוי לפי לוח זמנים — אז ההיסטוריה נשארת שמישה לחקירת אירועים, אבל הנפח לא גדל בלי סוף.
נדון במשימה: איך להביא את מעקב הצריכה לשליטה
כדי שהערכת ההטמעה תהיה לא לפי הערכה גסה, אלא לפי עובדות, נדרשים נתוני מקור על איך שנצרכות כעת בקשות למודלים. להלן רשימה קצרה: אם חלק מהסעיפים חסר, גם זו תשובה, היא מראה את היקף עבודת ההכנה בתוכנית העבודה.
- רשימת שירותים ותרחישים שפונים למודלים, עם תדירות קריאות משוערת;
- דוגמאות אנונימיות של בקשות ותשובות — לפיהן רואים היכן ההקשר מנופח בלי תועלת לתוצאה;
- כללי המגבלות הנוכחיים ואיך מטופלות חריגות כיום;
- ייצוא יומני פניות לתקופה אופיינית: שבוע שקט ושיא עומס;
- תרשים ניתוב: אילו מודלים ובאילו מצבים מעורבים, היכן יש מלאי למעבר;
- דרישות לדיווח — באיזה חתך צריך לראות את הצריכה: לפי מוצר, צוות או לקוח;
- מגבלות תשתית והרשאות, אם צריך להטמיע את המעקב במסלול קיים.
עם הסט הזה אנחנו חוזרים עם הערכת הטמעה ותוכנית עבודה: רצף צעדים, נקודות בקרה, מה ומתי יופיע בדוחות. תארו את המשימה בצורה נוחה — נדון מה במקרה שלכם ייתן אפקט מיד, ומה אפשר לא לעשות.