איך לדעת אם מודל בינה מלאכותית רץ על המחשב שלך — ולמה

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

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

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

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

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

הקומה הראשונה: המטבח

תשכחו ממחשב לרגע. דמיינו מטבח.

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

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

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

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

נשארו שלושה פרטים שמשנים די הרבה את התוצאה.

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

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

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

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

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

הקומה השנייה: המפה

אותם האובייקטים, הפעם עם השם שמופיע בתיעוד. זה אותו הציור — רק הוספתי תוויות.

שלוש מהמילים האלה מגיעות להן פסקה משלהן, כי כל הקומה השלישית תלויה בהן.

טוקן

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

A  memória  do  modelo  cabe  na  máquina
│  │        │   │       │     │   │
1  2        3   4       5     6   7      -> 7 tokens

anticonstitucionalmente
│    │      │        │
anti const itucional mente                -> 4 tokens

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

הקשר

זה כמה טוקנים נכנסים בכל השיחה — השאלה, הקבצים שהדבקת, ההיסטוריה והתשובה שנכתבת. כשמודל מכריז "256K של הקשר", הכוונה היא ל-262,144 טוקנים: בערך שמונה מאות עמודים בבת אחת.

מטמון הקשב

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

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

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

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

הפסקה קטנה במספרים העגולים, כי הם מסתירים פרט

אתה תראה, כל הזמן, דברים כמו "8K של הקשר", "מודל של 27B", "24 GB של זיכרון". כל המספרים האלה מעוגלים, והעיגולים האלה לא תמימים: הם מסתירים בין 2% ל-8% הבדל, בדיוק ברגע שהחישוב נמצא בגבול.

יש שלושה בלבולים שונים, וכדאי להפריד בין השלושה.

1. ה-"K" הוא לא אלף. הוא 1,024.

מחשב סופר בחזקות של שתיים, לא של עשר. אז:

שימו לב ש256K זה לא 256 אלף, זה 262,144 — כמעט 2.5% יותר. במודל שכבר מגרד את התקרה של הזיכרון שלך, ה-2.5% האלה הם מה שמכריע אם זה נטען או לא.

2. GB ו-GiB הם דברים שונים, וההבדל הוא 7%

זה הבלבול הכי גדול, ואין לו שום קשר לבינה מלאכותית — זה אותו בלגן כמו כשקונים דיסק קשיח של "1 TB" והמחשב מציג 931 GB.

ההבדל הוא 7.4%. קובץ מודל שמוכרז כ-"16 GB" מופיע כ-14.9 GiB במערכת שלך. שום דבר לא נעלם: אלה שני סרגלים שמודדים את אותו הדבר.

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

3. גם השם של המודל מעוגל

מודל שנקרא "27B" לא כולל בדיוק 27 מיליארד פרמטרים. ל-Qwen3.8-27B יש 27,781,427,952 — כמעט 2.9% יותר ממה שהשם מרמז. זה נשמע מעט, אבל ב-BF16 זה 1.5 GiB של הבדל, יותר ממספיק כדי לגלוש כרטיס שהיה במצב גבולי.

ולפעמים השם נושא שני מספרים, כמו ב-"26B A4B". במקרים כאלה הראשון הוא סך כל הפרמטרים — מה שתופס זיכרון — והשני, מסומן ב-"A" של פעילים (active), הוא כמה המודל באמת משתמש כדי לכתוב כל מילה. זה צוות הטבחים: כל 26 המיליארד חייבים להיות בזיכרון, אבל רק 4 מיליארד עובדים בכל רגע. כדי לדעת אם זה נכנס, תסתכל על המספר הראשון. כדי לדעת אם זה מהיר, תסתכל על השני.

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

הקומה השלישית: החישוב

אני אשתמש כדוגמה ב-Qwen3.8-27B, מודל פתוח שפורסם ב-5 באוגוסט 2026. כל המספרים למטה יצאו מקובץ ההגדרות הרשמי שלו, ובסוף המאמר יש תוכנית שעושה את החישוב מחדש לכל מודל שתרצה.

החישוב הכולל:

memória total = memória dos pesos + memória do cache + sobrecarga de execução

מרכיב 1: המשקלים (המזווה)

הפשוט ביותר:

