ה-LLM המקומי הטוב ביותר לקידוד באוגוסט 2026, לפי VRAM: Qwen3-Coder 30B, gpt-oss-20b, Qwen 2.5 Coder 7B

ה-LLM המקומי הטוב ביותר לקידוד באוגוסט 2026 נקבע לפי ה-VRAM שלך לפני כל דבר אחר. אם יש לך כרטיס 24GB — RTX 3090 או 4090 — הרץ Qwen3-Coder-30B-A3B-Instruct: 30B פרמטרים בסך הכול עם רק 3.3B פעילים לכל טוקן, חלון הקשר של 262,144 טוקנים, והמספרים המקומיים הטובים ביותר לקידוד שאנחנו יכולים לאמת. ב-16GB זה gpt-oss-20b, מודל ה-Mixture-of-Experts של O​penAI ברישיון Apache-2.0, שנכנס כולו ל-GPU בכ-14GB ומגיע לכ-140 טוקנים לשנייה. ב-8GB זה Qwen2.5-Coder-7B, סוס העבודה האמין בכ-4.7GB. שאר הדף הזה הוא ההסבר, המספרים הנמדדים, והמצבים הספציפיים שבהם כל אחת מהבחירות האלה שגויה.

מה העמוד הראשון עושה נכון — ומה שהוא מדלג עליו

הדירוג הנוכחי עבור "המודל המקומי הטוב ביותר לקידוד" הוא תערובת של פיסה אחת שימושית באמת והרבה חוזק תחומי. המדריך של Tembo (5 ביוני 2026) תופס את הצורה הנכונה — הוא מארגן לפי רמות של 8GB / 12–16GB / 24GB ובוחר במשפחת Qwen Coder — אבל הוא לא מפרסם ציוני benchmark למודלים המקומיים, לא נתוני tokens-per-second, לא גדלי חלון הקשר, ולא בחירות Apple Silicon לפי RAM. כלי הערכה ב-GitHub (gauravvij/local-llm-coding-eval) כולל נתונים אמיתיים אבל אין בו מסקנה והוא רץ על CPU בלבד. השאר הם מאמרי דעה של כותב יחיד (XDA, Yahoo Tech) ורשימות דלות (apidog, Security Boulevard, SitePoint) שמדרגות לפי חוזק תחומי, לא לפי היותן שימושיות.

מה שכולם מדלגים עליו, לפי סדר כמה שזה עולה לך:

• הפער הסוכני.יצירת קוד אינה אותה מיומנות כמו הנעת סוכן בביצוע שינוי רב-קבצים. עמוד ראשון כמעט לא מזכיר זאת; זה ההבדל בין מודל שאתה שומר לבין מודל שאתה מסיר.

• חלונות הקשר. קידוד אג'נטי שורף טוקנים בטעינת קבצים ופלט בדיקות. טענה ש-"30B נכנס ב-24GB" חסרת משמעות עד שתשאל באיזה הקשר זה נכנס.

• מתמטיקת קוונטיזציה. אף אחד לא מסביר ש-4-bit דורש בערך כמספר הפרמטרים בג'יגה-בייט, או ש-Q3 חוסך VRAM במחיר של שגיאות תחביר עדינות.

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

• כשמקומי הוא הבחירה הלא נכונה. בדיקת שטח ב-2026 על אפליקציית Flutter בת 15,000 שורות (EPAM) עדיין מראה שמודלים מתקדמים בענן מנצחים בריפקטורים מרובי-השלבים הקשים ביותר. אף אחד ממאמרי הרשימה לא אומר לך מתי לעצור.

חישוב ה-VRAM שרוב כתבות הרשימה מדלגות עליו

כלל האצבע שהופך את כל שאר המספרים במאמר זה לקריאים: בקוונטיזציה של 4 ביט, מודל דורש בערך את מספר הפרמטרים שלו בג'יגה-בייט — 7B ≈ 5GB, 30B ≈ 18GB+, לפני תקורת מטמון KV. Q4 הוא נקודת המתוק לקידוד; Q3 ומטה חוסכים VRAM אך מייצרים שגיאות תחביר עדינות במידה מדידה. ומטמון ה-KV גדל עם חלון ההקשר שלך, וזו הסיבה לכך ש"30B נכנס ב-24GB" נכון רק עבור קונטקסט שאתה בפועל צריך לציין.

