אילו מודלי AI ניתן לארח באופן עצמי על שרת VPS?

מה קובע אילו מודלי AI ניתן לארח באופן עצמי

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

שתי עלויות קובעות את התשובה. ה-weights הם העלות הקבועה, הנקבעת לפי מספר ה-parameter וה-quantisation. ה-context window הוא העלות השוטפת, וזהו המשתנה שאנשים שוכחים עד שמודל שנטען אתמול מסרב להיטען היום.

חישוב הנפח: ביטים לכל פרמטר

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

weights in GB = (parameters in billions x bits per weight) / 8

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

• Q8_0 מאחסן כ־8.5 ביטים למשקולת, כלומר כ־1.1 GB לכל מיליארד פרמטרים.
• Q6_K מאחסן כ־6.6 ביטים, כלומר כ־0.83 GB לכל מיליארד.
• Q5_K_M מאחסן כ־5.7 ביטים, כלומר כ־0.71 GB לכל מיליארד.
• Q4_K_M מאחסן כ־4.8 ביטים, כלומר כ־0.6 GB לכל מיליארד.

השתמשו ב־0.6 GB לכל מיליארד פרמטרים כמספר עבודה. Q4_K_M הוא ברירת המחדל ההגיונית עבור שרת המוגבל בזיכרון: אובדן האיכות בהשוואה ל־8 ביט הוא קטן ברוב המשימות, והקובץ קטן כמעט בחצי. מתחת ל־4 ביט האובדן גדל במהירות, לכן מודל 70B שנדחס ל־2 ביט בדרך כלל יספק תשובות פחות טובות ממודל 32B ב־4 ביט מאותו דור. כאשר הזיכרון מצומצם, עדיף להקטין את גודל המודל מאשר לרדת מתחת ל־4 ביט.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

עמודת המשקל לעיל מבוססת על כלל ה־0.6 GB למיליארד. קובצי GGUF אמיתיים נמצאים בטווח של אחוזים בודדים מחישוב זה, כיוון ששכבות ה-embedding וה-output נשמרות בדיוק גבוה יותר משאר המודל. מודל 3B ב־4 ביט הוא כ־1.8 GB. מודל 8B הוא 4.8 GB. מודל 32B הוא 19.2 GB, ומודל 70B הוא 42 GB.

מדוע אורך ההקשר (context length) צורך יותר זיכרון RAM מאשר המשקולות

ה־KV cache (מטמון מפתחות וערכים, מצב ה-attention שהמודל שומר עבור כל אסימון בשיחה הנוכחית) הוא העלות השנייה בחשיבותה. הוא מוקצה בעת טעינת המודל, גודלו נקבע לפי אורך ההקשר שביקשת, והוא גדל באופן ליניארי בהתאם לאורך זה.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

באורך ההקשר המוגדר כברירת מחדל ב-Ollama, מודל 8B צורך חצי ג'יגה-בייט עבור המטמון. ב-8192 אסימונים הוא צורך 1 GB. באורך הקשר של 128k, כפי שמפורסם בכרטיס המודל שלו, הוא צורך 16 GB, שזה יותר מפי שלושה ממשקל המודל עצמו. במודל 70B המצב הפוך: המטמון שלו ב-128k הוא 40 GB, פחות ממשקל המודל עצמו, כיוון ש-grouped query attention מונע מהעלות לכל אסימון לגדול באותו קצב של כמות הפרמטרים.

אורך ההקשר המוגדר כברירת מחדל ב-Ollama הוא 4096 אסימונים בשרת מבוסס CPU בלבד. כאשר קיים GPU, המערכת בוחרת את ברירת המחדל מתוך ה-VRAM: 32k עבור זיכרון שבין 24 ל-48 GiB, ו-256k עבור 48 GiB ומעלה. ניתן להגדיל ערך זה באמצעות המשתנה OLLAMA_CONTEXT_LENGTH בשרת, ולאחר מכן לבדוק מה קיבל המודל בפועל בעמודה CONTEXT בתוך ollama ps. החישובים המתמטיים של הזיכרון מאחורי הגדרה זו מפורטים ב-פוסט על num_ctx ואורך הקשר.

