الإعلان عن Humming: أنوية سريعة ومرنة للاستدلال الكمّي

تفتح Ant Group ومجتمع vLLM مصدر Humming، وهي مكتبة أنوية عالية الأداء متعددة الأغراض للاستدلال الكمّي. تقدّم Humming الميزات التالية:

• دعم واسع للأجهزة: يدعم معماريات وحدات معالجة الرسومية NVIDIA بدءًا من Turing وما بعدها، إلى جانب أجهزة متوافقة مع CUDA مثل Zhenwu 810E من T-Head.
• دعم واسع للكمّنة: بنية موحّدة تدعم تنوّعًا من التوليفات بين صيغ الأوزان والتفعيلات لأحمال العمل الكثيفة وأحمال MoE، وتغطي مجموعة واسعة من الأنواع الصحيحة والعشرية (الفاصلة العائمة) وعرضات البت ومخططات القياس (التحجيم).
• أداء تنفيذ قوي: يتفوق بشكل ملحوظ على التنفيذات الحالية من vLLM Marlin وFlashInfer وDeepGEMM عبر العديد من أحمال العمل التمثيلية.

المستودع: github.com/vllm-project/humming

الخلفية

مع نمو النماذج وأحمال عمل الاستدلال، تصبح سعة الذاكرة وعرض نطاق الذاكرة وتكاليف الحوسبة قيودًا متزايدة على النشر. ويتضح هذا بشكل خاص في نماذج MoE: حيث يُفعِّل كل رمز (token) مجموعة فرعية فقط من الخبراء، ولكن لا يزال يتعين تخزين كامل مجموعة الأوزان. على سبيل المثال، يمتلك DeepSeek-V3 معاملات يبلغ عددها 671 مليار، مع تفعيل 37 مليارًا لكل رمز. تخفض الكمّنة دقة الأوزان والتفعيلات لتقليل استخدام الذاكرة وحركة البيانات، ويمكنها أيضًا تحسين كفاءة الحوسبة.

تختلف متطلبات الكمّنة باختلاف النماذج وأجيال وحدات معالجة الرسومية. تشمل التكوينات الشائعة WNA16 وW8A8 وW4A8 وW4A4، حيث يحدد W وA عرضات بت الوزن والتفعيل، وN يشير إلى عرض بت وزن متغير. وحتى عند نفس الدقة، تختلف مخططات مثل INT4 وNVFP4 في الصيغة العددية والتحجيم. وتعمل دقة التحجيم وتمثيل عامل القياس وحجم المجموعة والكمّنة المتماثلة أو غير المتماثلة على توسيع فضاء التكوينات أكثر.

لا تتحول هذه التوفيرات في التخزين والحوسبة إلى زمن استجابة أقل وإنتاجية أعلى إلا باستخدام أنوية فعّالة. تفرض مرحلتي التعبئة المسبقة (prefill) وفك التشفير (decode) وأحمال خبراء MoE المتغيرة متطلبات مختلفة على الحوسبة والذاكرة. ويجب أن تتكيف الأنوية مع هذه الأحمال مع إبقاء تكاليف التحويل وإزالة الكمّنة والجدولة منخفضة.

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

تعالج Humming هذه المشكلة بفصل وصف الكمّنة عن خيارات التنفيذ، وبناء الأنوية من مكونات مشتركة.

بنية متعددة الأغراض

يتكون مسار التنفيذ في Humming من ثلاثة أجزاء: تمثيل الحساب الكمّي، واختيار التكوينات المناسبة للجهاز وحمل العمل، وتجميع النواة من مكونات CUDA.

تمثيل كمّن موحّد

تختلف النماذج المُصدَّرة من أدوات الكمّنة المختلفة في الصيغة العددية وتنظيم المعاملات وتخطيط الأوزان. تحوّل Humming صيغ التصدير المدعومة إلى الصيغة القياسية لـ Humming: وصف كمّن مشترك مع أوزان وعوامل قياس ونقاط صفرة (zero points) وموترات أخرى منظمة بشكل متسق.

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

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

الضبط والتجمع الفوري (JIT) لكل حمل عمل

