מהו DeepInfer? מנוע האינפרנס של DeepSeek, והחלקים שהיא לא שחררה

DeepInfer הוא מסגרת האינפרנס ש-DeepSeek פרסמה ב-16 באוקטובר 2026 תחת Apache-2.0, והיא מגישה בדיוק מודל אחד: DeepSeek-V4.1-Flash, כאשר DeepSeek-V4.1-Flash-1017 מהווה את נקודת ה-checkpoint המוגדרת כברירת מחדל. יש להבין קודם כל את היקף המודל הבודד הזה, משום שהוא מסביר כמעט כל דבר אחר במאגר. זו אינה מסגרת הגשה כללית שבמקרה כוללת תצורה של DeepSeek. זהו מסלול הקוד ש-DeepSeek מריצה בייצור, מצומצם לחלקים שניתנים להכללה, והוא כן שקוף לגבי הצמצום: הרשימה של ה-README עצמו — מה נדרש לשירות אינפרנס מלא ומה השחרור הזה אינו כולל — מציינת מערכת KV cache, פירוק VE/Prefill/Decode, ואיזון עומסים בין רפליקות data-parallel. מה שמקבלים הוא מסלול החישוב — קרנלים, מקביליות, פענוח ספקולטיבי, תזמון, פלט מובנה. מה שלא מקבלים הוא שכבת האחסון והניתוב שהופכת את מסלול החישוב לזול לתפעול בקנה מידה. DeepSeek מסבירה למה: הרכיבים האלה כרוכים באופן הדוק בתשתית פנימית, ולכן העיצוב מתואר במאמר שפורסם בעוד הקוד נשאר פנימי.

מה נמצא בפועל במאגר

רשימת התכונות שפורסמה נקראת כמו סיור בצווארי הבקבוק של מתן שירות למודל גדול מסוג תערובת מומחים. יש את ספריות הקרנל ש-DeepSeek שחררה בעבר — FlashMLA עבור קשב, DeepGEMM עבור כפל המטריצות, DeepEP עבור תקשורת מקבילית בין מומחים, וכן TileKernels ו-DeepSelect. יש את סכימת המקביליות: הקשב פועל כמקביליות נתונים עם מקביליות הקשר מאוזנת, חלק ה-MoE פועל כמקביליות מומחים עם מאזן עומסים למקביליות מומחים. יש את DSpark, מחסנית הפענוח הספקולטיבי, עם אורכי אימות שמתוזמנים ולא קבועים. יש את SWA bounded replay, המנגנון שמונע ממטמון קשב עם חלון הזזה לכפות חישוב מחדש מלא בכל החמצת מטמון. יש תזמון אצוות אסינכרוני, הסקה שאינה תלויה באצווה עם דגימה דטרמיניסטית, ופלט מובנה המוגבל על ידי regex, סכימת JSON או EBNF.

נקודת הכניסה קטנה בכוונה. לאחר הגדרת DEEPINFER_ACCELERATOR ל-nvidia או למקבילה של Ascend והרצת build.sh, המאגר כולל את examples/offline_inference.py, שמריץ את צ'קפוינט ברירת המחדל מקצה לקצה. DEEPINFER_HF_MODEL_DIR מפנה אותו לספריית משקלים אחרת. הבנצ'מרקים שפורסמו נמדדו על ארבעה GPUs מסוג SM100 עבור prefill ועל 64 GPUs מסוג SM100 עבור decode, וזהו המבנה של הפריסה שלשמה נכתב המנוע, ולא הדגמה בגודל מחשב נייד.

ה-README גם מציין מהיכן הגיע הקוד, וזה שווה לדעת לפני שקוראים אותו. המנוע נבנה במקור בעיקר על vLLM, עם השראה תכנונית מ-SGLang ומ-TensorRT-LLM. המורשת הזו ניכרת במבנה — המתזמן, ממשק ה-paged attention ומסלול הדגימה ייראו מוכרים לכל מי שקרא את הפרויקטים האלה — והיא מסבירה מדוע הגרסה שפורסמה היא fork של serving stack ולא ארכיטקטורה שנכתבה מאפס. מה ש-DeepSeek הוסיפה הוא החלק הייחודי למודל שלה: הפריסה המפורקת, ה-wide expert parallelism עם ה-balancer שלו, ה-sliding-window replay ו-DSpark.

מה שהוא לא מכיל, ולמה זה חשוב יותר

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

