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

ملخص

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

ما ستتعلمه

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

ما هي AirLLM؟

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

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

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

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

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

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

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

التوفير في الذاكرة مذهل. ينخفض ذروة استخدام ذاكرة الفيديو من 140 جيجابايت+ إلى أقل من 4 جيجابايت - وهو انخفاض بنسبة تزيد عن 95%. يعمل النموذج بدقة كاملة لأنه لا يتم تعديل أي أوزان؛ يتم تحميلها وتفريغها بالتتابع فقط⁵.

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

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

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

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

للمقارنة، يحقق llama.cpp الذي يشغل نموذج 70B بنظام quantization على بطاقة RTX 4090 عادةً من 8 إلى 15 توكن في الثانية - أي أسرع بحوالي 10 إلى 20 مرة من أفضل حالات AirLLM⁷.

الخلاصة: AirLLM ليست مناسبة لتطبيقات الدردشة التفاعلية، والتي تتطلب عموماً أكثر من 20 توكن في الثانية لتجربة سلسة. إنها مصممة لمعالجة الدفعات في وضع عدم الاتصال (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 بدقة كاملة مساحة تتراوح بين 120-140 جيجابايت في البداية. بعد عملية تفكيك الطبقات في التشغيل الأول لـ AirLLM، يتم حذف النموذج الأصلي تلقائياً (عبر علامة delete_original)، مما يترك حوالي 70 جيجابايت من أجزاء الطبقات - وهو توفير بنسبة 50%¹¹.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

المراجع