אירוח עצמי של 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 (קיצור של key value) אינו כזה: הוא גדל עם אורך ההקשר (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 לכל טוקן.

[
  {
    "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 דוחס את ה-key וה-value לוקטור לטנטי אחד בדרגה נמוכה, כך שהעלות האמיתית לכל טוקן נמוכה משמעותית מהדוגמה שחושבה. חברת Moonshot לא פרסמה את הממדים הלטנטיים, לכן לא אציין נתון למשתמש עבור K3 עצמו. מדדו את הנתונים שלכם במקום זאת: הפעילו את השרת עם --max-model-len קטן, עקבו אחר הזיכרון עם nvidia-smi, ואז העלו את המגבלה עד שהקצאת הזיכרון תיכשל.

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

שכבה 1: השכרת ה-cluster לפי שעה

זוהי השכבה היחידה שמריצה את 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 כפול מספר השעות כפול התעריף. מטרת הטבלה היא להציג את היחס. הרצה מתפרצת (bursting) של צומת עם 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

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

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

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

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

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

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

דרג 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

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 כלל. אותה חלוקה חלה על מודלים בעלי משקולות סגורות, שבהם אירוח עצמי של Claude אינו אפשרי ברמת המודל, והניהול (orchestration) הוא החלק היחיד שנמצא בשליטתך.

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

שרתי מחלקה כמו 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), כפול רמת המקביליות (concurrency), הוא העלות שממשיכה לגדול לאחר שכבר שילמת על המשקלים.
4. טוקנים לשנייה לכל דולר הם המספר היחיד שקובע את הדרג. כל מה שצוין לעיל הוא קלט לחישוב זה.

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

FAQ

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

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

כמה VRAM דורש Kimi K3?

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

האם קוונטיזציה מאפשרת ל-Kimi K3 להיכנס לצומת יחיד?

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

האם השכרת GPUs זולה יותר מה-API של Kimi K3?

רק בנפח עבודה גבוה וקבוע. בהנחה של 2.50 USD לשעת GPU, צומת של 8 GPUs שפועל ללא הפסקה עולה 14,400 USD בחודש, ובאותו סכום ניתן לרכוש כ-960 מיליון tokens של פלט לפי התעריף המפורסם של 15.00 USD למיליון. עליכם לשלם גם על שעות של חוסר פעילות, הורדת משקולות, ועל כוח האדם שמתחזק את ה-cluster. שכרו לפי שעה עבור עומסים מתפרצים, ובצעו השוואה מול נפח ה-tokens הנמדד שלכם במקום להסתמך על הערכה.

מה המשמעות של 104B פרמטרים פעילים עבור המהירות?

המשמעות היא שהחישוב האריתמטי לכל token הוא של מודל 104B, ולכן ה-throughput נמצא במחלקה הזו ולא במחלקה של 2.8T. אין לזה קשר לזיכרון: כל 2.8T הפרמטרים נשארים בזיכרון, כיוון שה-router יכול לקרוא לכל expert עבור כל token. השתמשו במספר הפרמטרים הפעילים כדי לחזות tokens לשנייה, ובמספר הכולל כדי לקבוע את גודל ה-VRAM.