స్థానిక LLMలో tokens per second ఎలా కొలవాలి

tokens per second GPU ఖర్చును సమర్థిస్తుందో నిర్ణయిస్తుంది

tokens per second అనేది మీ server output text ను ఉత్పత్తి చేసే రేటు. GPU ను అద్దెకు తీసుకోవడం, ప్రతి token కు APIకి చెల్లించడం కంటే చౌకగా ఉంటుందా అనే విషయాన్ని నిర్ణయించే సంఖ్య ఇదే. GPU box busyగా ఉన్నా idleగా ఉన్నా గంటల ప్రాతిపదికన billing జరుగుతుంది. Hosted APIకి token ప్రాతిపదికన billing జరుగుతుంది. కాబట్టి, మీరు చెల్లించే ఎక్కువ గంటల్లో output rate తగినంతగా ఉంటేనే GPU ఆర్థికంగా ప్రయోజనకరంగా ఉంటుంది.

అందువల్ల, ఎక్కడో చదివిన సంఖ్యపై ఆధారపడకుండా measurement అవసరం. ఈ పేజీ నమోదు చేయాల్సిన నాలుగు ముఖ్యమైన సంఖ్యలను వివరిస్తుంది. వాటిని పొందడానికి అవసరమైన commands ను, ఆ సంఖ్యలను ఉపయోగించి నిర్ణయం తీసుకునే arithmetic ను కూడా అందిస్తుంది.

ప్రచురించిన tokens per second గణాంకం మీ వాస్తవ గణాంకం ఎందుకు కాదు

DigitalOcean, July 2026లో ఒక NVIDIA H200 పై llama3.3-70b-instruct ను vLLM కింద FP8 (8-bit floating point)లో నడిపినప్పుడు లభించిన 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"
  }
]

పై పట్టికలోని ప్రతి వరుసను ఆ పేజీ నుంచే తీసుకున్నారు. వాటిలో రెండు ఆ పేజీలో ఇచ్చిన పరిధి యొక్క కనిష్ఠ విలువలు. కాబట్టి ఆ రెండింటిని కనిష్ఠ పరిమితిగా పరిగణించాలి. ఈ పట్టికలోని ఏ గణాంకాన్నీ మేము కొలవలేదు.

చివరి రెండు వరుసలతో ప్రారంభించండి. శీర్షికలో 4,071.6 tok/s ఉంది. Output-only rate 2,036 tok/s ఉంది. శీర్షికలో input మరియు output tokens రెండింటినీ కలిపి లెక్కించారు. ఆ పరీక్షలో 1,024 input tokens మరియు 1,024 output tokens ఉపయోగించారు. అందువల్ల శీర్షికలోని విలువలో దాదాపు సగం output అవుతుంది. ఈ విభజన ముఖ్యమైనది. మీరు చెల్లించే భాగం output. అదే నెమ్మదైన భాగం కూడా. Prefill (prompt చదవడం) అన్ని input tokens ను ఒకే passలో process చేస్తుంది. Decode (సమాధానం రాయడం) ఒక్కసారి ఒక token ను ఉత్పత్తి చేస్తుంది. Total-throughput శీర్షికలో తక్కువ ఖర్చుతో కూడిన ఒక రేటును, ఎక్కువ ఖర్చుతో కూడిన మరొక రేటుతో సగటు చేస్తారు.

ఇప్పుడు మొదటి వరుసను చూడండి. అదే H200 ఒకేసారి ఒక request ను serve చేస్తే 47 tok/s ఉత్పత్తి చేస్తుంది. అంటే అదే hardwareపై saturated figure 40 రెట్లకంటే ఎక్కువగా ఉంటుంది. ఈ తేడాకు కారణం ఏమిటంటే, ఒక decode stepలో ఎక్కువ సమయం GPU memory కోసం వేచి ఉంటుంది. Concurrent requests ఆ idle time ను ఉపయోగిస్తాయి. రెండో వరుసలోని 236 tok/s గణాంకం అదే modelపై ఒక H100కు సంబంధించినది. దీనిని KV cache (key and value cache; serve చేస్తున్న conversation ప్రతి request కోసం cardపై ఉంచే memory) పరిమితం చేస్తుంది. 80 GB cardలో 70B model కోసం తక్కువ concurrent requests మాత్రమే ఉంచగలరు. అందువల్ల అది తక్కువ స్థాయిలో saturate అవుతుంది.

