אירוח עצמי של Kimi K3: דרישות חומרה וחישובי זיכרון

מה נדרש לאירוח עצמי של Kimi K3

אירוח עצמי של Kimi K3 מחייב מציאת מקום עבור 2.8 טריליון פרמטרים. חברת Moonshot פרסמה את המשקולות הפתוחות בפורמט MXFP4, המהווה כחצי בייט לכל פרמטר; לכן, המשקולות לבדן מגיעות לכ-1.4 TB, עוד לפני הקצאת טוקן אחד של זיכרון מטמון (cache). כיום לא קיים מאיץ מסחרי שמסוגל להכיל זאת בעצמו. K3 הוא מודל מרובה צמתים (multi-node), ולכן התשובה עבור שרת בודד היא שלילית.

זהו פסק הדין. כל מה שמופיע להלן הוא החישוב העומד מאחורי קביעה זו, שכן החישוב הוא החלק שבו תשתמשו שוב בגרסה הבאה. מספר ספקי תשתית פרסמו מדריכי פריסה עבור K3 בשבועות שלאחר ההכרזה ב-17 ביולי 2026, וכל אחד מהם הניח שברשותכם כבר קיים אשכול (cluster). דף זה מתחיל מהצד השני: מה העלות, מה ניתן להריץ במקום, וכיצד לקבוע באיזו משתי האפשרויות הללו אתם נמצאים.

מספר הפרמטרים הכולל ומספר הפרמטרים הפעילים אינם זהים

K3 הוא מודל מסוג Mixture of Experts. מודל MoE מפצל את הרשת לתתי-רשתות רבות ומאפשר לנתב (router) לבחור כמה מהן עבור כל אסימון (token). כרטיס המודל מציין 2.8T פרמטרים בסך הכל ו-104B פרמטרים פעילים לכל אסימון, מתוך 896 מומחים מנותבים שמהם 16 מופעלים עבור כל אסימון נתון, לאורך 93 שכבות.

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

פרמטרים פעילים קובעים את עלות החישוב. אסימון עובר הכפלה דרך כ-104B פרמטרים, לכן קצב העבודה (throughput) הצפוי דומה לזה של מודל צפוף (dense) של 104B ולא של מודל 2.8T. זוהי הסיבה העיקרית לבניית MoE.

פרמטרים כוללים קובעים את עלות הזיכרון. הנתב עשוי לבחור בכל מומחה עבור כל אסימון, לכן כל מומחה חייב להיות טעון בזיכרון לפני הגעת הבקשה הראשונה. לא ניתן להחזיק 104B ב-VRAM ולהביא את השאר לפי דרישה, כיוון שהבאת הנתונים חייבת להסתיים במיקרו-שניות, בעוד חיבור PCIe מעביר עשרות גיגה-בייט בשנייה. אנשים אכן מנסים זאת. הזרמת מומחים מ-NVMe הופכת מודל שאמור להפיק עשרות אסימונים בשנייה לכזה שמפיק אסימון אחד בכל כמה שניות.

לסיכום, החישוב זול אך האחסון יקר. התאימו את החומרה לפי 2.8T. התאימו את ציפיות המהירות לפי 104B.

בייטים למשקל, ומקור הטרה-בייטים

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

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 אומן תוך מודעות לקוונטיזציה (quantisation aware) ושוחרר עם משקולות בפורמט MXFP4 ואקטיבציות בפורמט MXFP8, לכן השורה של 4-bit היא הרלוונטית. השורות שמעליה נועדו להמחשת קנה המידה: בפורמט bf16, אותו מודל היה דורש 5.6 TB. פורמט MXFP4 מאחסן גם scale משותף של 8-bit עבור כל בלוק של 32 משקולות, מה שמוסיף כ-6 אחוזים, ולכן המאגר שפורסם קרוב יותר ל-1.5 TB מאשר ל-1.4 TB נקיים.

