استضافة Mistral Large 4 محلياً: دروس تعلمناها بالصعب

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

الخطأ الأول: قراءة «الأوزان المفتوحة» على أنها «مجانية للاستخدام كما تشاء»

يحدث الخطأ الأول قبل أن يلمس أحد وحدة معالجة رسومية. يصدر Mistral Large 4 بموجب ترخيص شبيه بترخيص MIT مُعدّل مع استثناء مهم: إذا كنت أنت أو الشركات التابعة لك تدير أعمالاً تقدم النموذج كخدمة، فأنت تحتاج إلى ترخيص تجاري منفصل من Mistral قبل استخدام النموذج تجارياً. بالنسبة لشركة تشغّل الاستدلال داخلياً، كتلخيص المستندات أو تشغيل مساعد برمجي للموظفين، فالأمر على الأرجح مقبول. أما شركة ناشئة تخطط لإعادة بيع خدمة الاستدلال، فهذا توقف تام حتى تراسل الشركة.

يخطئ المختصون في هذا الأمر في الاتجاهين. بعض الفرق ترى كلمة «مفتوح» في البيان الصحفي فتبني منتجاً تجارياً على الأوزان، ليكتشفوا القيد أثناء تدقيق العناية الواجبة للتمويل، وهو أسوأ توقيت ممكن. وآخرون يبالغون في التصحيح ويفترضون أن الترخيص يمنع كل استخدام تجاري، بينما يستهدف فعلياً مزودي الاستدلال المنافسين. الحل مملّ لكنه ضروري: اطلب من فريقك القانوني قراءة نص الترخيص الفعلي لا منشور الإعلان. وسواء سميت ذلك «أوزاناً مفتوحة» أو «أوزاناً متاحة»، وهو تمييز يتجادل حوله المجتمع بصوت عالٍ ولا يخلو من وجاهة، فإن القرار الهندسي يجب أن يُبنى على ما تسمح به الشروط فعلياً لعملك.

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

الخطأ الثاني: تحديد الأجهزة من صفحة التسويق بدلاً من الحساب

هذا هو الخطأ الذي يستنزف أكبر قدر من المال. يقرأ مهندس «1 تريليون معامل»، ثم ينظر إلى أربع وحدات H200 في غرفة الخوادم بالشركة، ويقدّر أن 540 غيغابايت من ذاكرة VRAM تكفي تقريباً. لكنها لا تكفي، والسبب حساب حسابي يستغرق تسعين ثانية ويوفر عليك ربعاً من الإحراج.

عند دقة BF16، يحتاج تريليون معامل إلى نحو 2 تيرابايت من الذاكرة لأوزانه وحدها. مع التكميم إلى 8 بت تقترب من 1 تيرابايت. وعند 4 بت، حوالي 500 إلى 560 غيغابايت، قبل احتساب ذاكرة KV cache والتفعيلات وعبء الخدمة. خادم الـ540 غيغابايت يتسع لنموذج 4 بت فقط إذا كنت مرتاحاً لنافذة سياق قصيرة وعدد محدود من المستخدمين المتزامنين. معمارية الخبراء المختلطة (52 مليار معامل نشط لكل رمز) تساعد في الحوسبة لكل رمز، لكنها لا تفعل شيئاً للـذاكرة: فجميع التريليون معامل لا بد أن تكون موجودة في مكان قابل للوصول، ولأن أوزان الخبراء تُستدعى بشكل غير متوقع، فإن نقلها إلى ذاكرة المعالج يدمّر زمن الاستجابة بطريقة لا تحدث في النماذج الكثيفة.

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

# The 90-second sizing check before you buy anything
params = 1_000e9
for bits in (16, 8, 4, 3):
weights_gb = params * bits / 8 / 1e9
# KV cache ballpark for MoE: ~0.5-1.5 GB per 32k-token session
kv_gb = 20 * 1.0          # 20 concurrent 32k sessions
overhead_gb = weights_gb * 0.05
total = weights_gb + kv_gb + overhead_gb
print(f"{bits}-bit: weights {weights_gb:.0f} GB, total ~{total:.0f} GB")
# 16-bit: weights 2000 GB, total ~2120 GB
#  8-bit: weights 1000 GB, total ~1070 GB
#  4-bit: weights  500 GB, total  ~545 GB
#  3-bit: weights  375 GB, total  ~414 GB

