تحسين TensorRT-LLM: إتقان مجموعة أدوات الاستدلال من NVIDIA

آخر تحديث: 11 ديسمبر 2025

تحديث ديسمبر 2025: يحقق TensorRT-LLM أكثر من 10,000 رمز ناتج/ثانية على H100 مع FP8، وزمن وصول أول رمز (TTFT) أقل من 100 مللي ثانية. تُبلغ عمليات النشر الإنتاجية عن إنتاجية أعلى بـ 4 أضعاف مقارنة بـ PyTorch الأصلي. دمج النواة يجمع LayerNorm والضرب المصفوفي ودوال التنشيط في نوى CUDA واحدة. التجميع أثناء التشغيل يُعظّم استخدام وحدة معالجة الرسومات. انتباه FP8 على Hopper/Blackwell يوفر تسريعات إضافية.

يوفر TensorRT-LLM من NVIDIA أداء استدلال خام يصعب على البدائل مجاراته. على وحدات معالجة الرسومات H100 بدقة FP8، يحقق الإطار أكثر من 10,000 رمز ناتج في الثانية عند ذروة الإنتاجية مع زمن وصول أول رمز أقل من 100 مللي ثانية.¹ تُبلغ عمليات النشر الإنتاجية عن تحسينات في الإنتاجية تصل إلى 4 أضعاف مقارنة باستدلال PyTorch الأصلي. يأتي الأداء بتكلفة: يتطلب TensorRT-LLM خبرة أكبر في التكوين ودورات تحسين أطول من البدائل سهلة الاستخدام مثل vLLM.

بالنسبة للمؤسسات الملتزمة بأجهزة NVIDIA والراغبة في استثمار الوقت الهندسي في التحسين، يستخرج TensorRT-LLM أقصى أداء من البنية التحتية المكلفة لوحدات معالجة الرسومات. فهم بنية الإطار وخيارات التكميم ومعاملات الضبط يُمكّن الفرق من بناء أنظمة استدلال تُبرر استثمارات الأجهزة المتميزة من خلال اقتصاديات رموز متفوقة.

البنية والتحسينات الأساسية

يُبنى TensorRT-LLM على مُحسّن الاستدلال TensorRT من NVIDIA، موسعاً إطار التجميع بتحسينات خاصة بالمحولات. توفر المكتبة واجهات برمجة تطبيقات Python لتعريف النموذج إلى جانب مكونات وقت التشغيل بلغة C++ للنشر الإنتاجي.

دمج النواة: يجمع TensorRT-LLM عمليات المحول المتعددة في نوى CUDA محسّنة واحدة. تُنفذ LayerNorm والضرب المصفوفي وإضافات الانحياز ودوال التنشيط معاً بدلاً من طلب إطلاقات نواة منفصلة ونقل ذاكرة. يقلل الدمج من حمل إطلاق النواة ويُلغي تجسيد الموترات الوسيطة.²

نوى الانتباه المخصصة: تستفيد التطبيقات المحسّنة يدوياً للانتباه متعدد الرؤوس والانتباه المجمّع للاستعلام من تعليمات Tensor Core لتحقيق أقصى إنتاجية. تقلل متغيرات Flash Attention من متطلبات عرض النطاق الترددي للذاكرة مع الحفاظ على الدقة العددية. توفر نوى انتباه FP8 على وحدات معالجة الرسومات Hopper وBlackwell تسريعات إضافية.

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

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

مقارنة الأداء: TensorRT-LLM مقابل vLLM

يستهدف كلا الإطارين استدلال LLM الإنتاجي، لكن الاختلافات المعمارية تُنشئ ملفات أداء متميزة:

يتفوق TensorRT-LLM باستمرار على vLLM مع التكوينات الافتراضية، محققاً إنتاجية أعلى بـ 1.34 مرة على التسلسلات القصيرة ووقت أفضل بـ 2.72 مرة لكل رمز ناتج على التسلسلات الطويلة.⁵ على وحدات معالجة الرسومات B200، يوسع التحسين الأعمق لـ TensorRT-LLM لبنية Blackwell فجوة الأداء أكثر.

يقدم vLLM مزايا في تجربة المطور:⁶ - واجهة برمجة تطبيقات متوافقة مع OpenAI للاستبدال المباشر - نشر أبسط بدون خطوة تجميع - تحسين تلقائي للنموذج مع إعدادات افتراضية معقولة - دعم أوسع للأجهزة يتجاوز وحدات معالجة الرسومات NVIDIA

التوصية: انشر TensorRT-LLM عندما يُبرر تعظيم كفاءة الأجهزة الاستثمار الهندسي. اختر vLLM للوصول الأسرع للإنتاج أو عند العمل على نطاق أصغر حيث يهم الأداء المطلق أقل من سرعة التطوير.

استراتيجيات التكميم

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

تكميم FP8 (موصى به أولاً)