توفر الصيغة القياسية تمثيلًا مشتركًا عبر صيغ التصدير. ثم تقوم المعالجة المسبقة بالتحقق من المعاملات وحشو الأبعاد (padding) وإعادة تجميع هذه الموترات في تخطيطات مناسبة للنواة المستهدفة. تجمع Humming وصف الكمّنة مع شكل الوزن ونوع GEMM ووحدة معالجة الرسومية المستهدفة وخيارات الحساب لتكوين التنفيذ.

تصف ثلاثة تكوينات النواة:

• تكوين الطبقة (Layer Config) يصف أشكال الموترات وأنواع البيانات ومعاملات الكمّنة والمعمارية المستهدفة.
• تكوين الحساب (Compute Config) يحدد نوع GEMM وخيارات الحساب، مثل ثبات الدُفعة (batch invariance) وتخطيط مقياس المدخلات.
• تكوين الضبط (Tuning Config) يختار أشكال البلاطات، وعدد مراحل الأنبوب، وتخصص الـ warp، والوصول إلى الذاكرة، وتعليمات MMA. كما يتحكم في التزامن والجدولة؛ ويمكن تكوين TMA لكل موتر على حدة.

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

تجعل البنية الموحّدة في Humming من السهل ضبط معاملات التنفيذ واختيار المسارات (pipelines) لأحمال عمل مختلفة. عند أحجام الدفعات الصغيرة، يستخدم مسار متعدد المراحل نسخًا غير متزامنة (cp.async) ويمكن لـ MMA أن تتفوق على مسار معالجة مبني حول TMA وUMMA. عند أحجام الدفعات الأكبر، يمكن لـ TMA وUMMA أن توفرا إنتاجية أفضل. يستوعب Humming مساري التنفيذ كليهما ضمن نفس إطار التكوين والمكونات، مما يسمح له باختيار الاستراتيجية الأكثر فعالية لكل عبء عمل.

تتخصص الإعدادات الثلاثة مجتمعةً في النوى البرمجية المجمَّعة باستخدام NVRTC أو NVCC. تُخزَّن النوى المجمَّعة مؤقتًا لإعادة استخدامها. يجمع الاستدلال النواة المختارة مع الأوزان المعالجة مسبقًا والتنشيطات في زمن التشغيل.

مكونات CUDA مشتركة عبر الصيغ والمعماريات

على مستوى CUDA، ينظّم Humming جدولة المهام ونقل البيانات وإزالة التكميم والقياس وحسابات Tensor Core ومعالجة المخرجات في مكونات قابلة لإعادة الاستخدام. يوفر خطوط أنابيب قياسية ومتخصصة على مستوى الـ warp وخطوط UMMA مخصصة. تتشارك هذه الخطوط مكونات متوافقة مع استخدام تدفق البيانات والمزامنة التي يتطلبها كل أسلوب تنفيذ.

تتولى كل مجموعة من المكونات مصدرًا مختلفًا للتنوع:

• المعالجة الرقمية تتولى صيغ التكميم. تأخذ مكونات فك الترميز والحساب في الاعتبار عرض البت وتمثيل الأعداد الصحيحة أو الفاصلة العائمة والمقاييس ونقاط الصفر. يتم دمج إزالة التكميم والقياس في حساب النواة.
• تتولى واجهات الذاكرة والحساب الخلفية بنى GPU. يختار Humming تطبيقات نقل البيانات وTensor Core للبنية المستهدفة، مستخدمًا النسخ غير المتزامن وTMA والبث المتعدد حيثما كان مدعومًا.
• تتولى تعيين المهام والجدولة أعباء العمل الكثيفة وMoE. يستخدم كل نوع GEMM منطق الجدولة المناسب. كما يمكن دمج القياس وإضافة الانحياز في مرحلة الإخراج.

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

