Local LLM चा tokens per second कसा मोजाल

टोकन प्रति सेकंद हे GPU वापरणे आर्थिकदृष्ट्या योग्य ठरते की नाही हे ठरवते

टोकन प्रति सेकंद हा तुमचा सर्व्हर output text तयार करण्याचा दर आहे. GPU भाड्याने घेणे प्रति-token API शुल्क देण्यापेक्षा स्वस्त आहे की नाही हे ठरवणारा हाच आकडा आहे. GPU box वापरात असो किंवा idle असो, त्याचे तासानुसार billing होते. Hosted API चे billing token नुसार होते. त्यामुळे तुम्ही ज्या बहुतांश तासांसाठी पैसे देता, त्या काळात output rate पुरेसा जास्त असेल तरच GPU अधिक किफायतशीर ठरतो.

म्हणून तुम्हाला कुठेतरी वाचलेला आकडा नव्हे, तर प्रत्यक्ष measurement आवश्यक आहे. या पृष्ठावर नोंदवण्यासारखे चार आकडे परिभाषित केले आहेत. त्यानंतर ते मिळवण्यासाठी आवश्यक commands आणि त्या आकड्यांचे arithmetic करून निर्णय कसा घ्यायचा ते दिले आहे.

प्रकाशित tokens per second आकडा तुमचा आकडा का नाही

DigitalOcean ने July 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"
  }
]

वरील प्रत्येक ओळ त्या पानावरून घेतली आहे. त्यांपैकी दोन ओळींमध्ये दिलेल्या range ची lower end value आहे. त्यामुळे त्या दोन आकड्यांना किमान मर्यादा समजा. या chart मधील कोणताही आकडा आम्ही मोजलेला नाही.

शेवटच्या दोन ओळींपासून सुरुवात करा. Headline आकडा 4,071.6 tok/s आहे, तर केवळ output चा rate 2,036 tok/s आहे. Headline मध्ये input आणि output tokens एकत्र मोजले आहेत. या चाचणीत 1,024 input tokens आणि 1,024 output tokens वापरले गेले. त्यामुळे headline च्या जवळपास निम्मा भाग output आहे. हा फरक महत्त्वाचा आहे, कारण billing output वर होते आणि output हा धीमा भाग आहे. Prefill म्हणजे prompt वाचणे; यात सर्व input tokens एकाच pass मध्ये process केले जातात. Decode म्हणजे उत्तर लिहिणे; यात एका वेळी एक token तयार केला जातो. Total-throughput headline मध्ये कमी खर्चाच्या संख्येची आणि जास्त खर्चाच्या संख्येची सरासरी घेतली जाते.

आता पहिली ओळ पाहा. त्याच H200 वर एका वेळी एकच request serve केल्यास 47 tok/s मिळतात. त्यामुळे identical hardware वर saturated आकडा चाळीसपेक्षा अधिक पट जास्त आहे. हा फरक यामुळे असतो की प्रत्येक decode step मध्ये GPU चा बहुतेक वेळ memory ची प्रतीक्षा करण्यात जातो. Concurrent requests त्या idle वेळेचा उपयोग करतात. दुसरी ओळ, 236 tok/s, त्याच model वर चालणाऱ्या एका H100 ची आहे. KV cache मुळे हा आकडा मर्यादित होतो. KV cache म्हणजे key आणि value cache; served conversation साठी प्रत्येक request ची memory card वर ठेवली जाते. 70B model साठी 80 GB card वर कमी concurrent requests ठेवता येतात. त्यामुळे ती card कमी throughput वर saturate होते.

Model बदलला किंवा input-to-output ratio बदलला, तर वरील प्रत्येक आकडा बदलतो. Published figures तुमच्या अपेक्षा ठरवतात; budget नाही. Disk आणि network साठी VPS चे benchmark प्रामाणिकपणे करणे यालाही हाच नियम लागू होतो.

महत्त्वाच्या चार संख्या