Modelను మార్చినా, input మరియు output నిష్పత్తిని మార్చినా, పై గణాంకాలన్నీ మారతాయి. Published figures మీ అంచనాలను నిర్ణయిస్తాయి. మీ budgetను కాదు. Disk మరియు networkపై VPS benchmarkingను నిజాయితీగా నిర్వహించడం విషయంలో కూడా ఇదే నియమం వర్తిస్తుంది.

ముఖ్యమైన నాలుగు సంఖ్యలు

• మొదటి token కు పట్టే సమయం, TTFT. అభ్యర్థన పంపినప్పటి నుంచి మొదటి output token వచ్చే వరకు ఉండే ఆలస్యం. ఇందులో prefill సమయం మరియు queue సమయం ఉంటాయి. వినియోగదారుడు దీనిని నేరుగా అనుభవిస్తాడు.
• ప్రతి stream కు సెకనుకు వచ్చే output tokens. సమాధానం ప్రారంభమైన తర్వాత అది ఎంత వేగంగా వ్రాయబడుతుందో ఇది చూపిస్తుంది. సుమారుగా 20 tok/s కంటే ఎక్కువ వేగం ఉంటే, అది ఇప్పటికే చాలామంది చదివే వేగం కంటే ఎక్కువగా ఉంటుంది. అందువల్ల ఇక్కడ అదనపు వేగం వల్ల ప్రయోజనం తక్కువ.
• పూర్తి లోడ్‌లో మొత్తం output throughput. server పూర్తిగా లోడ్‌లో ఉన్నప్పుడు, సమాంతరంగా నడుస్తున్న అన్ని streams లోని output వేగాల మొత్తం. ఇది capacity సంఖ్య. GPU ఖర్చును భరించే సామర్థ్యాన్ని నిర్ణయించేది ఇదే.
• సమాంతర అభ్యర్థనల సమయంలో p50 మరియు p99 TTFT. p50 అంటే మధ్యస్థ అభ్యర్థన. p99 అంటే 100 అభ్యర్థనల్లో 99 అభ్యర్థనలు ఈ విలువ కంటే తక్కువ సమయంలో పూర్తయ్యే పరిమితి. Queueing ప్రభావం మొదట p99లో కనిపిస్తుంది.

server ఖాళీగా ఉన్నప్పుడు మొదటి రెండు మెరుగ్గా ఉంటాయి. server busyగా ఉన్నప్పుడు మూడవది మెరుగ్గా ఉంటుంది. ఇవి పరస్పరం వ్యతిరేకంగా ప్రభావితం చేస్తాయి. అందుకే serving box పనితీరును ఒకే సంఖ్యతో వివరించలేం.

మీరు కొలిచే ముందు input మరియు output పొడవులను స్థిరపరచండి

Throughput traffic యొక్క ఆకృతిపై ఆధారపడి ఉంటుంది. 4,000-token prompt మరియు 50-token answer ఉన్న పని prefill-heavy గా ఉంటుంది. 200-token prompt మరియు 2,000-token answer ఉన్న పని decode-heavy గా ఉంటుంది. అదే server ఈ రెండు సందర్భాల్లో tokens per second కు చాలా భిన్నమైన విలువలను చూపుతుంది. అందువల్ల ఒకే నిష్పత్తిని ఎంచుకుని, మీరు నమోదు చేసే ప్రతి సంఖ్య పక్కన ఆ నిష్పత్తిని రాయండి. నిష్పత్తులు వేర్వేరుగా ఉన్నప్పుడు వాటిని ఎప్పుడూ పోల్చవద్దు. 1,024 input మరియు 1,024 output అనేది సరైన default. ఎందుకంటే అనేక vendors ఆ నిష్పత్తిలో గణాంకాలను ప్రచురిస్తారు. మీ వాస్తవ traffic మీకు తెలిసి ఉంటే, అదే traffic ను ఉపయోగించండి.