תערובת המומחים משנה את המתמטיקה באופן שמשפיע על שתי הבחירות הגדולות להלן. סך הפרמטרים קובע את טביעת הרגל; הפרמטרים הפעילים קובעים את המהירות. לכן Qwen3-Coder-30B-A3B (30B סך הכול, 3.3B פעילים) ו-gpt-oss-20b (20.9B סך הכול, 3.61B פעילים) שניהם מרגישים הרבה יותר מהירים ממה שמשקלם על הדיסק מרמז, ולמה DeepSeek V4 Flash — 284B סך הכול, 13B פעילים — הוא התאמה מקומית גרועה אף על פי שה-API שלו זול.

זיכרון וידאו 24GB: Qwen3-Coder 30B

Qwen3-Coder-30B-A3B-Instructהוא שוחרר ביולי 2025 על ידי צוות Qwen של Alibaba תחת רישיון Apache 2.0, מדובר במודל Mixture-of-Experts עם 30B פרמטרים בסך הכל ו-3.3B פעילים לכל טוקן, חלון הקשר של 262,144 טוקנים, וטביעת רגל של 4-bit בגודל משוער של 17–20GB — מה שמשאיר מרווח אמיתי בכרטיס גרפי של 24GB עבור מטמון ה-KV שסשן קידוד ארוך צריך.

במסגרת ההערכה העצמאית המקומית שאנחנו הכי סומכים עליה (gauravvij/local-llm-coding-eval, ארבעה מודלים שרצו מקומית דרך Ollama על CPU), qwen3-coder:30b השיג 80% ביצירת קוד, 77% בבחירת כלים ו-80% דיוק סוכן — התוצאה המאוזנת ביותר מבין הארבעה, והמודל היחיד שהיה חזק בכל שלוש המשימות בו-זמנית. כלי מעקב של צד שלישי מרכיבים את הציון שלו ב-SWE-bench Verified סביב 50.3, ב-Aider Polyglot על 66.2, וב-LiveCodeBench v6 על 58.9; יש להתייחס אליהם כאל נתונים שמקובצים ממקורות חיצוניים, לא כאל המספרים הרשמיים של אליבאבא — שזה כל מה שקוון פרסמה עבור המודל הזה.

המהירות הנמדדת משתנה מאוד בין חומרות. נקודות הנתונים השימושיות ביותר: התקנת TurboQuant קהילתית מריצה אותו על RTX 3060 Ti עם 8GB בקצב יצירה של ~29 אסימונים/שנייה עם קונטקסט מלא של 262K, ו-benchmark של oMLX מדד את גרסת ה-MLX ב-4-bit על M4 Pro (48GB) ב-73.6 אסימונים/שנייה בקונטקסט של 1K, שיורדת ל-13.5 אסימונים/שנייה ב-64K. בכרטיס של 24GB בהתקנת Ollama רגילה כדאי לצפות לטווח של עשרות אסימונים בשנייה, לא מאות — זה המחיר של הרצת מקודד קרוב-לחזית בבית.

ההסתייגות הכנה: הוא לא המקודד המקומי המהיר ביותר, וקיים Qwen3-Coder-Next חדש יותר שמיועד לשימוש מרוחק (hosted) ובשורת פקודה (CLI) ולא להתקנות מקומיות מקוונטזות. אבל לעבודה אגנטית בקנה מידה של ריפו על כרטיס אחד, Qwen3-Coder-30B הוא הבחירה כיום.

16GB VRAM: gpt-oss-20b

