איך למדוד tokens per second ב-LLM מקומי בצורה נכונה

מדוע מספר ה-tokens לשנייה קובע אם השכרת GPU משתלמת

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

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

מדוע נתון ה-tokens per second שפורסם אינו המספר שלכם

ביולי 2026 פרסמה DigitalOcean נתוני תפוקה עבור NVIDIA H200 בודד המריץ את llama3.3-70b-instruct בפורמט FP8 (נקודה צפה של 8-ביט) תחת vLLM. הנתונים שימושיים, אך הם אינם משקפים את הביצועים שלכם.

[
  {
    "config": "H200, one stream",
    "tok_s": "47"
  },
  {
    "config": "H100, saturated",
    "tok_s": "236"
  },
  {
    "config": "H200, saturated",
    "tok_s": "2,036"
  },
  {
    "config": "H200, saturated, in+out",
    "tok_s": "4,071.6"
  }
]

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

נתחיל בשתי השורות האחרונות. הכותרת מציגה 4,071.6 tok/s, בעוד שקצב הפלט בלבד הוא 2,036 tok/s. הכותרת מחשבת את טוקני הקלט והפלט יחד. הבדיקה ההיא השתמשה ב-1,024 טוקני קלט מול 1,024 טוקני פלט, כך שכמעט מחצית מהכותרת מורכבת מפלט. החלוקה הזו חשובה כי הפלט הוא החצי שעליו אתם מחויבים בתשלום, והוא החצי האיטי. שלב ה-prefill (קריאת ה-prompt) מעבד את כל טוקני הקלט במעבר אחד. שלב ה-decode (כתיבת התשובה) מייצר טוקן אחד בכל פעם. כותרת של תפוקה כוללת עושה ממוצע בין מספר "זול" לבין מספר "יקר".

כעת לשורה הראשונה. אותו H200 המשרת בקשה אחת בכל פעם מייצר 47 tok/s, כך שהנתון במצב רוויה גבוה פי ארבעים על גבי חומרה זהה. הפער הזה קיים כיוון ששלב decode בודד מותיר את ה-GPU בהמתנה לזיכרון ברוב הזמן, ובקשות מקבילות ממלאות את זמן ההמתנה הזה. השורה השנייה, 236 tok/s, היא של H100 בודד על אותו מודל, המוגבל על ידי ה-KV cache (מטמון ה-key וה-value, הזיכרון לכל בקשה ששיחה פעילה שומרת על הכרטיס). כרטיס של 80 GB מחזיק פחות בקשות מקבילות עבור מודל 70B, ולכן הוא מגיע לרוויה בנקודה נמוכה יותר.

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

ארבעת המדדים הקריטיים

• זמן לקבלת טוקן ראשון, TTFT. העיכוב בין שליחת בקשה לבין הגעת הטוקן הראשון. מדד זה מורכב מזמן ה-prefill ומזמן ההמתנה בתור. המשתמש חווה מדד זה באופן ישיר.
• קצב טוקנים לשנייה, לכל זרם. המהירות שבה נכתבת תשובה מרגע שהחלה. מעל כ-20 טוקנים לשנייה, המהירות גבוהה יותר מקצב הקריאה של רוב האנשים, ולכן תוספת מהירות כאן אינה מועילה משמעותית.
• תפוקת פלט כוללת תחת עומס. סכום כל הזרמים המקבילים כאשר השרת מנוצל במלואו. זהו מדד הקיבולת, והוא המדד שקובע את עלות ה-GPU.
• ערכי p50 ו-p99 עבור TTFT תחת עומס. ה-p50 מייצג את הבקשה החציונית. ה-p99 הוא הערך ש-99 מתוך 100 בקשות עומדות בו. השפעת התור באה לידי ביטוי תמיד קודם כל ב-p99.

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

התאמת אורכי הקלט והפלט לפני המדידה