Output length ను కూడా నిర్దిష్టంగా ఉంచండి. ఒక model 60 tokens తర్వాత stop token ను చేరుకుంటే, ఆ run చిన్నదిగా ఉండి వేగంగా కనిపిస్తుంది. ఎందుకంటే అందులో TTFT వాటా ఎక్కువగా ఉంటుంది. vLLM benchmark client లోని --ignore-eos flag ప్రతి request కు నిర్దిష్టంగా కోరిన count మేరకు generate చేయిస్తుంది. అందువల్ల రెండు runs ను పోల్చవచ్చు. ఈ flags కంటే model ఎంపిక ఈ సంఖ్యలను ఎక్కువగా ప్రభావితం చేస్తుంది: ఒకే VPS GPUలో Qwen 3 model ను అమర్చడం ఆ ఎంపికకు సంబంధించిన memory అంశాన్ని వివరిస్తుంది.

ముందుగా ఒక stream ను కొలవండి

అత్యంత సరళమైన పరిస్థితితో ప్రారంభించండి. ఇది sanity check కూడా, గరిష్ఠ పరిమితి కూడా. Ollama తన స్వంత timings ను చూపిస్తుంది.

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

చూడాల్సిన line eval rate. ఇది ప్రతి సెకనుకు output tokens సంఖ్య. prompt eval rate prefill rate, load duration model ను VRAM లోకి load చేయడానికి పట్టిన సమయం. cold start తర్వాత చేసే మొదటి call లో load duration పెద్దగా ఉంటుంది. అందువల్ల total duration తప్పుదారి పట్టించవచ్చు. command ను రెండుసార్లు run చేసి, రెండవ result ను చదవండి. డిఫాల్ట్‌గా idle model ను Ollama ఐదు నిమిషాల తర్వాత unload చేస్తుంది. కాబట్టి runs మధ్య ఎక్కువ విరామం ఉంటే మళ్లీ cold case కు వెళ్తారు.

ఇదే fields 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 వస్తాయి. tokens per second కోసం Ollama స్వంత API documentation కూడా ఇదే division ను సూచిస్తుంది. server ఇంకా ప్రారంభం కాకపోతే, VPS పై Ollama తో LLM ను self-host చేయడం గురించి Ollama తో VPS పై LLM ను self-host చేయడం లో install మరియు 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 కావచ్చు. అందువల్ల ఈ విలువను ఒక event వరకు తేడా ఉండే TTFT గా పరిగణించండి. అదే server పై రెండు runs ను పోల్చడానికి ఇది సరిపడేంత ఖచ్చితంగా ఉంటుంది.

Single-stream సంఖ్యలు server సామర్థ్యాన్ని రెండుసార్లు ఎక్కువగా చూపిస్తాయి. మీకు ముందు ఏదీ queue లో లేకపోవడం వల్ల TTFT ఎప్పటికీ పొందగలిగే ఉత్తమ విలువగా ఉంటుంది. మొత్తం card ఒకే request కు సేవలందించడం వల్ల ప్రతి-stream rate కూడా ఎప్పటికీ పొందగలిగే ఉత్తమ విలువగా ఉంటుంది. ఈ రెండింటిలో ఏదీ server వాస్తవంగా ఎంత load ను నిర్వహించగలదో చెప్పదు.

Concurrency sweep ను ఎలా అమలు చేయాలి?