• पहिला token येईपर्यंतचा वेळ, TTFT. विनंती पाठवल्यानंतर पहिला output token मिळेपर्यंतचा विलंब. यात prefill time आणि queue time यांचा समावेश असतो. वापरकर्त्याला याचा थेट अनुभव येतो.
• प्रति stream प्रति सेकंद output tokens. उत्तर सुरू झाल्यानंतर ते किती वेगाने लिहिले जाते. साधारण 20 tok/s पेक्षा जास्त वेग बहुतेक लोकांच्या वाचनाच्या वेगापेक्षा आधीच जास्त असतो. त्यामुळे त्यापेक्षा अधिक वेगाचा उपयोग कमी असतो.
• पूर्णपणे लोड असताना एकूण output throughput. एकाच वेळी चालू असलेल्या सर्व streams मधील output throughput ची बेरीज. ही क्षमतेची संख्या आहे. GPU चा खर्च भागवणारी हीच संख्या असते.
• concurrency अंतर्गत p50 आणि p99 TTFT. p50 म्हणजे मधल्या विनंतीचे मूल्य. p99 म्हणजे 100 पैकी 99 विनंत्या ज्यापेक्षा कमी वेळात पूर्ण होतात ते मूल्य. Queueing चा परिणाम सर्वप्रथम p99 मध्ये दिसतो.

सर्व्हरवर कमी भार असताना पहिल्या दोन मोजमापांमध्ये सुधारणा होते. सर्व्हरवर जास्त भार असताना तिसऱ्या मोजमापात सुधारणा होते. ही मोजमापे एकमेकांच्या विरोधात परिणाम करतात. म्हणून serving box चे वर्णन एकाच संख्येने करता येत नाही.

मोजमाप करण्यापूर्वी इनपुट आणि आउटपुटची लांबी निश्चित करा

Throughput हा traffic च्या स्वरूपावर अवलंबून असतो. 4,000-token prompt आणि 50-token उत्तर हे prefill-heavy काम असते. 200-token prompt आणि 2,000-token उत्तर हे decode-heavy काम असते. या दोन परिस्थितींमध्ये त्याच server वर tokens per second चे परिणाम खूप वेगळे येतात. त्यामुळे एकच ratio निवडा, नोंदवलेल्या प्रत्येक संख्येजवळ तो लिहा आणि वेगवेगळ्या ratios मधील तुलना करू नका. 1,024 इनपुट आणि 1,024 आउटपुट हा योग्य default आहे, कारण अनेक vendors या ratio साठी मोजमाप प्रकाशित करतात. तुमचा वास्तविक traffic माहीत असल्यास, तोच वापरा.

आउटपुटची लांबीही निश्चित करा. एखादा model 60 tokens नंतर stop token वर थांबला, तर run कमी कालावधीचा दिसतो आणि वेगवान वाटतो, कारण TTFT चा त्यातील वाटा मोठा असतो. vLLM benchmark client मधील --ignore-eos flag प्रत्येक request कडून अचूकपणे मागितलेल्या संख्येइतके tokens generate करून घेतो. त्यामुळे दोन runs ची तुलना करता येते. कोणत्याही flag पेक्षा model ची निवड या संख्यांवर अधिक परिणाम करते: एकाच VPS GPU वर Qwen 3 model बसवणे या निवडीच्या memory संबंधित बाजूचे स्पष्टीकरण देते.

प्रथम एका stream चे मापन करा

सर्वात सोप्या प्रकरणापासून सुरुवात करा. ही एक sanity check आहे आणि ती कमाल मर्यादाही दाखवते. Ollama स्वतःचे timing दाखवतो.

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

वाचायची ओळ म्हणजे eval rate. ती प्रति सेकंद output tokens दर्शवते. prompt eval rate हा prefill rate आहे आणि load duration हा model VRAM मध्ये load करण्यात गेलेला वेळ आहे. cold start नंतरच्या पहिल्या call वर load duration मोठा असतो. त्यामुळे total duration दिशाभूल करणारा असतो. command दोनदा चालवा आणि दुसरा result वाचा. Ollama defaultनुसार idle model पाच मिनिटांनंतर unload करतो. त्यामुळे दोन runs मधील मोठा विराम असल्यास पुन्हा cold case येतो.

हेच fields API मधूनही मिळतात. त्यामुळे scripting करणे सोपे होते.

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 मिळतात. tokens per second साठी Ollama च्या स्वतःच्या API documentation मध्येही हाच भागाकार सुचवला आहे. Server अद्याप सुरू नसेल, तर VPS वर Ollama वापरून LLM self-host करणे यामध्ये 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 चा असतो. तो पहिला content token किंवा त्याच्या लगेच आधी पाठवलेला role-only delta असू शकतो. त्यामुळे या value ला एका event इतक्या फरकासह TTFT माना. एकाच server वरील दोन runs ची तुलना करण्यासाठी ती पुरेशी अचूक आहे.

