5 דרכים להוזיל את עלויות השימוש ב-Claude Code באמצעות LiteLLM
אחת היכולות השימושיות ביותר ב- LiteLLM היא סיוע בחסכון כספי בשימוש בכלי AI ומודלים – ביניהם כמובן Claude !
במאמר כאן נסביר כיצד להשיג זאת.
כלי AI כמו Claude Code הוא אחד הצרכנים הכבדים ביותר של input tokens בארגוני פיתוח והנדסת תוכנה מודרניים.
לולאות ארוכות של כלים (loops), קריאות קבצים גדולים וקטלוגים של MCP המכילים מאות כלים,
דוחפים כל בקשה לקצה העליון של ה-context window, וכתוצאה מכך החשבון מטפס בהתאם.
אם ה-Claude Code שלכם כבר מנותב ל-proxy של LiteLLM
(דרך המשתנה ANTHROPIC_BASE_URL),
למנהלי המערכת יש חמישה אמצעים שונים להפחתת העלויות.
אף אחד מהם אינו דורש שינויים מורכבים בצד של משתמשי הקצה!
1. מסגרות תקציב ומנגנוני Fallback
קיימות שתי אפשרויות שליטה מרכזיות ברמת ה-virtual key:
- מסגרות תקציב (Budget windows): מגבילות את סכום ההוצאה האפשרי של המפתח בפרק זמן מתגלגל. ניתן להגדיר
max_budget(בדולרים)
ו-budget_duration(למשל "24h", "7d", "30d" וכו').
המערכת של LiteLLM מאפסת את המונה אוטומטית בסיום כל חלון זמן.
ניתן גם לשלב (stack) מספר מסגרות חופפות, לדוגמה 10$ ביום יחד עם 100$ בחודש,
כך שאחר הצהריים אחד של שימוש חריג לא יחסל את התקציב החודשי כולו. - מנגנוני גיבוי תקציביים (Budget fallbacks): קובעים מה יקרה כאשר התקציב שהוקצה למודל מסוים מוצה.
במקום להציג שגיאה בטרמינל של המפתח, ניתן להגדירmodel_max_budgetלכל מודל, יחד עם שרשרתbudget_fallbacksהמציינת לאילו מודלים זולים יותר לנתב את הבקשה.
הבקשה מועברת בשקיפות (silently) למודל ה-fallback הראשון שעדיין נותר לו תקציב. לדוגמה, ברגע שהמפתח מנצל 20$ של מודל Opus ביום, הבקשות הבאות ל-Opus ינותבו אוטומטית ובשקיפות למודל Sonnet; אם גם התקציב של Sonnet נוצל, מודל Haiku ייכנס לפעולה.
מודלי fallback ללא הגדרתmodel_max_budgetייחשבו כבעלי תקציב ללא הגבלה.
מה זה Virtual key ? זהו מפתח API וירטואלי שמסתיר את מפתח ה- API האמיתי (הראשי), ונועד בין השאר לשפר את אבטחת המידע. ב- LiteLLM ניתן להגדיר מפתחות כאלה, וכפי שכתוב לעיל – אפשר גם לתת הגדרות תקציב פרטיות לכל מפתח וירטואלי.
2. מערכת Prompt Caching אוטומטית
מנגנון ה-prompt cache של Claude מחייב עלות של כ-10% בלבד ממחירו של input token חדש במקרה של cache hit, אך זה קורה רק אם הבקשה מסמנת את ההודעה הנכונה עם cache_control.
הפתרון של LiteLLM מזריק את הסמן הזה עבורכם: הגדירו את cache_control_injection_points כך שיצביע על ה-system message (או על הפנייה הלפני-אחרונה של המשתמש), וכל קריאה של Claude Code דרך ה-proxy תכלול את ה-checkpoint ללא צורך בשום עריכה מצד הלקוח.
הפעלת prompt_caching כ-pre call check פירושה שאם אתם מריצים מספר deployments של אותו מודל Claude, המערכת של LiteLLM תנתב בצורה חכמה את הבקשה ל-deployment הספציפי ששימש במקור עבורה.
3. דחיסת פרומפטים (Prompt Compression עם Headroom)
בעוד ש-Prompt cache חותך את הקידומת הסטטית (static prefix), הפתרון של Headroom מקצץ את האמצע הדינמי.
פלטים של כלים (outputs), קריאות קבצים, dumps ממסדי נתונים ו-payloads של RAG משוכתבים לצורה דחוסה לפני שהם מגיעים למודל.
במקרה שהמודל באמת זקוק למידע המקורי בשלמותו, קריאה ל-tool מסוג retrieve_headroom שולפת אותו לפי דרישה. החיסכון המדווח מגיע ל-60%-95% מהחלק הניתן לדחיסה בתעבורת ה-Claude Code.
מנגנון ה-Headroom פועל כ-sidecar container לצד LiteLLM.
יש לרשום אותו כ-guardrail מסוג pre_call ולהגדיר default_on: true או לשייך אותו ל-virtual keys ברמת המפתח הבודד.
המפתח עדיין מבצע export ל-ANTHROPIC_BASE_URL ומריץ את claude; הדבר היחיד שהוא יבחין בו הוא מספר קטן יותר בדוח ההוצאות.
4. דחיית טעינת כלים של MCP (Defer MCP tools)
סשן של Claude Code שמתחבר לחמישה או שישה שרתי MCP יכול להציף בקלות כמה מאות כלים,
וכל אחד מה-tool schemas הללו נשלח בכל קריאה של tools/list.
זוהי תקורה (overhead) טהורה של input-tokens בעומס עבודה שבו המודל משתמש בפועל רק בשניים או שלושה כלים בכל פנייה (turn).
על ידי הפעלת mcp_tool_search_enabled ב-virtual key, המערכת של LiteLLM מחליפה את הקטלוג המלא בשני כלים וירטואליים: mcp_tool_search ו-mcp_tool_call. המודל מבצע חיפוש לפי מילות מפתח, מקבל בחזרה התאמות מדורגות, וקורא לכלי שהוא צריך. עלות ה-tokens של רשימת הכלים צונחת ממאות schemas לשניים בלבד.
הדירוג (Ranking) מבוסס על חפיפת tokens מעל ה-name וה-description, כך שאין תלות במנועי embedding חיצוניים שיש להריץ. שטח הגישה אינו מתרחב; החיפוש מחזיר אך ורק כלים שהמפתח (key) כבר הורשה לקרוא להם.
5. ניתוב אוטומטי (Auto Routing)
העיקרון כאן הוא לשלוח כל בקשה למודל הקטן והיעיל ביותר שיכול לטפל בה, כך שבקשות "זולות" פשוטות לעולם לא ייגעו במודל היקר והכבד.
מערכת LiteLLM מספקת שלושה סוגי ניתוב עיקריים:
- Semantic (התאמת embedding).
- Complexity (מבוסס-כללים, ללא קריאות חיצוניות).
- Adaptive (לומד מהתעבורה בזמן אמת, זמין כעת בבטא).
ה-Complexity router הוא המהיר ביותר להגדרה. כוונו את Claude Code אל smart-router והוא יסווג כל בקשה לשכבה (tier) מתאימה.
סיכום: שילוב האמצעים לייעול מקסימלי (Stacking the levers)
חמשת הפיצ'רים הללו משתלבים ומשלימים זה את זה:
- מנגנוני Fallbacks מבוססי-תקציב תוחמים את ההוצאה הכוללת, ללא קשר לשאר הפעולות שתעשו.
- שימוש ב-Prompt cache checkpoints ובדחיסת Headroom מקצצים כל אחד חלק שונה מה-payload של הבקשה לפני שהיא מגיעה למודל.
- חיפוש כלי MCP חותך את תקורת ה-tool schema בתחילתו של כל תהליך.
- הניתוב האוטומטי דואג שכל בקשה תישלח למודל הקטן ביותר שמסוגל להתמודד איתה בהצלחה.
הפעילו את כולם יחד, ואותו עומס עבודה ב-Claude Code ירוץ על שבריר מה-input tokens שנדרשו בעבר – וכל זאת מבלי לגעת באף מחשב קצה של צוותי הפיתוח בארגון.
חברת ALM Toolbox מתמחה בהטמעת כלי AI ומודלים, וכן בכלים לאופטימיזצית שימוש בהם – כגון LiteLLM, LangFuse ונוספים.
החברה היא גם הנציגה הרשמית של LiteLLM בישראל ובמדינות נוספות.
לפרטים נוספים פנו אלינו: litellm@almtoolbox.com או טלפונית: 072-240-5222
