Local LLM-ல் Tokens per second அளவிடுவது எப்படி?

Tokens per second ஏன் GPU-ன் செலவுத் திறனைத் தீர்மானிக்கிறது

Tokens per second என்பது உங்கள் server வெளியீட்டு உரையை உருவாக்கும் வேகமாகும். ஒரு GPU-ஐ வாடகைக்கு எடுப்பது, API-க்கு token அடிப்படையில் பணம் செலுத்துவதை விட மலிவானதா என்பதை இந்த எண் தான் தீர்மானிக்கிறது. ஒரு GPU box பயன்பாட்டில் இருந்தாலும் இல்லாவிட்டாலும், மணிநேர அடிப்படையில் கட்டணம் வசூலிக்கப்படும். ஒரு hosted API-க்கு token அடிப்படையில் கட்டணம் வசூலிக்கப்படும். எனவே, நீங்கள் பணம் செலுத்தும் பெரும்பாலான மணிநேரங்களில் போதுமான அளவு அதிக வெளியீட்டு வேகத்தை (output rate) பராமரித்தால் மட்டுமே GPU லாபகரமாக இருக்கும்.

இதற்கு நீங்கள் எங்கோ படித்த ஒரு புள்ளிவிவரத்தை நம்பாமல், நீங்களே ஒரு அளவீட்டை மேற்கொள்ள வேண்டும். இந்தப் பக்கம் பதிவு செய்ய வேண்டிய நான்கு முக்கியமான எண்களை வரையறுக்கிறது. மேலும், அவற்றை எவ்வாறு கண்டறிவது என்பதற்கான commands மற்றும் அவற்றை முடிவெடுக்கும் கணக்கீடுகளையும் வழங்குகிறது.

வெளியிடப்பட்ட tokens per second புள்ளிவிவரம் ஏன் உங்களுக்கானது அல்ல

ஜூலை 2026-ல் DigitalOcean, 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-மட்டும் கொண்ட வேகம் 2,036 tok/s ஆகும். இந்தத் தலைப்புச் செய்தி input மற்றும் output tokens-ஐ ஒன்றாகக் கணக்கிடுகிறது. அந்தச் சோதனையில் 1,024 input tokens மற்றும் 1,024 output tokens பயன்படுத்தப்பட்டன, எனவே தலைப்புச் செய்தியில் கிட்டத்தட்ட பாதி அளவு output ஆகும். இந்தப்பிரிப்பு முக்கியமானது, ஏனெனில் நீங்கள் கட்டணம் செலுத்துவது output-க்கு மட்டுமே, அதுவே மெதுவான பகுதியாகும். Prefill (prompt-ஐ வாசித்தல்) அனைத்து input tokens-ஐயும் ஒரே முறையில் செயலாக்குகிறது. Decode (பதிலை எழுதுதல்) ஒரு நேரத்தில் ஒரு token-ஐ உருவாக்குகிறது. மொத்த throughput தலைப்புச் செய்தி, மலிவான எண்ணையும் விலையுயர்ந்த எண்ணையும் சராசரி செய்கிறது.

இப்போது முதல் வரிசையைப் பார்க்கவும். அதே H200 ஒரு நேரத்தில் ஒரு கோரிக்கையைச் (request) செயலாக்கும்போது 47 tok/s-ஐ உருவாக்குகிறது, எனவே ஒரே மாதிரியான hardware-ல் saturated புள்ளிவிவரம் நாற்பது மடங்கு அதிகமாக உள்ளது. இந்த இடைவெளி இருப்பதற்குக் காரணம், ஒரு decode படிநிலையில் GPU தனது நேரத்தின் பெரும்பகுதியை memory-க்காகக் காத்திருப்பதில் செலவிடுகிறது, மேலும் ஒரே நேரத்தில் வரும் கோரிக்கைகள் அந்த idle நேரத்தை நிரப்புகின்றன. இரண்டாவது வரிசையான 236 tok/s என்பது அதே model-ல் ஒரு ஒற்றை H100 ஆகும், இது KV cache-ஆல் (key and value cache, ஒரு உரையாடலின் போது card-ல் சேமிக்கப்படும் per-request memory) கட்டுப்படுத்தப்படுகிறது. 80 GB card-ல் 70B model-க்கான ஒரே நேரத்தில் வரும் கோரிக்கைகளை குறைவாகவே கையாள முடியும், எனவே அதன் saturation அளவு குறைவாக இருக்கும்.

