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

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

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

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

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

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

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

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

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

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

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

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

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

אחת התפניות המשמעותיות היא מעבר למודלים פתוחים. חשוב להבחין, זה לא קוד פתוח - אתה לא מקבל את קוד האימון או נתוני המקור. זה משקלות פתוחים (או 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 - ינוהל על ידו.

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