• מערכת מטמון ה-KV. שימוש חוזר בקידומות הוא המקום שבו נמצא רוב הכסף בעומס עבודה של צ'אט, מפני שפגיעת מטמון מחליפה prefill. בלי מאגר מטמון, כל בקשה מחשבת מחדש את הפרומפט שלה. התיעוד של DeepSeek עצמה מתאר את המאגר שהיא משתמשת בו: אשכול 3FS ייעודי ולא זיכרון מקומי של המארח, בדיוק כדי שכל מכונת prefill תוכל לפגוע בכל קידומת, וקיבולת המטמון תוכל להיות מותאמת בקנה מידה באופן בלתי תלוי במחשוב.

• פיצול VE/Prefill/Decode. ה-README מציין שרוב הפונקציונליות בצד המנוע כבר קיימת במהדורה; מה שחסר הוא הפריסה. פיצול מקוד הראייה, ה-prefill וה-decode מאפשר לך להתאים את הגודל של כל שלב לצוואר הבקבוק שלו ולשלוט בזמן עד לטוקן הראשון בנפרד מהזמן בין טוקנים. זו החלטת תשתית, לא דגל.

• איזון עומסים בין רפליקות מקבילות-נתונים. DeepSeek מפעילה ארבעה מאזני עומסים — prefill, decode, vision encoder ו-expert-parallel — ומתארת את כל הארבעה במסמך. שום חלק מהיגיון הניתוב לא נכלל במשלוח. בלעדיו, צי רפליקות אינו טוב יותר מהראוטר שתציבו לפניו, וראוטר נאיבי מסוג round-robin יהרוס את שיעור הפגיעות במטמון שהמאגר נבנה כדי להגן עליו.

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

שער החומרה הוא המסנן האמיתי

DeepInfer מיועד ל-NVIDIA SM100 ול-Huawei Ascend 950. אין מסלול Ampere ואין מסלול Hopper, מה שמוציא מכלל שימוש את רוב ה-GPUs ברוב האשכולות כיום. שאר שרשרת הכלים ספציפית באותה מידה: Linux בלבד, GCC 13 ואילך, Python 3.12, CUDA 13 עבור NVIDIA או CANN 9.2 עבור Ascend. ואין מהדורות כלל — למאגר היו אפס מהדורות שפורסמו כאשר נקרא ב-21 באוקטובר 2026, כך שאין מה להוריד ואין מה לנעוץ. משכפלים אותו ובונים אותו מול שרשרת הכלים שלכם.

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

צורת הפריסה ש-DeepSeek מריצה בפועל

מסמך הארכיטקטורה הוא המקום שבו ההנחות של המאגר נעשות גלויות לקריאה. המערכת מפורקת למקודד חזותי, prefill ו-decode, וכן לצמתי אחסון ייעודיים. ה-prefill משתמש במקביליות מומחים של 2 עד 8 עם מקביליות נתונים תואמת, ובוחר בתצורה הקטנה ביותר שה-HBM מאפשר. ה-decode הולך בכיוון ההפוך: מקביליות מומחים ומקביליות נתונים של 64 עד 128, שאותה DeepSeek מכנה Wide-EP, תוך שימוש בתצורה הגדולה ביותר שה-GPU הזמינים מאפשרים. מקביליות טנזורים ומקביליות הקשר אינן בשימוש כלל. המקודד החזותי פועל עם GPU אחד לכל מופע, כאשר מומלצים GPUs זולים יותר, כי המקודד אינו המקום שאליו הולך הכסף.

הפריסה הקטנה ביותר שיש בה היגיון נובעת מהמספרים האלה. מעבד GPU אחד ל-prefill ומעבד GPU אחד ל-decode יפעלו, ובפועל היחס בין שתי הקבוצות הוא בערך אחד לאחד. אבל מכיוון ש-decode דורש 64 מעבדי GPU או יותר כדי להשיג את יתרון ה-expert-parallel, היחידה היעילה הקטנה ביותר היא 64 מעבדי GPU ל-prefill ועוד 64 מעבדי GPU ל-decode. זה המספר שכדאי לזכור כשקוראים כל טענה לגבי היעילות של DeepInfer: הנתונים מתארים פריסה של 128 מעבדי GPU, ומחציתה היא שלב אחד.

פיצול ה-prefill וה-decode בין מרכזי נתונים אפשרי מבחינה טכנית מכיוון ש-DeepSeek-V4.1-Flash מדחיס את מטמון ה-KV שלו באופן משמעותי, והפריסה של DeepSeek עצמה אכן מציבה צמתי הסקה במרכזי נתונים שונים אך סמוכים. התקציב הוא בערך 400 Gbps של קישוריות לכל שמונה GPUs, והמסמך גלוי לגבי עלות האמינות — קל לחתוך סיבים בין בניינים.

