تشغيل نماذج الذكاء الاصطناعي محليًا أم عبر واجهة برمجة التطبيقات: أيهما تختار؟

Ashley Innocent

Ashley Innocent

16 أبريل 2026

تشغيل نماذج الذكاء الاصطناعي محليًا أم عبر واجهة برمجة التطبيقات: أيهما تختار؟

Apidog للمؤسسات

النشر على الخوادم المحلية

SSO و RBAC

متوافق مع SOC 2

استكشف Apidog للمؤسسات

ملخص سريع

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

مقدمة

جيما 4 (Gemma 4) يعمل بشكل أصلي على iPhone. إضافة متصفح تدمج نموذجًا لغويًا كاملاً بدون مفتاح API. هذه الأمور لم تكن ممكنة قبل 18 شهرًا. اليوم، يتم نشرها على HackerNews.

كان القرار بسيطًا فيما مضى: النماذج الرائدة (frontier models) تعمل فقط عبر واجهة برمجة التطبيقات (API)، وكل ما عداها كان ضعيفًا جدًا بحيث لا يُعتد به. لقد تغير هذا. النماذج المحلية مثل Qwen2.5-72B و Gemma 4 و DeepSeek-V3 تتنافس الآن في اختبارات الأداء الحقيقية. المطورون الذين كانوا يعتمدون بشكل افتراضي على واجهة برمجة تطبيقات OpenAI يعيدون النظر، خاصةً للتطبيقات الحساسة للخصوصية أو المهام عالية الحجم حيث تتزايد تكاليف كل رمز (token) بسرعة.

تتجاوز هذه المقالة التسويق. ستحصل على أرقام ملموسة حول التكلفة، وزمن الاستجابة (latency)، والقدرة حتى تتمكن من اتخاذ القرار الصحيح لحالة استخدامك.

💡
إذا كنت تختبر عمليات تكامل واجهة برمجة تطبيقات الذكاء الاصطناعي بغض النظر عما إذا كان النموذج محليًا أو سحابيًا، فإن سيناريوهات اختبار Apidog تعمل مع كليهما. يمكنك توجيهها إلى نقطة نهاية خادم llama-server محلي أو إلى /v1/chat/completions من OpenAI وتشغيل نفس التأكيدات. المزيد حول ذلك لاحقًا. انظر [internal: api-testing-tutorial] لنهج الاختبار الأساسي.
زر

ماذا يعني "تشغيل الذكاء الاصطناعي محليًا" بالفعل

الذكاء الاصطناعي المحلي ليس شيئًا واحدًا. هناك ثلاثة إعدادات متميزة:

تشغيل النموذج على الجهاز (On-device inference): يعمل النموذج بالكامل على الجهاز، بدون خادم. مثل Gemma Gem في علامة تبويب المتصفح، أو Gemma 4 على محرك Neural Engine لجهاز iPhone، أو نموذج Ollama على جهاز MacBook الخاص بك. لا يلزم الاتصال بالإنترنت بعد التنزيل.

خادم مستضاف ذاتيًا (Self-hosted server): تقوم بتشغيل نموذج على جهازك الخاص (محطة عمل، أو جهاز افتراضي سحابي تتحكم فيه، أو خادم في الموقع) وتُعَرِّض واجهة برمجة تطبيقات (API). لا يعمل النموذج على جهاز المستخدم النهائي، ولكنه ليس على OpenAI أيضًا. تتعامل أدوات مثل llama-server و Ollama و vLLM مع هذا الأمر.

سحابة خاصة (Private cloud): تقوم بنشر نموذج على البنية التحتية السحابية الخاصة بك (نماذج AWS Bedrock المخصصة، نقاط نهاية Azure الخاصة، نماذج GCP Vertex AI المخصصة). تحكم أكبر من واجهة برمجة التطبيقات العامة، ومتاعب أقل من الاستضافة الذاتية الكاملة.

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

مقارنة التكلفة

هنا يتفوق الذكاء الاصطناعي المحلي بوضوح لأعباء العمل ذات الحجم الكبير.

تسعير واجهة برمجة التطبيقات العامة (أبريل 2026):

النموذج الإدخال (لكل مليون رمز) الإخراج (لكل مليون رمز)
GPT-4o $2.50 $10.00
Claude 3.5 Sonnet $3.00 $15.00
Gemini 1.5 Pro $1.25 $5.00
GPT-4o mini $0.15 $0.60
Claude 3 Haiku $0.25 $1.25