בכרטיס של 16GB, התשובה היא gpt-oss-20b — וזה לא קרוב. הוא שוחרר ב-5 באוגוסט 2025 על ידי O​penAI תחת רישיון Apache 2.0. זהו מודל Mixture-of-Experts עם 20.9B פרמטרים בסך הכול ו-3.61B פעילים לכל טוקן, חלון הקשר של 131,072 טוקנים, וכימות MXFP4 המקורי שלו מגיע לכ-14GB. זו העובדה המכרעת: הוא רץ 100% על GPU בכרטיס של 16GB, בלי שדבר נשפך לזיכרון המערכת.

מדוע שהייה על ה-GPU חשובה יותר מכל benchmark: מודל שנכנס ל-VRAM מהיר פי 3–11 ממודל שמבצע offload. benchmark עצמאי רשם 139.93 tokens/sec עבור gpt-oss-20b על RTX 4080 — בערך פי 2.8 מאלטרנטיבה צפופה באותו footprint — ובודק אחד מ-2026 העניק לו ציון "מדד אינטליגנציה" של 52.1, וכינה אותו ללא תחרות במחלקת ה-16GB עבור קידוד וניפוי באגים מקצועיים. זהו התאמה הדוקה, לכן הריצו אותו לבד ושמרו על context צנוע; האיכות יורדת בחלק העליון של החלון.

האלטרנטיבה הסוכנותית על 16GB היא Devstral 24B (devstral-small-2:24b), שמציג את הציון המפורסם היחיד ב-SWE-bench Verified בקרב מודלי הקוד המקומיים בקטגוריית 16GB — 46.8% — אבל הוא איטי ולעיתים קרובות דורש העברת עומס למעבד (CPU offload) בקצב של כ-18 tokens/sec. אם העבודה שלך כוללת עריכות סוכנותיות בקבצים מרובים ואתה יכול לסבול את המהירות, Devstral מרוויח את מקומו; אם אתה רוצה מהירות וקוד נקי, gpt-oss-20b הוא ברירת המחדל הטובה יותר. מודלים צפופים של 14B — Qwen3-Coder 14B או Qwen2.5-Coder 14B ב-Q5 — הם חלופות נוחות וזולות.

8GB VRAM: Qwen 2.5 Coder 7B

ב-8GB, התשובה הכנה היא Qwen2.5-Coder-7B: 7B פרמטרים בכ-4.7GB בפורמט Q4_K_M, הקשר מקורי של 32,768 טוקנים הניתן להרחבה לכ-128K, וציוני הבנצ'מרק החזקים ביותר להשלמת קוד במחלקת ה-7B. זהו מודל ישן יותר — ששוחרר בנובמבר 2024 — וזה בסדר, כי שום דבר חדש יותר בהיקף ה-8GB לא הדיח אותו. מבחני קהילה ממקמים אותו בסביבות 50 טוקנים לשנייה על RTX 4060 או 3070; מבחן RTX 4060 עצמאי במרץ 2026 מדד 28–35 טוקנים לשנייה, פער שנובע כמעט כולו מהגדרות ההקשר.

שלושה דברים חשובים על כרטיס 8GB שלא חשובים במקומות אחרים. ראשית, הגבל את הקונטקסט ל-4–8K: מטמון ה-KV הוא מה שגורם ל-OOM בכרטיס 8GB, לא המשקולות — מדד אחד הראה שהמהירות קפצה מ-~3.6 ל-~37 טוקנים לשנייה רק בזכות הגבלת הקונטקסט. שנית, ודא באמצעות ollama ps שהמודל רץ 100% על ה-GPU; כל חלק על ה-CPU יגרום לקריסת המהירות. שלישית, Q4_K_M, לא Q3 — שגיאות התחביר של Q3 עולות לך יותר ממה שחוסך ה-VRAM.

הפיתוח הבולט של 2026 הוא ש- Qwen3-Coder-30B-A3B-Instruct יכול כעת להידחס ל-8GB באמצעות דחיסת TurboQuant KV-cache — הגדרה קהילתית מדדה ~7.5GB ו~29 טוקנים/שנייה על RTX 3060 Ti בהקשר מלא של 256K. זה עובד, וזה מספיק מסורבל כדי שלא נמליץ עליו כברירת מחדל. אם אתה רוצה אפשרות חדשה יותר ומוכנה לשימוש, Qwen3 8B (~5.2GB, מצב חשיבה היברידי) הוא צעד קטן למעלה מ-Qwen2.5-Coder-7B בהיגיון כללי, תוך שהוא נשאר מעט מאחור בקוד טהור.

