نحنُ مسؤولون.

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

اجتمعت مع الأخ من يومين وكان الهدف تحديد ميزات جديدة يريد إضافتها إلى المنصة لتسهيل الأمر عليه أكثر، وكان أحد الطلبات إضافة ميزة تشكيل التفريغات عند الطلب، ولكن لماذا نحن مسؤولون؟

إصرار المسلمين غير العرب والمسلمين الجدد على تعلّم الإسلام وإيجاد الطرق والأفكار لإنجاز هذا الهدف عظيم، ونحن كمسلمين "أصليين" (إن صحّت التسمية) لا نهتم لأمرهم كثيرا، فلا نهتم بتوفير منصة متكاملة لتعليم اللغة العربية، أو تسهيل بعض أمور العلم الشرعي عليهم، وهذا والله ثغر عظيم.

عموما، وبعد هذه المقدمة العاطفية، نعود للأمور التقنية.

مشروع تخرجّي من الجامعة كان هدفه بناء نموذج ذكاء اصطناعي لتشكيل النصوص العربية، والحمدلله أنجزنا المشروع ونشرنا عددا من النماذج والأوراق البحثية عن الأمر وكان إنجازا حقيقيا وقتها، وكان هذا بين عامي 2018 و2019.

فقررت إعادة استخدام النموذج ودمجه مع منصة باحث لتوفير الميزة التي طلبها الأخ، وكان هذا لأسباب منها:
- النماذج الجديدة تعتمد على معماريات معقدة تحتاج خادما قويا مثل Transformers.
- النموذج الخاص بنا تدرّب في غالبه على نصوص عربية فصيحة، وهذا أنسب لمتطلبات باحث.
- حجم النموذج صغير جدا، 30MB فقط.

فكان أمامي خياران، الأول بناء Service جديدة باستخدام FastAPI والتعامل معها من خلال API للتشكيل، وهذا الحل الأمثل والأكثر كفاءة، والثاني، وهو الذي طبّقته، استخدام مكتبة TensorFlowJS لتشكيل النصوص باستخدام النموذج على متصفح المستخدم مباشرة.

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

كل ما كان علي فعله هو تثبيت مكتبة tensorflowjs ثم تحويل النموذج المُنشأ باستخدام Keras (من 5 سنوات 😂) إلى JavaScript باستخدام الأمر التالي:

tensorflowjs_converter --input_format keras kera_model.h5 js_model

ثم رفعت ملفات النموذج المُحوّل (10MB بعد التحويل) إلى CloudFlare R2، وأنشأت Web Worker هدفه تحميل النموذج والتشكيل في Thread منفصلة عن الـ Thread الأساسية لـ JavaScript، يمكنك الاطلاع عليه من هنا وإعادة استخدامه:
https://baheth.ieasybooks.com/workers/diacritizationWorker.js

وأخيرًا، أضفت زرًّا في الواجهة يقوم باستخدام الـ Worker، دون إضافة جهد إضافيٍّ على خادم المنصة، كما هو موضّح في الصور المرفقة.

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

يمكنك الاطلاع على عملنا في التشكيل من خلال هذه المستودعات:
https://github.com/AliOsm/arabic-text-diacritization
https://github.com/AliOsm/shakkelha
https://github.com/AliOsm/shakkelha-website

والسلام عليكم 👋🏻

قليلٌ من التنظيف لن يضر 😁

الصفحة الأهم في منصة باحث هي صفحة عرض المواد (الدروس والمحاضرات)، وكما هو موضّح في الصورتين في الأسفل، طريقة عرض الصفحة وتجربة المستخدم تختلف حسب حجم شاشة المستخدم، فعلى الحاسب يُعرض كامل التفريغ على يسار المادة، وعلى الهاتف يُعرض التفريغ الحالي فقط أسفل المادة.

لتوفير هذه التجربة، كنت أُضيف الجزء الأيسر من الصفحة الخاص بالتفريغ ولكن أُخفيه على الهاتف، وأُضيف الجزء أسفل المادة وأُخفيه على الحاسب، فكان التفريغ يُضاف مرتين في الصفحة ويُعرض مرة واحدة، مما يتسبب في زيادة كبيرة في حجم الصفحة (نتمنى من الجميع ضبط النفس 😂).

البارحة فكّرت في فصل صفحة عرض المادة إلى صفحتين، الأولى تُعرض على الحاسب فقط، والثانية تعرض على الهاتف فقط.