لاحظ أن النسخة الصادقة من ذلك الجدول تتضمن ذاكرة KV cache والعبء الإضافي. أما النسخة غير الصادقة، التي تحسب الأوزان فقط، فهي السبب في أن تنتهي الفرق بنموذج يُحمّل ولكنه لا يخدم أكثر من ثلاثة مستخدمين.

الخطأ الثالث: اعتبار التكميم وجبة مجانية

بعد أن تقبل الفرق بحاجتها إلى التكميم، يأتي الخطأ التالي: افتراض أن 4 بت هو «نفس النموذج تقريباً». أحياناً يكون كذلك. وغالباً لا، وأنماط الفشل هي بالضبط ما تهتم به أكثر.

النمط الذي رأيته مراراً: يقيس فريق نشرهم بدقة 4 بت على اختبارات اختيار من متعدد بأسلوب MMLU، فيرون انخفاضاً بنسبة 1%، ثم يطلقون النموذج. بعدها يشكو المستخدمون في الإنتاج من أن إعادة هيكلة الشيفرة الطويلة متعددة الملفات تخرج عن السيطرة، أو أن مخرجات JSON لاستدعاء الأدوات تتشوه بشكل خفي باحتمال منخفض لكن بتكرار عالٍ. التكميم العدواني يضر بشكل غير متناسب بالمهام طويلة الأفق والمنظمة ومنخفضة درجة الحرارة، وهي بالضبط أعباء العمل الوكيلية والبرمجية التي تبرر أصلاً استخدام نموذج متقدم. المتوسط بالكاد يتحرك، لكن الذيل ينهار.

الحل أن تكمم بقدر ما يتحمله اختبار مهمتك، لا بقدر ما تفرضه ذاكرة VRAM. شغّل مطالبات عبء عملك على نسخ FP8 و4 بت و3 بت وقارن بينها. إذا نجحت نسخة 3 بت في اختباراتك، فهنيئاً لك، فقد انخفضت فاتورة الأجهزة إلى النصف. وإذا فشلت، فلن ينقذك أي متوسط في المقاييس. وفضّل الإصدارات المكممة الأصلية عندما يطلقها المختبر، فقد نشرت Mistral نسخة NVFP4 إلى جانب أوزان BF16، وكمية رسمية مع فروق جودة مقاسة أفضل من تحويل GPTQ من المجتمع تحققت منه في بعد ظهيرة واحدة.

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

الخطأ الرابع: مقارنة سعر الـAPI بسعر وحدة معالجة الرسوميات وتسميته تحليل تكلفة الملكية

الجدول الكلاسيكي: «الـAPI يكلف 2.10 دولار لكل مليون رمز مخرج، وعقدة GPU محجوزة تكلف X دولاراً في الساعة، إذن الاستضافة الذاتية تُجدي عند Y رمز شهرياً». هذا الجدول خاطئ في الغالب، وخطؤه يصب في الاتجاه المكلف.

ما يغفله: الاستخدام. الـAPI يمنحك 100% من استخدام سعة شخص آخر، وتُحاسب بالرمز. أما مجموعتك المستضافة ذاتياً فتمنحك الاستخدام الذي يفرزه نمط حركة المرور لديك، ومعظم أعباء العمل الداخلية متقطعة: كثيفة خلال ساعات العمل، وخاملة ليلاً، ومتقلبة حول الإصدارات. مجموعة مُحجّمة للذروة تبقى نصف فارغة معظم اليوم. ثم تضاف تكاليف لا تظهر في الجدول أبداً: مناوبة للطوارئ لمكدس خدمة يتضمن الآن ترقيات vLLM وعدم تطابق تعريفات CUDA، والاستدعاء الساعة 2 فجراً عندما تتفتت ذاكرة KV cache؛ وضجيج تحديث النماذج (هل تعيد التحقق من كل إصدار أوزان جديد؟ مجموعة اختباراتك تقول نعم)؛ وتكلفة الفرصة البديلة للمهندس المتخصص في تعلم الآلة الذي صار مربيّاً لوحدات GPU بدلاً من بناء المنتج.

هناك أيضاً مشكلة الهدف المتحرك التي لا يسعّرها أحد. خفّضت Mistral سعر الـAPI لهذا النموذج بما يقارب النصف بين النسخة التجريبية والإصدار الكامل، إذ انتقلت رموز الإدخال من 1.36 دولار إلى 0.70 دولار لكل مليون. أي حساب عائد استثمار للاستضافة الذاتية أُجري على السعر القديم صار خيالاً الآن. الاستدلال المتقدم يصبح أرخص وفق إيقاع ربع سنوي، بينما تهبط قيمة أجهزتك وفق إيقاع متعدد السنوات. هذا التفاوت هو القاتل الصامت لحالات العمل الخاصة بالاستضافة الذاتية.