Single-stream numbers मुळे server ची क्षमता दोनदा प्रत्यक्षापेक्षा चांगली दिसते. TTFT ही त्याची सर्वोत्तम स्थिती असते, कारण तुमच्यापूर्वी queue मध्ये कोणतेही request नसते. Per-stream rate देखील सर्वोत्तम असतो, कारण संपूर्ण card एकाच request साठी वापरला जातो. या दोन्हीपैकी कोणतेही माप server प्रत्यक्षात किती load हाताळू शकतो हे सांगत नाही.

समांतरता sweep कशी चालवायची?

Sweep मध्ये एकच निश्चित workload वाढत्या concurrency वर चालवला जातो आणि प्रत्येक टप्प्यावर काय घडते ते नोंदवले जाते. यासाठी vLLM client देते. हा client 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 एकाच वेळी सुरू असलेल्या requests ची कमाल संख्या ठरवते. Sweep मध्ये तुम्ही हेच मूल्य बदलता. --num-prompts ही पाठवायच्या requests ची एकूण संख्या आहे. स्थिर सरासरी मिळवण्यासाठी ती 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 दिलेला नाही. मात्र तो एका भागाकाराने काढता येतो. Mean TPOT (ms): म्हणजे पहिल्या output token नंतर प्रत्येक output token साठी लागणारा सरासरी वेळ. त्यामुळे प्रत्येक token साठी 25 ms म्हणजे प्रत्येक stream साठी प्रति सेकंद 40 tokens. Output throughput ला concurrency ने भागल्यास हेच उत्तर मिळते.

आता प्रत्येक run जतन करून ही प्रक्रिया loop मध्ये चालवा.

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 box वर sweep केल्यास मिळणाऱ्या आकाराचे, वास्तववादी परिमाणांवर आधारित उदाहरण आहेत. त्या तुमच्या server वरील मोजमाप नाहीत आणि vendor ने दिलेली आकडेवारीही नाहीत. वरील loop चालवा आणि त्या जागी तुमची मूल्ये भरा.

आकार समजून घ्या, कारण सर्वसाधारणपणे लागू होणारी बाब हाच आकार आहे. एका stream वर संपूर्ण box प्रति सेकंद 92 tokens तयार करतो आणि p99 TTFT 61 ms असतो. 128 streams वर एकूण throughput प्रति सेकंद 2304 tokens पर्यंत पोहोचतो, म्हणजे तो पंचवीस पट जास्त असतो. मात्र प्रत्येक स्वतंत्र stream चा वेग प्रति सेकंद 18 tokens पर्यंत कमी होतो आणि p99 TTFT 3820 ms पर्यंत वाढतो. Batching मुळे निष्क्रिय memory waits चे उपयुक्त कामात रूपांतर होते, म्हणून एकूण throughput वाढतो. तेच compute आता अनेक streams मध्ये विभागले जाते, म्हणून प्रत्येक stream चा वेग कमी होतो.

शेवटचे doubling महत्त्वाचे संकेत देते. 64 वरून 128 streams केल्यावर एकूण throughput मध्ये सहा टक्क्यांपेक्षा कमी वाढ होते, तर p99 TTFT साधारण तिप्पट होते. याचा अर्थ KV cache भरला आहे आणि requests चालवण्याऐवजी queue मध्ये थांबत आहेत. उपयुक्त operating point त्यापूर्वी येतो. 32 streams वर box अजूनही प्रति सेकंद 1728 tokens परत करतो. हे peak च्या 75 percent इतके आहे. त्या वेळी प्रत्येक stream साठी वेग प्रति सेकंद 54 tokens आणि p99 TTFT 498 ms असतो. हा operating point तुमची capacity म्हणून नोंदवा. Curve वरील peak वापरून users ना सेवा देता येत नाही.

Ollama आणि vLLM एकाच गोष्टीचे मापन करत नाहीत

ही चाचणी default Ollama server वर चालवली, तर एकूण आकडा फारसा बदलणार नाही. OLLAMA_NUM_PARALLEL ची default किंमत 1 आहे. त्यामुळे एक request चालते आणि उर्वरित requests प्रतीक्षा करतात. Queue मुळे p99 TTFT वाढतो, पण एकूण output स्थिर राहतो. कोणतेही मापन करण्यापूर्वी ही किंमत वाढवा.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"