model-ஐ மாற்றினாலோ அல்லது input-to-output விகிதத்தை மாற்றினாலோ மேலே உள்ள ஒவ்வொரு எண்ணும் மாறும். வெளியிடப்பட்ட புள்ளிவிவரங்கள் உங்கள் எதிர்பார்ப்புகளை மட்டுமே நிர்ணயிக்கும், உங்கள் பட்ஜெட்டை அல்ல. இதுவே VPS-ஐ நேர்மையாக benchmarking செய்தல் முறைக்கும் disk மற்றும் network-க்கும் பொருந்தும் அதே விதியாகும்.

கவனிக்க வேண்டிய நான்கு முக்கிய எண்கள்

• Time to first token, TTFT. ஒரு கோரிக்கையை (request) அனுப்பியதற்கும், முதல் வெளியீட்டு டோக்கன் (output token) கிடைப்பதற்கும் இடைப்பட்ட தாமதம். இது prefill நேரம் மற்றும் queue நேரத்தின் கூட்டுத்தொகை. பயனர் நேரடியாக உணரும் காரணி இதுவே.
• Output tokens per second, per stream. ஒரு பதில் எழுதத் தொடங்கிய பிறகு, அது எவ்வளவு வேகமாக உருவாகிறது என்பதைக் குறிக்கும். வினாடிக்கு சுமார் 20 tokens-க்கு மேல் இருந்தால், அது பெரும்பாலானோர் வாசிக்கும் வேகத்தை விட அதிகம் என்பதால், கூடுதல் வேகம் பெரிய பயனைத் தராது.
• Saturated total output throughput. சர்வர் முழுமையாகச் செயல்படும்போது, ஒரே நேரத்தில் இயங்கும் அனைத்து stream-களின் மொத்த வெளியீடு. இதுவே சர்வரின் கொள்ளளவு (capacity) எண்; GPU செலவுகளைத் தீர்மானிப்பது இதுவே.
• p50 and p99 TTFT under concurrency. p50 என்பது நடுத்தரமான கோரிக்கையைக் குறிக்கும். p99 என்பது 100-ல் 99 கோரிக்கைகள் முடிவடையும் நேரத்தைக் குறிக்கும். வரிசையில் காத்திருக்கும் சிக்கல்கள் (queueing) எப்போதும் p99 அளவீட்டிலேயே முதலில் வெளிப்படும்.

சர்வர் குறைவாகப் பயன்படுத்தப்படும்போது முதல் இரண்டு அளவீடுகள் சிறப்பாக இருக்கும். சர்வர் அதிகப் பயன்பாட்டில் இருக்கும்போது மூன்றாவது அளவீடு முக்கியத்துவம் பெறும். இவை ஒன்றுக்கொன்று முரணானவை என்பதால், ஒரே ஒரு எண்ணைக் கொண்டு சர்வரின் செயல்திறனை முழுமையாக வரையறுக்க முடியாது.

அளவீடு செய்வதற்கு முன் உள்ளீடு மற்றும் வெளியீட்டு நீளங்களைச் சரிசெய்யவும்

Throughput என்பது traffic-ன் தன்மையைப் பொறுத்தது. 4,000-token prompt மற்றும் 50-token பதில் கொண்ட வேலை prefill-heavy வகையைச் சார்ந்தது. 200-token prompt மற்றும் 2,000-token பதில் கொண்ட வேலை decode-heavy வகையைச் சார்ந்தது. ஒரே server-ல் இந்த இரண்டுக்கும் tokens per second அளவு மாறுபடும். எனவே, ஒரு விகிதத்தைத் (ratio) தேர்வு செய்து, நீங்கள் பதிவு செய்யும் ஒவ்வொரு எண்ணின் அருகிலும் அதைக் குறிப்பிடவும். வெவ்வேறு விகிதங்களை ஒப்பிட வேண்டாம். பல நிறுவனங்கள் 1,024 in மற்றும் 1,024 out என்ற விகிதத்தையே வெளியிடுவதால், இதையே இயல்பான அளவீடாகக் கொள்வது சிறந்தது. உங்கள் பயன்பாட்டின் உண்மையான traffic தெரிந்தால், அதையே பயன்படுத்தவும்.

