ما النماذج التي يمكنك استضافتها ذاتياً؟

ما الذي يحدد نماذج الذكاء الاصطناعي التي يمكنك استضافتها ذاتياً

يحدد مقدار واحد نماذج الذكاء الاصطناعي التي يمكنك استضافتها ذاتياً: سعة RAM في الخادم. تؤثر عائلة النموذج وإطار العمل بدرجة أقل بكثير من توافق الأوزان مع الذاكرة مع بقاء مساحة احتياطية. يشرح هذا المقال الحسابات اللازمة لتحديد ذلك. أما تثبيت بيئة التشغيل فهو مهمة منفصلة، وتغطيها الدليل الخاص بتشغيل Ollama على VPS.

تحدد كلفتان الإجابة. الأوزان هي الكلفة الثابتة، ويحددها عدد المعلمات ومستوى التكميم. أما نافذة السياق فهي الكلفة المتغيرة، وهي العامل الذي ينساه الناس إلى أن يرفض نموذج كان قد تحمّل بالأمس التحميل اليوم.

حسابات تحديد الحجم: عدد البتات لكل معامل

يتكوّن ملف النموذج تقريباً بالكامل من الأوزان. يُخزَّن كل وزن بعدد معيّن من البتات. تعني عملية التكميم تخزين الأوزان بعدد بتات أقل من الدقة التي دُرِّب بها النموذج، ما يسبب انخفاضاً طفيفاً في الدقة ويوفّر قدراً كبيراً من الذاكرة. ويتحدد الحجم مباشرةً وفق المعادلة التالية:

weights in GB = (parameters in billions x bits per weight) / 8

تُصدَر النماذج بدقة 16 بت، أي ما يعادل 2 GB لكل مليار معامل. لذلك لا يشغّل أحد تقريباً دقة الإصدار الأصلية على VPS. هذه هي مستويات التكميم التي ستصادفها فعلياً، مع متوسط عدد البتات الحقيقي لكل وزن:

• Q8_0 يخزّن نحو 8.5 بت لكل وزن، أي نحو 1.1 GB لكل مليار معامل.
• Q6_K يخزّن نحو 6.6 بت، أي نحو 0.83 GB لكل مليار معامل.
• Q5_K_M يخزّن نحو 5.7 بت، أي نحو 0.71 GB لكل مليار معامل.
• Q4_K_M يخزّن نحو 4.8 بت، أي نحو 0.6 GB لكل مليار معامل.

استخدم 0.6 GB لكل مليار معامل كرقم عملي. يُعد Q4_K_M الخيار الافتراضي المناسب على خادم مقيّد بالذاكرة: ففقدان الجودة مقارنةً بـ8 بت صغير في معظم المهام، بينما يكاد حجم الملف ينخفض إلى النصف. عند النزول إلى أقل من 4 بت، يتزايد الفقد سريعاً، لذلك يقدّم نموذج 70B مضغوط إلى 2 بت عادةً إجابات أسوأ من نموذج 32B بدقة 4 بت من الجيل نفسه. عندما تكون الذاكرة محدودة، انتقل إلى فئة حجم أصغر قبل أن تنزل إلى أقل من 4 بت.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

يطبّق عمود الأوزان أعلاه قاعدة 0.6 GB لكل مليار معامل. تصل ملفات GGUF الفعلية إلى قيمة تختلف عنها ببضعة بالمئة، لأن طبقتَي التضمين والإخراج تُحافظان على دقة أعلى من بقية الطبقات. يبلغ حجم نموذج 3B بدقة 4 بت نحو 1.8 GB. ويبلغ حجم نموذج 8B 4.8 GB. أما نموذج 32B فحجمه 19.2 GB، ويبلغ حجم نموذج 70B 42 GB.

لماذا يستهلك طول السياق ذاكرة RAM أكثر من الأوزان

تُعد ذاكرة KV المؤقتة (ذاكرة المفتاح والقيمة، وهي حالة الانتباه التي يحتفظ بها النموذج لكل رمز موجود حالياً في المحادثة) التكلفة الثانية. تُخصَّص عند تحميل النموذج، ويُحدَّد حجمها وفق طول السياق المطلوب، وتنمو خطياً مع هذا الطول.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

