GPU VPS بمقابلہ API tokens: break-even کب ہوتا ہے؟

اصل break-even کہاں بنتا ہے

GPU VPS کسی مرحلے پر per-token API billing سے زیادہ کفایتی ہو جاتا ہے: جب ماہانہ fixed rent کو اس مہینے میں حقیقتاً generate کیے گئے output tokens سے تقسیم کرنے پر حاصل ہونے والی لاگت، انہی tokens کے لیے API کی وصول کردہ قیمت سے کم ہو۔ rent تبدیل نہیں ہوتا۔ API bill ہر request کے ساتھ تبدیل ہوتا ہے۔ اس لیے جواب ہمیشہ ماہانہ volume ہوتا ہے، سادہ ہاں یا نہیں نہیں۔

اسے $0.50 فی گھنٹہ والے mid-range GPU VPS پر لاگو کریں، جو 730-hour ماہ کے لیے $365 بنتا ہے۔ frontier model API کے مقابلے میں break-even 24.3 million output tokens ماہانہ پر ہوتا ہے۔ small commercial model کے مقابلے میں یہ 73 million پر ہوتا ہے۔ اسی size کے hosted open-weight model کے مقابلے میں آپ کبھی break-even نہیں ہوتے، کیونکہ ایک card crossing point تک پہنچنے کے لیے ایک ماہ میں کافی tokens generate نہیں کر سکتا۔

شائع شدہ break-even studies اس سوال کا جواب نہیں دیتیں۔ 2026 کے آغاز میں شائع ہونے والی ان میں سے دو studies نے H200 پر crossover تقریباً 72% sustained utilisation اور MI300X پر 22% سے 48% duty cycle کے درمیان رکھا۔ دونوں studies کا موازنہ اسی vendor کی اپنی serverless product کے ساتھ ہے، اور دونوں ایسے accelerators کی قیمتیں استعمال کرتی ہیں جن کا فی گھنٹہ خرچ یہاں کے اکثر readers کے ماہانہ خرچ سے زیادہ ہے۔ حساب ایک ہی ہے۔ ذیل کا حساب ایک card، 7B سے 30B range کے ایک open model، اور عام metered API billing کے لیے دوبارہ کیا گیا ہے۔

ذیل کا ہر number ایک input ہے، result نہیں۔ ان سب کو اپنی values سے replace کریں۔

فارمولا، تاکہ آپ اپنے اعداد شامل کر سکیں

cost_per_million = (hourly_rate * 1000000) / (tokens_per_second * 3600 * duty_cycle)

breakeven_millions_per_month = (hourly_rate * hours_per_month) / api_price_per_million

capacity_millions_per_month = (tokens_per_second * 3600 * hours_per_month) / 1000000

required_duty_cycle = breakeven_millions_per_month / capacity_millions_per_month

چار inputs درکار ہیں، اور آپ چاروں کی پیمائش یا تلاش کر سکتے ہیں۔

• hourly_rate وہ لاگت ہے جو GPU VPS فی گھنٹہ لیتا ہے، اس وقت کو بھی شامل کرتے ہوئے جب وہ idle رہتا ہے۔ اگر آپ ماہانہ ادائیگی کرتے ہیں تو ماہانہ قیمت کو 730 سے تقسیم کریں۔
• tokens_per_second وہ مجموعی output rate ہے جسے آپ کا server حقیقی concurrency کے تحت برقرار رکھتا ہے۔ یہ vendor chart میں دیا گیا single-stream number نہیں ہے۔
• duty_cycle مہینے کے اس حصے کو ظاہر کرتا ہے جس میں GPU tokens generate کرنے میں مصروف رہتا ہے۔ جس box کو آپ پورے مہینے rent کرتے ہیں لیکن روزانہ دو گھنٹے استعمال کرتے ہیں، اس کی شرح 8.3% ہے۔
• api_price_per_million وہ metered price ہے جس سے آپ output tokens کے لیے موازنہ کر رہے ہیں۔

