Local LLM-এ প্রতি সেকেন্ডে token মাপার পদ্ধতি

কেন প্রতি সেকেন্ডে টোকেনের হার নির্ধারণ করে GPU নেওয়া সাশ্রয়ী কি না

প্রতি সেকেন্ডে টোকেনের হার হলো আপনার সার্ভার যে গতিতে আউটপুট টেক্সট তৈরি করে। এই হারই নির্ধারণ করে, প্রতি টোকেনের জন্য API-কে অর্থ দেওয়ার চেয়ে GPU ভাড়া করা সাশ্রয়ী কি না। GPU server ব্যস্ত থাকুক বা নিষ্ক্রিয় থাকুক, প্রতি ঘণ্টা অনুযায়ী বিল হয়। Hosted API-তে টোকেনের সংখ্যা অনুযায়ী বিল হয়। তাই আপনি যে সময়ের জন্য অর্থ দিচ্ছেন, তার বেশির ভাগ সময়ে যথেষ্ট বেশি output rate বজায় রাখতে পারলেই GPU সাশ্রয়ী হয়।

তাই অন্য কোথাও পড়া কোনো সংখ্যা নয়, আপনার একটি পরিমাপ প্রয়োজন। এই পৃষ্ঠায় নথিবদ্ধ করার মতো চারটি সংখ্যা সংজ্ঞায়িত করা হয়েছে। এরপর সেই সংখ্যাগুলো বের করার command এবং সেগুলো ব্যবহার করে সিদ্ধান্তে পৌঁছানোর হিসাব দেওয়া হয়েছে।

প্রকাশিত tokens per second-এর সংখ্যা আপনার সংখ্যা নয় কেন

DigitalOcean 2026 সালের July মাসে llama3.3-70b-instruct-কে vLLM-এর অধীনে FP8 (8-bit floating point)-এ চালানো একটি 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"
  }
]

উপরের প্রতিটি row ওই page থেকে নেওয়া হয়েছে। এর মধ্যে দুটি row-তে দেওয়া range-এর নিম্নসীমা ব্যবহার করা হয়েছে, তাই ওই দুটিকে minimum হিসেবে পড়ুন। এই chart-এর কোনো মাপই আমরা নিইনি।

শেষের দুটি row দিয়ে শুরু করুন। Headline হলো 4,071.6 tok/s, আর output-only rate হলো 2,036 tok/s। Headline-এ input ও output token একসঙ্গে গণনা করা হয়েছে। ওই test-এ 1,024টি input token এবং 1,024টি output token ব্যবহার করা হয়েছে। তাই headline-এর প্রায় অর্ধেকই output। এই বিভাজন গুরুত্বপূর্ণ, কারণ billing-এর ভিত্তি output, এবং এটিই ধীর অংশ। Prefill অর্থ prompt পড়া; এটি এক pass-এ সব input token process করে। Decode অর্থ answer লেখা; এটি একবারে একটি token তৈরি করে। মোট throughput-এর headline একটি কম-খরচের সংখ্যা এবং একটি বেশি-খরচের সংখ্যার গড়।

এবার প্রথম row দেখুন। একই H200 একবারে একটি request serve করলে 47 tok/s দেয়। তাই একই hardware-এ saturated figure চল্লিশ গুণেরও বেশি বেশি। এর কারণ, একটি decode step-এর বেশির ভাগ সময় GPU memory-এর জন্য অপেক্ষা করে। Concurrent request এই idle time ব্যবহার করে। দ্বিতীয় row-তে থাকা 236 tok/s হলো একই model-এ একটি H100-এর ফল। এটি KV cache-এর কারণে সীমিত। KV cache হলো key এবং value cache; কোনো served conversation-এর জন্য card-এ রাখা per-request memory। 70B model-এর ক্ষেত্রে 80 GB card-এ কম concurrent request রাখা যায়। তাই এটি কম throughput-এ saturation-এ পৌঁছায়।

Model পরিবর্তন করলে বা input-to-output ratio পরিবর্তন করলে উপরের প্রতিটি সংখ্যা বদলে যাবে। Published figure আপনার expectation নির্ধারণ করে, budget নয়। Disk এবং network-এ VPS সঠিকভাবে benchmark করা-র ক্ষেত্রেও একই নিয়ম প্রযোজ্য।