sudo systemctl restart ollama सह server पुन्हा सुरू करा आणि model अजूनही उपलब्ध VRAM मध्ये बसतो का ते तपासा. प्रत्येक parallel slot ला context window मधील स्वतंत्र हिस्सा मिळतो. त्यामुळे Ollama च्या documentation नुसार, 4 parallel requests साठी 2K context मुळे 8K allocation होते. Slot count पुरेसा वाढवल्यास model VRAM च्या बाहेर जाऊ शकतो. ollama ps तपासा: PROCESSOR column मध्ये 48%/52% CPU/GPU सारखी value दिसत असल्यास, model चा काही भाग CPU वर चालू आहे. अशा वेळी concurrency वाढवल्यावर throughput वाढण्याऐवजी कमी होतो. Parallel slots ची मर्यादा ओलांडल्यानंतर requests OLLAMA_MAX_QUEUE पर्यंत queue मध्ये थांबतात. त्याची default value 512 आहे. त्यानंतर server 503 उत्तर देतो.

vLLM continuous batching वापरते. त्यामुळे slots मोकळे होताच ते चालू batch मध्ये नवीन requests समाविष्ट करते. KV cache संपेपर्यंत त्याचा आलेख वाढत राहतो. Ollama एका model साठी, एका machine वर आणि कमी setup cost मध्ये कार्य करण्यासाठी optimize केलेले आहे. त्यामुळे या दोन engines कडून एकाच sweep साठी वेगवेगळी उत्तरे मिळतात. हाच Ollama आणि vLLM यांची serving engines म्हणून तुलना यामागील मुख्य विषय आहे. प्रत्येक आकडा कोणत्या engine आणि कोणत्या version ने निर्माण केला ते नोंदवा.

चुकीची गोष्ट मोजण्याचे पाच मार्ग

• Client खूप दूर आहे. इंटरनेटवरून तुमच्या laptop वरून benchmark चालवल्यास प्रत्येक TTFT मध्ये तुमचा round trip time जोडला जातो. त्यामुळे तुम्ही server ऐवजी तुमचे home connection मोजता. Client server च्या त्याच region मध्ये चालवा.
• Model cold होता. पहिल्या request मध्ये weights load करण्याचा वेळ लागतो. vLLM मध्ये graph capture चा वेळही लागू शकतो. Warmup batch पाठवा आणि त्याचा result discard करा.
• Prefix caching ने तुमच्यासाठी उत्तर दिले. vLLM मध्ये automatic prefix caching default ने enabled असते. त्यामुळे तोच prompt पुन्हा पुन्हा पाठवल्यास prefill ऐवजी cache मोजला जातो आणि TTFT चे वास्तविक मूल्याच्या तुलनेत अत्यल्प मूल्य दिसते. --dataset-name random ही अडचण टाळते, कारण प्रत्येक prompt वेगळा असतो. खात्री करण्यासाठी server --no-enable-prefix-caching सह सुरू करा.
• Outputs लहान होते. 32-token answers वापरल्यास प्रत्येक request मध्ये TTFT चा वाटा मोठा असतो आणि तुमचा tokens per second आकडा प्रत्यक्षात prefill चे वर्णन करतो. वास्तववादी output length सह --ignore-eos वापरा.
• तुम्ही concurrency 1 नोंदवली. हा अहवालातील सर्वात अनुकूल आकडा आहे आणि त्याचा cost शी संबंध नाही.

तुमच्या मोजलेल्या संख्येचे निर्णयात रूपांतर करा

तुमच्या sweep मधून मिळालेला saturated output throughput घ्या. Single-stream rate वापरू नका. त्याची per-token pricing सोबत तुलना करा. Break-even काढण्यासाठी एक भागाकार पुरेसा आहे:

break_even_tok_s = (price_per_hour / price_per_million_output_tokens) * 1000000 / 3600

DigitalOcean च्या July 2026 मधील किमती वापरून हे मोजू. त्यांचा H200 dedicated inference endpoint $4.47 प्रति तास होता आणि serverless equivalent ची किंमत $0.65 प्रति million tokens होती. त्यामुळे 4.47 ला 0.65 ने भागल्यास प्रति तास 6.88 million tokens मिळतात. 3,600 seconds ने भागल्यास सुमारे 1,910 output tokens प्रति सेकंद मिळतात. या किमती DigitalOcean च्या आहेत. भागाकार आमचा आहे.

