למה ה-CTO של Fireworks AI חושב שהעתיד הוא אלפי מודלים מותאמים, לא מודל-על אחד

לאחרונה האזנתי לראיון עם דמיטרו דז'ולגקוב, מייסד-שותף ו-CTO של Fireworks AI (ולשעבר מוביל צוות PyTorch במטא), על המצב האמיתי של מודלי קוד פתוח היום. כמה מהנקודות שלו שינו לי את הדרך שבה אני חושב על מתי לפנות למודל frontier ומתי לכוון (fine-tune) משהו קטן יותר למשימה ספציפית.

הפער מול חברות ה-frontier נסגר מהר

במשך תקופה, כלל האצבע היה שמודלי קוד פתוח מפגרים אחרי חברות ה-frontier בסביבות שלושה עד שישה חודשים במבחני benchmark. הקריאה של דז'ולגקוב היא שהשחרורים האחרונים - GLM 5.2, Kimi K3, וגם DeepSeek Flash ו-V4 החדשים - מייצגים קפיצת יכולת אמיתית, דומה לזו שמודלי ה-frontier עברו בסביבות נובמבר-דצמבר האחרונים. זו הייתה התזוזה מהעתקת קוד מחלון צ'אט לפיתוח אגנטי אמיתי: סוכנים שמריצים תת-סוכנים, עובדים בלולאות, רודפים אחרי מטרות לאורך זמן בלי פיקוח מתמיד. רמת היכולת הזו הגיעה עכשיו גם למודלי קוד פתוח.

היסטוריה קצרה של איך הגענו לכאן

הרגע הראשון האמיתי של קוד פתוח, לפי דז'ולגקוב, היה DeepSeek R1, ואחריו V3. מה שהפך את R1 למרשים לא היה רק הציונים ב-benchmarks. זו הייתה הפעם הראשונה שהרבה אנשים, כולל לא-מעט משתמשים לא-טכניים, יכלו בפועל לצפות במודל חושב צעד אחר צעד. מודלי reasoning סגורים באותה תקופה הסתירו את עקבות החשיבה שלהם לגמרי. לראות את זה נחשף בגלוי היה חדש באמת. Kimi K3 היה, לדעתו, ה"פגיעה" האמיתית השנייה, ו-DeepSeek V4 נחת רק שבועיים אחרי.

התמחות, לא מודל אחד לכל דבר

התזה המרכזית מאחורי Fireworks AI היא שכל הגישה של חברת frontier היא לבנות מודל אחד שהכי טוב בכל דבר. Fireworks מהמרת בכיוון ההפוך: fine-tuning ו-reinforcement learning לפי שימוש ספציפי, כך שבמקום מודל אחד או שניים ששולטים בהכל, מגיעים לאלפי, אולי מיליוני, מודלים מותאמים - כל אחד מכוון לנישה צרה. יש גם היבט שליטה שקל לפספס: הרצת מודל בקוד פתוח אומרת שאתם לא חשופים לספק שמשנה בשקט התנהגות, רושם את הנתונים שלכם, או מוסיף סירובים שלא ביקשתם. אפשר לארח בעצמכם, או להריץ איפה שהגיוני לכם.

מה בפועל גורם למישהו לעשות fine-tune

התשובה של דז'ולגקוב הייתה קונקרטית ומרעננת: בדרך כלל איכות קודם, עלות שנייה - אבל הסדר מתהפך בהתאם ללקוח. הדרך הנפוצה נראית כך: סטארטאפ מתחיל בעטיפת מודל frontier, מקבל שימוש ונתונים אמיתיים, סוחט מה שאפשר מ-prompting והנדסת harness, ומגיע לבערך 80-90 אחוז מהחוויה שהוא באמת רוצה. fine-tuning הוא מה שסוגר את הפער האחרון ל-95 או 99 אחוז, כי בשלב הזה כבר לא מבצעים אופטימיזציה רק לפרומפט. מבצעים אופטימיזציה לכל המחסנית: ה-harness, הנתונים, דפוסי השימוש בפועל - הכל אפוי ישירות לתוך משקלי המודל.

הצוואר בקבוק האמיתי הוא לא האימון. זה ה-evals

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

איכות מנצחת כמות, בהפרש גדול

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

Pretraining מאפס הוא מועדון מתכווץ

יש פיתוי לחשוב שברגע שלחברה יש מספיק נתונים קנייניים, הצעד הבא הטבעי הוא לאמן מודל משלה מאפס. לפי דז'ולגקוב, הנתיב הזה בעצם נהיה נדיר יותר, לא נפוץ יותר. ב-2023, הרבה חברות ניסו pretraining מלא לתחום ספציפי (הדוגמה המוכרת ביותר מאותה תקופה היא המודל הפיננסי של Bloomberg, מאומן בכבדות על הנתונים שלה) ורוב המאמצים האלה הובסו במהירות על ידי מודלי frontier גנריים שעברו fine-tuning אחר כך. Pretraining נהנה כל כך הרבה מקנה מידה אגרסיבי שרק מספר קטן של שחקנים יכולים להישאר תחרותיים בזה. ההסדר היציב יותר: קומץ מעבדות מבצעות pretraining, וכולם האחרים מתמחים מעליו דרך post-training.

הפיתוח עצמו עובר לענן

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

להפוך ל-tech lead של מאה סוכנים

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

איפה זה משאיר אותי

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