গুরুত্বপূর্ণ চারটি সংখ্যা

• প্রথম token পাওয়ার সময়, TTFT। অনুরোধ পাঠানো থেকে প্রথম output token আসা পর্যন্ত বিলম্ব। এর মধ্যে prefill time এবং queue time দুটিই অন্তর্ভুক্ত। ব্যবহারকারী এই বিলম্বটি সরাসরি অনুভব করেন।
• প্রতি stream-এ প্রতি সেকেন্ডে output token। উত্তর লেখা শুরু হওয়ার পর একটি উত্তর কত দ্রুত লেখা হয়। প্রায় 20 tok/s-এর বেশি গতি হলে তা বেশিরভাগ মানুষের পড়ার গতির চেয়ে বেশি হয়। তাই এর পর আরও গতি বাড়ালে লাভ কম।
• সম্পূর্ণ load-এ মোট output throughput। সার্ভার সম্পূর্ণ load-এ থাকা অবস্থায় সব concurrent stream-এর output-এর যোগফল। এটি capacity-এর সংখ্যা। GPU-এর খরচ মেটানোর ক্ষেত্রে এই সংখ্যাটিই প্রধান।
• concurrency-র অধীনে p50 এবং p99 TTFT। p50 হলো মাঝামাঝি request-এর মান। p99 হলো সেই মান, যার নিচে 100টির মধ্যে 99টি request সম্পন্ন হয়। Queueing-এর প্রভাব প্রথমে p99-তেই দেখা যায়।

সার্ভার কম ব্যস্ত থাকলে প্রথম দুটি মান উন্নত হয়। সার্ভার ব্যস্ত থাকলে তৃতীয় মান উন্নত হয়। এগুলো পরস্পরের বিপরীত দিকে প্রভাব ফেলে। তাই কোনো একটি সংখ্যা দিয়ে serving box-এর সম্পূর্ণ বৈশিষ্ট্য বোঝানো যায় না।

পরিমাপের আগে ইনপুট ও আউটপুটের দৈর্ঘ্য নির্ধারণ করুন

Throughput ট্রাফিকের গঠনের ওপর নির্ভর করে। 4,000-token prompt এবং 50-token উত্তর prefill-heavy কাজ। 200-token prompt এবং 2,000-token উত্তর decode-heavy কাজ। একই server এই দুই ক্ষেত্রে tokens per second-এর খুব ভিন্ন ফল দেখায়। তাই একটি অনুপাত নির্ধারণ করুন, রেকর্ড করা প্রতিটি সংখ্যার পাশে সেই অনুপাত লিখুন, এবং ভিন্ন অনুপাতের ফল কখনও তুলনা করবেন না। 1,024 in এবং 1,024 out একটি যুক্তিসংগত default, কারণ কয়েকটি vendor এই অনুপাতে ফল প্রকাশ করে। আপনার প্রকৃত traffic জানা থাকলে প্রকৃত traffic ব্যবহার করুন।

Output-এর দৈর্ঘ্যও নির্দিষ্ট করুন। কোনো model 60 token-এর পরে stop token পেলে run ছোট হয় এবং দ্রুত মনে হয়, কারণ তখন TTFT-এর অংশ তুলনামূলকভাবে বেশি থাকে। vLLM benchmark client-এর --ignore-eos flag প্রতিটি request-কে নির্ধারিত সংখ্যক token তৈরি করতে বাধ্য করে। ফলে দুটি run তুলনাযোগ্য থাকে। যেকোনো flag-এর চেয়ে model নির্বাচন এই সংখ্যাগুলোকে বেশি প্রভাবিত করে: একটি single 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 token-এর সংখ্যা। prompt eval rate হলো prefill rate, আর load duration হলো model-কে VRAM-এ load করতে ব্যয় হওয়া সময়। cold start-এর পরে প্রথম call-এ load duration বড় হয়, তাই total duration বিভ্রান্তিকর। command-টি দুইবার চালিয়ে দ্বিতীয় ফলাফল পড়ুন। Ollama ডিফল্টভাবে idle model পাঁচ মিনিট পরে unload করে। তাই দুই run-এর মধ্যে দীর্ঘ বিরতি হলে আবার cold case-এ ফিরে যাবেন।

একই field 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 nanosecond-এ দেওয়া হয়। তাই 1,000,000,000 দিয়ে ভাগ করলে second পাওয়া যায়। 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}'

