הרצת Nemotron 3.5 Lightning על שרת VPS עם Ollama

מהו הייעוד של Nemotron 3.5 Lightning

Nemotron 3.5 Lightning הוא מודל Mixture-of-Experts פתוח של NVIDIA בעל 30B פרמטרים, ששוחרר באוגוסט 2026. הוא תוכנן עבור סוכנים (agents) הפועלים במשך שעות, ולא עבור חלון צ'אט בודד. המשמעות של MoE (תערובת מומחים) היא שהמשקולות מחולקות לתתי-רשתות מומחיות רבות, כאשר כל token מנותב דרך מספר מצומצם בלבד מהן. כרטיס המודל של NVIDIA מציין 30 מיליארד פרמטרים בסך הכל, עם 3 מיליארד פעילים לכל token. אתם משלמים על המספר הגבוה בזיכרון, ומקבלים בתמורה את המספר הנמוך כמהירות.

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

NVIDIA מתארת את הארכיטקטורה כהיברידית: שכבות Mamba-2 ו-MoE משולבות עם שכבות attention נבחרות. כרטיס המודל מציין אורך הקשר (context length) מרבי של עד 1M tokens ורישיון OpenMDW-1.1, המסומן כמתאים לשימוש מסחרי. השפות העיקריות הן אנגלית וקוד, כאשר גם ספרדית, צרפתית, גרמנית, איטלקית ויפנית מופיעות ברשימה.

Artificial Analysis פרסמה מדידות השקה באוגוסט 2026 המראות קרוב ל-670 tokens לשנייה, בנקודת קצה (endpoint) של DeepInfra בגרסת טרום-הפצה המגישה משקולות NVFP4. זוהי נקודת קצה של GPU מאוחסן. התייחסו לנתון זה כאל מה שהארכיטקטורה מאפשרת, ולא כאל מה שה-VPS שלכם יבצע בפועל.

איזו תגית Ollama מתאימה לאיזה VPS

ספריית Ollama מפרסמת כמה גרסאות לאותם משקלים (weights). ההבדל ביניהן הוא ה-quantisation, כלומר מספר הביטים המשמש לאחסון כל משקל, מה שמשפיע משמעותית על גודל ההורדה.

[
  {
    "label": "30b-a3b-q4_K_M",
    "size_gb": 25
  },
  {
    "label": "30b-a3b-q8_0",
    "size_gb": 35
  },
  {
    "label": "30b-a3b-bf16",
    "size_gb": 66
  },
  {
    "label": "30b-a3b-mlx",
    "size_gb": 23
  }
]

התגיות latest, 30b ו-30b-a3b כולן מצביעות על אותו digest כמו 30b-a3b-q4_K_M, לכן ברירת המחדל להורדה היא גרסת ה-four-bit בגודל 25 GB עם context מלא של 1M. גרסת Q8_0 היא בגודל 35 GB וגרסת bf16 היא בגודל 66 GB, שתיהן גם הן ב-1M. גרסאות ה-MLX בגודל 23 GB מיועדות ל-Apple silicon ומוגבלות ל-context של 256K, לכן הן אינן הבחירה הנכונה עבור Linux VPS.

אלו הם גדלי הורדה, לא דרישות זיכרון. NVIDIA אינה מפרסמת נתון מינימלי ל-VRAM (זיכרון וידאו) עבור גרסאות Ollama, לכן יש להתייחס לגודל ההורדה כרף תחתון בלבד. המשקלים חייבים להיות מאוחסנים איפשהו: בזיכרון ה-GPU אם הכרטיס מסוגל להכיל אותם, או בזיכרון ה-RAM של המערכת אחרת. בנוסף, יש להוסיף את ה-KV cache (זיכרון ה-key/value, הזיכרון של המודל לכל token בשיחה). המספר המדויק עבור החומרה שלכם מתקבל מפקודה, לא מחישוב אריתמטי, והוא מופיע בהמשך. אם טרם החלטתם על רמת ה-quantisation, המאמר מה העלות של Q4, Q8 ו-FP16 מפרט על מה מוותרים בכל שלב.