هذه التنفيذات CUDA خفيفة وتتجنب الاعتماد على أطر النوى الثقيلة، مما يحافظ أيضًا على سرعة ترجمة JIT. في اختبارنا لترجمة نواة W4A16 واحدة على خادم H200 مزود بـ CUDA 13.4، انخفض زمن الترجمة من 23.35 ثانية لـ CUTLASS مع NVCC إلى 1.82 ثانية لـ Humming مع NVCC أو 1.88 ثانية مع NVRTC، مع تعطيل ذاكرة التخزين المؤقت للترجمة. هذا يقلل من تكلفة تجهيز النوى لأعباء العمل الجديدة ويجعل الضبط التكراري أكثر عملية. كما يقوم Humming بترجمة النوى على التوازي أثناء تهيئة النموذج. في اختباراتنا، تستغرق ترجمة وتحميل النوى التي تغطي جميع أحجام M المدعومة لعملية GEMM لطبقة واحدة حوالي 2–4 ثوانٍ فقط، مما يجعل من العملي تجهيز عدة نوى متخصصة قبل الاستدلال.

ضبط الأداء بناءً على معلمات الجهاز

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

استدلال W4A8-MXFP4 فعّال على وحدات GPU الحالية. تفتقر البنى السابقة لـ Blackwell إلى دعم أصلي لـ Tensor Core بصيغة MXFP4، وقد تتأثر نوى W4A8-MXFP4 التقليدية بعبء إزالة التكميم والقياس عند قيم M الأكبر. يعالج Humming ذلك بمسار سريع لإزالة تكميم MXFP4 إلى INT8/FP8 يحوّل أوزان MXFP4 إلى صيغة حساب مدعومة داخل النواة. في هذا السياق، يتفوق هذا المسار بشكل كبير على تطبيقات W4A8 التقليدية عند قيم M الصغيرة ويقترب من أداء W8A8 عند قيم M الكبيرة. لذلك يمكن لوحدات GPU مثل H200 تشغيل نوى W4A8-MXFP4 عالية الأداء مع الاحتفاظ بفوائد تخزين الأوزان بدقة 4 بت.

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

ضوابط ضبط واسعة مع استدلالات خاصة بكل جهاز. يكشف Humming عن أشكال البلاطات وعدد مراحل خط الأنابيب وتخصص الـ warp وTMA وتعليمات MMA وتزامن CTA وجدولة Stream-K. تجمع الاستدلالات الخاصة بالأجهزة بين أشكال GEMM وقيود الموارد لموازنة التوازي وإعادة استخدام البيانات وعبء خط الأنابيب، مختارةً استراتيجيات تنفيذ مختلفة مع تغير أحجام المدخلات. يمكن للمطورين استخدام التهيئات الافتراضية مباشرة أو تحسينها لنماذج وسيناريوهات نشر محددة.

النتائج

دعم واسع للأجهزة

تتيح بنية Humming الموحدة دعمًا واسعًا لوحدات GPU. بالنسبة لوحدات NVIDIA، يدعم Humming بشكل كامل كل بنية من Turing فصاعدًا، مقدّمًا إطار حساب مُكمّمًا موحدًا لأجيال متعددة من العتاد.

تجعل بنية JIT الموحدة أيضًا توسيع Humming إلى وحدات GPU أخرى متوافقة مع برمجة CUDA أمرًا مباشرًا. يدعم Humming بالفعل بشكل كامل Zhenwu 810E من T-Head، ناقلًا نواه المشتركة وقدرات الضبط إلى منصات عتاد أكثر.

يوضح الشكل أدناه أنواع التنشيط عالية الأداء التي يدعمها Humming على كل جهاز: الأنواع التي يمكنها استغلال قدرات الحساب القصوى للجهاز بشكل كامل. لا تزال بعض الأنواع غير المذكورة في الشكل قابلة للتشغيل عبر مسارات تعليمات أخرى. على سبيل المثال، لم تعد تعليمات UMMA على B300 (SM103) تدعم حساب INT8، لكن تعليمات MMA السابقة يمكنها مع ذلك تنفيذ GEMM بصيغة INT8، بأداء أقل بشكل ملحوظ.

دعم التكميم

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