يوفر FP8 أفضل توازن بين تحسين الأداء مع الحد الأدنى من تدهور الدقة:⁷

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat fp8 \
    --kv_cache_dtype fp8 \
    --output_dir $OUTPUT_PATH

يتطلب تكميم FP8 معايرة لتحديد عوامل القياس المناسبة. تُشغّل عملية المعايرة الاستدلال على عينات تمثيلية لقياس نطاقات التنشيط:

from tensorrt_llm.quantization import QuantConfig, CalibConfig

quant_config = QuantConfig(
    quant_algo="fp8",
    kv_cache_quant_algo="fp8"
)

calib_config = CalibConfig(
    calib_dataset="cnn_dailymail",
    calib_batch_size=8,
    calib_num_samples=512
)

يوفر FP8 تحسيناً متوسطاً في الأداء مع تأثير منخفض جداً على الدقة ويتطلب دقائق فقط للمعايرة. توفر وحدات معالجة الرسومات Hopper وBlackwell دعم FP8 على مستوى الأجهزة؛ تدعم وحدات معالجة الرسومات Ada تكميم FP8 بكفاءة أقل.

INT4 AWQ لعمليات النشر المقيدة بالذاكرة

عندما تحد الذاكرة من حجم النموذج، يضغط التكميم الواعي للتنشيط INT4 الأوزان إلى 4 بتات مع الحفاظ على دقة مقبولة:⁸

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat int4_awq \
    --awq_block_size 64 \
    --tp_size 4 \
    --output_dir $OUTPUT_PATH

يتفوق INT4 AWQ في سيناريوهات الدفعات الصغيرة (حجم الدفعة ≤ 4) حيث يصبح الاستدلال مقيداً بالذاكرة. يهيمن وقت تحميل الأوزان على الحوسبة، لذا يوفر ضغط الأوزان القوي تسريعات كبيرة. للدفعات الكبيرة، تتناقص ميزة أداء INT4 AWQ مع زيادة كثافة الحوسبة.

INT8 SmoothQuant للتحسين المتوازن

ينقل SmoothQuant صعوبة التكميم من التنشيطات إلى الأوزان، مما يُمكّن من تكميم INT8 فعال دون فقدان دقة كبير:

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat int8_sq \
    --kv_cache_dtype int8 \
    --output_dir $OUTPUT_PATH

يوفر INT8 SmoothQuant تحسيناً متوسطاً في الأداء مع تأثير متوسط على الدقة. يجب على المؤسسات تجربة FP8 أولاً، والعودة إلى INT8 SQ إذا لم تلبِ نتائج FP8 المتطلبات.

إطار اختيار التكميم

توصي NVIDIA بترتيب الأولوية التالي:⁹

1. FP8 - أفضل مفاضلة بين الأداء والدقة، يتطلب Hopper/Blackwell
2. INT8 SmoothQuant - بديل جيد لوحدات معالجة الرسومات Ada أو عندما تكون دقة FP8 غير كافية
3. INT4 AWQ/GPTQ - أقصى ضغط للسيناريوهات المقيدة بالذاكرة

لذاكرة التخزين المؤقت لـ KV تحديداً، يُوصى بتكميم FP8 بدلاً من INT8 على وحدات معالجة الرسومات Hopper وAda بسبب التأثير الأقل على الدقة في معظم الحالات.

تكوين النشر الإنتاجي

يتطلب النشر الأمثل لـ TensorRT-LLM ضبط معاملات متعددة بناءً على خصائص عبء العمل:

تكوين بناء المحرك

trtllm-build \
    --checkpoint_dir $CHECKPOINT_PATH \
    --output_dir $ENGINE_PATH \
    --max_batch_size 256 \
    --max_num_tokens 8192 \
    --max_input_len 4096 \
    --max_seq_len 8192 \
    --gemm_plugin auto \
    --use_paged_context_fmha enable \
    --workers 8

max_batch_size: الافتراضي 256 في الإصدارات الحديثة. غالباً ما تزيد عمليات النشر الإنتاجية التي تحقق أقصى إنتاجية إلى 2048، مستفيدة بالكامل من قدرات التجميع أثناء التشغيل.¹⁰

max_num_tokens: يتحكم في إجمالي الرموز المعالجة لكل تكرار دفعة. الافتراضي 8192 يوازن بين الإنتاجية واستهلاك الذاكرة. خفّضه لعمليات النشر المقيدة بالذاكرة؛ زِده بحذر مع المراقبة.

use_paged_context_fmha: يُمكّن الانتباه بالصفحات لإدارة فعالة لذاكرة التخزين المؤقت لـ KV. مطلوب عند استخدام التجميع أثناء التشغيل. يُخصص التطبيق ذاكرة التخزين المؤقت لـ KV مسبقاً، مما يتطلب حوالي 60% أكثر من VRAM مقارنة بأوزان النموذج وحدها.¹¹

تكامل Triton Inference Server

تستخدم عمليات النشر الإنتاجية عادةً NVIDIA Triton Inference Server مع خلفية TensorRT-LLM:

