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

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

בפרק הזה (שהוא המשך של פרק קלוד קוד למתקדמים), אנסה לנתח את כלכלת הטוקנים החדשה, איפה הכסף נשרף ואיך אפשר לשלוט בו. כי בעולם שבו "הסקה" (Inference) הוא המשאב המרכזי - מי שלא מנהל אותו, יישרף.

בפרק הקודם דיברנו על הצורך בצמצום ה-Context Window מבלי לפגוע באיכות התוצאה, אבל ככל שמודל השימוש שלנו מתקדם, צריכת הטוקנים מתפוצצת. צ'אט בסיסי למשל ב-2023 היה סביב 500 טוקנים. שאלת שאלה, קיבלת פיסקה או שתיים. ב-2026, אותה שיחה עולה כבר פי 5 בגלל שימוש ב-RAG, קונטקסט ייחודי וזיכרון. גם סייעני קוד, שב-2023 סרקו קובץ וחצי, מנתחים היום בקלות קודבייס שלם. אבל הבזבזן הגדול, בפער, סוכן קוד, שמבצע לופים, של תכנון, פעולה ואימות בקצב שנושק למיליון טוקנים בשעה. אם מתכנתים היו רואים כמה שרת מתאמץ בשביל להזיז כפתור - הם היו פשוט מזיזים אותו לבד.

הדרך הראשונה לחסוך כסף היא קאשינג, או - לא לחשוב פעמיים על אותו דבר. חלק גדול מה-Promptים חוזרים על עצמם. במודלים מודרנים אפשר לאחסן את הייצוג המתמטי של הטוקנים שכבר עובדו על ידי המודל. כאשר נשלחת בקשה חדשה שמתחילה באותו רצף טוקנים, המודל יכול "להמשיך" מהנקודה שבה הפסיק במקום להתחיל מאפס. אבל החיסכון הזה נוגע רק ל-Input. על Output, שהוא לרוב יקר פי 5, נמשיך לשלם מהטוקן הראשון. עם קאשינג אתה מאבד רנדומיזציה - התשובות הופכות פחות מגוונות, וזה טוב או רע תלוי מה אתה מנסה להשיג. אבל בעיה אינהרנטית יותר היא אובדן הדינמיות. לאחר האינטראקציה השנייה או השלישית, המשתמש מכניס נתונים כל כך ייחודיים, שהופכים את המטמון ללא רלוונטי. קאש עובד טוב כשיש חזרתיות, אבל משתמשים הם הכל חוץ מחזרתיים. אם תצליח לשמר חזרתיות, ההנחה תופעל אוטומטית ותגיע לפעמים ל-90%. אמרנו, זה מוזיל רק את ה-Input ורק במקרים ספציפיים. אתה יותר ממוזמן לפתח את פתרון הקאשינג בעצמך, עם redis או memcache, אבל מישהו צריך לנהל את המטמון הזה.

הדרך השניה היא Batching - סבלנות ככלי כלכלי. אם תעבד (בע') את הבקשות שלך באצוות (בא') תזכה להנחה משמעותית עבור משימות שאינן דורשת תגובה מיידית. OpenAI למשל תחתוך מחיר בחצי אם אתה בסדר שהתוצאה תעובד בחלון של 24 שעות. עבור פרוייקטים של ניתוח תוכנה, או סריקה של לוגים, זו יכולה להיות אסטרטגיית חיסכון לא רעה. אם זה לא צ'אט, אין סיבה לשלם מחיר של צ'אט.

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

הבעיה בראוטינג היא להבין - איזה מודל מספיק טוב, וכמה שווה החיסכון. בנצ'מרקים ציבוריים (מפרק 36) הם כלי שימושי להשוואה כללית, אך הם סובלים מהטיה - בעיקר כי נתוני בדיקה דולפים עם הזמן לשלב האימון של המודלים. הפתרון המקצועי - בניית מערכת evaluations (או eval אם אתם רוצים להישמע מגניב), שתעמת מאות שאילתות אמיתיות של משתמשי קצה, עם תשובות הזהב שנקבעו על ידי מומחים אנושיים. כשעוברים ממודל GPT-4 ל-GPT-5-mini אפשר להריץ את ה-Evals ולהשוות את הציון. אם מודל זול שומר על 95% מהאיכות, בשאלות שהמשתמשים שלך שואלים כל יום, מעבר הוא החלטה עסקית מתבקשת. זיכרו - בנצ'מרקים משקרים - הטסטים שלכם לא.