إطار عمل Ruby on Rails يستخدم مكتبة browser بشكل افتراضي للتحقق من بعض ما يتعلّق بالمتصفحات، كإصدار المتصفح ونوع نظام التشغيل والجهاز الذي يعمل عليه، اعتمادًا على الـ User Agent، يمكنك الاطلاع على مكتبة browser من هنا:
https://github.com/fnando/browser

فمثلا، يمكنك كتابة browser.device.mobile?، للتحقق مما إذا كان الجهاز الذي يستخدمه المستخدم هو هاتف أم لا. بناءً على وجود هذه الميزة، أنشأت صفحتين جديدتين بدلا من الصفحة القديمة، وأصبحت أعرض كل صفحة بناء على جهاز المستخدم.

وماذا استفادت الأمة من هذا التعقيد الإضافي؟

اختبرت التعديل الجديد على 3 مواد من خلال Google Chrome Dev Tools وموقع DebugBear لمقارنة حجم الصفحات قبل وبعد التعديل.

المادة الأولى ومدتها 77 دقيقة، نزل حجم صفحتها من 55.1KB إلى 51.1KB حسب Google Chrome Dev Tools، وحسب موقع DebugBear نزل حجم الصفحة الكامل بعد الضغط من 71.1KB إلى 42.3KB.

المادة الثانية ومدتها 144 دقيقة، نزل حجم صفحتها من 117KB إلى 99KB حسب Google Chrome Dev Tools، وحسب موقع DebugBear نزل حجم الصفحة الكامل بعد الضغط من 150KB إلى 83.2KB.

المادة الأخيرة ومدتها 151 دقيقة، نزل حجم صفحتها من 111KB إلى 94.2KB حسب Google Chrome Dev Tools، وحسب موقع DebugBear نزل حجم الصفحة الكامل بعد الضغط من 143KB إلى 79.8KB.

هذا النزول الكبير في حجم الصفحات ينعكس على أمور عديدة منها تقليل الجهد المطلوب من الخادم بذله للاستجابة لطلبات المستخدمين وسرعة تنزيل الصفحة لدى المستخدم وسرعة معالجتها على المتصفح وعرض محتواها.

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

والسلام عليكم 👋🏻

مما يُعشَق في اللغة العربية الشعر، ومما يُعشَق في الشعر قصائد الزهد والتزكية، ومنها:
- نونية البُستي: https://youtu.be/yRu-P1Xz6bI
- لامية ابن الوردي: https://youtu.be/oWzo-SsqOVY
- تائية الإلبيري: https://youtu.be/HEYIcr8ODcI

وأغلب قصائد أبو العتاهية مثل:
- يسلم المرءَ أخوه: https://youtu.be/NAmc74KK7JI
- إن السلامة أن ترضى بما قضي: https://youtu.be/-bg5Ld09uW4

والشعرُ عامةً صديقٌ جيِّدٌ أثناء العمل، وفيه نوعٌ من التغيير. هو خيرٌ لك من الأغاني والموسيقى. فعلى أقل تقدير، ستتعلم كلماتٍ ومعانيَ جديدةً في اللغة العربية 😁

ما هي استعلامات س+1 أو N+1 Queries 🤔 (الإصرار على التعريب 😂)

تخيّل أن لديك مجموعة من قوائم التشغيل، وكل قائمة تشغيل تحتوي على مجموعة من المواد المرئية أو المسموعة، وأنت تريد عرض قوائم التشغيل في الصفحة وتريد عرض عدد المواد الموجودة في كل قائمة تشغيل.

الأمر سهل، نحتاج لإحضار قوائم التشغيل من قاعدة البيانات باستخدام الاستعلام التالي:

SELECT * FROM playlists ORDER BY created_at DESC

ثم لكل قائمة تشغيل منها نقوم باستخدام الاستعلام التالي لحساب عدد المواد الموجودة فيها:

SELECT COUNT(*) FROM media WHERE playlist_id = {playlist_id}

مبروك، هذه هي استعلامات س+1 🥳

البيانات الأساسية والمهمة موجودة في الاستعلام الأول، ولكن احتجت للقيام باستعلام ثانٍ لكل صف من الصفوف القادمة من الاستعلام الأول لحساب عدد المواد، فأنت نفّذت استعلاما واحدًا (1) واحتجت بعده لـ (س) من الاستعلامات، وهكذا أصبحت س+1.

وتطبيقات هذا الأمر كثيرة، ولا تقف عند المثال المذكور، ولكن كيف نحل المشكلة في هذا المثال؟

في Ruby on Rails الأمر سهل جدا، تحتاج لإضافة عمود جديد في جدول قوائم التشغيل باسم media_count، وعند تعريف العلاقة بين قوائم التشغيل والمواد يمكنك إضافة الخيار counter_cache: true كما هو موضّح في الصورة.

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

