AirLLM: تشغيل موديلات 70B على GPU بسعة 4GB — الضجة مقابل الواقع

ملخص

AirLLM هي مكتبة Python مفتوحة المصدر تتيح لك تشغيل نماذج لغوية تحتوي على ٧٠ مليار معلمة (70B) على وحدة معالجة رسومات (GPU) واحدة بسعة ٤ جيجابايت - وحتى نماذج 405B على ٨ جيجابايت من ذاكرة الفيديو (VRAM) - دون الحاجة إلى تقليل الدقة (quantization). تعمل المكتبة عن طريق تحميل طبقة محول (transformer layer) واحدة تلو الأخرى من القرص الصلب، وإجراء الحسابات، ثم استبدالها بالطبقة التالية. المقايضة هنا هي السرعة: تتراوح القياسات في العالم الحقيقي من حوالي ٠٫٧ توكن في الثانية على الأجهزة السريعة إلى دقائق لكل توكن في الإعدادات الأبطأ. تعد AirLLM إنجازاً تقنياً حقيقياً من أجل إتاحة التكنولوجيا للجميع، ولكنها ليست بديلاً لأدوات الاستدلال (inference) المخصصة للإنتاج مثل llama.cpp أو vLLM. إليك ما تفعله فعلياً، وأين تتفوق، وأين تقصر.

---

ما ستتعلمه

• ما هي AirLLM والمشكلة التي تحلها
• كيف يعمل الاستدلال بنظام الطبقات (layer-wise inference) من الداخل
• أرقام الأداء في العالم الحقيقي ومقايضات السرعة
• كيف تقارن AirLLM بـ llama.cpp و vLLM و Ollama
• ما هي حالات الاستخدام التي تعد AirLLM جيدة لها حقاً - وما هي الحالات التي لا تصلح لها
• هل الضجة المثارة حول تشغيل نماذج 70B على أجهزة المستهلكين العادية مبررة

---

ما هي AirLLM؟

AirLLM هي مكتبة Python مفتوحة المصدر أنشأها Gavin Li، وهو مهندس ذكاء اصطناعي سابق في Airbnb قاد جهود دعم العملاء بالذكاء الاصطناعي في الشركة^١. تم إصدار AirLLM لأول مرة في ٢٠ نوفمبر ٢٠٢٣، وهي تعالج واحداً من أكبر العوائق أمام تشغيل النماذج اللغوية الكبيرة محلياً: ذاكرة وحدة معالجة الرسومات (GPU).

يتطلب نموذج يحتوي على ٧٠ مليار معلمة بدقة كاملة حوالي ١٤٠ جيجابايت من ذاكرة الفيديو (VRAM) - وهو ما يتجاوز بكثير ما تقدمه أي وحدة معالجة رسومات للمستهلكين. الحل القياسي هو الـ quantization: ضغط النموذج إلى دقة ٤ بت أو ٨ بت بحيث يتناسب مع ذاكرة أقل. يعمل هذا بشكل جيد ولكنه يتضمن دائماً بعض الفقد في الدقة.

تتبع AirLLM نهجاً مختلفاً تماماً. بدلاً من تقليص حجم النموذج، تقوم ببثه (streaming). تقوم المكتبة بتحميل طبقة محول واحدة في كل مرة في ذاكرة وحدة معالجة الرسومات، وتشغيل الحسابات لتلك الطبقة، وحفظ النتيجة الوسيطة، ثم استبدالها بالطبقة التالية. النتيجة: نموذج 70B يعمل على وحدة معالجة رسومات بذاكرة ٤ جيجابايت فقط، وبدقة كاملة، دون الحاجة إلى quantization^٢.

أضاف الإصدار الأخير (2.11.0) دعماً لاستدلال Llama 3.1 405B على ٨ جيجابايت فقط من ذاكرة الفيديو، إلى جانب دعم عائلة نماذج Qwen2.5^٣.

---

كيف يعمل الاستدلال بنظام الطبقات

يقوم استدلال النماذج اللغوية الكبيرة التقليدي بتحميل النموذج بالكامل في ذاكرة وحدة معالجة الرسومات دفعة واحدة. بالنسبة لنموذج 70B، يعني هذا أن جميع طبقات المحول التي تزيد عن ٨٠ طبقة تقبع في ذاكرة الفيديو في وقت واحد. يعمل نهج AirLLM القائم على الطبقات بشكل مختلف جذرياً.