קצב העברת הנתונים (throughput) תלוי במבנה התעבורה. הנחיה (prompt) של 4,000 טוקנים עם תשובה של 50 טוקנים היא עבודה עתירת prefill. הנחיה של 200 טוקנים עם תשובה של 2,000 טוקנים היא עבודה עתירת decode. אותו שרת יציג נתונים שונים מאוד של טוקנים לשנייה עבור שני המקרים הללו, לכן יש לבחור יחס אחד, לתעד אותו לצד כל מספר שאתם רושמים, ולעולם לא להשוות בין יחסים שונים. יחס של 1,024 טוקנים בכניסה מול 1,024 ביציאה הוא ברירת מחדל סבירה, כיוון שספקים רבים מפרסמים נתונים לפי יחס זה. אם ידוע לכם אופי התעבורה האמיתי שלכם, השתמשו בו.

יש לכפות גם את אורך הפלט. מודל שמגיע לטוקן העצירה שלו לאחר 60 טוקנים יפיק הרצה קצרה יותר שנראית מהירה יותר, כיוון שזמן ה-TTFT מהווה חלק גדול יותר ממנה. הדגל --ignore-eos בלקוח ה-benchmark של vLLM גורם לכל בקשה לייצר בדיוק את כמות הטוקנים המבוקשת, כך ששתי הרצות נשארות בנות-השוואה. בחירת המודל משפיעה על המספרים הללו יותר מכל דגל: התאמת מודל Qwen 3 ל-GPU בודד ב-VPS מכסה את ההיבט של ניצול הזיכרון בבחירה זו.

מדידת זרם בודד תחילה

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

ollama run llama3.1:8b --verbose "Write 200 words about disk scheduling."

השורה שיש לקרוא היא eval rate, המייצגת את קצב יצירת הטוקנים לשנייה. prompt eval rate הוא קצב ה-prefill, ו-load duration הוא הזמן שהושקע בטעינת המודל ל-VRAM. בקריאה הראשונה לאחר הפעלה קרה (cold start), הערך load duration יהיה גבוה, ולכן total duration עלול להטעות. הריצו את הפקודה פעמיים וקראו את התוצאה השנייה. כברירת מחדל, Ollama פורקת מודל לא פעיל מהזיכרון לאחר חמש דקות, כך שהפסקה ארוכה בין הרצות תחזיר אתכם למצב של הפעלה קרה.

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

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Write 200 words about disk scheduling.",
  "stream": false
}' | jq '{eval_count, eval_duration,
         tok_s: (.eval_count / (.eval_duration / 1000000000))}'

הערך eval_duration הוא בננו-שניות, לכן חלוקה ב-1,000,000,000 תיתן את התוצאה בשניות. חלוקה זו היא בדיוק מה שתיעוד ה-API של Ollama מורה לבצע עבור חישוב טוקנים לשנייה. אם השרת עדיין אינו פעיל, המדריך אירוח עצמי של LLM עם Ollama על גבי VPS מכסה את תהליך ההתקנה ואת יחידת ה-systemd.

עבור TTFT נדרשת בקשת streaming, וניתן להשתמש ב-curl כדי למדוד זאת עבורכם.

curl -s -o /dev/null -N \
  -w 'ttfb=%{time_starttransfer}s  total=%{time_total}s\n' \
  http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen/Qwen3-8B",
       "messages":[{"role":"user","content":"Write 200 words about disk scheduling."}],
       "stream":true,"max_tokens":256}'

הערך time_starttransfer הוא הרגע שבו מגיע הבייט הראשון של גוף התגובה. בהשלמת צ'אט בזרם (streaming), בייט זה שייך לאירוע ה-server-sent הראשון, שהוא או טוקן התוכן הראשון או delta של תפקיד (role) שנשלח רגע לפניו. לכן, התייחסו לערך זה כאל TTFT בסטייה של אירוע אחד. הוא מדויק מספיק כדי להשוות בין שתי הרצות על אותו שרת.

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

כיצד מריצים בדיקת עומס (concurrency sweep)?

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

vllm bench serve \
  --backend openai-chat \
  --base-url http://127.0.0.1:8000 \
  --endpoint /v1/chat/completions \
  --model Qwen/Qwen3-8B \
  --dataset-name random \
  --random-input-len 1024 \
  --random-output-len 1024 \
  --ignore-eos \
  --num-prompts 160 \
  --max-concurrency 16 \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,99