عند استخدام طول السياق الافتراضي في Ollama، يستهلك نموذج 8B نصف غيغابايت لذاكرة التخزين المؤقت. وعند 8192 رمزاً، يستهلك 1 GB. أما عند طول السياق 128k الذي تعلنه بطاقة النموذج، فيستهلك 16 GB، أي أكثر من ثلاثة أضعاف حجم الأوزان. أما نموذج 70B فهو الحالة المعاكسة: إذ تبلغ ذاكرته المؤقتة عند 128k مقدار 40 GB، وهو أقل من حجم أوزانه، لأن آلية grouped query attention تمنع تكلفة كل رمز من النمو بمعدل يقترب من معدل عدد المعاملات.

يبلغ طول السياق الافتراضي في Ollama مقدار 4096 رمزاً على خادم يعمل بوحدة CPU فقط. عند وجود GPU، يختار Ollama القيمة الافتراضية من VRAM بدلاً من ذلك: 32k بين 24 و48 GiB، و256k عند 48 GiB أو أكثر. ارفع القيمة باستخدام متغير OLLAMA_CONTEXT_LENGTH على الخادم، ثم تحقق من القيمة الفعلية التي حصل عليها نموذج قيد التشغيل في عمود CONTEXT ضمن ollama ps. يشرح المقالة حول num_ctx وطول السياق الحسابات المتعلقة بالذاكرة وراء هذا الإعداد.

هناك طريقتان لتقليل حجم الذاكرة المؤقتة. اطلب طول السياق الذي تحتاج إليه بدلاً من الطول الذي تعلنه بطاقة النموذج، لأن معظم أعمال المحادثة والبرمجة تقع ضمن 8k إلى 32k. أو حوّل الذاكرة المؤقتة نفسها إلى 8 بت، ما يقلل حجمها إلى النصف، مع بعض التراجع في استرجاع المعلومات ضمن السياقات الطويلة.

يحافظ النموذج المقيم على وجوده في RAM حتى تُفرغه الخدمة.

يُبقي Ollama النموذج في الذاكرة لمدة 5 دقائق بعد آخر طلب، ثم يفرغه. يناسب هذا الإعداد الحاسوب المحمول، لكنه غير مناسب للخادم، لأن أول طلب بعد كل فترة خمول سيتحمل وقت التحميل من جديد.

ollama ps
ollama stop qwen3:4b

يعرض ollama ps النماذج المقيمة، مع عمود SIZE الذي يوضح مقدار الذاكرة التي يشغلها النموذج، وعمود UNTIL الذي يوضح وقت انتهاء بقائه. لتثبيت نموذج بشكل دائم، اضبط OLLAMA_KEEP_ALIVE=-1 في الخدمة. تؤدي قيمة 0 إلى تفريغ النموذج فور انتهاء كل استجابة.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

أرسل مطالبة واحدة، ثم شغّل ollama ps مرة أخرى بعد عشر دقائق. سيظل النموذج مدرجاً، وهذا هو المقصود تحديداً: سيحتفظ بتلك الـRAM سواء كان أحد يستخدمه أم لا. النموذج المثبّت ليس سعة احتياطية. على VPS بسعة 16 GB، يشغل نموذج 8B مع سياق 8k نحو 6 GB طوال مدة تشغيل الخدمة، لذلك صمّم الخادم وفق احتياجات النموذج وتطبيقك معاً، لا وفق النموذج وحده. يشرح تثبيت نموذج في الذاكرة المفاضلة مقابل زمن بدء التشغيل البارد.

ما الذي يمكن تشغيله على VPS بسعة 4 GB

احجز نحو 1 GB لنظام التشغيل وخادم النموذج، لتتبقى نحو 3 GB. يتيح ذلك تشغيل نموذج بسعة تتراوح بين 1B و4B، بدقة 4 bits، ومع سياق افتراضي يبلغ 4096 token. اعتباراً من August 2026، تشمل هذه الفئة Llama 3.2 بسعة 3B، وQwen 3 بسعتي 1.7B و4B، وإصدارات Gemma وPhi الصغيرة. تعامل مع هذه النماذج بوصفها أمثلة على الأحجام، لا توصيات. تتغير الأسماء كل بضعة أشهر، أما الحساب فلا يتغير.

