مقامی LLM کی tokens per second کیسے ناپیں

GPU کی لاگت کا جواز طے کرنے میں tokens per second کیوں فیصلہ کن ہے

Tokens per second وہ شرح ہے جس پر آپ کا server output text تیار کرتا ہے۔ یہی عدد طے کرتا ہے کہ GPU کرائے پر لینا فی token API کو ادائیگی کرنے سے سستا ہے یا نہیں۔ GPU box کے لیے فی گھنٹہ billing ہوتی ہے، چاہے وہ مصروف ہو یا idle۔ Hosted API کے لیے فی token billing ہوتی ہے۔ اس لیے GPU صرف اسی صورت میں فائدہ مند ہے جب ادائیگی کیے گئے زیادہ تر گھنٹوں میں output rate کافی بلند رہے۔

اس کا مطلب ہے کہ آپ کو ایک measurement درکار ہے، نہ کہ کہیں پڑھی ہوئی کوئی figure۔ یہ صفحہ record کرنے کے قابل چار numbers کی وضاحت کرتا ہے، پھر وہ commands دیتا ہے جو یہ numbers حاصل کرتی ہیں، اور آخر میں وہ arithmetic دکھاتا ہے جو انہیں فیصلے میں تبدیل کرتی ہے۔

شائع کردہ tokens per second کا عدد آپ کا عدد کیوں نہیں ہے

DigitalOcean نے July 2026 میں llama3.3-70b-instruct کو vLLM کے تحت FP8 (8-bit floating point) میں چلانے والے ایک NVIDIA H200 کے لیے throughput کے اعداد شائع کیے۔ یہ اعداد مفید ہیں، لیکن یہ آپ کے اعداد نہیں ہیں۔

[
  {
    "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"
  }
]

اوپر کی ہر row اسی صفحے سے نقل کی گئی ہے، اور ان میں سے دو اعداد وہاں دی گئی range کی کم ترین حد ہیں، اس لیے انہیں minimum سمجھیں۔ اس chart میں شامل کوئی بھی عدد ہم نے خود measure نہیں کیا۔

آخری دو rows سے شروع کریں۔ Headline عدد 4,071.6 tok/s ہے، جبکہ صرف output کی rate 2,036 tok/s ہے۔ Headline میں input اور output tokens کو ملا کر شمار کیا گیا ہے۔ اس test میں 1,024 input tokens اور 1,024 output tokens استعمال ہوئے، اس لیے headline کا تقریباً نصف output ہے۔ یہ تقسیم اہم ہے کیونکہ billing output پر ہوتی ہے، اور یہی کم رفتار والا حصہ ہے۔ Prefill، یعنی prompt پڑھنا، تمام input tokens کو ایک ہی pass میں process کرتا ہے۔ Decode، یعنی answer لکھنا، ایک وقت میں ایک token تیار کرتا ہے۔ Total-throughput headline کم لاگت والے عدد کو زیادہ لاگت والے عدد کے ساتھ average کرتا ہے۔

اب پہلی row دیکھیں۔ ایک ہی H200 جب ایک وقت میں صرف ایک request serve کرتا ہے تو 47 tok/s دیتا ہے، اس لیے اسی hardware پر saturated figure چالیس گنا سے بھی زیادہ ہے۔ یہ فرق اس لیے ہے کہ ایک decode step کے دوران GPU زیادہ تر وقت memory کا انتظار کرتا ہے، جبکہ concurrent requests اس idle وقت کو استعمال کر لیتی ہیں۔ دوسری row میں 236 tok/s، اسی model پر ایک H100 کی rate ہے، اور اسے KV cache، یعنی key and value cache، محدود کرتی ہے۔ یہ وہ per-request memory ہے جسے served conversation card پر برقرار رکھتی ہے۔ 80 GB card ایک 70B model کے لیے کم concurrent requests رکھ سکتی ہے، اس لیے یہ کم سطح پر saturate ہوتی ہے۔

Model تبدیل کریں یا input اور output کا ratio تبدیل کریں تو اوپر کے تمام اعداد بدل جائیں گے۔ Published figures آپ کی توقعات طے کرتے ہیں، budget نہیں۔ یہی اصول VPS کی دیانت دارانہ benchmarking پر بھی لاگو ہوتا ہے، disk اور network کے معاملے میں۔