מה לגבי Apple Silicon?

זיכרון מאוחד משנה את המשוואה בכיוון אחד: הקיבולת עולה, מהירות היצירה יורדת. M4 Pro עם 48GB יכול להחזיק מודלים שכרטיס Windows עם 16GB לא יכול להריץ, אבל הוא מייצר טוקנים לאט הרבה יותר בקונטקסט ארוך. הנתונים שיש לנו: גרסת ה-4-bit MLX של Qwen3-Coder-30B-A3B-Instruct השתמשה ב-16.6GB בקונטקסט של 1K וב-25.5GB בקונטקסט של 64K על M4 Pro, כשמהירות היצירה ירדה מ-73.6 טוקנים/שנייה ל-13.5 ככל שהקונטקסט גדל (מדד oMLX). gpt-oss-20b נכנס בנוחות ב-16GB של זיכרון מאוחד והוא בחירה מצוינת ל-Mac. אם אתם רוצים מולטי-מודאליות על Apple Silicon, Gemma 4 12B פועל בכ-16GB של זיכרון מאוחד עם קונטקסט של 256K — האפשרות המקומית החזקה ביותר אם עבודת הקידוד שלכם מתבצעת לצד מסמכים עתירי תמונות.

המספרים העצמאיים: codegen אינה המיומנות שחשובה.

הנתונים הבהירים ביותר שמצאנו הם בדיקה מקומית בודדת שכדאי לצטט בשלמותה. gauravvij/local-llm-coding-eval הריץ ארבעה מודלים מקומית דרך Ollama, על CPU, ללא ענן — יצירת קוד, קריאות לפונקציות, ומשימת סוכן מרובת-שלבים — עם תוצאות שהולכות נגד האינסטינקט ש"מספר יצירת הקוד הגדול יותר מנצח":

• Qwen3.6 27B (qwen3.6:27b, dense, ~17GB): 80.0% יצירת קוד, 84.6% כלים, 100% סוכן — הכל-בו הטוב ביותר.

• Qwen3.6 35B A3B (qwen3.6:35b-a3b, MoE, ~18GB): 70.0% יצירת קוד, 84.6% כלים, 100% סוכן.

• Qwen3-Coder-30B-A3B-Instruct (qwen3-coder:30b, MoE, ~17GB): 80.0% ייצור קוד, 76.9% כלים, 80% סוכן — המאוזן ביותר.

• DeepSeek-Coder-V2 33B (deepseek-coder:33b, צפוף, ~18GB): 90.0% יצירת קוד — הטוב מבין הארבעה — אבל 10% סוכן, אחרון ממש בעבודה רב-שלבית.

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

כאשר הרצה מקומית היא הבחירה הלא נכונה

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

• העבודה האייג'נטית הקשה ביותר עדיין מנצחת אותך. בדיקת השדה של EPAM לשנת 2026 על אפליקציית Flutter בת 15,000 שורות מצאה שמודלי קצה בענן (GPT-5.3-codex) עדיין עולים על מודלים מקומיים ברפקטורינג הרב-שלבי המורכב ביותר. אם היום שלך מורכב משמונה שעות של רפקטורינג לקוד מדור קודם, המודלים המקומיים עדיין לא מוכנים.

• צורכי ההקשר שלך עולים על קיבולת הכרטיס. סוכן קוד שטוען מאגר קוד שלם יחרוג ממטמון ה-KV שכרטיס של 16GB יכול להחזיק. הקונטקסט של 256K של Qwen3-Coder-30B הוא הסיבה לכך שהוא מנצח בקטגוריית ה-24GB — כרטיסים קטנים יותר מפסידים במשחק הזה כבר בשלב מוקדם.

