ضبط نواة لينكس لخوادم الذكاء الاصطناعي: ما الذي يُحدث الفرق فعلاً؟

يُعدّ نواة أوبونتو الافتراضية على حزمة HWE 6.8 أو 6.11 مناسبة لحوالي 80% من أحمال عمل الذكاء الاصطناعي. هذه المقالة مخصصة للنسبة المتبقية البالغة 20%، وهي: معالج EPYC متعدد المقابس يدعم ثماني وحدات معالجة رسومية، وخادم vLLM يعمل بكفاءة عالية. vm.max_map_count جدار تحت الحمل، أو خادم استدلال يتم استهلاك زمن استجابته بواسطة انتقالات حالة C لوحدة المعالجة المركزية.

معظم النصائح العامة حول "تحسين أداء لينكس للذكاء الاصطناعي" هي عبارة عن إرشادات مُعاد تدويرها لقواعد البيانات من عام 2015، وجزء كبير منها يُؤدي إلى تفاقم زمن استجابة الاستدلال. فيما يلي مجموعة أصغر وأكثر فعالية من التغييرات التي تُحسّن أداء جهاز K-AI من فئة Kentino (4-8 وحدات معالجة رسومية على معالجات Xeon أو EPYC، نظام Ubuntu 22.04 / 24.04، نواة 6.x). يُفترض تثبيت برنامج التشغيل ومجموعة CUDA. L01 و L02.

التسلسل الهرمي النزيه للمكاسب

قبل إجراء أي تغييرات على sysctl، ركز على حجم الجائزة:

إذا لم تستفد من هذه المقالة إلا بشيء واحد: يُعدّ الوعي بتقنية NUMA وميزة مُنظِّم أداء وحدة المعالجة المركزية من أهمّ المكسبين. أما باقي الأمور فهي هامشية ما لم يتمّ قياسها بدقة.

مُنظِّم وحدة المعالجة المركزية: أرخص 5-15% على الطاولة

الوضع الافتراضي في أوبونتو هو powersave (intel_pstate) أو ondemand (acpi_cpufreq) يعتمد على برنامج التشغيل. كلا الترددين يرتفعان بشكل تفاعلي، مما يكلف 5-15% من وقت الاستدلال الكلي (TTFT) ومن وقت التحضير على جانب وحدة المعالجة المركزية (CPU) حول تمريرة vLLM الأمامية - التجزئة، والجدولة، وأخذ عينات لوجيت.

لصندوق التقديم، قم بتجهيزه performance ثم انسَ الأمر:

sudo apt install -y cpufrequtils
echo 'GOVERNOR="performance"' | sudo tee /etc/default/cpufrequtils
sudo systemctl restart cpufrequtils

# Verify
for c in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do cat $c; done | sort -u

على معالج EPYC Genoa / Turin بنواة 6.5+، amd-pstate يستبدل السائق acpi-cpufreqنفس الفكرة، مجموعة scaling_governor إلى performance. الأحدث amd-pstate-epp يحافظ هذا الوضع على الأداء مع السماح بتعزيز الأداء لكل نواة على حدة؛ اترك وضع EPP على performance، لا balance_performance.

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

NUMA: الفرق بين جهاز EPYC سريع ومتوسط

لا تحتاج خوادم Xeon أو EPYC أحادية المقبس إلى التفكير في أي شيء - عقدة NUMA واحدة، وكل عملية وصول إلى الذاكرة محلية. أما الخوادم ثنائية المقبس فهي تمثل نسبة 10-30% من الخوادم.

سيقوم المجدول الافتراضي بوضع عامل vLLM على المقبس 0، مما يؤدي إلى خطأ في الصفحة يؤدي إلى نقل البيانات إلى الذاكرة المخصصة على المقبس 1 - كل عملية تحميل هي عبارة عن قفزة UPI / Infinity Fabric عبر المقبس. بالنسبة لنموذج يحتوي على مئات الجيجابايت من الأوزان التي يتم التعامل معها مرة واحدة لكل رمز مميز، فإن هذا أمر واقعي.

فحص:

numactl --hardware                            # node count, sizes, distance matrix
nvidia-smi topo -m                            # GPU↔CPU NUMA affinity
cat /sys/class/net/<iface>/device/numa_node   # NIC NUMA affinity