تقدير تكلفة الاستضافة الذاتية (Qwen2.5-72B على A100 80GB واحد):

يكلف جهاز A100 80GB من Lambda Labs حوالي 1.99 دولارًا للساعة عند الطلب. يتناسب Qwen2.5-72B بتقسيم INT4 مع A100 واحد ويخدم ما يقرب من 200 رمز/ثانية.

بمعدل 200 رمز/ثانية مع استخدام 100%، هذا يعادل 720 ألف رمز/ساعة، أو حوالي 0.0028 دولار لكل ألف رمز إجمالي (إدخال + إخراج). للمقارنة، تفرض GPT-4o رسومًا قدرها 0.01 دولار لكل ألف رمز إخراج وحده.

نقطة التعادل: إذا كنت تعالج أكثر من حوالي 70 ألف رمز إخراج يوميًا بشكل ثابت، فإن الاستضافة الذاتية تتفوق على GPT-4o من حيث التكلفة. أقل من ذلك، تتفوق واجهة برمجة التطبيقات لأنك لا تدفع مقابل وقت وحدة معالجة الرسوميات (GPU) الخاملة.

للنماذج الأخف: يعمل نموذج Gemma 4 (12B) المكمم بـ 4 بت على بطاقة RTX 4090 واحدة (بسعر 600-800 دولار مستعملة). بتكلفة 0.40 دولار/ساعة لوقت وحدة معالجة الرسوميات السحابية المكافئة، تحقق الاستضافة الذاتية نقطة التعادل مقابل GPT-4o mini عند حوالي 15 ألف رمز إخراج يوميًا.

مقارنة زمن الاستجابة

هنا يصبح الأمر أكثر دقة.

زمن الوصول للرمز الأول (TTFT): على جهاز A100 مخصص، يكون زمن الوصول للرمز الأول لمطالبة (prompt) بحجم ألف رمز باستخدام نموذج 72B حوالي 800 مللي ثانية - 1.5 ثانية. عادةً ما تُرجع واجهة برمجة تطبيقات OpenAI الرمز الأول في 300-800 مللي ثانية لمدخلات مماثلة تحت الحمل العادي.

بالنسبة لتشغيل النماذج على الجهاز (محرك Neural Engine في iPhone، Apple Silicon)، يكون زمن الوصول للرمز الأول لـ Gemma 4 بين 200-400 مللي ثانية لأنه لا يوجد أي عبء إضافي للشبكة. هنا يتفوق التشغيل على الجهاز بوضوح.

معدل الإنتاجية (Throughput): يخدم جهاز A100 واحد يشغل نموذج 72B بتقسيم INT4 مستخدمًا واحدًا بشكل جيد ولكنه يتدهور تحت الحمل المتزامن بدون تجميع (batching). تتعامل واجهات برمجة التطبيقات العامة مع التزامن بشفافية.

التدفق (Streaming): يدعم كلا النهجين التدفق. بالنسبة للنماذج التي تعمل على الجهاز، يتم الإنشاء بالكامل محليًا، لذا لا يوجد تقلب في الشبكة. بالنسبة لنماذج واجهة برمجة التطبيقات، أنت تحت رحمة ظروف الشبكة.

الملخص: يتفوق التشغيل على الجهاز في أقل زمن استجابة (لا شبكة). تتفوق الاستضافة الذاتية في معدل الإنتاجية على نطاق واسع (مع التجميع السليم عبر vLLM). وتتفوق واجهة برمجة التطبيقات العامة في القدرة على التعامل مع الأحمال المفاجئة والبساطة.

مقارنة القدرات

هنا لا تزال واجهات برمجة التطبيقات العامة تتمتع بميزة للمهام الأكثر تطلبًا.

الاستدلال والمهام المعقدة: لا تزال GPT-4o و Claude 3.5 Sonnet متفوقة على النماذج مفتوحة الوزن في اختبارات MMLU و HumanEval والاستدلال المعقد متعدد الخطوات. لقد تقلصت الفجوة بشكل كبير مع Qwen2.5-72B و DeepSeek-V3، لكنها لا تزال قائمة.

توليد الأكواد: متقارب. يتطابق DeepSeek-Coder-V2 و Qwen2.5-Coder-32B مع GPT-4o في العديد من معايير الأكواد. للمهام الخاصة بالأكواد في إعداد مستضاف ذاتيًا، يمكنك استخدام نموذج أكواد متخصص بدلاً من نموذج عام.

