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

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

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

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

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

DigitalOcean ने जुलाई 2026 में vLLM के तहत FP8 (8-bit floating point) में llama3.3-70b-instruct चलाने वाले एक NVIDIA H200 के लिए थ्रूपुट आंकड़े प्रकाशित किए। ये आंकड़े उपयोगी हैं, लेकिन ये आपके आंकड़े नहीं हैं।

[
  {
    "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 है, जबकि केवल-आउटपुट दर 2,036 tok/s है। हेडलाइन इनपुट और आउटपुट टोकन दोनों की गणना करती है। उस टेस्ट में 1,024 इनपुट टोकन के मुकाबले 1,024 आउटपुट टोकन का उपयोग किया गया था, इसलिए हेडलाइन का लगभग आधा हिस्सा आउटपुट है। यह विभाजन मायने रखता है क्योंकि आउटपुट वह आधा हिस्सा है जिसके लिए आपसे शुल्क लिया जाता है, और यह धीमा हिस्सा है। Prefill (प्रॉम्प्ट पढ़ना) सभी इनपुट टोकन को एक बार में प्रोसेस करता है। Decode (उत्तर लिखना) एक बार में एक टोकन उत्पन्न करता है। कुल-थ्रूपुट हेडलाइन एक सस्ते नंबर का एक महंगे नंबर के साथ औसत निकालती है।

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

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

महत्वपूर्ण चार संख्याएँ

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

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

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

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

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

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

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

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

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

Concurrency sweep कैसे चलाएं?

Sweep एक निश्चित वर्कलोड को बढ़ती हुई concurrency पर चलाता है और हर चरण पर होने वाली गतिविधियों को रिकॉर्ड करता है। 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 इन-फ्लाइट रिक्वेस्ट की संख्या को सीमित करता है, और यही वह वेरिएबल है जिसे आप sweep कर रहे हैं। --num-prompts कुल भेजी गई रिक्वेस्ट की संख्या है, इसलिए स्थिर औसत प्राप्त करने के लिए इसे 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 टोकन प्रति सेकंड प्रति स्ट्रीम। आउटपुट थ्रूपुट को 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 द्वारा उत्पन्न आकार का चित्रण हैं, जो परिमाण के संभावित क्रम पर आधारित हैं। ये आपके सर्वर का मापन नहीं हैं और न ही ये किसी वेंडर द्वारा दिए गए आंकड़े हैं। ऊपर दिए गए लूप को चलाएं और उन्हें अपने आंकड़ों से बदलें।

आकार को पढ़ें, क्योंकि आकार ही वह चीज़ है जो सामान्यीकृत (generalise) होती है। एक स्ट्रीम पर पूरा बॉक्स 92 टोकन प्रति सेकंड उत्पन्न करता है, जिसका p99 TTFT 61 ms है। 128 streams पर कुल थ्रूपुट 2304 टोकन प्रति सेकंड तक पहुँच जाता है, जो पच्चीस गुना अधिक है, जबकि प्रत्येक व्यक्तिगत स्ट्रीम 18 टोकन प्रति सेकंड तक गिर जाती है और p99 TTFT 3820 ms तक पहुँच जाता है। कुल थ्रूपुट इसलिए बढ़ता है क्योंकि बैचिंग निष्क्रिय मेमोरी वेट (idle memory waits) को उपयोगी कार्य में बदल देती है। प्रति-स्ट्रीम गति इसलिए गिरती है क्योंकि अब वही कंप्यूट संसाधन साझा किए जा रहे हैं।

अंतिम बार दोगुना करना ही मुख्य संकेत है। 64 से 128 स्ट्रीम तक जाने पर कुल थ्रूपुट में छह प्रतिशत से भी कम की वृद्धि होती है, जबकि p99 TTFT लगभग तीन गुना हो जाता है। इसका अर्थ है कि KV cache भर चुका है और अनुरोध चलने के बजाय कतार (queue) में लग रहे हैं। उपयोगी ऑपरेटिंग पॉइंट इससे पहले आता है: 32 स्ट्रीम पर बॉक्स अभी भी 1728 टोकन प्रति सेकंड देता है, जो इसके पीक का 75 प्रतिशत है, जिसमें 54 टोकन प्रति सेकंड प्रति स्ट्रीम और p99 TTFT 498 ms है। उस बिंदु को अपनी क्षमता के रूप में रिपोर्ट करें। कर्व का पीक वह संख्या है जहाँ से आप उपयोगकर्ताओं को सेवा नहीं दे सकते।

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

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

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 एक मॉडल, एक मशीन और कम सेटअप लागत के लिए अनुकूलित है। इसलिए ये दोनों engines एक ही sweep के अलग-अलग परिणाम देते हैं, जो कि serving engines के रूप में Ollama और vLLM की तुलना का मुख्य विषय है। रिकॉर्ड करें कि प्रत्येक संख्या किस engine और किस version द्वारा उत्पन्न की गई थी।

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

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

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

अपने sweep से प्राप्त saturated output throughput का उपयोग करें, न कि single-stream rate का, और इसकी तुलना per-token pricing से करें। break-even बिंदु निकालने के लिए एक साधारण विभाजन (division) की आवश्यकता होती है:

break_even_tok_s = (price_per_hour / price_per_million_output_tokens) * 1000000 / 3600

इसे DigitalOcean की July 2026 की कीमतों के साथ समझें। उनका H200 dedicated inference endpoint $4.47 प्रति घंटा था, और serverless विकल्प $0.65 प्रति मिलियन tokens था। इसलिए 4.47 को 0.65 से विभाजित करने पर 6.88 मिलियन tokens प्रति घंटा प्राप्त होते हैं, और इसे 3,600 seconds से विभाजित करने पर लगभग 1,910 output tokens प्रति second मिलते हैं। कीमतें उनकी हैं। विभाजन हमारा है। जब हमने 7 October 2026 को जाँच की, तो H200 endpoint अभी भी $4.47 प्रति घंटा था, लेकिन DigitalOcean ने 18 August 2026 को serverless Llama 3.3 70B को बंद कर दिया था और उपयोगकर्ताओं को Llama 4 Maverick पर जाने का सुझाव दिया, जिसकी कीमत $0.87 प्रति मिलियन output tokens है। यह एक अलग model है, इसलिए तुलना करने से पहले इसके लिए अपना अलग sweep करना आवश्यक है।

जो शब्द इस निर्णय को तय करता है वह है sustained (निरंतर)। दिन में दो घंटे saturation पर 1,910 tokens प्रति second की गति प्राप्त करना 1,910 tokens प्रति second sustained नहीं है, क्योंकि आप बाकी के बाईस घंटों के लिए भी भुगतान करते हैं। GPU Droplet के रूप में card किराए पर लेने से यह सीमा कम नहीं होती: 7 October 2026 को DigitalOcean की Droplet pricing में H200 की कीमत on-demand $4.47 प्रति घंटा थी, जो endpoint के समान ही है, और उनके सबसे सस्ते NVIDIA Droplets, जैसे $0.76 प्रति घंटा वाला RTX 4000 और $1.57 प्रति घंटा वाले L40S या RTX 6000, इतने छोटे हैं कि उनमें 70B model को FP8 में नहीं रखा जा सकता। इसलिए, उपरोक्त आंकड़ों के आधार पर, एक H200 जो 2,036 output tokens प्रति second पर saturate होता है, उसे $0.65 प्रति मिलियन tokens की लागत से मेल खाने के लिए आपके द्वारा भुगतान किए गए प्रत्येक घंटे में उस peak का लगभग 94 प्रतिशत औसत बनाए रखना होगा, और उससे कम होने पर per-token price ही किफायती रहती है। Idle GPU hours, न कि slow tokens, आमतौर पर self-hosting को घाटे में डालते हैं।

अतः आपके निर्णय के दो inputs हैं। Sweep आपको अधिकतम क्षमता (ceiling) देता है। आपका traffic pattern यह बताता है कि आप उस क्षमता का कितना हिस्सा वास्तव में उपयोग कर रहे हैं। उन्हें गुणा करें, फिर परिणाम को GPU VPS बनाम per-token API break-even पर ले जाएं और अपने volume के लिए उत्तर देखें।

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 की दर से, यह सीमा जुलाई 2026 की कीमतों पर लगभग 1,910 output tokens per second sustained के आसपास है। एक बड़े model पर एक single stream कभी इस स्तर तक नहीं पहुँचती, इसीलिए batching का उपयोग किया जाता है।

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

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

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

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

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

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