Bitrix24 تشرح ما تبنيه حول نموذجها اللغوي الخاص بحجم 1 تريليون معامل

قالت Bitrix24 في Saint HighLoad++ إن المرحلة الحقيقية تبدأ بعد عبارة «نشرنا نموذجنا اللغوي LLM الخاص» بحجم 1 تريليون معامل. فأوزان هذا النموذج وحدها تشغل نحو 1 تيرابايت حتى بصيغة FP8، أي ما يقارب خادمًا كاملًا بثماني وحدات GPU. وعلى العتاد نفسه تعمل في الوقت ذاته الدردشات ومعالجة المستندات الطويلة والوكلاء. ويقتصر إعلان Habr على عرض المسألة فقط، أما التفاصيل ففي المقال الكامل. وفيما يلي تحليل للأسئلة الهندسية الكامنة وراءها.

أين ينتهي «البسيط»

الحسابات هنا صارمة. يزن المعامل الواحد بصيغة FP8 بايتًا واحدًا، ما يعني أن نموذجًا بحجم 1 تريليون معامل يحتاج إلى نحو 1 تيرابايت من الذاكرة قبل أول طلب. وبصيغة BF16 يصل الرقم إلى نحو 2 تيرابايت، وبصيغة 4 بت إلى نحو 0,5 تيرابايت. توفر ثماني وحدات H200 ما مجموعه 1128 غيغابايت من ذاكرة HBM، فتكاد عقدة واحدة تكفي لأوزان FP8، ولا يبقى لذاكرة KV-cache سوى القليل جدًا. لذلك تصطدم المنصة حتمًا تقريبًا بالحاجة إلى التوزيع على عدة عقد وإلى توفير الذاكرة.

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

ثلاثة أحمال على وحدات GPU نفسها

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

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

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

التحسينات وخطر التدهور الصامت

السؤال الثالث هو الأكثر إزعاجًا. فالتكميم (quantization) وتخزين البادئات مؤقتًا والفك التخميني (speculative decoding) والتغييرات في التجميع الدفعي (batching) تسرّع النظام، لكنها قد تضعف الإجابات دون أن يلحظ أحد. لا يتعطل الخدمة بسبب الخطأ، ولا يظهر في مقاييس زمن التأخر. يخلط النموذج الوقائع أكثر قليلًا، أو يلتزم بصيغة استدعاء الأدوات بدرجة أقل. وهذا حرج للوكلاء: فبنية JSON واحدة معطوبة تُفسد السلسلة كلها.

الطريقة الوحيدة لاكتشاف ذلك هي تشغيل مجموعة ثابتة من المهام قبل كل تغيير وبعده ومقارنة النتائج. ويجب أن تضم المجموعة سيناريوهات المنتج الفعلية: السياق الطويل واستدعاء الدوال واللغة الروسية. أما المعايير العامة (benchmarks) فتكاد لا تفيد هنا.

ما يجب التحقق منه قبل الإطلاق

من يفكر في نموذج كبير خاص به، عليه أن يراجع قائمة قصيرة:

• حساب الذاكرة: الأوزان، وKV-cache عند طول السياق الفعلي، وهامش لفترات الذروة.
• تقسيم الحركة إلى فئات والاتفاق مسبقًا على الفئة التي يجوز تأخيرها.
• تحديد ما سيملأ أوقات الخمول، وكيف تُقاطَع تلك المهام.
• بناء مجموعة تقييم جودة خاصة قبل أول تحسين، لا بعده.
• قياس ليس متوسط السرعة فقط، بل أيضًا ذيول التأخر: p95 وp99 للدردشات، والإنتاجية للوكلاء.

والفكرة المحورية في المداخلة أن نموذجًا لغويًا خاصًا بحجم 1 تريليون معامل هو منصة متكاملة بمُجدوِل وطوابير ونظام لمراقبة الجودة، لا نموذج واحد على خادم. أما أرقام الأحمال الفعلية وإعدادات العنقود فتكشفها Bitrix24 في النسخة الكاملة من المادة على Habr.