time_starttransfer হলো response body-এর প্রথম byte আসার সময়। streaming chat completion-এ এই byte প্রথম server-sent event-এর অংশ। এটি হয় প্রথম content token, অথবা তার ঠিক আগে পাঠানো role-only delta। তাই এই মানকে প্রায় এক event-এর তারতম্যসহ TTFT হিসেবে বিবেচনা করুন। একই server-এ দুটি run তুলনা করার জন্য এটি যথেষ্ট নির্ভুল।

Single-stream সংখ্যা server-এর সক্ষমতাকে দুবার বেশি দেখায়। TTFT যত কম হবে, এটিই তার সর্বোত্তম অবস্থা, কারণ আপনার আগে কোনো request queue-তে নেই। প্রতি-stream rate-ও সর্বোচ্চ, কারণ সম্পূর্ণ card একটি request পরিবেশন করছে। এই দুটির কোনোটিই দেখায় না যে server বাস্তবে কতটা load বহন করতে পারে।

কীভাবে concurrency sweep চালাবেন?

একটি sweep-এ concurrency ধাপে ধাপে বাড়িয়ে একই নির্দিষ্ট workload চালানো হয় এবং প্রতিটি ধাপে কী ঘটছে তা রেকর্ড করা হয়। 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 একসঙ্গে চলমান request-এর সংখ্যা সীমাবদ্ধ করে। এটিই sweep করার variable। --num-prompts হলো মোট পাঠানো request-এর সংখ্যা। স্থিতিশীল average পেতে এটিকে concurrency-এর প্রায় দশ গুণ রাখুন। summary-তে Output token throughput (tok/s): এবং Total token throughput (tok/s):, এরপর Time to First Token heading-এর অধীনে Mean TTFT (ms):, Median TTFT (ms): এবং P99 TTFT (ms): দেখানো হয়।

এই output-এ প্রতি stream-এর rate নেই। তবে এটি একবার ভাগ করলেই বের করা যায়। Mean TPOT (ms): হলো প্রথমটির পর প্রতিটি output token তৈরি করতে গড় সময়। তাই প্রতি token-এ 25 ms হলে প্রতি stream-এ প্রতি সেকেন্ডে 40 token তৈরি হয়। output throughput-কে concurrency দিয়ে ভাগ করলেও একই ফল পাওয়া যায়।

এরপর loop চালিয়ে প্রতিটি run সংরক্ষণ করুন।

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টি token তৈরি করে এবং p99 TTFT হয় 61 ms। 128 streams-এ মোট throughput বেড়ে প্রতি সেকেন্ডে 2304টি token হয়, যা পঁচিশ গুণ বেশি। একই সময়ে প্রতিটি stream-এর গতি কমে প্রতি সেকেন্ডে 18টি token হয় এবং p99 TTFT বেড়ে 3820 ms হয়। Batching নিষ্ক্রিয় memory wait-কে কার্যকর কাজে ব্যবহার করে বলে মোট throughput বাড়ে। একই compute এখন ভাগাভাগি করে ব্যবহার করতে হয় বলে প্রতিটি stream-এর গতি কমে।

শেষ দ্বিগুণ বৃদ্ধিই গুরুত্বপূর্ণ সংকেত দেয়। 64 থেকে 128 stream-এ গেলে মোট throughput ছয় শতাংশেরও কম বাড়ে, কিন্তু p99 TTFT প্রায় তিন গুণ হয়। এর অর্থ KV cache পূর্ণ এবং request-গুলো চলার বদলে queue-তে অপেক্ষা করছে। কার্যকর operating point আরও আগে: 32 stream-এ box এখনও প্রতি সেকেন্ডে 1728টি token ফেরত দেয়, যা peak-এর 75 শতাংশ। তখন প্রতি stream-এর গতি প্রতি সেকেন্ডে 54টি token এবং p99 TTFT 498 ms। এই point-টিকেই আপনার capacity হিসেবে report করুন। Curve-এর peak থেকে user-দের জন্য service দেওয়া যায় না।

Ollama এবং vLLM একই বিষয় পরিমাপ করে না

