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

ما الذي يحدد نماذج AI التي يمكنك استضافتها ذاتياً

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

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

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

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

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

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

• 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 المؤقتة (ذاكرة key value المؤقتة، وهي حالة الانتباه التي يحتفظ بها النموذج لكل token موجود حالياً في المحادثة) التكلفة الثانية. تُخصَّص عند تحميل النموذج، ويُحدَّد حجمها وفق طول السياق الذي طلبته، وتزداد خطياً مع هذا الطول.

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

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

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

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

النموذج المقيم يحتفظ بمساحة 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 مرة أخرى بعد 10 دقائق. سيظل النموذج مدرجاً، وهذا هو المقصود تحديداً: فهو يحتفظ بمساحة 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 في الثانية. تؤدي النماذج الصغيرة بهذا الحجم مهاماً محددة بشكل جيد، مثل التصنيف، واستخراج الوسوم، والتلخيص القصير، وإعادة صياغة فقرة وفق أسلوب محدد. لكنها ضعيفة في الاستدلال متعدد الخطوات وفي كتابة تعليمات برمجية تمتد عبر عدة ملفات. ولا يعالج ذلك أي قدر من تحسين صياغة الطلبات.

تتمثل مشكلة هذا المستوى في 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 نحو عشرين دقيقة. بهذه السرعة، يفشل الطلب عادةً قبل أن ينهي النموذج عمله، لأن مهلة انتظار في أحد العملاء أو في Proxy أمام Ollama تنتهي أولاً. ومن هنا يظهر خطأ انتهاء مهلة السياق. هذه الأدوات مخصصة للمعالجة الدفعية. أرسل إليها طابوراً من المستندات طوال الليل، ولن تكون السرعة مهمة. أما وضعها خلف نافذة محادثة، فيجعل السرعة مهمة جداً.

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

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

يتطلب توليد كل token قراءة كل وزن نشط من الذاكرة مرة واحدة. لا توجد طريقة لتجنب ذلك، لذلك تحدد bandwidth الذاكرة سرعة التوليد على CPU، وليس عدد الأنوية. الحد الأقصى هو ناتج قسمة: bandwidth الذاكرة القابل للاستخدام على حجم الأوزان بالـbytes. يوفّر 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 عادية، وليست نتيجة قياس لجهاز واحد. تعتمد نتيجتك على جيل الذاكرة، وعدد القنوات في المضيف، وعدد الجيران الذين يتنافسون على مواردها. قِس أداء جهازك باستخدام أي وسم نموذج لديك بالفعل:

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

ينتهي الملخص المطبوع بعد الإجابة بسطر يحتوي على eval rate: ... tokens/s. هذه هي سرعة التوليد. تجاهل التشغيل الأول في الجلسة، لأن load duration في الملخص نفسه يتضمن قراءة الأوزان من القرص. يشرح قياس عدد 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 للأوزان وحدها، قبل احتساب أي cache. هذه عتاد متخصص، واستئجاره شهرياً يكلف أكثر بكثير مما ينفقه معظم الأشخاص على رموز API خلال عام. يوضّح ما يلزم لاستضافة نموذج من فئة Kimi ذاتياً المتطلبات الفعلية. ويظهر التقسيم نفسه داخل مكتبة Ollama، حيث يُدرج GLM 5.2 كنموذج سحابي فقط، بينما يُنزَّل نموذج شقيق أصغر فعلياً إلى VPS.

الحد الفاصل بوضوح بين الحالتين هو التالي: استضف الخدمة ذاتياً عندما يكون الحمل ثابتاً، وعندما يجب ألا تغادر البيانات خادمك. واشترِ رموز 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 لأوزان النموذج عند استخدام quantisation بدقة 4 bit، إضافة إلى KV cache لطول السياق، ونحو 1 GB لنظام التشغيل وخادم النموذج. عند استخدام سياق بطول 8192 token، يضيف الـcache نحو 1 GB، لذلك تكفي خطة بسعة 8 GB، بينما لا تكفي خطة بسعة 4 GB. إذا أردت استخدام سياق 128k كاملاً كما يذكر model card، فستبلغ سعة الـcache وحدها 16 GB، وستحتاج إلى خطة بسعة 32 GB.

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

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

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

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

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

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

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

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