اہمیت رکھنے والے چار اعداد

• پہلے token تک وقت، TTFT۔ درخواست بھیجنے اور پہلے output token کے موصول ہونے کے درمیان تاخیر۔ اس میں prefill time اور queue time شامل ہوتے ہیں۔ صارف اس تاخیر کو براہِ راست محسوس کرتا ہے۔
• ہر stream کے لیے output tokens فی second۔ جواب شروع ہونے کے بعد ایک جواب کتنی تیزی سے لکھا جاتا ہے۔ تقریباً 20 tok/s سے زیادہ رفتار پر یہ پہلے ہی زیادہ تر لوگوں کی پڑھنے کی رفتار سے زیادہ ہوتی ہے، اس لیے یہاں اضافی رفتار کا فائدہ کم ہوتا ہے۔
• مکمل load پر مجموعی output throughput۔ تمام concurrent streams کی output رفتار کا مجموعہ، جب server پوری طرح مصروف ہو۔ یہ capacity کا عدد ہے، اور GPU bill بھی اسی سے متعلق ہوتا ہے۔
• concurrency کے دوران p50 اور p99 TTFT۔ p50 درمیانی request کی قدر ہے۔ p99 وہ قدر ہے جس سے 100 میں سے 99 requests کم وقت میں مکمل ہوتی ہیں۔ Queueing کا اثر ہمیشہ پہلے p99 میں ظاہر ہوتا ہے۔

پہلے دو اعداد server کے کم مصروف ہونے پر بہتر ہوتے ہیں۔ تیسرا server کے مصروف ہونے پر بہتر ہوتا ہے۔ یہ ایک دوسرے کے خلاف اثر ڈالتے ہیں، اسی لیے کوئی ایک عدد serving box کی مکمل کارکردگی بیان نہیں کرتا۔

پیمائش سے پہلے input اور output کی لمبائیاں مقرر کریں

Throughput کا انحصار network traffic کی ساخت پر ہوتا ہے۔ 4,000-token prompt اور 50-token جواب والا کام prefill-heavy ہوتا ہے۔ 200-token prompt اور 2,000-token جواب والا کام decode-heavy ہوتا ہے۔ ایک ہی سرور ان دونوں صورتوں میں tokens per second کی نمایاں طور پر مختلف شرح دکھاتا ہے۔ اس لیے ایک ratio منتخب کریں، ریکارڈ کیے گئے ہر عدد کے ساتھ اسے درج کریں، اور مختلف ratios کے نتائج کا کبھی موازنہ نہ کریں۔ 1,024 input اور 1,024 output ایک مناسب default ہے، کیونکہ کئی vendors اسی ratio پر اعداد شائع کرتے ہیں۔ اگر آپ کو اپنا حقیقی traffic معلوم ہے تو اپنا حقیقی traffic استعمال کریں۔

Output کی لمبائی بھی مقرر کریں۔ جو model 60 tokens کے بعد stop token تک پہنچ جاتا ہے، وہ ایک مختصر run مکمل کرتا ہے جو زیادہ تیز دکھائی دیتا ہے، کیونکہ TTFT اس run کا بڑا حصہ بن جاتا ہے۔ vLLM benchmark client میں موجود --ignore-eos flag ہر request کو عین مطلوبہ count پیدا کرنے پر مجبور کرتا ہے، اس لیے دونوں runs قابلِ موازنہ رہتے ہیں۔ Model کا انتخاب ان اعداد کو کسی بھی flag سے زیادہ متاثر کرتا ہے: ایک Qwen 3 model کو single VPS GPU پر چلانے کے لیے فٹ کرنا اس انتخاب کے memory پہلو کی وضاحت کرتا ہے۔

پہلے ایک stream کی پیمائش کریں

سب سے سادہ صورت سے شروع کریں۔ یہ sanity check بھی ہے اور maximum حد بھی۔ Ollama اپنی timing خود دکھاتا ہے۔

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