זה סוגר את נתיב המילוט המקובל. "פשוט תבצע קוונטיזציה" לא עוזר כאן, כיוון שה-checkpoint ששוחרר הוא כבר ב-4-bit. ירידה ל-2-bit תביא את המשקולות ל-0.7 TB ותעלה בדיוק שאף אחד לא מדד ב-checkpoint הזה. עדיין תהיה רחוק מאוד מכל כרטיס בודד.

כמה יחידות GPU נדרשות עבור Kimi K3

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

התייחסו למספרים אלו כאל רף מינימלי, לא כיעד אופטימלי. הם מונים את משקלי המודל בלבד: ללא KV cache, ללא מאגרי הפעלה (activation buffers), ללא פרגמנטציה של ה-allocator, וללא מרווח לבקשה מקבילה שנייה. הם גם מניחים פיצול מקבילי שמתחלק באופן שווה, דבר ש-93 שכבות ו-896 מומחים לא תמיד מאפשרים.

ההנחיות הרשמיות שפורסמו נמצאות הרבה מעל רף המינימום. נכון לאוגוסט 2026, Moonshot ממליצה על supernode של 64 מאיצים או יותר, וה-cookbook של SGLang מציע תצורת H100 הבנויה מארבעה צמתים של 8-GPU, סך הכל 32 יחידות GPU ו-2,560 GB של זיכרון מצטבר, לעומת רף מינימלי של 18 כרטיסים. הפער הזה אינו בזבוז. הוא מיועד ל-KV cache, לזיכרון הפעלה, ולמרווח המאפשר לשרת לעבד בקשות רבות בו-זמנית. אפילו השורה האופטימית ביותר, 5 כרטיסים מסוג GB300, מתארת מכונה שרוב ספקי הענן אינם משכירים כ-SKU בודד.

מטמון ה-KV הוא החלק שמפתיע אנשים

המשקולות (weights) הן עלות קבועה. מטמון ה-KV (מפתח-ערך) אינו כזה: הוא גדל עם אורך ההקשר (context length) וגדל שוב עם כל משתמש בו-זמני. עבור מנגנון attention רגיל הנוסחה היא bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, ולאחר מכן מכפילים באורך ההקשר ובמספר המשתמשים בו-זמנית.

להלן דוגמה מחושבת, וזוהי דוגמה בלבד: 64 שכבות, 8 ראשי KV, ממד ראש 128, בפורמט fp8. זה נותן 2 64 8 128 1 = 131,072 בתים, כלומר 128 KiB לכל אסימון (token).

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

משתמש אחד עם הקשר של 128k עולה 16 GiB. משתמש אחד עם הקשר מלא של מיליון עולה 128 GiB, שזה יותר ממה שכרטיס בודד כלשהו יכול להכיל, עבור שיחה אחת.

K3 אינו משתמש ב-attention רגיל, והמספר האחרון הוא הסיבה לכך. 93 השכבות שלו מורכבות מ-69 שכבות KDA (ראשי תיבות של Kimi Delta Attention) ו-24 שכבות Gated MLA (מנגנון multi-head latent attention). KDA שומר על מצב רקורסיבי בגודל קבוע במקום מטמון שגדל עם כל אסימון, ו-MLA דוחס מפתח וערך לתוך וקטור לטנטי אחד בדרגה נמוכה (low rank), כך שהעלות האמיתית לכל אסימון נמוכה משמעותית מהדוגמה המחושבת. חברת Moonshot לא פרסמה את הממדים הלטנטיים, לכן לא אציין נתון למשתמש עבור K3 עצמו. מדדו את הנתונים שלכם במקום זאת: הפעילו את השרת עם --max-model-len קטן, עקבו אחר הזיכרון בעזרת nvidia-smi, ולאחר מכן העלו את המגבלה עד שהקצאת הזיכרון תיכשל.

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

שכבה 1: השכרת אשכול לפי שעה

