Local LLM-এর tokens per second কীভাবে মাপবেন

GPU ব্যবহার করলে খরচ সাশ্রয় হবে কি না, তা tokens per second নির্ধারণ করে

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

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

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

DigitalOcean 2026 সালের July মাসে vLLM-এর অধীনে FP8 (8-bit floating point) মোডে একটি NVIDIA H200-এ llama3.3-70b-instruct চালানোর throughput figure প্রকাশ করেছে। এই figure-গুলো উপযোগী, কিন্তু এগুলো আপনার ফলাফল নয়।

[
  {
    "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 ওই পৃষ্ঠা থেকে নেওয়া, এবং তার মধ্যে দুটি সেখানে দেওয়া range-এর নিম্নসীমা। তাই ওই দুটিকে minimum হিসেবে পড়ুন। এই chart-এর কোনো সংখ্যাই আমরা মাপিনি।

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

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

Model পরিবর্তন করলে বা input-to-output ratio পরিবর্তন করলে উপরের প্রতিটি সংখ্যা বদলে যাবে। Published figure আপনার প্রত্যাশা নির্ধারণ করে, 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 bill পরিশোধে মূলত এই মানটিই প্রভাব ফেলে।
• concurrency-এর অধীনে p50 এবং p99 TTFT। p50 হলো মাঝামাঝি অনুরোধের মান। p99 হলো সেই মান, যার নিচে 100টির মধ্যে 99টি অনুরোধ সম্পন্ন হয়। 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 জানা থাকলে সেটিই ব্যবহার করুন।

Output length-ও নির্দিষ্ট করে দিন। কোনো model 60 token-এর পরে stop token পেলে run-টি ছোট হয় এবং full run-এর সঙ্গে তুলনা করা যায় না। এতে TTFT-এর অংশ তুলনামূলকভাবে বড় হয়। ফলে benchmark যেভাবে output throughput গণনা করে, তা কমে যায়, যদিও প্রতিটি request দ্রুত শেষ হয়। vLLM benchmark client-এর --ignore-eos flag ব্যবহার করলে প্রতিটি request ঠিক নির্ধারিত সংখ্যক token generate করে। এতে দুটি 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 ডিফল্টভাবে পাঁচ মিনিট নিষ্ক্রিয় থাকার পরে 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 করা অংশে installation এবং 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 তুলনা করার জন্য এটি যথেষ্ট নির্ভুল।

একটি stream-এর সংখ্যা server-কে দুবার বেশি সক্ষম বলে দেখায়। TTFT যত কম হওয়া সম্ভব, এখানে সেটিই দেখা যায়, কারণ আপনার আগে কোনো request 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 একসঙ্গে চলমান request-এর সংখ্যা সীমিত করে। এটিই আপনি sweep করবেন। --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 নেই। তবে একটি ভাগ করলেই তা পাওয়া যায়। প্রথম output token-এর পর প্রতি output token-এর গড় সময় হলো Mean TPOT (ms):। তাই প্রতি token-এ 25 ms হলে প্রতি stream-এ প্রতি সেকেন্ডে 40 token পাওয়া যায়। Output throughput-কে concurrency দিয়ে ভাগ করলেও একই ফল পাওয়া যায়।

এবার প্রতিটি run-এর output সংরক্ষণ করে 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টি row একটি ছোট ভাড়ায় নেওয়া যায় এমন GPU box-এ sweep চালালে যে ধরনের ফল পাওয়া যেতে পারে, তার একটি উদাহরণ। সংখ্যাগুলো সম্ভাব্য মাত্রার মধ্যে রাখা হয়েছে। এগুলো আপনার server-এর measurement নয় এবং কোনো vendor-এর প্রকাশিত figure-ও নয়। উপরের loop চালিয়ে ওই মানগুলোর জায়গায় আপনার মান বসান।

ফলাফলের আকৃতি দেখুন, কারণ এই আকৃতিটিই সাধারণভাবে প্রযোজ্য। একটি stream-এ পুরো box প্রতি সেকেন্ডে 92টি token তৈরি করে এবং p99 TTFT হয় 61 ms। 128 streams-এ মোট throughput বেড়ে প্রতি সেকেন্ডে 2304টি token হয়, যা 25 গুণ বেশি। তবে প্রতিটি আলাদা stream-এর গতি কমে প্রতি সেকেন্ডে 18টি token হয় এবং p99 TTFT বেড়ে 3820 ms হয়। Batching নিষ্ক্রিয় memory wait-কে কার্যকর কাজে রূপান্তর করে বলে মোট throughput বাড়ে। একই compute এখন ভাগ করে ব্যবহার করতে হয় বলে প্রতিটি stream-এর গতি কমে।

শেষবার দ্বিগুণ করার ফলটি গুরুত্বপূর্ণ। 64 থেকে 128 stream-এ গেলে মোট throughput 6 শতাংশেরও কম বাড়ে, কিন্তু p99 TTFT প্রায় 3 গুণ হয়। এর অর্থ request-গুলো processing না হয়ে queue-তে অপেক্ষা করছে। কারণ হতে পারে KV cache পূর্ণ হয়ে গেছে, অথবা server vLLM-এর max_num_seqs-এর মতো কোনো scheduling cap-এ পৌঁছেছে। কার্যকর operating point আরও আগের অবস্থানে: 32 stream-এ box এখনও প্রতি সেকেন্ডে 1728টি token ফেরত দেয়, যা peak-এর 75 শতাংশ। তখন প্রতি stream-এর গতি প্রতি সেকেন্ডে 54টি token এবং p99 TTFT 498 ms। এই point-টিকেই আপনার capacity হিসেবে report করুন। Curve-এর peak এমন একটি সংখ্যা, যার ভিত্তিতে users-কে নির্ভরযোগ্যভাবে service দেওয়া যায় না।

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

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

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"

sudo systemctl restart ollama দিয়ে restart করুন। এরপর নিশ্চিত করুন যে model এখনও মেমরিতে fit করছে। প্রতিটি 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 হয়। এর default মান 512। সীমা অতিক্রম করলে server 503 উত্তর দেয়।

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

ভুল বিষয় পরিমাপ করার পাঁচটি উপায়

• ক্লায়েন্ট অনেক দূরে। Internet-এর মাধ্যমে laptop থেকে benchmark চালালে প্রতিটি TTFT-তে আপনার round trip time যোগ হয়। ফলে আপনি মূলত নিজের home connection পরিমাপ করেন। server-এর একই region-এ client চালান।
• model cold অবস্থায় ছিল। প্রথম request-এ weight loading-এর সময় লাগে। vLLM-এ graph capture-এর সময়ও লাগতে পারে। একটি warmup batch পাঠিয়ে তার ফলাফল বাদ দিন।
• Prefix caching আপনার হয়ে উত্তর দিয়েছে। vLLM ডিফল্টভাবে automatic prefix caching সক্রিয় রাখে। তাই একই prompt বারবার পাঠালে prefill নয়, cache পরিমাপ হয় এবং TTFT প্রকৃত মানের একটি ভগ্নাংশে নেমে আসে। --dataset-name random এই সমস্যা এড়ায়, কারণ প্রতিটি prompt আলাদা। নিশ্চিত হতে server-টি --no-enable-prefix-caching দিয়ে start করুন।
• output-গুলো ছোট ছিল। 32-token উত্তর ব্যবহার করলে প্রতিটি request-এ TTFT-এর প্রভাব বেশি থাকে। তখন আপনার tokens per second আসলে prefill-এর বৈশিষ্ট্য প্রকাশ করে। বাস্তবসম্মত output length নিয়ে --ignore-eos ব্যবহার করুন।
• আপনি শুধু concurrency 1-এর ফলাফল দিয়েছেন। এতে তালিকায় সবচেয়ে অনুকূল TTFT পাওয়া যায়। আপনার প্রকৃত request কখনো একসঙ্গে না চললেই এটি cost হিসাবের উপযুক্ত input। request-গুলো একসঙ্গে চললে, আপনার traffic যে concurrency তৈরি করে সেখানে বজায় রাখা throughput-এর ওপর cost নির্ভর করে। তাই সেই concurrency-তেও পরিমাপ করুন।

পরিমাপ করা সংখ্যাকে সিদ্ধান্তে রূপ দিন

আপনার বাস্তব traffic যে concurrency-তে পৌঁছায়, sweep-এ সেই concurrency-তে পাওয়া output throughput নিন এবং per-token pricing-এর সঙ্গে তুলনা করুন। পর্যাপ্ত request overlap করে batch পূর্ণ রাখলেই কেবল এটি saturated figure। একবারে একটি request পাঠানো workload-এর ক্ষেত্রে single-stream rate ব্যবহার করতে হবে। প্রতিটি output token-এর সঙ্গে আসা input token-এর মূল্য ধরলে break-even বের করতে একটি ভাগই যথেষ্ট:

cost_per_million_output = price_out + price_in * (input_tokens / output_tokens)
break_even_tok_s = (price_per_hour / cost_per_million_output) * 1000000 / 3600

DigitalOcean-এর July 2026-এর মূল্য দিয়ে হিসাবটি করি। তাদের H200 dedicated inference endpoint-এর মূল্য ছিল প্রতি ঘণ্টায় $4.47। Serverless Llama 3.3 70B-এর input-এর মূল্য ছিল প্রতি million token-এ $0.65 এবং output-এর মূল্যও প্রতি million token-এ $0.65। উপরের 1:1 অনুপাতে প্রতি million output token-এর সঙ্গে এক million input token আসে। তাই কার্যকর মূল্য হয় প্রতি million output token-এ $1.30। সুতরাং 4.47-কে 1.30 দিয়ে ভাগ করলে প্রতি ঘণ্টায় প্রায় 3.44 million output token পাওয়া যায়। 3,600 সেকেন্ড দিয়ে ভাগ করলে প্রতি সেকেন্ডে প্রায় 955 output token, অথবা input ও output একসঙ্গে ধরলে প্রায় 1,910 token পাওয়া যায়। মূল্যগুলো তাদের। ভাগের হিসাবটি আমাদের। 25 October 2026-এ পরীক্ষা করার সময় H200 endpoint-এর মূল্য এখনও প্রতি ঘণ্টায় $4.47 ছিল। তবে DigitalOcean 18 August 2026-এ serverless Llama 3.3 70B deprecated করেছে এবং ব্যবহারকারীদের Llama 4 Maverick-এ নির্দেশ করছে। এর তালিকাভুক্ত মূল্য প্রতি million input token-এ $0.25 এবং প্রতি million output token-এ $0.87। এটি ভিন্ন model। তাই তুলনাটি অর্থপূর্ণ করতে এর জন্য আলাদা sweep দরকার।

এই সিদ্ধান্তে নির্ধারক শব্দ হলো sustained। Saturation-এ প্রতি সেকেন্ডে 955 output token দুই ঘণ্টা পাওয়া মানে sustained rate হিসেবে প্রতি সেকেন্ডে 955 output token নয়। কারণ বাকি বাইশ ঘণ্টার মূল্যও আপনাকে দিতে হবে। GPU Droplet হিসেবে card ভাড়া নিলেও সীমা কমে না। 25 October 2026-এ DigitalOcean-এর Droplet pricing-এ H200-এর on-demand মূল্য endpoint-এর সমান, প্রতি ঘণ্টায় $4.47 ছিল। তাদের সবচেয়ে সস্তা NVIDIA Droplet, RTX 4000 প্রতি ঘণ্টায় $0.76 এবং L40S বা RTX 6000 প্রতি ঘণ্টায় $1.57, FP8-এ 70B model ধারণ করার জন্য যথেষ্ট বড় নয়। তাই উপরের সংখ্যাগুলো অনুযায়ী, saturation-এ প্রতি সেকেন্ডে 2,036 output token দিতে সক্ষম H200-কে আপনি যে প্রতিটি ঘণ্টার জন্য মূল্য দেন, সেই প্রতিটি ঘণ্টায় peak-এর প্রায় 47 শতাংশ average করতে হবে। তাহলেই input ও output মিলিয়ে প্রতি million token-এ $0.65 মূল্যের সঙ্গে সমতা হবে। এর নিচে per-token মূল্য বেশি সুবিধাজনক। ধীর token নয়, idle GPU hour-ই সাধারণত self-hosting-এর অর্থনৈতিক হিসাব নষ্ট করে।

তাই আপনার সিদ্ধান্তে দুটি input আছে। Sweep আপনাকে ceiling দেয়। আপনার traffic pattern বলে সেই ceiling-এর কত অংশ বাস্তবে ব্যবহার করতে পারবেন। দুটিকে গুণ করুন। তারপর ফলাফলটি GPU VPS এবং per-token API break-even-এ প্রয়োগ করে আপনার volume অনুযায়ী উত্তরটি দেখুন।

FAQ

স্বয়ং-হোস্ট করা LLM-এর জন্য প্রতি সেকেন্ডে কত token ভালো বলে ধরা হয়?

এর দুটি উত্তর আছে, কারণ এই metric দুটি কাজ করে। একজন ব্যক্তি output পড়লে, প্রতি stream-এ প্রতি সেকেন্ডে প্রায় 20-এর বেশি output token পড়ার গতির চেয়ে দ্রুত। তাই এর বেশি গতি সাধারণত অতিরিক্ত সুবিধা দেয় না। Cost-এর ক্ষেত্রে আপনার প্রকৃত load-এ টেকসইভাবে বজায় রাখতে পারা মোট output throughput-ই গুরুত্বপূর্ণ। ভালো throughput বলতে এমন throughput বোঝায়, যা break-even অতিক্রম করে। প্রতি million token-এর দাম input ও output উভয়ের জন্য $0.65 এবং server-এর দাম প্রতি ঘণ্টায় $4.47 হলে, July 2026-এর দামে 1:1 ratio-তে এই সীমা টেকসই প্রায় 955 output token per second। বড় model-এ একটি stream কখনও এই সীমায় পৌঁছায় না। এ কারণেই batching ব্যবহার করা হয়।

একসঙ্গে একাধিক request যোগ করলেও আমার Ollama throughput অপরিবর্তিত থাকে কেন?

OLLAMA_NUM_PARALLEL-এর default মান 1। তাই server প্রতি model-এ একবারে একটি request চালায় এবং বাকি request queue-তে রাখে। OLLAMA_MAX_QUEUE-এর সীমা পর্যন্ত (default হিসেবে 512), এরপর 503 ফেরত দেয়। p99 TTFT বাড়লেও মোট output অপরিবর্তিত থাকে। এটি ব্যস্ত 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 আপনার কাছে এখনও গ্রহণযোগ্য। সেই point-এর throughput-কে capacity হিসেবে report করুন। Curve-এর সর্বোচ্চ point থেকে পাওয়া throughput ব্যবহার করবেন না।

প্রতি সেকেন্ডে বেশি token মানেই কি প্রতি token-এর cost কম?

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