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

מבוא: שטיפת המוח של עמק הסיליקון

עמק הסיליקון מוכר לציבור משוואה נוחה: יותר שבבים, יותר חשמל, יותר פרמטרים ובסוף תגיע בינת־על. בשיח על בינה מלאכותית יוצרת, בינה מלאכותית כללית (AGI) ובינת־על מלאכותית (Artificial Superintelligence, ASI), גודל התשתית מוצג לעיתים כאילו הוא מדד לאיכות החשיבה. הבעיה אינה בהשקעה במחשוב. הבעיה מתחילה כשגודל ההשקעה הופך בעצמו להוכחה שהכיוון נכון.

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

נקודת המוצא שלי היא רשת של מודלים (Network of Models) ובה 200–300 מומחים, שכל אחד מהם מכיל כ־100 מיליארד פרמטרים ומאומן לעומק בתחום מוגדר. מעליהם פועלת ליבת הסקה של 100B–200B, שאחראית לפירוק בעיות, לחיבור תחומים ולבחירת הבדיקות שיכריעו ביניהם. זאת אינה הגדלת צ׳אטבוט; זאת ארכיטקטורת רשת שמבקשת להפוך התמחות נפרדת לאינטליגנציית נחיל (Swarm Intelligence).

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

הפיקציה של ה-MoE המיקרוסקופי: מה המעבדות באמת עושות?

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

ב־MoE המומחים הם רכיבים בתוך תהליך חישוב משותף. כאשר הם פרוסים בין מאיצים, העברת הטוקנים ביניהם יוצרת דרישות תקשורת התלויות בפריסה. בנחיל שאני מציע, שאפשר לתאר כתערובת מומחים ברמת המערכת (System-Level MoE), היחידה שמקבלת משימה היא מודל שלם: הוא מחזיק הקשר מקומי, מפעיל כלים ומחזיר תוצר שאפשר לבדוק.

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

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

אימון מקבילי וטיהור נתונים: קיצור זמן ללא פיקציה חישובית

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

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

כדי לדבר ברצינות על שבועות, צריך חשבון. חוקי קנה המידה של צ׳ינצ׳ילה (Chinchilla Scaling Laws) מספקים מסגרת לדיון ביחס בין גודל המודל, היקף הנתונים ותקציב האימון. לצורך אומדן החישוב באימון Transformer צפוף משתמשים בקירוב C ≈ 6ND: מספר הפרמטרים כפול טוקני האימון, כפול שש. נניח 250 מומחי 100B, שכל אחד מהם עובר אימון המשך על 100 מיליארד טוקנים. מתקבלות כ־1.5×10²⁵ פעולות חישוב.

אם מוקצים לתהליך 25,000 מאיצים, שכל אחד מספק בממוצע 0.4 פטהפלופ לשנייה של תפוקה מועילה, שלב ההתמחות דורש כ־17.4 ימים. ב־300 מיליארד טוקנים למומחה מדובר בכ־52.1 ימים. אלה הנחות תכנון, לא ביצועים שנמדדו במערכת הזאת; אימון הבסיס, הכנת הנתונים ואימון שיתוף הפעולה מתווספים לחשבון.

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

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

"דילמת המתזמר": המבנה הפנימי של ליבת ההסקה

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

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

המנהל יבחר מומחים לפי ביצועיהם במשימות דומות ולפי התרומה הצפויה של הבדיקה הבאה. הביטחון שהמודל מצהיר עליו אינו תחליף לכיול מול תוצאות. אימון תזמור נלמד כבר נבחן ב־ToolOrchestra של אנבידיה (NVIDIA); כאן אני מציע להרחיב אותו לניהול חקירה רב־תחומית ממושכת.

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

המענה שלי הוא לא לסגור כל מומחה בחדר, אלא להוסיף לאימון המקומי אימון חוצה־תחומים ודיאלוג רב־סוכנים (Multi-Agent Debate). צוותים קטנים יפתרו בעיות שבהן התשובה של מומחה אחד משנה את עבודת האחר. המנהל ילמד גם לשנות את פירוק הבעיה, והמומחים יורשו לערער על ההנחות שקיבלו.

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

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

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

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

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

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

סימפוניה של מוחות מומחים: לא מוח אחד שיודע הכול אלא מערכת שיודעת לחשוב יחד

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

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

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

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

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

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

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

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

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

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