مثال میں دونوں جانب output tokens کی قیمت شامل ہے، کیونکہ chat اور agent work میں bill کا بڑا حصہ output پر مشتمل ہوتا ہے۔ اگر آپ کے prompts طویل ہیں تو دونوں جانب input بھی شامل کریں۔ API کی جانب یہ invoice میں الگ line ہوتی ہے۔ اپنے card پر prefill GPU time استعمال کرتا ہے، اس لیے یہ پہلے ہی کم ناپے گئے tokens_per_second میں ظاہر ہوتا ہے۔

حساب پر بھروسا کرنے سے پہلے tokens per second کی پیمائش کیسے کریں

اوپر کی تمام calculation ایک measured number پر مبنی ہے۔ اگر یہ number تین گنا غلط ہو تو answer بھی تین گنا غلط ہوگا۔ اسے اسی card پر measure کریں جسے آپ rent کر رہے ہیں، اور اسی model اور quantisation کے ساتھ جسے آپ حقیقت میں run کریں گے۔

Ollama ایک command میں single-stream figure دیتا ہے:

ollama run qwen3:8b --verbose "Write 400 words about disk latency."

--verbose جواب کے بعد timing block print کرتا ہے۔ اہم line eval rate ہے، جو tokens per second میں ہوتی ہے اور صرف generation کو count کرتی ہے۔ prompt eval rate prefill speed ہے، جو عموماً اس سے کہیں زیادہ ہوتی ہے۔ آپ کے numbers ان numbers سے مختلف ہوں گے:

eval count:       412 token(s)
eval duration:    9.612s
eval rate:        42.86 tokens/s

Cost model کے لیے single stream درست number نہیں ہے، کیونکہ یہ ایک ایسے card پر ایک وقت میں صرف ایک request measure کرتا ہے جو بیک وقت کئی requests serve کر سکتا ہے۔ Aggregate figure کے لیے model کو vLLM کے ذریعے serve کریں اور وہ throughput پڑھیں جسے server اپنے بارے میں report کرتا ہے:

pip install vllm
vllm serve Qwen/Qwen3-8B --max-model-len 8192

جب requests in flight ہوں تو server ہر reporting interval پر status line log کرتا ہے۔ Exact fields vLLM releases کے درمیان بدل سکتے ہیں، اس لیے میری output کے بجائے اپنی output پڑھیں:

Avg prompt throughput: 812.4 tokens/s, Avg generation throughput: 396.1 tokens/s, Running: 16 reqs, Waiting: 0 reqs, GPU KV cache usage: 21.7%

Avg generation throughput وہ number ہے جسے formula استعمال کرتا ہے۔ Concurrent requests بڑھانے سے یہ اس وقت تک بڑھتا ہے جب تک KV cache (key-value cache، یعنی ہر request کے لیے vLLM کی VRAM میں رکھی ہوئی attention state) بھر نہ جائے۔ اس کے بعد یہ بڑھنا بند ہو جاتا ہے۔ اس حد سے آگے جانے پر requests تیز ہونے کے بجائے queue میں شامل ہوتی ہیں، جس کا نتیجہ بڑھتا ہوا Waiting count ہوتا ہے۔ vLLM ایک load generator بھی ship کرتا ہے، vllm bench serve۔ اس کے flags versions کے درمیان بدل سکتے ہیں، اس لیے کسی blog post سے command copy کرنے کے بجائے اپنے installed version پر vllm bench serve --help run کریں۔

Test کے دوران card کو monitor کریں:

nvidia-smi --query-gpu=utilization.gpu,memory.used,power.draw --format=csv -l 5