வெளியீட்டு நீளத்தையும் (output length) கட்டாயப்படுத்தவும். ஒரு model 60 tokens-க்கு பிறகு stop token-ஐ அடைந்தால், அந்த run குறுகியதாகி வேகமாகத் தெரியும், ஏனெனில் TTFT அதில் அதிகப் பங்கைக் கொண்டிருக்கும். vLLM benchmark client-ல் உள்ள --ignore-eos flag, ஒவ்வொரு கோரிக்கையும் சரியாகக் கேட்கப்பட்ட எண்ணிக்கையிலான tokens-ஐ உருவாக்குவதை உறுதி செய்கிறது. இதனால் இரண்டு run-களை ஒப்பிட முடியும். எந்தவொரு flag-ஐ விடவும், model தேர்வுதான் இந்த எண்களை அதிகம் மாற்றும்: Qwen 3 model-ஐ ஒரு VPS GPU-ல் பொருத்துதல் என்பது அந்தத் தேர்வின் memory சார்ந்த அம்சங்களை விளக்குகிறது.

ஒரு stream-ஐ முதலில் அளவிடுதல்

மிகவும் எளிமையான சூழலில் இருந்து தொடங்கவும். இது ஒரு sanity check மற்றும் இதுவே அதிகபட்ச செயல்திறன் வரம்பு (ceiling). Ollama தனது சொந்த நேர அளவீடுகளை வெளியிடுகிறது.

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

நீங்கள் கவனிக்க வேண்டிய வரி eval rate, இது ஒரு வினாடிக்கு உருவாக்கப்படும் tokens-ன் எண்ணிக்கையைக் குறிக்கிறது. prompt eval rate என்பது prefill rate, மற்றும் load duration என்பது model-ஐ VRAM-ல் ஏற்ற எடுத்துக்கொள்ளும் நேரம். cold start-க்கு பிறகு முதல் அழைப்பின் போது load duration அதிகமாக இருக்கும், எனவே total duration தவறான புரிதலை ஏற்படுத்தலாம். கட்டளையை இரண்டு முறை இயக்கவும், இரண்டாவது முடிவைப் பார்க்கவும். Ollama இயல்புநிலையாக ஐந்து நிமிடங்களுக்குப் பிறகு பயன்பாட்டில் இல்லாத model-ஐ நீக்கிவிடும், எனவே இரண்டு இயக்கங்களுக்கு இடையே நீண்ட இடைவெளி இருந்தால், அது மீண்டும் cold case நிலைக்குச் சென்றுவிடும்.

இதே தகவல்கள் 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-ஆல் வகுத்தால் வினாடிகள் கிடைக்கும். அந்த வகுத்தல் முறையே Ollama-வின் சொந்த API ஆவணத்தில் tokens per second-ஐக் கணக்கிட பரிந்துரைக்கப்படுகிறது. server இன்னும் தயாராகவில்லை என்றால், Ollama மூலம் VPS-ல் LLM-ஐ self-hosting செய்தல் என்ற பகுதி நிறுவல் மற்றும் 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-ல் இரண்டு இயக்கங்களை ஒப்பிடுவதற்கு இது போதுமான துல்லியமானது.

Single-stream எண்கள் server-ன் திறனை மிகைப்படுத்திக் காட்டும். TTFT என்பது மிகச்சிறந்த நிலையில் இருக்கும், ஏனெனில் உங்களுக்கு முன்னால் எந்த request-ம் வரிசையில் இல்லை. Per-stream rate-ம் மிகச்சிறந்த நிலையில் இருக்கும், ஏனெனில் முழு GPU-வும் ஒரு request-ஐ மட்டுமே கையாள்கிறது. இவை இரண்டும் அந்த server-ன் உண்மையான கொள்ளளவை (capacity) குறிக்காது.

Concurrency sweep-ஐ எவ்வாறு இயக்குவது?