عند تحميل نموذج لأول مرة، يقوم محرك تفكيك الطبقات في AirLLM بتقسيم نقطة الفحص (checkpoint) الكاملة إلى أجزاء طبقات فردية - عادةً من ٨٠ إلى ١٠٠ ملف منفصل لنموذج 70B. أثناء الاستدلال، يتبع خط المعالجة تسلسلاً صارماً: تحميل الطبقة N في ذاكرة وحدة معالجة الرسومات، وحساب تنشيطات تلك الطبقة، وحفظ المخرجات، وتفريغ الطبقة N، ثم الجلب المسبق للطبقة N+1. يستمر هذا حتى تعالج جميع الطبقات المدخلات^٤.

التوفير في الذاكرة مذهل. ينخفض ذروة استخدام ذاكرة الفيديو من ١٤٠ جيجابايت+ إلى أقل من ٤ جيجابايت - وهو انخفاض بنسبة تزيد عن ٩٥٪. يعمل النموذج بدقة كاملة لأنه لا يتم تعديل أي أوزان؛ يتم تحميلها وتفريغها بالتتابع فقط^٥.

أضاف إصدار AirLLM v2.0 خيار الـ quantization بنظام الكتل (٤ بت أو ٨ بت) الذي يمكنه تسريع الاستدلال بما يصل إلى ٣ مرات عندما لا تكون الدقة الكاملة مطلوبة. قدم الإصدار 2.5 ميزة الجلب المسبق (prefetching) لتداخل عمليات قراءة القرص مع حسابات وحدة معالجة الرسومات، مما يقلل وقت الخمول بين الطبقات^٦.

---

مقايضة السرعة: أين تلتقي الضجة بالواقع

هذا هو المكان الذي يحتاج فيه الادعاء الرئيسي - "تشغيل 70B على ٤ جيجابايت" - إلى سياق جاد. تجعل AirLLM النماذج الكبيرة ممكنة على أجهزة المستهلكين، لكنها لا تجعلها سريعة.

يتطلب كل تبديل للطبقات قراءة عشرات الميجابايت من القرص الصلب. حتى على قرص NVMe SSD، يتراكم هذا العبء الإضافي لعمليات الإدخال والإخراج (I/O) عبر أكثر من ٨٠ طبقة لكل توكن يتم إنتاجه. يختلف الأداء الفعلي بشكل كبير اعتماداً على الأجهزة:

الأجهزة	النموذج	السرعة التقريبية
NVMe SSD + وحدة معالجة رسومات مخصصة	Llama 2 70B	~٠٫٧ توكن/ثانية
M2 MacBook Pro (16GB RAM)	نموذج 70B	~٥٠ توكن في ١٢ دقيقة (~٠٫٠٧ توكن/ثانية)
Google Colab T4	Llama 2 7B	~١ توكن في الدقيقة (أبلغ عنها المستخدمون)
وضع الدفعات (٥٠ برومبت)	نموذج 70B	~٥٫٣ ثانية لكل توكن

للمقارنة، يحقق llama.cpp الذي يشغل نموذج 70B بنظام quantization على بطاقة RTX 4090 عادةً من ٨ إلى ١٥ توكن في الثانية - أي أسرع بحوالي ١٠ إلى ٢٠ مرة من أفضل حالات AirLLM^٧.

الخلاصة: AirLLM ليست مناسبة لتطبيقات الدردشة التفاعلية، والتي تتطلب عموماً أكثر من ٢٠ توكن في الثانية لتجربة سلسة. إنها مصممة لمعالجة الدفعات في وضع عدم الاتصال (offline batch processing)، والتحليل لمرة واحدة، والتجارب البحثية حيث يكون زمن الاستجابة مقبولاً.

---

النماذج المدعومة وتوافق المنصات

تدعم AirLLM مجموعة واسعة من معماريات النماذج مفتوحة المصدر. بدءاً من الإصدار 2.11.0، تشمل عائلات النماذج المدعومة Llama (بما في ذلك Llama 3 و Llama 3.1 405B)، و Qwen و Qwen2.5، و Mistral و Mixtral، و ChatGLM، و Baichuan، و InternLM^٨.