الحل: لا تستضف ذاتياً إلا لأسباب لا يستطيع الـAPI توفيرها بطبيعته. هذه الأسباب موجودة وحقيقية، لكن «أرخص عند الحجم الكبير» نادراً ما تكون واحدة منها عند الأحجام التي تعمل بها معظم الشركات فعلياً.

متى تنتصر الاستضافة الذاتية فعلاً

إذن متى يتفوق تشغيل أوزان من فئة Mistral محلياً على الـAPI؟ بعد مراقبة فرق نجحت وأخرى أخفقت، تتجمع الحالات الرابحة في أربع فئات:

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

لاحظ ما ليس في القائمة: زمن الاستجابة. استضافة نموذج MoE بتريليون معامل ذاتياً لن تمنحك زمن استجابة أقل من API جيد التجهيز، إلا إذا كنت مستعداً للإنفاق بسخاء على فك الترميز التخميني وخدمة مُحسّنة لطلب واحد. ولاحظ أيضاً ما ليس فيها: «تجنب الاعتماد على المزوّد». الأوزان التي تنزلها اليوم ستكون متأخرة بجيلين خلال عام، وستعود إلى نقطة القرار نفسها، وهذا بالمناسبة حجة جيدة لعادة الأرشفة التي يتبعها بعض المختصين، أي الاحتفاظ بنسخ محلية من إصدارات الأوزان المهمة. التخزين رخيص، والخيارات قيّمة.

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

الخطأ الخامس: التقييم بالمعايير العامة بدلاً من عبء عملك

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

تجيب المعايير العامة عن سؤال «هل هذا النموذج قادر بشكل عام؟». لكنها لا تجيب عن «هل يصنّف هذا النموذج تذاكر الدعم لدينا بالنبرة والتنسيق اللازمين، بدقة 4 بت، تحت حمل التزامن لدينا؟». كتبنا من قبل عن سبب إغفال معايير الذكاء الاصطناعي لـ90% من العمل الحقيقي، والاستضافة الذاتية تجعل الفجوة أوضح لا أخف: صرت مسؤولاً عن كل متغير كان مزود الـAPI يديره عنك. مكدس النشر، وإعدادات أداة أخذ العينات، وأعراف موجه النظام التي تدرّب عليها النموذج، كلها صارت مسؤوليتك وحدك لتخطئ فيها.

الحل هو تقييم من ثلاث طبقات تبنيه قبل الالتزام بالأجهزة:

1. مجموعة ذهبية من الإنتاج. بضع مئات من المطالبات الحقيقية مع مخرجات مثالية مُراجعة، تغطي توزيع مهامك الفعلي، بما في ذلك الحالات الطويلة والفوضوية متعددة الأدوار.
2. إطار اختبار الانحدار. كل مرشح (API مقابل محلي، وFP8 مقابل 4 بت، والأوزان القديمة مقابل الإصدار الجديد) يشغّل المجموعة الذهبية تلقائياً. قيّم بنموذج حكم قوي مع مراجعة بشرية عينية، ولا تثق بالحكم بشكل أعمى في المخرجات المنظمة.
3. فترة الظل. شغّل النشر المحلي جنباً إلى جنب مع الـAPI على حركة المرور الحية لمدة أسبوعين، وقارن المخرجات وقس زمن الاستجابة الفعلي تحت حمل حقيقي. هنا تظهر أخطاء تحجيم ذاكرة KV cache وإخفاقات ذيل التكميم فعلاً.

يسدد هذا الإطار تكلفته من أول مرة يصدر فيها إصدار أوزان جديد، فتستطيع الإجابة عن «هل نرقّي؟» بالبيانات خلال بعد ظهيرة واحدة، بدلاً من الاعتماد على الانطباعات في اجتماع.

الدرس الحقيقي: الأوزان المفتوحة غيّرت السؤال لا الجواب

قبل عام، كان سؤال «هل نستضيف نموذجاً متقدماً ذاتياً؟» افتراضياً، لأن النموذج المتقدم لم يكن قابلاً للتنزيل. وقد جعل Mistral Large 4، مع موجة نماذج تريليونية أخرى، منه قراراً حقيقياً بمال حقيقي. لكن إطار القرار لم يتغير، بل صار إلزامياً فحسب.

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