ఒక sweep సమయంలో ఒకే workload ను పెరుగుతున్న 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 ఒకేసారి అమలులో ఉన్న requests సంఖ్యకు పరిమితి విధిస్తుంది. మీరు sweep చేసేది ఇదే variable. --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 తో లెక్కించవచ్చు. మొదటి output token తర్వాత ప్రతి token కు పట్టే సగటు సమయం Mean TPOT (ms):. అందువల్ల ప్రతి 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 వరుసలు చిన్న rental GPU box పై sweep ఎలా కనిపిస్తుందో చూపించే ఉదాహరణ మాత్రమే. ఇవి సాధ్యమైన పరిమాణాల ఆధారంగా ఇచ్చినవి. అవి మీ server పై చేసిన కొలతలు కావు. అవి vendor గణాంకాలు కూడా కావు. పై loop ను run చేసి, వాటి స్థానంలో మీ విలువలను పెట్టండి.

ఆకారాన్ని పరిశీలించండి. సాధారణీకరించగలిగేది అదే. ఒక 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 వేగం తగ్గుతుంది.

చివరి రెట్టింపు ముఖ్యమైన సంకేతాన్ని ఇస్తుంది. 64 streams నుంచి 128 streams కు పెంచినప్పుడు మొత్తం throughput ఆరు శాతం కంటే తక్కువగా మాత్రమే పెరుగుతుంది. అదే సమయంలో p99 TTFT సుమారు మూడు రెట్లు పెరుగుతుంది. దీని అర్థం KV cache నిండిపోయి, requests అమలు కాక queueలో వేచి ఉంటున్నాయి. ఉపయోగకరమైన operating point అంతకుముందే ఉంటుంది. 32 streams వద్ద box ఇప్పటికీ ప్రతి సెకనుకు 1728 tokens ను ఉత్పత్తి చేస్తుంది. ఇది peak లో 75 శాతం. ప్రతి stream కు ప్రతి సెకనుకు 54 tokens వేగం, p99 TTFT 498 ms గా ఉంటాయి. ఆ point ను మీ capacity గా report చేయండి. Curve యొక్క peak ఆధారంగా users కు వాస్తవంగా సేవ అందించలేరు.

Ollama మరియు vLLM ఒకే విషయాన్ని కొలవవు

ఆ sweep ను default Ollama server పై అమలు చేస్తే మొత్తం విలువలో దాదాపు మార్పు కనిపించదు. OLLAMA_NUM_PARALLEL default గా 1 ఉంటుంది. అందువల్ల ఒక request నడుస్తుండగా మిగతావి వేచి ఉంటాయి. ఈ queue కారణంగానే p99 TTFT పెరుగుతుంది, అయితే మొత్తం output స్థిరంగా ఉంటుంది. ఏదైనా కొలిచే ముందు దీని విలువను పెంచండి.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"

sudo systemctl restart ollama తో restart చేసి, model ఇప్పటికీ సరిపోతుందో నిర్ధారించండి. ప్రతి parallel slot కు context window లో స్వంత భాగం కేటాయించబడుతుంది. అందువల్ల 4 parallel requests కోసం 2K context 8K ను కేటాయిస్తుందని Ollama documentation పేర్కొంటుంది. 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 ఖాళీ అయినప్పుడు నడుస్తున్న batch లోకి కొత్త requests ను చేర్చుతుంది. KV cache పూర్తయ్యే వరకు దాని curve పెరుగుతూనే ఉంటుంది. Ollama ఒక model, ఒక machine, తక్కువ setup cost కోసం optimise చేయబడింది. అందువల్ల ఒకే sweep కు ఈ రెండు engines వేర్వేరు ఫలితాలను ఇస్తాయి. ఇదే Ollama మరియు vLLM ను serving engines గా పోల్చడం అనే అంశం. ప్రతి సంఖ్యను ఏ engine మరియు ఏ version ఉత్పత్తి చేశాయో నమోదు చేయండి.

తప్పుగా కొలిచే 5 పద్ధతులు