توقّع سرعة تتراوح تقريباً بين 6 و14 token في الثانية. تؤدي النماذج بهذا الحجم أعمالاً محدودة بصورة جيدة، مثل التصنيف، واستخراج الوسوم، والتلخيص القصير، وإعادة صياغة فقرة وفق أسلوب محدد. لكنها ضعيفة في الاستدلال متعدد الخطوات وفي كتابة code يمتد عبر عدة ملفات، ولا يمكن لأي قدر من صياغة التعليمات إصلاح ذلك.

تتمثل مشكلة هذا المستوى في swap. إذا لم يتسع النموذج للذاكرة، فلن يرفض Linux تحميله. بدلاً من ذلك، ينقل أجزاء الذاكرة إلى القرص، وبما أن توليد token واحد يقرأ كل الأوزان مرة واحدة، تنخفض سرعة التوليد إلى عدة ثوانٍ لكل token. راقب free -h وعمودي si وso في vmstat 1 أثناء إجابة النموذج. يعني وجود قيم غير صفرية لـswap in وswap out أثناء التوليد أن النموذج أكبر من أن يناسب الخطة.

ما الذي يمكن تشغيله على VPS بسعة 8 إلى 16 GB

هنا يصبح النموذج المستضاف ذاتياً مفيداً بوجه عام. على خادم بسعة 8 GB، يمكنك تشغيل نموذج بحجم 7B أو 8B بدقة 4 bits، وبحوالي 4.8 GB من الأوزان، مع سياق بحجم 8k. وعلى خادم بسعة 16 GB، يمكنك تشغيل نموذج بحجم 13B أو 14B بدقة 4 bits، وبحوالي 8.4 GB، أو إبقاء نموذج 8B بدقة 8 bits إذا كنت تفضّل تخصيص الذاكرة للدقة بدلاً من عدد المعلمات.

السرعة هي القيد. يولّد نموذج 8B على CPU نحو 3 إلى 7 token في الثانية، بينما يولّد نموذج 14B نحو 1.5 إلى 3.5 token في الثانية. يقرأ الشخص بسرعة تتراوح تقريباً بين 5 و10 token في الثانية، لذلك يبدو نموذج 8B على VPS يعمل بـCPU كأنك تراقب كاتباً بطيئاً. هذا مناسب لمهمة تعمل في الخلفية، لكنه مرهق للدردشة التفاعلية. توضّح التجارب المقاسة لـ Qwen 3 بحجم 8B وأحجام أكبر على VPS كيف يبدو الأداء عملياً.

ما الذي يمكن تشغيله على VPS بسعة 32 إلى 64 GB

يبلغ حجم نموذج 32B بدقة 4 بت نحو 19.2 GB، لذلك يمكن تشغيله على خطة بسعة 32 GB مع سياق قصير، ويعمل براحة على خادم بسعة 48 GB أو 64 GB. أما نموذج 70B بدقة 4 بت، فيبلغ حجمه نحو 42 GB، لذلك يحتاج إلى 64 GB قبل إضافة أي ذاكرة تخزين مؤقت.

ثم قيّم السرعة بواقعية. يعمل نموذج 32B على CPU بسرعة تقارب 0.6 إلى 1.5 رمزاً في الثانية، بينما يعمل نموذج 70B بسرعة 0.2 إلى 0.5. تستغرق إجابة من 500 رمزاً من نموذج 70B نحو عشرين دقيقة. هذه الأدوات مناسبة للمعالجة الدفعية. يمكنك تزويدها بقائمة انتظار من المستندات طوال الليل، وعندها لا تهم السرعة. لكن إذا وضعتها خلف واجهة محادثة، فستصبح السرعة مهمة جداً.

