إزاي Cerebras بتشغّل موديل 3 تريليون parameter؟ الحسبة بالأرقام

موديل فيه حوالي 3 تريليون parameter محتاج terabytes علشان يشيل الأوزان بس، وفي نفس الوقت رقاقة Cerebras الواحدة فيها 44 GB ذاكرة. طب إزاي بيشغّلوه وبسرعة كمان؟ Cerebras نشرت يوم 22 أكتوبر 2026 مقال بيشرح الحسبة خطوة بخطوة، وده ملخصه بالعربي مع رأيي.

المثال: Kimi K3

Cerebras استخدمت Kimi K3 كمثال توضيحي: موديل open source حوالي 3T parameter، فيه 93 طبقة: 69 طبقة linear-attention و 24 طبقة dense.

والافتراضات اللي بنوا عليها الحسبة:

• متوسط حجم الطلب 256k token
• الأوزان بـ 4-bit quantization
• الـ KV cache بـ 8-bit

الخطوة 1: حجم كل طبقة

لو الـ 3T parameter متخزنين بـ 4 bits، يبقى الأوزان لوحدها حوالي 1.5 TB. لما تقسمهم على 93 طبقة، كل طبقة بتطلع حوالي 16 GB.

الخطوة 2: كام رقاقة؟

هنا الفرق بين نوعين الطبقات:

• الطبقات الـ dense محتاجة مكان زيادة للـ KV cache، لأنها بتخزن الـ keys والـ values لكل token في كل طلب شغال. علشان كده بيحطوا طبقة dense واحدة في كل رقاقة والباقي من الـ SRAM للـ KV cache.
• الطبقات الـ linear-attention مش محتاجة KV cache بيكبر مع طول الـ context، كل طلب ليه state صغيرة وثابتة. فبيحطوا طبقتين linear في الرقاقة (2 × 16 = 32 GB).

النتيجة:

• الطبقات الـ linear: 69 طبقة على 35 رقاقة
• الطبقات الـ dense: 24 طبقة على 24 رقاقة
• المجموع: 59 رقاقة

الخطوة 3: توصيل الرقاقات

Cerebras بتشغّل الموديل كـ pipeline. بما إن الطبقة (16 GB) بتدخل كاملة في رقاقة (44 GB)، الأوزان في الغالب مش بتتحرك خالص. اللي بيتنقل بين الرقاقات هو الـ activations بس، عن طريق RDMA over Ethernet، وده بياخد حوالي 2 microseconds لكل نقلة.

الخطوة 4: طلبات كتير في نفس الوقت

فيه سوء فهم شائع: لو الـ token لازم يعدي على كل رقاقة بالترتيب، يبقى كل رقاقة قاعدة مستنية دورها؟ الإجابة لأ.

كل رقاقة مرحلة في خط إنتاج. وهي شغالة على token لطلب A، اللي قبلها شغالة على طلب B، واللي قبلها على طلب C. وكمان كل مرحلة ممكن تشتغل على micro-batch صغير بدل طلب واحد:

• micro-batch أصغر يعني كل طلب أسرع
• micro-batch أكبر يعني throughput إجمالي أعلى

وفي الـ production، Cerebras بتقول إنها بتستخدم مراحل أصغر بكتير وأكتر من "طبقة لكل مرحلة".

الخطوة 5: إيه اللي بيحدد عدد المستخدمين؟

الحد الأقصى لعدد الطلبات اللي شغالة مع بعض بيحدده حجم الـ KV cache اللي فاضل في رقاقات الـ dense، لأن كل طلب محتاج KV cache خاص بيه على كل رقاقة dense.

وده الدرس المهم لينا كـ devs حتى لو عمرنا ما هنلمس hardware زي ده: الـ context الطويل غالي لأنه بياكل KV cache، وده بيقلل عدد الناس اللي يتخدموا في نفس اللحظة.

أرقام Cerebras عن نفسها

Cerebras بتقول إن الطريقة دي بتخليها تشغّل موديلات multi-trillion بسرعة 1000 لـ 2000+ token في الثانية. خلي بالك إن ده رقم الشركة نفسها مش قياس مستقل.

رأيي

أكتر حاجة عجبتني في المقال إنهم هم نفسهم قالوا إن الـ concurrency والـ batch size مش هما المقياس الصح للمقارنة، وإن الأهم هو tokens في الثانية لكل megawatt عند نفس سرعة التوليد. ده مقياس عادل أكتر لما تقارن أي inference provider بغيره.

ولو بتبني coding agents أو أي حاجة بتبعت context طويل، افتكر الحسبة دي: كل token زيادة في الـ prompt ليه تمن في الذاكرة، مش في الفاتورة بس.

المصادر

• Cerebras: How we deploy trillion-parameter frontier models on Cerebras