Sweep என்பது ஒரு நிலையான பணிச்சுமையை (workload) அதிகரித்துக்கொண்டே செல்லும் concurrency-ல் இயக்கி, ஒவ்வொரு நிலையிலும் என்ன நடக்கிறது என்பதைப் பதிவு செய்கிறது. vLLM இதற்கான 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 in flight) எண்ணிக்கையைக் கட்டுப்படுத்துகிறது; இதுவே நீங்கள் 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): ஆகியவற்றைக் காட்டும்.

அந்த வெளியீட்டில் stream-க்கு தனிப்பட்ட விகிதம் இல்லை, ஆனால் ஒரு எளிய வகுத்தல் மூலம் அதைக் கண்டறியலாம். Mean TPOT (ms): என்பது முதல் token-க்கு பிந்தைய சராசரி நேரமாகும்; எனவே 25 ms per token என்பது ஒரு stream-க்கு வினாடிக்கு 40 tokens ஆகும். வெளியீட்டு 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 பெட்டியில், நம்பத்தகுந்த அளவில் ஒரு sweep உருவாக்கும் வடிவத்தை விளக்கும் உதாரணங்கள் மட்டுமே. இவை உங்கள் server-ன் அளவீடுகள் அல்ல, விற்பனையாளர் வழங்கிய புள்ளிவிவரங்களும் அல்ல. மேலே உள்ள loop-ஐ இயக்கி, அந்த மதிப்புகளை உங்கள் சொந்த தரவுகளைக் கொண்டு மாற்றவும்.

அந்த வடிவத்தைப் புரிந்துகொள்ளுங்கள், ஏனெனில் அந்த வடிவமே பொதுவான தன்மையைக் குறிக்கிறது. ஒரு stream-ல், முழு பெட்டியும் வினாடிக்கு 92 tokens-ஐ உருவாக்குகிறது, அதன் p99 TTFT 61 ms ஆக உள்ளது. 128 streams அளவில், மொத்த வேகம் வினாடிக்கு 2304 tokens-ஆக உயர்கிறது; இது இருபத்தைந்து மடங்கு அதிகம். அதே சமயம், ஒவ்வொரு தனிப்பட்ட stream-ன் வேகமும் வினாடிக்கு 18 tokens-ஆகக் குறைகிறது மற்றும் p99 TTFT 3820 ms-ஐ எட்டுகிறது. Batching செய்வதன் மூலம், சும்மா இருக்கும் memory காத்திருப்பு நேரத்தை பயனுள்ள வேலையாக மாற்றுவதால், மொத்த throughput அதிகரிக்கிறது. அதே compute திறன் பல stream-களுக்குப் பகிரப்படுவதால், தனிப்பட்ட stream-ன் வேகம் குறைகிறது.

கடைசியாக நிகழும் இரட்டிப்புதான் முக்கியமான அறிகுறி. 64-லிருந்து 128 stream-களுக்குச் செல்லும்போது, மொத்த வேகத்தில் ஆறு சதவீதத்திற்கும் குறைவான வளர்ச்சியே கிடைக்கிறது, ஆனால் p99 TTFT சுமார் மூன்று மடங்கு அதிகரிக்கிறது. இதன் பொருள், KV cache நிரம்பிவிட்டது மற்றும் கோரிக்கைகள் (requests) இயங்குவதற்குப் பதிலாக வரிசையில் காத்திருக்கின்றன என்று அர்த்தம். பயனுள்ள செயல்பாட்டு புள்ளி (operating point) இதற்கு முன்பே உள்ளது: 32 stream-களில், அந்த பெட்டி இன்னும் வினாடிக்கு 1728 tokens-ஐ வழங்குகிறது, இது அதன் உச்சகட்ட வேகத்தில் 75 சதவீதமாகும். அப்போது ஒவ்வொரு stream-க்கும் வினாடிக்கு 54 tokens கிடைக்கிறது மற்றும் p99 TTFT 498 ms ஆக உள்ளது. இந்தப் புள்ளியையே உங்கள் கொள்ளளவாக (capacity) குறிப்பிடவும். வளைவின் உச்சியில் உள்ள எண்ணை வைத்து பயனர்களுக்குச் சேவை வழங்க முடியாது.

Ollama மற்றும் vLLM ஆகியவை ஒரே விஷயத்தை அளவிடுவதில்லை

