Local LLM पर tokens per second कैसे मापें

Tokens per second यह क्यों तय करता है कि GPU का उपयोग किफायती है या नहीं

Tokens per second वह दर है जिस पर आपका सर्वर आउटपुट टेक्स्ट तैयार करता है। यही वह संख्या है जो यह तय करती है कि GPU किराए पर लेना, प्रति टोकन API शुल्क देने से सस्ता है या नहीं। GPU बॉक्स का बिल प्रति घंटे के हिसाब से आता है, चाहे वह व्यस्त हो या खाली। होस्ट की गई API का बिल प्रति टोकन के हिसाब से आता है। इसलिए, GPU तभी फायदेमंद होता है जब आप उन घंटों के दौरान, जिनका आप भुगतान कर रहे हैं, पर्याप्त उच्च आउटपुट दर बनाए रखें।

इसका मतलब है कि आपको एक माप (measurement) की आवश्यकता है, न कि किसी ऐसी संख्या की जिसे आपने कहीं पढ़ा हो। यह पृष्ठ उन चार संख्याओं को परिभाषित करता है जिन्हें रिकॉर्ड करना आवश्यक है, फिर उन commands को देता है जो उन्हें उत्पन्न करती हैं, और वह गणित बताता है जो उन्हें एक निर्णय में बदल देता है।

प्रकाशित tokens per second का आंकड़ा आपका वास्तविक नंबर क्यों नहीं है

DigitalOcean ने जुलाई 2026 में vLLM के अंतर्गत FP8 (8-bit floating point) में llama3.3-70b-instruct चलाने वाले एक 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"
  }
]

ऊपर दी गई हर पंक्ति उसी पेज से ली गई है, और उनमें से दो आंकड़े दी गई रेंज का निचला स्तर हैं, इसलिए उन्हें न्यूनतम सीमा (floor) के रूप में पढ़ें। इस चार्ट में मौजूद किसी भी आंकड़े को हमने नहीं मापा है।

अंतिम दो पंक्तियों से शुरुआत करें। मुख्य आंकड़ा 4,071.6 tok/s है, जबकि केवल output की दर 2,036 tok/s है। मुख्य आंकड़ा input और output tokens को मिलाकर गिना जाता है। उस परीक्षण में 1,024 input tokens के मुकाबले 1,024 output tokens का उपयोग किया गया था, इसलिए मुख्य आंकड़े का लगभग आधा हिस्सा output है। यह विभाजन महत्वपूर्ण है क्योंकि output वह आधा हिस्सा है जिसके लिए आपसे शुल्क लिया जाता है, और यह धीमा हिस्सा भी है। Prefill (प्रॉम्प्ट पढ़ना) सभी input tokens को एक बार में प्रोसेस करता है। Decode (उत्तर लिखना) एक बार में एक token उत्पन्न करता है। कुल throughput का मुख्य आंकड़ा एक सस्ते नंबर और एक महंगे नंबर का औसत होता है।

अब पहली पंक्ति देखें। वही H200 एक समय में एक request सर्व करते हुए 47 tok/s उत्पन्न करता है, इसलिए समान हार्डवेयर पर saturated आंकड़ा चालीस गुना से अधिक है। यह अंतर इसलिए है क्योंकि एक single decode step GPU को अधिकांश समय मेमोरी पर प्रतीक्षा करने के लिए मजबूर करता है, और concurrent requests उस खाली समय को भर देते हैं। दूसरी पंक्ति, 236 tok/s, उसी मॉडल पर एक single H100 है, जो KV cache (key and value cache, वह प्रति-request मेमोरी जो एक सर्व की गई बातचीत कार्ड पर रखती है) के कारण सीमित है। एक 80 GB कार्ड 70B मॉडल के लिए कम concurrent requests को होल्ड कर पाता है, इसलिए यह कम पर ही saturate हो जाता है।

मॉडल बदलें या input-to-output अनुपात बदलें, तो ऊपर दिया गया हर नंबर बदल जाएगा। प्रकाशित आंकड़े आपकी अपेक्षाएं निर्धारित करते हैं, न कि आपका बजट। यही नियम VPS की ईमानदारी से बेंचमार्किंग करने पर डिस्क और नेटवर्क के लिए भी लागू होता है।

महत्वपूर्ण चार आंकड़े