يغيّر توجيه الخبراء المختلطين هذه الحسابات، وهو التفصيل المعماري الوحيد الذي يستحق التعلّم. يمرّر نموذج MoE كل رمز عبر جزء صغير فقط من أوزانه. يحتاج نموذج بإجمالي 30B من المعاملات و3B من المعاملات النشطة لكل رمز إلى ذاكرة تكفي لنموذج 30B، لكنه يولّد بسرعة قريبة من نموذج كثيف بحجم 3B، لأن كل رمز يقرأ الخبراء النشطين فقط. على خادم بسعة 32 GB، يكون نموذج MoE بهذه البنية أكثر قابلية للاستخدام بكثير من نموذج كثيف بحجم 30B. القاعدة الأساسية: يحدد إجمالي المعاملات مقدار الذاكرة، بينما تحدد المعاملات النشطة السرعة.

ما سرعة الاستدلال على CPU، بصراحة؟

يتطلب توليد كل token قراءة كل weight نشط من الذاكرة مرة واحدة. لا يمكن تجاوز ذلك، ولذلك تحدد bandwidth الذاكرة سرعة التوليد على CPU، وليس عدد الأنوية. الحد الأقصى هو ناتج قسمة bandwidth الذاكرة القابلة للاستخدام على حجم الـweights بالبايت. يوفّر VPS مشترك صغير عملياً من 10 إلى 25 GB في الثانية عبر vCPUs الخاصة به، ولذلك يصل نموذج حجمه 4.8 GB إلى نحو 2 إلى 5 tokens في الثانية.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

هذه نطاقات تُذكر عادةً على أجهزة VPS عادية، وليست نتيجة benchmark لجهاز واحد. تعتمد نتيجتك على جيل الذاكرة، وعدد القنوات في المضيف، وعدد الجيران الذين يتنافسون على مواردها. قِس نتيجتك بنفسك باستخدام أي model tag لديك مسبقاً:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

ينتهي الملخص المطبوع بعد اكتمال الإجابة بسطر يحتوي على eval rate: ... tokens/s. هذه هي سرعة التوليد. تجاهل التشغيل الأول في الجلسة، لأن load duration في الملخص نفسه يتضمن قراءة الـweights من القرص. يشرح قياس عدد الـtokens في الثانية بطريقة صحيحة كيفية الحصول على رقم صالح للمقارنة.

توجد نتيجتان تفاجئان الناس هنا. تتوقف إضافة vCPUs عن تحقيق فائدة بسرعة، لأن الأنوية الإضافية بعد نحو 8 أنوية تنتظر الذاكرة بدلاً من تنفيذ العمليات الحسابية. وفي الخطة المشتركة، يعيد الأمر نفسه أرقاماً مختلفة من ساعة إلى أخرى. هذا هو وقت CPU المسروق بسبب جار مزعج، وليس خطأً في إعداداتك.

تختلف قراءة prompt عن توليد الإجابة. تعتمد معالجة prompt على الحساب، ولذلك تتوسع مع عدد الأنوية، وهنا يتقدم GPU بأكبر فارق. يحتاج مستند طويل إلى دقائق لقراءته على CPU، بينما يحتاج إلى ثوانٍ على GPU. هذا هو أول عائق تواجهه عند توجيه coding agent إلى نموذج تستضيفه، لأن كل جولة تعيد إرسال سياق الملف وتعريفات الأدوات قبل وصول token واحد من الإجابة.

ما الذي يتغير عند إضافة GPU

لا تتغير الحسابات، بل تتغير مجموعة الموارد التي تنطبق عليها. تُعد VRAM حداً صارماً، لذلك احسب ما يمكن استيعابه قبل الاستئجار:

• تستوعب 8 GB من VRAM نموذجاً بحجم 7B أو 8B بدقة 4 bits مع سياق قصير.
• تستوعب 16 GB نموذجاً بحجم 14B بدقة 4 bits مع سياق فعلي، أو نموذجاً بحجم 8B بدقة 8 bits.
• تستوعب 24 GB نموذجاً بحجم 32B بدقة 4 bits مع إبقاء السياق قصيراً.
• تستوعب 48 GB أو أكثر نموذجاً بحجم 70B بدقة 4 bits مع مساحة للتخزين المؤقت والتزامن.