இயல்புநிலை Ollama server-ல் அந்த sweep-ஐ இயக்கினால், மொத்த அளவு பெரிய அளவில் மாறாது. OLLAMA_NUM_PARALLEL இயல்பாக 1 என இருப்பதால், ஒரு request இயங்கும்போது மற்றவை காத்திருக்கும். இந்த வரிசைமுறைதான் 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 ஆவணங்கள் குறிப்பிடுகின்றன. slot எண்ணிக்கையை அதிகமாக உயர்த்தினால், model VRAM-லிருந்து வெளியேறிவிடும். ollama ps-ஐச் சரிபார்க்கவும்: PROCESSOR column-ல் 48%/52% CPU/GPU போன்ற ஒரு மதிப்பு இருந்தால், model-ன் ஒரு பகுதி CPU-வில் உள்ளது என்று அர்த்தம். இப்போது நீங்கள் concurrency-ஐ அதிகரிக்கும்போது throughput அதிகரிப்பதற்குப் பதிலாகக் குறையும். parallel slots-க்கு அப்பால், requests OLLAMA_MAX_QUEUE-க்கு வரிசைப்படுத்தப்படும் (இயல்பாக 512). அதற்கு மேல் சென்றால் server 503 பிழையை வழங்கும்.

vLLM continuous batching-ஐப் பயன்படுத்துகிறது. எனவே, slots காலியாகும்போது புதிய requests-ஐ இயங்கும் batch-க்குள் அது அனுமதிக்கும். KV cache தீரும் வரை அதன் செயல்திறன் வளைவு (curve) உயர்ந்து கொண்டே இருக்கும். Ollama ஒரு model, ஒரு machine, குறைந்த setup செலவு ஆகியவற்றிற்காக மேம்படுத்தப்பட்டுள்ளது. எனவே, இந்த இரண்டு engines-ம் ஒரே sweep-க்கு வெவ்வேறு பதில்களைத் தரும். இதுவே Ollama மற்றும் vLLM ஆகியவற்றை serving engines-ஆக ஒப்பிடுதல் என்பதன் உண்மையான பொருளாகும். ஒவ்வொரு எண்ணையும் எந்த engine மற்றும் எந்த version உருவாக்கியது என்பதைப் பதிவு செய்யவும்.

தவறான விஷயங்களை அளவிடுவதற்கான ஐந்து வழிகள்

• Client தொலைவில் உள்ளது. இணையம் வழியாக உங்கள் laptop-லிருந்து benchmarking செய்யும்போது, ஒவ்வொரு TTFT-க்கும் உங்கள் round trip நேரம் சேர்க்கப்படுகிறது; எனவே நீங்கள் உங்கள் வீட்டு இணைய இணைப்பையே அளவிடுகிறீர்கள். Client-ஐ server இருக்கும் அதே region-ல் இயக்கி சோதிக்கவும்.
• Model cold நிலையில் இருந்தது. முதல் request-க்கு weight loading-க்கான நேரம் தேவைப்படும், vLLM-ல் graph capture-க்கும் நேரம் எடுக்கலாம். ஒரு warmup batch-ஐ அனுப்பிவிட்டு, அதன் முடிவுகளைப் புறக்கணிக்கவும்.
• Prefix caching உங்களுக்குப் பதிலளித்தது. vLLM தானாகவே prefix caching-ஐ இயல்பாகவே செயல்படுத்துகிறது, எனவே ஒரே prompt-ஐ மீண்டும் மீண்டும் அனுப்பும்போது prefill-க்கு பதிலாக cache-ஐயே அளவிடுகிறீர்கள்; இதனால் TTFT உண்மையான மதிப்பை விட மிகக் குறைவாகக் காட்டப்படும். --dataset-name random ஒவ்வொரு prompt-ம் மாறுபடுவதால் இந்தச் சிக்கலைத் தவிர்க்கிறது. இதை உறுதிப்படுத்த, --no-enable-prefix-caching flag-ஐப் பயன்படுத்தி server-ஐத் தொடங்கவும்.
• வெளியீடுகள் மிகச் சிறியவை. 32-token பதில்களைப் பயன்படுத்தும்போது, ஒவ்வொரு request-லும் TTFT-ன் ஆதிக்கமே அதிகமாக இருக்கும், உங்கள் tokens per second கணக்கீடு உண்மையில் prefill-ஐ மட்டுமே குறிக்கும். யதார்த்தமான வெளியீட்டு நீளத்துடன் --ignore-eos-ஐப் பயன்படுத்தவும்.
• நீங்கள் concurrency 1-ஐப் பதிவு செய்துள்ளீர்கள். இது அட்டவணையில் பார்க்க எளிதான எண், ஆனால் இது செலவுத் திறனுடன் எந்தத் தொடர்பும் கொண்டதல்ல.