قدم الإصدار 2.6 ميزة AutoModel، التي تكتشف تلقائياً معمارية النموذج من ملفات نقطة الفحص، مما يلغي الحاجة إلى تحديد فئة النموذج يدوياً أثناء التهيئة^٩.

توافق المنصات واسع: تعمل AirLLM على Linux و Windows و macOS، بما في ذلك Apple Silicon (من M1 إلى M4). يتم دعم الاستدلال المعتمد على المعالج (CPU) فقط بدءاً من الإصدار 2.10.1، على الرغم من أن الأداء على المعالج أبطأ بكثير حتى من أبطأ إعدادات وحدة معالجة الرسومات^١٠.

---

مساحة القرص: المتطلب الخفي

بينما تزيل AirLLM عائق ذاكرة الفيديو (VRAM)، فإنها تنقل متطلبات التخزين إلى القرص الصلب. يشغل نموذج 70B بدقة كاملة مساحة تتراوح بين ١٢٠-١٤٠ جيجابايت في البداية. بعد عملية تفكيك الطبقات في التشغيل الأول لـ AirLLM، يتم حذف النموذج الأصلي تلقائياً (عبر علامة delete_original)، مما يترك حوالي ٧٠ جيجابايت من أجزاء الطبقات - وهو توفير بنسبة ٥٠٪^١١.

بالنسبة لنموذج Llama 3.1 405B، تزداد متطلبات القرص بشكل طردي. يوفر قرص NVMe SSD تحميل طبقات أسرع بـ ٣-٥ مرات من قرص SATA SSD، مما يجعل نوع التخزين عاملاً حاسماً في الأداء الفعلي. ستعمل محركات الأقراص الصلبة الميكانيكية (HDD) ولكنها ستجعل الاستدلال بطيئاً بشكل مؤلم^١٢.

---

AirLLM مقابل البدائل

ليست AirLLM هي الطريقة الوحيدة لتشغيل النماذج الكبيرة على أجهزة المستهلكين. إليك كيف تقارن بالبدائل الثلاثة الأكثر شعبية:

الميزة	AirLLM	llama.cpp (GGUF)	vLLM	Ollama
النهج الأساسي	بث الطبقات (Layer-wise streaming)	التكميم (Quantization - GGUF)	PagedAttention	التكميم + الخدمة
أقل VRAM لنموذج 70B	٤ جيجابايت	~٣٢-٤٠ جيجابايت (Q4)	٨٠ جيجابايت+	~٣٢-٤٠ جيجابايت (Q4)
السرعة (70B)	~٠٫٧ توكن/ثانية في أفضل الحالات	٨-١٥ توكن/ثانية (RTX 4090)	٢٠+ توكن/ثانية (A100)	٥-١٠ توكن/ثانية
الدقة	كاملة (FP16/FP32)	مكممة (Q4-Q8)	كاملة أو مكممة	مكممة
جاهز للإنتاج	لا	نعم	نعم	نعم
دردشة تفاعلية	لا	نعم	نعم	نعم
النظام البيئي	مستقل	واسع (LM Studio، إلخ)	يركز على الخوادم	مناسب لسطح المكتب

يعد llama.cpp هو المقارنة الأكثر مباشرة. فهو يستخدم التكميم لضغط النماذج — عادةً إلى دقة ٤ بت — بحيث تتناسب مع ذاكرة VRAM المتاحة. عادةً ما يكون فقدان الدقة الناتج عن التكميم المنفذ جيدًا صغيرًا (غالبًا لا يمكن اكتشافه في الممارسة العملية)، وميزة السرعة هائلة. بالنسبة لمعظم المستخدمين الذين يرغبون في تشغيل نماذج كبيرة محليًا، فإن llama.cpp مع تكميم GGUF هو الخيار العملي الأفضل^١٣.

تم تصميم vLLM لخدمة الإنتاج ذات الإنتاجية العالية مع ميزات مثل PagedAttention لإدارة الذاكرة بكفاءة. يتطلب ذاكرة VRAM أكبر بكثير ولكنه يقدم أداءً بمستوى الإنتاج.