סוכני קוד היום משתמשים המון בכלים, עושים ls לקבל קבצים, grep כדי לחפש בהם, git status לראות את מצבך, jest או vitest כדי להריץ בדיקה. שימוש כזה, בעשרות, מנפח מאוד את הקונטקסט. דרך רביעית, אולי הקלה ליישום, והגאונית בפשטות שלה - להתקין כלי צמצום קונטקסט, מעין אוזמפיק של טוקנים. rtk למשל, שכתוב ב-rust הוא כלי שאפשר להפעיל לפני כל פקודה. במקום git status מריצים rtk git status והוא מפלטר את התשובה כך שתכלול את הדברים החשובים ביותר. הקלוד קוד שלך מונחה להשתמש ב-rtk לכל פעולה. אם rtk מכיר אותה, הוא יחסוך 80% מהטוקנים. אם לא, הוא יעביר אותה כמו שהיא למערכת ההפעלה. התקנה אחת, עם שיהוי זניח של 10ms לפעולה, לא רק יחסוך המון מה-input בכלים, גם יקטין את הצורך של קלוד ב-compaction, ויאריך את הסשנים.

אפשר גם לחכות. המודלים היקרים הולכים ונעשה פחות יקרים לשימוש עם השיפור בחומרה, אבל הם נעשים יותר יקרים לאימון. מודלים שעלו עשרות מיליונים לאמן נושקים היום למיליארד דולר. השימוש שלך מממן את האימון שלהם.

אחת התפניות המשמעותיות היא מעבר למודלים פתוחים. חשוב להבחין, זה לא קוד פתוח - אתה לא מקבל את קוד האימון או נתוני המקור. זה משקלות פתוחים (או Open Weights) - הפרמטרים הסופיים של המודל, שמאפשרים להריץ אותו באופן עצמאי.

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

כדי להבין את האלטרנטיבה נעשה קצת מתמטיקה. כמה טוקנים צורך מתכנת, או סוכן, או בילדר, ביום עבודה ממוצע. בוא נעריך שמשתמש קל עושה מיליון טוקנים, בינוני 10 מיליון וכבד 100 מיליון, ליום. אם מניחים שהטוקנים מתפזרים ביחס של 4 ל-1 (4 טוקנים בקלט על כל טוקן אחד בפלט) אנחנו מדברים על עלות חודשית במודלי פרמיום של 150 לחודש בקל עד $15,000 לכבד. אז כן אפשר להתווכח אם שווה לי לשלם $15,000 למתכנת הכי יקר שלי אם האסימונים שלו מחליפים 2 בינוניים, או שהוא גורם לפיצ'רים לעלות פי 2 יותר מהר, אבל הדיון לא צריך להיות כמותי אלא איכותני - האם המודלים האלה, סינים ברובם, בכלל מגיעים לרמה של מעבדות השפה האמריקאיות?

אם מאמינים לבנצ'מרקים אז כן. הם מדגדגים אותם במבחני תכנות, ואייג'נטיות ועולים 90% פחות. בפרק הקודם דיברנו על agentic loop ואיך הוא מתקצר כשאתה מסביר לקלוד קוד איך נראית הצלחה. תנשמו שניה. אני יודע שאתם אוהבים את אופוס וסונט וג'מיני פרו וקודקס וגרוק 4 הארד וסופר הארד, גם אני, אבל מה אם נשתמש במודלים האמריקאים ל-planning וליצירת הטסטים, ואת כל העבודה השחורה ניתן לעוף בשקל?

מודל DeepSeek V3, או Kimi K2.5 או MiniMax M2.5 כולם עולים בערך שקל לצריכה. במחיר הזה, גם אם נכפיל את מספר האיטרציות פי 3, אנחנו עדיין מסתכלים על חיסכון של פי 50 בהוצאות.

המודלים האלה זולים בגלל שיטות חסכוניות, כמו MoE (או Mixture of Experts) - דרך להפעיל רק חלק מהפרמטרים, וגם quantization - עיגול בקטנה של כמה נקודות עשרוניות, מקטין במעט את אחוז הדיוק ומכפיל את הביצועים.

אבל מיכאל, בחיית, השתגעת? לשלוח את הקודבייס שלי לסינים? האמת שיש בזה משהו. המודלים האלה זולים כי הסינים מצאו חומרה זולה, חשמל זול, מודל גנוב שנפל ממשאית או כי הם רוצים את הדאטה שלך. אני לא יודע מה הם צריכים עשרות פרוייקטי צד שלא הבשילו לכלום, אני כן רואה איך הם שמים את היד שלהם על Intellectual Property ומידע מסווג.

הצעה - להשתמש בספקים הסיניים שאין לך מה להפסיד, שאתה לא כבול לכלום או כותב קוד שממילא ישתנה.

הצעה 2 - לראות איך מריצים את אותם מודלים מחוץ לסין. ופה יש 4 אפשרויות:

להריץ אותם מקומית, אפילו ללא צורך בחיבור לאינטרנט. פיתרון מושלם לעבודה במטוס או סביבה סופר מאובטחת. מעניין כמה חיילים בצה"ל, שלא יכולים להריץ claude מן הסתם, משתמשים במודלים פתוחים, ואילו.