النمط المطلوب - والذي يكتشفه NCCL تلقائيًا - هو تثبيت وحدة معالجة الرسومات N على عقدة NUMA التي تستضيف مُجمّع PCIe الجذري الخاص بها، وليس على المقبس الآخر. بالنسبة لعملية الاستدلال التي يتم تشغيلها يدويًا، قم بتثبيت كل من وحدة المعالجة المركزية والذاكرة على العقدة المحلية.

# vLLM on a 2-socket EPYC, GPUs 0–3 on NUMA node 0
numactl --cpunodebind=0 --membind=0 \
  python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.3-70B-Instruct --tensor-parallel-size 4

مقبضان متصلان:

• kernel.numa_balancing ينقل الصفحات باتجاه وحدة المعالجة المركزية التي تتفاعل معها. مفيد لأحمال العمل العامة، ولكنه قد يكون غير فعال أحيانًا في تطبيقات الذكاء الاصطناعي: حيث يقوم التعبئة المسبقة بمسح الأوزان مرة واحدة، ثم يقوم النظام بنقل الصفحات، وفي الطلب التالي يتم سحبها مرة أخرى. اتركه مفعلًا افتراضيًا (1); إذا كان التذبذب مرتبطًا بـ numa_pte_updates in /proc/vmstat، في محاولة sysctl kernel.numa_balancing=0.
• NCCL على مقبس مزدوج - تعيين NCCL_SOCKET_IFNAME إلى إدارة NIC و NCCL_IB_HCA إلى بطاقة الشبكة الموجودة على نفس عقدة NUMA التي توجد بها وحدات معالجة الرسومات. استخدام بطاقة شبكة خاطئة يُقلل معدل نقل البيانات بين العقد إلى النصف دون تنبيه.

خادم EPYC 9004/9005 ذو المقبس الواحد: تجاهل هذا القسم بأكمله.

صفحات ضخمة شفافة: madvise، لا always

تقوم تقنية THP بطي صفحات بحجم 4 كيلوبايت إلى صفحات بحجم 2 ميجابايت بشكل انتهازي، مما يقلل الضغط على ذاكرة الترجمة السريعة (TLB). يستفيد كل من PyTorch وبرنامج تشغيل CUDA بشكل طفيف. تكمن المشكلة في always الوضع تحت تأثير اضطراب الذاكرة - يقوم النواة بإيقاف مؤشر الترابط لمدة 50-100 مللي ثانية لضغط الذاكرة، مما يؤدي إلى إتلاف أي مستوى التزام زمني.

الإعداد الصحيح هو madviseالتطبيقات التي تعرف ما تفعله تسمى madvise(MADV_HUGEPAGE) يتم تخصيص الموارد على المدى الطويل والحصول على THP؛ لا شيء آخر يفعل ذلك. يتم التعيين عبر /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="... transparent_hugepage=madvise"

update-grub && rebootيجب أن تتطابق عملية إلغاء التجزئة مع — defer+madvise يسمح هذا النظام بضغط البيانات في الخلفية بدلاً من مسار مؤشر الترابط المُخصِّص:

echo defer+madvise | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

بالنسبة لـ vLLM / SGLang / TensorRT-LLM في بيئة الإنتاج، madvise هذا هو الإعداد الافتراضي الصحيح. يستفيد PyTorch مع ذاكرة CUDA الموحدة (كود البحث) أحيانًا من always — قم بالقياس قبل قلبها.

صفحات ضخمة بحجم 1 جيجابايت صريحة: فقط إذا قمت بقياسها

صفحات ضخمة صريحة محجوزة عند بدء التشغيل عبر hugetlbfs يُحقق هذا النظام فائدة إضافية طفيفة لأوزان LLM الكبيرة جدًا عن طريق التخلص من أخطاء TLB أثناء فحص الوزن. لكن المشكلة تكمن في أن الذاكرة تُحجز مسبقًا ولا تتوفر لبقية النظام، ويجب تصميم التطبيق لاستخدامها، وتتراوح الفائدة بين 1 و3% لمعظم أحمال العمل.

GRUB_CMDLINE_LINUX_DEFAULT="... default_hugepagesz=1G hugepagesz=1G hugepages=64"

