הניוזלטר השבועי / מודלים זולים יותר, התחייבויות גדולות יותר: מי מנהל את כלכלת ה־ AI ?
AI Weekly / גיליון עומק

מודלים זולים יותר, התחייבויות גדולות יותר: מי מנהל את כלכלת ה־AI?

ההפצה של OpenAI דרך Google Cloud, נתוני ההוצאה של Ramp, הדוחות של Meta ושתי הכרזות תשתית מצביעים על שינוי שהנהלות צריכות להבין: מי מחזיק בשליטה על העלות, ההקשר והביצוע.

23.10.2026חמש סקירות · חדשות ועמדה ניהולית

מאת

01

OpenAI ב־Google Cloud

מודלי OpenAI מגיעים ל־Model Garden. הבחירה במודל והבחירה בערוץ הרכש מתחילות להיפרד.

02

שימוש, מחיר והוצאה

נתוני Ramp מחייבים להבחין בין נפח שימוש, תמהיל מודלים והוצאה כספית, וגם בין תקופות המדידה.

03

Meta והקצאת ההון

הדוחות מציגים צמיחה לצד תזרים חופשי שלילי. חשוב לבדוק גם השקעות, חיובים משפטיים והתחייבויות עתידיות.

04–05

תשתיות והפעלה

TorchTPU ו־llm-d מחברים את התחרות בחומרה לשאלות של מעבר, עומס והשלמת תהליכים.

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

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

הפצה ורכש · 21.10.2026

OpenAI ב־Google Cloud: את המודל אפשר להחליף, אבל למי שייך הקשר עם הלקוח?

העדכון החדשותי · פרטים וגבולות

ב־21 באוקטובר Google Cloud הכריזה על גישה ל־GPT-6 Astra, GPT-6.1 Sol ו־GPT-6 Luna דרך Model Garden, בשלב זה ב־private preview ללקוחות ארגוניים נבחרים. השימוש מחויב דרך Marketplace, נכלל בחשבונית הענן ויכול להיספר כנגד התחייבויות ענן קיימות. בהכרזה, אפשרויות Zero Data Retention ו־Confidential Compute מתוארות כיכולות שיגיעו בהמשך, ולכן אין להציג אותן כזמינות כבר כעת.

הקריאה שלי

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

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

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

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

מה הייתי מבקש לבדוק בארגון

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

כלכלת שימוש · סיקור 22.10; נתוני רקע קודמים

כשצריכת הטוקנים עולה והחשבון לא: מה באמת אפשר ללמוד על הביקוש?

העדכון החדשותי · פרטים וגבולות

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

בלוח Ramp שנבדק לגיליון, השבוע שהסתיים ב־11 באוקטובר מציג עלייה של 23.0% בהוצאה ושל 52.4% בנפח לעומת השבוע שהסתיים ב־13 בספטמבר; המחיר המשולב ל־OpenAI ול־Anthropic ירד מ־0.86 ל־0.64 דולר למיליון טוקנים. זהו מדגם של לקוחות Ramp, וההשוואה השבועית אינה אותה השוואה כמו בסקירה החודשית.

הקריאה שלי

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

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

לשם המחשה בלבד, נניח שעלות המודל להפקת מסמך יורדת משתי אגורות לאגורה, אבל כל מסמך עדיין דורש בדיקה אנושית שעולה עשרים אגורות. העלות הכוללת תרד מ־22 ל־21 אגורות, כלומר בכ־4.5%, אף שעלות המודל נחתכה בחצי. אם המודל הזול יגדיל אפילו מעט את עבודת התיקון, גם החיסכון הזה עלול להיעלם. זו הסיבה שאני לא חושב שנכון לבנות תוכנית התייעלות סביב מחיר הטוקן לבדו.

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

מה הייתי מבקש לבדוק בארגון

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

דוחות והקצאת הון · 21–22.10.2026

Meta צומחת, אבל המזומן כבר מספר סיפור אחר

העדכון החדשותי · פרטים וגבולות