• אתה לא יכול להשגיח על חומרה. החומרה היא כסף אמיתי: כרטיס 24GB הוא בקטגוריית 700–1,600 דולר, בתוספת חשמל ותחזוקה. בנפח נמוך, קריאה ל-API זולה יותר מצריכת החשמל.

• DeepSeek V4 Flash הוא ההוכחה. עם 284B פרמטרים בסך הכול, משקלי ה-4-bit של DeepSeek V4 Flash לבדם הם בערך 140GB — לא מודל לכרטיס צרכני, נקודה. העיצוב שלו, שבו 13B פרמטרים פעילים, הוא בדיוק הסיבה שה-API שלו מהיר וזול ב-$0.15 / $0.29 לכל 1M טוקנים (MIT, הקשר של 1M). עבור המודל הזה, "להריץ אותו מקומית" היא השאלה הלא נכונה; ה-API הוא הנקודה.

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

אם אתה רוצה את התשובה בצד ה-API לאותה שאלה — איזה מודל קידוד בענן הוא ברירת המחדל כאשר מודל מקומי אינו הפשרה הנכונה — התייחשנו לכך בנפרד במדריך שלנו לבחירת ה-LLM הטוב ביותר לקידוד, והמאמר שלנו על סוכני קידוד ב-AI מכסה כלים כמו Cline ו-OpenCode שעובדים עם המודלים המקומיים האלה.

איך לבדוק לפני שקונים את הכרטיס

הדרך הזולה ביותר להחליט היא להריץ פרומפטים משלך לפני שמתחייבים לחומרה. Ollama או LM Studio מריצים כל אחת משלוש הבחירות תוך דקות, והמבחן שחשוב הוא הקבצים האמיתיים של הריפו שלך, לא benchmark. ראוטר מרוויח את מקומו בהחלטה הנלווית: כשמשווים מועמד מקומי מול מודלים מתקדמים מתארחים, נקודת קצה אחת מאפשרת להריץ את אותו פרומפט בשניהם בלי להתעסק בהחלפת מפתחות. ב-OrcaRouter, DeepSeek V4 Flash מוגש במחיר המחירון של הספק שלו, מועבר ללא שינוי — $0.15 / $0.29 לכל 1M טוקנים, 0% תוספת מחיר — עם מעבר אוטומטי, מה שהופך אותו לקנה מידה זול והוגן לשאלה "האם המודל המקומי שלי באמת טוב יותר מה-API שעולה $0.15?"

הסתייגות כנה אחת: OrcaRouter אינו מארח את Qwen3-Coder-30B-A3B-Instruct או את gpt-oss-20b. אם המטרה שלך היא אך ורק אופליין, ראוטר אינו רלוונטי עבורך — ארח בעצמך (self-host) וסיימת. אם המטרה שלך היא להשוות A/B בין אותו מודל בעל משקלים פתוחים לבין מודלי הקצה לפני שתוציא כסף על כרטיס מסך, התפקיד של הראוטר הוא ההשוואה, לא האירוח.

השורה התחתונה

זיכרון הווידאו (VRAM) שלך קובע קודם, איכות המודל שנייה. על 24GB, הרץ את Qwen3-Coder-30B-A3B-Instruct — המודל המקומי החזק ביותר לכל מטרה, עם הקשר של 256K שעבודת סוכנים דורשת. על 16GB, הרץ את gpt-oss-20b — המודל הנדיר שהוא גם מהיר וגם פועל כולו על ה-GPU. על 8GB, הרץ את Qwen2.5-Coder-7B ושמור על אורך הקשר מתון. שפוט כל אחד מהם לפי עמודת הסוכנות, לא לפי עמודת יצירת הקוד, וקבל שהרפקטורינג הקשה ביותר על פני קבצים מרובים עדיין שייך לענן. המספרים לעיל נכונים לתאריך 10 באוגוסט 2026 — ודא שוב את המערך ואת מחירי המחירון לפני שאתה מוציא כסף, כי התחום הזה משתנה מדי שבוע.