למה ה-decode פרוס כל כך רחב?

מקביליות מומחים רחבה היא הבחירה בעלת ההשלכות הרבה ביותר בתכנון, וקל לפרש אותה בטעות כתחבולת סקיילינג. בשכבה מסוג תערובת מומחים, כל אסימון נוגע במספר קטן של מומחים, ולכן העלות של שלב פענוח נשלטת על ידי העברת משקלי מומחים ואקטיבציות ולא על ידי עצימות אריתמטית. פריסת המומחים על פני 64 או 128 GPUs מפחיתה את תעבורת הזיכרון לכל שלב שכל GPU תורם, מה שמעלה את מספר האסימונים לשנייה אם — וזה התנאי — העומס בין המומחים נשאר אחיד. לשם כך נועד מאזן העומסים המקבילי בין מומחים.

ההגדרות של DeepSeek ספציפיות מספיק כדי להעתיק אותן. עבור prefill, כל GPU מחזיק ארבעה מומחים עודפים מעבר לאלה שהוא עצמו מחזיק, סטטיסטיקות נאספות על פני חלון של 100 צעדים, ומומחים מוקצים מחדש כל 1,000 צעדים, כאשר המשקלים מעורבבים מחדש בתוך הקבוצה דרך זיכרון משותף NVLink. חוסר האיזון שנמדד — הראנק האיטי ביותר חלקי הממוצע — יצא 1.074 עבור תצורת EP4/DP4 ו-1.045 עבור EP2/DP2. עבור decode ההגדרות נמתחות: מומחה עודף אחד לכל GPU, חלון סטטיסטיקות של 1,000 צעדים, הקצאה מחדש כל 10,000 צעדים, וחוסר איזון נמדד של 1.090. ההבדל בין השניים הוא העיקר. prefill רואה עבודה מתפרצת והטרוגנית וזקוק לאיזון מחדש מהיר; decode רואה זרם יציב ויכול להרשות לעצמו חלון ארוך, כך שהוא מאזן מחדש לעיתים רחוקות וכמעט לא משלם על הפריבילגיה.

לצד הניתוב יש אותו אופי. בקשות Prefill מחולקות לפי אורך ההקשר הכולל לארבע שכבות — מתחת ל-16K, 16 עד 64K, 64 עד 256K, ו-256K ומעלה — ומנועים מוקצים לשכבות בהתאם לחלקן של כל שכבה בביקוש למחשוב בסבב הקודם. בתוך GPU, גודל המקטע בכל שלב Prefill אינו קבוע: מודל עלות ריבועי מותאם חוזה כמה זמן יימשך שלב בהינתן מספר אסימוני הרצף והקידומת שכבר חושבה, והמתזמן מוצא את המקטע הגדול ביותר שנכנס לתקציב של 32,768 אסימונים בתוך הזמן שנותר. מאזן הפענוח מאזן שני ממדים בבת אחת — מספר הבקשות ואורך מטמון ה-KV הכולל — ושולח בקשות קצרות ל-GPU-ים עם מקביליות נמוכה ומטמון ארוך, ובקשות ארוכות ל-GPU-ים עם מטמון קטן. הסיכום של DeepSeek עצמה לגבי כמה כל זה נותן: בערך 80 אחוז מבנצ'מרק לא מקוון מאוזן לחלוטין.

המטמון, ושאלת שלושת הימים

מטמון ה-KV מתגורר באשכול 3FS ייעודי, ולא בזיכרון המארח המקומי, והחלטה זו מכתיבה את שאר תכנון האחסון. הנתונים נשמרים בקידוד מחיקה 10+2, כך שכל קבוצת קידוד שורדת שני כשלי צמתים בו-זמניים; קריאה שולחת בקשות לכל 11 הצמתים בקבוצה, ודי בכל 10 תגובות כדי לפענח. תהליך עובד לאיסוף אשפה פועל בכל צומת אחסון ומפנה לפי LRU לאחר חציית סף. השרת המומלץ כולל 20 כונני מצב מוצק בנפח 30.73 TB כל אחד, ועומד בלפחות 40 GB/s בקריאה ו-5 GB/s בכתיבה, בגודל שנועד לשמור בערך 24 שעות של נתונים לכל שרת. בפועל האשכול פועל בכ-14.4 TB של מטמון לוגי לכל GPU מקוון, כאשר הקיבולת הפיזית גדולה מכך.

