הגדרת Reasoning Effort במודל שפה מקומי: מדריך

כיצד משתנה מאמץ ההסקה (Reasoning Effort) במודל שפה מקומי

מאמץ ההסקה הוא הגדרה המורה למודל כמה זמן עליו "לחשוב" לפני מתן תשובה. הגדרה זו משנה אך ורק את אורך מקטע ההסקה. משקולות המודל על הדיסק נותרות זהות בכל רמה, ה־quantisation נשאר זהה, והתשובה מופקת מאותו forward pass. מה שמשתנה הוא מספר ה־tokens שהמודל מקצה לטיוטה הפנימית שלו לפני תחילת התשובה.

להבחנה זו יש חשיבות בשל המקום שבו ה־tokens הללו נצרכים. בשימוש ב־API חיצוני, ה־tokens של ההסקה מופיעים בחשבונית. בשרת VPS שבבעלותכם, המחיר משולם בזמן יצירה (generation time) על ה־CPU או ה־GPU שלכם, ובניצול נפח בתוך ה־context window. מודל שמוגדר ברמת המאמץ הגבוהה ביותר עלול להקדיש את רוב הפלט שלו להסקה לפני שמופיעה המילה הראשונה בתשובה; בחומרה מאוחסנת עצמית, זהו ההבדל בין תגובה של שתי שניות לבין תגובה של שתי דקות.

היכן נמצאת רמת המאמץ: תבנית הצ'אט, לא המשקולות

מודל חשיבה מאומן להפיק מקטע הנמקה, שבדרך כלל עטוף בתגיות <think> ו-</think>, לפני מתן התשובה הסופית. רמת המאמץ היא הוראה שתבנית הצ'אט של המודל כותבת לתוך ה-prompt. תבנית זו היא קובץ Jinja שמגיע עם המודל. היא קוראת משתנה כגון reasoning_effort ומרנדרת שורת מערכת שונה עבור כל ערך, והמודל אומן לקצר או להאריך את מרחב הטיוטה שלו בתגובה לשורה זו.

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

בבדיקה שנערכה ב-2026-08-20, כרטיס המודל Qwen3.8-27B מתעד שלוש רמות מאמץ: low, medium ו-xhigh, כאשר xhigh היא ברירת המחדל. לא קיימת רמה high. החשיבה עצמה מופעלת באמצעות enable_thinking, שמופעל כברירת מחדל, והכרטיס מתעד גם את preserve_thinking, שמופעל כברירת מחדל, ושומר על הנמקה מסיבובים קודמים בהיסטוריית השיחה. gpt-oss משתמש ב-low, medium ו-high במקום זאת. משפחות רבות אחרות מקבלות ערך בוליאני בלבד. קראו את הכרטיס עבור הגרסה המדויקת שהורדתם, כיוון ששמות אלו אינם סטנדרט. הרצת מודל 27B על שרת VPS מגיעה קודם. דף זה עוסק במה להגדיר לאחר שהמודל מתחיל לענות.

מדוע מאמץ חישובי גבוה עולה יותר ב-VPS

טוקנים של פלט. טוקני הסקה (reasoning) הם טוקנים שנוצרים בתהליך. הם עוברים דרך אותו לולאת פענוח כמו התשובה, באותו קצב טוקנים לשנייה שהחומרה שלך מסוגלת לספק. נניח שמשימה מייצרת 200 טוקנים של תשובה ו-4,000 טוקנים של הסקה. יצרת 4,200 טוקנים והקורא ראה רק 200 מהם. קצב הפענוח שלך נקבע על ידי רוחב הפס של הזיכרון ועל ידי הקוונטיזציה שבחרת, לכן המשתנה היחיד שנותר הוא מספר הטוקנים עצמו.

זמן המתנה (Wall clock). משתמש ממתין לטוקן הראשון של התשובה, כיוון שכל מה שלפני כן הוא מסך ריק או ספינר טעינה. טוקני ההסקה מופקים ראשונים, לכן זמן ההמתנה הוא בערך מספר טוקני ההסקה חלקי קצב הפענוח שלך, בתוספת זמן עיבוד ה-prompt. הכפלת אורך ההסקה מכפילה את זמן ההמתנה הזה.