קיימות שתי דרכים לצמצם את צריכת הזיכרון של המטמון. בקש את אורך ההקשר הדרוש לך במקום את האורך המפורסם בכרטיס המודל, שכן רוב עבודות הצ'אט והתכנות נכנסות בטווח של 8k עד 32k. לחלופין, בצע קוונטיזציה (quantisation) למטמון עצמו ל-8-bit, מה שיחצה את צריכתו, במחיר מסוים של ירידה בדיוק השליפה בהקשרים ארוכים.

מודל תושב שומר על ה-RAM עד שגורם כלשהו מפנה אותו

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

ollama ps
ollama stop qwen3:4b

ollama ps מציג את המודלים השוכנים בזיכרון, כאשר עמודה SIZE מציגה כמה זיכרון תופס המודל, ועמודה UNTIL מציגה מתי הוא יפוג. כדי להצמיד מודל לצמיתות, הגדירו את OLLAMA_KEEP_ALIVE=-1 בשירות. ערך של 0 יפנה את המודל מיד עם סיום כל תגובה.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

שלחו הנחיה (prompt) אחת, ולאחר מכן הריצו את ollama ps שוב כעבור עשר דקות. המודל עדיין מופיע ברשימה, וזו בדיוק המטרה: הוא תופס את ה-RAM ללא קשר לשאלה אם מישהו משתמש בו. מודל מוצמד אינו נחשב לקיבולת פנויה. בשרת VPS עם 16 GB, מודל 8B עם context של 8k תופס בערך 6 GB כל עוד השירות רץ, לכן יש להתאים את גודל השרת לפי המודל בתוספת היישום שלכם, ולא לפי המודל בלבד. הצמדת מודל בזיכרון סוקרת את הפשרה מול השהיית טעינה קרה (cold start latency).

מה ניתן להריץ על שרת VPS עם 4 GB זיכרון

הקצו כ-1 GB עבור מערכת ההפעלה ושרת המודלים, מה שמותיר כ-3 GB פנויים. נפח זה מתאים להרצת מודל בגודל 1B עד 4B בקוונטיזציה של 4-bit, עם אורך הקשר (context) ברירת מחדל של 4096 טוקנים. נכון לאוגוסט 2026, קטגוריה זו כוללת את Llama 3.2 בגרסת 3B, את Qwen 3 בגרסאות 1.7B ו-4B, וכן את המהדורות הקטנות של Gemma ו-Phi. התייחסו לשמות אלו כדוגמאות לגודל בלבד, ולא כהמלצות. השמות מתחלפים מדי כמה חודשים, אך החישוב המתמטי נותר קבוע.

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

אופן הכשל ברמה זו הוא שימוש ב-swap. אם המודל אינו נכנס בזיכרון, Linux לא תסרב לטעון אותו. במקום זאת, המערכת תעביר דפי זיכרון לדיסק (paging). מכיוון שיצירת טוקן בודד דורשת קריאה של כל משקולות המודל פעם אחת, מהירות היצירה תצנח לשניות לכל טוקן. עקבו אחר free -h ועמודות si ו-so בתוך vmstat 1 בזמן שהמודל משיב. ערכים שאינם אפס ב-swap in וב-swap out במהלך היצירה מעידים על כך שהמודל גדול מדי עבור תוכנית האירוח שלכם.

מה מריצים על VPS עם 8 עד 16 GB RAM

זהו השלב שבו מודל באירוח עצמי הופך לשימושי באמת. על 8 GB ניתן להריץ מודל 7B או 8B בקוונטיזציה של 4 ביט, שזה בערך 4.8 GB של משקולות, עם context של 8k. על 16 GB ניתן להריץ מודל 13B או 14B ב-4 ביט, כ-8.4 GB, או להשאיר מודל 8B ב-8 ביט אם אתם מעדיפים להשקיע את הזיכרון בדיוק (precision) מאשר במספר הפרמטרים.