پڑھنے والی لائن eval rate ہے، جو output tokens per second ہے۔ prompt eval rate prefill rate ہے، جبکہ load duration model کو VRAM میں load کرنے میں صرف ہونے والا وقت ہے۔ cold start کے بعد پہلی call پر load duration بڑا ہوتا ہے، اس لیے total duration گمراہ کن ہے۔ command دو بار چلائیں اور دوسرا نتیجہ پڑھیں۔ Ollama بطور default idle model کو پانچ منٹ بعد unload کر دیتا ہے، اس لیے runs کے درمیان طویل وقفہ آپ کو دوبارہ cold case میں لے جاتا ہے۔

یہی fields API سے بھی حاصل کی جا سکتی ہیں، اور API کو script میں استعمال کرنا آسان ہے۔

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 nanoseconds میں ہوتا ہے، اس لیے اسے 1,000,000,000 سے تقسیم کرنے پر seconds حاصل ہوتے ہیں۔ Ollama کی اپنی API documentation بھی tokens per second کے لیے یہی تقسیم تجویز کرتی ہے۔ اگر server ابھی up نہیں ہے تو VPS پر Ollama کے ساتھ LLM کی self-hosting میں installation اور systemd unit کا طریقہ دیا گیا ہے۔

TTFT کے لیے streaming request درکار ہوتی ہے، اور 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 وہ لمحہ ہے جب response body کا پہلا byte موصول ہوتا ہے۔ streaming chat completion میں یہ byte پہلے server-sent event سے متعلق ہوتا ہے۔ یہ event یا تو پہلا content token ہوتا ہے یا اس سے فوراً پہلے بھیجا جانے والا صرف role والا delta۔ اس لیے اس value کو تقریباً ایک event کے فرق کے ساتھ TTFT سمجھیں۔ ایک ہی server پر دو runs کا موازنہ کرنے کے لیے یہ کافی درست ہے۔

Single-stream numbers server کی صلاحیت کو دو بار زیادہ ظاہر کرتے ہیں۔ TTFT اپنی بہترین ممکنہ حالت میں ہوتا ہے، کیونکہ آپ سے پہلے کوئی request queue میں نہیں ہوتی۔ فی stream rate بھی اپنی بہترین ممکنہ حالت میں ہوتا ہے، کیونکہ پورا card ایک ہی request کو serve کر رہا ہوتا ہے۔ ان میں سے کوئی بھی یہ نہیں بتاتا کہ server حقیقت میں کتنا load سنبھال سکتا ہے۔

آپ concurrency sweep کیسے چلاتے ہیں؟

Sweep میں ایک مقررہ workload کو بڑھتی ہوئی concurrency کے ساتھ چلایا جاتا ہے، اور ہر مرحلے پر نتیجہ record کیا جاتا ہے۔ vLLM اس مقصد کے لیے client فراہم کرتا ہے۔ یہ OpenAI API استعمال کرتا ہے، اس لیے Ollama اور دیگر OpenAI-compatible سروسز کے خلاف بھی کام کرتا ہے۔

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 زیرِ تکمیل requests کی تعداد محدود کرتا ہے، اور یہی وہ variable ہے جسے آپ sweep کر رہے ہیں۔ --num-prompts بھیجی جانے والی کل requests ہیں، اس لیے مستحکم average حاصل کرنے کے لیے اسے concurrency سے تقریباً دس گنا رکھیں۔ Summary میں Output token throughput (tok/s): اور Total token throughput (tok/s):، پھر Mean TTFT (ms):، Median TTFT (ms): اور P99 TTFT (ms):، Time to First Token heading کے تحت دکھائے جاتے ہیں۔

اس output میں ہر stream کی rate شامل نہیں ہوتی، لیکن اسے ایک division سے حاصل کیا جا سکتا ہے۔ Mean TPOT (ms): پہلے output token کے بعد ہر output token کے لیے اوسط وقت ہے۔ اس لیے فی token 25 ms کا مطلب ہر stream کے لیے 40 tokens per second ہے۔ Output throughput کو concurrency پر تقسیم کرنے سے بھی یہی نتیجہ ملتا ہے۔