הקשר (Context). טוקני הסקה תופסים מקום בחלון ההקשר כמו כל טוקן אחר. כאשר preserve_thinking מופעל, ה-scratchpad מהתור הראשון עדיין נמצא ב-prompt בתור החמישי, כך שעיבוד ה-prompt הופך לאיטי יותר בכל תור ככל שהחלון מתמלא משני הצדדים. הגדלת num_ctx כדי להכיל זאת דורשת זיכרון KV cache, שב-VPS ללא GPU הוא זיכרון RAM של המערכת שייתכן ואינו פנוי עבורך.

מתי להעלות את רמת הפירוט ומתי להשאיר אותה נמוכה

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

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

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

כיצד להגדיר את הרמה ב-llama.cpp

llama.cpp כותב את המשתנה ישירות לתוך התבנית, מה שהופך אותו לסביבת הריצה שבה ניתן לוודא שהרמה אכן התקבלה. הצביעו עם -m על קובץ ה-GGUF שכבר ברשותכם.

llama-server -m ./qwen3.8-27b-Q4_K_M.gguf \
  --jinja \
  --reasoning-effort medium \
  --reasoning-format deepseek \
  -c 32768 \
  --host 127.0.0.1 --port 8080

--jinja משתמש בתבנית הצ'אט המובנית של המודל והוא מופעל כברירת מחדל בגרסאות הנוכחיות. --reasoning-effort מקבל את default, minimal, low, medium, high, xhigh או max, כאשר default משמעותו להשאיר את ברירת המחדל של התבנית כפי שהיא. רשימה זו היא אוצר המילים של llama.cpp ולא של המודל, לכן העבירו רק שם שמופיע בכרטיס: רמה שהתבנית אינה מגדירה עלולה לגרום לשגיאת תבנית בעת הבקשה. --reasoning-format deepseek מעביר את תהליך ההסקה מחוץ ל-message.content אל תוך message.reasoning_content, וזה מה שהופך את הפיצול למדיד בסעיף הבא.

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

llama-server -m ./qwen3.8-27b-Q4_K_M.gguf --jinja \
  --chat-template-kwargs '{"enable_thinking": false}'

--reasoning-budget הוא מנגנון שונה. הוא מגביל את מקטע ההסקה בטוקנים, כאשר 0 מסיים אותו מיד ו--1 משאיר אותו ללא הגבלה, במקום לבקש מהמודל לתכנן מקטע קצר יותר. שני הדגלים חלים על כל השרת. llama-server אינו מקבל את reasoning_effort כשדה פר-בקשה, לכן הגשת שתי רמות מאמץ בו-זמנית מחייבת שני תהליכים על שני פורטים שונים.

vLLM חושף את אותו משתנה עבור כל בקשה, בתוך גוף הבקשה התואם ל-OpenAI:

{"model": "Qwen/Qwen3.8-27B",
 "messages": [{"role": "user", "content": "Summarise this changelog in two lines."}],
 "chat_template_kwargs": {"reasoning_effort": "medium"}}

כיצד להגדיר את הרמה ב-Ollama

ל-Ollama יש שדה משלה, think, ב-/api/chat וב-/api/generate. הוא מקבל true, false, או אחד מ-low, medium, high ו-max, כאשר max מבקש את הרמה הגבוהה ביותר שהמודל מציע. תהליך ה-Thinking מופעל כברירת מחדל עבור מודלים התומכים בכך.

ollama run qwen3.8:27b --think=low "Draft a one line commit message for a README typo fix"

{"model": "qwen3.8:27b",
 "messages": [{"role": "user", "content": "Which HTTP status code means the request body was too large?"}],
 "think": "low",
 "stream": false}

הסקת המסקנות (reasoning) חוזרת ב-message.thinking והתשובה ב-message.content, כשהן כבר מופרדות עבורך. בתוך סשן ollama run אינטראקטיבי, /set think ו-/set nothink מחליפים את המצב ללא צורך באתחול.

כעת שימו לב לאי-ההתאמה. אוצר המילים של Ollama הוא low, medium, high ו-max. התבנית של Qwen3.8 מגדירה low, medium ו-xhigh. משהו חייב למפות את האחד לשני, ומודל Ollama נושא תבנית הארוזה בתוך ה-tag שלו במקום קובץ Jinja מהמאגר המקורי, לכן השאלה האם הרמה שלך מגיעה למודל תלויה בתבנית הארוזה הזו. אל תניחו שזה עבד. מדידת העניין אורכת כדקה.

