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

ఒక సెకనుకు tokens సంఖ్య GPU ఖర్చు సమర్థవంతమో నిర్ణయిస్తుంది

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

అందువల్ల ఎక్కడో చదివిన figure కాకుండా, మీకు ఒక 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"
  }
]

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

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

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

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

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

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

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

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

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

Output length ను కూడా నిర్దిష్టంగా నిర్ణయించండి. ఒక model 60 tokens తర్వాత stop token ను చేరుకుంటే, ఆ run తక్కువగా ఉండి వేగంగా కనిపిస్తుంది, ఎందుకంటే అందులో TTFT వాటా ఎక్కువగా ఉంటుంది. vLLM benchmark client లోని --ignore-eos flag ప్రతి request ద్వారా కోరిన count కు ఖచ్చితంగా output 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 ను రెండుసార్లు run చేసి, రెండవ ఫలితాన్ని చదవండి. డిఫాల్ట్‌గా Ollama idle model ను ఐదు నిమిషాల తర్వాత 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 కూడా ఇదే భాగాకారాన్ని సూచిస్తుంది. server ఇంకా ప్రారంభం కాలేకపోతే, VPSలో Ollamaతో 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}'

response body లోని మొదటి byte వచ్చిన క్షణమే time_starttransfer. streaming chat completion లో ఆ byte మొదటి server-sent event కు చెందుతుంది. అది మొదటి content token కావచ్చు లేదా దాని వెంటనే పంపే role-only delta కావచ్చు. అందువల్ల ఈ విలువను ఒక event తేడాతో కూడిన TTFT గా పరిగణించండి. అదే server పై రెండు runs ను పోల్చడానికి ఇది తగినంత ఖచ్చితమైనది.

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

కాన్కరెన్సీ 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 సంఖ్య. స్థిరమైన సగటు కోసం దీన్ని 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 నేరుగా ఉండదు. కానీ దాన్ని ఒక భాగహారంతో లెక్కించవచ్చు. మొదటి token తరువాత ప్రతి output token కు సగటు సమయాన్ని Mean TPOT (ms): సూచిస్తుంది. కాబట్టి token కు 25 ms అంటే ప్రతి stream కు సెకనుకు 40 tokens. Output throughput ను concurrency తో భాగించినా అదే ఫలితం వస్తుంది.

తరువాత దీన్ని loop లో అమలు చేసి, ప్రతి run ను save చేయండి.

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 పై concurrency sweep ఎలా కనిపిస్తుందో చూపించే ఉదాహరణ మాత్రమే. ఇవి సాధ్యమైన పరిమాణ క్రమాల ఆధారంగా ఇచ్చినవి. ఇవి మీ server పై చేసిన కొలతలు కావు. ఇవి vendor గణాంకాలు కూడా కావు. పై loop ను అమలు చేసి, ఈ విలువల స్థానంలో మీ విలువలను ఉంచండి.

ఈ ఆకృతిని అర్థం చేసుకోండి. సాధారణీకరించగలిగేది ఈ ఆకృతే. ఒక stream వద్ద మొత్తం box ప్రతి second కు 92 tokens ఉత్పత్తి చేస్తుంది. p99 TTFT 61 ms ఉంటుంది. 128 streams వద్ద మొత్తం throughput ప్రతి second కు 2304 tokens కు చేరుతుంది. ఇది ఇరవై ఐదు రెట్లు ఎక్కువ. అయితే ప్రతి stream వేగం ప్రతి second కు 18 tokens కు తగ్గుతుంది. p99 TTFT 3820 ms కు చేరుతుంది. Batching వల్ల idle memory waits ఉపయోగకరమైన పనిగా మారుతుంది కాబట్టి మొత్తం throughput పెరుగుతుంది. అదే compute ఇప్పుడు అనేక streams మధ్య పంచబడుతుంది కాబట్టి ప్రతి stream వేగం తగ్గుతుంది.