القيمة الفريدة لـ AirLLM هي أنه من بين الأدوات القليلة التي يمكنها تشغيل نموذج 70B بدقة كاملة على وحدة معالجة رسومات (GPU) بسعة ٤ جيجابايت — دون الحاجة إلى أي تكميم. تدعم الأطر الأخرى مثل llama.cpp تفريغ الطبقات جزئيًا إلى ذاكرة الوصول العشوائي (RAM)، ولكنها تتطلب عادةً التكميم لتناسب النموذج. إذا كانت حالة الاستخدام الخاصة بك تتطلب عدم فقدان أي دقة بسبب التكميم ويمكنك تحمل الاستدلال البطيء، فإن AirLLM هو أحد الأدوات الوحيدة التي تقدم ذلك.

---

من يجب أن يستخدم AirLLM؟

يحل AirLLM مشكلة حقيقية، ولكن لجمهور محدود. بناءً على بيانات الأداء في العالم الحقيقي وتعليقات المجتمع، يعد AirLLM مناسبًا تمامًا للباحثين الذين يحتاجون إلى اختبار أو تقييم النماذج الكبيرة دون الوصول إلى وحدات معالجة الرسومات السحابية، ومهام المعالجة المجمعة (batch processing) في وضع عدم الاتصال حيث لا يهم زمن الاستجابة (مثل معالجة مجموعة بيانات طوال الليل)، والتجريب السريع بأحجام نماذج مختلفة لفهم اختلافات القدرات، والحالات التي يكون فيها استدلال الدقة الكاملة مطلوبًا حقًا وتكون عيوب التكميم غير مقبولة^١٤.

لا يعد AirLLM الأداة المناسبة لروبوتات الدردشة التفاعلية أو التطبيقات في الوقت الفعلي، أو خدمة الإنتاج API، أو أي سير عمل ينتظر فيه المستخدمون الاستجابات، أو المواقف التي ينتج فيها نموذج مكمم عبر llama.cpp جودة مقبولة (وهي معظم الحالات).

---

هل يرقى AirLLM إلى مستوى الضجة المثارة حوله؟

الإجابة الصادقة: جزئيًا.

الادعاء التقني الأساسي حقيقي وتم التحقق منه. يقوم AirLLM بالفعل بتشغيل نموذج 70B على وحدة معالجة رسومات بسعة ٤ جيجابايت بدقة كاملة. هذا ليس تسويقًا — إنه إنجاز هندسي مشروع. تعمل بنية بث الطبقات، وبالنسبة لمجموعة محدودة من حالات الاستخدام حيث تهم الدقة الكاملة على الحد الأدنى من الأجهزة، لا يوجد شيء آخر يفعل ذلك^١٥.

لكن الضجة — المدفوعة بعناوين مثل "شغل 70B على لابتوبك!" — تبالغ في تصوير التجربة العملية. إن تشغيل نموذج 70B بسرعة ٠٫٠٧ توكن في الثانية على جهاز MacBook ممكن تقنيًا ولكنه عديم الفائدة عمليًا لأي شيء تفاعلي. مقايضة السرعة ليست مجرد ملاحظة هامشية صغيرة؛ إنها السمة المميزة لاستخدام AirLLM.

بالنسبة لمعظم الأشخاص الذين يرغبون في تشغيل نماذج كبيرة محليًا، فإن التوصية البراجماتية هي البدء بـ llama.cpp أو Ollama مع النماذج المكممة. يعمل نموذج 70B مكمم جيدًا بدقة Q4 أسرع بـ ١٠-٢٠ مرة من نهج الدقة الكاملة لـ AirLLM، مع اختلافات في الدقة نادرًا ما تكون ملحوظة في الممارسة العملية. إذا كنت مهتمًا بكيفية تطور النماذج مفتوحة المصدر على نطاق أوسع، فإن دليلنا حول Google Gemma 4 يغطي أحدث ما في نشر النماذج مفتوحة الأوزان.

تكمن القيمة الحقيقية لـ AirLLM كأداة للبحث والتجريب — وهي وسيلة للوصول إلى نماذج كانت ستكون بعيدة المنال تمامًا لولا ذلك. في هذا الوعد المحدود، فإنه يفي بوعوده. أما بالنسبة للوعد الأوسع بـ "إضفاء الطابع الديمقراطي" على نماذج 70B للاستخدام اليومي، فإن ضريبة السرعة باهظة للغاية بالنسبة لمعظم سير العمل. للحصول على نظرة أوسع على كيفية تشكيل تكاليف البنية التحتية للذكاء الاصطناعي لما هو عملي، راجع تحليل تكاليف الذاء الاصطناعي الخاص بنا.

---

المراجع