הדגל --max-concurrency מגביל את מספר הבקשות הפעילות בו-זמנית, וזהו המשתנה שאתם משנים בבדיקה. --num-prompts הוא סך הבקשות שנשלחו, לכן מומלץ לשמור עליו ברמה של פי עשרה מהמקביליות כדי לקבל ממוצע יציב. הסיכום מדפיס את Output token throughput (tok/s): ו-Total token throughput (tok/s):, ולאחר מכן את Mean TTFT (ms):, Median TTFT (ms): ו-P99 TTFT (ms): תחת הכותרת Time to First Token.

אין פלט של קצב לכל stream בנפרד, אך ניתן לחשב זאת בקלות. Mean TPOT (ms): הוא הזמן הממוצע לכל token פלט לאחר ה-token הראשון, כך ש-25 ms לכל token שקולים ל-40 tokens לשנייה לכל stream. חילוק של תפוקת הפלט הכוללת במקביליות ייתן את אותה התוצאה.

לאחר מכן, בצעו לולאה ושמרו את התוצאות של כל הרצה.

for C in 1 4 16 32 64 128; do
  vllm bench serve \
    --backend openai-chat \
    --base-url http://127.0.0.1:8000 \
    --endpoint /v1/chat/completions \
    --model Qwen/Qwen3-8B \
    --dataset-name random \
    --random-input-len 1024 \
    --random-output-len 1024 \
    --ignore-eos \
    --num-prompts $(( C * 10 )) \
    --max-concurrency "$C" \
    --percentile-metrics ttft,tpot,itl,e2el \
    --metric-percentiles 50,99 \
    --save-result --result-filename "sweep-c$C.json"
done

for f in sweep-c*.json; do
  jq -r --arg f "$f" \
    '[$f, .output_throughput, .total_token_throughput,
      .median_ttft_ms, .p99_ttft_ms] | @tsv' "$f"
done

מה מראה בפועל סריקת מקביליות (concurrency sweep)?

[
  {
    "label": "1 stream",
    "per_stream_tok_s": 92,
    "total_tok_s": 92,
    "ttft_p50_ms": 48,
    "ttft_p99_ms": 61
  },
  {
    "label": "4 streams",
    "per_stream_tok_s": 88,
    "total_tok_s": 352,
    "ttft_p50_ms": 71,
    "ttft_p99_ms": 96
  },
  {
    "label": "16 streams",
    "per_stream_tok_s": 71,
    "total_tok_s": 1136,
    "ttft_p50_ms": 152,
    "ttft_p99_ms": 244
  },
  {
    "label": "32 streams",
    "per_stream_tok_s": 54,
    "total_tok_s": 1728,
    "ttft_p50_ms": 287,
    "ttft_p99_ms": 498
  },
  {
    "label": "64 streams",
    "per_stream_tok_s": 34,
    "total_tok_s": 2176,
    "ttft_p50_ms": 611,
    "ttft_p99_ms": 1240
  },
  {
    "label": "128 streams",
    "per_stream_tok_s": 18,
    "total_tok_s": 2304,
    "ttft_p50_ms": 1490,
    "ttft_p99_ms": 3820
  }
]

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

קרא את הצורה, כיוון שהצורה היא מה שניתן להכללה. בזרם (stream) אחד, השרת כולו מפיק 92 טוקנים לשנייה עם p99 TTFT של 61 מילי-שניות. ב-128 streams, התפוקה הכוללת מגיעה ל-2304 טוקנים לשנייה, פי עשרים וחמישה, בעוד שכל זרם בודד יורד ל-18 טוקנים לשנייה וערך ה-p99 TTFT מגיע ל-3820 מילי-שניות. התפוקה הכוללת עולה מכיוון שעיבוד באצווה (batching) הופך זמני המתנה של זיכרון פנוי לעבודה מועילה. המהירות לכל זרם יורדת מכיוון שאותו כוח חישוב מתחלק כעת בין יותר בקשות.

