ההפעלה החלקית מאפשרת למודל להשתייך לקטגוריית מודלים גדולה יחסית, אך לכוון לפרופיל חישוב של רשת פעילה קטנה בהרבה. היא אינה מבטלת את הצורך לאחסן ולנהל את המודל המלא, אך עשויה להפחית את כמות החישוב הנדרשת עבור כל טוקן שנוצר.
סוכנים אוטונומיים נוטים להפעיל את המודל פעמים רבות. משימה אחת עשויה לכלול בחירת כלים, חילוץ מידע מובנה, אימות, בדיקות מדיניות ועיצוב הפלט — שוב ושוב לאחר שהתוכנית הראשונית כבר נקבעה.
הפעלת מודל בקנה מידה של מודל־חזית עבור כל אחת מהקריאות האלה עלולה להגדיל את זמן התגובה ואת עלויות התפעול. Lightning נועד לטפל בחלק הצפוי והתדיר של התהליך, בעוד שמודל חזק יותר נשאר זמין למקרים עמומים, לחריגים ולהחלטות שדורשות חשיבה מורכבת.
ארכיטקטורה דו־שכבתית טיפוסית יכולה להיראות כך:
NVIDIA ממקמת את Nemotron 3 Ultra — מודל MoE עם 550 מיליארד פרמטרים בסך הכול ו־55 מיליארד פרמטרים פעילים — בצד של חשיבה מתקדמת ותזמור. בכך היא מחדדת את ההבדל בין שני המודלים.
כדי שמבנה כזה יעבוד, המערכת צריכה לדעת איזה מודל יקבל כל שלב. אין טעם לשלוח כל בקשה לאותו קצה API אם חלק מהמשימות פשוטות וחוזרות, ואחרות דורשות יכולת גבוהה יותר.
NeMo Switchyard הוא SDK לניתוב, שאינו תלוי בספק מסוים. הוא מאפשר לייצג בקשות, להגדיר יעדי מודלים ולנהל את הקריאות לספק או למזהה המודל שנבחר. בפועל, כך ניתן לבנות היררכיית מודלים שבה Lightning מטפל בקריאות שגרתיות, ומודל גדול יותר מקבל את המקרים המורכבים.
זו נקודה ארכיטקטונית חשובה: Lightning אינו בהכרח המעניין ביותר כצ'אטבוט עצמאי. הערך המרכזי שלו הוא כרכיב בתוך מערכת סוכנים מרובת־מודלים, שבה כל משימה מנותבת למודל המתאים לה.
לפי חומרי המודל, Lightning מציע קיבולת הקשר של עד מיליון טוקנים. הדבר עשוי להיות רלוונטי לסוכנים שמנהלים שיחות ארוכות, מעבדים מסמכים גדולים או שומרים מצב משמעותי לאורך משימה ממושכת. הקיבולת השימושית בפועל והביצועים יהיו תלויים במחסנית ההגשה ובהגדרות הפריסה.
גרסת NVFP4 מיועדת לפריסת הסקה ומשתמשת בקרנלים ייעודיים של NVIDIA בדורות GPU נתמכים. NVIDIA מציינת אפשרויות שימוש בתשתית מקומית, בתחנות עבודה, במרכזי נתונים ובענן, והמודל זמין גם דרך Hugging Face ושירותים מתארחים.
AWS מציינת כי Nemotron 3.5 Lightning זמין דרך SageMaker JumpStart, וניתן לפרוס אותו באמצעות קונסולת SageMaker או באמצעות SDK של Python. תיעוד NIM של NVIDIA מספק מסלול נפרד, מבוסס קונטיינר, עם דרישות מוגדרות למערכת ההפעלה, ל־CUDA, לדרייבר ול־Docker.
עם זאת, כדאי להיזהר מהכללה לגבי חומרה. צ'קפוינט מקוונטז עשוי להפוך את ההגשה למעשית יותר, אך האפשרות להפעיל את המודל על GPU יחיד תלויה בכרטיס הגרפי, בזיכרון, באורך ההקשר, בשיטת הקוונטיזציה, באצווה ובתוכנת ההגשה. טענות לגבי תמיכה רחבה בכל מחשב נייד או שולחני עם GeForce RTX, או לגבי חיסכון מדויק באחסון, צריכות להיבדק מול כרטיס המודל ומתכון הפריסה העדכניים.
NVIDIA ו־AWS מפרסמות עד פי ארבעה תפוקה ועד 30% קיצור בזמן השלמת משימה בעומסי עבודה ממוקדים של סוכנים. אלה אינן מדידות אוניברסליות של אינטליגנציה, וגם לא הבטחה לביצועים זהים בכל סביבת ייצור.
התוצאה בפועל עשויה להשתנות לפי:
לכן נכון יותר לבחון את Lightning לפי המדדים החשובים לסוכן הספציפי: דיוק בחילוץ, אמינות קריאות לכלים, עמידה בפלט מובנה וזמן השלמה מקצה לקצה — ולא רק לפי מספר הטוקנים לשנייה.
מחירי API יכולים להפוך את Lightning למעניין במיוחד עבור הסקה בנפח גבוה. DeepInfra מציגה מחיר של 0.05 דולר למיליון טוקני קלט ו־0.20 דולר למיליון טוקני פלט, במודל תשלום לפי שימוש וללא צורך לנהל תשתית GPU.
עם זאת, המחיר אינו תכונה קבועה של המודל. ספקים אחרים מציגים תעריפים שונים, והעלות האפקטיבית עשויה להשתנות לפי ספק, דיוק, מטמון ונתיב ניתוב. בהשוואה למודלים גדולים יותר יש לחשב את עלות התהליך כולו, כולל ניסיונות חוזרים, קריאות לכלים, ניתוב והקריאות שעדיין יופנו למודל חזק יותר.
Nemotron 3.5 Lightning הוא מודל עובד מהיר וגמיש למערכות סוכנים. הוא מתאים במיוחד לאפליקציות שמייצרות מספר גדול של קריאות דומות, ושבהן אפשר להגדיר את המשימה, להגביל אותה או לבצע למודל התאמה נוספת.
הוא אינו מוצג כתחליף אוניברסלי למודל תזמור גדול. תכנון מורכב, שיקול דעת בתנאי אי־ודאות ומשימות שבהן מחיר הטעות גבוה עשויים עדיין לדרוש מודל גדול יותר, כמו Nemotron 3 Ultra, או מערכת חזיתית אחרת.
במילים פשוטות: Lightning הגיוני בעיקר כשכבת הביצוע דלת־ההשהיה בתוך מערכת סוכנים שמנתבת משימות בין כמה מודלים. 30 מיליארד הפרמטרים הכוללים, כ־3 מיליארד הפרמטרים הפעילים, חומרי המודל הפתוחים, אפשרות ההסקה ב־NVFP4 ומגוון מסלולי הפריסה נועדו להפוך עבודה שגרתית של סוכנים למהירה וזולה יותר. ההבטחות מרשימות — אך לפני פריסה בייצור, צריך לבדוק אותן מול זרימת העבודה הספציפית של הארגון.