הבעיה עם עם הרצה מקומית היא שגודל המודל דורש זיכרון עצום. מודל של 70 מיליארד פרמטרים דורש 140GB זיכרון רק כדי להיטען. מודלי הקצה הם מאות מיליארדי פרמטרים. גם אם תקנה את המחשב הכי חזק ב-KSP לא תצליח, פיזית, לפתוח אותם.

זה לא שאין אפשרות לקנות חומרה כזו, זו פשוט דילמה של CapeX מול OpeX.

אם תקנה שרת, למשל של Nvidia הוא יצטרך להכיל 8 כרטיסי H100 או H200 ויעלה בין רבע לחצי מיליון דולר. השרת הזה מרעיש כמו שכנה ביום של הדברה בבניין - צריך לאחסן אותו בחווה, לשלם על עלויות חשמל (שהם פי 10-100 מצריכה של שרתים רגילים) ולדאוג לקירור. תצטרך גם מהנדס CUDA שיודע לבצע אופטימיזציה לחומרה - משרה שמשלמת המון - ולא בא לך לריב עם Nvidia על עובדים.

החומרה הזו מתיישנת במהירות והכדאיות שלה היא ביחס ישר לנצילות. קנית שרת בחצי מיליון דולר והוא טוחן רק 25% מהזמן? מחיר הטוקן שלך יהיה גבוה פי 4. זו הסיבה שרוב החברות מעדיפות את מודל ה-OpeX.

במקום לקנות, אפשר לשכור, מעבדים לפי שעה ולכבות אותם בסופי שבוע. חברות רבות (וגם Amazon) מציעות H200 ב-6 דולר לשעה (אתה כאמור צריך 8 כאלה). המודל הזה מאפשר גמישות - אם יוצא מודל חדש בארכיטקטורה אחרת, פשוט שוכרים חומרה חדשה. אם משהו נשרף, מחליפים את השרת, אבל לא כל החברות נותנות לך לשכור מעבד רק לשעות העבודה, ויש גם עלות וזמן בטעינת המודל בכל פעם.

עבור אלו שרוצים את המודלים הפתוחים, בלי פחד מסין, בלי כאב ראש של ניהול שרתים, בלי לחשוב על gpu או סקייל, אני ממליץ על ספקי תשתית (Providers) שמנגישים לכם API.

אפשר להשתמש ב-Groq (עם q), חברה בת/מתחרה ל-Nvidia שמתכננת שבבי LPU ייעודיים למודלי שפה גדולים, אבל לא גדולים מדי. היא לא מריצה (עדיין) מודלים של מאות מיליארד פרמטרים.

אפשר להשתמש ב-OpenRouter, ה"בורסה" של הטוקנים, מעין שכבת אבסטרקציה מעל עשרות ספקים ומודלים. מערכת שמחצינה ממשק אחיד שבו ניתן להגדיר חלוקת עומסים או מעבר אוטומטי מספק שקרס. אפשר לבקש - תן לי את הסיני הכי זול בתפריט, אבל כזה שיושב בארה"ב, ואם אין אז משהו מסחרי זול. הם דורשים טעינה מראש של ארנק, גובים גם עמלת אשראי וגם דמי שירות (חליצה) קטנים על כל קריאה. יש גם תוספת שיהוי (25-40ms) אבל מקבלים אחלה נראות לשימוש, וחשבונית אחת.

הבעיה, ויש 2. היא לא תומכת ב-Anthropic API. אי אפשר להפעיל דרכה את קלוד קוד כי קלוד מדבר אחרת. לרוב המשתמשים זה big no-no אבל יש פתרון. לעבור ל-ollama cloud עם תוכניות של 20 ו-$100 שיעבדו לנצח, או להתקין claude-code-router, תוסף שיודע לתרגם קלוד ל-OpenAI API.

אני לא מת על 2 הפתרונות האלה כי הם מרגישים לי כמו שערי מכס בדרך ליעד. כחברה, אני רוצה כמה שפחות hopים וכמה שפחות עיניים על הקוד שלי. הפתרון שמצאתי, נכון לעכשיו, הוא לשלם לחברת Fireworks, שמגישה מגוון מודלים פתוחים, מאדמת ארה"ב, עם zero data retention, אפס אימון ומינימום שיהוי, והיא עושה את זה ב-Anthropic API.

חיסכון? נחזור למתמטיקה. יש לך 100 עובדים בינוניים. כלומר הם סופר סטארים, אבל בינוניים בשימוש - נאמר 10 מיליון טוקנים ליום, ביחס של 4 ל-1 בין input ל-output. קלוד אופוס יעלה לכל מתכנת, ביום, $90 לאופוס, 54 לסונט או 4.80 למינימקס. חודשית זה כבר $2,700 באופוס, 1,620 לסונט ו-144 למינימקס. לשנה, ההבדל בין 100 עובדים שטוחנים אופוס לאלו שמדברים מיני מקס יהיה קצת יותר מ-3 מיליון דולר.

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

עד הפעם הבאה, תהיו טובים, ותמשיכו להיות סקרנים. יאללה ביי.