משכו את ה-tag המדויק, לעולם לא latest

latest הוא מצביע דינמי. כאשר הספרייה מפרסמת אותו מחדש, התנהגות הסוכן שלכם תשתנה ב-pull הבא ללא כל תיעוד בהערות שלכם שיסביר מדוע. ציינו את שם ה-tag.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama pull nemotron-3.5-lightning:30b-a3b-q4_K_M

סקריפט ההתקנה מגדיר שירות systemd שרץ כמשתמש ollama ושומר מודלים תחת /usr/share/ollama/.ollama/models. נתיב זה נמצא במערכת הקבצים הראשית (root) ברוב תמונות ה-VPS, לכן בדקו שיש מקום פנוי לפני שאתם מקצים 25 GB.

df -h /usr/share/ollama

פעולת pull שנעצרת באמצע ומדווחת על no space left on device משמעותה בדיוק זה, וה-blobs החלקיים נשארים על הדיסק עד שתמחקו אותם. לאחר מכן, ודאו מה הותקן בפועל:

ollama show nemotron-3.5-lightning:30b-a3b-q4_K_M

ollama show מדפיס את הארכיטקטורה, את מספר הפרמטרים, את אורך ההקשר (context length) ואת ה-quantisation שהקובץ מכיל בפועל. אם אחד מהנתונים הללו אינו תואם לדף הספרייה, משכתם tag שונה מזה שהתכוונתם אליו.

הגשת המודל ובדיקת מיקום ההרצה בפועל

sudo systemctl enable --now ollama
ollama run nemotron-3.5-lightning:30b-a3b-q4_K_M "Reply with one word: ready"

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

ollama ps

זו הפקודה שתענה על שאלת צריכת הזיכרון במכונה שלכם. ollama ps מציגה את המודל הטעון, את נפחו בזיכרון ואת העמודה PROCESSOR. הערך 100% GPU מציין שכל המודל נמצא ב-VRAM. הערך 100% CPU מציין ששום חלק ממנו אינו שם, וכל token מחושב על ידי המעבד מתוך ה-RAM של המערכת. פיצול כמו 65%/35% CPU/GPU מציין שהשכבות לא נכנסו במלואן לזיכרון הגרפי, ומהירות העבודה שלכם תיקבע לפי נתח ה-CPU. אל תנסו להעריך את הדרישות; טענו את המודל וקראו את השורה הזו.

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

Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB)

האם VPS מבוסס CPU בלבד מהיר מספיק?

בשרת VPS כללי אין GPU, לכן ה-CPU מבצע את כל העבודה וקורא כל משקל נדרש מה-RAM של המערכת. מודל MoE מסייע כאן, כיוון שרק כ-3 מיליארד מתוך 30 מיליארד הפרמטרים נדרשים עבור כל token, ולכן החישוב האריתמטי לכל token קטן משמעותית בהשוואה למודל dense של 30B. הזיכרון אינו נהנה מכך כלל; כל 30 מיליארד הפרמטרים חייבים להישאר בזיכרון, כיוון שה-router עשוי לבחור בכל מומחה עבור כל token.

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

בצעו מדידה לפני שתקצו סוכן (agent) לשרת, באמצעות השיטה המתוארת ב-מדידת tokens לשנייה עבור LLM מקומי:

ollama run --verbose nemotron-3.5-lightning:30b-a3b-q4_K_M "Write a 200 word summary of TCP slow start."

השורה eval rate המודפסת בסיום היא מהירות ההפקה שלכם ב-tokens לשנייה. מספר יחיד זה מכריע את השאלה, כיוון שזמן ה-wall-clock של סוכן מושפע ממנו בעיקר.

[
  {
    "label": "Nemotron 3.5 Lightning",
    "sec_per_task": 30
  },
  {
    "label": "gpt-oss-120b",
    "sec_per_task": 204
  },
  {
    "label": "Qwen3.6 35B",
    "sec_per_task": 210
  }
]