• Time to first token, TTFT: अनुरोध भेजने और पहले आउटपुट टोकन के आने के बीच का विलंब। यह प्रीफिल समय और कतार (queue) में लगे समय का योग है। उपयोगकर्ता इसे सीधे महसूस करता है।
• Output tokens per second, per stream: एक बार शुरू होने के बाद एक उत्तर कितनी तेजी से लिखा जा रहा है। लगभग 20 tok/s से अधिक की गति अधिकांश लोगों के पढ़ने की गति से तेज होती है, इसलिए इससे अधिक गति का बहुत कम लाभ मिलता है।
• Saturated total output throughput: सर्वर के पूरी तरह लोड होने पर सभी समवर्ती (concurrent) स्ट्रीम का कुल योग। यह क्षमता का आंकड़ा है, और यही वह संख्या है जो GPU के खर्च को सार्थक बनाती है।
• p50 and p99 TTFT under concurrency: p50 मध्यम अनुरोध है। p99 वह मान है जिसके अंतर्गत 100 में से 99 अनुरोध पूरे हो जाते हैं। कतारबद्ध होने की समस्या सबसे पहले p99 में दिखाई देती है।

सर्वर के खाली होने पर पहले दो आंकड़े बेहतर होते हैं। सर्वर के व्यस्त होने पर तीसरा आंकड़ा बेहतर होता है। ये एक-दूसरे के विपरीत काम करते हैं, यही कारण है कि कोई भी एक अकेला आंकड़ा सर्विंग बॉक्स की पूरी क्षमता को नहीं दर्शाता है।

माप लेने से पहले इनपुट और आउटपुट की लंबाई को ठीक करें

थ्रूपुट (throughput) ट्रैफिक के स्वरूप पर निर्भर करता है। 4,000-token का प्रॉम्प्ट और 50-token का उत्तर prefill-heavy कार्य है। 200-token का प्रॉम्प्ट और 2,000-token का उत्तर decode-heavy कार्य है। एक ही सर्वर इन दोनों स्थितियों के लिए tokens per second के बहुत अलग आंकड़े देता है, इसलिए एक अनुपात चुनें, उसे अपने द्वारा रिकॉर्ड किए गए प्रत्येक नंबर के साथ लिखें, और कभी भी अलग-अलग अनुपातों की तुलना न करें। 1,024 इनपुट और 1,024 आउटपुट एक उचित डिफ़ॉल्ट है क्योंकि कई वेंडर इसी अनुपात पर आंकड़े प्रकाशित करते हैं। यदि आप अपने वास्तविक ट्रैफिक को जानते हैं, तो उसी का उपयोग करें।

आउटपुट की लंबाई को भी बाध्य (force) करें। जो मॉडल 60 tokens के बाद अपने स्टॉप टोकन पर पहुँच जाता है, वह एक छोटा रन देता है जो तेज़ दिखता है, क्योंकि ऐसी स्थिति में TTFT उसका एक बड़ा हिस्सा बन जाता है। vLLM बेंचमार्क क्लाइंट में --ignore-eos फ्लैग प्रत्येक रिक्वेस्ट को ठीक उतनी ही संख्या में जनरेट करने के लिए मजबूर करता है जितनी मांगी गई है, जिससे दो रन आपस में तुलना योग्य बने रहते हैं। किसी भी फ्लैग की तुलना में मॉडल का चुनाव इन आंकड़ों को अधिक प्रभावित करता है: एक सिंगल VPS GPU पर Qwen 3 मॉडल को फिट करना इस चुनाव के मेमोरी पक्ष को कवर करता है।

सबसे पहले एक स्ट्रीम को मापें

सबसे सरल स्थिति से शुरुआत करें। यह एक sanity check है और यह अधिकतम क्षमता (ceiling) को दर्शाता है। Ollama अपनी टाइमिंग स्वयं प्रिंट करता है।

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

पढ़ने वाली लाइन eval rate है, जो प्रति सेकंड आउटपुट टोकन की संख्या है। prompt eval rate प्रीफिल दर है, और 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 से विभाजित करने पर सेकंड प्राप्त होते हैं। वह विभाजन बिल्कुल वही है जो Ollama का अपना API दस्तावेज़ प्रति सेकंड टोकन के लिए निर्धारित करता है। यदि सर्वर अभी तक चालू नहीं है, तो Ollama के साथ VPS पर LLM को self-host करना इंस्टॉलेशन और systemd यूनिट को कवर करता है।

