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

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

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

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

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

ביולי 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 טוקנים לשנייה, בעוד שקצב הפלט בלבד הוא 2,036 טוקנים לשנייה. הכותרת מחשבת טוקני קלט ופלט יחד. הבדיקה ההיא השתמשה ב-1,024 טוקני קלט מול 1,024 טוקני פלט, כך שכמעט בדיוק מחצית מהנתון בכותרת הוא פלט. החלוקה הזו חשובה כי הפלט הוא החצי שעליו אתם מחויבים בתשלום, והוא החצי האיטי. שלב ה-Prefill (קריאת ה-prompt) מעבד את כל טוקני הקלט במעבר אחד. שלב ה-Decode (כתיבת התשובה) מייצר טוקן אחד בכל פעם. נתון תפוקה כולל עושה ממוצע בין מספר "זול" למספר "יקר".

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

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

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

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

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

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

קצב העברת הנתונים (throughput) תלוי באופי התעבורה. Prompt של 4,000 טוקנים עם תשובה של 50 טוקנים הוא עבודה עתירת prefill. Prompt של 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. בקריאה הראשונה לאחר הפעלה קרה, 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 הוא הרגע שבו מגיע הבית הראשון של גוף התגובה. בבקשת chat completion עם streaming, בית זה שייך לאירוע ה-server-sent event הראשון, שהוא או טוקן התוכן הראשון או delta המכיל תפקיד בלבד שנשלח רגע לפניו. לכן, התייחסו לערך זה כאל ה-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 לחימום (warmup) והתעלמו מהתוצאה שלו.
• Prefix caching ענה במקומכם. vLLM מפעיל prefix caching אוטומטי כברירת מחדל, לכן שליחת אותו ה-prompt שוב ושוב מודדת את ה-cache במקום את ה-prefill, וה-TTFT צונח לשבריר מהערך האמיתי. --dataset-name random מונע זאת כיוון שכל prompt שונה. כדי לוודא זאת, הפעילו את השרת עם --no-enable-prefix-caching.
• הפלט היה קצר מדי. עם תשובות של 32-token, ה-TTFT הוא הגורם הדומיננטי בכל בקשה, ומדד ה-tokens per second שלכם מתאר למעשה רק את ה-prefill. השתמשו ב---ignore-eos עם אורך פלט ריאליסטי.
• דיווחתם על concurrency 1. זהו המספר הנוח ביותר בטבלה, אך אין לו כל קשר לעלות.

הפיכת המדידה להחלטה

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

break_even_tok_s = (price_per_hour / price_per_million_output_tokens) * 1000000 / 3600

נבצע את החישוב לפי המחירים של DigitalOcean מיולי 2026. נקודת קצה (endpoint) ייעודית מסוג H200 עלתה 4.47 דולר לשעה, והחלופה ללא שרת (serverless) עלתה 0.65 דולר למיליון טוקנים. חילוק של 4.47 ב-0.65 נותן 6.88 מיליון טוקנים בשעה, וחילוק ב-3,600 שניות מניב כ-1,910 טוקני פלט לשנייה. המחירים הם שלהם. החישוב הוא שלנו. בבדיקה שערכנו ב-7 באוקטובר 2026, נקודת הקצה H200 עדיין עלתה 4.47 דולר לשעה, אך DigitalOcean הפסיקה את התמיכה ב-serverless Llama 3.3 70B ב-18 באוגוסט 2026 והפנתה משתמשים ל-Llama 4 Maverick, שמתומחר ב-0.87 דולר למיליון טוקני פלט. מדובר במודל שונה, ולכן הוא דורש בדיקה משלו לפני שההשוואה תהיה רלוונטית.

המילה הקובעת כאן היא sustained (מתמשך). הגעה ל-1,910 טוקנים לשנייה ברוויה למשך שעתיים ביום אינה נחשבת ל-1,910 טוקנים לשנייה באופן מתמשך, כיוון שאתם משלמים גם על עשרים ושתיים השעות הנותרות. השכרת הכרטיס כ-GPU Droplet אינה מורידה את הרף: ב-7 באוקטובר 2026, מחירון ה-Droplet של DigitalOcean הציג את ה-H200 במחיר של 4.47 דולר לשעה לפי דרישה, בדיוק כמו נקודת הקצה. ה-GPU Droplets הזולים ביותר שלהם, ה-RTX 4000 במחיר 0.76 דולר לשעה וה-L40S או ה-RTX 6000 במחיר 1.57 דולר לשעה, קטנים מדי מכדי להריץ מודל 70B ב-FP8. לכן, לפי הנתונים לעיל, שרת H200 שמגיע לרוויה של 2,036 טוקני פלט לשנייה חייב לשמור על ממוצע של כ-94 אחוזים מהשיא הזה בכל שעה שאתם משלמים עליה, רק כדי להשוות למחיר של 0.65 דולר למיליון טוקנים. מתחת לרף הזה, מחיר ה-per-token משתלם יותר. שעות GPU במצב סרק, ולא איטיות בטוקנים, הן בדרך כלל הגורם שהופך אירוח עצמי ללא כדאי.

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

FAQ

מהו קצב אסימונים (tokens) לשנייה סביר עבור מודל שפה (LLM) באירוח עצמי?

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

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

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

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

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

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

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