تسمى هذه الميزة باسم Counter Cache وهي تعمل على العلاقات المباشرة فقط، أما إذا أردت استخدامها على العلاقات المُتعدّية، فستحتاج لاستخدام مكتبة counter_culture:
https://github.com/magnusvk/counter_culture

وبسبب شيوع هذا الخطأ في أُطر العمل المختلفة لسهولة التواصل مع قاعدة البيانات باستخدام الـ ORMs، يوجد أدوات كثيرة لاكتشاف هذا النوع من الأخطاء والتعامل معها كمكتبة bullet المختصة في تتبع هذا النوع من الاستعلامات وتنبيهك عليها:
https://github.com/flyerhzm/bullet

ومكتبة goldiloader التي تحاول حل المشكلة من جذورها من خلال جلب البيانات الإضافية المطلوبة من قاعدة البيانات في استعلام واحد، بدلا من مجرد تنبيهك:
https://github.com/salsify/goldiloader

والسلام عليكم 👋🏻

يقول أحدهم: "النوايا الحسنة لا تعمل، الآليات هي التي تعمل" أو "Good intentions don't work. Mechanisms do".

عندما نقلت منصة باحث من استخدام قوالب ERb الخاصة بإطار عمل Ruby on Rails لبناء الواجهات إلى مكتبة Phlex قررت أن لا أضيف أي ملفات ERb إلى المشروع مرة أخرى، ولكن "النوايا الحسنة لا تعمل" 😁

فكّرت قليلا، فقررت إضافة GitHub Action يتأكد أن عدد ملفات ERb لم يزد في الـ PR الجديدة مقارنة بالحالة الحالية للمستودع، مع استثناء الملفات المنتهية بـ turbo_stream.erb لأن Phlex لا تقدم لها حلا إلى الآن.

وفعلا كتبت الـ GitHub Action المرفق في الصورة (بمساعدة ChatGPT 🥹) وأضفته إلى المستودع وأثبتت الأيام أن "الآليات هي التي تعمل" 😎

نستفيد أمران من هذه القصة:
- حاول استغلال GitHub Actions طالما أنهم مجانيين
- أول سطر في المنشور

وأخيرا، إذا كنت تتساءل عن ما هي الـ GitHub Actions، فمن المهم أن تقرأ عنها وتتعلمها ✌🏻

والسلام عليكم 👋🏻

إنما السيل اجتماع النُّقط 🌊

من 30 يوما، تحديدا يوم 26/12/2024، اتخذت قرارًا دون سابق تخطيطٍ أو ترتيب، أن أنشر منشورًا تقنيًّا واحدًا يوميًّا لمدة 30 يوما على قبيلة و LinkedIn، ثم دخل Telegram على الساحة، والبارحة كان اليوم الأخير ولله الحمد.

ماذا استفدت من هذه التجربة؟

- عرضَيْ عمل 😁
- شاركت جزءًا كبيرا من تجربتي في تطوير منصة باحث وباقي المشاريع التي أعمل عليها
- تعرّفت على أكثر من 15 صديقًا جديدًا (تحدثنا فعليًّا)
- بدأت التعاون مع 6 أشخاص لتطوير منصة باحث بشكل أكبر في نواحٍ مختلفة
- أكثر من 5 اجتماعات إلى الآن ضمن هذا التعاون والعدد يزداد
- كتبت نصف المنشورات تقريبا باللغة الفصحى، مع ركاكتها ولكن ستتحسن بمرور الوقت بإذن الله 🥹
- أكثر من 17 ألف ظهور للمنشورات على قبيلة وأكثر من 125 ألف على LinkedIn
- أكثر من 250 مشاهدة للملف الشخصي على قبيلة وأكثر من 1,150 على LinkedIn
- زيادة بنسبة 35% في عدد المتابعين على LinkedIn

أسأل الله أن يجعل هذا العمل خالصًا لوجهه الكريم، وأشجّع الجميع على مشاركة تجاربهم "العملية" لنشر الفائدة.

نستمر بإذن الله، والسلام عليكم 👋🏻

يقول رسولنا صلى الله عليه وسلم: "أَحَبُّ الأعمالِ إلى اللهِ أدْومُها وإن قَلَّ"، وعندما سُئلت عائشة رضي الله عنها: "هلْ كانَ رَسولُ اللَّهِ صَلَّى اللهُ عليه وسلَّمَ يَخْتَصُّ مِنَ الأيَّامِ شيئًا؟"، قالت: "لَا، كانَ عَمَلُهُ دِيمَةً، وأَيُّكُمْ يُطِيقُ ما كانَ رَسولُ اللَّهِ صَلَّى اللهُ عليه وسلَّمَ يُطِيقُ"، وحسب موقع الدرر السنِيَّة: "الدِّيمةُ في الأصلِ: المطَرُ المُستمِرُّ مع سُكونٍ بلا رَعْدٍ ولا بَرْقٍ، ثمَّ استُعمِلَ في غَيرِه؛ شَبَّهَت عَمَلَه في دَوامِه مع الاقتصادِ بدِيمةِ المَطَرِ".