memória dos pesos = número de parâmetros x bytes por parâmetro

ל-Qwen3.8-27B יש 27,781,427,952 פרמטרים. כל פרמטר עולה פחות או יותר מקום בהתאם לדיוק שבו שומרים אותו:

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

מרכיב 2: המטמון (משטח העבודה)

הנוסחה:

cache = 2 x contexto x camadas_que_crescem x cabeças_de_cache x dimensão_da_cabeça x bytes

מונח אחרי מונח, בלי למהר:

• 2 — כי יש שתי טבלאות קטנות לכל טוקן, זו של המפתח (key) וזו של הערך (value). (בכמה מודלים של 2026 השתיים זהות ושומרים רק אחת; באלה, ה-2 הזה הופך ל-1.)
• הקשר — כמה טוקנים יש בשיחה. זה המונח היחיד שמשתנה תוך כדי השימוש במודל. כל השאר הם מאפיינים קבועים של הארכיטקטורה.
• שכבות_שגדלות — וכאן נמצאת הנקודה שכמעט כולם טועים בה: אלה לא כל השכבות. אני חוזר לזה מיד.
• ראשי_מטמון x מימד_הראש — הרוחב של מה שנשמר לכל טוקן. שימו לב שזה לא הרוחב הכולל של המודל: רק ראשי המפתח והערך נכנסים לחישוב, והם הרבה פחות מרובים מראשי השאילתה (query). ב-Qwen3.8-27B יש 4 ראשים במימד 256, כלומר 1,024 — בעוד שהרוחב הכולל של המודל הוא 5,120. פי חמישה פחות, כי כמה ראשי שאילתה חולקים את אותו זוג טבלאות.
• בייטים — 2 אם המטמון נשמר ב-16 סיביות, 1 אם מקוונטזים את המטמון ל-8 סיביות. כן, גם את המטמון אפשר לייבש בהקפאה, וכמעט אף אחד לא זוכר את זה.

למה "שכבות שגדלות" ולא "שכבות"

מודל הוא ערימה של שכבות. ב-Qwen3.8-27B יש 64. אבל הן לא כולן זהות:

48 מתוך 64 השכבות הן סיר מרק. הן שומרות מצב בגודל קבוע — בערך 3 MiB כל אחת, 0.14 GiB בסך הכול — והמספר הזה לא משתנה גם אם ממלאים את ההקשר עד התקרה. רק 16 שכבות משטח העבודה צוברות טוקן אחרי טוקן.

אז, ב-Qwen3.8-27B, כל טוקן מוסיף 4 KiB בכל אחת מ-16 השכבות שגדלות. והוא מוסיף אפס ב-48 האחרות.

החישוב הסגור

תסתכלו על העמודה האמצעית מלמעלה למטה: היא היחידה שזזה. זה כל הרעיון של המאמר בעמודה אחת של טבלה.

דוגמה מעשית: זה נכנס בכרטיס של 24 GB?

כרטיס RTX 3090 יד שנייה עולה בסביבות US$ 700 ויש לו 24 GB. בואו נראה מה רץ עליו.

קודם כול, תשמרו את התקורה. המערכת, התוכנה שמריצה את המודל והחישובים הביניים צורכים 2 עד 3 GB לפני כל דבר. נשארים ~21 GB לעבודה.

אחר כך, המשקלים. ב-BF16 זה 51.7 GiB: לא נכנס, אפילו לא קרוב. ב-Q4_K_M זה 15.8 GiB: נכנס, ונשארים בערך 5 GiB.

לבסוף, המטמון. עם 5 GiB זמינים והמטמון ב-16 סיביות, זה מספיק לבערך 80 אלף טוקנים של הקשר. אבל אם מקוונטזים את המטמון ל-8 סיביות, כל טוקן עולה חצי — ואותם 5 GiB קונים בערך 160 אלף טוקנים.

הפסיקה: הכרטיס הזה מריץ את כל ה-Qwen3.8-27B, מקוונטז, עם הקשר בסביבות 128 אלף טוקנים. ההקשר המקסימלי של 262 אלף לא נכנס — היה צריך עוד 8 GiB. והגרסה הלא-מקוונטזת לא נכנסת בשום אופן.

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