שאלת זמני התגובה (Latency): ההקרבה המודעת של System 2

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

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

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

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

הפרוטוקול החסר: המפרט הטכני של תקשורת בין-סוכנים

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

כבר קיים Agent-to-Agent (A2A), פרוטוקול לתקשורת, לגילוי יכולות ולניהול משימות בין סוכנים. לכן אין צורך להמציא מחדש את מעטפת ההעברה. שכבת התקשורת הסמנטית שאני מציע מעליה, Semantic Agent Protocol (SAP), תגדיר את משמעות התוצרים: לא רק מה נשלח, אלא באילו תנאים מותר להסתמך עליו.

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

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

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

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

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

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

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

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

חשבון החומרה המדויק: השוואה בין מונולית לנחיל

אחרי הגדרת מנגנון העבודה אפשר לגשת לחשבון החומרה. 250 מומחי 100B מכילים יחד 25 טריליון פרמטרים. בשני בתים לפרמטר, המשקולות לבדן דורשות כ־50 טרה־בייט. אלה משקולות זמינות, לא כולן פעילות בכל בקשה, וגם לא 25 טריליון פרמטרים של ידע בלתי חופף.

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

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

מאיפה נובע החיסכון באנרגיה וב-CapEx?

היעד של עשירית נשאר במרכז התזה, אבל 400 מיליארד מתוך חמישה טריליון אינם הוכחה לחיסכון של 92% בחשמל. יעילות חישובית (Compute Efficiency) נמדדת לאורך כל מסלול העבודה, בהשוואה לחלופות יעילות, כולל MoE. מספר הפרמטרים הזמינים אינו תחליף למדידת החישוב שבוצע.

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

ניקח תרחיש תקציבי, לא תוצאה ניסויית, שבו למשימות הייחוס עלות שווה: 80% מהמשימות מבוצעות בעשירית מעלות ההפעלה המקבילה, ו־20% דורשות חקירה בעלות של 60%. אם התקורה המשותפת מוסיפה עוד 5% מעלות הייחוס, העלות הממוצעת היא 25% מהמקור, כלומר חיסכון של 75%.

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

זעזוע בוול סטריט: התפכחות ה-CapEx וגבולות הדמוקרטיזציה

לחץ גובר על שאלת ה-ROI

החשבון ההנדסי הזה מוביל לשאלה הכלכלית הרחבה יותר. הוצאות ההון של חברות הטכנולוגיה הגדולות עברו 400 מיליארד דולר ב־2025; באפריל 2026 העריך IEA עלייה נוספת של 75% באותה שנה. זהו היקף הוצאות רחב, לא כולו אימון מודלים, והנתון ל־2026 הוא תחזית.

זאת שאלת החזר ההשקעה בבינה מלאכותית (AI ROI). הסיכון לבועת השקעות הון (CapEx Bubble) מתחיל בהתיישנות כלכלית בלי התיישנות פיזית: חוות שרתים יכולה להמשיך לעבוד מצוין, ובכל זאת להיות יקרה מדי מול מערכת שמייצרת תוצאה שקולה ברבע מהמשאבים או בעשיריתם.

קירור הפרמיה של "מוכרי האתים"

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

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

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

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

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

בטיחות מרובת-סוכנים: תורת המשחקים במקום נאיביות הנדסית

לצד שאלת העלות עולה גם שאלת השליטה. אותו עיקרון של הפרדת רכיבים מגיע גם לבטיחות בינה מלאכותית ולהתאמת מטרותיה לאדם (AI Safety & Alignment). הפרדת המודלים מאפשרת להפריד גם סמכויות. מומחה יכול לנתח בלי לבצע; המנהל יכול לתכנן בלי לשנות הרשאות; ורכיב ביקורת יכול לבדוק תוצר בלי להשתתף בייצורו. גבולות כאלה מופיעים גם במסגרת המחקרית Intelligent AI Delegation.

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

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

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

מתווה תיקוף והטמעה הנדסי (Empirical Roadmap)

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

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

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

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

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

סיכום: המעבר מרשת משקולות לרשת מוחות

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

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

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

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

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

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

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

לא להאט את האינטליגנציה. לבנות אותה נכון.