చివరి doubling కీలక సంకేతాన్ని ఇస్తుంది. 64 నుంచి 128 streams కు పెంచినప్పుడు మొత్తం throughput ఆరు శాతానికి లోపే పెరుగుతుంది. అదే సమయంలో p99 TTFT సుమారు మూడు రెట్లు పెరుగుతుంది. అంటే KV cache నిండిపోయింది. Requests అమలు కాకుండా queue లో వేచి ఉంటున్నాయి. ఉపయోగకరమైన operating point దానికి ముందే ఉంటుంది. 32 streams వద్ద box ఇప్పటికీ ప్రతి second కు 1728 tokens అందిస్తుంది. ఇది peak లో 75 శాతం. ప్రతి stream కు ప్రతి second కు 54 tokens వేగం ఉంటుంది. p99 TTFT 498 ms ఉంటుంది. ఆ operating 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 ఖాళీ అయినప్పుడు కొత్త requests ను నడుస్తున్న batch లోకి చేర్చుతుంది. KV cache పూర్తయ్యే వరకు దాని curve పెరుగుతూనే ఉంటుంది. Ollama ఒక model, ఒక machine, తక్కువ setup cost కోసం optimize చేయబడింది. అందువల్ల ఒకే sweep కు రెండు engines వేర్వేరు ఫలితాలను ఇస్తాయి. ఇదే Ollama మరియు vLLM ను serving engines గా పోల్చడం యొక్క ప్రధాన విషయం. ప్రతి సంఖ్యను ఏ engine, ఏ version ఉత్పత్తి చేశాయో నమోదు చేయండి.

తప్పు విషయాన్ని కొలిచే ఐదు పద్ధతులు

• క్లయెంట్ చాలా దూరంలో ఉంది. ఇంటర్నెట్ ద్వారా మీ laptop నుంచి benchmark నిర్వహిస్తే, ప్రతి TTFT లో మీ round trip సమయం కూడా చేరుతుంది. అప్పుడు మీరు మీ home connection ను కొలుస్తారు. క్లయెంట్‌ను server ఉన్న region లోనే నడపండి.
• Model cold state లో ఉంది. మొదటి request లో weights loading కోసం సమయం పడుతుంది. vLLM లో graph capture కోసం కూడా సమయం పడవచ్చు. ఒక warmup batch పంపి, దాని ఫలితాన్ని విస్మరించండి.
• Prefix caching మీ తరఫున సమాధానం ఇచ్చింది. vLLM default గా automatic prefix caching ను enable చేస్తుంది. అందువల్ల ఒకే 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 ను report చేశారు. పట్టికలో ఇది అత్యంత అనుకూలమైన సంఖ్య. కానీ ఖర్చుతో దీనికి సంబంధం ఉండదు.

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

మీ 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 సమాన సేవ ధర million tokens కు $0.65. కాబట్టి 4.47 ను 0.65తో భాగిస్తే గంటకు 6.88 million tokens వస్తాయి. దాన్ని 3,600 seconds తో భాగిస్తే సుమారు 1,910 output tokens per second వస్తాయి. ధరలు వారివి. Division మనది.

ఈ నిర్ణయంలో ప్రధానమైన పదం sustained. రోజుకు రెండు గంటలు saturation వద్ద 1,910 tokens per second సాధించడం, sustained గా 1,910 tokens per second సాధించినట్లు కాదు. ఎందుకంటే మిగిలిన ఇరవై రెండు గంటలకు కూడా మీరు చెల్లిస్తారు. తక్కువ ధర కలిగిన $3.44 per hour GPU Droplet కోసం DigitalOcean స్వయంగా చూపిన crossover, 72.2 percent sustained average utilisation వద్ద ఉంటుంది. దాని కంటే తక్కువ utilisation ఉన్నప్పుడు per-token price ప్రయోజనకరంగా ఉంటుంది. సాధారణంగా self-hosting ను నష్టపరిచేది నెమ్మదైన tokens కాదు. ఉపయోగించని GPU గంటలే.

కాబట్టి మీ నిర్ణయానికి రెండు inputs ఉన్నాయి. Sweep మీ ceiling ను చూపుతుంది. మీ traffic pattern, ఆ ceiling లో మీరు వాస్తవంగా ఉపయోగించే fraction ను చూపుతుంది. ఈ రెండింటిని multiply చేయండి. తరువాత ఫలితాన్ని 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 ఖర్చయ్యే machine పై ప్రతి million tokens కు $0.65 ధర ఉంటే, 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 లో ఉంచి ఆ తరువాత 503 ను తిరిగి పంపుతుంది. p99 TTFT పెరుగుతున్నప్పటికీ మొత్తం output స్థిరంగా ఉంటే, GPU busyగా ఉండటం కంటే queue ఏర్పడినదే కారణం. systemd drop-in లో variable ను set చేసి service ను 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 విలువ ఎక్కువగా ఉంటే ప్రతి token ఖర్చు ఎల్లప్పుడూ తక్కువగా ఉంటుందా?

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