זוהי השכבה היחידה שמריצה את K3 בעצמה. אינכם רוכשים את החומרה. אתם שוכרים אותה עבור השעות להן אתם זקוקים ועוצרים אותה לאחר מכן.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

התעריף הוא הערכה בלבד, לא הצעת מחיר. מחירי המחירון לפי דרישה למאיצי מרכזי נתונים נעו בערך בין 2 ל-5 דולר לשעת GPU לאורך שנת 2026, וקיבולת שמורה זולה יותר. קחו את המספר האמיתי של הספק שלכם ובצעו את הכפל מחדש: מספר ה-GPUs כפול מספר השעות כפול התעריף. מטרת הטבלה היא להציג את היחס. הרצה מתפרצת של צומת עם 8 GPUs למשך ארבע שעות ביום עולה 2,400 דולר בחודש, בעוד השארת תצורת 32 ה-GPUs בגודל SGLang פועלת עולה 57,600 דולר.

שני השרתים המרכזיים מפרסמים פקודת הפעלה בכרטיס המודל.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

אף אחת מהפקודות הגולמיות אינה מה שמריצים באשכול אמיתי. הוסיפו את דגלי המקביליות התואמים לחומרה שלכם: SGLang משתמש ב---tp-size עבור מקביליות טנזורים וב---ep-size עבור מקביליות מומחים, ומכפלתם חייבת להיות שווה למספר ה-GPUs שברשותכם בפועל.

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

curl http://127.0.0.1:30000/v1/models

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

הכשל הנפוץ ביום הראשון הוא סביבת זמן ריצה ישנה יותר מהמודל. K3 שוחרר עם KDA ושכבת MoE חדשה שגרסאות ה-vLLM וה-SGLang היציבות לא כללו בעת ההשקה, והתסמין הוא יציאת השרת במהלך העלייה עם שורה בתבנית Model architectures [...] are not supported for now. שום שינוי בתצורה לא יתקן זאת, כיוון שהקוד להרצת שכבות אלו אינו קיים בגרסת הבנייה שלכם. התקינו את גרסת ה-nightly המצוינת בכרטיס המודל, או המתינו לגרסה הרשמית הכוללת אותה.

הערה אחת בנושא עלויות שתופסת משתמשים רבים: המונה מתחיל לפעול ברגע שהמופע (instance) עולה, לא כשהמודל מוכן. הורדה של 1.5 TB במהירות 1 GB/s אורכת כ-25 דקות של זמן אשכול לפני יצירת הטוקן הראשון. אחסנו את המשקולות בנפח (volume) ששורד את המופע, כך שההרצה השנייה תתחיל תוך דקות.

דרג 2: הרצת מודל קטן על מאיץ יחיד

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

כלל ההתאמה הוא אותה נוסחה בקנה מידה קטן: מספר הפרמטרים כפול בייטים לכל משקל, בתוספת ה-KV cache, בתוספת כ-2 GB של תקורה בזמן ריצה, חייבים להיכנס בתוך ה-VRAM שלכם. ב-4-bit מדובר בערך בחצי בייט לפרמטר, מה שמאפשר שילובים נוחים:

• כרטיס 16 GB: מודל 7B ב-4-bit עם מקום להקשר (context) ארוך.
• כרטיס 24 GB: מודל 14B ב-4-bit.
• כרטיס 48 GB: מודל 32B ב-4-bit.
• כרטיס 80 GB: מודל 70B ב-4-bit, או מודל MoE מסדר גודל של 30B ב-8-bit.

כל שילוב לעיל מניח בקשה אחת בכל פעם. ברגע שאדם שני שולח הנחיה (prompt), כל slot מקבילי דורש KV cache משלו; זהו הפשרה ש-הגדרות NUM_PARALLEL ו-MAX_QUEUE ב-Ollama מבצעות עבורכם בין slots מקביליים, בקשות בתור וה-VRAM שנותר לכם.