அளவிடப்பட்ட எண்ணை முடிவெடுக்கும் காரணியாக மாற்றுதல்

உங்கள் sweep சோதனையிலிருந்து பெறப்பட்ட முழுமையான output throughput-ஐ எடுத்துக்கொள்ளுங்கள் (single-stream rate அல்ல). இதை per-token விலையுடன் ஒப்பிடுங்கள். 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 மாற்று விலை ஒரு மில்லியன் tokens-க்கு $0.65. எனவே, 4.47-ஐ 0.65-ஆல் வகுத்தால் ஒரு மணி நேரத்திற்கு 6.88 மில்லியன் tokens கிடைக்கும். இதை 3,600 வினாடிகளால் வகுத்தால், வினாடிக்கு சுமார் 1,910 output tokens கிடைக்கும். விலைகள் அவர்களுடையது, கணக்கீடு நம்முடையது.

இங்கு முடிவெடுக்கும் முக்கிய சொல் sustained (தொடர்ச்சியான பயன்பாடு) என்பதாகும். ஒரு நாளில் இரண்டு மணி நேரம் மட்டும் வினாடிக்கு 1,910 tokens என்ற உச்சத்தை அடைவது, வினாடிக்கு 1,910 tokens sustained என்று அர்த்தமாகாது; ஏனெனில் நீங்கள் மீதமுள்ள இருபத்தி இரண்டு மணி நேரத்திற்கும் கட்டணம் செலுத்த வேண்டியிருக்கும். DigitalOcean-ன் $3.44 விலை கொண்ட GPU Droplet-க்கான crossover புள்ளி 72.2 சதவீத sustained பயன்பாட்டில் அமைகிறது. அதற்கு கீழே பயன்பாடு இருந்தால், per-token விலை முறையே லாபகரமானது. மெதுவான tokens-ஐ விட, பயன்படுத்தப்படாத idle GPU மணிநேரங்களே self-hosting-ஐ நஷ்டமடையச் செய்யும்.

எனவே, உங்கள் முடிவுக்கு இரண்டு உள்ளீடுகள் தேவை. Sweep சோதனை உங்களுக்கு அதிகபட்ச உச்ச வரம்பைத் (ceiling) தருகிறது. உங்கள் traffic pattern, அந்த உச்ச வரம்பில் நீங்கள் உண்மையில் பயன்படுத்தும் அளவைத் தருகிறது. இரண்டையும் பெருக்கி, வரும் விடையை GPU VPS மற்றும் per-token API break-even ஒப்பீடு பகுதிக்கு எடுத்துச் சென்று, உங்கள் பயன்பாட்டு அளவிற்கு ஏற்ற முடிவைப் பெறுங்கள்.

FAQ

சுய-வழங்கப்பட்ட (self-hosted) LLM-க்கு ஒரு வினாடிக்கு எத்தனை tokens இருப்பது சிறந்தது?

இதற்கு இரண்டு பதில்கள் உள்ளன, ஏனெனில் இந்த அளவீடு இரண்டு பணிகளைச் செய்கிறது. வெளியீட்டை வாசிக்கும் ஒரு நபருக்கு, ஒரு வினாடிக்கு சுமார் 20 output tokens-க்கு மேல் இருந்தால் அது வாசிக்கும் வேகத்தை விட அதிகமாக இருக்கும், எனவே அதற்கு மேல் இருப்பது பெரிய மாற்றத்தை ஏற்படுத்தாது. செலவைப் பொறுத்தவரை, முக்கியமான எண் மொத்த output throughput ஆகும். உங்கள் செலவை ஈடுகட்டும் அளவே சிறந்ததாகக் கருதப்படுகிறது. ஒரு மணி நேரத்திற்கு $4.47 செலவாகும் சர்வரில், ஒரு மில்லியன் tokens-க்கு $0.65 என்ற விலையில், ஜூலை 2026 விலையின்படி ஒரு வினாடிக்கு 1,910 output tokens என்பது ஒரு நிலையான அளவாகும். ஒரு பெரிய மாடலில் ஒரே ஒரு stream மூலம் இந்த அளவை அடைய முடியாது, இதனால்தான் batching பயன்படுத்தப்படுகிறது.