משך השהות הוא המקום שבו הפשרה נעשית גלויה. אין לוגיקת תפוגה בצד המטמון; ה-TTL מוגדר בצד האחסון לשלושה ימים עבור תעבורת סוכנים ושבעה ימים עבור תעבורת צ'אטבוטים, באשכול המחזיק בכ-100 פטה-בייט של אחסון במצב מוצק. הפיצול קיים משום שלתעבורת הצ'אטבוטים יש זנב ארוך כבד בהרבה של פגיעות — כמות קטנה של מטמון נקראת שוב ושוב, ולכן איבודה עולה בשיעור הפגיעות הכולל יותר ממה שהנפח מרמז. העלות שנמדדה אצל DeepSeek מקיצור משך השמירה של הצ'אטבוט לשלושה ימים היא 0.5 עד 1 אחוז משיעור הפגיעות במטמון. זהו מספר קטן שבמקרה מייצג כמות גדולה של מילוי מקדים שמחושב מחדש.

קשב חלון מחליק מקבל מטמון נפרד עם כללים שונים. מטמון ה-SWA אינו נכנס לבלוקים המחולקים לעמודים; כל רצף תופס משבצת אחת בגודל קבוע בזיכרון המארח, ועבור DeepSeek-V4.1-Flash השכבות המאוחסנות הן 20 הראשונות. רק אזור זה נשמר — 20 שכבות על 134 טוקנים על 528 בתים, שהם 1,415,040 בתים לכל רצף בפורמט MXFP8. שום דבר לא עובר לאשכול האחסון; הוא נשאר בזיכרון של המכונה שיצרה אותו, עם מדריך בזיכרון המתעד איזו מכונה מחזיקה מה, ופגיעה חוצת-מכונות מושכת אותו בחזרה דרך VLAN של 400 Gbps.

שני המנגנונים שמפיקים את מספרי הכותרת

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

בצד המפענח נמצא החיסכון הגדול. בארכיטקטורה הזו, מטמון הבלוקים של שכבות המפענח מוקרן מהמצב החבוי של שכבת המקודד האחרונה, כך שרק מטמון ה-SWA של המפענח צריך להיות מחושב בכל שכבה — ושחזורו במדויק היה מחייב להעביר את 2,560 הטוקנים האחרונים דרך 20 שכבות מפענח בכל prefill. במקום זאת, הרצה חוזרת של 128 טוקנים והשימוש בתוצאה לפענוח בלבד, במקום לתת לה להיכנס למטמון הקידומת, מפחיתים כמעט בחצי את סך חישוב ה-prefill. שינוי בודד זה שווה יותר מרוב אופטימיזציות הקרנל, וזה מסוג הדברים שרק צוות שבבעלותו ארכיטקטורת המודל יכול לעשות.

התרומה של DSpark קטנה יותר ושגרתית יותר. לטוקני טיוטה יש הסתברויות קבלה שונות בהתאם לבקשה ולמיקום, ולכן אימות של חמישה טוקני טיוטה קבועים בכל צעד מבזבז מחשוב על טוקנים שיידחו. ראש חיזוי ביטחון חוזה את שיעור הקבלה של כל טוקן טיוטה, והמתזמן ממיין את הטיוטות לפי תשואה צפויה ומאמת רק את הקידומת שממקסמת את התפוקה. בסביבת ייצור מודל הטיוטה עדיין מייצר חמישה טוקנים בכל צעד; מספר הטוקנים המאומתים יורד מ-5.00 ל-בין 3.2 ל-4.4, קיצוץ של כ-30 אחוז, בעוד שהאורך המקובל כמעט לא משתנה — 3.29 לעומת 3.20. על סמך נתוני מדד EP64/DP64, מדובר בתוספת תפוקה של 4 עד 7 אחוזים בסביבות 60 רצפים במקביל לכל דרג. ב-60 בדיוק, התפוקה לכל דרג עולה מ-13,730 ל-14,466 טוקנים לשנייה. מתחת לכ-16 רצפים במקביל הטכניקה מהווה הפסד נטו קטן, וכדאי לדעת זאת לפני אימוצה לפריסה בעלת תעבורה נמוכה.

מה המשמעות של הנתון של 155 טריליון