একটি ডিফল্ট Ollama server-এর বিরুদ্ধে ওই sweep চালালে মোট ফলাফল প্রায় বদলাবে না। OLLAMA_NUM_PARALLEL-এর ডিফল্ট মান 1। তাই এক সময়ে একটি request চলে এবং বাকি request-গুলো অপেক্ষা করে। এই queue-ই p99 TTFT বাড়ায়, কিন্তু মোট output অপরিবর্তিত থাকে। কোনো measurement নেওয়ার আগে এর মান বাড়ান।

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"

sudo systemctl restart ollama দিয়ে restart করুন। এরপর নিশ্চিত করুন যে model এখনও ফিট করছে। প্রতিটি parallel slot context window-এর নিজস্ব অংশ পায়। তাই Ollama-এর documentation অনুযায়ী, 4টি parallel request-এর জন্য 2K context 8K বরাদ্দ করে। slot count যথেষ্ট বাড়ালে model VRAM-এর বাইরে চলে যায়। ollama ps পরীক্ষা করুন। সেখানে PROCESSOR column-এ 48%/52% CPU/GPU-এর মতো কোনো মান থাকলে বুঝতে হবে model-এর একটি অংশ CPU-তে চলছে। তখন concurrency বাড়ালে throughput বাড়ার বদলে কমতে শুরু করবে। parallel slot-এর সীমা পার হলে request-গুলো OLLAMA_MAX_QUEUE পর্যন্ত queue হয়; ডিফল্ট মান 512। এরপর server 503 উত্তর দেয়।

vLLM continuous batching ব্যবহার করে। তাই কোনো slot খালি হলে চলমান batch-এ নতুন request যুক্ত করে। KV cache শেষ না হওয়া পর্যন্ত এর curve বাড়তে থাকে। Ollama একটি model, একটি machine এবং কম setup cost-এর জন্য optimize করা। তাই একই sweep-এ দুই engine ভিন্ন ফল দেয়। এটিই serving engine হিসেবে Ollama এবং vLLM-এর তুলনা-এর মূল বিষয়। প্রতিটি সংখ্যার ক্ষেত্রে কোন engine এবং কোন version ফলাফল তৈরি করেছে, তা record করুন।

ভুল জিনিস মাপার পাঁচটি উপায়

• ক্লায়েন্ট অনেক দূরে। Internet-এর মাধ্যমে আপনার laptop থেকে benchmark চালালে প্রতিটি TTFT-তে আপনার round trip time যোগ হয়। ফলে আপনি আসলে নিজের home connection মাপছেন। Server-এর একই region-এ client চালান।
• Model cold অবস্থায় ছিল। প্রথম request-এ model weight load করার সময় লাগে। vLLM-এ graph capture-এর সময়ও লাগতে পারে। একটি warmup batch পাঠিয়ে ফলাফলটি বাদ দিন।
• Prefix caching আপনার হয়ে উত্তর দিয়েছে। vLLM ডিফল্টভাবে automatic prefix caching চালু রাখে। তাই একই prompt বারবার পাঠালে prefill নয়, cache মাপা হয় এবং TTFT প্রকৃত মানের একটি ভগ্নাংশে নেমে যায়। --dataset-name random এই সমস্যা এড়ায়, কারণ প্রতিটি prompt আলাদা হয়। নিশ্চিত হতে server-টি --no-enable-prefix-caching দিয়ে চালু করুন।
• Output-গুলো ছোট ছিল। 32-token উত্তর হলে প্রতিটি 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 সমতুল্যটির মূল্য প্রতি million tokens-এ $0.65। তাই 4.47-কে 0.65 দিয়ে ভাগ করলে প্রতি ঘণ্টায় 6.88 million tokens পাওয়া যায়। 3,600 seconds দিয়ে ভাগ করলে প্রতি second-এ প্রায় 1,910 output tokens হয়। মূল্য তাদের। ভাগের হিসাব আমাদের।

এই সিদ্ধান্তে sustained শব্দটিই গুরুত্বপূর্ণ। Saturation অবস্থায় দিনে দুই ঘণ্টা 1,910 tokens per second পাওয়া sustained 1,910 tokens per second নয়, কারণ বাকি twenty-two ঘণ্টার জন্যও আপনাকে মূল্য দিতে হয়। DigitalOcean-এর নিজস্ব হিসাবে, কম দামের প্রতি ঘণ্টায় $3.44 GPU Droplet-এর crossover sustained average utilisation-এর 72.2 percent-এ হয়। এর নিচে per-token price বেশি সাশ্রয়ী। ধীর tokens নয়, idle GPU hours-ই সাধারণত self-hosting-এর খরচের ভারসাম্য নষ্ট করে।

