מה תופס VRAM כשמריצים LLM

זיכרון GPU של מודל שפה הוא שלושה דברים: המשקלים, ה-KV cache וה-overhead של סביבת ההרצה. שנו את המודל, את ה-quantization, את אורך ההקשר ואת מספר הבקשות במקביל, וראו איזה חלק גדל.

פורסם ב-13 באוקטובר 2026

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

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

נסו בעצמכם

מודל
Quantization
הקשר
בקשות במקביל
זיכרון ה-GPU של המודל, לפי חלקים מהנתונים

העמודה מציגה את הקצה העליון של כל טווח.

משקלים
15.2 GB
KV cache
0.2 GB
Overhead
1.2–3.0 GB
סה"כ
16.7–18.5 GB

מול GPUs לייחוס

  • NVIDIA GeForce RTX 4090, ‏24 GB: נכנס
  • NVIDIA L40S, ‏48 GB: נכנס
  • NVIDIA H100 SXM, ‏80 GB: נכנס

מנוע @anaroq/gpu 1.0.0 · נתוני מודלים 2026.10.0 · נתוני GPU 2026.10.0

סה"כ 16.7–18.5 GB: משקלים 15.2 GB, ‏KV cache 0.2 GB, ‏overhead 1.2–3.0 GB.

שלב אחר שלב

  1. כל פרמטר של המודל מוחזק בזיכרון ה-GPU. ב-16 ביט (BF16, הפורמט שבו רוב המודלים הפתוחים מתפרסמים) זה 2 בתים לפרמטר, ולכן מודל עם 7.6 מיליארד פרמטרים צריך כ-15 GB למשקלים בלבד.

  2. ‏FP8 שומר משקל ב-8 ביט ו-INT4 בכ-4.25 ביט כולל ה-scales. המשקלים של אותו מודל יורדים לחצי או לפחות משליש. שכבות ה-embedding והפלט נשארות בדרך כלל ב-16 ביט, ולכן ההערכה היא טווח.

  3. לכל token בהקשר, כל שכבה שומרת וקטור key ווקטור value כדי לא לחשב אותם מחדש: 2 × layers × KV heads × head size × bytes לכל token. ‏Quantization של המשקלים לא מקטין אותו. מעבר מהקשר של 4K ל-32K מכפיל אותו פי שמונה.

  4. שרת מחזיק KV cache לכל בקשה שהוא מטפל בה באותו זמן. שש-עשרה בקשות במקביל עם הקשר ארוך יכולות לתפוס יותר זיכרון מהמשקלים עצמם: זה מה שמגביל כמה משתמשים GPU אחד משרת.

  5. סביבת ההרצה מוסיפה זיכרון משלה: ה-CUDA context, ה-framework וה-activations. חברו את שלושת החלקים והשוו את הסכום לזיכרון של GPU. הקצה העליון של הטווח הוא זה שבטוח לתכנן לפיו.

מהנתונים מחושב במנוע ה-GPU של ANAROQ מנתוני מודלים ו-GPUs מגורסאים עם מקורות רשמיים.

מה התרשים מראה

התרשים הוא עמודה של זיכרון GPU ב-GB, מחולקת למשקלים, ‏KV cache ו-overhead, עם קווים בגובה הזיכרון של שלושה GPUs לייחוס. מתחתיה כל חלק והסכום מוצגים כטווחים, וכל GPU מסומן לפי אם הקצה העליון של הסכום נכנס בו או לא.

הבקרים בוחרים את המודל, את ה-quantization (‏BF16, ‏FP8, ‏INT4), את אורך ההקשר (4K, ‏8K, ‏32K tokens) ואת מספר הבקשות במקביל (1, 4, 16). ‏Quantization משנה רק את המשקלים; הקשר ובקשות במקביל משנים רק את ה-KV cache.

נסו בכלי

פתחו את Open WebUI

מה לא מכוסה כאן

מודלים dense בלבד: מודלי mixture-of-experts צריכים מודל זיכרון אחר. ה-KV cache הוא ב-16 ביט, וה-overhead הוא הנחה מוצהרת ולא מדידה; מנועים שמחלקים את ה-KV cache לדפים או מבצעים לו quantization משתמשים בפחות. ‏Throughput לא מכוסה.

מקורות

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

כל ההסברים