המהירות היא המכשול. מודל 8B על גבי CPU מייצר בערך 3 עד 7 טוקנים לשנייה, ומודל 14B מייצר כ-1.5 עד 3.5. קצב קריאה אנושי הוא סביב 5 עד 10 טוקנים לשנייה, כך שמודל 8B על שרת VPS מבוסס CPU מרגיש כמו צפייה בקלדן איטי. זה תקין עבור משימות רקע, אך מעייף עבור צ'אט אינטראקטיבי. הרצות מדודות של Qwen 3 בגרסת 8B ומעלה על VPS מראות כיצד זה נראה בפועל.

מה מריצים על שרת VPS עם 32 עד 64 GB זיכרון

מודל 32B בקוונטיזציה של 4 ביט תופס כ-19.2 GB, לכן הוא נכנס בתוכנית של 32 GB עם הקשר (context) קצר, ורץ בנוחות על 48 GB או 64 GB. מודל 70B ב-4 ביט תופס כ-42 GB, ולכן הוא דורש 64 GB עוד לפני הוספת זיכרון מטמון (cache) כלשהו.

לאחר מכן בחנו את המהירות באופן מציאותי. מודל 32B על CPU מפיק בערך 0.6 עד 1.5 טוקנים בשנייה, ומודל 70B מפיק 0.2 עד 0.5. תשובה באורך 500 טוקנים ממודל 70B נמשכת בערך 20 דקות. בקצב כזה הבקשה בדרך כלל נכשלת לפני שהמודל מסיים, משום ש־timeout של לקוח או של proxy שנמצא לפני Ollama מופעל קודם. מכאן נובעת שגיאת חריגת הזמן שהוקצה להקשר. אלה כלים לעיבוד באצווה. הזינו להם תור של מסמכים במהלך הלילה, והמהירות אינה חשובה. הציבו אותם מאחורי חלון צ׳אט, והמהירות נעשית חשובה מאוד.

ניתוב בשיטת Mixture of Experts משנה את החישוב הזה, וזהו פרט הארכיטקטורה היחיד ששווה ללמוד. מודל MoE מעביר כל טוקן דרך חלק קטן בלבד מהמשקולות שלו. מודל עם 30B פרמטרים בסך הכל ו-3B פרמטרים פעילים לכל טוקן דורש זיכרון של מודל 30B, אך מייצר טקסט במהירות הקרובה למודל 3B דחוס, כיוון שכל טוקן קורא רק את המומחים הפעילים. על שרת עם 32 GB, מודל MoE במבנה כזה הוא שימושי הרבה יותר ממודל 30B דחוס. הכלל שיש לזכור: סך הפרמטרים קובע את צריכת הזיכרון, והפרמטרים הפעילים קובעים את המהירות.

מהי המהירות האמיתית של הסקת CPU?

יצירת טוקן בודד מחייבת קריאה של כל המשקולות הפעילות מהזיכרון פעם אחת. אין דרך לעקוף זאת, לכן מהירות היצירה ב-CPU נקבעת לפי רוחב הפס של הזיכרון ולא לפי מספר הליבות. התקרה היא תוצאה של חילוק: רוחב הפס הזמין של הזיכרון חלקי גודל המשקולות בבתים. שרת VPS שיתופי קטן מספק באופן ריאלי בין 10 ל-25 GB לשנייה לכל ה-vCPUs שלו, לכן מודל בגודל 4.8 GB יגיע למהירות מקסימלית של כ-2 עד 5 טוקנים לשנייה.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

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

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

הסיכום המודפס לאחר סיום התשובה מסתיים בשורה המכילה את eval rate: ... tokens/s. זהו נתון מהירות היצירה שלכם. התעלמו מההרצה הראשונה של סשן, כיוון ש-load duration באותו סיכום כולל את קריאת המשקולות מהדיסק. מדידה נכונה של טוקנים לשנייה מסביר כיצד לקבל נתון שראוי להשוואה.

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

קריאת ה-prompt שלכם היא משימה שונה מיצירת התשובה. עיבוד ה-prompt מוגבל על ידי כוח חישוב (compute bound), לכן הוא אכן משתפר עם הוספת ליבות, וזהו המקום שבו GPU משיג את היתרון המשמעותי ביותר. מסמך ארוך ידרוש מ-CPU דקות של קריאה, בעוד ש-GPU יסיים זאת בשניות. זהו המחסום הראשון שבו תיתקלו כאשר מפנים סוכן תכנות למודל שאתם מארחים, כיוון שכל סבב שולח מחדש את הקשר הקובץ ואת הגדרות הכלים לפני שטוקן בודד של התשובה חוזר.

