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

המחיר הנסתר של הקונטקסט

כל טוקן שאתם מייצרים מוסיף מצב (state) ל-KV cache. ה-cache הזה שומר את המפתחות (keys) והערכים (values) שחושבו במהלך שלבי ה-prefill וה-generation, והוא יושב בזיכרון לצד משקלי המודל, חוצצי ה-attention וה-runtime overhead. ב-GPU צרכני טיפוסי עם 12 GB או 16 GB של VRAM, ה-KV cache בסופו של דבר מתחרה על מקום עם כל שאר הרכיבים. כשזיכרון הווידאו הייעודי מתמלא, מערכת ההפעלה לא זורקת שגיאה ועוצרת. היא מזרמת בשקט את העודפים לזיכרון משותף (shared memory), תוך העברת נתונים בין ה-GPU לבין ה-system RAM דרך ה-PCIe bus. ה-bus הזה מהיר להעברת קבצים, אבל הוא איטי בצורה קיצונית בהשוואה לרוחב הפס של הזיכרון בתוך כרטיס גרפי. התוצאה היא לא ירידה קלה בביצועים. זו קריסה.

שלושה סימנים לכך שהגעתם לצוק

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

  • ה-Shared VRAM עולה. זהו זיכרון שדרייבר ה-GPU דחף מתוך ה-dedicated video RAM אל תוך מאגר המנוהל על ידי מערכת ההפעלה המארחת. ברגע שהמדד הזה עולה מעל אפס, חציתם את הגבול.
  • שימוש ב-System RAM מתנפח. העודפים חייבים לנחות איפשהו, והיעד הזה הוא הזיכרון הראשי שלכם. אם השימוש ב-RAM גדל בזמן שהמודל מייצר טוקנים, נתונים מועברים (offloaded) מה-GPU.
  • מהירות ה-Eval צונחת בחצי או יותר. האטה של 10% עשויה להעיד על thermal throttling או תהליכי רקע. ירידה של 50%, או יותר מכך, אומרת שהצוואר בקבוק עבר מ-tensor cores לרוחב פס של זיכרון ו-PCIe latency. כשאתם רואים את קצב היצירה צונח ממספרים דו-ספרתיים למספרים חד-ספרתיים, כבר נפלתם מהצוק.

למה הבנצ'מרק המהיר שלכם כנראה משקר לכם

בדיקת "עשן" (smoke test) קצרה תיתן לכם ביטחון שווא. אם תבצעו בנצ'מרק למודל עם פרומפט של מאה טוקנים, תראו תפוקה (throughput) תקינה ותחשבו שסיימתם, מדדתם רק את "תקופת הדבש". ה-KV cache כמעט ריק. השכבות לא עברו עומס של prefill ארוך. טביעת הרגל האמיתית נחשפת רק לאחר שהמודל מעבד פרומפט משמעותי וה-cache מתמלא לגודל העבודה האמיתי שלו. עליכם לבדוק עם prefill עמוק והרצות יצירה ארוכות. תנו לקונטקסט להצטבר באמת. רק אז לחץ הזיכרון יתייצב ויראה לכם את הגבול האמיתי.

מציאת הגבול שלכם עם llama.cpp

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

1. מדדו את השימוש בזיכרון משותף.
רשמו את ה-baseline של ה-dedicated VRAM שלכם עם פרומפט מינימלי, לאחר מכן הריצו משימת long-context ושימו לב לשיא (peak). החסרו את ה-baseline מהשיא. ההפרש הוא מה ש"נשפך" מה-GPU שלכם אל הזיכרון המשותף של המערכת.

2. חשבו את ה-RAM delta שלכם.
בצעו את אותה פעולת חיסור עבור ה-system RAM. החסרו את ה-baseline RAM מה-peak RAM במהלך ההרצה הארוכה. המספר הזה אומר לכם בדיוק כמה נתונים נדחפו מכרטיס הווידאו אל הזיכרון הראשי שלכם. הוא מודד את ה"דליפה" לאורך ה-bus.

3. מדדו את זמן קריסת מהירות ה-eval.
השוו את קצב ה-tokens-per-second הבסיסי שלכם לעומת הקצב לאחר שהמודל "לעס" מסמך ארוך. אתם עשויים לראות מודל שנע בקצב של שבע עשרה טוקנים בשנייה כשהקונטקסט טרי, ואז מספק רק שני טוקנים בשנייה ברגע שה-cache התנפח. הירידה של חמש עשרה טוקנים היא ה"קנרית במכרה הפחם" שלכם.

איתור נקודת השבירה באמצעות טריאנגולציה

To map the curve accurately, do not settle for one lonely data point. Run three distinct trials at 16,000 tokens, 32,000 tokens, and 65,000 tokens. Two points might suggest a line, but two dots are just a guess. The third point proves whether you are looking at measurement noise or a real memory wall. Subtract the results between runs to calculate how much extra memory each additional thousand tokens consumes on your specific combination of model, quantization layer, and GPU.

Once you have that slope, you can project forward. Take your per-token cost, multiply it by the target context length, divide by 1024 to move between units, and add the result to your base model VRAM load. The equation looks like this:

Model VRAM load + (tokens × memory per token ÷ 1024) = Theoretical VRAM usage

This projection is not prophecy. It is a guidepost derived from actual behavior. Use it to estimate your ceiling before you commit to a full production run.

Why Paper Formulas Fail, and What Quantization Can Fix

Textbook formulas ignore the messy reality of local inference. Different architectures allocate attention buffers differently. Your operating system reserves VRAM for the display driver, compositor, and CUDA context. Driver versions change how aggressively they use shared memory. A theoretical equation cannot know how much VRAM is actually free on your machine at 2:00 PM with a browser full of tabs open. You have to run the model on your specific hardware and watch the meters.

Quantization offers partial relief. Moving the KV cache from f16 to q8_0 halves its memory footprint while keeping precision high enough for nearly all practical tasks. That change buys you headroom. It does not grant immunity. The cache still grows linearly with every token you feed in. Eventually, even the reduced size overwhelms your available dedicated memory and the spillover to system RAM begins. The pressure only stops when the context window is capped or the data stops moving.

The Real Takeaway

Do not trust marketing slides, parameter counts, or back-of-the-envelope math. Load the model. Open your system monitor. Run a 65,000-token thread, watch the RAM climb, and count the tokens per second. The numbers that appear on your specific screen, on your specific GPU, are the only numbers that matter. Context always wins. Your job is to know exactly when it wins on your machine.