اگر generation کے دوران utilization.gpu تقریباً 100% رہے تو آپ throughput-bound ہیں، اور measured number حقیقی ceiling ہے۔ اگر یہ کم رہے تو limit کہیں اور ہے: concurrent requests بہت کم ہیں، client سست ہے، یا model VRAM میں fit نہیں ہوتا اور جزوی طور پر system RAM پر offload ہو رہا ہے۔ Ollama اور vLLM یہاں بہت مختلف trade-offs پیش کرتے ہیں، اور اسی card پر ان دونوں کے درمیان فرق اتنا زیادہ ہو سکتا ہے کہ break-even کئی گنا بدل جائے۔

ایک ماہ کے دوران بل کی صورت

اس عملی مثال میں 24 GB GPU VPS شامل ہے، جس کا کرایہ فی گھنٹہ $0.50 ہے۔ اس پر vLLM کے ذریعے 8B open model فراہم کیا جاتا ہے۔ 16 بیک وقت درخواستوں کے ساتھ مجموعی رفتار 400 output tokens فی سیکنڈ ناپی گئی ہے۔ آپ GPU استعمال کریں یا نہ کریں، کرایہ مقرر رہتا ہے۔ اس رفتار پر گنجائش ماہانہ 1,051 million output tokens ہے۔ اگر GPU کبھی بند نہ ہو تو card اتنے ہی tokens تیار کرتا ہے۔

[
  {
    "output_tokens_millions": 5,
    "gpu_vps_usd": 365,
    "open_api_usd": 1,
    "small_api_usd": 25,
    "frontier_api_usd": 75
  },
  {
    "output_tokens_millions": 10,
    "gpu_vps_usd": 365,
    "open_api_usd": 2,
    "small_api_usd": 50,
    "frontier_api_usd": 150
  },
  {
    "output_tokens_millions": 25,
    "gpu_vps_usd": 365,
    "open_api_usd": 5,
    "small_api_usd": 125,
    "frontier_api_usd": 375
  },
  {
    "output_tokens_millions": 50,
    "gpu_vps_usd": 365,
    "open_api_usd": 10,
    "small_api_usd": 250,
    "frontier_api_usd": 750
  },
  {
    "output_tokens_millions": 100,
    "gpu_vps_usd": 365,
    "open_api_usd": 20,
    "small_api_usd": 500,
    "frontier_api_usd": 1500
  },
  {
    "output_tokens_millions": 250,
    "gpu_vps_usd": 365,
    "open_api_usd": 50,
    "small_api_usd": 1250,
    "frontier_api_usd": 3750
  },
  {
    "output_tokens_millions": 500,
    "gpu_vps_usd": 365,
    "open_api_usd": 100,
    "small_api_usd": 2500,
    "frontier_api_usd": 7500
  },
  {
    "output_tokens_millions": 1000,
    "gpu_vps_usd": 365,
    "open_api_usd": 200,
    "small_api_usd": 5000,
    "frontier_api_usd": 15000
  }
]

GPU کی لاگت 365 dollars پر مستقل رہتی ہے، کیونکہ کرایہ اس بات سے متاثر نہیں ہوتا کہ آپ card کے ساتھ کیا کر رہے ہیں۔ ہر API لاگت صفر سے شروع ہونے والی سیدھی لکیر ہے۔ ہر جوڑا صرف ایک بار ایک دوسرے کو کاٹتا ہے۔

ماہانہ 25 million output tokens پر frontier API کا بل 375 dollars ہے، اس لیے دونوں لاگتوں میں دس dollars سے کم فرق رہ جاتا ہے۔ 50 million tokens پر small commercial model کا بل 250 dollars ہے اور یہ اب بھی سستا اختیار ہے۔ 1000 million output tokens پر، جس کے لیے card کو ماہ کے 95% وقت مصروف رہنا ہوگا، hosted open-weight API کا بل 200 dollars ہے، جبکہ card کا کرایہ اتنا ہی رہتا ہے۔ عین اس مقدار پر، جب card سب سے زیادہ کام کر رہا ہوتا ہے، card کی لاگت تقریباً دو گنا زیادہ ہو جاتی ہے۔