TTFT के लिए एक स्ट्रीमिंग अनुरोध की आवश्यकता होती है, और 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 वह क्षण है जब रिस्पॉन्स बॉडी का पहला बाइट आता है। स्ट्रीमिंग चैट कंप्लीशन पर वह बाइट पहले सर्वर-सेंट इवेंट से संबंधित होता है, जो या तो पहला कंटेंट टोकन होता है या उससे ठीक पहले भेजा गया रोल-ओनली डेल्टा। इसलिए इस मान को एक इवेंट के अंतर के साथ TTFT मानें। यह एक ही सर्वर पर दो रन की तुलना करने के लिए पर्याप्त सटीक है।

सिंगल-स्ट्रीम संख्याएं बॉक्स की क्षमता को बढ़ा-चढ़ाकर दिखाती हैं। TTFT सबसे बेहतर स्थिति है, क्योंकि आपके आगे कुछ भी कतार में नहीं है। प्रति-स्ट्रीम दर सबसे बेहतर स्थिति है, क्योंकि पूरा कार्ड एक ही अनुरोध को पूरा कर रहा है। इनमें से कोई भी यह नहीं बताता कि बॉक्स कितना लोड उठा सकता है।

आप concurrency sweep कैसे चलाते हैं?

एक sweep बढ़ती हुई concurrency पर एक निश्चित workload चलाता है और हर चरण पर होने वाली गतिविधियों को रिकॉर्ड करता है। 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 की संख्या है, इसलिए एक स्थिर औसत प्राप्त करने के लिए इसे concurrency के लगभग दस गुना रखें। सारांश Output token throughput (tok/s): और Total token throughput (tok/s): को प्रिंट करता है, और फिर Time to First Token हेडिंग के अंतर्गत Mean TTFT (ms):, Median TTFT (ms): और P99 TTFT (ms): को दिखाता है।

उस आउटपुट में प्रति-स्ट्रीम दर नहीं होती है, लेकिन इसे एक साधारण विभाजन द्वारा निकाला जा सकता है। Mean TPOT (ms): पहले टोकन के बाद प्रति आउटपुट टोकन का औसत समय है, इसलिए 25 ms प्रति टोकन का अर्थ है 40 टोकन प्रति सेकंड प्रति स्ट्रीम। आउटपुट throughput को concurrency से विभाजित करने पर भी यही उत्तर मिलता है।

इसके बाद इसे लूप में चलाएं और प्रत्येक रन को सेव करें।

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 बॉक्स पर sweep द्वारा उत्पन्न आकार का चित्रण हैं, जो संभावित परिमाण के क्रम (orders of magnitude) पर आधारित हैं। ये आपके सर्वर का मापन नहीं हैं और न ही ये किसी वेंडर द्वारा दिए गए आंकड़े हैं। ऊपर दिए गए लूप को चलाएं और इन मानों को अपने परिणामों से बदलें।