Ollama הוא הדרך הקצרה ביותר לשרת עובד על שרת VPS עם GPU מחובר:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run מוריד את המודל בשימוש הראשון, ואז מעביר אתכם לשורת פקודה. תג (tag) שאינו קיים יחזיר Error: model "..." not found, לכן העתיקו תגים מדף הספרייה במקום להקליד אותם מהזיכרון. המדריך המלא, כולל יחידת systemd וגישה מרחוק, נמצא ב-הרצת Ollama על גבי VPS.

llama.cpp מעניק לכם שליטה רבה יותר על קוונטיזציה (quantisation) ועל פריקה (offload):

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 מבקש להעביר כל שכבה ל-GPU. קראו את לוג הטעינה: הוא מדפיס כמה שכבות נפרקו. שכבות שזולגות ל-RAM של המערכת רצות ברוחב הפס של ה-RAM במקום ברוחב הפס של ה-HBM, לכן מהירות היצירה צונחת בסדר גודל ברגע שהמודל מפסיק להיכנס לזיכרון. הפשרות בין שני הכלים מכוסות ב-השוואה בין Ollama ל-llama.cpp.

דרג 3: API מאוחסן, ניהול תזמור (orchestration) בהתקנה עצמית

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

נקודת הקצה (endpoint) תואמת ל-OpenAI, לכן לקוח קיים יעבוד לאחר שתשנה את ה-base URL.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

מפתח תקין מחזיר אובייקט JSON עם מערך choices. שגיאת 401 מציינת שהמפתח שגוי או שהקידומת Bearer חסרה. שגיאת model-not-found מעידה בדרך כלל על כך שה-id השתנה, כיוון שספקים מוציאים משימוש מזהי מודלים בין נקודות ביקורת (checkpoints).

כעת נבחן את נקודת האיזון, תוך שימוש בתעריף השכירות שהונח לעיל. צומת (node) עם 8 מעבדים גרפיים (GPU) הפועל ללא הפסקה עולה 14,400 דולר בחודש. במחיר של 15.00 דולר למיליון טוקנים של פלט, אותו סכום כסף יקנה כ-960 מיליון טוקנים של פלט מה-API. כדי להשיג כדאיות כלכלית, עליך לייצר קרוב למיליארד טוקנים של פלט בחודש, בערך 30 מיליון ביום, ולשמור על ה-cluster עמוס כל הזמן, כיוון שמעבדים גרפיים במצב המתנה מחויבים באותו תעריף כמו מעבדים פעילים. עומסי עבודה של סוכנים (agents) עתירי הנחיות (prompts) מרחיקים את נקודת האיזון עוד יותר: הקשר (context) חוזר מחויב לפי תעריף פגיעה במטמון (cache-hit) של 0.30 דולר למיליון, במקום תעריף החמצה במטמון (cache-miss) של 3.00 דולר.

מה שאתה מתקין באופן עצמי בדרג זה הוא כל מה שמסביב למודל: שער (gateway) שמחזיק את מפתח ה-API כך שהוא לעולם לא מגיע ללקוח, לוגים של בקשות ותגובות, ניסיונות חוזרים (retries), הגבלות קצב (rate limits) ותקציבים לכל משתמש. רכיבים אלו רצים על VPS קטן ללא צורך ב-GPU כלל. אותה חלוקה חלה על מודלים בעלי משקולות סגורות (closed weights), שבהם אירוח עצמי של Claude אינו אפשרי ברמת המודל, וניהול התזמור הוא החלק היחיד שנמצא בשליטתך.

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

שרתי vLLM ו-SGLang שייכים לשכבה 1. הם קיימים כדי לשרת בקשות רבות בו-זמנית, תוך שימוש ב-continuous batching וב-paged KV cache, לצד הקבלה של טנזורים ומומחים (tensor and expert parallelism) הפרוסה על פני כמה צמתים. הם מניחים קיום של מאיצי מרכזי נתונים וחיבור מהיר ביניהם. על כרטיס צרכני בודד, הם כבדים יותר להתקנה ומספקים יתרון מורגש מועט בלבד.