يوضح الشكل أدناه توليفات أنواع الأوزان والتنشيط المدعومة من Humming. تمثل الصفوف أنواع الأوزان، وتمثل الأعمدة أنواع التنشيط، وتشير علامات الصح إلى التوليفات المدعومة. إلى جانب مصفوفة دعم الأجهزة أعلاه، يحدد هذا المسارات عالية الأداء للحساب المُكمَّم المتاحة على كل بنية عتاد.

يدعم Humming أيضًا تنسيقًا خاصًا للفاصلة العائمة بأس صفري، تتطابق قيمه القابلة للتمثيل مع قيم الأعداد الصحيحة المتماثلة عند نفس عرض البت. على سبيل المثال، INT8 باستثناء -128 و float8e0m7 يمثل كلاهما أعدادًا صحيحة من -127 إلى 127. الأوزان بهذا التنسيق تتمتع بنفس توافق نوع التفعيلات مثل أوزان INT ذات عرض البت نفسه. يحوّل Humming تلقائيًا أوزان الأعداد الصحيحة المتماثلة المؤهلة إلى هذا التنسيق لإزالة تكميم أسرع.

كما اكتشفت المجتمع قدرتين خفيتين في أنوية Blackwell Tensor: دعم أصلي لـ float4e0m3 و float8e3m4، وهما تنسيقان خاصان للفاصلة العائمة غير مكشوفين في نظام أنواع PTX. يدعم Humming هذه الميزات عبر جميع معماريات Blackwell، بما في ذلك أجهزة SM100/SM103 لمراكز البيانات وأجهزة SM120/SM121 لمحطات العمل والحوسبة الشخصية. كلا التنسيقين مدمجان في إطارها الموحد للتكميم والحساب، ما يوفر خيارات حساب أصليّة أكثر للاستدلال منخفض الدقة. لا يدعم Rubin هذين التنسيقين الخفيين في Tensor Core، لذا لا يمتد دعم مسارات الحساب الأصلية هذه إلى Rubin.

الأداء

اختبارات الأداء الدقيقة للنوى أدناه، التي أجراها مجتمع vLLM، تقيس أداء GEMM مع قيم M تغطي كل قوة من قوى العدد اثنين من 1 إلى 8192. يتم تسخين النوى بالكامل وتوقيتها بشكل مستقل مع ذاكرة تخزين مؤقت L2 باردة، مع توقف قصير بين العينات. تسريعات MoE تستخدم مجموع زمني تأخير GEMM لـ Gateup وDown. يحدد كل شكل خط الأساس وتنسيقات التكميم وأبعاد المصفوفات وإصدارات البرامج لديه.

WnA16

يُعد WnA16 أحد أكثر أساليب الاستدلال المُكمّم تنوعًا وشيوعًا في الاستخدام. فهو يجمع أوزانًا منخفضة البت مع تفعيلات FP16/BF16، ما يقلل تخزين الأوزان وحركة مرور الذاكرة مع الاستفادة من قدرات الحوسبة شائعة التوفر بدقة 16 بت. هذا يجعله مناسبًا للعديد من أجيال وحدات معالجة الرسومات وسيناريوهات نشر النماذج. وقد جذبت عائلة W4A16 اهتمامًا خاصًا من المجتمع وهي محور رئيسي لأعمال التحسين في Humming.

بالنسبة إلى W4A16 الكثيف، يطابق Humming أداء vLLM Marlin أو يتجاوزه في معظم التكوينات المختبرة، مع مكاسب كبيرة في عدة أحمال عمل على Hopper وBlackwell. يستخدم الشكل أدناه cuBLAS كخط أساس مشترك. عند أحجام الدفعات الصغيرة، يحقق Humming تسريعات تقارب 3–4× على عدة أجهزة. ومع نمو حجم الدفعة، يستمر في استخدام العتاد بكفاءة، ليصل إلى ضعف أداء Marlin تقريبًا في أحمال عمل H200 ذات الدفعات الكبيرة، وأكثر من ثلاثة أضعاف أدائه في بعض حالات B300.