הכפלה האחרונה היא נקודת המפתח. מעבר מ-64 ל-128 זרמים מוסיף פחות משישה אחוזים לתפוקה הכוללת, בעוד שערך ה-p99 TTFT בערך משלש את עצמו; המשמעות היא שה-KV cache מלא והבקשות נמצאות בתור במקום לעבור עיבוד. נקודת העבודה היעילה נמצאת מוקדם יותר: ב-32 זרמים, השרת עדיין מחזיר 1728 טוקנים לשנייה, 75 אחוז מהשיא שלו, בקצב של 54 טוקנים לשנייה לכל זרם ו-p99 TTFT של 498 מילי-שניות. דווח על נקודה זו כקיבולת שלך. שיא העקומה הוא מספר שלא ניתן לספק ממנו שירות למשתמשים.

Ollama ו-vLLM אינם מודדים את אותו הדבר

הריצו את הבדיקה הזו מול שרת Ollama בהגדרות ברירת המחדל, והתוצאה הכוללת בקושי תשתנה. OLLAMA_NUM_PARALLEL מוגדר כברירת מחדל ל-1, לכן בקשה אחת רצה בזמן שהשאר ממתינות, והתור הוא הגורם לעלייה ב-p99 TTFT בעוד התפוקה הכוללת נשארת יציבה. העלו ערך זה לפני שתבצעו מדידה כלשהי.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"

בצעו הפעלה מחדש עם sudo systemctl restart ollama, ולאחר מכן ודאו שהמודל עדיין נכנס בזיכרון. כל slot מקבילי מקבל חלק משלו מחלון ההקשר (context window), לכן התיעוד של Ollama מציין כי הקשר של 2K עם 4 בקשות מקבילות מקצה 8K. העלו את מספר ה-slots מספיק כדי שהמודל יגלוש מחוץ ל-VRAM. בדקו את ollama ps: עמודת PROCESSOR המציגה ערך כמו 48%/52% CPU/GPU משמעותה שחלק מהמודל נמצא ב-CPU, ותפוקת העבודה תרד ככל שתוסיפו במקביל במקום לעלות. מעבר ל-slots המקביליים, בקשות נכנסות לתור עד OLLAMA_MAX_QUEUE, כברירת מחדל 512, ולאחר מכן השרת משיב בשגיאת 503.

vLLM משתמש ב-continuous batching, לכן הוא מכניס בקשות חדשות ל-batch הרץ ככל שמתפנים slots, והעקומה שלו ממשיכה לעלות עד שנגמר ה-KV cache. Ollama מותאם למודל אחד, מכונה אחת, ועלות הקמה נמוכה. שני המנועים מספקים לכן תשובות שונות לאותה בדיקה, וזהו הנושא האמיתי של השוואה בין Ollama ל-vLLM כמנועי הגשה. תעדו איזה מנוע ואיזו גרסה הפיקו כל מספר.

חמש דרכים למדוד את הדבר הלא נכון

• הלקוח מרוחק מדי. ביצוע benchmarking מהמחשב האישי דרך האינטרנט מוסיף את זמן ה-round trip שלכם לכל TTFT, כך שאתם מודדים את איכות החיבור הביתי שלכם. הריצו את הלקוח באותו אזור (region) שבו נמצא השרת.
• המודל היה "קר". הבקשה הראשונה סופגת את זמן טעינת המשקולות, וב-vLLM היא עשויה לספוג גם את זמן ה-graph capture. שלחו batch לחימום המערכת והתעלמו מהתוצאה שלו.
• מנגנון ה-prefix caching ענה במקומכם. vLLM מפעיל prefix caching אוטומטי כברירת מחדל, לכן שליחת אותו ה-prompt שוב ושוב מודדת את המטמון במקום את ה-prefill, וה-TTFT צונח לשבריר מהערך האמיתי. --dataset-name random מונע זאת כיוון שכל prompt שונה. כדי לוודא זאת, הפעילו את השרת עם --no-enable-prefix-caching.
• הפלט היה קצר מדי. עם תשובות של 32-token, ה-TTFT משתלט על כל בקשה ומדד ה-tokens per second שלכם מתאר למעשה רק את ה-prefill. השתמשו ב---ignore-eos עם אורך פלט ריאליסטי.
• דיווחתם על concurrency 1. זהו המספר הנוח ביותר בטבלה, אך אין לו כל קשר לעלות.