يستحق الأمر العناء لجهاز TensorRT-LLM حيث يتناسب المحرك مع الذاكرة المخصصة، وتسعى فيه إلى تقليل وقت الاستجابة إلى أدنى حد ممكن. لا يستحق العناء لخادم vLLM عام يقوم بتبديل النماذج أو أي جهاز تدريب. تجنبه في الإصدار الأول؛ ولا تعيد النظر فيه إلا إذا perf stat -e dTLB-load-misses يعرض ضغط TLB ولديك مساحة كافية لرأس RAM.

vm.max_map_count و nofile: الجدران التي يصطدم بها برنامج vLLM على نطاق واسع

الترتيب vm.max_map_count يبلغ عدد عمليات ربط الذاكرة المختلفة التي يمكن أن يحتفظ بها أي معالج في نظام أوبونتو 65530. يُستخدم vLLM لخدمة نموذج كبير ذي تزامن عالٍ، أو أي إطار عمل يستخدم الكثير من... mmapشظايا "d safetensors"، تتجاوز هذا وتموت مع Cannot allocate memoryالقيمة 262144 المستمدة من Elasticsearch هي الحد الأدنى؛ بالنسبة لـ vLLM الذي يخدم أكثر من 70 مليار عملية مع مئات التسلسلات المتزامنة، قم بالترقية إلى 1048576. لا يكلف ذلك شيئًا - إنه حد مرن، وليس حجزًا.

الترتيب ulimit -n يبلغ الحد الأقصى على أوبونتو 1024. وهو منخفض بشكل مثير للسخرية: حيث أن vLLM وTriton وعمال PyTorch DataLoader وNCCL وطبقة gRPC التي تربط بينها تفتح مئات من ملفات تعريف الملفات (FDs) لكل منها. عند الوصول إلى الحد الأقصى، ستحصل على EMFILE: too many open files وعملية تتشكل بصمت.

# /etc/sysctl.d/99-ai-server.conf
vm.max_map_count = 1048576

# /etc/security/limits.d/99-ai-server.conf
*    soft    nofile  1048576
*    hard    nofile  1048576

# /etc/systemd/system.conf.d/99-limits.conf
[Manager]
DefaultLimitNOFILE=1048576

sudo sysctl --system و systemctl daemon-reexecتحقق من ذلك مع ulimit -n و cat /proc/<pid>/limits.

تقارب مقاطعات IRQ: تثبيت مقاطعات بطاقة الشبكة على وحدات المعالجة المركزية المحلية

في بطاقة شبكة ConnectX-6/7 بسرعة 100 جيجابت/ثانية تدعم تدفق بيانات أو حركة مرور RDMA بمعدل 10+ جيجابايت/ثانية، يجب أن تصل المقاطعات إلى وحدات المعالجة المركزية (أ) الموجودة على نفس عقدة NUMA الخاصة ببطاقة الشبكة، و(ب) ليس على نفس النوى التي تشغل عمال DataLoader. هذا هو الوضع الافتراضي irqbalance يؤدي وظيفة مقبولة؛ لكنه لا يؤديها تحت الأحمال الثقيلة.

الحل الأمثل هو منتج ميلانوكس set_irq_affinity.sh من mlnx-tools:

sudo systemctl disable --now irqbalance
sudo /usr/sbin/set_irq_affinity.sh enp1s0f0                  # all NIC-local cores
sudo /usr/sbin/set_irq_affinity_cpulist.sh 4-11 enp1s0f0     # pin to specific cores

الخطوة الخاطئة هي المغادرة irqbalance عند تشغيل الجهاز على خادم قمت بتثبيت الشبكة عليه يدويًا، يحدث تعارض بينهما. اختر أحدهما. خادم مزود ببطاقة شبكة RDMA واحدة أو اثنتين: قم بالتثبيت يدويًا، أو قم بالتعطيل. irqbalanceصندوق متعدد الأغراض ذو واجهات متعددة: اتركه irqbalance على مع --banirq لاستبعاد بطاقة الشبكة الحرجة.

مخازن بيانات نواة الشبكة: مخصصة فقط لمسارات التخزين/البث السريع