তাই আপনার সিদ্ধান্তের দুটি input আছে। sweep আপনাকে ceiling জানায়। আপনার traffic pattern জানায়, সেই ceiling-এর কত fraction আপনি বাস্তবে ব্যবহার করেন। দুটিকে গুণ করুন। এরপর ফলাফলটি GPU VPS ও per-token API-এর break-even তুলনা-তে মিলিয়ে আপনার volume অনুযায়ী সিদ্ধান্তটি পড়ে নিন।

FAQ

self-hosted LLM-এর জন্য প্রতি সেকেন্ডে কত tokens ভালো?

এর দুটি উত্তর আছে, কারণ এই metric দুটি ভিন্ন কাজ করে। একজন ব্যক্তি output পড়লে, প্রতি stream-এ প্রতি সেকেন্ডে প্রায় 20 output tokens-এর বেশি হলেই তা পড়ার গতির চেয়ে দ্রুত; তাই এর বেশি গতি সাধারণত কাজে আসে না। খরচের ক্ষেত্রে গুরুত্বপূর্ণ সংখ্যা হলো saturated total output throughput। ভালো throughput বলতে break-even অতিক্রম করার মতো throughput বোঝায়। প্রতি million tokens-এর দাম $0.65 এবং server-এর দাম প্রতি ঘণ্টায় $4.47 হলে, July 2026-এর দামে এই সীমা sustained অবস্থায় প্রতি সেকেন্ডে প্রায় 1,910 output tokens। বড় model-এ একটি stream কখনো এই পর্যায়ে পৌঁছায় না। এ কারণেই batching ব্যবহার করা হয়।

concurrent request যোগ করলেও আমার Ollama throughput স্থির থাকে কেন?

OLLAMA_NUM_PARALLEL-এর default মান 1। তাই server প্রতিটি model-এর জন্য একবারে একটি request চালায় এবং বাকি request queue করে। OLLAMA_MAX_QUEUE-এ পৌঁছালে (default 512) server 503 ফেরত দেয়। p99 TTFT বাড়লেও মোট output স্থির থাকে। এটি busy GPU-এর নয়, queue-এর লক্ষণ। systemd drop-in-এ variable-টি সেট করে restart করুন। এরপর ollama ps পরীক্ষা করুন, কারণ প্রতিটি parallel slot বরাদ্দকৃত context-এর আকার বাড়ায় এবং model-এর একটি অংশ CPU-তে চলে যেতে পারে।

আমার কি time to first token নাকি tokens per second মাপা উচিত?

দুটিই মাপুন, কারণ load বাড়লে এগুলো বিপরীত দিকে পরিবর্তিত হয়। TTFT ব্যবহারকারী যে latency অনুভব করেন তা নির্দেশ করে। saturated output throughput আপনার invoice-এ প্রতিফলিত হয়। প্রতিটি concurrency ধাপে p50 এবং p99 TTFT record করুন। এরপর এমন সর্বোচ্চ concurrency বেছে নিন যেখানে p99 TTFT আপনার কাছে এখনও গ্রহণযোগ্য। সেই অবস্থার throughput-কে capacity হিসেবে report করুন। curve-এর সর্বোচ্চ প্রান্তের maximum throughput ব্যবহার করবেন না।

tokens per second-এর বেশি মান কি সবসময় প্রতি token-এর কম খরচ বোঝায়?

না। প্রতি token-এর খরচ হলো প্রতি ঘণ্টার দামকে ওই ঘণ্টায় server আসলে যত tokens তৈরি করেছে তা দিয়ে ভাগ করা। তাই দ্রুত server দিনের বেশির ভাগ সময় idle থাকলে প্রতি token-এর খরচ এখনও বেশি থাকবে। Peak speed নয়, utilisation খরচ নির্ধারণ করে। Unit-ও পরীক্ষা করুন। উল্লেখ করা total token throughput-এর মধ্যে input tokens থাকে। তাই input-to-output ratio 1:1 হলে, এটি আপনার billed output rate-এর প্রায় দ্বিগুণ।