عندما لا يتسع النموذج، يقسمه Ollama: توضع بعض الطبقات على GPU، والباقي على CPU. يعرض ollama ps هذا التقسيم في العمود PROCESSOR، بصيغة مثل 78%/22% CPU/GPU. تعامل مع ذلك كتحذير، لا كميزة. يحدد جزء CPU سرعة التنفيذ، لأن كل token لا يزال ينتظر تلك الطبقات. لذلك يعمل نموذج توجد ربع طبقاته على CPU بسرعة أقرب بكثير إلى سرعة CPU منها إلى سرعة GPU. إذا رأيت تقسيماً لم تقصده، فاخفض طول السياق أولاً. غالباً ما تكون ذاكرة التخزين المؤقت هي التي تجاوزت الحد.

التزامن سبب آخر لاختيار سعة أكبر. تُشارك أوزان النموذج بين الطلبات المتزامنة، لكن كل طلب نشط يحتاج إلى KV cache خاص به. لذلك يحتاج عشرة مستخدمين متزامنين لنموذج 8B بسياق 8k إلى عشرة أضعاف 1 GB من ذاكرة التخزين المؤقت، إضافة إلى الأوزان. يوضح تشغيل مستخدمين متزامنين من نموذج واحد مستضاف ذاتياً كيفية تحديد هذا الحد الأقصى.

ويُعد تحديد جدوى استئجار GPU مسألة حسابية أيضاً. ويتوقف ذلك على عدد tokens التي تنشئها فعلياً كل شهر. تتضمن نقطة التعادل بين GPU VPS وtokens واجهة API هذه الأرقام.

ما لا يمكنك استضافته ذاتياً

توجد هنا عقبتان مختلفتان، ومن المفيد معرفة أيٍّ منهما تواجه.

الأولى هي الأوزان المغلقة. لا تُوزَّع النماذج التجارية الرائدة، لذلك لا يوجد ملف لتنزيله، ولن يغيّر أي مقدار من RAM ذلك. يمكنك استضافة كل ما يحيط بها ذاتياً: الواجهة، وطبقة الاسترجاع، وحلقة الوكيل، والسجلات. أما النموذج نفسه فيبقى عبر API بعيدة. يشرح ما إذا كان يمكنك استضافة Claude ذاتياً ذلك بالتفصيل.

الثانية هي الأوزان المفتوحة التي تكون كبيرة جداً. أكبر الإصدارات المفتوحة هي تصاميم مزيج من الخبراء، وتضم مئات المليارات من المعلمات الإجمالية. وتنطبق عليها القاعدة نفسها: يحتاج نموذج يضم 400B من المعلمات الإجمالية بدقة 4 بت إلى نحو 240 GB للأوزان وحدها، قبل احتساب أي ذاكرة تخزين مؤقت. هذه أجهزة متخصصة، واستئجارها شهرياً يكلّف أكثر بكثير مما ينفقه معظم الأشخاص على رموز API خلال سنة. يشرح ما يتطلبه استضافة نموذج من فئة Kimi ذاتياً المتطلبات الفعلية.

الحد الفاصل العملي بين الخيارين واضح: استضف النموذج ذاتياً عندما يكون الحمل ثابتاً ولا ينبغي للبيانات مغادرة خادمك. واشترِ رموز API عندما يكون الحمل متقطعاً، أو عندما تكون جودة إجابات النماذج الرائدة هي ما تحتاج إليه فعلياً.

تحقّق مما لديك قبل الاختيار

free -h
nproc
lscpu | grep 'Model name'

خطّط وفق عمود available في free -h، وليس عمود total، لأن total يتضمن الذاكرة التي يستخدمها النظام بالفعل. اطرح نحو 1 GB لنظام التشغيل وخادم النموذج. اقسم المتبقي على 0.6 لتحصل على أكبر عدد للمعاملات، بالمليارات، يمكنك استيعابه عند 4 bits. ثم اطرح ذاكرة KV cache للسياق الذي تريده فعلياً. ما يتبقى هو الإجابة، وعلى خلاف قائمة بأسماء النماذج، لا تصبح هذه الإجابة قديمة.