• Client చాలా దూరంలో ఉంది. Internet ద్వారా మీ laptop నుంచి benchmark నడిపితే, ప్రతి TTFTలో మీ round trip time కూడా చేరుతుంది. అప్పుడు మీరు మీ home connection ను కొలుస్తారు. Client ను server ఉన్న region లోనే నడపండి.
• Model cold స్థితిలో ఉంది. మొదటి request సమయంలో weights loading జరుగుతుంది. vLLMలో graph capture కూడా అదే సమయంలో జరగవచ్చు. Warmup batch పంపి, దాని result ను విస్మరించండి.
• Prefix caching మీ తరఫున సమాధానం ఇచ్చింది. vLLMలో automatic prefix caching defaultగా enabled ఉంటుంది. అందువల్ల అదే prompt ను పదేపదే పంపితే prefill కాకుండా cache కొలుస్తారు. TTFT వాస్తవ విలువలోని చిన్న భాగానికి పడిపోతుంది. --dataset-name random ప్రతి prompt ను భిన్నంగా ఉంచడం ద్వారా దీనిని నివారిస్తుంది. నిర్ధారించుకోవడానికి server ను --no-enable-prefix-caching తో ప్రారంభించండి.
• Outputs చిన్నగా ఉన్నాయి. 32-token సమాధానాలతో ప్రతి requestలో TTFT ఆధిపత్యం చెలాయిస్తుంది. అప్పుడు మీ tokens per second విలువ వాస్తవానికి prefill ను వివరిస్తుంది. వాస్తవిక output length తో --ignore-eos ఉపయోగించండి.
• మీరు concurrency 1 ను నివేదించారు. పట్టికలో ఇది అత్యంత అనుకూలమైన సంఖ్య. ఖర్చుతో దీనికి సంబంధం ఉండదు.

మీ కొలిచిన సంఖ్యను నిర్ణయంగా మార్చండి

మీ 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 2026 జూలై ధరలతో దీనిని లెక్కిద్దాం. వారి H200 dedicated inference endpoint ధర గంటకు $4.47. Serverless సమాన సేవ ధర ప్రతి మిలియన్ tokens కు $0.65. కాబట్టి 4.47 ను 0.65 తో భాగిస్తే గంటకు 6.88 million tokens వస్తాయి. దాన్ని 3,600 seconds తో భాగిస్తే సుమారు సెకనుకు 1,910 output tokens వస్తాయి. ధరలు DigitalOcean కు చెందినవి. భాగహారం మన లెక్క. 2026 అక్టోబర్ 7న పరిశీలించినప్పుడు H200 endpoint ధర ఇంకా గంటకు $4.47గానే ఉంది. అయితే DigitalOcean 2026 ఆగస్టు 18న serverless Llama 3.3 70B ను deprecated చేసి, users ను Llama 4 Maverick వైపు మళ్లించింది. దాని ధర ప్రతి million output tokens కు $0.87గా ఉంది. అది వేరే model కాబట్టి, పోలికకు ముందు దానిపై ప్రత్యేక sweep చేయాలి.

ఇక్కడ నిర్ణయాత్మక పదం sustained. Saturation వద్ద రోజుకు రెండు గంటలపాటు సెకనుకు 1,910 tokens అందుకోవడం అంటే sustained గా సెకనుకు 1,910 tokens అందుకోవడం కాదు. ఎందుకంటే మిగిలిన ఇరవై రెండు గంటలకు కూడా మీరు చెల్లిస్తారు. GPU Droplet గా card ను rent చేయడం వల్ల ఈ పరిమితి తగ్గదు. 2026 అక్టోబర్ 7న DigitalOcean Droplet pricing లో H200 on-demand ధర గంటకు $4.47గా ఉంది. అది endpoint ధరతో సమానం. వాటి చవకైన NVIDIA Droplets అయిన RTX 4000 గంటకు $0.76, L40S లేదా RTX 6000 గంటకు $1.57 ధరలకు లభించినా, FP8లో 70B model ను ఉంచడానికి అవి సరిపోవు. కాబట్టి పై సంఖ్యల ప్రకారం, saturation వద్ద సెకనుకు 2,036 output tokens అందించే H200, ప్రతి చెల్లించే గంటలో ఆ peak లో సగటున సుమారు 94 శాతం throughput సాధించాలి. అప్పుడే ప్రతి million tokens కు $0.65 ధరతో సమానమవుతుంది. దాని కంటే తక్కువైతే per-token ధరే ప్రయోజనకరం. సాధారణంగా self-hosting ను నష్టపరిచేది slow tokens కాదు; ఉపయోగించకుండా చెల్లించిన GPU గంటలే.