בדוחות שפרסמה Meta ב־21 באוקטובר, ההכנסות הרבעוניות הגיעו ל־64.60 מיליארד דולר, עלייה של 26%. התזרים מפעילות שוטפת היה 32.79 מיליארד דולר, אך התזרים החופשי היה שלילי, 2.12 מיליארד דולר. תחזית ההשקעות ההוניות לשנה צומצמה ל־135–145 מיליארד דולר. אלה השקעות הוניות, לא כלל ההוצאות. בדוחות נכלל גם חיוב משפטי של 9.9 מיליארד דולר, ולכן אי אפשר לייחס את כל הלחץ על התוצאות ל־AI.

בדוח ה־10-Q מופיעות גם התחייבויות חוזיות שאינן ניתנות לביטול בהיקף 454.52 מיליארד דולר, בעיקר לענן ותשתיות טכניות, עם פריסת תשלומים עתידית. זה אינו סכום השקעה של רבעון אחד. Reuters דיווחה ב־22 באוקטובר על ירידה של כ־3% במסחר המוקדם, לצד עלייה ביעדי מחיר מצד אנליסטים.

הקריאה שלי

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

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

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

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

מה הייתי מבקש לבדוק בארגון

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

תשתיות ותחרות · 20.10.2026

TorchTPU: התחרות על החומרה עוברת דרך היכולת לעבור אליה

העדכון החדשותי · פרטים וגבולות

ב־20 באוקטובר Google הודיעה על פתיחת TorchTPU בקוד פתוח, בפיתוח משותף עם צוות PyTorch של Meta. המטרה היא הרצת עומסי PyTorch על TPU דרך ממשקים מוכרים, עם תמיכה ב־torch.compile ושילובים עם vLLM ו־SGLang. במאגר הפרויקט מופיעים גם כלי בדיקה ודוגמאות לאימון ולהסקה. ההכרזה אינה מספקת הוכחה ליתרון עלות גורף לכל עומס עבודה.

הקריאה שלי

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

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

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

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

מה הייתי מבקש לבדוק בארגון

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

תפעול סוכנים · 20.10.2026

llm-d 1.0: כשכמה סוכנים חולקים תשתית, ההבטחה העסקית פוגשת תור

העדכון החדשותי · פרטים וגבולות

ב־20 באוקטובר הוכרזה llm-d 1.0, תשתית קוד פתוח להפעלת מודלים בסביבת Kubernetes. ההכרזה מתארת ניתוב שמביא בחשבון הקשר שכבר נמצא במטמון, בקרת תעבורה בין משתמשים וזמינות גבוהה. Google הציגה הדגמה של 1,000 סוכנים מול נקודת שירות משותפת. זו הדגמת ספק, לא מבחן עצמאי לתהליך ארגוני. מסמכי הפרויקט עוסקים גם בתיאום עדכוני שרתים ובהפרדה בין שלבי עיבוד.

הקריאה שלי

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

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

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

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

מה הייתי מבקש לבדוק בארגון

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

מבט ניהולי

מה הייתי לוקח מכאן לדיון הנהלה

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

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

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

מקורות, תאריכים והקשר

הגיליון מתייחס להתפתחויות מ־20–23 באוקטובר 2026, עם נתוני רקע מוקדמים המסומנים במפורש. מקורות ונתוני לוחות חיים נבדקו ב־23.10.2026. הודעות ספקים מוצגות ככאלה; הפרשנות והדוגמאות העסקיות מופיעות בנפרד מהעדכון העובדתי.

  1. Google Cloud expands model choice and flexibility, bringing OpenAI models to customers · 2026-10-21
  2. Axios — The AI boom has a new complication: falling prices · 2026-10-22
  3. Ramp — October 2026 AI Index: Cracks in the AI Thesis, Part 3 · 2026-10-14
  4. Ramp AI Index — token spending, volume and methodology · 2026-10-23
  5. Meta — Third Quarter 2026 Results · 2026-10-21
  6. Meta — Form 10-Q, quarter ended September 30, 2026 · 2026-10-21
  7. Reuters — Meta falls as investors balance Muse growth with rising AI costs · 2026-10-22
  8. Google Cloud — TorchTPU is now open source: Run native PyTorch on TPUs · 2026-10-20
  9. TorchTPU — project repository and examples · 2026-10-23
  10. Google Cloud — llm-d 1.0: Open distributed inference for agents · 2026-10-20
  11. llm-d — DisaggregatedSet architecture and rollout documentation · 2026-10-23