GPU VPS विरुद्ध API tokens: खर्च-समानता कधी होते?

खर्च-समानता बिंदू प्रत्यक्षात कुठे येतो

GPU VPS वरील खर्च आणि प्रति-token API billing यांची तुलना एका विशिष्ट बिंदूवर समान होते: त्या महिन्यात तुम्ही प्रत्यक्षात तयार केलेल्या output tokens ने निश्चित मासिक भाडे भागल्यावर प्रति token येणारा खर्च, त्याच tokens साठी API आकारत असलेल्या दरापेक्षा कमी होतो तेव्हा. भाडे बदलत नाही. प्रत्येक request नुसार API bill बदलतो. त्यामुळे उत्तर नेहमी मासिक volume असते; साधे होय किंवा नाही नसते.

$0.50 प्रति तास दराच्या mid-range GPU VPS वर ही गणना करा. 730 तासांच्या महिन्यासाठी हा खर्च $365 होतो. Frontier model API च्या तुलनेत 24.3 million output tokens प्रति महिना वापरल्यानंतर खर्च-समानता होते. Small commercial model च्या तुलनेत हा आकडा 73 million आहे. समान आकाराच्या hosted open-weight model च्या तुलनेत खर्च-समानता कधीच होत नाही, कारण crossing point पर्यंत पोहोचण्यासाठी एका card कडून महिन्यात पुरेसे tokens तयार होत नाहीत.

प्रकाशित break-even अभ्यास या प्रश्नाचे उत्तर देत नाहीत. 2026 च्या सुरुवातीला प्रकाशित झालेल्या त्यांपैकी दोन अभ्यासांनुसार H200 वर crossover सुमारे 72% sustained utilisation येथे, तर MI300X वर 22% ते 48% duty cycle दरम्यान येतो. दोन्ही अभ्यास त्याच vendor च्या serverless product शी तुलना करतात. तसेच, दोन्ही अभ्यासांमध्ये अशा accelerators चे दर वापरले आहेत ज्यांचा प्रति तास खर्च येथे बहुतेक वाचक एका महिन्यात खर्च करतात त्यापेक्षा जास्त आहे. गणित मात्र तेच आहे. पुढील गणना एका card साठी, 7B ते 30B range मधील एका open model साठी आणि सामान्य metered API billing साठी पुन्हा केली आहे.

खालील प्रत्येक संख्या input आहे, result नाही. त्या सर्व आपल्या आकड्यांनी बदला.

तुमचे स्वतःचे आकडे त्यात बसवण्यासाठीचे सूत्र

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

चार इनपुट आहेत. हे चारही आकडे तुम्ही मोजू किंवा शोधू शकता.

• hourly_rate म्हणजे GPU VPS ची प्रति तास किंमत. GPU निष्क्रिय असताना लागणारे तासही यात धरले आहेत. तुम्ही मासिक शुल्क भरत असल्यास, मासिक किंमत 730 ने भागा.
• tokens_per_second म्हणजे तुमच्या प्रत्यक्ष concurrency अंतर्गत सर्व्हरचा स्थिर aggregate output rate. Vendor chart मधील single-stream आकडा येथे वापरू नका.
• duty_cycle म्हणजे GPU tokens generate करण्यासाठी वापरल्या जाणाऱ्या महिन्याच्या कालावधीचा अंश. तुम्ही संपूर्ण महिना भाड्याने घेतलेला server दररोज दोन तास वापरत असल्यास, हा आकडा 8.3% असेल.
• api_price_per_million म्हणजे output tokens साठी ज्या metered price शी तुम्ही तुलना करत आहात ती किंमत.

या उदाहरणात दोन्ही बाजूंना output tokens ची किंमत धरली आहे, कारण chat आणि agent कामामध्ये बिलाचा मुख्य भाग output मुळे येतो. तुमचे prompts मोठे असल्यास, input दोन्ही बाजूंना जोडा. API च्या बाजूला invoice वर त्यासाठी स्वतंत्र ओळ असते. तुमच्या स्वतःच्या card वर prefill साठी GPU time लागतो. त्यामुळे ते आधीच कमी मोजलेल्या tokens_per_second मध्ये दिसते.

