خطآن برمجيان كانا متخفيين في وضح النهار: قصة تحرٍّ في إصلاح أخطاء vLLM — أساف غاردين ويوفال بيلفر
AAI Engineer
Computing/SoftwareInternet Technology
Transcript
00:00:00إذاً، تضع نموذجك في مكان ما، وتضع عميلك، وتأمل في أفضل النتائج،
00:00:24وتنتظر أن يحدث عطل ما، وكل شيء يبدو جيداً، وكل شيء على ما يرام.
00:00:29ثم ترى هذا.
00:00:33وهذه هي المشكلة، أليس كذلك، في هذا النوع من الأخطاء.
00:00:37لا يوجد تعطل، ولا يوجد تحذير، ولا خطأ، وهناك ثقة عالية.
00:00:43هذه ليست مشكلة جودة.
00:00:46لأن هذا شيئاً لا تعرف حقاً ماهيته ولا سببه.
00:00:53أهلاً بك في هذه المحاضرة. اسمي يوفال. وهذا آصاف.
00:00:58معاً، سنأخذكم في رحلة حول كيفية انتهائنا إلى إصلاح هذا النوع من الأخطاء.
00:01:04نبذة بسيطة عنا.
00:01:06نعمل في AI21، وهي مختبر لأبحاث الذكاء الاصطناعي.
00:01:10بدأنا كشركة نماذج تأسيسية، ونشتهر أكثر بنموذج Jamba، وهو بنية هجينة بين محولات المحولات (Transformers) وMamba، وهي حالة مساحة الحالة (SSM).
00:01:22وبينما كنا نقوم بذلك، وبينما كنا ندرّب تلك النماذج، وبينما كنا نشحن تلك النماذج إلى بيئة الإنتاج وكان لدينا مستخدمون وعبء عمل، واجهنا العديد من الأخطاء المثيرة للاهتمام.
00:01:36وهذه هي الأخطاء التي أعتقد أنها الأصعب في التعامل معها.
00:01:41لأن هذه ليست مشكلة جودة.
00:01:43وليست شيئاً يمكنك جعل فريق البحث لديك يحاول تحسينه أو حله أو جعل النموذج أفضل فيه.
00:01:53إذن، هذه مشكلة هندسية. هذه مشكلة توجد فيها ثقة عالية، ولكن النتيجة سيئة.
00:02:02لذا، دعونا نتعمق في الحالة الأولى، ما نسميه الطلب الدخيل، حيث لتهيئة الموقف، عما نتحدث؟
00:02:12نحن نتحدث عن كيف قمنا، أثناء تدريب نموذج Jamba الخاص بنا، وبشكل أكثر تحديداً، بإجراء GRPO، وهو نوع من التدريب بالتعزيز (RL).
00:02:22وكما ذكرت، هذا نموذج هجين.
00:02:24طبقات من Mamba والاهتمام (Attention).
00:02:27وفقط للتأكد من أننا جميعا على متفقون، ما هو شكل الطلب؟
00:02:31إذاً، دورة حياة الطلب.
00:02:34إذن، نبدأ بالنص التوجيهي (Prompt)، والترميز (Tokenization)، ثم في مرحلة التمرير الأمامي (Forward Pass)، نقوم بكل من التعبئة المسبقة (Prefill) ثم فك التشفير (Decode).
00:02:44بعد ذلك، ننتهي من التمرير الأمامي، وإلغاء الترميز (Detokenization) للعودة إلى النص.
00:02:51والأمر السيء في هذه الجريمة هو أنها سيئة على مستويات عديدة، ولكن بشكل رئيسي على هذه المستويات الثلاثة.
00:02:59هذا ما نسميه هراء واحد في الألف.
00:03:01إنه ليس شيئاً سيحدث في أول 500 أو 900 طلب، ولكنه سيحدث في الطلب الألف.
00:03:09وهو نادر بما يكفي لعدم تكراره بسهولة، ولكنه ليس، أليس كذلك، شائع جداً بحيث لا يمكن شحنه.
00:03:18عذراً.
00:03:19أيضاً، حدث ذلك فقط في VLLM، وليس في أي إطار عمل استدلال آخر.
00:03:26وهو شيء متأخر الظهور.
00:03:28إنه ليس شيئاً سيحدث إذا كان لديك عدد قليل فقط من الطلبات.
00:03:32أنت بحاجة إلى نوع من عبء العمل.
00:03:34لذا فهو نادر.
00:03:35وهو متأخر الظهور.
00:03:36وهو خاص جداً بالمحرك.
00:03:38إنها مهمة صعبة للغاية، وكان علينا جلب أحد أفضل محققينا للتعامل مع ذلك.
00:03:43لذا، سأترك الكلمة لآصاف ليشرح الكيفية.
00:03:47حسناً.
00:03:48أهلاً بكم يا شباب.
00:03:48شكراً لك يا يوفال.
00:03:49شكراً يا يوفال.
00:03:50إذن، سنبدأ بمحاولة إعادة إنتاج شيء كان من الصعب جداً إعادة إنتاجه.
00:03:55وبشكل أساسي، يحتوي VLLM على الكثير من العلامات، والكثير من علامات واجهةs سطر الأوامر (CLI)، والكثير من الخيارات التي يمكنكم تدويرها وتعديلها.
00:04:04وواحد من الأمور التي ساعدتنا في فهم كيفية إعادة إنتاجه حتى، لأنه عندما حاولنا إعادة إنتاجه للمرة الأولى، فقط بإرسال نصوص توجيهية هنا وهناك، وبضع دفعات، لم يساعدنا ذلك حقاً في نجاحنا في استعادة كلام غير مفهوم من نموذجنا.
00:04:17استجاب النموذج بشكل جيد تماماً.
00:04:19لذا، ما فعلناه هو أننا حاولنا جعله يحدث في وقت قصير جداً جداً.
00:04:25حتى نحصل على حلقة تعليقات سريعة عندما نحول تصحيح أخطائه.
00:04:29لذا، ما فعلناه هو أننا أخذنا واحدة من أكثر العلامات افتراضية وشيوعاً التي يتيح لك VLLM اللعب بها، وهي استخدام ذاكرة وحدة معالجة الرسوميات (GPU memory utilization)، والتي تتيح لك أساساً اختيار مقدار ذاكرة وحدة معالجة الرسوميات التي تريد تخصيصها لأوزانك، وتنشيطاتك، وذاكرة التخزين المؤقت KV، وما إلى ذلك.
00:04:48وقمنا بخفضها من 90% إلى 20%.
00:04:51وبمجرد قيامنا بذلك، ثم بدأنا في تشغيل الكثير من الطلبات في وقت واحد، وفجأة، عاد الطلب رقم، لنقل 854، فجأة بكلام غير مفهوم.
00:05:05وعندما فعلنا ذلك، أخذنا عينات من جميع الدفعات بدرجة حرارة صفر، لكي نتمكن بشكل حتمي ومستمر من جعل نفس الطلب يعود ويستجيب بكلام غير مفهوم.
00:05:17لذا، مثلما قال يوفال، حدث ذلك فقط في VLLM.
00:05:20واستخدمنا، من أجل، طريقة أخرى لإعادة إنتاجه وفهم مصدر المشكلة حقاً، استخدمنا مكتبة Transformers من Hugging Face كخط أساس، نظراً لأن Transformers تحتوي، وكان لديها تطبيق قياسي وبسيط جداً لنواة Mamba الخاصة بنا، على عكس VLLM، حيث مرت جميع النواة وجميع المحرك بالكثير من التغييرات والتعديلات لدعم الكثير من الميزات الرائعة.
00:05:46لذا، استخدمنا Transformers كخط أساس لنا لنفهم ما إذا كانت هناك مشكلة في الاستدلال لدينا أم لا، مع النموذج أم لا.
00:05:55لذا، ما فعلناه هو أننا أخذنا VLLM وأرسلنا جميع نصوصنا التوجيهية من خلال VLLM وقومنا بتوليد استجابة، جميع الاستجابات.
00:06:02حصلنا، والآن بين أيدينا الاستجابة جنباً إلى جنب مع الاحتمالات اللوغاريتمية (log probs)، لأنه في VLLM يمكنك إخراج احتمالاتك اللوغاريتمية وفحصها.
00:06:11ثم ما فعلناه هو أننا أخذنا التسلسل الكامل، النص التوجيهي والتوليد، ومررناه إلى عملية التمرير الأمامي لـ Hugging Face.
00:06:20ولكن كل ما فعلناه هو تشغيل التعبئة المسبقة فقط، ثم أخذنا المخرجات (logits) من استجابة التعبئة المسبقة، ومررناها عبر دالة Softmax، ومن ثم تمكنا من مقارنة الانحراف في توزيعات الرموز (tokens) الخاصة بنا.
00:06:38هذا رمز برمجي زائف (pseudocode) قصير لما بدا عليه الأمر.
00:06:41يمكنك أن ترى هنا أننا نأخذ النص التوجيهي، ونقوم بتشغيله من خلال دالة التوليد في VLLM، ونحصل على الاستجابة مرة أخرى جنباً إلى جنب مع الاحتمالات اللوغاريتمية، ونمررها إلى عملية التمرير الأمامي لـ Hugging Face، ونقوم بتشغيلها فقط باستخدام التعبئة المسبقة.
00:06:55أنشأنا دالة ما تسمى حساب الاحتمالات اللوغاريتمية (compute log probs)، والتي تشغل Softmax، ثم تحسب الفرق بينهم، وبعد ذلك ستكون قادراً على معرفة الانحراف بين الاحتمالات اللوغاريتمية لكل رمز من الرموز.
00:07:09حسناً، الآن بعد أن أصبحت الأدوات بين أيدينا لنفهم من أين قد تأتي المشكلة ربما، بدأنا في النظر إلى مشتبه بهم مختلفين في محرك VLLM.
00:07:19لذا فإن أول شيء نظرنا إليه هو نواة التعبئة المسبقة لـ CUDA الخاصة بـ Mamba.
00:07:24نظرنا إليها، وفحصنا كل الرياضيات التي تتم هناك، ونظرنا إلى الموتر الداخل، والمواتر الخارجة قبل استدعاء التعبئة المسبقة وبعدها.
00:07:36كل شيء بدا على ما يرام.
00:07:38الشيء الثاني الذي فعلناه هو تشغيل أداة معقم الحوسبة (compute sanitizer) الخاصة بـ NVIDIA لنرى حقاً ما إذا كان لدينا أي ذاكرة خارج الحدود، أو أي أخطاء أو مشاكل أخرى في الذاكرة.
00:07:48بدا الأمر لي جيداً.
00:07:52ثم ما فعلناه هو أننا حاولنا الفصل بين نواة فك التشفير ونواة التعبئة المسبقة.
00:07:56الآن، رأينا أن نواة التعبئة المسبقة كانت تعمل بشكل جيد تماماً، لذلك حاولنا عدم استدعاء نواة فك التشفير، لأنه في Mamba يمكنك القيام بذلك.
00:08:03لذا، ما فعلناه هو أننا نقلنا جميع استدعاءاتنا وجميع حساباتنا لتمر عبر نواة التعبئة المسبقة، وهناك تجد الأمر.
00:08:12الكلام غير المفهوم اختفى فجأة نوعاً ما.
00:08:14لذلك قلنا، حسناً، لابد أن الأمر متعلق بنواة فك التشفير.
00:08:18لكنكم تعرفون كيف يكون الأمر في البرمجيات.
00:08:20أنت تحمس بسرعة كبيرة، ثم تكتشف أن هذا ليس ما حدث.
00:08:24لذا، ما فعلناه هو أننا حاولنا البدء في اللعب بمحرك VLLM، وكنا بحاجة نوعاً ما للذهاب، كما تعلمون، لرفع الغطاء ومعرفة ما يمكننا فعله ربما للحصول على فهم أفضل وربما، كما تعلمون، لتوسيع خبرتنا.
00:08:38لأن VLLM لم يمنحنا حقاً المزيد من الأدوات لتصحيح أخطاء نواتنا ومرورنا الأمامي حقاً.
00:08:45لذا بمجرد أن يصل الموتر، وبمجرد أن يصل الطلب طوال الطريق إلى مرورك الأمامي، وقبل أن يدخل في نواتي التعبئة المسبقة وفك التشفير لديك، ليس لديهم أي هوية حقاً.
00:08:55لا يمكنك حقاً معرفة النص التوجيهي الذي تتم معالجته حالياً.
00:08:59الأمر كله مجرد مواتر وأرقام ومصفوفات.
00:09:02لذا، ما فعلناه هو أننا أضفنا معرف الطلب (request ID) إلى فئة ما تسمى سياق التمرير (forward context) والتي قمنا بنشرها طوال الطريق وصولاً إلى التمرير الأمامي لـ Mamba قبل استدعاء نواتي التعبئة المسبقة وفك التشفير مباشرة.
00:09:16وهناك تمكنا فقط، كما تعلمون، من الحصول على شرط if بسيط مع معرف الطلب، وهو الذي أعطانا كلاماً غير مفهوم، ووضع نقطة توقف (breakpoint) هناك.
00:09:26وبعد ذلك تمكنا من الاستنتاج وفحص جميع البيانات الوصفية التي تأتي معها حقاً.
00:09:33وفي اللحظة التي فعلنا فيها ذلك، رأينا أن الطلب كان، للمرة الأولى، عندما مر عبر التمرير الأمامي، ي実は يقوم بفك التشفير قبل التعبئة المسبقة.
00:09:43قرر المجدول (scheduler) أن هذا الطلب يجب أن يقوم بفك التشفير قبل التعبئة المسبقة.
00:09:50وكما قال يوفال في وقت سابق، في دورة حياة النص التوجيهي، يجب أن يمر النص التوجيهي أولاً عبر التعبئة المسبقة ثم فك التشفير.
00:10:00وما حدث هو أنه عندما تقوم في Mamba بتشغيل طلب مع فك التشفير أولاً، بعد أن تم حساب الكثير من الطلبات الأخرى بالفعل، كانت الحالة قد استُخدمت بإفراط نوعاً ما.
00:10:15وكنا نستخدم بيانات وحسابات الطلبات القديمة، والطلبات التي جاءت قبله.
00:10:21لذا كنا في الواقع نقوم بتشغيل فك التشفير على الطلبات السابقة.
00:10:25وقد أدى ذلك إلى توليد كلام غير مفهوم بالنسبة لنا.
00:10:28لذا لم تكن النواة تفعل الشيء الخاطئ.
00:10:30لقد تم استدعاؤها في الوقت الخطأ للطلبات الخطأ.
00:10:34والآن -- ولماذا كان هذا مهمًا فقط بالنسبة لـ Mamba؟
00:10:37السبب وراء ذلك هو أنه في آلية الانتهاء (Attention)، عندما تكتب رموز KV -- أنت تكتب رموز KVs قبل أن تقرأها فعليًا.
00:10:47لذا، حتى لو كان لديك بيانات قديمة، يتم الكتابة فوقها.
00:10:50ولكن بالنسبة لـ Mamba، كما قلت، عندما تمر عبر نواة فك التشفير لأول مرة، فإنك تقرأ الحالة أولاً، ثم تحسب بناءً عليها.
00:10:58لذا، ما حدث هو أنك استخدمت بيانات قديمة فقط عندما تقوم بفك التشفير.
00:11:05وكان الإصلاح بسيطا نسبيًا.
00:11:07كنا بحاجة فقط للتأكد من أن ما نقوم به هو أنه عندما يقوم الطلب لأول مرة -- عندما يصنف المجدول الطلب لأول مرة، عليه التأكد من أنه يضبط -- أنه إذا رأيت الطلب الذي لم يتم حساب رموزه من قبل، وكانت صفراً،
00:11:26أن يتم وضع علامة عليها كـ تعبئة مسبقة (prefill)، بحيث عندما تصل إلى التمرير الأمامي، يتم استخدامها بالفعل للتعبئة المسبقة فقط وليس لفك التشفير، وليس كجزئية.
00:11:38يمكنك أن ترى أنه تم دمج هذا التعديل بعد مرور بعض الوقت.
00:11:41وهذا يقودنا حقًا -- وبعد ذلك اعتقدنا أن كل شيء قد تم إصلاحه، أليس كذلك؟
00:11:45اعتقدنا أن كل شيء تم إصلاحه، وها هو ذا.
00:11:47لا مزيد من المشاكل.
00:11:48ولكن كان هذا هو الحال تقريبًا، لأنه بعد مرور وقت قليل، يقودنا ذلك إلى الحالة رقم اثنين،
00:11:54والتي أظهرت مشكلة أخرى واجهناها في التدريب بالتعزيز (RL)، وفي الاستدلال لدينا.
00:12:01لذا قمنا بتشغيل التعزيز، وأثناء تشغيلنا للتدريبات وتدريبات ما بعد التدريب، ونظرنا إلى تقييماتنا وجميع معاييرنا،
00:12:10اعتقدنا أن لدينا بعض قمم الاحتمالات اللوغاريتمية بين مرحلة التنفيذ وخطوة FSDP.
00:12:15وكان ذلك قبل أي تحديث للأوزان.
00:12:18إذن بعض الأوزان، ونفس المدخلات، ويجب أن تكون الاحتمالات اللوغاريتمية متطابقة.
00:12:23لكنها لم تكن كذلك.
00:12:24لاحظنا أنه كل 12 خطوة باستمرار، كانت هناك قمة في الاحتمالات اللوغاريتمية، وكان ذلك أمراً غريباً بعض الشيء.
00:12:33والآن، ماذا كنتم ستفعلون أيها الشباب؟
00:12:36ما هو أول شيء يجب القيام به هنا؟
00:12:39لذا أردنا إيجاد طريقة لتغيير كيفية حدوث الأخطاء وليس فقط حجم تلك الأخطاء.
00:12:44أردنا معرفة مدى - أردنا تعديل بعض العوامل التي لا تقتصر على إخبارنا بأن هذا الخطأ سيئ للغاية، أو أنه يحدث بعدد معين من المرات، وما إلى ذلك.
00:12:57ولذا أردنا تعديل بعض العوامل التي تخبرنا بطريقة ما أنه بمجرد تعديلها، نفهم كيف ترتبط بأي شيء في محرك VLM.
00:13:08وبالتالي سنكون قادرين على الذهاب وتصحيح هذا الجزء المحدد بدقة.
00:13:14تلك صورة ساخرة رائعة أردتم جميعا إضافتها.
00:13:19لذا ما قمنا به هو أننا قررنا زيادة عدد عمليات التنفيذ لكل مطالبة.
00:13:26بما أننا رأينا في محرك التعزيز الافتراضي لدينا ثماني عمليات تنفيذ لكل مطالبة، ورأينا أنها تحدث بشكل حتمي كل 12 خطوة، قررنا: حسناً، لنحاول تعديل الأمر قليلاً وزيادة عدد عمليات التنفيذ لكل مطالبة.
00:13:40لذا بدأنا بمضاعفتها من 8 إلى 16 ثم 64، 32، و128.
00:13:45ويمكنكم أن تروا هنا أن الأمر يكاد يكون - يكاد يكون - هناك نمط هنا.
00:13:51كلما زادناه، كلما حدث بشكل أسرع، لأن ما أردنا تحقيقه هنا هو محاولة إعادة إنتاج المشكلة بأسرع ما يمكن ليكون لدينا حلقة تصحيح وحلقة تغذية مرتدة أسرع.
00:14:05لذا عندما شغّلناها بـ 128 عملية تنفيذ لكل مطالبة، حدثت المشكلة فوراً في الخطوة الأولى، ولم نضطر للانتظار حتى الخطوة 12 و24 وما إلى ذلك.
00:14:12الآن، قد تفكرون، حسناً، لقد عبثتم بنسبة استخدام ذاكرة وحدة معالجة الرسوميات من قبل.
00:14:18لقد قمتم بتعديلها، وقومتم بتقليلها.
00:14:20يبدو أنك عندما تختبر تحت الضغط، فإن ذلك يبرز الأمور حقاً.
00:14:24لذا اعتقدنا ذلك أيضاً.
00:14:26وعندما خفضنا ذاكرة وحدة معالجة الرسوميات من 0.9 إلى 0.2، تسبب ذلك في اختفاء المشكلة بالفعل.
00:14:35لذا فقد قمنا بجذب الذراع الخاطئة هنا.
00:14:38والسبب في ذلك هو أننا لاحظنا أن ومضات مامبا تستخدم مؤشر فهرس صحيح غير سالبة سعة 32 بت.
00:14:48لذا بمجرد أن تجاوزت الإزاحة حوالي 4 مليارات رقم، عادت للالتفاف من الصفر بدلاً من إطلاق خطأ.
00:14:55لذا عندما قلصنا ذاكرة وحدة معالجة الرسوميات، خصصت VLM مخزناً مؤقتاً للحالة صغيراً، ولم يصبح فهرس التخزين المؤقت كبيراً بما يكفي للوصول إلى تلك الخانة.
00:15:04لذا لم نكن نصل إلى مدى بعيد بما يكفي لكي يتسبب المخزن المؤقت في تجاوز الحد.
00:15:09لذا، مرة أخرى، كان الإصلاح بسيطاً نسبياً.
00:15:13كل ما احتجنا إلى فعله هو تغيير كلمة واحدة، متغير نوع بيانات واحد من UINT32 إلى size_t، مما يعني أساساً لمعظم البنى الحديثة، بنيات الأجهزة،
00:15:27أن size_t سيعني أنه سيتم تغييره الآن إلى صحيح غير سالبة سعة 64 بت.
00:15:32وهذا رقم كبير جداً.
00:15:34لم نصل إلى هذا الرقم أبداً، ولم يحدث تجاوز السعة هذا مرة أخرى.
00:15:38لذا ما يمكننا رؤيته هنا هو أنه كان لدينا مشهدان ومجرم واحد.
00:15:45كلاهما كان، كما تعلمون، له أعراض متشابهة.
00:15:48كلاهما عانى من هراء صامت وقمم احتمالات لوغاريتمية صامتة، والتي كانت تولد أيضاً بعض الهراء أحياناً.
00:15:55كلاهما كان يتعلق بذاكرة التخزين المؤقت لحالة مامبا.
00:15:57وكلاهما برزا بسبب ضغط الذاكرة، سواء كان ذلك للأسوأ أو للأفضل.
00:16:03وكلاهما تم اكتشافهما عبر التحقيق الجنائي للاحتمالات اللوغاريتمية.
00:16:09أنظمة الاستدلال ذات الحالة لا تفشل بصخب.
00:16:12بل تكذب عليك بثقة.
00:16:13أقصد، من الواضح أنه في بعض الأحيان يحدث تعطل.
00:16:15تحصل على أخطاء تجاوز النطاق.
00:16:16تحصل على استثناءات أخرى، كما تعلمون، وما إلى ذلك.
00:16:19ولكن في بعض الأحيان تكون هناك بعض الأخطاء التي لا تظهر على السطح، ولا تحصل على سجل تتبع.
00:16:24أنت لا تحصل على أي شيء.
00:16:25عليك أن تبحث وتحفر لتفهم سبب حدوث الأمور.
00:16:29لذا، إذا كانت هناك بعض الدروس المستفادة من هذا العرض التقديمي، فهي: قم ببناء نص برمجي لمقارنة الاحتمالات اللوغاريتمية.
00:16:36إذا كنت بحاجة إلى مقارنة الجودة الخاصة بك، فأنت بحاجة إلى مقارنتها لفهم ما إذا كنت قد قمت بنمذجة المشكلات أم لا.
00:16:41إن النص البرمجي لمقارنة الاحتمالات اللوغاريتمية مع خط أساس من إطار عمل استدلال آخر تملكه أو قمت ببنائه هو أمر رائع دائماً.
00:16:48أعد الإنتاج تحت الضغط والذاكرة المحدودة، وارفض النطاق، والعب بالعوامل الأخرى التي يمنحها لك إطار عمل الاستدلال وحاول حقاً فهم مصدر المشكلة.
00:16:59ابحث عن ما يحرك شكل الفشل، والتوقيت، والمساحة، والموقع.
00:17:05وعندما لا تمتلك الأشياء هوية حقاً، قم بتمرير الهوية عبر الخيوط.
00:17:10وما أود منك أن تأخذه من هذا أيضاً، ولا تخف حتى، كما تعلمون، بالنسبة للأنظمة المعقدة مثل VLLM أو أي إطار عمل معقد آخر، لا تخف من التعمق في الكود وتوسيخ يديك.
00:17:23في بعض الأحيان، كما تعلمون، نماذج اللغات، قد تخبرك النماذج اللغوية الكبيرة كيف تعمل الأمور، ولكن، كما تعلمون، دون أن تراها بعينيك وتوسخ يديك، لن تحصل على فهم كامل لما يجري.
00:17:34شكراً لكم، يمكنكم إضافتنا على لينكد إن، امسحوا رمز الاستجابة السريعة لقراءة المدونة الفعلية التي نشرناها مع هذا الاكتشاف.
00:17:43نعم، هذا كل شيء.
00:18:04نراكم في المرة القادمة.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video