متى يصبح GPU VPS أرخص من رموز API؟
اكتشف معادلة نقطة التعادل وعدد الرموز الشهري الذي يجعل استئجار GPU بسعر 0.50 دولار للساعة أوفر من فوترة API لكل رمز.
موضع نقطة التعادل فعلياً
يتفوق استئجار GPU VPS على الفوترة حسب عدد الرموز عبر API عند نقطة واحدة: عندما يصبح الإيجار الشهري الثابت، مقسوماً على رموز الإخراج التي تولدها فعلياً خلال ذلك الشهر، أقل من السعر الذي تفرضه API على الرموز نفسها. لا يتغير الإيجار. وتتغير فاتورة API مع كل طلب. لذلك تكون الإجابة دائماً حجم استخدام شهرياً، وليست نعم أو لا مجردتين.
طبّق الحساب على GPU VPS متوسط الإمكانات بسعر $0.50 في الساعة، أي $365 لشهر يتكون من 730 ساعة. مقارنةً بـAPI لنموذج متقدم، تصل إلى نقطة التعادل عند 24.3 مليون رمز إخراج شهرياً. أما مقارنةً بنموذج تجاري صغير، فتصل إليها عند 73 مليوناً. وبالمقارنة مع نموذج مستضاف ذي أوزان مفتوحة بالحجم نفسه، فلن تصل إلى نقطة التعادل أبداً، لأن بطاقة واحدة لا تستطيع توليد عدد كافٍ من الرموز خلال شهر للوصول إلى نقطة التقاطع.
لا تجيب دراسات نقطة التعادل المنشورة عن هذا السؤال. يقدّر تحليل لأحد المورّدين من July 2026 نقطة التقاطع عند استخدام بنسبة 50% تقريباً لبطاقة H100 مخصصة بسعر $2.00 في الساعة، مقارنةً بالاستدلال عديم الخوادم. وتقارن دراسات من هذا النوع بطاقة مخصصة في مركز بيانات بمنتج عديم الخوادم، كما تسعّر المسرّعات بعدة أضعاف السعر المستخدم هنا لكل ساعة. الحساب الرياضي نفسه. لكن التحليل التالي يعيد إجراءه لبطاقة واحدة، ونموذج مفتوح واحد يتراوح حجمه بين 7B و30B، وفوترة API العادية حسب الاستخدام.
كل رقم أدناه مدخل وليس نتيجة. استبدلها جميعاً ببياناتك الخاصة.
الصيغة، بحيث يمكنك استبدال الأرقام بأرقامك
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هي تكلفة VPS الذي يحتوي على GPU لكل ساعة، بما في ذلك الساعات التي يبقى فيها خاملاً. إذا كنت تدفع شهرياً، فاقسم السعر الشهري على 730.tokens_per_secondهو معدل الإخراج الإجمالي الذي يحافظ عليه خادمك عند مستوى التزامن الفعلي لديك. لا تستخدم الرقم الخاص بتدفق واحد الوارد في مخطط المورّد.duty_cycleهو نسبة الشهر التي يقضيها GPU في توليد الرموز. إذا استأجرت خادماً طوال الشهر واستخدمته ساعتين يومياً، فستبلغ النسبة 8.3%.api_price_per_millionهو السعر المحسوب الذي تقارنه، بالنسبة إلى رموز الإخراج.
يسعّر المثال رموز الإخراج على كلا الجانبين، لأن الإخراج يشكّل الجزء الأكبر من الفاتورة في محادثات الدردشة وعمل الوكلاء. إذا كانت المطالبات طويلة، فأضف الإدخال إلى كلا الجانبين. في جانب API، يظهر ذلك كسطر منفصل في الفاتورة. أما على خادمك الخاص، فيستهلك prefill وقت GPU، ولذلك يظهر بالفعل كمعدل tokens_per_second مقاس أقل.
كيفية قياس عدد الرموز في الثانية قبل الوثوق بالحسابات
يعتمد كل ما سبق على رقم واحد مقاس. إذا أخطأت فيه بمعامل ثلاثة، فستكون الإجابة خاطئة بالمعامل نفسه. قِس هذا الرقم على البطاقة التي تستأجرها، باستخدام النموذج وquantisation اللذين ستشغّلهما فعلياً.
يعرض Ollama رقم التدفق لخيط واحد بأمر واحد:
ollama run qwen3:8b --verbose "Write 400 words about disk latency."يطبع --verbose كتلة توقيت بعد الإجابة. السطر المهم هو eval rate، بوحدة الرموز في الثانية، وهو يحسب التوليد فقط. أما prompt eval rate فهو سرعة prefill، وتكون عادةً أعلى بكثير. ستختلف أرقامك عن الأرقام التالية:
eval count: 412 token(s)
eval duration: 9.612s
eval rate: 42.86 tokens/sلا يصلح التدفق لخيط واحد لبناء نموذج تكلفة، لأنه يقيس طلباً واحداً في كل مرة على بطاقة يمكنها خدمة عدة طلبات بالتزامن. للحصول على الرقم الإجمالي، شغّل النموذج باستخدام vLLM واقرأ معدل التدفق الذي يعرضه الخادم عن نفسه:
pip install vllm
vllm serve Qwen/Qwen3-8B --max-model-len 8192أثناء وجود الطلبات قيد التنفيذ، يسجّل الخادم سطراً للحالة في كل فترة إبلاغ. تتغير الحقول الفعلية بين إصدارات vLLM، لذلك اقرأ السطر لديك بدلاً من نسخ سطري:
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 هو الرقم الذي تحتاج إليه الصيغة. يرتفع هذا الرقم كلما أضفت طلبات متزامنة، إلى أن تمتلئ KV cache (ذاكرة التخزين المؤقت للمفاتيح والقيم، وهي حالة attention الخاصة بكل طلب التي يحتفظ بها vLLM في VRAM)، ثم يتوقف عن الارتفاع. إذا تجاوزت ذلك، ستنتظر الطلبات في طابور بدلاً من أن تنفذ بسرعة أكبر، وسترى ذلك في ارتفاع عدد Waiting. يوفّر vLLM أيضاً مولّد تحميل هو vllm bench serve. تتغير خياراته بين الإصدارات، لذلك شغّل vllm bench serve --help على الإصدار الذي ثبّتَّه، بدلاً من نسخ أمر من منشور في مدونة.
راقب البطاقة أثناء تشغيل الاختبار:
nvidia-smi --query-gpu=utilization.gpu,memory.used,power.draw --format=csv -l 5إذا بقي utilization.gpu قريباً من 100% أثناء التوليد، فأنت مقيّد بمعدل التدفق، والرقم الذي قسته هو الحد الفعلي. إذا بقي منخفضاً، فهناك عامل آخر يفرض الحد: عدد قليل جداً من الطلبات المتزامنة، أو عميل بطيء، أو نموذج لا يتسع في VRAM ويجري تفريغ جزء منه إلى RAM النظام. يُجري Ollama وvLLM مقايضات مختلفة جداً هنا، والفارق بينهما على البطاقة نفسها كبير بما يكفي لتغيير نقطة التعادل بعدة أضعاف.
كيف تبدو الفاتورة خلال شهر
المثال التطبيقي هو VPS مزوّد بوحدة GPU بسعة 24 GB، بسعر $0.50 للساعة، ويشغّل نموذجاً مفتوحاً بحجم 8B عبر vLLM، مع معدل مقاس يبلغ 400 رمز خرج في الثانية إجمالاً، و16 طلباً متزامناً. تبقى تكلفة الاستئجار ثابتة سواء استخدمت البطاقة أم لا. وتبلغ السعة بهذا المعدل 1,051 مليون رمز خرج شهرياً، وهي الكمية التي تنتجها البطاقة إذا لم تتوقف مطلقاً.
البيانات وراء هذا الرسم البياني
[
{
"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 دولاراً، لأن تكلفة الاستئجار لا تتأثر بما تفعله بالبطاقة. وكل بند من بنود API خط مستقيم يبدأ من الصفر. ويتقاطع كل زوج منها مرة واحدة بالضبط.
عند 25 مليون رمز خرج شهرياً، تبلغ فاتورة API الرائد 375 دولاراً، لذلك لا يتجاوز الفرق بين الخيارين عشرة دولارات. وعند 50 مليوناً، يكلّف نموذج الأعمال الصغير 250 دولاراً، ويظل الخيار الأرخص. وعند 1000 مليون رمز خرج، وهي كمية تتطلب تشغيل البطاقة عند 95% من الشهر، تبلغ فاتورة API للنموذج المفتوح المستضاف 200 دولاراً، مقابل تكلفة الاستئجار نفسها. وتخسر البطاقة بفارق يقارب الضعف عند الحجم الذي تعمل فيه بأقصى جهد.
تُفاجئ هذه النتيجة الأخيرة بعض الناس، لكنها ليست مصادفة. نقطة النهاية المستضافة للنموذج المفتوح هي أسطول من وحدات GPU يعمل بنسبة استخدام مرتفعة، لذلك يقترب سعرها من تكلفة بطاقة مشبعة. لا يمكنك التفوق على أسطول مشبع باستئجار بطاقة واحدة وتشغيلها بأقل من حملها الكامل. ما يمكنك التفوق عليه هو تسعير النماذج الرائدة، الذي تحدده القدرات لا زمن تشغيل العتاد.
التكلفة لكل مليون رمز ناتج عند كل معدل إشغال
الحجم ومعدل الإشغال هما الحقيقة نفسها من زاويتين. تدفع تكلفة الاستئجار مقابل الساعات. الساعات الخاملة لا تنتج شيئاً، لكنها تظل تكلف مالاً.
البيانات وراء هذا الرسم البياني
[
{
"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: 0.20 دولار لكل مليون رمز ناتج لنموذج مفتوح الأوزان مستضاف بحجم 8B، و5.00 دولار لنموذج تجاري صغير، و15.00 دولار لنموذج متقدم. هذه الأرقام توضيحية. تحقّق من صفحة الأسعار الحالية قبل اتخاذ أي قرار. وإذا كانت المقارنة مع خطة شهرية ثابتة بدلاً من الرموز المحاسبة حسب الاستخدام، فإن حسابات الاشتراك تعمل بطريقة مختلفة، وتتغير نقطة التعادل مرة أخرى.
شغّل البطاقة بأقصى طاقتها، وستبلغ تكلفة مليون رمز ناتج 0.35 دولار، وهي تكلفة منخفضة فعلاً. عند معدل إشغال 10%، تبلغ تكلفة المليون نفسه 3.47 دولاراً. وعند معدل إشغال 2%، تبلغ التكلفة 17.36 دولاراً، وهي ليست ضمن النطاق نفسه الذي يبلغه سعر 0.20 دولاراً الذي يفرضه نموذج مفتوح مستضاف مقابل الناتج نفسه.
مقارنةً بنموذج مفتوح الأوزان مستضاف، يكون استئجار GPU هو الخيار الأعلى تكلفة عند كل معدل إشغال في المخطط. عند معدل 10%، تدفع 3.47 دولاراً لكل مليون رمز مقابل ناتج يُباع بسعر 0.20 دولاراً. وما تحصل عليه مقابل فرق السعر هو الخصوصية وفاتورة لا تتغير. قد تكون لهذين العاملين قيمة مالية حقيقية. لكنهما لا يمثلان ميزة سعرية، فلا تسجلهما على أنهما كذلك. أما مقارنةً بالطبقات التجارية، فتنقلب الصورة: عند معدل إشغال 10%، تكون تكلفة البطاقة أقل من سعري النموذج التجاري الصغير والنموذج المتقدم، وتظل أقل تكلفة من الطبقة المتقدمة حتى ينخفض معدل الإشغال إلى نحو 2.3%.
حجم نقطة التعادل لكل فئة من واجهات API
البيانات وراء هذا الرسم البياني
[
{
"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
}
]مقابل فئة النماذج الرائدة، تحتاج إلى 24.3 مليون رمز خرج شهرياً، وهذا لا يمثل سوى 2.3% مما تستطيع البطاقة معالجته. هذا حد منخفض. ويمكن لفريق صغير يشغّل وكلاء البرمجة طوال يوم العمل تجاوزه.
مقابل الفئة التجارية الصغيرة، تحتاج إلى 73 مليون رمز شهرياً، أو دورة تشغيل بنسبة 6.9%. أما مقابل فئة النماذج مفتوحة الأوزان المستضافة، فتبلغ دورة التشغيل المطلوبة 174%. أي قيمة تتجاوز 100% غير ممكنة بحكم التعريف، لأن البطاقة ستحتاج إلى العمل لساعات أكثر من عدد ساعات الشهر. لا يمكن لبطاقة واحدة متوسطة الفئة، بهذا المعدل الساعي، أن تتفوق في هذه المقارنة. لذلك، لا تتغير النتيجة إلا ببطاقة أرخص، أو بطاقة أسرع، أو سبب لا يتعلق بالسعر.
ما تخفيه المعادلة
تسعّر المعادلة ساعات GPU والرموز. لكن عدة تكاليف فعلية تقع خارجها.
بدء التشغيل البارد. يحتاج نموذج 8B بأوزان 16-bit إلى نحو 16 GB، ويستغرق تحميله من القرص المحلي إلى VRAM عشرات الثواني. إذا أوقفت الخادم بين الاستخدامات لتوفير التكلفة، فسوف تدفع ثمن هذا الانتظار مع كل طلب أول. وإذا أبقيته قيد التشغيل لتجنب الانتظار، فسوف تنخفض نسبة التشغيل الفعلية، ما يرفع التكلفة لكل رمز. هذه المفاضلة هي السبب الكامل لوجود الاستدلال serverless.
التخزين والتنزيل. أحجام الأوزان كبيرة. يبلغ حجم نموذج 8B بدقة 16-bit نحو 16 GB، ويبلغ حجم نموذج 30B بعد تكميمه إلى 4-bit نحو 18 GB، بينما لا يتسع نموذج 30B بدقة 16-bit على بطاقة بسعة 24 GB أصلاً. يصبح الحد الأقصى صارماً سريعاً في الطرف الأعلى، حيث يعني تشغيل نموذج مفتوح من فئة تريليون معلمة مثل Kimi K3 أن الأوزان وحدها تتجاوز سعة أي بطاقة واحدة يمكنك استئجارها بالساعة. ستدفع تكلفة هذا القرص كل شهر، وستدفع وقتاً مع كل عملية إعادة بناء. شغّل du -sh ~/.cache/huggingface/hub بعد أسبوع من التجارب. سيزداد حجمه أسرع مما تتوقع، لأن كل تكميم جرّبته مرة واحدة سيظل موجوداً.
وقتك أنت. إصدارات برنامج التشغيل وCUDA، وأخطاء نفاد الذاكرة عند طول سياق كان يعمل بالأمس، وتحديث نموذج يغيّر قالب المحادثة. لا يظهر أي من ذلك في رقم التكلفة لكل رمز، لكنك تدفع ثمنه من أمسياتك. إذا لم يسبق لك تحديد حجم أحد هذه الخوادم، فاقرأ ما الذي يقدمه GPU VPS فعلياً قبل الالتزام بتكلفة شهر كامل.
فجوة الجودة. هذه أكبر تكلفة خفية وأصعبها تقديراً. النموذج المفتوح 8B ليس نموذجاً متقدماً. إذا احتاج إلى 3 محاولات بينما يحتاج النموذج المتقدم إلى محاولة واحدة، فإن سعره الفعلي لكل إجابة مفيدة يساوي 3 أضعاف قيمة المخطط، وقد يفشل في المهمة على أي حال. قارن النتائج باستخدام مطالباتك أنت قبل المقارنة على أساس السعر. في أعباء عمل الوكلاء، يكون الحل المعتاد هو التوجيه وفق مستوى الصعوبة، مع إبقاء الرموز المحلية الرخيصة للمهام الكبيرة، وهذا هو معظم ما يتناوله التحكم في إنفاق الوكلاء على VPS.
رسوم نسيتها. يواصل مثيل GPU المحسوب بالساعة إصدار الفواتير غالباً مقابل التخزين المرفق وعنوان IP المحجوز حتى بعد إيقافه. راجع الفاتورة، لا صفحة الأسعار.
متى تكون الاستضافة الذاتية الخيار الأفضل لسبب غير السعر
أربع حالات لا تكون فيها الحسابات العامل الحاسم.
- بيانات لا يمكن أن تخرج من نطاق تحكمك. إذا كانت قاعدة امتثال تمنع إرسال النص إلى طرف ثالث، فإن السعر لكل token ليس السؤال المطروح.
- حجم مرتفع ومستقر وفق جدول زمني. تعمل مهمة تصنيف دفعية ست ساعات كل ليلة بمعدل تشغيل يبلغ 25% بحكم تصميمها، ولا تفاجئك أبداً بفاتورة.
- حدود معدل الطلبات. تملك بطاقتك الخاصة queue واحدة، وهي لك.
- نموذج لا يقدمه أي API. إذا كنت تحتاج إلى fine-tune محدد، فلا يوجد خيار تقارنه به.
إذا أردت اختبار الإصدار الرخيص أولاً، فإن تشغيل نموذج صغير على VPS باستخدام Ollama يستغرق فترة بعد الظهر، كما يوضح لك تحديد حجم نموذج مفتوح وفق البطاقة التي كنت ستستأجرها وحدة GPU التي تحتاج إليها فعلياً. أجرِ القياس هناك قبل الاشتراك في استئجار GPU لمدة شهر.
FAQ
عند أي حجم شهري من الرموز يتفوق VPS مزود بوحدة GPU على تسعير API؟
اقسم التكلفة الشهرية لوحدة GPU على سعر API لكل مليون رمز ناتج. بطاقة تُستأجر مقابل $365 شهرياً، مقارنةً بـ API رائد بسعر 15.00 دولار لكل مليون، تصل إلى نقطة التعادل عند 24.3 مليون رمز ناتج شهرياً. وبمقارنتها بنموذج تجاري صغير بسعر 5.00 دولار، تكون نقطة التعادل عند 73 مليون رمز. أما مقارنةً بنموذج مستضاف ذي أوزان مفتوحة بسعر 0.20 دولار، فلا تستطيع بطاقة واحدة متوسطة المدى توليد عدد كافٍ من الرموز خلال شهر للوصول إلى نقطة التعادل إطلاقاً.
لماذا تقل تكلفة API المستضاف ذي الأوزان المفتوحة عن تكلفة وحدة GPU الخاصة بي؟
لأن سعره محدد قريباً من تكلفة وحدة GPU عند تشغيلها بكامل طاقتها، بينما لا تعمل بطاقتك بكامل طاقتها. يقدّم المزوّد الخدمة لآلاف الطلبات المتزامنة ويحافظ على أسطوله قريباً من التشبع، لذلك يستطيع بيع الرموز بسعر قريب من التكلفة الحدّية لإنتاجها. تكون بطاقتك في وضع الخمول معظم اليوم، لكنك تدفع مقابل ساعات الخمول. عند دورة تشغيل بنسبة 10%، تبلغ تكلفتك 3.47 دولار لكل مليون رمز ناتج، مقارنةً بـ 0.20 دولار لديهم.
هل ينبغي أن أحتسب رموز الإدخال إلى جانب رموز الإخراج؟
احتسبها إذا كانت مطالباتك طويلة. تستخدم المقارنة هنا رموز الإخراج فقط، لأنها العامل الأكبر في المحادثات وعمل الوكلاء. تؤثر إضافة رموز الإدخال في كلا الجانبين. في جانب API، تظهر كعنصر منفصل منخفض السعر في الفاتورة. أما في بطاقتك الخاصة، فتستهلك عملية prefill وقتاً من وحدة GPU، ولذلك تكون التكلفة محسوبة أصلاً ضمن إجمالي عدد الرموز في الثانية الذي قسته. أجرِ القياس باستخدام أطوال المطالبات الفعلية، وعندها تبقى المقارنة بين الجانبين متكافئة.
كيف أقيس عدد الرموز في الثانية الذي تحتاج إليه الصيغة؟
شغّل النموذج بالطريقة التي ستستخدمه بها، ثم اقرأ معدل التوليد الإجمالي عند وجود تزامن فعلي. باستخدام Ollama، تطبع ollama run <model> --verbose قيمة eval rate بالرموز في الثانية، لكن ذلك يمثل تدفقاً واحداً ويقلل من تقدير أداء خادم يعالج دفعات. باستخدام vLLM، يسجل الخادم قيد التشغيل Avg generation throughput أثناء وجود الطلبات قيد التنفيذ، وهذه هي القيمة التي ينبغي استخدامها. راقب nvidia-smi في الوقت نفسه. إذا لم يكن استخدام وحدة GPU قريباً من 100% أثناء التوليد، فلم تصل بعد إلى الحد الأقصى للأداء.
هل يستحق استئجار VPS مزود بوحدة GPU عند استخدام أقل من 10%؟
يعتمد ذلك على API الذي كنت ستدفع تكلفته بدلاً من ذلك. عند دورة تشغيل بنسبة 10%، تدفع 3.47 دولار لكل مليون رمز ناتج، وهي تكلفة أقل من المستويين التجاري الصغير والرائد، لكنها أعلى بكثير من مستوى الأوزان المفتوحة المستضاف. عند نسبة 2%، تدفع 17.36 دولار، وهي أعلى من كل API محسوب وفق الاستخدام في هذه المقارنة، بما في ذلك المستوى الرائد. ومن حيث السعر وحده، تتوقف البطاقة عن تحقيق الأفضلية عند دورة تشغيل تقارب 6.9% مقارنةً بالمستوى التجاري الصغير، وتقارب 2.3% مقارنةً بالمستوى الرائد، ولا تحقق الأفضلية مطلقاً مقارنةً بالأوزان المفتوحة المستضافة. استأجر البطاقة عند مستويات أقل من هذه الحدود فقط عندما تكون الخصوصية أو استخدام نموذج لا يوفّره أي API هي القيمة التي تدفع مقابلها.