تمتد هذه المكاسب إلى MoE. يوفر Humming مسارات Indexed وGrouped فعّالة لأحمال العمل التي توزَّع فيها الرموز على الخبراء ويتغير حجم العمل لكل خبير مع الحمل. في الشكل أدناه، يصل MXFP4 W4A16 على H20 وH200 إلى ضعف أداء Marlin تقريبًا في عدة حالات دفعات متوسطة إلى كبيرة. على B300، تحقق مساري MXINT4 وNVFP4 مكاسب أكبر عند أحجام الدفعات الكبيرة، مع وصول مسار Grouped إلى نحو 5×. كما تُظهر النتائج على SM120 وSM121 تفوق Humming على Marlin وتنفيذات FlashInfer المقابلة عبر مجموعة من أحمال العمل.

تمتد تحسينات Humming أيضًا إلى ما هو أبعد من W4A16 إلى تركيبات WnA16 أخرى. توفر مساراتها المشتركة لإزالة التكميم والحوسبة أداءً قويًا للأوزان الصحيحة وأوزان الفاصلة العائمة عند عروض بت مختلفة، بما في ذلك INT1 وINT2 وINT3 وFP4 حتى FP8. يُظهر الشكل التالي مكاسب واسعة عبر هذه التنسيقات عند أحجام الدفعات الصغيرة والمتوسطة، مع تجاوز التكوينات ذات أدنى بت على SM120 أداء 5× من BF16 cuBLAS. عند أحجام الدفعات الكبيرة على H20، تحافظ عروض بت متعددة على كفاءة حساب قريبة من BF16 cuBLAS. يمنح هذا النماذج خيارات أدق بين الدقة والتخزين والإنتاجية.

W8A8 / W4A8 / W4A4

مع Hopper، أصبح FP8 W8A8 مع القياس الكتلي (blockwise scaling) نهجًا رئيسيًا للاستدلال المُكمّم عالي الأداء. يحسّن Humming مسار الحساب الراسخ هذا بشكل أكبر من خلال تحسين حركة البيانات والقياس وجدولة الخبراء معًا. يُظهر العمود الأيسر أدناه نتائج W8A8 على H20 وH200. عند أحجام الدفعات الصغيرة والمتوسطة، يحقق Humming أداءً يقارب 2.6× و2.5× أداء DeepGEMM Contiguous على التوالي، مع أداء تنافسي من تخطيطي Indexed وGrouped معًا.

مع تبني المزيد من النماذج تكميم أوزان MXFP4 الأصلي، تزداد قيمة تحويل بصمة الأوزان الأصغر إلى مكاسب عملية في الاستدلال. يعالج Humming ذلك بمسار W4A8 فعّال يزيل تكميم أوزان MXFP4 بسرعة أثناء تحميلها ويستخدم أنوية FP8 Tensor للحساب، مما يتيح تنفيذ W4A8-MXFP4 فعّالًا على Hopper. يحافظ العمود الأيمن أعلاه على DeepGEMM W8A8 كخط أساس. عند أحجام الدفعات الصغيرة والمتوسطة، يحقق W4A8 من Humming أداءً يقارب 4.2× خط الأساس على H20 و4.5× على H200، كما يتفوق بشكل كبير على نتائج W8A8 من Humming في الشكل نفسه. انخفاض حركة الأوزان يترجم إلى زمن تأخير أقل لـ GEMM. كما أن FlashInfer CUTLASS W4A8 هو تنفيذ قائم على نهج Humming، بينما يحقق التنفيذ الحالي من Humming أداءً أفضل في الاختبارات المعروضة هنا.

يضيف Blackwell دعمًا أصليًا من أنوية Tensor لتنسيقات microscaling مثل MXFP8 وMXFP4. من أجهزة SM100/SM103 لمراكز البيانات إلى أجهزة SM120/SM121 لمحطات العمل والحوسبة الشخصية، يستخدم Humming قدرات الحوسبة منخفضة الدقة لكل معمارية لدعم W8A8 وW4A8 وW4A4 داخل نواة واحدة وإطار ضبط واحد.