طول السياق: تدعم نماذج API الرائدة سياقات تتراوح من 128 ألف إلى مليون رمز. تتوقف معظم النماذج المستضافة ذاتيًا عند 32 ألف - 128 ألف في الممارسة (تتطلب السياقات الأطول ذاكرة أكبر بشكل متناسب).

متعدد الأنماط (Multimodal): تتعامل GPT-4o و Gemini 1.5 Pro مع مدخلات الصور والصوت والفيديو. توجد نماذج متعددة الأنماط مفتوحة الوزن (LLaVA, Qwen-VL) لكنها تتأخر في الأداء.

استدعاء الوظائف / استخدام الأدوات: تتمتع OpenAI و Anthropic بأكثر دعم موثوق لاستخدام الأدوات. تعمل النماذج مفتوحة الوزن التي تدعم استخدام الأدوات ولكنها أقل اتساقًا في سلاسل الأدوات المعقدة. انظر [internal: how-ai-agent-memory-works] لمعرفة كيف يؤثر هذا على معماريات الوكيل (agent).

الخصوصية والتحكم في البيانات

هنا يتفوق الحل المحلي بلا منازع.

مع واجهة برمجة تطبيقات عامة: - تغادر مطالباتك شبكتك - تطبق سياسة الاحتفاظ بالبيانات الخاصة بالمزود (تحتفظ OpenAI بالمدخلات لمدة 30 يومًا بشكل افتراضي ما لم تختار عدم الاحتفاظ بها عبر API) - أنت خاضع لشروط خدمة المزود بشأن المحتوى الحساس - في الصناعات المنظمة (الرعاية الصحية، المالية، القانونية)، قد يكون هذا عائقًا للامتثال

مع نموذج مستضاف ذاتيًا: - تبقى المطالبات على بنيتك التحتية - لا يوجد احتفاظ بالبيانات من طرف ثالث - تحكم كامل فيما يمكن للنموذج معالجته وما لا يمكنه - الامتثال لـ GDPR/HIPAA أسهل في الصيانة

للتطبيقات التي تتعامل مع بيانات صحية شخصية، أو مستندات قانونية، أو أكواد مملوكة، غالبًا ما تكون الاستضافة الذاتية ليست خيارًا بل ضرورة.

كيفية اختبار تكاملات الذكاء الاصطناعي بغض النظر عن مكان تشغيل النموذج

سواء كنت تستخدم https://api.openai.com/v1/chat/completions أو http://localhost:11434/api/chat (Ollama) أو http://localhost:8080/v1/chat/completions (llama-server)، فإن واجهة برمجة التطبيقات (API) متوافقة مع OpenAI. هذا مهم لأن سيناريوهات اختبار Apidog تعمل مع أي نقطة نهاية HTTP.

يمكن لسيناريو اختبار واحد العمل على كليهما:

{
  "scenario": "اختبار دخاني لإكمال الدردشة",
  "environments": {
    "local": {"base_url": "http://localhost:11434"},
    "production": {"base_url": "https://api.openai.com"}
  },
  "steps": [
    {
      "name": "إكمال أساسي",
      "method": "POST",
      "url": "{{base_url}}/v1/chat/completions",
      "body": {
        "model": "{{model_name}}",
        "messages": [{"role": "user", "content": "قل 'الاختبار اجتاز' ولا شيء آخر"}],
        "max_tokens": 20
      },
      "assertions": [
        {"field": "status", "operator": "equals", "value": 200},
        {"field": "response.choices[0].message.content", "operator": "contains", "value": "test passed"},
        {"field": "response.usage.total_tokens", "operator": "less_than", "value": 50}
      ]
    }
  ]
}

قم بتشغيل هذا السيناريو مقابل مثيل Ollama المحلي الخاص بك أثناء التطوير ومقابل واجهة برمجة تطبيقات OpenAI في CI. إذا كان الكود الخاص بك يعمل مع النموذج المحلي، فيجب أن يعمل مع واجهة برمجة التطبيقات. إذا لم يعمل، فإن الاختلاف عادة ما يكون في: - تنسيق اسم النموذج (يستخدم Ollama qwen2.5:72b، ويستخدم OpenAI gpt-4o) - بنية استجابة استدعاء الوظيفة (اختلافات طفيفة بين المزودين) - تنسيق حدث التدفق (بيانات مقابل دلتا مقابل كائنات استجابة كاملة).