اب اسے loop میں چلائیں اور ہر run محفوظ کریں۔

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 rows ایک چھوٹے کرائے کے قابل GPU box پر sweep سے بننے والی شکل کی مثال ہیں، اور ان کی مقداریں قابلِ قبول حدود میں رکھی گئی ہیں۔ یہ آپ کے server کی پیمائش نہیں ہیں، اور نہ ہی کسی vendor کے اعداد و شمار ہیں۔ اوپر دیا گیا loop چلائیں اور ان کی جگہ اپنے اعداد و شمار درج کریں۔

اس شکل کو سمجھیں، کیونکہ یہی شکل مختلف حالات میں بھی عمومی طور پر برقرار رہتی ہے۔ ایک stream پر پورا box فی second 92 tokens پیدا کرتا ہے، جبکہ p99 TTFT 61 ms ہے۔ 128 streams پر مجموعی رفتار 2304 tokens فی second تک پہنچ جاتی ہے، جو 25 گنا زیادہ ہے، لیکن ہر stream کی رفتار کم ہو کر 18 tokens فی second رہ جاتی ہے اور p99 TTFT بڑھ کر 3820 ms ہو جاتا ہے۔ مجموعی throughput اس لیے بڑھتا ہے کہ batching، غیر فعال memory waits کو مفید کام میں تبدیل کر دیتی ہے۔ ہر stream کی رفتار اس لیے کم ہوتی ہے کہ اب وہی compute متعدد streams میں تقسیم ہو رہا ہے۔

آخری doubling اصل صورتِ حال واضح کرتی ہے۔ 64 سے 128 streams تک جانے سے مجموعی throughput میں 6 فیصد سے بھی کم اضافہ ہوتا ہے، جبکہ p99 TTFT تقریباً 3 گنا بڑھ جاتا ہے۔ اس کا مطلب ہے کہ KV cache بھر چکا ہے اور requests چلنے کے بجائے queue میں جا رہی ہیں۔ مفید operating point اس سے پہلے آتا ہے: 32 streams پر box اب بھی 1728 tokens فی second واپس کرتا ہے، جو اپنی peak کا 75 فیصد ہے، جبکہ ہر stream کی رفتار 54 tokens فی second اور p99 TTFT 498 ms ہے۔ اسی point کو اپنی capacity کے طور پر رپورٹ کریں۔ curve کی peak ایسی تعداد ہے جس پر آپ users کو سروس فراہم نہیں کر سکتے۔

Ollama اور vLLM ایک ہی چیز کی پیمائش نہیں کرتے

اس sweep کو default Ollama server کے خلاف چلائیں تو total بمشکل تبدیل ہوگا۔ OLLAMA_NUM_PARALLEL کی default قدر 1 ہے، اس لیے ایک request چلتی ہے جبکہ باقی انتظار کرتی ہیں، اور یہی queue p99 TTFT کو بڑھاتی ہے جبکہ total output تقریباً یکساں رہتا ہے۔ کسی بھی پیمائش سے پہلے اس قدر کو بڑھائیں۔

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"

sudo systemctl restart ollama کے ساتھ restart کریں، پھر تصدیق کریں کہ model اب بھی فٹ ہوتا ہے۔ ہر parallel slot کو context window میں اپنا حصہ ملتا ہے، اس لیے Ollama کی documentation کے مطابق 4 parallel requests کے ساتھ 2K context، 8K مختص کرتا ہے۔ slot count اتنا بڑھائیں کہ model VRAM سے باہر نکل جائے۔ ollama ps چیک کریں: اگر PROCESSOR column میں 48%/52% CPU/GPU جیسی قدر نظر آئے تو model کا کچھ حصہ CPU پر ہے، اور اب concurrency بڑھانے کے ساتھ throughput بڑھنے کے بجائے کم ہوگا۔ parallel slots کی حد سے آگے requests OLLAMA_MAX_QUEUE تک queue میں شامل ہوتی ہیں، جو default طور پر 512 ہے؛ اس کے بعد server 503 کا جواب دیتا ہے۔

