הצלחתי להריץ מודל שפה בעל 284 מיליארד פרמטרים על מחשב נייד עם 3.2 GB בלבד של RAM, תוך שימוש ב-C99 נקי ובכונן NVMe בלבד. הטריק היה להזרים (stream) את משקלי המומחים (expert weights) של המודל במקום לטעון את כל ה-checkpoint במשקל 160 GB לזיכרון, מה שמוכיח שניתן לדחוס אפילו את מודלי ה-mixture-of-experts (MoE) הגדולים ביותר לחומרה צרכנית.

למה זה חשוב

מודלי שפה גדולים (LLMs) מניעים יצירת קוד, סיוע במחקר ועוד, אך הגודל שלהם מחייב בדרך כלל משתמשים לעבור לשרתים יקרים עם מרובי GPU או להשתמש בקוונטיזציה (quantisation) כבדה שפוגעת באיכות. ההוכחה שמודל MoE עם 284B פרמטרים יכול לרוץ עם כמה גיגה-בייט של RAM פותחת דלת עבור חובבים, סטארט-אפים קטנים וחוקרים עם תקציב מוגבל להתנסות במודלים מתקדמים (state-of-the-art) מבלי להקריב את רמת הדיוק.

המודל וצוואר הבקבוק של החומרה

DeepSeek-V4-Flash מאחסן 284B פרמטרים על פני 256 מומחים (experts) לכל שכבת transformer. ה-checkpoint הגולמי תופס כ-160 GB בדיסק — גודל המעמיס משמעותית על ה-3.2 GB של ה-RAM במחשב נייד טיפוסי. צינורות עיבוד (inference pipelines) מסורתיים מנסים למפות את כל ה-checkpoint לזיכרון, מה שמהר מאוד מרוקן את תקציב ה-RAM וגורם לקריסה.

הזרמת משקלי מומחים: הרעיון המרכזי

ארכיטקטורות MoE מפעילות רק תת-קבוצה קטנה מאוד של מומחים עבור כל טוקן (token). ב-DeepSeek-V4-Flash, הנתב (router) בוחר שישה מומחים מתוך 256 בכל שכבה. מכיוון שהחישוב לעולם לא נוגע במומחים הרדומים, מנוע ה-inference יכול לדלג על טעינתם.

המימוש מתייחס ל-checkpoint כמקור הזרמה (streaming source). כאשר הנתב מחליט אילו מומחים נחוצים עבור הטוקן הנוכחי, המנוע מושך את בלוקי המשקלים הללו מכונן ה-NVMe אל מטמון (cache) מסוג LRU (least-recently-used) שיושב ב-RAM. אם המטמון גדול מספיק, אותם מומחים מנוצלים מחדש עבור טוקנים עוקבים, מה שיוצר cache hits; אם המטמון קטן מדי, המנוע קורא מהדיסק בתדירות גבוהה יותר. התוצאה היא טביעת רגל של זיכרון (memory footprint) בשיא של 3.23 GB, בתוך גבולות המחשב הנייד, תוך שמירה על משקלים בדיוק מלא (full-precision) וללא צורך בהאצת GPU.

לקחים שהושגו בקושי מהמימוש

1. פלט רהוט אינו הוכחה לנכונות קרנל (kernel) עם באג יכול עדיין להפיק משפטים שנראים הגיוניים, במיוחד כאשר דפוסי השפה של המודל מסווים שגיאות מספריות. אימתתי כל אחת מ-14 הפעולות הקריטיות מול ייחוס (reference) טרי של PyTorch, וודאתי שההפרש המספרי נשאר בתוך טולרנס (tolerance) זעיר. דילוג על שלב זה היה מאפשר לשגיאות סטייה עדינות לחמוק.

2. מצבי כשל משותפים יכולים להטעות את הבדיקות שלך באג של שחיתות זיכרון (memory-corruption) צמצם את בחירות הניתוב למספר קטן של מומחים, מה שהניף את שיעור ה-cache-hit מ-52% ל-95% ויצר אשליה של האצה עצומה. מכיוון שחבילת הבדיקות השוואה בין שתי גרסאות של אותו קוד עם באג, היא פספסה את הבעיה. התרופה היא להוסיף נתיב ייחוס עצמאי — קוד שאינו משתף לוגיקה עם המימוש העיקרי — כך שפגם משותף לא יוכל לחמוק מבלי שיבחינו בו.

3. מדדו לפני שאתם מבצעים אופטימיזציה הנחתי שהעתקת זיכרון לוקחת 1ms והשקעתי זמן באופטימיזציה שלה. פרופיילינג (Profiling) הראה שהפעולה למעשה עלתה 3.6ms, או 22% מזמן ה-inference הכולל. הלקח: לעולם אל תסתמכו על אינטואיציה עבור חלקים קריטיים לביצועים; מדידה מדויקת היא המדריך האמין היחיד.

4. תנאים תרמיים משפיעים דרמטית על תפוקה (throughput) הרצת הבנצ'מרקים על מחשב נייד "חם" (heat-soaked) הניבה זמני ריצה איטיים עד פי שלושה מאשר במכונה קרה. טמפרטורות גבוהות הגבילו את התפוקה של כונן ה-NVMe והאטו את ה-CPU, מה שעוות את התוצאות. תעדו את המצב התרמי של המערכת בכל פעם שאתם מפרסמים נתוני ביצועים.

איך נראים המספרים

  • גודל המודל בדיסק: ~160 GB
  • שימוש שיא ב-RAM: 3.23 GB
  • מומחים לכל טוקן: 6 (מתוך 256)
  • שיעור cache-hit: משתנה בהתאם ל-RAM; עם 3.2 GB הוא נע בין ערכים שונים.
  • ללא קוונטיזציה: משקלים בדיוק מלא מועברים בסטרימינג, מה ששומר על איכות המודל.

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

קוד המקור זמין לציבור בכתובת github.com/ronak-create/deepseek-v4-in-c. ערוץ דיון קהילתי קיים בכתובת t.me/GyaanSetuAi לכל מי שמחפש לשחזר או להרחיב את הניסוי.

שורה תחתונה

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