हा निर्णय घेणारा शब्द sustained आहे. Saturation स्थितीत दोन तास प्रतिदिन 1,910 tokens प्रति सेकंद मिळणे म्हणजे 1,910 tokens प्रति सेकंद sustained असे नाही. कारण उर्वरित twenty-two तासांचेही पैसे द्यावे लागतात. DigitalOcean च्या स्वस्त $3.44 प्रति तास GPU Droplet साठीचा crossover 72.2 percent sustained average utilisation वर येतो. त्यापेक्षा कमी वापर असल्यास per-token price अधिक फायदेशीर ठरते. Self-hosting मध्ये सहसा slow tokens मुळे नाही, तर वापरात नसलेल्या GPU hours मुळे खर्च वाढतो.

म्हणून तुमच्या निर्णयासाठी दोन inputs आहेत. Sweep तुम्हाला कमाल मर्यादा दाखवतो. तुमचा traffic pattern त्या कमाल मर्यादेपैकी प्रत्यक्षात वापरला जाणारा fraction दाखवतो. या दोन्हींचा गुणाकार करा. त्यानंतर परिणाम GPU VPS आणि per-token API यांमधील break-even शी तुलना करा आणि तुमच्या volume साठी योग्य उत्तर ठरवा.

FAQ

self-hosted LLM साठी tokens per second किती असणे योग्य आहे?

याची दोन उत्तरे आहेत, कारण हे मापन दोन वेगवेगळी कामे करते. एक व्यक्ती output वाचत असेल, तर प्रत्येक stream साठी साधारणपणे 20 output tokens per second पेक्षा जास्त वेग आधीच वाचनाच्या वेगापेक्षा अधिक असतो. त्यामुळे त्यापेक्षा जास्त वेगाचा उपयोग होत नाही. खर्चाच्या दृष्टीने महत्त्वाचा आकडा म्हणजे saturated total output throughput. तुमचा break-even पार करणारा कोणताही throughput चांगला मानला जातो. प्रति million tokens $0.65 खर्च आणि प्रति तास $4.47 किंमत असलेल्या सर्व्हरच्या बाबतीत, July 2026 मधील किमतींनुसार ही किमान पातळी sustained 1,910 output tokens per second इतकी आहे. मोठ्या model वर एक stream ही पातळी कधीच गाठत नाही. म्हणूनच batching वापरले जाते.

concurrent requests वाढवल्यावर माझा Ollama throughput स्थिर का राहतो?

OLLAMA_NUM_PARALLEL चे default मूल्य 1 आहे. त्यामुळे server प्रत्येक model साठी एका वेळी एकच request चालवतो आणि उर्वरित requests queue मध्ये ठेवतो. OLLAMA_MAX_QUEUE पर्यंत (default मूल्य 512) queue भरल्यानंतर server 503 परत करतो. p99 TTFT वाढत असताना एकूण output स्थिर राहतो. हे GPU व्यस्त असल्याचे नव्हे, तर queue तयार झाल्याचे लक्षण आहे. systemd drop-in मध्ये हे variable सेट करून service restart करा. त्यानंतर ollama ps तपासा, कारण प्रत्येक parallel slot मुळे allocated context वाढतो आणि model चा काही भाग CPU वर जाऊ शकतो.

time to first token मोजावे की tokens per second?

दोन्ही मोजा, कारण load वाढल्यावर हे दोन्ही परस्परविरुद्ध दिशेने बदलतात. TTFT वापरकर्त्याला जाणवणारा विलंब दर्शवतो. saturated output throughput तुमच्या invoice मध्ये दिसणारा वापर दर्शवतो. प्रत्येक concurrency स्तरावर p50 आणि p99 TTFT नोंदवा. त्यानंतर p99 TTFT तुम्हाला स्वीकार्य राहतो त्या मर्यादेतील सर्वाधिक concurrency निवडा. त्या बिंदूवरील throughput तुमची capacity म्हणून नोंदवा. curve च्या सर्वोच्च बिंदूवरील maximum throughput वापरू नका.

tokens per second चा आकडा जास्त असणे म्हणजे cost per token नेहमी कमी असतो का?

नाही. cost per token म्हणजे त्या तासात server ने प्रत्यक्ष तयार केलेल्या tokens ने hourly price भागल्यावर मिळणारे मूल्य. त्यामुळे वेगवान server दिवसाचा मोठा भाग idle असेल, तरी cost per token जास्त राहतो. peak speed नव्हे, तर utilisation हे ठरवते. units कडेही लक्ष द्या. दिलेला total token throughput input tokens मोजत असेल, तर input-to-output ratio 1:1 असताना तो तुम्हाला billed होणाऱ्या output rate च्या जवळपास दुप्पट असतो.