קוון / Qwen

מה זה קוון ולמה הוא הפך לבסיס הפתוח הנפוץ בעולם?

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

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

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

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

הפיצ'רים המרכזיים של קוון

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

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

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

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

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

כמה זה עולה?

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

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

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

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

קוון מול DeepSeek ומול המודלים הסגורים

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

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

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

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

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

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

הפיצ'ר שעושה את ההבדל: ניתוב לפי גודל

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

# שכבת ניתוב בין גדלים באותה משפחת מודלים
import os
import re
import requests

BASE = os.environ.get("QWEN_BASE", "http://qwen.internal:8000/v1")
HEADERS = {
    "Authorization": "Bearer " + os.environ.get("QWEN_API_KEY", "local"),
    "Content-Type": "application/json; charset=utf-8",
}

# הסולם, מהזול ליקר. הניתוב תמיד מתחיל מלמעלה
LADDER = ["qwen3-1.7b", "qwen3-8b", "qwen3-32b", "qwen3-235b-a22b"]

def call(model, prompt, thinking=False, temperature=0.2):
    body = {
        "model": model,
        "temperature": temperature,
        "messages": [{"role": "user", "content": prompt}],
        "extra_body": {"enable_thinking": thinking},
    }
    r = requests.post(BASE + "/chat/completions", json=body, headers=HEADERS, timeout=180)
    r.raise_for_status()
    return r.json()["choices"][0]["message"]["content"]

# הערכת מורכבות זולה: אורך, מספר שאלות, ונוכחות דרישת חישוב
def complexity(prompt):
    score = 0
    score += len(prompt) // 800
    score += prompt.count("?")
    if re.search(r"חשב|נתח|השווה|הסבר למה", prompt):
        score += 2
    return score

def route(prompt, validate):
    start = 0 if complexity(prompt) < 2 else 1
    for model in LADDER[start:]:
        deep = model.endswith("235b-a22b")
        out = call(model, prompt, thinking=deep)
        if validate(out):
            return {"model": model, "output": out}
    return {"model": None, "output": None}

# בדיקת פלט לדוגמה: התשובה חייבת להיות JSON תקין עם השדות שביקשנו
def valid_json(text, required=("category", "urgency")):
    try:
        import json as _json
        data = _json.loads(text)
    except ValueError:
        return False
    return all(k in data for k in required)

# שילוב באוטומציה של תיוג פניות נכנסות
# שלב 1: כל פנייה עוברת דרך route עם הבדיקה valid_json
# שלב 2: המודל שנבחר נשמר לצד התוצאה, כדי למדוד את התפלגות העלות
# שלב 3: אחת לחודש בוחנים את ההתפלגות ומכווננים את סף המורכבות

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

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

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

חסרונות שאתם צריכים לדעת

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

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

היתרונות שעושים את קוון שווה

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

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

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

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

מתי לבחור קוון ומתי לבחור אחרת?

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

# עץ החלטה לבחירת בסיס מודל פתוח
שאלה 1: יש מגבלה ארגונית על מקור הטכנולוגיה?
    כן, חסימה מוחלטת     -->  בסיס פתוח מערבי
    צריך אישור           -->  לברר בכתב לפני ההטמעה
    אין מגבלה            -->  ממשיכים לשאלה 2

שאלה 2: מי מתחזק את התשתית?
    אין צוות             -->  ממשק חינמי או שירות מנוהל
    צוות חלקי            -->  שירות מנוהל, גרסה בינונית
    צוות ייעודי          -->  הרצה עצמית עם ניתוב בין גדלים

שאלה 3: מה סוג המשימה העיקרית?
    תיוג וסיווג בנפח     -->  הגרסה הקטנה, מספיקה בהחלט
    קוד והשלמות          -->  הגרסה הייעודית לקוד
    הסקה רב שלבית        -->  הגרסה הגדולה עם מצב חשיבה
    ניסוח בעברית         -->  מודל אחר לשלב הזה

שאלה 4: מתכננים לכוונן על נתונים שלכם?
    כן, בטווח הקרוב      -->  להתחיל מהגרסה הבינונית
    אולי בהמשך           -->  לקבע גרסה ולא לרדוף אחרי דורות
    לא                   -->  לשקול בכלל מודל מנוהל

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

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

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

השורה התחתונה: האם קוון שווה?

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

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

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

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