מה משתנה בעת הוספת GPU

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

• 8 GB של VRAM מכילים מודל 7B או 8B בקוונטיזציה של 4-bit עם הקשר (context) קצר.
• 16 GB מכילים מודל 14B ב-4-bit עם הקשר מלא, או מודל 8B ב-8-bit.
• 24 GB מכילים מודל 32B ב-4-bit עם הקשר קצר.
• 48 GB ומעלה מכילים מודל 70B ב-4-bit עם מקום ל-cache ולעבודה במקביל.

כאשר מודל אינו נכנס בזיכרון, Ollama מפצלת אותו: חלק מהשכבות רצות על ה-GPU, והשאר על ה-CPU. ollama ps מדווח על הפיצול בעמודה PROCESSOR, בפורמט כגון 78%/22% CPU/GPU. התייחסו לכך כאזהרה ולא כתכונה. החלק שרץ על ה-CPU קובע את קצב העבודה, כיוון שכל טוקן ממתין לסיום עיבוד השכבות הללו. לכן, מודל שרבע מהשכבות שלו רצות על ה-CPU ירוץ במהירות שקרובה יותר למהירות ה-CPU מאשר למהירות ה-GPU. אם אתם רואים פיצול שלא תכננתם, צמצמו תחילה את אורך ההקשר (context length). ה-cache הוא לרוב הגורם שחורג מהמכסה.

עבודה במקביל (concurrency) היא סיבה נוספת להגדלת המשאבים. המשקולות (weights) משותפות בין בקשות בו-זמניות, אך כל בקשה פעילה זקוקה ל-KV cache משלה. לכן, עשרה משתמשים בו-זמניים המריצים מודל 8B עם הקשר של 8k ידרשו פי עשרה מ-1 GB של cache מעבר למשקולות המודל. הגשת שירות למשתמשים בו-זמניים ממודל באירוח עצמי מפרט היכן עובר הגבול הזה.

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

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

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

המחסום הראשון הוא משקולות (weights) סגורות. מודלים מסחריים חזיתיים אינם מופצים, לכן אין קובץ שניתן להוריד, ושום שינוי בנפח ה-RAM לא ישנה זאת. ניתן לארח באופן עצמי את כל המעטפת שלהם: הממשק, שכבת השליפה (retrieval), לולאת הסוכן (agent loop) והלוגים. המודל עצמו נשאר API מרוחק. המאמר האם ניתן לארח את Claude באופן עצמי מפרט זאת במלואו.

המחסום השני הוא משקולות פתוחות שפשוט גדולות מדי. המודלים הפתוחים הגדולים ביותר מבוססים על ארכיטקטורת Mixture of Experts, עם מאות מיליארדי פרמטרים בסך הכל. אותו כלל חל עליהם: מודל של 400B פרמטרים בקוונטיזציה של 4-bit דורש כ-240 GB עבור המשקולות בלבד, עוד לפני חישוב ה-cache. מדובר בחומרה ייעודית, ועלות השכרתה החודשית גבוהה בהרבה ממה שרוב האנשים מוציאים על טוקנים של API בשנה שלמה. המאמר מה נדרש כדי לארח באופן עצמי מודל מסוג Kimi מפרט את הדרישות בפועל. אותה חלוקה מופיעה בתוך הספרייה של Ollama, שם GLM 5.2 מופיע כמודל ענן בלבד בעוד שגרסה קטנה בהרבה היא זו שניתן להוריד בפועל ל-VPS.

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

בדקו מה עומד לרשותכם לפני הבחירה

free -h
nproc
lscpu | grep 'Model name'