הפיכת המספר המדוד להחלטה

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

break_even_tok_s = (price_per_hour / price_per_million_output_tokens) * 1000000 / 3600

בצעו את החישוב לפי המחירים של DigitalOcean מיולי 2026. נקודת קצה להסקה (inference) ייעודית מסוג H200 עלתה 4.47 דולר לשעה, והחלופה ללא שרת (serverless) עלתה 0.65 דולר למיליון טוקנים. לכן, 4.47 חלקי 0.65 שווה 6.88 מיליון טוקנים בשעה, וחילוק ב-3,600 שניות נותן כ-1,910 טוקני פלט לשנייה. המחירים הם שלהם. החילוק הוא שלנו.

המילה הקובעת כאן היא מתמשך (sustained). הגעה ל-1,910 טוקנים לשנייה ברוויה למשך שעתיים ביום אינה שווה ל-1,910 טוקנים לשנייה באופן מתמשך, כיוון שאתם משלמים גם על עשרים ושתיים השעות הנותרות. נקודת המעבר של DigitalOcean עצמם עבור ה-GPU Droplet הזול יותר, שעולה 3.44 דולר לשעה, נמצאת ב-72.2 אחוז ניצולת ממוצעת מתמשכת; מתחת לשיעור זה, המחיר לפי טוקן משתלם יותר. שעות GPU בטלות, ולא טוקנים איטיים, הן בדרך כלל הגורם שמפיל אירוח עצמי.

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

FAQ

מהו קצב tokens לשנייה טוב עבור LLM באירוח עצמי?

ישנן שתי תשובות, כיוון שהמדד משרת שתי מטרות. עבור אדם יחיד שקורא את הפלט, כל קצב הגבוה מ-20 tokens לשנייה לכל stream הוא מהיר יותר מקצב קריאה אנושי, ולכן מהירות גבוהה יותר אינה מועילה. מבחינת עלות, המספר הקובע הוא סך תפוקת הפלט המקסימלית (saturated throughput), וקצב "טוב" הוא כזה שמכסה את נקודת האיזון שלכם. בהשוואה למחיר של $0.65 למיליון tokens על שרת שעולה $4.47 לשעה, רף הכדאיות עומד על כ-1,910 tokens לשנייה בממוצע מתמשך לפי מחירי יולי 2026. stream יחיד במודל גדול לעולם לא יגיע לקצב זה, וזו הסיבה לקיומו של batching.

מדוע התפוקה של Ollama נשארת קבועה כשאני מוסיף בקשות במקביל?

OLLAMA_NUM_PARALLEL מוגדר כברירת מחדל ל-1, לכן השרת מעבד בקשה אחת בכל פעם לכל מודל ומכניס את השאר לתור, עד למקסימום של OLLAMA_MAX_QUEUE (512 כברירת מחדל) לפני החזרת שגיאת 503. סך הפלט נשאר קבוע בעוד ה-p99 TTFT עולה, מה שמעיד על קיומו של תור ולא על עומס ב-GPU. הגדירו את המשתנה ב-systemd drop-in ובצעו restart, לאחר מכן בדקו את ollama ps, כיוון שכל slot מקבילי מכפיל את ה-context המוקצה ועלול לדחוף חלק מהמודל ל-CPU.

האם עליי למדוד זמן ל-token ראשון (TTFT) או tokens לשנייה?

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

האם מספר גבוה יותר של tokens לשנייה תמיד אומר עלות נמוכה יותר ל-token?

לא. עלות ל-token היא המחיר השעתי חלקי כמות ה-tokens שהשרת הפיק בפועל באותה שעה, לכן שרת מהיר שנמצא ב-idle רוב היום עדיין מתאפיין בעלות גבוהה ל-token. הניצולת (utilisation) היא הקובעת, לא המהירות בשיא. שימו לב גם ליחידות המידה: תפוקת tokens כוללת המצוינת בנתונים סופרת גם tokens של קלט, כך שביחס של 1:1 בין קלט לפלט, המספר קרוב לכפול מקצב הפלט שעליו אתם מחויבים בתשלום.