یہ آخری نتیجہ لوگوں کو حیران کرتا ہے، لیکن یہ اتفاق نہیں ہے۔ hosted open-weight endpoint دراصل high utilisation پر چلنے والا GPU fleet ہے، اس لیے اس کی قیمت saturated card کی لاگت کے قریب رہتی ہے۔ ایک card کرائے پر لے کر اسے مکمل load سے کم پر چلانے سے آپ saturated fleet سے کم لاگت حاصل نہیں کر سکتے۔ آپ frontier pricing کو ضرور پیچھے چھوڑ سکتے ہیں، کیونکہ وہ silicon time کے بجائے capability کی بنیاد پر مقرر ہوتی ہے۔

ہر duty cycle پر 1 ملین output tokens کی لاگت

Volume اور duty cycle ایک ہی حقیقت کو دو زاویوں سے ظاہر کرتے ہیں۔ کرایہ گھنٹے خریدتا ہے۔ Idle گھنٹے کوئی output پیدا نہیں کرتے، لیکن پھر بھی ان کی لاگت آتی ہے۔

[
  {
    "label": "100% duty",
    "self_host_usd_per_million": "0.35",
    "open_api_usd_per_million": "0.20",
    "small_api_usd_per_million": "5.00",
    "frontier_api_usd_per_million": "15.00"
  },
  {
    "label": "50% duty",
    "self_host_usd_per_million": "0.69",
    "open_api_usd_per_million": "0.20",
    "small_api_usd_per_million": "5.00",
    "frontier_api_usd_per_million": "15.00"
  },
  {
    "label": "25% duty",
    "self_host_usd_per_million": "1.39",
    "open_api_usd_per_million": "0.20",
    "small_api_usd_per_million": "5.00",
    "frontier_api_usd_per_million": "15.00"
  },
  {
    "label": "10% duty",
    "self_host_usd_per_million": "3.47",
    "open_api_usd_per_million": "0.20",
    "small_api_usd_per_million": "5.00",
    "frontier_api_usd_per_million": "15.00"
  },
  {
    "label": "5% duty",
    "self_host_usd_per_million": "6.94",
    "open_api_usd_per_million": "0.20",
    "small_api_usd_per_million": "5.00",
    "frontier_api_usd_per_million": "15.00"
  },
  {
    "label": "2% duty",
    "self_host_usd_per_million": "17.36",
    "open_api_usd_per_million": "0.20",
    "small_api_usd_per_million": "5.00",
    "frontier_api_usd_per_million": "15.00"
  }
]

تین API کالم، August 2026 تک شائع شدہ عام list prices ہیں: hosted 8B open-weight model کے لیے 1 ملین output tokens پر 0.20 dollars، small commercial model کے لیے 5.00 dollars، اور frontier model کے لیے 15.00 dollars۔ یہ اعداد صرف مثال کے لیے ہیں۔ کوئی فیصلہ کرنے سے پہلے آج کا price page دیکھیں۔ اگر آپ کا موازنہ metered tokens کے بجائے flat monthly plan سے ہے تو subscription کا حساب مختلف طریقے سے کام کرتا ہے اور crossing point دوبارہ بدل جاتا ہے۔

Card کو مکمل capacity پر چلائیں تو 1 ملین output tokens کی لاگت 0.35 dollars آتی ہے، جو واقعی کم ہے۔ 10% duty cycle پر اسی 1 ملین کی لاگت 3.47 dollars آتی ہے۔ 2% duty cycle پر لاگت 17.36 dollars ہو جاتی ہے، جو hosted open model کے اسی output کے لیے وصول کیے جانے والے 0.20 dollars کے برابر range میں نہیں ہے۔