תכננו לפי עמודת ה-available ב-free -h, ולא לפי עמודת ה-total, כיוון ש-total כוללת זיכרון שהמערכת כבר משתמשת בו. החסירו כ-1 GB עבור מערכת ההפעלה ושרת המודלים. חלקו את היתרה ב-0.6 כדי לקבל את מספר הפרמטרים המקסימלי במיליארדים שניתן להחזיק ב-4 bits. לאחר מכן, החסירו את ה-KV cache עבור ההקשר (context) שבו אתם באמת מעוניינים. מה שנותר הוא התשובה שלכם, ובניגוד לרשימת שמות מודלים, נתון זה אינו מתיישן.

FAQ

כמה זיכרון RAM דרוש להרצת מודל 8B?

בערך 4.8 GB עבור המשקולות בקוונטיזציה של 4 bit, בתוספת ה-KV cache עבור אורך ההקשר (context length) שלך, ובתוספת של כ-1 GB עבור מערכת ההפעלה ושרת המודל. בהקשר של 8192 טוקנים, ה-cache מוסיף בערך 1 GB, לכן תוכנית של 8 GB תעבוד ותוכנית של 4 GB לא תספיק. אם ברצונך להשתמש במלוא ה-128k context שמצוין בכרטיס המודל, ה-cache לבדו יצרוך 16 GB, ותצטרך תוכנית של 32 GB.

מדוע המודל שלי איטי למרות של-VPS יש הרבה vCPUs?

מכיוון שיצירת טקסט מוגבלת על ידי רוחב הפס של הזיכרון, ולא על ידי מספר הליבות. כל טוקן דורש שליפה של כל סט המשקולות הפעיל מה-RAM, כך שברגע שמספר ליבות מנצלות את ערוצי הזיכרון, שאר הליבות פשוט ממתינות. סיבה נפוצה נוספת היא swap. אם vmstat 1 מציג ערכים שאינם אפס ב-si וב-so בזמן שהמודל משיב, המשקולות אינן נכנסות ב-RAM וחלק מכל טוקן מוגש מהדיסק, מה שגורם להאטה משמעותית הרבה יותר ממה שנראה לעין.

האם חלון הקשר (context window) ארוך יותר באמת דורש יותר זיכרון?

כן, והגידול הוא ליניארי ביחס למספר הטוקנים. מודל 8B טיפוסי צורך כ-128 KiB של KV cache לכל טוקן, לכן 8192 טוקנים עולים 1 GB ו-131072 טוקנים עולים 16 GB. ה-cache מוקצה בעת טעינת המודל ולא ככל שהשיחה גדלה, לכן הגדרה של 128k context משריינת את הזיכרון הזה באופן מיידי, גם אם כל prompt שתשלח יהיה באורך של 200 טוקנים בלבד.

האם כדאי להריץ מודל גדול ב-2 bit או מודל קטן יותר ב-4 bit?

עדיף לבחור במודל הקטן יותר ב-4 bit. האיכות יורדת באיטיות מ-8 bit ל-4 bit, אך צונחת במהירות מתחת ל-4 bit. לכן, מודל 70B שנדחס ל-2 bit בדרך כלל יספק תשובות פחות טובות ממודל 32B ב-4 bit מאותו דור מודלים. קוונטיזציה כבדה מתבטאת בחזרתיות ובפספוס הוראות במקום בהודעת שגיאה, מה שמקשה על זיהוי הבעיה ומטעה לחשוב שהבעיה היא ב-prompt. התייחס ל-4 bit כאל רף מינימלי ושנה את מספר הפרמטרים בהתאם לצורך.

האם ניתן לארח באופן עצמי מודל בעל יכולות דומות למודלים המסחריים הגדולים?

לא ב-VPS רגיל. המודלים החזקים ביותר בעלי משקולות פתוחות מגיעים למאות מיליארדי פרמטרים, מה שב-4 bit דורש מעל 200 GB של RAM עוד לפני ה-KV cache, והמודלים המסחריים החזקים ביותר אינם מופצים כלל. מה שחומרה רגילה עושה היטב הוא הרצת מודל 8B עד 32B למשימה ספציפית, שבה מודל קטן וממוקד עם prompt איכותי משתווה לעיתים קרובות למודל כללי. אם אתה זקוק לאיכות ברמה הגבוהה ביותר, השווה את עלות ה-API מול עלות החומרה לפני הרכישה.