איך לחסוך בעלויות AI API

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

שלב 1 - Prompt Caching

כשאותו system prompt, מסמך רקע או הוראות ארוכות נשלחים שוב בכל קריאה, מסמנים אותם ל-caching. הקריאה הראשונה עולה מעט יותר (כ-1.25 פעמים המחיר הרגיל, כי כותבים למטמון), אבל כל קריאה חוזרת שמשתמשת באותו prefix עולה קרוב לעשירית מהמחיר המקורי על אותו חלק. באפליקציה ששולחת מסמך של 5,000 מילה כרקע קבוע ל-100 קריאות ביום, ההבדל בין caching לבלי זה עשרות דולרים בחודש על משימה יחידה.

שלב 2 - Batch API למשימות לא-דחופות

כל שלושת הספקים הגדולים - OpenAI, Anthropic ו-Google - מציעים נתיב batch: שולחים קובץ עם עד אלפי בקשות, מקבלים תשובה תוך שעות (SLA רשמי של עד 24 שעות), ומשלמים 50% פחות מהמחיר הרגיל. זה לא מתאים לצ'אט חי, אבל מתאים בול לעיבוד לילי - סיווג פניות מהיום, יצירת תקצירים לכל הכתבות שפורסמו, ניתוח קבוצתי של נתונים.

שלב 3 - לקצר את מה שנשלח, לא רק את מה שמבקשים

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

במקום לשלוח 40 תורות שיחה מלאים:
1. שולחים סיכום של 3-4 משפטים על מה שנקבע בתחילת השיחה.
2. שולחים את 5-6 התורות האחרונים במלואם.
3. שולחים את השאלה הנוכחית.

שלב 4 - להגביל את הפלט

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

כמה כל טכניקה חוסכת בפועל

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

איפה זה נשבר

Caching לא עוזר כשהתוכן משתנה בכל קריאה - למשל חותמת זמן או מזהה ייחודי שמוזרקים לתוך ה-system prompt במקום להישלח בנפרד. Batch API לא רלוונטי לשום דבר שדורש תשובה בתוך שניות. וקיצור קלט אגרסיבי מדי עלול לחתוך בדיוק את המידע שהמודל צריך - הבדיקה הכי בטוחה היא להשוות תשובות עם ובלי הקיצור על כמה דוגמאות לפני שמפעילים את זה בפרודקשן.

מה לא לצפות ממנו

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

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