تقریباً 10% duty cycle سے کم پر GPU کرائے پر لینا مہنگا انتخاب ہے۔ آپ 1 ملین tokens کے output کے لیے 3.47 dollars ادا کر رہے ہیں، جبکہ یہی output 0.20 dollars میں دستیاب ہے۔ اس فرق کے بدلے آپ privacy اور ایسی bill لاگت خرید رہے ہیں جو تبدیل نہیں ہوتی۔ ان دونوں کی حقیقی مالی قدر ہو سکتی ہے۔ لیکن یہ price advantage نہیں ہے، اس لیے اسے price win نہ سمجھیں۔

ہر API tier کے لیے break-even volume

[
  {
    "label": "Hosted open 8B API",
    "breakeven_tokens_millions": 1825,
    "required_duty_pct": 174
  },
  {
    "label": "Small commercial model",
    "breakeven_tokens_millions": 73,
    "required_duty_pct": 6.9
  },
  {
    "label": "Frontier model",
    "breakeven_tokens_millions": 24.3,
    "required_duty_pct": 2.3
  }
]

frontier tier کے مقابلے میں آپ کو ماہانہ 24.3 million output tokens درکار ہیں، جو card کی صلاحیت کا صرف 2.3% ہے۔ یہ ایک کم حد ہے۔ working day کے دوران coding agents چلانے والی ایک چھوٹی team اسے باآسانی پورا کر سکتی ہے۔

small commercial tier کے مقابلے میں آپ کو ماہانہ 73 million tokens، یا 6.9% duty cycle درکار ہے۔ hosted open-weight tier کے مقابلے میں مطلوبہ duty cycle 174% ہے۔ 100% سے زیادہ کوئی بھی قدر اصولاً ناقابل حصول ہے، کیونکہ card کو مہینے میں موجود گھنٹوں سے زیادہ وقت چلانا پڑے گا۔ اس hourly rate پر ایک mid-range card اس تقابل میں کامیاب نہیں ہو سکتا۔ لہٰذا نتیجہ بدلنے کے صرف یہ طریقے ہیں: زیادہ سستا card، زیادہ تیز card، یا قیمت کے علاوہ کوئی اور وجہ۔

فارمولے میں چھپے اخراجات

یہ فارمولا GPU hours اور tokens کی قیمت کا حساب لگاتا ہے۔ کئی حقیقی اخراجات اس میں شامل نہیں ہوتے۔

Cold starts۔ 16-bit weights والا 8B model تقریباً 16 GB کا ہوتا ہے، اور اسے local disk سے VRAM میں load ہونے میں دسیوں seconds لگتے ہیں۔ کرایہ بچانے کے لیے استعمال کے درمیان box بند کر دیں تو ہر بار پہلی request پر یہی انتظار کرنا پڑتا ہے۔ انتظار سے بچنے کے لیے اسے چلتا رہنے دیں تو duty cycle بہت کم ہو جاتی ہے، جس سے ہر token کی لاگت بڑھ جاتی ہے۔ یہی trade-off serverless inference کے وجود کی بنیادی وجہ ہے۔

Storage اور download۔ Weights بڑی ہوتی ہیں۔ 16-bit کا 8B model تقریباً 16 GB، 4-bit میں quantised 30B model تقریباً 18 GB، اور 16-bit کا 30B model 24 GB card پر بالکل fit نہیں ہوتا۔ بڑے models میں یہ حد تیزی سے نمایاں ہو جاتی ہے۔ مثلاً ایک trillion-parameter open model جیسے Kimi K3 کو چلانے کے لیے صرف weights ہی اس واحد card سے زیادہ جگہ لیتی ہیں جسے آپ فی گھنٹہ rent پر لے سکتے ہیں۔ اس disk کی ماہانہ قیمت آپ ادا کرتے ہیں، اور ہر rebuild میں اس کے لیے وقت بھی صرف ہوتا ہے۔ ایک ہفتے کے experiments کے بعد du -sh ~/.cache/huggingface/hub چلائیں۔ یہ آپ کی توقع سے زیادہ تیزی سے بڑھتا ہے، کیونکہ ہر وہ quantisation جسے آپ نے ایک بار آزمایا تھا، اب بھی وہاں موجود ہوتی ہے۔