على B300 (SM103)، يُظهر Humming مكاسب أداء كبيرة عبر جميع تركيبات صيغة MX الثلاث. تستخدم كل لوحة أدناه DeepGEMM Contiguous بالدقة المقابلة كخط أساس لها. عند أحجام الدفعات الصغيرة والمتوسطة، يحقق W8A8 وW4A8 وW4A4 ما يقارب 1.25× و1.6× و1.4× من أداء الخط الأساس على التوالي، ويتفوق على تطبيقات FlashInfer المقابلة عبر أعباء عمل كثيرة. تستفيد كل من مساري Indexed وGrouped من الحساب الأصلي منخفض الدقة، مما يوفر خيارات فعالة لتخطيطات الخبراء المختلفة.

تمتد هذه المكاسب أيضًا إلى SM120 وSM121. في النتائج أدناه، يتفوق Humming's MXFP4 × MXFP8 W4A8 وNVFP4 × NVFP4 W4A4 على FlashInfer CUTLASS عند معظم النقاط المختبرة. على SM121 عند أحجام الدفعات الصغيرة، تصل مكاسب الأداء إلى حوالي 19% لـ W4A8 و9% لـ W4A4؛ وعلى SM120، يتصدر Humming أيضًا عبر معظم الأحجام المختبرة. تجلب البنية الموحدة هذه التحسينات الاستدلالية منخفضة الدقة إلى المزيد من الأجهزة، مما يوسع الحساب الكمي الفعال إلى ما وراء مراكز البيانات.

أداء الاستدلال من البداية إلى النهاية

تمتد مكاسب W4A8 في Humming إلى خدمة النماذج. في اختبارنا لـ DeepSeek-V4.1-Flash على ثماني وحدات H20 GPUs مع TP=8، أدى الإبقاء على أوزان MXFP4 للنموذج دون تغيير والتحول من تنفيذ MoE بـ Marlin W4A16 (تفعيلات BF16) إلى Humming W4A8 (تفعيلات FP8 على مستوى الرمز) إلى تحسين الإنتاجية من البداية إلى النهاية بنسبة تقارب 14%–43% وتقليل متوسط زمن أول رمز (TTFT) بنسبة تقارب 25%–32%. وتزداد ميزة الإنتاجية مع التزامن: عند التزامن 64، يرتفع إنتاجية الإخراج من 442.37 إلى 633.94 رمزًا/ثانية، بينما ينخفض متوسط الزمن لكل رمز إخراج (TPOT) بنسبة تقارب 31%.

الاستخدام

التثبيت

ثبّت Humming باستخدام pip:

pip install humming-kernels

يستخدم Humming مترجم CUDA لتوليد النوى (kernels) عند الطلب. إذا لم يتوفر مترجم CUDA على النظام، اختر أحد خيارات التثبيت التالية لتضمين تبعيات الترجمة لإصدار CUDA الرئيسي الخاص ببيئتك:

pip install "humming-kernels[cu12]"  # CUDA 12
pip install "humming-kernels[cu13]"  # CUDA 13

إن Humming نفسه خفيف الوزن للغاية، بتبعيات بسيطة وحزمة wheel لا تتجاوز 500 KB تقريبًا. الترجمة عند الطلب تتجنب تجميع مجموعة كبيرة من النوى المترجمة مسبقًا. من حيث المبدأ، أي بيئة قادرة على تشغيل PyTorch 2.7 يمكنها أيضًا تشغيل Humming، مما يسهل دمجه في بيئات الاستدلال القائمة.

استخدام Humming في vLLM

Humming مدمج بعمق في vLLM. بدءًا من vLLM 0.29.0، تتضمن تثبيتات CUDA الحصول على Humming كتبعية، لذا لا حاجة لتثبيت Humming منفصلًا. يدعم Humming وحدات معالجة الرسومات من NVIDIA عبر جميع البنى من Turing وما بعدها (SM75 وأعلى).

الخيار --linear-backend و --moe-backend يحدّد Humming كمحرك حساب لـ GEMM الكثيف و GEMM لـ MoE على التوالي. على سبيل المثال، لتفعيل Humming لكليهما مع حجم توازٍ للموترات (tensor parallel) قدره 8:

vllm serve deepseek-ai/DeepSeek-V4.1-Flash-1017 \
    --tensor-parallel-size 8 \
    --linear-backend humming --moe-backend humming