vLLM continuous batching استعمال کرتا ہے، اس لیے slots خالی ہوتے ہی یہ نئی requests کو جاری batch میں شامل کر لیتا ہے، اور اس کی curve اس وقت تک بڑھتی رہتی ہے جب تک KV cache ختم نہ ہو جائے۔ Ollama ایک model، ایک machine اور کم setup cost کے لیے optimize کیا گیا ہے۔ اسی لیے دونوں engines ایک ہی sweep پر مختلف نتائج دیتے ہیں، اور یہی Ollama اور vLLM کا serving engines کے طور پر تقابل کا اصل موضوع ہے۔ ہر number کے ساتھ یہ بھی record کریں کہ اسے کس engine اور کس version نے پیدا کیا۔

غلط چیز کی پیمائش کرنے کے 5 طریقے

• کلائنٹ بہت دور تھا۔ انٹرنیٹ کے ذریعے اپنے laptop سے benchmark چلانے پر ہر TTFT میں آپ کا round trip time شامل ہو جاتا ہے، اس لیے پیمائش دراصل آپ کے home connection کی ہوتی ہے۔ کلائنٹ کو server والے ہی region میں چلائیں۔
• ماڈل cold تھا۔ پہلی request میں weights load کرنے کا وقت شامل ہوتا ہے، اور vLLM میں graph capture کا وقت بھی شامل ہو سکتا ہے۔ ایک warmup batch بھیجیں اور اس کا result خارج کر دیں۔
• Prefix caching نے آپ کی جگہ جواب دیا۔ vLLM default طور پر automatic prefix caching enabled رکھتا ہے، اس لیے ایک ہی prompt بار بار بھیجنے سے prefill کے بجائے cache کی پیمائش ہوتی ہے، اور TTFT حقیقی قدر کے ایک حصے تک کم ہو جاتا ہے۔ --dataset-name random اس مسئلے سے بچاتا ہے کیونکہ ہر prompt مختلف ہوتا ہے۔ یقین کرنے کے لیے server کو --no-enable-prefix-caching کے ساتھ start کریں۔
• Outputs مختصر تھے۔ 32-token جوابات میں ہر request پر TTFT غالب آ جاتا ہے، اس لیے tokens per second دراصل prefill کو بیان کرتا ہے۔ حقیقت پسندانہ output length کے ساتھ --ignore-eos استعمال کریں۔
• آپ نے concurrency 1 رپورٹ کی۔ جدول میں یہ سب سے خوش آئند number ہے، لیکن اس کا cost سے کوئی تعلق نہیں۔

اپنے پیمائش شدہ عدد کو فیصلے میں تبدیل کریں

اپنے sweep سے حاصل شدہ saturated output throughput استعمال کریں، single-stream rate نہیں، اور اسے per-token pricing کے ساتھ compare کریں۔ break-even ایک division سے معلوم ہوتا ہے:

break_even_tok_s = (price_per_hour / price_per_million_output_tokens) * 1000000 / 3600

DigitalOcean کی July 2026 prices کے ساتھ حساب دیکھیں۔ ان کا H200 dedicated inference endpoint $4.47 فی گھنٹہ تھا، جبکہ serverless متبادل $0.65 فی million tokens تھا۔ لہذا 4.47 کو 0.65 پر تقسیم کرنے سے 6.88 million tokens فی گھنٹہ حاصل ہوتے ہیں، اور 3,600 seconds سے تقسیم کرنے پر تقریباً 1,910 output tokens فی second آتے ہیں۔ prices ان کی ہیں۔ division ہماری ہے۔

اس فیصلے کا تعین کرنے والا لفظ sustained ہے۔ saturation پر دو گھنٹے روزانہ 1,910 tokens فی second حاصل کرنا 1,910 tokens فی second sustained نہیں ہے، کیونکہ باقی بائیس گھنٹوں کی ادائیگی بھی آپ کرتے ہیں۔ DigitalOcean کے مطابق کم قیمت والے $3.44 فی گھنٹہ GPU Droplet کا crossover 72.2 percent sustained average utilisation پر آتا ہے، اور اس سے کم utilisation پر per-token price بہتر رہتی ہے۔ عموماً self-hosting کو slow tokens نہیں بلکہ idle GPU hours نقصان پہنچاتے ہیں۔