המספר המצוטט ביותר בהקשר לשחרור הזה הוא אשכול בודד המגיש 155 טריליון טוקנים ביום, בהכנסה כוללת של 38 דולר ארה"ב לשעת GPU ב-valley pricing. שני החלקים מדווחים על ידי הספק, ואף אחד מהם אינו מדד שאפשר לשחזר, מה שלא הופך אותם ללא מעניינים — נתון הכנסה לשעת GPU הוא סוג שונה מהותית של טענה מנתון תפוקה, משום שהוא מקפל לשורה אחת ניצול, תמחור ושיעור פגיעות מטמון. זה גם הנתון שסביר ביותר שיצוטט ללא ההסתייגויות שלו, ולכן ההסתייגויות ראויות להירשם: אשכול אחד, valley pricing, הכנסה ולא עלות, וסכום מצטבר על פני prefill, decode ו-vision encoder.

שתי חשיפות קטנות יותר שימושיות יותר באופן ישיר. גרעין הפענוח FlashMLA במאגר הציבורי חסר אופטימיזציית אסמבלי מכווננת ביד שיש בגרסה הפנימית, מה שהופך אותו לאיטי ב-5 עד 10 אחוזים בבידוד; DeepSeek מציינת שהביצועים מקצה לקצה נבדלים בלכל היותר 5 אחוזים. ומודל הטיוטה הפנימי לפענוח ספקולטיבי חדש יותר מהמפורסם, כאשר הפער בביצועים מתואר כקטן. שתי ההצהרות קובעות ציפייה לגבי כמה מהביצועים המפורסמים צד שלישי יכול להשיג באמצעות העתקת הקוד, והתשובה היא: את רובו, בתנאי שהחומרה מתאימה.

המאגר, כפי שהוא

צילום המסך שלמעלה נוצר ב-21 באוקטובר 2026 ומראה שהדף מציג 16.3 אלף כוכבים. ה-API של GitHub, שנשאל באותו יום, החזיר 16,590 כוכבים, 1,649 פורקים ו-176 issues פתוחים, כאשר ה-Issues מושבתים והדיון מנותב ל-GitHub Discussions במקום. מאז מספר הכוכבים המשיך לטפס, ולכן יש לקרוא כל נתון כאן כחותמת זמן ולא כתכונה של הקוד. תנועה בסדר גודל כזה בפחות משבוע אומרת יותר על העניין במערך ההגשה של DeepSeek מאשר על מוכנות הקוד, וספירת אפס המהדורות אומרת את השאר.

אם יש לך כוונה להריץ את זה בעצמך

הסיכום הכנה הוא ש-DeepInfer שווה קריאה מדוקדקת וקשה לתפעול. ארבע שאלות יגידו לך אם הוא מתאים.

• האם יש לך SM100 או Ascend 950? כל השאר בשרשרת הכלים נגזר מזה. בלי המאיץ הנכון, המספרים שפורסמו אינם תקפים, והגרסאות שהוסבו על ידי הקהילה אינן מאומתות בהיקף ייצורי.

• האם ניתן להריץ 64 מעבדי GPU לפענוח בתחום תקשורת אחד? מקביליות מומחים רחבה אינה אופטימיזציה שאפשר לדלג עליה; זו התצורה שנתיב הפענוח תוכנן סביבה. מתחת לרמה הזו, אתם מריצים מערכת אחרת עם אותו שם.

• האם כבר יש לך מטמון קידומות? אם לא, אתה משווה את מסלול החישוב של DeepInfer מול סטאק מתחרה שמגיע עם אחד כזה, וההשוואה תיראה גרועה יותר ממה שהעיצוב ראוי לו.

• האם תוכל להרשות לעצמך לכתוב את שכבת הניתוב? חלוקת prefill לדליים, איזון decode והקצאה מחדש של מומחים מתוארים מספיק טוב כדי לממשם מחדש, ומימוש מחדש כזה הוא שבועות של עבודה שהמאגר לא עושה עבורך.

אם אתה מעדיף שלא להחזיק באף אחד מהדברים שלעיל

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

ההשוואה שצריך לעשות אינה איזה מנוע מהיר יותר באופן מופשט, משום שהנתונים המפורסמים הם מדידות שדווחו על ידי הספק על חומרה שלרוב הקוראים אין. היא האם עומס העבודה הוא כזה שבו TTL של מטמון של 3 ימים ובריכת פענוח של 64 GPU משנים את המחיר, או כזה שבו בקשה כל כמה שניות דרך API פשוט זולה יותר מכל הפעולות שתוארו לעיל. במקרה השני — שהוא רוב המקרים — הכמות הנכונה של DeepInfer לשימוש היא אפס, והכמות הנכונה לקרוא היא כולה. התחל מדף המודל DeepSeek V4.1 Flash אם אתה רוצה את נקודת הקצה; התחל מה-README של המאגר אם אתה רוצה לדעת מה נקודת הקצה עושה.