الميزة الذكية (Smart Mock) الخاصة بـ Apidog مفيدة لمحاكاة سلوك النموذج المحلي في CI دون الحاجة إلى تشغيل وحدة معالجة الرسوميات (GPU). قم بتكوين mock يعيد استجابات متوافقة مع OpenAI وقم بتشغيل سيناريوهات الاختبار الخاصة بك مقابلها. انظر [internal: how-to-build-tiny-llm-from-scratch] للحصول على معلومات أساسية حول سبب اختلاف هياكل الاستجابة على مستوى النموذج.

إعداد خادم نموذج محلي في 10 دقائق

إذا كنت ترغب في تجربة الاستضافة الذاتية قبل الالتزام بها، فإن Ollama هو أسرع طريق:

# تثبيت Ollama
curl -fsSL https://ollama.com/install.sh | sh

# سحب نموذج (Gemma 4 12B، يتناسب مع 10 جيجابايت VRAM)
ollama pull gemma4:12b

# تشغيل الخادم (واجهة برمجة تطبيقات متوافقة مع OpenAI على المنفذ 11434)
ollama serve

# اختباره
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4:12b",
    "messages": [{"role": "user", "content": "مرحبًا"}]
  }'

للاستضافة الذاتية الإنتاجية مع التزامن متعدد المستخدمين، vLLM هو الخيار الأفضل:

pip install vllm
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-72B-Instruct-AWQ \
  --quantization awq \
  --max-model-len 32768

هذا يعرض واجهة برمجة تطبيقات متوافقة مع OpenAI على المنفذ 8000. وجّه Apidog إلى http://your-server:8000 وقم بتشغيل سيناريوهات الاختبار الخاصة بك مباشرة.

متى تختار كل نهج

السيناريو محلي واجهة برمجة التطبيقات (API)
معالجة دفعات كبيرة الحجم (>100 ألف رمز/يوم) أرخص مكلف
بيانات حساسة للخصوصية (صحية، قانونية، مالية) مطلوب محفوف بالمخاطر
أقل زمن استجابة على الجهاز الأفضل غير ممكن
الحاجة إلى قدرة نموذج رائد غير كافٍ مطلوب
أعباء عمل متقطعة مع حركة مرور متغيرة معقد في التوسع يتعامل تلقائيًا
لا تتوفر وحدة معالجة رسوميات (GPU) صعب سهل
بيئة التطوير/الاختبار ممتاز (Ollama) يكلف مالاً
مهام متعددة الأنماط محدود دعم كامل
الامتثال للصناعات المنظمة أسهل يتطلب اتفاقية معالجة البيانات (DPA)

الإجابة الصادقة لمعظم الفرق: استخدم واجهة برمجة تطبيقات عامة للإنتاج (Claude أو GPT-4o للمهام التي تتطلب جودة عالية، Haiku أو 4o-mini للمهام الأرخص ذات الحجم الكبير)، و Ollama محليًا للتطوير والاختبار. يمنحك هذا أفضل ما في العالمين: جودة رائدة في الإنتاج، وتكلفة صفرية في التطوير، وواجهة برمجة تطبيقات متوافقة مع OpenAI متسقة في كل مكان.

انظر [internal: open-source-coding-assistants-2026] لمعرفة كيف تتناسب مساعدات البرمجة مفتوحة المصدر مع صورة الذكاء الاصطناعي المحلي.

الخلاصة

قرار الذكاء الاصطناعي المحلي مقابل واجهة برمجة التطبيقات ليس ثنائيًا. الإجابة الصحيحة تعتمد على حجم عملك، متطلبات الخصوصية، احتياجات زمن الاستجابة، ومستوى القدرة الذي تحتاجه.

لمعظم المطورين الذين يبنون تطبيقات مدعومة بالذكاء الاصطناعي: ابدأ بواجهة برمجة تطبيقات عامة، انتقل إلى الاستضافة الذاتية عندما تتجاوز فاتورتك الشهرية 200-300 دولار، واستخدم Ollama في بيئتك المحلية من اليوم الأول. حافظ على استقلالية الكود الخاص بك عن المزود باستخدام واجهة برمجة التطبيقات المتوافقة مع OpenAI في كل مكان.