אלו נתונים שפורסמו על ידי צד שלישי, שהומרו מדקות לכל משימה כפי שדווח על ידי Artificial Analysis בעת ההשקה, והם נמדדו על גבי נקודות קצה של GPU מאוחסן ולא על גבי VPS. המודל Nemotron 3.5 Lightning הפיק בממוצע כ-30 שניות למשימה, כאשר gpt-oss-120b ארך בערך 204 ו-Qwen3.6 35B ארך בערך 210. השתמשו בנתונים אלו כדי להבין את סדר הגודל של הפער, ולא כהבטחה לגבי החומרה שלכם.

ההמלצה הכנה תלויה בשאלה מי ממתין. אם אדם ממתין לסוכן, או שהסוכן מבצע שרשראות ארוכות של קריאות בזו אחר זו, שכרו קיבולת GPU. אם הסוכן רץ לפי לוח זמנים במהלך הלילה ואף אחד לא צופה בו, תוכנית CPU עם נפח RAM גדול היא פתרון סביר. כך או כך, ההגדרה זהה, והמדריך הרצת Ollama על גבי VPS מכסה את התאמת גודל התוכנית ואת ההשוואה בין מופע GPU לבין תשלום לספק API לפי token. נקודת האיזון היא שאלת ניצולת: מופע GPU מחויב על כל שעה שבה הוא קיים, בעוד ש-API מחויב רק לפי שימוש ב-tokens. לכן, סוכן שעסוק רוב שעות היום מצדיק שרת בבעלותכם, בעוד שסוכן שמופעל פעמיים בשעה לרוב אינו מצדיק זאת.

חלון ההקשר של 1M אינו בחינם

1M טוקנים הם המקסימום של המודל, ו-Ollama לא מעניקה אותם כברירת מחדל. Ollama מגישה חלון ברירת מחדל קטן בהרבה ומשליכה את הטוקנים הישנים ביותר ברגע ששיחה חורגת ממנו. שום דבר לא נרשם בלוגים כאשר זה קורה, לכן עבור סוכן (agent) זה נראה כאילו המודל שוכח את תחילת המשימה שלו.

הגדירו את החלון באופן יזום. עבור כל השרת, ערכו את השירות:

sudo systemctl edit ollama

הוסיפו את זה, ולאחר מכן הריצו את sudo systemctl restart ollama:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

עבור בקשה ספציפית, שלחו את num_ctx באובייקט ה-options במקום זאת:

curl http://localhost:11434/api/chat -d '{
  "model": "nemotron-3.5-lightning:30b-a3b-q4_K_M",
  "messages": [{"role": "user", "content": "Say ready"}],
  "options": {"num_ctx": 32768},
  "stream": false
}'

כל הגדלה עולה בזיכרון, מכיוון ש-KV cache גדל עם מספר הטוקנים שאתם מאפשרים. העלו את הערך, בצעו הפעלה מחדש, ולאחר מכן הריצו את ollama ps שוב וצפו בגודל המדווח עולה. אם עמודת PROCESSOR משתנה מ-100% GPU לפיצול (split) לאחר השינוי הזה, ה-KV cache דחק שכבות מודל מחוץ ל-VRAM והמהירות שלכם תרד משמעותית. בחירת num_ctx ב-Ollama מפרט את האיזון הזה לעומק. אל תגדירו 1000000 רק בגלל שכרטיס המודל מאפשר זאת, מכיוון שההקצאה מתבצעת מראש והטעינה פשוט תיכשל.

חיבור לסוכן הפועל באופן קבוע

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

ollama launch claude --model nemotron-3.5-lightning

הפוסט מתעד את claude, opencode, openclaw ו-hermes במיקום זה. תת-הפקודה דורשת גרסה עדכנית של Ollama, לכן יש לבדוק תחילה את ollama --version, ואם היא חסרה, יש להפנות את הסוכן ל-API באופן ידני. Ollama חושף נקודת קצה (endpoint) תואמת OpenAI, שרוב סביבות העבודה של סוכנים מקבלות:

export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollama

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

שתי הגדרות שרת הן קריטיות ברגע שהסוכן פועל ללא השגחה. OLLAMA_KEEP_ALIVE שולט על משך הזמן שבו מודל נשאר בזיכרון לאחר הבקשה האחרונה; ברירת המחדל פורקת אותו לאחר חמש דקות, כך שהקריאה הבאה תגרור שוב את זמן הטעינה המלא. בקובץ בגודל 25 GB ללא GPU, השהיה זו ארוכה מספיק כדי לגרום לחריגת זמן (timeout). הגדירו את OLLAMA_KEEP_ALIVE=-1 כדי להשאיר את המודל בזיכרון (resident). OLLAMA_HOST=0.0.0.0:11434 הופך את ה-API לנגיש ממכונות אחרות, והוא אינו כולל שום מנגנון אימות, לכן יש לפתוח אותו רק מאחורי חוק firewall או ברשת פרטית.

מצבי כשל והודעות השגיאה הנלוות

משיכת המודל נכשלת באופן מיידי. Error: pull model manifest: file does not exist מציין שהתג (tag) אינו קיים. שמות תגים הם מחרוזות מדויקות, לכן יש להעתיק אותם מדף הספרייה במקום לנחש את סיומת הקוונטיזציה (quantisation).

המודל אינו נטען. Error: model requires more system memory (28.4 GiB) than is available (15.6 GiB) מציין שהתג גדול מדי עבור התוכנית הנוכחית כפי שהוגדרה. עברו לקוונטיזציה קטנה יותר, או הנמיכו את OLLAMA_CONTEXT_LENGTH, כיוון שזיכרון ה-KV cache נכלל בדרישה זו.

אין מענה בפורט 11434. curl: (7) Failed to connect to localhost port 11434 מציין שהשירות אינו רץ, או שאינו מאזין בכתובת המצופה. קראו את systemctl status ollama ואת journalctl -u ollama -n 50. אם הפעלתם גם את ollama serve באופן ידני, העותק השני יסתיים עם השגיאה Error: listen tcp 127.0.0.1:11434: bind: address already in use.

השירות עונה, אך באיטיות רבה. בדקו את ollama ps לפני ביצוע שינויים. כל נתח של CPU בעמודה PROCESSOR במכונה בעלת GPU מעיד על כך שחלק מהמודל זלג אל מחוץ ל-VRAM; במקרה כזה, הקטינו את ההקשר (context) או השתמשו בקוונטיזציה קטנה יותר. במכונה ללא GPU, איטיות היא התוצאה הצפויה ושום הגדרה לא תתקן זאת.

הסוכן שוכח את ההנחיות שלו במהלך המשימה. השיחה חרגה מחלון ההקשר (context window) והטוקנים הישנים ביותר הוסרו בשקט. הגדילו את OLLAMA_CONTEXT_LENGTH, ודאו באמצעות ollama ps שהמודל עדיין נכנס בזיכרון, ואם הוא אינו נכנס עוד, הפתרון הוא שדרוג למכונה חזקה יותר ולא הקטנת החלון.

מיקומו של מודל זה ביחס לחלופות

מודל MoE בגודל 30B הוא רכיב כבד לאירוח עבור משימות קטנות. אם מודל dense בגודל 8B כבר מבצע את המשימה שלכם, עלות ההרצה שלו תהיה נמוכה משמעותית והוא ייטען תוך שניות; Qwen 3 בגרסאות 8B ו-27B על גבי VPS הוא ההשוואה הישירה להחלטה זו. לסקירה רחבה יותר של מה שתוכנית אירוח נתונה יכולה להכיל בפועל, התחילו ב-אילו מודלים של AI ניתן לארח באופן עצמי. אם אתם מתכננים להריץ כמה סוכנים בו-זמנית במקום אחד, קראו תחילה את Ollama בהשוואה ל-vLLM, כיוון ש-Ollama אינו מבצע batching לבקשות במקביל כפי שעושה שרת הסקה (inference server) בסביבת production, ושם בדיוק נעצרת היכולת להרחיב הגדרה של משתמש יחיד.