FAQ

كم أحتاج من RAM لتشغيل نموذج 8B؟

تحتاج إلى نحو 4.8 GB لأوزان النموذج عند استخدام تكميم 4 bit، إضافةً إلى ذاكرة KV cache لطول السياق، ونحو 1 GB لنظام التشغيل وخادم النموذج. عند استخدام سياق من 8192 token، تضيف ذاكرة التخزين المؤقت نحو 1 GB، لذلك تعمل خطة بسعة 8 GB، بينما لا تعمل خطة بسعة 4 GB. إذا أردت استخدام سياق 128k كاملاً كما تذكره بطاقة النموذج، فستحتاج ذاكرة KV cache وحدها إلى 16 GB، ما يعني أنك تحتاج إلى خطة بسعة 32 GB.

لماذا يعمل النموذج ببطء رغم أن VPS يحتوي على عدد كبير من vCPU؟

لأن توليد النص محدود بعرض نطاق الذاكرة، وليس بعدد الأنوية. يحتاج كل token إلى تحميل مجموعة الأوزان النشطة كاملة من RAM، لذلك عندما تشبع عدة أنوية قنوات الذاكرة، تنتظر الأنوية الأخرى. السبب الشائع الآخر هو swap. إذا أظهر vmstat 1 قيمة غير صفرية في si وso أثناء إجابة النموذج، فهذا يعني أن الأوزان لا تتسع في RAM، وأن جزءاً من كل token يُحمّل من القرص، ما يسبب تكلفة أكبر بكثير مما يبدو متوقعاً.

هل تحتاج نافذة السياق الأطول فعلاً إلى ذاكرة أكبر؟

نعم، ويزداد الاستهلاك خطياً مع عدد token. يستهلك نموذج 8B نموذجي نحو 128 KiB من ذاكرة KV cache لكل token، لذلك يستهلك سياق من 8192 token مقدار 1 GB، بينما يستهلك سياق من 131072 token مقدار 16 GB. تُخصَّص ذاكرة التخزين المؤقت عند تحميل النموذج، لا عند ازدياد حجم المحادثة، لذلك يؤدي طلب سياق 128k إلى حجز تلك الذاكرة فوراً، حتى إذا كان كل prompt ترسله يتكون من 200 token.

هل أشغّل نموذجاً كبيراً عند 2 bits أم نموذجاً أصغر عند 4 bits؟

اختر النموذج الأصغر عند 4 bits. تنخفض الجودة ببطء من 8 bits إلى 4 bits، ثم تنخفض بسرعة تحت 4 bits. لذلك يعطي نموذج 70B مضغوطاً إلى 2 bits إجابات أسوأ عادةً من نموذج 32B عند 4 bits من الجيل نفسه. يظهر التكميم الشديد في صورة تكرار وإهمال للتعليمات، وليس في صورة رسالة خطأ، لذلك يسهل إلقاء اللوم على prompt. اعتبر 4 bits الحد الأدنى، وغيّر عدد المعلمات بدلاً من ذلك.

هل يمكنني استضافة نموذج ذاتياً بقدرة مماثلة للنماذج التجارية الكبيرة؟

ليس على VPS عادي. تصل أقوى النماذج ذات الأوزان المفتوحة إلى مئات المليارات من المعلمات، ويعني ذلك أكثر من 200 GB من RAM عند استخدام 4 bits، قبل إضافة ذاكرة KV cache. أما أقوى النماذج التجارية فلا تُوزَّع أصلاً. ما تؤديه الأجهزة العادية جيداً هو تشغيل نموذج جيد من 8B إلى 32B لمهمة محددة، حيث يمكن لنموذج صغير وموجّه جيداً أن يضاهي نموذجاً عاماً في كثير من الحالات. إذا كنت تحتاج إلى جودة النماذج الرائدة، فقارن تكلفة API بتكلفة العتاد قبل شراء أيٍّ منهما.