بالنسبة لخادم استدلال أحادي العقدة يتواصل مع العملاء عبر بروتوكول TCP العادي بمعدلات متواضعة، فإن الإعداد الافتراضي net.core.rmem_max / wmem_max حجم 208 كيلوبايت مناسب. بالنسبة لعقدة تسحب بيانات التدريب من نظام ملفات الشبكة (NFS) بسرعة 100 جيجابت إيثرنت أو من مخزن كائنات، أو واجهة أمامية لـ vLLM خلف موازن تحميل عالي معدل الطلبات في الثانية (RPS)، فإن الإعدادات الافتراضية تمثل الحد الأقصى لحاصل ضرب عرض النطاق الترددي في زمن التأخير. إليك مجموعة إعدادات مبدئية لجهاز متصل بشبكة 100 جيجابت إيثرنت:

# /etc/sysctl.d/99-ai-network.conf
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.tcp_rmem = 4096 87380 268435456
net.ipv4.tcp_wmem = 4096 65536 268435456
net.core.netdev_max_backlog = 250000
net.core.somaxconn = 65535

يُعدّ الحد الأقصى البالغ 256 ميجابايت مُبالغًا فيه بالنسبة لشبكة 100 جيجابت إيثرنت داخل الرف (يبلغ حجم BDP حوالي 1.25 ميجابايت)، ولكنه غير ضار، حيث يقوم الضبط التلقائي لبروتوكول TCP بزيادة حجم المخازن المؤقتة حسب الحاجة فقط حتى الحد الأقصى. أما بالنسبة لمسار البيانات في RDMA (RoCE / IB)، فلا تُؤثر هذه الإعدادات، لأن RDMA يتجاوز حزمة بروتوكول TCP الخاصة بنواة النظام. ومع ذلك، تظل هذه الإعدادات مهمة لمستوى الإدارة، ونظام ملفات الشبكة (NFS)، وتنزيلات النماذج.

حالات C: زمن الاستجابة مقابل الطاقة الخاملة

بالنسبة لخادم خدمة حساس للتأخير، فإن أرخص طريقة لتحسين زمن الاستجابة بعد مُتحكم وحدة المعالجة المركزية هي تعطيل حالات C العميقة. يستغرق الدخول/الخروج من حالة C6 عشرات الميكروثواني؛ بالنسبة لطلب يُفترض أن يستجيب في غضون 30 مللي ثانية، فإن خروج وحدة المعالجة المركزية من حالة C6 لمعالجة أخذ العينات بعد الرمز المميز يُضيف تذبذبًا ملحوظًا.

GRUB_CMDLINE_LINUX_DEFAULT="... intel_idle.max_cstate=1 processor.max_cstate=1"

update-grub && rebootتحقق من ذلك مع cpupower idle-info — يجب أن يكون الخياران C0 و C1 فقط متاحين. التكلفة: 30-50 واط من الطاقة الخاملة لكل مقبس لأن النوى لا تدخل في وضع السكون العميق. في خادم ثنائي المقابس بثمانية وحدات معالجة رسومية، يبلغ استهلاك الطاقة الدائم 60-100 واط، وهو ضئيل مقارنةً باستهلاك الطاقة المستمر لوحدة معالجة الرسوميات تحت الضغط، والذي يتراوح بين 3.5 و4.5 كيلوواط.

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

ضبط نواة النظام المتعلقة بنظام الملفات (معاينة حتى السطر 04)

حفنة من fs.* أهمية sysctls:

fs.aio-max-nr = 1048576              # default 65536 too low for vLLM weight loaders
fs.inotify.max_user_watches = 524288 # tooling that watches checkpoint dirs

fs.aio-max-nr هي المشكلة الحقيقية - حيث تستهلك الأطر التي تُجري عمليات إدخال/إخراج غير متزامنة على العديد من الأجزاء (مثل DALI ومحملات وزن vLLM) الذاكرة الافتراضية البالغة 65536 بايت في النماذج الكبيرة. كما يؤثر اختيار نظام الملفات نفسه (XFS مقابل ZFS مقابل ext4)، وخيارات التثبيت، و O_DIRECT تتواجد الدلالات في L04.

تعطيل وحدات النواة غير الضرورية

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

# /etc/modprobe.d/blacklist-ai-server.conf
blacklist bluetooth
blacklist btusb
blacklist snd_hda_intel
blacklist uvcvideo
blacklist joydev

# Plus
sudo systemctl disable --now bluetooth.service cups.service avahi-daemon.service \
                              ModemManager.service whoopsie.service apport.service