llama.cpp ו-Ollama שייכים לשכבה 2. הם מיועדים למכונה בודדת, לשימוש בקוונטיזציה מסוג GGUF, להעברת עומס ל-CPU כאשר המודל אינו נכנס בזיכרון, ולרמת מקביליות נמוכה. טכנית, llama.cpp יטען מודל MoE עצום על ידי שמירת רוב השכבות ב-RAM של המערכת, ועבור מודל של 2.8T, קצב העבודה בנתיב זה נמדד בשניות לכל טוקן. זה מוכיח שהקובץ תקין מבחינת ניתוח (parsing), אך זהו אינו שירות שניתן להציע למשתמשים. ההשוואה המלאה נמצאת ב-Ollama מול vLLM, והיא אינה משתנה בהתאם למודל: השאלה היא תמיד האם אתם משרתים משתמשים רבים על חומרה משותפת, או משתמש אחד על החומרה שלכם.

ארבעת המספרים ששורדים את נקודת הביקורת הזו

1. מכפלת סך הפרמטרים בבתים לכל משקל קובעת את רף הזיכרון המינימלי. שום דבר לא ירוץ מתחת לרף זה, ושום טכניקת קוונטיזציה לא תשנה זאת משמעותית ברגע שהגרסה היא כבר 4-bit.
2. מספר הפרמטרים הפעילים קובע את מחלקת התפוקה. מודל MoE של 2.8T עם 104B פרמטרים פעילים מחושב כמו מודל של 104B.
3. ה-KV cache לכל טוקן, כפול אורך ההקשר (context length), כפול רמת המקביליות, הוא העלות שממשיכה לגדול לאחר שכבר שילמת על המשקלים.
4. מספר הטוקנים לשנייה לכל דולר הוא המספר היחיד שקובע את הדרג. כל מה שצוין לעיל הוא קלט לחישוב זה.

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

FAQ

האם ניתן להריץ את Kimi K3 על גבי GPU בודד?

לא. המשקולות תופסות כ-1.4 TB בדיוק MXFP4 שבו Moonshot משחררת את המודל, בעוד המאיץ הבודד הגדול ביותר הקיים למכירה מכיל 288 GB. מודל MoE אינו יכול להזרים מומחים לא פעילים מהדיסק במהירות סבירה, כיוון שהנתב (router) עשוי לבחור בכל מומחה עבור כל token, וזמן האחזור של PCIe ארוך בהרבה ממה שמאפשר תקציב ה-token. הפריסה הקטנה ביותר ההגיונית עבור K3 היא צומת (node) מרובה-GPU, והמתכונים שפורסמו משתמשים ב-32 מאיצים או יותר.

כמה VRAM דורש Kimi K3?

יש להתחיל ב-1.4 TB עבור המשקולות בלבד, שהם 18 כרטיסי H100 80GB או 5 כרטיסים מסוג GB300. לכך יש להוסיף זיכרון עבור KV cache וזיכרון הפעלות (activation memory). נכון לאוגוסט 2026, Moonshot ממליצה על 64 מאיצים או יותר, וספר המתכונים של SGLang מפרסם תצורה של 32 כרטיסי H100 עם סך של 2,560 GB, לכן יש להתייחס לנתון המשקולות כרף תחתון ולא כדרישה מלאה.

האם קוונטיזציה מאפשרת להריץ את Kimi K3 על צומת בודד?

לא באופן מעשי. ה-checkpoint ששוחרר הוא כבר ב-4-bit עם אימון מודע לקוונטיזציה, כך שהחיסכון הקל כבר בוצע. הפחתה נוספת ל-2-bit מביאה את המשקולות ל-0.7 TB, שזה עדיין יותר מפי שניים מהקיבולת של הכרטיס הגדול ביותר, ועלות הדיוק של 2-bit טרם נמדדה במודל זה.

האם השכרת GPUs זולה יותר משי