لہذا آپ کے فیصلے کے دو inputs ہیں۔ sweep آپ کو ceiling فراہم کرتا ہے۔ آپ کا traffic pattern بتاتا ہے کہ اس ceiling کا کتنا حصہ حقیقت میں حاصل ہوتا ہے۔ دونوں کو multiply کریں، پھر نتیجے کو GPU VPS اور per-token API کے break-even کا موازنہ تک لے جائیں اور اپنے volume کے مطابق جواب معلوم کریں۔

FAQ

self-hosted LLM کے لیے فی سیکنڈ tokens کی اچھی شرح کیا ہے؟

اس کے دو جواب ہیں، کیونکہ یہ پیمانہ دو مختلف کام کرتا ہے۔ اگر ایک شخص output پڑھ رہا ہو تو ہر stream کے لیے تقریباً 20 output tokens فی سیکنڈ سے زیادہ رفتار پہلے ہی پڑھنے کی رفتار سے زیادہ ہے، اس لیے مزید رفتار فائدہ نہیں دیتی۔ لاگت کے لیے اہم عدد مجموعی saturated output throughput ہے، اور اچھی شرح وہ ہے جو break-even حد عبور کر دے۔ $4.47 فی گھنٹہ لاگت والے server پر فی million tokens $0.65 کی قیمت کے مقابلے میں، July 2026 کی قیمتوں پر یہ حد مسلسل تقریباً 1,910 output tokens فی سیکنڈ بنتی ہے۔ ایک بڑے model پر ایک stream کبھی اس حد تک نہیں پہنچتی، اسی لیے batching استعمال کی جاتی ہے۔

متعدد concurrent requests شامل کرنے پر میرے Ollama کا throughput یکساں کیوں رہتا ہے؟

OLLAMA_NUM_PARALLEL کی default قدر 1 ہے، اس لیے server ہر model کے لیے ایک وقت میں صرف ایک request چلاتا ہے اور باقی requests کو queue میں رکھتا ہے۔ یہ سلسلہ OLLAMA_MAX_QUEUE تک جاری رہتا ہے، جس کی default قدر 512 ہے؛ اس کے بعد server 503 واپس کرتا ہے۔ جب p99 TTFT بڑھتا رہے لیکن مجموعی output یکساں رہے تو یہ مصروف GPU کے بجائے queue کی علامت ہے۔ systemd drop-in میں یہ variable set کر کے service restart کریں، پھر ollama ps چیک کریں، کیونکہ ہر parallel slot allocated context کو کئی گنا بڑھاتا ہے اور model کے ایک حصے کو CPU پر منتقل کر سکتا ہے۔

کیا مجھے time to first token ناپنا چاہیے یا tokens per second؟

دونوں ناپیں، کیونکہ load بڑھنے پر یہ مخالف سمتوں میں تبدیل ہوتے ہیں۔ TTFT وہ چیز ہے جسے user محسوس کرتا ہے، جبکہ saturated output throughput وہ چیز ہے جو آپ کے invoice میں ظاہر ہوتی ہے۔ ہر concurrency مرحلے پر p50 اور p99 TTFT ریکارڈ کریں، پھر وہ سب سے زیادہ concurrency منتخب کریں جہاں p99 TTFT اب بھی آپ کے لیے قابل قبول ہو۔ اسی مقام کا throughput اپنی capacity کے طور پر رپورٹ کریں، نہ کہ curve کے بلند ترین حصے سے حاصل ہونے والی زیادہ سے زیادہ شرح۔

کیا tokens per second کی زیادہ شرح ہمیشہ فی token کم لاگت کا مطلب ہوتی ہے؟

نہیں۔ فی token لاگت اس hourly price کو ان tokens سے تقسیم کرنے سے معلوم ہوتی ہے جو server نے اس گھنٹے میں حقیقتاً produce کیے ہوں۔ اس لیے دن کے زیادہ حصے میں idle رہنے والے تیز server کی فی token لاگت پھر بھی زیادہ ہو سکتی ہے۔ اس کا فیصلہ peak speed نہیں بلکہ utilisation کرتا ہے۔ Units بھی دیکھیں: quoted total token throughput میں input tokens بھی شامل ہوتے ہیں، اس لیے 1:1 input-to-output ratio پر یہ اس output rate سے تقریباً دوگنا ہوتا ہے جس کی billing ہوتی ہے۔