विश्वास ठेवण्यापूर्वी tokens per second कसे मोजावे

वरील सर्व गणना एका मोजलेल्या संख्येवर आधारित आहेत. ती संख्या तीनपट चुकीची असल्यास उत्तरही तीनपट चुकीचे असेल. तुम्ही भाड्याने घेतलेल्या card वर, प्रत्यक्षात चालवणार असलेल्या model आणि quantisation सह ती संख्या मोजा.

Ollama मध्ये single-stream आकडा एका command ने मिळतो:

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

--verbose उत्तरानंतर timing block दाखवते. महत्त्वाची ओळ eval rate आहे. ती tokens per second मध्ये असते आणि फक्त generation मोजते. prompt eval rate हा prefill speed आहे आणि तो सामान्यतः खूप जास्त असतो. तुमचे आकडे खालील आकड्यांपेक्षा वेगळे असतील:

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

Cost model साठी single stream हा चुकीचा आकडा आहे. तो एकावेळी एक request मोजतो, पण card एकाच वेळी अनेक request हाताळू शकतो. Aggregate आकड्यासाठी model vLLM द्वारे serve करा आणि server स्वतःबद्दल दाखवत असलेला throughput वाचा:

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

Requests in flight असताना server प्रत्येक reporting interval ला status line log करतो. vLLM releases नुसार अचूक fields बदलतात. त्यामुळे माझे fields न वापरता तुमचे fields वाचा:

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 आहे. Concurrent requests वाढवत गेल्यावर हा आकडा वाढतो, जोपर्यंत KV cache (key-value cache; vLLM प्रत्येक request साठी VRAM मध्ये ठेवत असलेली attention state) पूर्ण होत नाही. त्यानंतर तो वाढत नाही. त्यापुढे load वाढवल्यास requests अधिक वेगाने पूर्ण होण्याऐवजी queue मध्ये थांबतात. हे वाढणाऱ्या Waiting count मध्ये दिसते. vLLM सोबत vllm bench serve हा load generator देखील येतो. त्याचे flags version नुसार बदलतात. त्यामुळे blog post मधील command कॉपी करण्याऐवजी तुम्ही install केलेल्या version वर vllm bench serve --help चालवा.

Test चालू असताना card चे निरीक्षण करा:

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

Generation दरम्यान utilization.gpu जवळपास 100% राहिल्यास तुम्ही throughput-bound आहात आणि मोजलेला आकडा ही वास्तविक कमाल मर्यादा आहे. तो कमी राहिल्यास मर्यादा इतरत्र आहे: concurrent requests फार कमी असणे, client धीमा असणे किंवा model VRAM मध्ये पूर्णपणे न मावल्यामुळे त्याचा काही भाग system RAM मध्ये offload होणे. Ollama आणि vLLM येथे खूप वेगवेगळे trade-offs देतात, आणि त्याच card वर त्यांच्यातील फरक इतका मोठा असू शकतो की break-even अनेक पटींनी बदलतो.

महिनाभरातील बिलाचे स्वरूप

या उदाहरणात $0.50 प्रति तास दराने एक 24 GB GPU VPS वापरला आहे. त्यावर vLLM द्वारे 8B open model दिले जाते. 16 समांतर विनंत्यांसह एकत्रित output दर 400 tokens प्रति सेकंद मोजला आहे. तुम्ही card वापरला किंवा नाही तरी भाडे निश्चितच राहते. या दराने महिन्याला 1,051 million output tokens इतकी क्षमता मिळते. card कधीही थांबत नसेल तर तेवढे output तयार होतात.

