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

Tokens per second ஏன் ஒரு GPU-ன் லாபத்தை தீர்மானிக்கிறது

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

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

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

DigitalOcean, ஜூலை 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-மட்டும் கொண்ட வேகம் 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, ஒரு உரையாடலின் போது கார்டில் சேமிக்கப்படும் per-request நினைவகம்) கட்டுப்படுத்தப்படுகிறது. ஒரு 80 GB கார்டு 70B மாதிரிக்கான குறைவான ஒரேகாலக் கோரிக்கைகளையே (concurrent requests) தாங்கும், எனவே அதன் saturation அளவு குறைவாக இருக்கும்.

மாதிரியை மாற்றினாலோ அல்லது 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-ல் தான் வெளிப்படும்.

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

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

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

வெளியீட்டு நீளத்தையும் கட்டாயப்படுத்தவும். ஒரு 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-ஐக் கணக்கிட பரிந்துரைக்கப்படுகிறது. server இன்னும் இயங்கவில்லை என்றால், Ollama மூலம் VPS-ல் LLM-ஐ self-host செய்தல் என்ற பகுதி நிறுவல் மற்றும் 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-வாகவோ இருக்கலாம். எனவே, இந்த மதிப்பை TTFT-ஆகக் கருதலாம் (சிறிய மாற்றங்கள் இருக்கலாம்). ஒரே server-ல் இரண்டு இயக்கங்களை ஒப்பிட்டுப் பார்க்க இது போதுமான துல்லியமானது.

Single-stream எண்கள் server-ன் திறனை மிகைப்படுத்திக் காட்டும். TTFT மிகச் சிறந்த நிலையில் இருக்கும், ஏனெனில் உங்களுக்கு முன்னால் எந்த request-ம் வரிசையில் இல்லை. ஒவ்வொரு stream-க்கான வேகமும் மிகச் சிறந்த நிலையில் இருக்கும், ஏனெனில் முழு card-ம் ஒரு 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-க்கு பிந்தைய சராசரி நேரமாகும்; எனவே, ஒரு token-க்கு 25 ms என்பது ஒரு 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-ன் வேகமும் குறைகிறது.

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

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

இயல்புநிலை Ollama server-ல் அந்த sweep-ஐ இயக்கினால், மொத்த அளவு பெரிய அளவில் மாறாது. 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 செய்து, 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-க்கு queue செய்யப்படும் (இயல்பாக 512). அதற்கு மேல் சென்றால் server 503 பிழையை வழங்கும்.

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

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

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

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

உங்கள் sweep-ல் கிடைத்த saturated output throughput-ஐ எடுத்துக் கொள்ளுங்கள்; single-stream rate-ஐ அல்ல. அதை per-token விலையுடன் ஒப்பிடுங்கள். 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 மில்லியன் tokens கிடைக்கும். அதை 3,600 வினாடிகளால் வகுத்தால், வினாடிக்கு சுமார் 1,910 output tokens கிடைக்கும். விலைகள் அவர்களுடையது, வகுத்தல் நம்முடையது. அக்டோபர் 7, 2026 அன்று நாங்கள் சரிபார்த்தபோது, H200 endpoint விலை இன்னும் $4.47-ஆகவே இருந்தது. ஆனால், DigitalOcean ஆகஸ்ட் 18, 2026 அன்று serverless Llama 3.3 70B சேவையை நிறுத்திவிட்டு, பயனர்களை Llama 4 Maverick-க்கு மாற்றியது; அதன் விலை ஒரு மில்லியன் output tokens-க்கு $0.87. இது வேறொரு model என்பதால், ஒப்பீடு அர்த்தமுள்ளதாக இருக்க அதற்குத் தனி sweep தேவை.

இங்கு முடிவைத் தீர்மானிக்கும் சொல் sustained (தொடர்ச்சியான). ஒரு நாளில் இரண்டு மணி நேரம் மட்டும் saturation நிலையில் 1,910 tokens per second-ஐ எட்டுவது என்பது, sustained throughput 1,910 tokens per second என்று அர்த்தமல்ல; ஏனெனில் நீங்கள் மீதமுள்ள இருபத்தி இரண்டு மணி நேரத்திற்கும் பணம் செலுத்துகிறீர்கள். GPU Droplet-ஆக வாடகைக்கு எடுப்பது இந்த அளவுகோலைக் குறைக்காது: அக்டோபர் 7, 2026 அன்று DigitalOcean-ன் Droplet விலைப்பட்டியலில் H200 on-demand விலை endpoint-ஐப் போலவே ஒரு மணி நேரத்திற்கு $4.47-ஆக இருந்தது. அவர்களின் மலிவான NVIDIA Droplet-களான RTX 4000 (மணிக்கு $0.76) மற்றும் L40S அல்லது RTX 6000 (மணிக்கு $1.57) ஆகியவை 70B model-ஐ FP8-ல் வைத்திருக்கப் போதுமானவை அல்ல. எனவே, மேற்கூறிய புள்ளிவிவரங்களின்படி, 2,036 output tokens per second saturation-ஐ எட்டும் ஒரு H200, ஒரு மில்லியன் tokens-க்கு $0.65 என்ற விலையைச் சமன் செய்ய, நீங்கள் பணம் செலுத்தும் ஒவ்வொரு மணி நேரத்திலும் அந்த உச்ச அளவில் சுமார் 94 சதவீதத்தை சராசரியாகப் பெற வேண்டும். அதற்கு குறைவாக இருந்தால், per-token விலையே லாபகரமானது. பொதுவாக, self-hosting-ஐ நஷ்டமடையச் செய்வது மெதுவான tokens அல்ல, பயன்பாடற்ற idle GPU மணிநேரங்களே ஆகும்.

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

FAQ

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

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

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

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

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

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

ஒரு வினாடிக்கு அதிக tokens கிடைப்பது எப்போதும் ஒரு token-க்கான செலவைக் குறைக்குமா?

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