model_repository/
└── llama-70b/
    ├── 1/
    │   └── model.py
    ├── config.pbtxt
    └── tensorrt_llm/
        └── 1/
            ├── config.json
            └── engine/

يوفر Triton تنسيق النماذج المتعددة وانتظار الطلبات وجمع المقاييس والتوسع الأصلي لـ Kubernetes. تتضمن حاوية NGC المُعدة مسبقاً خلفية TensorRT-LLM مع تمكين التجميع أثناء التشغيل ودعم ذاكرة التخزين المؤقت لـ KV بالصفحات.

تخطيط الذاكرة

قدّر متطلبات الذاكرة قبل النشر:

إجمالي VRAM = أوزان النموذج + ذاكرة التخزين المؤقت لـ KV + ذاكرة التنشيط + حمل وقت التشغيل

أوزان النموذج (FP8): المعاملات × 1 بايت
أوزان النموذج (INT4): المعاملات × 0.5 بايت
ذاكرة التخزين المؤقت لـ KV: حجم_الدفعة × طول_التسلسل × عدد_الطبقات × 2 × البُعد_المخفي × بايتات_الدقة

يتطلب نموذج بـ 70 مليار معامل في FP8 تقريباً: - الأوزان: 70 جيجابايت - ذاكرة التخزين المؤقت لـ KV (دفعة 256، تسلسل 8192): ~120 جيجابايت - التنشيطات + الحمل الزائد: ~30 جيجابايت - الإجمالي: ~220 جيجابايت (3x H100 80GB أو 2x H200 141GB)

سير عمل ضبط الأداء

يستخرج التحسين المنهجي أقصى أداء من عمليات نشر TensorRT-LLM:

المرحلة 1: القياس الأساسي

استخدم trtllm-bench للتقييم السريع للأداء:

python -m tensorrt_llm.bench \
    --model_dir $ENGINE_PATH \
    --input_len 512 \
    --output_len 256 \
    --batch_size 32 \
    --num_requests 1000

تضبط أداة القياس معاملات المحرك المثلى تلقائياً، مما يوفر أداءً أساسياً دون تعقيد النشر الكامل لـ Triton.¹²

المرحلة 2: اختيار التكميم

اختبر FP8 أولاً مقابل متطلبات الدقة. إذا تدهورت الدقة إلى ما بعد العتبات المقبولة، قيّم INT8 SQ أو INT4 AWQ. شغّل معايير التقييم على مهام تمثيلية، وليس فقط قياسات الحيرة.

المرحلة 3: تحسين حجم الدفعة

قِس الإنتاجية عبر أحجام الدفعات من 1 إلى max_batch_size. حدد نقطة انعطاف منحنى الإنتاجية حيث يوفر التجميع الإضافي عوائد متناقصة. اضبط max_batch_size بنسبة 20-30% أعلى من هذه النقطة لاستيعاب ذروات حركة المرور.

المرحلة 4: ضبط ذاكرة التخزين المؤقت لـ KV

راقب استخدام ذاكرة التخزين المؤقت لـ KV أثناء أعباء العمل الإنتاجية. إذا تجاوز الاستخدام باستمرار 80%، زِد max_num_tokens أو خفّض max_batch_size. إذا بقي الاستخدام أقل من 50%، خفّض التخصيص لتحرير الذاكرة لدفعات أكبر.

المرحلة 5: المراقبة المستمرة

تتبع المقاييس الرئيسية في الإنتاج: - الرموز في الثانية (الإنتاجية) - زمن وصول أول رمز (زمن الانتقال) - عمق قائمة الانتظار (السعة) - استخدام ذاكرة التخزين المؤقت لـ KV (الذاكرة) - استخدام وحدة معالجة الرسومات (الكفاءة)

التحسينات المتقدمة

فك التشفير التخميني

يدعم TensorRT-LLM فك التشفير التخميني باستخدام نماذج مسودة أصغر للتنبؤ برموز متعددة يتحقق منها النموذج الرئيسي. توفر التقنية تسريعاً بمقدار 1.5-2x لأعباء العمل المتوافقة:

# تمكين فك التشفير التخميني في بناء المحرك
trtllm-build \
    --speculative_decoding_mode draft_tokens_external \
    --max_draft_len 5 \
    ...

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

تكوينات وحدات معالجة الرسومات المتعددة

يدعم TensorRT-LLM التوازي الموتري (TP) وتوازي خط الأنابيب (PP) وتوازي الخبراء (EP) للاستدلال الموزع:

# توازي موتري رباعي
trtllm-build \
    --tp_size 4 \
    --pp_size 1 \
    ...

يقسم TP كل طبقة عبر وحدات معالجة الرسومات، مما يتطلب عمليات all-reduce عند كل حدود طبقة. يقسم PP الطبقات عبر وحدات معالجة الرسومات في مراحل خط أنابيب. للاستدلال، يوفر TP عادةً زمن انتقال أفضل بينما يُمكّن PP

[تم اقتطاع المحتوى للترجمة]