కాబట్టి మీ నిర్ణయానికి రెండు inputs ఉన్నాయి. Sweep మీకు ceiling ను ఇస్తుంది. మీ traffic pattern లో ఆ ceiling లో వాస్తవంగా ఎంత భాగం ఉపయోగపడుతుందో నిర్ణయిస్తుంది. ఈ రెండింటిని గుణించండి. తరువాత ఫలితాన్ని 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 ను మించే ఏ throughput అయినా సరిపోతుంది. గంటకు $4.47 ఖర్చయ్యే box పై ఒక million tokens కు $0.65 ధర ఉన్నప్పుడు, July 2026 ధరల ప్రకారం ఈ కనిష్ఠ స్థాయి నిరంతరంగా సుమారు 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 చేసి ఆ తర్వాత 503 ఇస్తుంది. p99 TTFT పెరుగుతున్నప్పటికీ మొత్తం output మారకుండా ఉంటుంది. ఇది busy GPU కంటే queue ఉన్నదనే సూచన. systemd drop-in లో ఈ variable ను set చేసి restart చేయండి. తరువాత ollama ps ను పరిశీలించండి. ప్రతి parallel slot కేటాయించిన context పరిమాణాన్ని పెంచుతుంది. దాంతో model లో కొంత భాగం CPU పైకి వెళ్లవచ్చు.

time to first token ను కొలవాలా లేదా tokens per second ను కొలవాలా?

రెండింటినీ కొలవాలి, ఎందుకంటే load పెరిగేకొద్దీ ఇవి వ్యతిరేక దిశల్లో మారుతాయి. TTFT ను user అనుభవిస్తాడు. Saturated output throughput మీ invoice లో ప్రతిబింబిస్తుంది. ప్రతి concurrency దశలో p50 మరియు p99 TTFT ను record చేయండి. తరువాత p99 TTFT మీకు ఇంకా ఆమోదయోగ్యంగా ఉన్న అత్యధిక concurrency ను ఎంచుకోండి. ఆ స్థాయి వద్ద ఉన్న throughput ను మీ capacity గా report చేయండి. Curve పై గరిష్ఠ స్థాయి నుంచి వచ్చిన throughput ను capacity గా ఉపయోగించవద్దు.

tokens per second ఎక్కువగా ఉంటే cost per token ఎల్లప్పుడూ తక్కువగానే ఉంటుందా?

లేదు. Cost per token అనేది గంటకు చెల్లించే ధరను, ఆ గంటలో box వాస్తవంగా ఉత్పత్తి చేసిన tokens సంఖ్యతో భాగించిన విలువ. కాబట్టి రోజులో ఎక్కువసేపు idle గా ఉండే వేగవంతమైన server కు కూడా cost per token ఎక్కువగానే ఉంటుంది. Peak speed కాదు, utilisation దీనిని నిర్ణయిస్తుంది. Units ను కూడా పరిశీలించండి. Quoted total token throughput లో input tokens కూడా లెక్కిస్తారు. కాబట్టి input మరియు output నిష్పత్తి 1:1 గా ఉంటే, అది మీకు charge అయ్యే output rate కు దాదాపు రెట్టింపుగా ఉంటుంది.