اختبر كلتا البيئتين باستمرار باستخدام Apidog لالتقاط الفروق الدقيقة بين سلوك النموذج المحلي والنموذج السحابي قبل أن تتحول إلى أخطاء إنتاجية.

زر

الأسئلة الشائعة

ما هي أقل وحدة معالجة رسوميات (GPU) لتشغيل نموذج محلي مفيد؟تعمل بطاقة RTX 3060 (بذاكرة فيديو 12 جيجابايت) على تشغيل Qwen2.5-7B أو Gemma 4 4B بجودة كاملة. تتعامل بطاقة RTX 4090 (بذاكرة فيديو 24 جيجابايت) مع معظم نماذج 14B-20B بتقسيم INT4 ونماذج 34B بتقسيم INT2. أما لنماذج 72B، فأنت بحاجة إلى وحدتي معالجة رسوميات بحجم 24 جيجابايت أو A100/H100 واحدة.

هل يمكنني تشغيل الذكاء الاصطناعي المحلي على Apple Silicon؟نعم. يدعم Ollama معالجات Apple Silicon بشكل أصلي ويستخدم محرك Neural Engine للتسريع. يمكن لجهاز M3 Pro (ذاكرة موحدة 18 جيجابايت) تشغيل Qwen2.5-14B براحة. أما جهاز M4 Max (128 جيجابايت)، فيتعامل مع نماذج 70B.

هل جودة إخراج النموذج المحلي جيدة بما يكفي للإنتاج؟يعتمد ذلك على المهمة. لتوليد الأكواد، التلخيص، واستخراج البيانات المنظمة: نعم، مع نموذج بحجم 32B+. أما للاستدلال المعقد، أو الكتابة الدقيقة، أو المهام التي تتطلب معرفة عميقة بالعالم: لا تزال نماذج API الرائدة تتمتع بميزة واضحة.

هل تدعم النماذج المحلية استدعاء الوظائف؟نعم، ولكن بشكل غير متسق. تدعم كل من Llama 3.1 و Qwen2.5 و Mistral استخدام الأدوات. لكن الموثوقية أقل من GPT-4o أو Claude 3.5 Sonnet في سلاسل الأدوات المعقدة. اختبر بدقة باستخدام سيناريوهات اختبار Apidog قبل الاعتماد على استخدام الأدوات في النماذج المحلية في الإنتاج. انظر [internal: claude-code] لمعرفة كيف تتعامل النماذج الرائدة مع استخدام الأدوات في سياقات البرمجة.

كم تكلفة استضافة نموذج 70B ذاتيًا على AWS؟تكلفة جهاز p4d.24xlarge (8x A100 40GB) هي 32.77 دولارًا/ساعة عند الطلب. يشغل نموذج 70B INT8 بمعدل إنتاجية عالٍ. جهاز g5.2xlarge (1x A10G 24GB) بتكلفة 1.21 دولار/ساعة يشغل نموذج 14B INT4 لأعباء العمل الأخف. تقلل الحجوزات المسبقة (Reserved instances) هذه التكاليف بنسبة 30-40%.

ما الفرق بين Ollama و llama.cpp؟llama.cpp هو محرك الاستدلال الأساسي. يغلف Ollama أداة llama.cpp بواجهة برمجة تطبيقات REST، وإدارة النماذج (السحب، القائمة، الحذف)، وواجهة سطر أوامر بسيطة. استخدم Ollama للتطوير. استخدم llama.cpp مباشرة (عبر llama-server) إذا كنت بحاجة إلى مزيد من التحكم في تنسيقات التكميم أو تكوين الأجهزة.

هل يمكنني التبديل بين النماذج المحلية ونماذج واجهة برمجة التطبيقات دون تغيير الكود الخاص بي؟نعم، إذا كنت تستخدم عميلاً متوافقًا مع OpenAI. في بايثون (Python): openai.OpenAI(base_url='http://localhost:11434/v1', api_key='ollama') يتصل بـ Ollama. قم بتغيير base_url إلى https://api.openai.com/v1 وحدث api_key للتبديل إلى السحابة. اضبط هذه المتغيرات عبر متغيرات البيئة (environment variables) ولن يتغير الكود الخاص بك أبدًا.

ممارسة تصميم API في Apidog

اكتشف طريقة أسهل لبناء واستخدام واجهات برمجة التطبيقات