המספר שמשנה את סדר הגודל של האפשרי

ה-Qwen3.8-27B מכריז על הקשר של עד מיליון טוקנים — בערך עשרה ספרים בבת אחת. אם עושים את החישוב עם המטמון ב-16 סיביות:

שמונים ג'יגה-בייט זה הרבה, אבל זו מכונה שקיימת: Mac Studio עם 128 GB מסתדר, כי במק הזיכרון משותף בין המעבד לכרטיס המסך. לפני שנתיים, הקשר בגודל כזה על מכונה אישית פשוט לא היה אפשרי — ומה שהשתנה לא היה כמות הזיכרון הזמינה בשוק. זה שהארכיטקטורה של המודל התחילה לשמור פחות.

מה השתנה בארכיטקטורה, בשלושה מהלכים

לחלוק את הטבלאות (החל מ-2023). קודם, כל ראש קשב שמר את זוג הטבלאות שלו. עברו לחלוק: ב-Qwen3.8-27B יש 24 ראשי שאילתה מול 4 זוגות שמורים. פי שישה פחות זיכרון, עם אובדן איכות קטן מספיק כדי להפוך לתקן.

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

להחליף את משטח העבודה בסיר (2025 ואילך). שכבות קשב לינארי לא שומרות טוקן אחרי טוקן: הן מחזיקות מצב בגודל קבוע שמסכם את כל מה שעבר. זה המתכון שה-Qwen3.8-27B משתמש בו ב-48 מתוך 64 השכבות שלו.

שלושת המהלכים תוקפים את אותו הדבר — עלות הזיכרון — ובגלל זה האינטואיציה של 2023 ("הקשר ארוך גולש מהזיכרון") כבר לא מתארת את המודלים של היום. ב-Qwen3.8-27B עם 256 אלף טוקנים של הקשר, המטמון (16.1 GiB) הוא באותו הגודל של המשקלים המקוונטזים (15.8 GiB). שני המרכיבים השתוו.

מה הייתי עושה עם זה

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

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

חשבו את המשקלים לפי 0.61 בייט לפרמטר ב-4-bit, לא 0.5. אם החישוב סוגר רק עם הערך התיאורטי, הוא לא סוגר.

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

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

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

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

git clone https://github.com/ulissesflores/llm-memory-meter.git
cd llm-memory-meter
python3 medidor.py --repo Qwen/Qwen3.8-27B

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

הערת אימות. כל מספרי הזיכרון במאמר הזה חישבתי בעצמי ב-14 באוגוסט 2026 מתוך קבצי config.json הרשמיים שפורסמו ב-Hugging Face, עם התוכנית המצוינת למעלה. שתי הסתייגויות כנות: לא הרצתי את המודל בפועל, רק חישבתי את מה שהארכיטקטורה מצהירה — הערכים הם הרצפה התיאורטית הנכונה, וההרצה בפועל תמיד גובה קצת יותר. התקורה של 2 עד 3 GB היא הטווח היחיד בטקסט הזה שלא מדדתי אישית; הוא מגיע מהתנהגות שנצפתה בדיווחי שימוש ומשתנה לפי התוכנה שבה משתמשים. גודל המצב של השכבות הלינאריות (0.14 GiB) הוא סדר גודל שנגזר משדות ההגדרה, לא מדידה בזמן ריצה — הוא קטן מדי בשביל לשנות מסקנה כלשהי כאן. קובצי ה־config.json ששימשו קפואים במאגר, עם סכומי ה־SHA-256 שלהם מתועדים, וכל מספר במאמר הזה הוא בדיקה אוטומטית שרצה באינטגרציה רציפה. החבילה ניתנת לציטוט: 10.5281/zenodo.21941274.

מקורות

• Qwen3.8-27B — כרטיס המודל (model card) וההגדרות הרשמיות
• GQA: Training Generalized Multi-Query Transformer Models
• Fast Transformer Decoding: One Write-Head is All You Need
• Gated Delta Networks: Improving Mamba2 with Delta Rule
• Mamba: Linear-Time Sequence Modeling with Selective State Spaces
• llama.cpp — סיביות לכל משקל בכל פורמט קוונטיזציה
• תיעוד vLLM על מטמון מקוונטז