آپ کا اپنا وقت۔ Driver اور CUDA versions، اس context length پر out-of-memory errors جو کل کام کر رہی تھی، اور model update جس سے chat template بدل جائے۔ ان میں سے کوئی چیز cost-per-token figure میں ظاہر نہیں ہوتی، لیکن ان سب کی قیمت آپ کی شاموں سے وصول ہوتی ہے۔ اگر آپ نے پہلے ان میں سے کوئی box size نہیں کیا تو commit کرنے سے پہلے یہ پڑھنا مفید ہے کہ GPU VPS دراصل کیا فراہم کرتا ہے۔

Quality gap۔ یہ سب سے بڑا hidden cost اور اس کی قیمت کا اندازہ لگانا سب سے مشکل ہے۔ 8B open model frontier model نہیں ہوتا۔ اگر اسے وہ کام کرنے کے لیے تین attempts درکار ہوں جس کے لیے frontier model کو ایک attempt کافی ہو، تو مفید answer کی حقیقی قیمت chart value سے تین گنا ہو جاتی ہے، اور ممکن ہے کہ یہ task مکمل ہی نہ کر سکے۔ Price کا موازنہ کرنے سے پہلے اپنے prompts پر quality کا موازنہ کریں۔ Agent workloads کے لیے عام حل یہ ہے کہ difficulty کے مطابق routing کی جائے اور bulk work کے لیے سستے local tokens رکھے جائیں۔ عموماً VPS پر agent spend کو control کرنا اسی کے بارے میں ہوتا ہے۔

وہ billing جسے آپ بھول گئے۔ جس hourly GPU instance کو آپ نے stop کر دیا ہو، اس کی attached storage اور reserved IP address کی billing اکثر جاری رہتی ہے۔ Price page نہیں، invoice پڑھیں۔

قیمت کے علاوہ حالات میں self-hosting کب بہتر ہوتا ہے

چار صورتیں جن میں حساب کتاب فیصلہ کن عامل نہیں ہوتا۔

• ایسا data جو آپ کے control سے باہر نہیں جا سکتا۔ اگر compliance rule کسی third party کو text بھیجنے سے منع کرتا ہے تو فی token price وہ سوال ہی نہیں جس کا جواب درکار ہے۔
• مقررہ schedule پر مسلسل زیادہ volume۔ ایسا batch classification job جو ہر رات چھ گھنٹے چلتا ہے، بنیادی طور پر 25% duty cycle پر رہتا ہے، اور bill کے ذریعے کبھی اچانک حیران نہیں کرتا۔
• Rate limits۔ آپ کے اپنے card کی ایک queue ہوتی ہے، اور وہ آپ کی ملکیت ہوتی ہے۔
• ایسا model جو کوئی API فراہم نہیں کرتی۔ اگر آپ کو specific fine-tune درکار ہے تو موازنہ کرنے کے لیے کوئی متبادل موجود نہیں۔

اگر آپ پہلے کم لاگت والا version آزمانا چاہتے ہیں تو Ollama کے ساتھ VPS پر ایک چھوٹا model چلانے میں ایک دوپہر لگتی ہے، اور جس card کو آپ rent کریں گے اس کے مطابق open model کی sizing سے معلوم ہوتا ہے کہ آپ کو حقیقت میں کون سا GPU درکار ہے۔ GPU rent کے ایک ماہ کے لیے sign up کرنے سے پہلے وہیں measurement کریں۔

FAQ

ماہانہ کتنے token volume پر GPU VPS کی قیمت API pricing سے کم ہو جاتی ہے؟