כיצד למדוד האם הרמה אכן הופעלה

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

for level in low medium max; do
  body=$(jq -n --arg lvl "$level" '{
    model: "qwen3.8:27b",
    messages: [{role: "user", content: "A pump fills a 4500 litre tank in 25 minutes. A second pump is 40 percent slower. How long do both together take? Answer in minutes."}],
    think: $lvl,
    stream: false,
    options: {temperature: 0, num_ctx: 8192}
  }')
  echo "== $level"
  curl -s http://localhost:11434/api/chat -d "$body" | jq '{
    thinking_chars: (.message.thinking // "" | length),
    answer_chars: (.message.content | length),
    eval_count: .eval_count,
    seconds: (.total_duration / 1e9),
    tok_per_sec: (.eval_count / (.eval_duration / 1e9))
  }'
done

eval_count כולל כל טוקן שנוצר, כולל תהליך הסקת המסקנות (reasoning), לכן הפער בין שתי רמות מורכב כמעט כולו מהסקה. thinking_chars מספק לכם את הפיצול ישירות. שני דברים צריכים להתקיים: המספרים משתנים בין רמות, והתשובה נשארת נכונה ברמה הנמוכה יותר. אם eval_count נשאר בטווח רעש סטטיסטי לאורך כל שלושת הריצות, הרמה אינה נלקחת בחשבון, והתיקון הוא סביבת הרצה (runtime) שמעבירה את הפרמטר בפועל במקום להסתמך על שם רמה שונה.

זמן כולל הוא רק חצי מהתמונה, לכן מדדו את הפער עד לטוקן התשובה הראשון באמצעות הזרמת נתונים (streaming) ועצירה ב־content הלא-ריק הראשון. פעולה זו דורשת jq ו־bc.

start=$(date +%s.%N)
curl -sN http://localhost:11434/api/chat -d '{
  "model": "qwen3.8:27b",
  "messages": [{"role": "user", "content": "Explain what a reverse proxy does, in three sentences."}],
  "think": "low",
  "stream": true
}' |
while IFS= read -r line; do
  if [ -n "$(printf '%s' "$line" | jq -r '.message.content // ""')" ]; then
    echo "first answer token after $(echo "$(date +%s.%N) - $start" | bc)s"
    break
  fi
done

הריצו זאת ב־low ושוב ב־max. ההפרש הוא זמן ההמתנה שאתם רוכשים. ב־llama.cpp אותם מספרים מוחזרים בתוך התגובה, ללא צורך בחישובים ב־shell:

curl -s http://localhost:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model": "local", "temperature": 0,
       "messages": [{"role": "user", "content": "A pump fills a 4500 litre tank in 25 minutes. A second pump is 40 percent slower. How long do both together take?"}]}' | jq '{
  reasoning_chars: (.choices[0].message.reasoning_content // "" | length),
  answer_chars: (.choices[0].message.content | length),
  predicted_n: .timings.predicted_n,
  tok_per_sec: .timings.predicted_per_second
}'

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

מה עלול להשתבש

התשובה נקטעת, או ש-content ריק בזמן ש-thinking מלא. מגבלת היצירה נוצלה על ידי תהליך ה-reasoning. הפרמטר num_predict ב-Ollama מגביל את כלל היצירה, כולל ה-reasoning, ומכיוון שה-reasoning מופיע ראשון, מגבלה של 512 טוקנים במאמץ גבוה עלולה לסיים את התגובה לפני שהתשובה מתחילה. Ollama מדווח על "done_reason": "length" בתגובה כזו. הגדילו את המגבלה או הנמיכו את רמת המאמץ. כיצד num_predict סופר טוקנים מסביר את האינטראקציה הזו בפירוט.

שינוי הרמה אינו משפיע על דבר. ספירת הטוקנים זהה בכל רמה. ייתכן שסביבת ההרצה אינה מעבירה את המשתנה, או שהתבנית אינה קוראת אותו. בדקו את התבנית שסביבת ההרצה שלכם משתמשת בה בפועל, במקום זו המופיעה במאגר המקורי. llama.cpp עם --jinja ו---chat-template-kwargs כותב את המשתנה ידנית, ולכן הוא משמש כבקרת איכות טובה: אם הרמה עובדת שם ולא במקום אחר, המודל תקין וסביבת ההרצה האחרת היא זו שמשמיטה את המשתנה.

שם רמה נדחה. שגיאת תבנית בעת הבקשה, או כשל בהודעה הראשונה מול שרת תקין, מעידים בדרך כלל על כך שהעברתם רמה שהתבנית אינה מגדירה, כמו למשל high למודל שכרטיס המידע שלו מפרט רק low, medium ו-xhigh.

שיחות מרובות סבבים מאטות בכל סבב. ה-reasoning הישן נשמר בהיסטוריה. הגדירו את preserve_thinking ל-false אם המודל תומך בכך, או הסירו את השדה thinking מההודעות שאתם שולחים בחזרה. אחרת, עיבוד ה-prompt גדל בכל סבב בעוד אורך התשובות נשאר זהה.

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

הרצת שתי רמות בו-זמנית

התוכנה llama.cpp מקבעת את הרמה בעת ההפעלה, לכן שרת שמשרת גם עורך וגם משימת batch לילית זקוק לשני תהליכים בשני פורטים שונים, כאשר לכל אחד מהם --reasoning-effort משלו. שני תהליכים משמעותם גם שני עותקים של המשקולות בזיכרון, אלא אם כן תפרידו את המשימות בזמן. בשרת VPS יחיד, הסידור הזול יותר הוא בדרך כלל שרת בעל מאמץ נמוך עבור כל פעולה שמשתמש ממתין לה, בתוספת הרצה מתוזמנת בעלת מאמץ גבוה יותר עבור עבודה שאף אחד לא צופה בה. המאמר מה קורה כאשר כמה משתמשים משתפים מודל מקומי אחד רלוונטי גם כאן: אסימוני הסקה (reasoning tokens) הם עבודת פענוח, לכן העלאת המאמץ מקטינה את הקיבולת המקבילית האפקטיבית שלכם בערך באותו יחס שבו היא מעלה את כמות האסימונים.

FAQ

באיזו רמת מאמץ הסקה (reasoning effort) כדאי להשתמש כברירת מחדל?

התחילו ברמה הנמוכה ביותר שהמודל מציע והעלו אותה רק עבור משימות שראיתם שנכשלו. כמה מודלי חשיבה מגיעים עם הגדרת ברירת מחדל גבוהה, ו־Qwen3.8-27B מוגדר כברירת מחדל על xhigh, הרמה הגבוהה ביותר שלו, נכון לאוגוסט 2026. ברירת מחדל זו נבחרה כדי להציג ביצועים טובים בטבלאות השוואה (benchmarks), וטבלאות אלו אינן גובות תשלום עבור זמן. על החומרה שלכם אתם משלמים בשניות, לכן הפכו את הרמה הגבוהה לבחירה יזומה לכל משימה, במקום הגדרה שכל בקשה יורשת.

האם אסימוני הסקה (reasoning tokens) נספרים בתוך חלון ההקשר (context window)?

כן. אלו אסימונים רגילים בפלט והם תופסים מקום בחלון ההקשר לצד כל השאר. השאלה אם הם נשארים שם בתור הבא תלויה בסביבת ההרצה (runtime) ובמודל. הכרטיס של Qwen3.8 מתעד את preserve_thinking, שמופעל כברירת מחדל ושומר את תהליך החשיבה הקודם בהיסטוריה, כך ששיחה ארוכה נושאת איתה כל "טיוטה" שהופקה. הגדירו זאת כ-false, או הסירו את השדה thinking מהודעות שאתם שולחים שוב, ועיבוד ה-prompt יפסיק לגדול.

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

ההגדרה אינה מגיעה לתבנית הצ'אט (chat template). הרמה היא משתנה תבנית, לכן היא עובדת רק אם סביבת ההרצה מעבירה אותה והתבנית הארוזה קוראת אותה. סביבות הרצה מסוימות מגיעות עם תבנית משלהן במקום קובץ ה-Jinja מהמאגר המקורי, ואז המשתנה מושמט ללא הודעת שגיאה. ניתן לוודא זאת על ידי שליחת אותו prompt ברמה הנמוכה ביותר וברמה הגבוהה ביותר עם temperature על 0 והשוואת ה-eval_count. אם הספירות זהות בטווח השגיאה, הרמה אינה נלקחת בחשבון.

האם רמת מאמץ הסקה נמוכה הופכת את המודל לפחות מדויק?

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