يظنُّ البعض أن الأعمال عامة تنتج فجأةً دون سابق توفيق من الله وعمل طويل ومداومة عليه، فالناس ترى من أعمال الآخرين ومشاريعهم الثمرة الأخيرة، ولكن لا يعلمون ما كان خلف ذلك من بذل للوقت والجهد، ومرة أخرى "المداومة".

بدأت تفريغ مواد منصة باحث في شهر 5 من سنة 2023، وأُطلقت المنصة في شهر 7 من نفس السنة. خلال هذه الفترة فرَّغت ما يقارب الـ 7,000 ساعة لـ 19 متحدِّثًا، الشهر الأول 2,130 والشهر الثاني 3,471 والشهر الثالث 1,401.

بعد إطلاق المنصة، كان التعليق المُرفق في الصورة من أوائل التعليقات التي وصلت اعتراضًا على محتوى المنصة وكيف أنه قليل ولا يُغطِّي العدد الكافي من المتحدِّثين، مع العلم أن الأخ صاحب التعليق لم يفهم فكرة المنصة جيدًّا قبل كتابة التعليق.

بعد ذلك مرّت الأيام والأسابيع والأشهر وكانت إضافة المواد مستمرة، كل شهرٍ بحسبه، فأحيانا أكثر من 10 آلاف أو 15 ألف ساعة، وأحيانا أقل من ألف ساعة في الشهر، وأحيانا أنقطع تماما لبعض الظروف كالذي حصل في شهر 10 من سنة 2023 أو شهرَيْ 3 و 4 من سنة 2024.

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

فالآن وبعد ما يقارب السنة والنصف من التفريغ، اقترب عدد المتحدثين على المنصة من 200 متحدث، وعدد الساعات تجاوز الـ 110 ألف ساعة ولله الحمد.

داوم على الأعمال ولو مع تقلُّبٍ وعدم استقرار في الكفاءة، فهذا طبيعيٌّ في الخط الأزرق، ولكنك ستلاحظ أو خطك الأحمر دائما في ازدياد وتحسُّن بإذن الله.

والسلام عليكم 👋🏻

أهمية الاختبارات 😅

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

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

بعد ذلك طلب مني صديقي الذي تحدثت عنه في هذا المنشور:
https://t.me/programmerskhan/57

طلب تجميع العلامات المرجعية الخاصة بكل قائمة تشغيل في جدول منفصل، ليسهل تتبع العلامات المرجعية بناءً على قوائم التشغيل، وبالفعل انتهيت من ذلك بتاريخ 15/11/2024.

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

بدأت صباح اليوم في العمل على هذا التعديل، وخلال العمل اكتشفت المفاجأة 😀

بدايةً، كيف أقوم بتجميع بيانات هذه الصفحة؟

في باحث يوجد جدول لقوائم التشغيل (playlists) وجدول للمواد (media) وجدول للتفريغات (cues). قوائم التشغيل تمتلك العديد من المواد والمواد تمتلك العديد من التفريغات. والعكس كذلك، فكل تفريغ ينتمي لمادة وكل مادة تنتمي لقائمة تشغيل.

عندما يقوم المستخدم بإضافة علامة مرجعية جديدة، أقوم بإضافة صفٍّ في جدول يربط المستخدمين بالتفريغات (cue_bookmarks)، وعندما يُزيل العلامة المرجعية أحذف الصف من الجدول.

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

ثم انتقلت للواجهة لترتيب العلامات المرجعية الخاصة بكل قائمة تشغيل بناء على وقت الإنشاء، بدلا من الترتيب القديم الذي كان يعتمد على المُعرّف الخاص بالمادة ووقت بداية التفريغ نفسه، ولكن لم أرتح للسطر المكتوب وأنا أقرأه 😂

عدّلت السطر كما هو موضّح في الصورة الثانية ليستخدم created_at: :desc بدلا من 'cues.medium_id, cues.start_time'، ثم راجعت السطر مِرارا لأكتشفت أنني أعرض بيانات كل المستخدمين لكل المستخدمين 🥳