GPU کی ماہانہ لاگت کو فی million output tokens API price سے تقسیم کریں۔ اگر card کا ماہانہ کرایہ $365 ہو اور frontier API کی قیمت 15.00 dollars فی million ہو، تو break-even 24.3 million output tokens فی ماہ پر ہوگا۔ کسی چھوٹے commercial model کی 5.00 dollars فی million قیمت کے مقابلے میں یہ مقدار 73 million ہوگی۔ hosted open-weight model کی 0.20 dollars فی million قیمت کے مقابلے میں ایک mid-range card کسی بھی صورت میں ماہانہ اتنے tokens generate نہیں کر سکتی کہ break-even ہو سکے۔

hosted open-weight API میرے اپنے GPU سے کم قیمت کیوں ہے؟

کیونکہ اس کی قیمت fully loaded GPU کی لاگت کے قریب مقرر کی جاتی ہے، جبکہ آپ کا card fully loaded نہیں ہوتا۔ ہزاروں concurrent requests فراہم کرنے والا provider اپنے fleet کو saturation کے قریب رکھتا ہے، اس لیے وہ tokens کو انہیں generate کرنے کی marginal cost کے قریب فروخت کر سکتا ہے۔ آپ کا card دن کے بیشتر حصے میں idle رہتا ہے، لیکن idle hours کی ادائیگی بھی آپ کرتے ہیں۔ 10% duty cycle پر آپ کی لاگت 3.47 dollars فی million output tokens ہے، جبکہ ان کی لاگت 0.20 dollars ہے۔

کیا مجھے input tokens کو بھی output tokens کے ساتھ شمار کرنا چاہیے؟

اگر آپ کے prompts طویل ہیں تو انہیں بھی شمار کریں۔ یہاں کا comparison صرف output tokens استعمال کرتا ہے، کیونکہ chat اور agent work میں یہی dominant term ہے۔ input شامل کرنے سے دونوں sides تبدیل ہو جاتی ہیں۔ API side پر یہ invoice میں الگ اور کم قیمت والی line ہوتی ہے۔ اپنے card پر prefill GPU time استعمال کرتا ہے، اس لیے اس کی لاگت آپ کے ناپے ہوئے aggregate tokens per second میں پہلے ہی شامل ہوتی ہے۔ اپنی حقیقی prompt lengths کے ساتھ measure کریں، تاکہ دونوں sides comparable رہیں۔

formula کے لیے درکار tokens per second کیسے measure کروں؟

Model کو اسی طرح serve کریں جس طرح آپ اسے استعمال کریں گے، پھر حقیقی concurrency کے تحت aggregate generation rate پڑھیں۔ Ollama کے ساتھ، ollama run <model> --verbose tokens per second میں eval rate print کرتا ہے، لیکن یہ single stream ہے اور batched server کی rate کو کم ظاہر کرتا ہے۔ vLLM کے ساتھ، requests in flight ہونے کے دوران running server logs میں Avg generation throughput لکھتا ہے، اور یہی وہ figure ہے جسے استعمال کرنا چاہیے۔ اسی وقت nvidia-smi کو بھی monitor کریں۔ اگر generation کے دوران GPU utilisation 100% کے قریب نہیں ہے، تو آپ نے ابھی maximum ceiling حاصل نہیں کی۔

کیا 10% utilisation سے کم پر GPU VPS کرائے پر لینا فائدہ مند ہے؟

قیمت کے لحاظ سے نہیں۔ 10% duty cycle پر آپ 3.47 dollars فی million output tokens ادا کرتے ہیں، جبکہ 2% پر آپ 17.36 dollars ادا کرتے ہیں۔ اس comparison میں دونوں rates ہر metered API سے زیادہ ہیں، سوائے frontier tier کے۔ اس حد سے کم utilisation پر صرف اس وقت rent کریں جب privacy یا ایسا model حاصل کرنا مقصد ہو جو کوئی API فراہم نہیں کرتی۔