דלג לתוכן הראשי
מדריכים DeepSeek ומודלים מקומיים
מעודכן ליולי 2026 15 דקות קריאה מתחילים עד מתקדם

DeepSeek ומודלים
פתוחים שרצים אצלך

עד לא מזמן, AI חזק היה רק בענן של OpenAI, Anthropic ו-Google. DeepSeek ומודלים פתוחים אחרים שינו את המשוואה: מודלים ברמת GPT — חינמיים, פתוחים, ורצים על המחשב שלך. במדריך: מה מיוחד ב-DeepSeek, איך מריצים מודל מקומית עם Ollama, מפת המודלים הפתוחים, ומתי זה עדיף על ה-API בענן.

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

Open
משקלים פתוחים
Local
רץ אצלך
Private
הנתונים נשארים
$0
ללא עלות API

מה זה DeepSeek

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

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

ארכיטקטונית, החלק שמסביר את העלות הנמוכה הוא Mixture-of-Experts: רק חלק מהפרמטרים פעיל בכל שאילתה, כך שמודל גדול מאוד רץ בעלות חישוב של מודל קטן בהרבה. זה גם מסביר משהו פחות נעים שנגיע אליו — המודל גדול בזיכרון גם כשהוא זול בחישוב.

שתי שאלות נפרדות

"האם להשתמש ב-DeepSeek" ו"האם להריץ מודל אצלי" הן לא אותה שאלה. אפשר לצרוך את DeepSeek דרך API של ספק בדיוק כמו כל מודל אחר.

"משקלים פתוחים" אינו "קוד פתוח"

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

שלוש השלכות מעשיות:

מודל פתוח לא חוסך כסף — הוא מזיז אותו

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

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

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

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

מה הרצה מקומית באמת פותרת

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

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

אבל כדאי לדייק מה הרצה מקומית פותרת ומה לא:

מודל שחושב לפני שהוא עונה

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

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

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

ומתי הוא כן משתלם: כשיש שלב אחד במערכת שדורש נימוק אמיתי — סיווג מורכב, בדיקת עמידה בכללים, פתרון בעיה — ולא בכל שלב. הדפוס הנפוץ הוא מודל מהיר לרוב השלבים ומודל חושב לשלב אחד.

כמה חומרה באמת צריך

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

# אומדן זיכרון גס למודל שרץ מקומית
params_b = 8            # מיליארדי פרמטרים
bytes_per_param = {
    "fp16": 2,          # דיוק מלא יחסית
    "q8":   1,          # קוונטיזציה 8 ביט
    "q4":   0.5,        # 4 ביט — הנפוץ בהרצה ביתית
}

for name, b in bytes_per_param.items():
    weights = params_b * b
    print(name, "≈", round(weights + 2, 1), "GB")
    # ה-+2 הוא מרווח גס להקשר ולתקורה;
    # הקשר ארוך מגדיל אותו משמעותית

מה שהחשבון הזה מלמד מיד: מודל של 7–8 מיליארד פרמטרים בקוונטיזציה של 4 ביט נכנס בנוחות למחשב נייד סביר, ומודל של עשרות מיליארדים כבר דורש GPU ייעודי. וכאן חוזר האזהרה מסעיף ה-MoE: מודל MoE גדול צריך זיכרון לכל המשקלים גם אם רק חלק מהם פעיל בכל שאילתה — הוא חוסך בחישוב, לא בזיכרון. זו הסיבה שאנשים מופתעים לגלות שהמודל ה"יעיל" לא נכנס אצלם.

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

מה עוד יש בשוק הפתוח

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

הכלל שמנחה את הבחירה: הגודל נקבע לפי המשימה, לא לפי מה שמרשים. מודל של 7 מיליארד שמסווג פניות נכון ב-95% מהמקרים עדיף על מודל ענק שעושה את זה ב-97% ודורש חומרה שאין לכם — במיוחד כשאפשר לשלוח את 5% הלא-בטוחים לבדיקה במקום לנחש.

קוונטיזציה: מה מרוויחים ומה משלמים

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

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

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

איך מריצים בפועל

לא צריך להיות מהנדס ML. שני כלים הפכו את זה לפשוט כמו התקנת אפליקציה — Ollama בשורת הפקודה, וLM Studio בממשק גרפי למי שמעדיף.

# הורדה והרצה — פקודה אחת
ollama run deepseek-r1:8b

# Ollama חושף API תואם-OpenAI על פורט 11434,
# כך שקוד קיים עובר אליו בשינוי כתובת בלבד:
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",          # לא נבדק, נדרש טכנית
)

r = client.chat.completions.create(
    model="deepseek-r1:8b",
    messages=[{"role": "user",
               "content": "סכם את הפסקה הבאה בשתי שורות: ..."}],
)
print(r.choices[0].message.content)

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

עברית — הנקודה שמכריעה כאן

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

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

שלוש מסקנות מעשיות:

כיוונון: מתי זה באמת נחוץ

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

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

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

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

מקומי בייצור: מה משתנה

להריץ מודל על המחשב שלכם זה דבר אחד; להריץ אותו כשמערכת אמיתית תלויה בו זה אחר. ארבעה דברים שלא קיימים בגרסת הניסוי:

מה נשבר בהרצה מקומית, ואיך מאבחנים

ארבע תקלות מכסות כמעט כל מקרה, וכולן נראות בהתחלה כמו "המודל גרוע":

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

השאלות שלא נעים לשאול

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

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

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

איך מחליטים, בפועל

במקום ויכוח עקרוני, סדר בדיקה שמגיע לתשובה תוך יומיים:

  1. לבנות את המערכת מול API של ספק. יום עבודה, ובסופו ברור אם הרעיון בכלל עובד. רוב הפרויקטים נופלים כאן, ואז כל דיון בחומרה היה מיותר.
  2. לבנות מערך של עשרים עד שלושים מקרים אמיתיים עם התשובה הנכונה מסומנת. זה גם מה שיאפשר את ההשוואה וגם מה שתצטרכו ממילא.
  3. להוריד מודל פתוח ולהריץ את אותו מערך מולו — בשינוי כתובת בלבד, בזכות ה-API התואם. עכשיו יש מספר במקום תחושה.
  4. לחשב את שתי העלויות על חודש אמיתי, כולל ניצולת וזמן אדם.
  5. להחליט לפי מה שהתקבל, ולא לפי מה שהיה נעים יותר להאמין בו.

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

מתי לא לטרוח

טעויות שחוזרות