להוזיל עלויות LLM
בלי להתפשר על איכות

מאיפה בכלל מגיעה העלות

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

• הקלט חוזר על עצמו — בכל בקשה שולחים שוב את אותו system prompt, אותן הוראות ואותם מסמכים. משלמים עליהם כל פעם מחדש.
• ההקשר גדל — בשיחה או בסוכן, ההיסטוריה מצטברת. הבקשה ה-20 יקרה פי כמה מהראשונה כי היא נושאת את כל מה שקדם.
• מודל גדול מדי — משתמשים במודל הכי חזק גם למשימות פשוטות שמודל קטן וזול פי 5–25 היה עושה מצוין.

כל אחת מהבעיות האלה יש לה פתרון ישיר. נעבור עליהן לפי סדר ההשפעה.

Prompt Caching — הטכניקה עם ההשפעה הגדולה ביותר

זה החיסכון הכי גדול, ורוב האנשים לא מנצלים אותו. Prompt caching מאפשר לספק ה-AI "לזכור" חלק קבוע מהפרומפט בין בקשות. במקום לעבד מחדש בכל פעם את ה-2,000 טוקנים של ה-system prompt והמסמכים, המודל טוען אותם מהמטמון — במחיר מוזל דרמטית (טוקן שנקרא מהמטמון עולה כעשירית מטוקן קלט רגיל).

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

נקודות מפתח מעשיות: יש מינימום טוקנים כדי שמטמון בכלל יופעל (סביב 1,024 טוקנים — קצר מזה פשוט לא ייכנס למטמון), למטמון יש תוקף קצר (מתאפס אחרי כמה דקות של חוסר שימוש, אלא אם מרעננים), ומוגבל מספר "נקודות השבירה" של המטמון בבקשה. את החיסכון האמיתי משיגים כשאותו prefix גדול חוזר בהרבה בקשות — למשל צ'אטבוט עם system prompt ארוך, או RAG עם אותם מסמכי הקשר.

איך לא לשבור את המטמון בטעות

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

• timestamp דינמי בפרומפט — הזרקת datetime.now() לתוך ה-system prompt משנה אותו בכל בקשה ושוברת את המטמון לחלוטין. אם צריך זמן, שים אותו בסוף.
• JSON לא ממוין — אם סדר המפתחות ב-JSON משתנה בין בקשות, ה-prefix שונה. מיין תמיד.
• רשימת כלים משתנה — כלים שמתווספים/מוסרים או משנים סדר פוסלים את המטמון. שמור סדר קבוע.
• ID ייחודי בהתחלה — מזהה בקשה או session בתחילת הפרומפט = מטמון חדש בכל פעם.

Batch Processing — 50% הנחה על עבודה לא-דחופה

לא כל בקשה צריכה תשובה מיידית. אם אתה מעבד 10,000 מסמכים בלילה, מסווג דאטהסט, או מייצר תיאורים למוצרים — זו עבודה a-סינכרונית. רוב הספקים מציעים Batch API שמעבד בקשות כאלה בתוך חלון זמן (בד"כ עד 24 שעות) תמורת 50% הנחה על המחיר הרגיל.

הכלל פשוט: כל דבר שלא צריך תשובה בשנייה — לתוך batch. משתמש שמחכה לצ'אט צריך זמן אמת; ריצת לילה של דוחות לא. חצי מהחשבונית על כל העבודה הזו פשוט נעלמת.

בחירת מודל וניהול context

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

• נתב לפי מורכבות — משימות פשוטות למודל קטן וזול, משימות מורכבות למודל דגל. אפשר אפילו לתת למודל קטן לנתב.
• מודל מקומי למשימות בנפח — למשימות חוזרות אפשר להריץ מודל מקומי (Llama/Qwen) באפס עלות פר-בקשה.
• גזום את ההקשר — בסוכנים ובשיחות ארוכות, אל תגרור היסטוריה אינסופית. סיכום או ניקוי של הקשר ישן חוסך טוקנים בכל בקשה.
• פלט קצר — פלט יקר פי כמה מקלט. בקש מהמודל תשובות תמציתיות והגבל max_tokens בהתאם.

צ'קליסט החיסכון