நான் ஒரே நேரத்தில் பல கோரிக்கைகளை (concurrent requests) அனுப்பும்போது ஏன் Ollama-வின் throughput மாறாமல் இருக்கிறது?

OLLAMA_NUM_PARALLEL இயல்பாக 1 என அமைக்கப்பட்டுள்ளது, எனவே சர்வர் ஒரு நேரத்தில் ஒரு மாடலுக்கு ஒரு கோரிக்கையை மட்டுமே கையாளும். மற்றவை வரிசையில் (queue) வைக்கப்படும். OLLAMA_MAX_QUEUE (இயல்பாக 512) வரை வரிசையில் காத்திருந்து, அதற்கு மேல் சென்றால் 503 பிழையைத் தரும். GPU பிஸியாக இருப்பதற்குப் பதிலாக, கோரிக்கைகள் வரிசையில் காத்திருப்பதால், மொத்த output மாறாமல் இருக்கும் அதே வேளையில் p99 TTFT அதிகரிக்கும். systemd drop-in-ல் இந்த மாறியை (variable) அமைத்து, சர்வரை restart செய்யவும். பின்னர் ollama ps-ஐச் சரிபார்க்கவும், ஏனெனில் ஒவ்வொரு parallel slot-ம் ஒதுக்கப்பட்ட context-ஐப் பெருக்கி, மாடலின் ஒரு பகுதியை CPU-க்குத் தள்ளக்கூடும்.

நான் time to first token-ஐ அளவிட வேண்டுமா அல்லது tokens per second-ஐ அளவிட வேண்டுமா?

இரண்டையுமே அளவிட வேண்டும், ஏனெனில் சுமை (load) அதிகரிக்கும் போது இவை இரண்டும் எதிர் திசையில் செயல்படுகின்றன. பயனர் உணர்வது TTFT-ஐத்தான், உங்கள் கட்டணத்தில் பிரதிபலிப்பது saturated output throughput ஆகும். ஒவ்வொரு concurrency நிலையிலும் p50 மற்றும் p99 TTFT-ஐப் பதிவு செய்யவும். பின்னர், p99 TTFT உங்களுக்கு ஏற்புடையதாக இருக்கும் மிக உயர்ந்த concurrency அளவைத் தேர்ந்தெடுக்கவும். அந்தப் புள்ளியில் உள்ள throughput-ஐ உங்கள் கொள்ளளவாகக் (capacity) கருதவும், வளைவின் உச்சியில் உள்ள அதிகபட்ச அளவை அல்ல.

tokens per second எண் அதிகமாக இருந்தால், ஒரு token-க்கான செலவு எப்போதும் குறைவாக இருக்குமா?

இல்லை. ஒரு token-க்கான செலவு என்பது, அந்த மணிநேரத்தில் சர்வர் உண்மையில் உருவாக்கிய tokens-ஆல் வகுக்கப்படும் மணிநேர விலையாகும். எனவே, நாள் முழுவதும் சும்மா இருக்கும் ஒரு வேகமான சர்வர், ஒரு token-க்கு அதிக செலவையே கொண்டிருக்கும். உச்ச வேகம் (peak speed) அல்ல, பயன்பாடுதான் (utilisation) இதைத் தீர்மானிக்கிறது. அலகுகளையும் (units) கவனிக்கவும்: குறிப்பிடப்படும் மொத்த token throughput என்பது input tokens-ஐயும் கணக்கிடுகிறது. எனவே 1:1 என்ற input-to-output விகிதத்தில், இது நீங்கள் கட்டணம் செலுத்தும் output விகிதத்தை விட இருமடங்காக இருக்கும்.