FAQ

באיזה תג (tag) של Nemotron 3.5 Lightning כדאי להשתמש בשרת VPS מבוסס Linux?

השתמשו ב-nemotron-3.5-lightning:30b-a3b-q4_K_M. גודלו 25 GB, הוא תומך בטווח הקשר (context) המקסימלי של 1M, והוא מצביע על אותו ה-digest שאליו מצביעים התגים latest, 30b ו-30b-a3b נכון לאוגוסט 2026. ציינו את שם התג במפורש במקום למשוך את latest, כדי שפרסום מחדש של אותו מצביע בעתיד לא ישנה את התנהגות הסוכן שלכם מבלי שתבחינו בכך. התגים mlx מיועדים למעבדי Apple silicon ולא יפעלו ב-Linux.

כמה זיכרון RAM דורש Nemotron 3.5 Lightning?

NVIDIA אינה מפרסמת דרישת זיכרון מינימלית עבור גרסאות ה-Ollama, לכן עדיף למדוד מאשר להעריך. משכו את התג, הריצו את המודל פעם אחת, וקראו את ollama ps בזמן שהוא טעון: הפלט מציג את הגודל התפוס בפועל ואם המודל נטען ל-GPU או ל-CPU. גודל ההורדה, 25 GB עבור התג המוגדר כברירת מחדל, הוא הרף התחתון, כיוון שזיכרון ה-KV cache מתווסף מעליו וגדל בהתאם לטווח ההקשר שתגדירו. אם התוכנית קטנה מדי, Ollama תציג שגיאת model requires more system memory ותציין את שני המספרים.

האם ניתן להריץ את Nemotron 3.5 Lightning בשרת VPS ללא GPU?

כן, בתנאי שלתוכנית יש מספיק RAM כדי להכיל את המשקולות (weights). מבנה ה-MoE מסייע בכך שרק כ-3 מתוך 30 מיליארד הפרמטרים מחושבים עבור כל token. המהירות היא המכשול העיקרי. ללא GPU, המודל מוגבל על ידי רוחב הפס של הזיכרון, לכן הוספת vCPUs כמעט אינה משפרת את התוצאות. הריצו את ollama run --verbose עם prompt קבוע, קראו את שורת ה-eval rate, והעריכו את המספר מול דרישות הזמן של הסוכן שלכם. עבור משימות אצווה (batch) שרצות בלילה זה לרוב תקין. עבור כל אינטראקציה שדורשת המתנה של אדם, זה לרוב לא מספיק.

מדוע Ollama לא מספקת לי את טווח ההקשר המלא של 1M?

1M הוא המקסימום של המודל, לא ברירת המחדל של Ollama. Ollama מחילה טווח קטן בהרבה ומוחקת את ה-tokens הישנים ביותר ברגע שהשיחה חורגת ממנו, ללא הודעת שגיאה, מה שגורם לסוכן "לשכוח" את ההנחיות שלו. הגדירו את OLLAMA_CONTEXT_LENGTH בשירות ה-systemd, או העבירו את num_ctx בכל בקשה. העלו את הערך בהדרגה ובדקו שוב את ollama ps בכל פעם, כיוון שזיכרון ה-KV cache גדל בהתאם לטווח ועלול לדחוק שכבות מודל מחוץ ל-GPU.

האם השימוש המסחרי ב-Nemotron 3.5 Lightning הוא בחינם?

כרטיס המודל של NVIDIA מציב את המודל תחת רישיון OpenMDW-1.1 ומציין שהוא מוכן לשימוש מסחרי. זה תקף למשקולות שאתם מורידים ומריצים בעצמכם. זה לא מתייחס לתוכנות אחרות ב-stack שלכם, לכן בדקו בנפרד את הרישיונות של סביבת הסוכן ושל כל כלי שאתם מחברים אליו, וקראו את כרטיס המודל העדכני לפני שאתם מסתמכים על כך לצרכים חוזיים.