يعتبر --quantization humming هذا الخيار مخصصًا فقط كمسار توافق للصيغ التي يدعمها Humming لكن vLLM لم تعد تدعمها أو لا تدعمها أصلًا بعد، مثل GPTQ INT3. على سبيل المثال، يمكن تحميل نقطة تحقق GPTQ INT3 عبر مسار التوافق هذا:

vllm serve hfl/Qwen2.5-VL-3B-Instruct-GPTQ-Int3 --quantization humming

اختيار أنواع التنشيط

افتراضيًا، يستخدم Humming نوع التنشيط المحدد في نقطة التحقق ويكيّف التنفيذ مع الجهاز. إذا لم تدعم وحدة معالجة الرسومات (GPU) نوع الحساب ذلك، ينتقل Humming إلى نوع أعلى دقة مدعوم. على سبيل المثال، يمكن للأجهزة التي لا تدعم MXFP4 أصلًا استخدام مسارات حساب FP8 أو BF16 أو FP16 تلقائيًا، مما يتيح تشغيل نقطة التحقق الكمّية نفسها عبر أجيال مختلفة من وحدات معالجة الرسومات.

يمكن للمستخدمين تجاوز الإعداد الافتراضي عبر واجهة تكوين الكمّنة في vLLM لاختيار نوع تنشيط لنشرهم. يضبط المثال التالي نوع التنشيط لطبقات MoE إلى MXFP8:

vllm serve openai/gpt-oss-20b --moe-backend humming --quantization-config.moe.activation mxfp8

الخطط المستقبلية

دعم أوسع وأعمق للأجهزة

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

• دعم المزيد من ميزات معمارية Rubin، بما فيها نطاقات الموقع (Locality Domains)، لتحسين مطابقة المهام والوصول إلى البيانات بشكل أكبر.
• توسيع الدعم ليشمل المزيد من أجهزة T-Head PPU، بما في ذلك Zhenwu M890.
• دعم المزيد من الأجهزة المتوافقة مع برمجة CUDA، لنقل صيغ الكمّنة ومكونات النواة وإمكانات الضبط الحالية إلى منصات عتاد إضافية.

إضافة Autotune

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

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

تكامل أعمق مع أطر الاستدلال

سيواصل Humming تعميق تكامله مع أطر الاستدلال مثل vLLM، بتوسيع الدعم عبر تحميل النماذج الكمّية، واختيار الخلفية، والاستدلال المتوازي، وجدولة وقت التشغيل، وتكييف الأجهزة. ونحن نهدف إلى جعل المزيد من طرق الكمّنة تعمل مع كامل نطاق قدرات الإطار، بما فيها التحسينات مثل الاتصال الكمّي All-to-All (A2A) للتوازي الخبير (EP). وستجعل هذه الجهود النوى الكمّية عالية الأداء أسهل في الاستخدام عبر سيناريوهات النشر المتنوعة، وتساعد على ترجمة مكاسب أداء النوى إلى فوائد استدلالية من طرف إلى طرف.

شكر وتقدير

نشكر Jinzhen Lin وZekai Gu وZhilin Huang من مجموعة Ant، بالإضافة إلى Michael Goin وRoberto L. Castro وChauncey Jiang وغيرهم من أعضاء مجتمع vLLM، على مساهماتهم ودعمهم طوال تطوير Humming.

نشكر أيضًا مجتمع vLLM على توفير موارد التطوير والاختبار والتكامل المستمر (CI) التي أتاحت التحقق من Humming وتحسينه عبر مجموعة واسعة من العتاد وأعباء العمل.

يستلهم تصميم Humming وتحسيناته الإلهام من Marlin وvLLM Marlin وLMDeploy وDeepGEMM وFlashInfer وCUTLASS وغيرها من المشاريع مفتوحة المصدر. ونحن ممتنون لمؤلفيها والمساهمين فيها على مشاركة أفكارهم وتطبيقاتهم، بما يساعد على دفع عجلة الاستدلال الكمّي عالي الأداء لأجامل المجتمع بأسره.