ينخفض ​​وقت بدء التشغيل من حوالي 30 ثانية إلى حوالي 10 ثوانٍ في إصدار EPYC النموذجي و lsmod تصبح قابلة للقراءة. لا يوجد تأثير على أداء الاستدلال، وانخفاض طفيف في مساحة الهجوم.

ملفان تعريفيان: الاستدلال مقابل التدريب

يختلف شكل الضبط اختلافًا حقيقيًا. رسومات توضيحية جاهزة للاستخدام:

الاستدلال (/etc/sysctl.d/99-ai-inference.conf)

vm.max_map_count = 1048576
vm.swappiness = 1
vm.overcommit_memory = 1
kernel.numa_balancing = 1
fs.aio-max-nr = 1048576
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.tcp_rmem = 4096 87380 268435456
net.ipv4.tcp_wmem = 4096 65536 268435456
net.core.netdev_max_backlog = 250000
net.core.somaxconn = 65535

بالإضافة إلى سطر أوامر النواة: transparent_hugepage=madvise intel_idle.max_cstate=1 processor.max_cstate=1الحاكم: performance. مقاطعات بطاقة الشبكة (NIC IRQs) المثبتة على النوى المحلية لـ NUMA، irqbalance إيقاف.

تمرين (/etc/sysctl.d/99-ai-training.conf)

vm.max_map_count = 1048576
vm.swappiness = 1
vm.overcommit_memory = 1
kernel.numa_balancing = 0       # page migration mid-epoch is just churn
fs.aio-max-nr = 1048576
fs.inotify.max_user_watches = 524288
net.core.rmem_max = 536870912
net.core.wmem_max = 536870912
net.ipv4.tcp_rmem = 4096 131072 536870912
net.ipv4.tcp_wmem = 4096 131072 536870912

سطر أوامر النواة: transparent_hugepage=madvise (تجاوز تثبيت حالة C - التدريب مرتبط بالإنتاجية، وتتراكم الطاقة الخاملة على مدى أسابيع). المحافظ: performance إذا كانت لديك ميزانية الطاقة. يتم تثبيت NCCL على NUMA المحلي عبر NCCL_IB_HCA.

فخ "ضبطت كل شيء ثم أصبح أبطأ"

أكثر أسباب الفشل شيوعًا هو اتباع أسلوب النسخ العشوائي: نسخ مئات من أوامر sysctl من منشور مدونة، إعادة تشغيل الجهاز، ملاحظة تراجع الأداء، وعدم معرفة أي أمر يجب التراجع عنه. الطريقة الناجحة:

1. تحديد خط الأساس — nccl-tests all_reduce_perf، vLLM benchmark_throughput.pyوقت التدريب. دوّن الأرقام.
2. غيّر شيئًا واحدًا.
3. أعد تشغيل نفس الاختبار المعياري ثلاث مرات لقياس التشويش.
4. احتفظ بالخيار إذا كان الوسيط أفضل بشكل ملحوظ. أعده إلى وضعه السابق إذا لم يكن كذلك.
5. قم بتوثيق التغيير وسببه، في نظام التحكم بالإصدارات بجوار ملف sysctl.

لقد رأينا أجهزة إنتاجية تحتوي على 40 سطرًا من ضبط sysctl وكانت أبطأ بنسبة 2٪ من الإعدادات الافتراضية لنظام Ubuntu - كل تغيير فردي كان محايدًا أو أسوأ، لكن المشغل كان متأكدًا من أن "الضبط يساعد".

ريد هات tuned 2.27 سفينة صريحة ai-inference و ai-training يُعدّ ملف التعريف اختصارًا موثوقًا به على نظامي RHEL / Rocky. لا يأتي نظام Ubuntu مزودًا به؛ apt install tuned يعمل، لكنه أقل صقلاً. على أوبونتو، يتم إنشاء ملفات إضافية يدويًا في /etc/sysctl.d/ كما أن سطر أوامر GRUB النظيف يسهل مراجعته، وتعرف بالضبط ما تم تعيينه.

---

هذا جزء من ويكي كينتينو، وهي سلسلة مرجعية حول الحوسبة الذكية، والروبوتات، والأنظمة التي تربط بينهما. نرحب بالتعليقات والتصويبات على info@kentino.com.