[
  {
    "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 सर्वाधिक कार्यरत असलेल्या याच output प्रमाणावर तो पर्याय जवळपास दुप्पट महाग पडतो.

शेवटचा निष्कर्ष अनेकांना आश्चर्यकारक वाटतो. मात्र तो योगायोग नाही. hosted open-weight endpoint म्हणजे उच्च utilisation वर चालवलेली GPU fleet आहे. त्यामुळे तिची किंमत पूर्ण क्षमतेने वापरल्या जाणाऱ्या card च्या खर्चाच्या जवळ असते. एक card भाड्याने घेऊन तो पूर्ण क्षमतेपेक्षा कमी वापरत असताना saturated fleet पेक्षा कमी खर्च साध्य करता येत नाही. मात्र frontier pricing पेक्षा कमी खर्च साध्य करता येतो. frontier pricing हे silicon time पेक्षा model capability वर ठरते.

प्रत्येक duty cycle वर प्रति दशलक्ष output tokens खर्च

Volume आणि duty cycle ही एकच बाब दोन दृष्टिकोनांतून पाहिलेली आहे. भाडे भरल्यावर तासांची क्षमता मिळते. निष्क्रिय तासांत कोणतेही 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 साठी प्रति दशलक्ष 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 सतत पूर्ण क्षमतेने चालवल्यास प्रति दशलक्ष output tokens खर्च 0.35 dollars येतो. हा खर्च खरोखर कमी आहे. 10% duty cycle वर त्याच दशलक्ष tokens चा खर्च 3.47 dollars येतो. 2% duty cycle वर हा खर्च 17.36 dollars होतो. समान output साठी hosted open model आकारत असलेल्या 0.20 dollars शी हा खर्च समान श्रेणीत येत नाही.

साधारणपणे 10% duty cycle पेक्षा कमी वापर असल्यास GPU भाड्याने घेणे हा महाग पर्याय ठरतो. तुम्ही प्रति दशलक्ष tokens output साठी 3.47 dollars देत आहात, तर त्याच output ची hosted open model किंमत 0.20 dollars आहे. या फरकाच्या बदल्यात तुम्हाला privacy आणि बदलत नसलेले bill मिळते. या दोन्हींचे प्रत्यक्ष आर्थिक मूल्य असू शकते. मात्र हा price win नाही. त्यामुळे त्याची नोंद 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 दशलक्ष output tokens आवश्यक आहेत. हे card च्या क्षमतेच्या केवळ 2.3% इतके आहे. ही मर्यादा कमी आहे. working day मध्ये coding agents चालवणारी छोटी team ती सहज गाठू शकते.

small commercial tier च्या तुलनेत तुम्हाला दरमहा 73 दशलक्ष tokens, म्हणजे 6.9% duty cycle आवश्यक आहे. hosted open-weight tier च्या तुलनेत आवश्यक duty cycle 174% आहे. 100% पेक्षा जास्त मूल्य व्याख्येनुसार साध्य होऊ शकत नाही. त्या card ला महिन्यात उपलब्ध असलेल्या तासांपेक्षा जास्त तास चालावे लागेल. या hourly rate वर एक mid-range card ही तुलना जिंकू शकत नाही. त्यामुळे निकाल बदलण्याचे एकमेव मार्ग म्हणजे स्वस्त card, अधिक वेगवान card किंवा किंमतीशी संबंधित नसलेले कारण.

सूत्र काय लपवते

हे सूत्र GPU तास आणि tokens यांची किंमत मोजते. मात्र अनेक वास्तविक खर्च त्याच्या बाहेर राहतात.

Cold starts. 16-bit weights असलेले 8B model सुमारे 16 GB असते. ते local disk मधून VRAM मध्ये load होण्यासाठी काही दहा सेकंद लागतात. भाडे वाचवण्यासाठी वापरांदरम्यान box बंद केला, तर प्रत्येक वेळी पहिल्या request वेळी हा विलंब सहन करावा लागतो. हा विलंब टाळण्यासाठी box सुरू ठेवला, तर तुमचा duty cycle मोठ्या प्रमाणात कमी होतो आणि प्रति token खर्च वाढतो. Serverless inference असण्यामागचे हेच संपूर्ण कारण आहे.

Storage and download. Weights मोठे असतात. 16-bit मधील 8B model सुमारे 16 GB असते, 4-bit मध्ये quantise केलेले 30B model सुमारे 18 GB असते, आणि 16-bit मधील 30B model 24 GB card वर मुळीच बसत नाही. उच्च क्षमतेच्या model मध्ये ही मर्यादा लवकर स्पष्ट होते. उदाहरणार्थ, Kimi K3 सारखे trillion-parameter open model चालवणे म्हणजे weights चीच मात्रा तुम्ही तासाच्या हिशोबाने भाड्याने घेऊ शकता अशा कोणत्याही single card पेक्षा जास्त होते. त्या disk साठी दर महिन्याला पैसे द्यावे लागतात आणि प्रत्येक rebuild वेळी वेळही खर्च होतो. आठवडाभर प्रयोग केल्यानंतर du -sh ~/.cache/huggingface/hub चालवा. ते तुमच्या अपेक्षेपेक्षा वेगाने वाढते, कारण तुम्ही एकदा वापरून पाहिलेली प्रत्येक quantisation अजूनही तिथेच साठवलेली असते.

तुमचा स्वतःचा वेळ. Driver आणि CUDA versions, कालपर्यंत चाललेल्या context length वर येणाऱ्या out-of-memory errors, तसेच chat template बदलणारे model update—यापैकी काहीही प्रति-token खर्चाच्या आकड्यात दिसत नाही. मात्र या सर्वांचा खर्च तुमच्या मोकळ्या वेळेतून होतो. तुम्ही यापूर्वी अशा box चे sizing केले नसेल, तर महिनाभर भाड्याने घेण्याचा निर्णय करण्यापूर्वी GPU VPS प्रत्यक्षात काय देते हे वाचणे उपयुक्त ठरेल.

गुणवत्तेतील तफावत. हा सर्वात मोठा लपलेला खर्च आहे आणि त्याची किंमत ठरवणे सर्वात कठीण आहे. 8B open model हे frontier model नसते. Frontier model ला एक प्रयत्न पुरत असताना त्याला तीन प्रयत्न लागले, तर उपयुक्त उत्तरामागील त्याची वास्तविक किंमत chart मधील मूल्याच्या तिप्पट होते. त्यातूनही task अयशस्वी होऊ शकते. किंमत पाहण्यापूर्वी तुमच्या स्वतःच्या prompts वर गुणवत्तेची तुलना करा. Agent workloads साठी नेहमीचा उपाय म्हणजे अडचणीनुसार routing करणे आणि मोठ्या प्रमाणातील कामासाठी स्वस्त local tokens वापरणे. VPS वरील agent खर्च नियंत्रित करणे याचा मुख्य भाग हाच आहे.

तुम्ही विसरलेले billing. तुम्ही थांबवलेले hourly GPU instance त्याच्याशी जोडलेल्या storage आणि reserved IP address साठी billing सुरू ठेवू शकते. Price page नव्हे, तर invoice तपासा.

किंमतीव्यतिरिक्त इतर बाबतीत self-hosting कधी फायदेशीर ठरते

गणित हा निर्णायक घटक नसतो अशी चार उदाहरणे.

• तुमच्या नियंत्रणाबाहेर जाऊ नये असा डेटा. एखादा compliance नियम मजकूर third party कडे पाठवण्यास मनाई करत असेल, तर tokenमागील किंमत हा विचारला जाणारा प्रश्नच नसतो.
• ठरावीक वेळापत्रकावर सातत्याने मोठ्या प्रमाणात काम. दररोज रात्री सहा तास चालणारे batch classification काम रचनेनुसार 25% duty cycle वर चालते आणि त्यासाठी अनपेक्षित बिल येत नाही.
• Rate limits. तुमच्या स्वतःच्या card साठी एकच queue असते आणि ती तुमची असते.
• कोणत्याही API वर उपलब्ध नसलेले model. एखादे विशिष्ट fine-tune आवश्यक असल्यास, तुलना करण्यासाठी दुसरा पर्यायच नसतो.

तुम्हाला आधी स्वस्त पर्याय तपासायचा असल्यास, Ollama वापरून VPS वर छोटे model चालवणे यासाठी एका दुपारइतकाच वेळ लागतो. तसेच तुम्ही भाड्याने घेणार असलेल्या card नुसार open model चे sizing करणे यामुळे तुम्हाला प्रत्यक्षात कोणता GPU आवश्यक आहे हे समजते. एका महिन्याचे GPU rent घेण्यापूर्वी तिथेच मोजमाप करा.

FAQ

कोणत्या मासिक token volume वर GPU VPS ची किंमत API पेक्षा कमी पडते?

GPU ची मासिक किंमत प्रति million output tokens API किंमतीने भागा. दरमहा $365 भाड्याने मिळणारे card, प्रति million output tokens 15.00 dollars असलेल्या frontier API च्या तुलनेत, दरमहा 24.3 million output tokens वर समसमान खर्च गाठते. 5.00 dollars किंमत असलेल्या small commercial model च्या तुलनेत हा आकडा 73 million आहे. 0.20 dollars किंमत असलेल्या hosted open-weight model च्या तुलनेत एक mid-range card दरमहा समसमान खर्च गाठण्यासाठी पुरेसे tokens निर्माण करू शकत नाही.

Hosted open-weight API ची किंमत माझ्या स्वतःच्या GPU पेक्षा कमी का असते?

कारण त्याची किंमत पूर्णपणे वापरल्या जाणाऱ्या GPU च्या खर्चाच्या जवळ ठरवली जाते, पण तुमचे card पूर्ण क्षमतेने वापरले जात नाही. हजारो concurrent requests हाताळणारा provider आपल्या fleet ला saturation जवळ ठेवतो. त्यामुळे तो tokens निर्मितीच्या marginal cost जवळ विकू शकतो. तुमचे card दिवसातील बहुतांश वेळ idle असते आणि त्या idle तासांचेही पैसे तुम्ही देता. 10% duty cycle वर तुमचा खर्च प्रति million output tokens 3.47 dollars असतो, तर त्यांची किंमत 0.20 dollars असते.

Input tokens आणि output tokens दोन्ही मोजावेत का?

तुमचे prompts मोठे असतील, तर तेही मोजा. येथे केलेल्या तुलनेत फक्त output tokens वापरले आहेत, कारण chat आणि agent कामासाठी तो प्रमुख घटक आहे. Input जोडल्यास दोन्ही बाजूंवर परिणाम होतो. API च्या बाजूला तो invoice वरील स्वतंत्र आणि कमी किमतीचा घटक असतो. तुमच्या स्वतःच्या card वर prefill साठी GPU time लागतो. त्यामुळे तुम्ही मोजलेल्या एकूण tokens per second मध्ये त्याचा खर्च आधीच समाविष्ट असतो. तुमच्या प्रत्यक्ष prompt lengths वापरून मोजमाप करा. त्यामुळे दोन्ही बाजूंची तुलना सुसंगत राहते.

Formula साठी आवश्यक tokens per second कसे मोजायचे?

Model ज्या पद्धतीने वापरणार आहात त्याच पद्धतीने serve करा. त्यानंतर प्रत्यक्ष concurrency अंतर्गत aggregate generation rate वाचा. Ollama मध्ये, ollama run <model> --verbose tokens per second मधील eval rate print करते. मात्र हा single stream असतो. त्यामुळे batched server च्या क्षमतेपेक्षा कमी दर दिसतो. vLLM मध्ये requests in flight असताना running server logs Avg generation throughput नोंदवतो. वापरायचा आकडा हा आहे. त्याच वेळी nvidia-smi वर लक्ष ठेवा. Generation दरम्यान GPU utilisation 100% च्या जवळ नसेल, तर तुम्हाला अद्याप कमाल क्षमता सापडलेली नाही.

10% utilisation पेक्षा कमी वापरासाठी GPU VPS भाड्याने घेणे फायदेशीर आहे का?

किंमतीच्या दृष्टीने नाही. 10% duty cycle वर प्रति million output tokens तुमचा खर्च 3.47 dollars असतो. 2% वर तो 17.36 dollars असतो. या तुलनेतील frontier tier वगळता प्रत्येक metered API पेक्षा हे दोन्ही खर्च जास्त आहेत. Privacy किंवा कोणताही API देत नसलेला model यासाठीच तुम्ही पैसे देत असाल, तरच त्या मर्यादेपेक्षा कमी वापरावर भाड्याने घ्या.