आकार को समझें, क्योंकि यही वह चीज़ है जो सामान्यीकृत (generalise) होती है। एक स्ट्रीम पर पूरा बॉक्स 92 tokens प्रति सेकंड उत्पन्न करता है, जिसका p99 TTFT 61 ms है। 128 streams पर कुल थ्रूपुट 2304 tokens प्रति सेकंड तक पहुँच जाता है, जो पच्चीस गुना अधिक है, जबकि प्रत्येक व्यक्तिगत स्ट्रीम {{q:sweep

Ollama और vLLM एक ही चीज़ को नहीं मापते हैं

उस sweep को एक डिफ़ॉल्ट Ollama सर्वर पर चलाएं और कुल संख्या में शायद ही कोई बदलाव दिखे। OLLAMA_NUM_PARALLEL डिफ़ॉल्ट रूप से 1 पर सेट होता है, इसलिए एक request चलती है जबकि बाकी प्रतीक्षा करती हैं, और यही queue p99 TTFT को बढ़ाती है जबकि कुल आउटपुट स्थिर रहता है। कुछ भी मापने से पहले इसे बढ़ाएं।

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"

sudo systemctl restart ollama के साथ restart करें, फिर पुष्टि करें कि मॉडल अभी भी फिट बैठता है। प्रत्येक parallel slot को context window का अपना हिस्सा मिलता है, इसलिए Ollama का documentation बताता है कि 4 parallel requests के साथ 2K context, 8K allocate करता है। slot count को इतना बढ़ाएं कि मॉडल VRAM से बाहर हो जाए। ollama ps की जाँच करें: यदि PROCESSOR कॉलम में 48%/52% CPU/GPU जैसा कुछ दिखाई देता है, तो इसका मतलब है कि मॉडल का हिस्सा CPU पर है, और अब concurrency बढ़ाने पर throughput बढ़ने के बजाय गिर जाएगा। parallel slots के बाद, requests OLLAMA_MAX_QUEUE तक queue में लग जाती हैं, जो डिफ़ॉल्ट रूप से 512 है, जिसके बाद सर्वर 503 error देता है।

vLLM continuous batching का उपयोग करता है, इसलिए जैसे ही slots खाली होते हैं, यह नई requests को चल रहे batch में शामिल कर लेता है, और इसका curve तब तक ऊपर चढ़ता रहता है जब तक KV cache खत्म न हो जाए। Ollama एक मॉडल, एक मशीन और कम सेटअप लागत के लिए अनुकूलित है। इसलिए ये दोनों इंजन एक ही sweep के अलग-अलग परिणाम देते हैं, जो कि serving engines के रूप में Ollama और vLLM की तुलना का मुख्य विषय है। प्रत्येक संख्या को रिकॉर्ड करते समय यह नोट करें कि किस इंजन और किस वर्ज़न ने उसे उत्पन्न किया है।

गलत चीजों को मापने के पाँच तरीके

• क्लाइंट बहुत दूर है। इंटरनेट के माध्यम से अपने लैपटॉप से बेंचमार्किंग करने पर हर TTFT में आपका राउंड ट्रिप समय जुड़ जाता है, इसलिए आप वास्तव में अपने होम कनेक्शन को माप रहे होते हैं। क्लाइंट को सर्वर वाले ही रीजन में चलाएँ।
• मॉडल कोल्ड (cold) था। पहली रिक्वेस्ट में वेट लोडिंग का समय लगता है, और vLLM पर इसमें ग्राफ कैप्चर का समय भी जुड़ सकता है। एक वार्मअप बैच भेजें और उसके परिणाम को छोड़ दें।
• प्रीफिक्स कैशिंग (prefix caching) ने आपके लिए उत्तर दिया। vLLM डिफ़ॉल्ट रूप से ऑटोमैटिक प्रीफिक्स कैशिंग को इनेबल रखता है, इसलिए बार-बार एक ही प्रॉम्प्ट भेजने से प्रीफिल के बजाय कैश मापा जाता है, और TTFT वास्तविक मान के एक छोटे से हिस्से तक गिर जाता है। --dataset-name random इससे बचता है क्योंकि हर प्रॉम्प्ट अलग होता है। सुनिश्चित करने के लिए, सर्वर को --no-enable-prefix-caching के साथ शुरू करें।
• आउटपुट छोटे थे। 32-token के उत्तरों के साथ, TTFT हर रिक्वेस्ट पर हावी रहता है और आपका टोकन प्रति सेकंड (tokens per second) का डेटा वास्तव में केवल प्रीफिल को दर्शाता है। यथार्थवादी आउटपुट लंबाई के साथ --ignore-eos का उपयोग करें।
• आपने 1 की कॉन्करेंसी (concurrency) रिपोर्ट की। यह शीट पर सबसे अनुकूल संख्या है और इसका लागत से कोई लेना-देना नहीं है।

अपने मापे गए नंबर को निर्णय में बदलें

अपने स्वीप (sweep) से प्राप्त सैचुरेटेड आउटपुट थ्रूपुट (saturated output throughput) का उपयोग करें, न कि सिंगल-स्ट्रीम रेट का, और इसकी तुलना प्रति-टोकन मूल्य निर्धारण (per-token pricing) से करें। ब्रेक-ईवन (break-even) एक साधारण विभाजन है:

break_even_tok_s = (price_per_hour / price_per_million_output_tokens) * 1000000 / 3600

इसे DigitalOcean की जुलाई 2026 की कीमतों के साथ समझें। उनका H200 डेडिकेटेड इंफरेंस एंडपॉइंट $4.47 प्रति घंटा था, और सर्वरलेस विकल्प $0.65 प्रति मिलियन टोकन था। इसलिए 4.47 को 0.65 से विभाजित करने पर 6.88 मिलियन टोकन प्रति घंटा प्राप्त होते हैं, और 3,600 सेकंड से विभाजित करने पर लगभग 1,910 आउटपुट टोकन प्रति सेकंड मिलते हैं। कीमतें उनकी हैं। विभाजन हमारा है।

जो शब्द इस निर्णय को तय करता है वह है sustained (निरंतर)। दिन में दो घंटे सैचुरेशन पर 1,910 टोकन प्रति सेकंड की गति प्राप्त करना 1,910 टोकन प्रति सेकंड निरंतर नहीं है, क्योंकि आप बाकी के बाईस घंटों के लिए भी भुगतान करते हैं। DigitalOcean का अपना क्रॉसओवर, जो सस्ते $3.44 प्रति घंटा वाले GPU Droplet के लिए है, 72.2 प्रतिशत निरंतर औसत उपयोग (sustained average utilisation) पर आता है, और उससे नीचे प्रति-टोकन मूल्य ही किफायती रहता है। निष्क्रिय GPU घंटे, न कि धीमे टोकन, आमतौर पर सेल्फ-होस्टिंग को नुकसान पहुँचाते हैं।

इसलिए आपके निर्णय के दो इनपुट हैं। स्वीप आपको अधिकतम सीमा (ceiling) देता है। आपका ट्रैफिक पैटर्न आपको उस सीमा का वह अंश देता है जिसे आप वास्तव में उपयोग करते हैं। उन्हें गुणा करें, फिर परिणाम को प्रति-टोकन API ब्रेक-ईवन के मुकाबले GPU VPS पर ले जाएं और अपने वॉल्यूम के लिए उत्तर देखें।

FAQ

self-hosted LLM के लिए tokens per second की अच्छी दर क्या है?

इसके दो उत्तर हैं, क्योंकि यह metric दो अलग-अलग काम करता है। यदि कोई व्यक्ति output पढ़ रहा है, तो प्रति stream लगभग 20 output tokens per second से अधिक की गति पढ़ने की सामान्य गति से तेज होती है, इसलिए इससे अधिक गति का कोई विशेष लाभ नहीं है। लागत के मामले में, महत्वपूर्ण संख्या 'saturated total output throughput' है, और 'अच्छा' का अर्थ वह दर है जो आपके break-even point को पूरा करे। $4.47 प्रति घंटे की लागत वाले सर्वर पर $0.65 प्रति मिलियन tokens की दर से, July 2026 की कीमतों के अनुसार यह सीमा लगभग 1,910 output tokens per second sustained पर स्थित है। एक बड़े model पर एक single stream कभी भी इस स्तर तक नहीं पहुँचती, यही कारण है कि batching का उपयोग किया जाता है।

concurrent requests जोड़ने पर मेरा Ollama throughput स्थिर क्यों रहता है?

OLLAMA_NUM_PARALLEL का default मान 1 है, इसलिए सर्वर प्रति model एक समय में केवल एक request process करता है और बाकी को queue में डाल देता है। यह queue OLLAMA_MAX_QUEUE (default रूप से 512) तक पहुँचने के बाद 503 error return करती है। इस स्थिति में total output स्थिर रहता है जबकि p99 TTFT बढ़ता जाता है, जो कि busy GPU के बजाय queue के होने का संकेत है। systemd drop-in में इस variable को set करें और service को restart करें। इसके बाद ollama ps की जाँच करें, क्योंकि प्रत्येक parallel slot आवंटित context को बढ़ा देता है, जिससे model का कुछ हिस्सा CPU पर shift हो सकता है।

मुझे time to first token मापना चाहिए या tokens per second?

दोनों को मापें, क्योंकि load बढ़ने पर ये विपरीत दिशाओं में चलते हैं। TTFT वह है जिसे user अनुभव करता है, और saturated output throughput वह है जो आपके invoice में दिखता है। हर concurrency step पर p50 और p99 TTFT को record करें, फिर वह उच्चतम concurrency चुनें जहाँ p99 TTFT आपके लिए स्वीकार्य हो। उस बिंदु पर प्राप्त throughput को अपनी capacity के रूप में रिपोर्ट करें, न कि curve के उच्चतम बिंदु पर मिलने वाली अधिकतम गति को।

क्या tokens per second की उच्च संख्या का अर्थ हमेशा प्रति token कम लागत होता है?

नहीं। प्रति token लागत का अर्थ है प्रति घंटे की कीमत को उस घंटे में सर्वर द्वारा वास्तव में उत्पादित tokens से विभाजित करना। इसलिए, एक तेज सर्वर जो दिन भर खाली (idle) रहता है, उसकी प्रति token लागत अधिक ही बनी रहती है। यह utilisation पर निर्भर करता है, न कि peak speed पर। units का भी ध्यान रखें: quoted total token throughput में input tokens भी शामिल होते हैं, इसलिए 1:1 input-to-output ratio पर यह उस output rate से लगभग दोगुना होता है जिस पर आपको billing की जाती है।