وبالتجربة اكتشفت أن حدسي في محلّه، فإذا قمت بإضافة علامة مرجعية واحدة إلى أي قائمة تشغيل، ستستطيع رؤية كل العلامات المرجعية الأخرى التي وضعها باقي المستخدمين على نفس القائمة، ولكن، ولله الحمد، دون أن تعرف من هو المستخدم 😁

فقمت بإضافة where(user: current_user) لتحديد العلامات المرجعية التي يجب إظهارها والتي تخص المستخدم الحالي فقط والحمدلله حُلّت المشكلة.

ماذا نستفيد؟

لا تستعجل في تنفيذ طلبات أصدقاءك، واختبر تعديلاتك الجديدة جيدا على أكثر من حساب بأكثر من صلاحية ✌🏻

والسلام عليكم 👋🏻

هل من الممكن تشغيل DeepSeek v3 على المعالج والذاكرة الخاصة به دون وجود معالجات رسومية (GPUs) أبدا؟

الجواب نعم، ولكن!

لدي وصول إلى جهاز بذاكرة بحجم 374GB و 48 معالجًا، فجربت تشغيل نموذج DeepSeek v3 والذي يبلغ حجمه 671 مليار مُعامل عليه من خلال Ollama كالتالي:

ollama run deepseek-v3

وكم كنت بريئًا 😂

أول ما ظهر على الشاشة بعد تنزيل النموذج كان تنبيها من Ollama يقول أن الذاكرة غير كافية لتشغيل النموذج. نعم، 374GB غير كافية 😁

لم يكن هناك أي Swap على هذا الجهاز، فأضفت 75GB إلى الـ Swap وأعدت تشغيل نفس الأمر من Ollama، فبدأت الذاكرة تمتلئ بالنموذج.

استغرق الأمر ما يقارب 20 دقيقة حتى انتهت Ollama من تحميل النموذج على الذاكرة، ثم كتبت "Hi"، فرد علي بعد 3 دقائق تقريبا "?Hello, how I can help you today"، وانتهت المحادثة وأغلقت الجهاز وعدت لما كنت أقوم به 😂

فالجواب نعم، ولكنه سيكون بطيئًا جدا.

ملاحظة: لا أدري إن كان سبب البطئ الشديد هو استخدامي للـ Swap، ولكن لم يكن لدي أي حلول.

نشرت البارحة منشورًا أُشارك فيه تجربتي في تشغيل DeepSeek v3 على جهاز لا يحتوي على أي معالجات رسومية (GPUs)، يمكنك قراءته من هنا:
https://t.me/programmerskhan/77

اليوم قررت تجربة نماذج DeepSeek R1 المُقطّرة (Distilled) من نموذج DeepSeek R1 الأصلي بحجم 671 مليار مُعامل على نفس الجهاز.

تأتي النماذج المُقطّرة بأحجام 1.5 مليار و 7 مليارات و 8 مليارات و 14 مليارًا و 32 مليارًا و 70 مليار مُعامل.

بحثت في أمر اختبار النماذج ووجدت أكثر من مكتبة تقوم بهذا الأمر كمكتبة ollama-benchmark:
https://github.com/aidatatools/ollama-benchmark

فهمت كيف تعمل باستخدام Ollama وكتبت Script قصير يقوم بنفس الأمر ولكن على نماذج DeepSeek R1 المذكورة، يمكنك الاطلاع على الـ Script وتفاصيل الاختبار من هنا:
https://github.com/AliOsm/deepseek-r1-cpu-bench

كما هو موضّح في الصورة المرفقة، استطاع الجهاز إنتاج ما يقارب الـ 50 رمزا (Token) في الثانية باستخدام النموذج الأصغر، مقارنة بأكبر النماذج الذي استطاع الجهاز إنتاج ما يقارب الـ 2.2 رمزا في الثانية باستخدامه.

كما أن استهلاك الذاكرة كان يتراوح بين 1.4GB و 42.3GB من النموذج الأصغر إلى الأكبر.

الجميل أن الجهاز استطاع إنتاج ما يقارب الـ 15.5 رمزا في الثانية باستخدام نموذج 8 مليارات مُعامل مُستهلكًا 5.7GB من الذاكرة، وهو رقم جيد للاستخدام الشخصي أو لمعالجة البيانات على فترات طويلة (لدي صبر كبير على هذه الأمور 😂).

استخدمت 11 رسالة (Prompt) في الاختبار، تنقسم إلى 3 مجموعات:
- المحادثة (1)
- الأوامر (5)
- الأسئلة والأجوبة (5)

كل هذه الرسائل استعرتها من مكتبة ollama-benchmark 😁

والسلام عليكم 👋🏻