Үдеткіштері бар сервердегі GPU драйверлерінің қайшылықтары

GPU драйверлерінің қайшылықтары «драйвер мен кітапхана үйлеспейді» деген анық хабарламадан сирек басталады. Көбіне бір тапсырма төрт үдеткішті көреді, екіншісі екеуін ғана көреді, түйінде nvidia-smi жұмыс істегенімен, контейнер CUDA driver version is insufficient for CUDA runtime version қатесін қайтарады немесе қайта жүктегеннен кейін барлық карта жоғалады. Бұл белгілер ұқсас көрінгенімен, әртүрлі деңгейде пайда болады.

Мен мұндай ақауды төменнен жоғары қарай талдаймын: PCIe, ядро модулі, пайдаланушы кеңістігіндегі кітапханалар, контейнер, есептеу фреймворкі және жоспарлағыш. CUDA немесе ROCm жүйесін бірден қайта орнату себепті уақытша жасырып, серверді келесі жаңартуда қайта бұзылатын күйде қалдыруы мүмкін. Бірнеше үдеткіші бар түйінде алдымен ақау шекарасын анықтап, содан кейін ғана пакеттерді өзгерту керек.

Бірдей қате бірдей ақауды білдірмейді

Алғашқы тексеру бір сұраққа жауап беруі керек: үдеткіш қай деңгейде қолжетімсіз болды? Бірден сегіз картаға арналған оқыту тапсырмасын іске қоспаңыз. Дұрыс жұмыс істейтін түйінмен немесе алдыңғы жүктелумен салыстыруға болатын қысқа күй жазбасын жинаңыз.

uname -r
lspci -Dnn | grep -Ei 'VGA|3D|Display'
lsmod | grep -E 'nvidia|amdgpu'
modinfo nvidia 2>/dev/null | grep -E '^(version|vermagic):'
nvidia-smi -L 2>&1
nvidia-smi -q | grep -E 'Product Name|GPU UUID|Bus Id'

AMD үшін соңғы екі пәрменді rocminfo және rocm-smi пәрмендерімен ауыстырыңыз. dmesg -T нәтижесін де сақтаңыз, бірақ бүкіл журналды чатқа салмаңыз. Алдымен NVRM, Xid, amdgpu, kfd, IOMMU, AER және pcie жолдарын іріктеңіз.

journalctl -k -b | grep -Ei 'NVRM|Xid|amdgpu|kfd|IOMMU|AER|pcie'

Нәтижені түсіндіру оңай. Егер lspci картаны көрмесе, әзірше CUDA мен контейнерлерге қатысы жоқ. Қуатты, картаның ұяға дұрыс отыруын, райзер кабелін, BIOS баптауларын, PCIe желілерінің бөлінуін немесе құрылғы ақауын тексеріңіз. PCIe барлық картаны көріп, ядро модулі жүктелмесе, модуль құрастырылымын, Secure Boot және ядро журналдарын тексеріңіз. Қызметтік утилита карталарды көрсетіп, қолданба істемесе, пайдаланушы кітапханалары мен тапсырма ортасына өтіңіз.

Аралық қолайсыз жағдай да бар: nvidia-smi карталардың бір бөлігін ғана, ал lspci барлығын көрсетеді. Мұнда GPU нөмірлерін емес, PCI мекенжайларын салыстырыңыз. Құрылғыны ауыстырғаннан, микробағдарламаны жаңартқаннан немесе анықтау реті өзгергеннен кейін GPU 0 нөмірі ауысуы мүмкін. Тексеру кезінде PCI мекенжайы мен UUID сенімдірек.

Құрылғыны қай процесс ұстап тұрғанын тексеріңіз. Ілініп қалған процесс тапсырма тоқтағаннан кейін де қалып, контексті сақтап, картаны қалпына келтіруге немесе модульді түсіруге кедергі жасай алады:

fuser -v /dev/nvidia* 2>/dev/null
lsof /dev/nvidia* 2>/dev/null
nvidia-smi pmon -c 1

Табылған PID процесін тексермей тоқтатпаңыз. Оны жоспарлағыш тапсырмасымен, контейнермен және иесімен сәйкестендіріңіз. Мониторинг демоны, MPS сервері немесе фабрика қызметі де пайдаланушы тапсырмасы аяқталғаннан кейін құрылғыларды ашық ұстай алады. Жүйелік қызметті мәжбүрлеп тоқтату ақауды дұрыс карталарға таратуы мүмкін.

Кез келген өзгеріске дейін күй жазбасын сақтаңыз. Ең аз жинаққа уақыт, түйін атауы, жүктелген ядро, PCIe құрылғыларының тізімі, UUID, драйвер тармағы, белсенді процестер және ядро журналының таңдалған жолдары кіреді. Қайта орнату көптеген ізді өшіреді де, әкімшіде тек тексеруге келмейтін «кеше жұмыс істеді» деген сөз қалады.

nvidia-smi көрсеткен нұсқа орнатылған CUDA нұсқасы емес

nvidia-smi ішіндегі CUDA Version жолы жүйеде немесе контейнерде орнатылған Toolkit нұсқасын емес, жүктелген драйвер қолдайтын ең жоғары CUDA нұсқасын көрсетеді. NVIDIA мұны CUDA Toolkit, Driver, and Architecture Matrix құжатында тікелей түсіндіреді. Сондықтан CUDA Version: 12.4 нәтижесі /usr/local/cuda ішінде Toolkit 12.4 бар екенін дәлелдемейді.

Төрт бөлек нысанды жеке тексеріңіз:

• cat /proc/driver/nvidia/version арқылы жүктелген ядро модулінің нұсқасын;
• динамикалық жүктеуші таңдаған пайдаланушы кеңістігіндегі libcuda.so файлын;
• тапсырма бейнесіндегі CUDA Runtime немесе ROCm нұсқасын;
• мысалы, PyTorch фреймворкінің нұсқасы мен құрастырылымын.

cat /proc/driver/nvidia/version
ldconfig -p | grep 'libcuda\.so'
readlink -f /usr/lib/x86_64-linux-gnu/libcuda.so.1
nvcc -V 2>/dev/null || true
python3 -c 'import torch; print(torch.__version__, torch.version.cuda); print(torch.cuda.is_available())'

nvcc -V пәрмені тек PATH ішінен табылған Toolkit туралы мәлімет береді. Ол процесс нақты жүктеген кітапхананы көрсетпейді. Даулы процесс үшін қысқа сынақты LD_DEBUG=libs арқылы жүргізіңіз немесе /proc/<PID>/maps ішінен кітапхана бейнеленуін тексеріңіз. Осылай қолданба жүйелік нұсқадан бұрын жүктеген стандартты емес каталогтағы ескі libcuda.so тез табылады.

NVIDIA Minor Version Compatibility құжаты драйвер ең төменгі талапқа сай болса, бір негізгі тармақ шегінде жаңа Toolkit қолданылған кейбір қолданбалардың жұмыс істеуіне рұқсат береді. Бірақ бұл барлық үйлесімге берілген рұқсат емес. Драйвердің жаңа мүмкіндігіне сүйенетін код cudaErrorCallRequiresNewerDriver қатесін қайтара алады, ал ескі драйвердегі PTX кодының бөлек шектеулері бар. cuDNN, cuBLAS, NCCL және фреймворктің де өз тәуелділіктері болады.

CUDA ережелерін ұқсастық бойынша ROCm жүйесіне қолданбаңыз. AMD операциялық жүйе, ядро, GPU архитектурасы, ROCm және фреймворктердің тексерілген үйлесімдері бар Compatibility Matrix жариялайды. Бір минорлық шығарылым айырмасы «қауіпсіз шығар» деп ойламай, нақты тармақты тексеріңіз. Үйлесімділік әкімшінің үміті емес, жазылған және тексерілген жинақ болуы керек.

Бірнеше Toolkit нұсқасы орнатылған түйінде /usr/local/cuda символдық сілтемесі жаңылыстыруы мүмкін. Бір қызмет PATH мәнін жүйелік профильден, екіншісі unit файлынан, үшіншісі контейнерден алады. Нақты істемеген процестің ортасын жазып, абсолют жолдарды салыстырыңыз. Бір қолданба үшін ортақ сілтемені өзгерту интерактив сынақты түзеп, фондық қызметті бұзуы мүмкін.

Бір хостта NVIDIA мен AMD үдеткіштерін араластыру бұдан да қатаң тәртіпті талап етеді. Олардың ядро модульдері қатар жұмыс істей алады, бірақ тапсырмалар дұрыс device nodes, runtime және орта айнымалыларын алуы керек. /dev/dri/render* беріліп, /dev/kfd берілмеген ROCm тапсырмасы кітапхана ақауына ұқсайды. Екі өндірушінің барлық құрылғылары ашылған CUDA контейнерінде оқшаулау мәселесі бар. Әр стекті бөлек, содан кейін жоспарлағыштың аралас режимін тексеріңіз.

Пакет атауындағы кітапхана нұсқасы да жеткіліксіз. Бейне қолданба каталогында, виртуалды ортада немесе wheel пакетінде қосымша көшірме ұстай алады. Бір қысқа іске қосуда LD_DEBUG=libs іздеу жолын және таңдалған файлды көрсетеді, бірақ нәтижесі көп болады. libcuda, libcudart, libnvidia-ml, libamdhip64, libhsa-runtime жолдарын іріктеп, бейне нұсқасымен бірге сақтаңыз.

Ядро жаңартуы кітапханалардан бұрын модульді бұзады

Ядро жаңартылғаннан кейін сервер жиі дұрыс жүктеледі, бірақ GPU драйвері алдыңғы ядро үшін құрастырылған күйде қалады. Бұл CUDA Runtime үйлесімсіздігінен бөлек ақау. Басқа Toolkit орнату оны түземейді.

Алдымен ағымдағы ядроны, модульдің vermagic мәнін және DKMS күйін салыстырыңыз:

uname -r
modinfo -F vermagic nvidia 2>/dev/null
dkms status
find /lib/modules/$(uname -r) -type f -name 'nvidia*.ko*' -o -name 'amdgpu*.ko*'

vermagic жолының алғашқы бөліктері жүктелген ядроға сәйкес болуы керек. Осы ядроға арналған модуль файлы жоқ болса, DKMS құрастыру журналын қараңыз. Әдеттегі себептер түсінікті: дәл ағымдағы ядроның тақырып файлдары жоқ, компилятор жарамайды, модуль ядроның жаңа API нұсқасымен құрастырылмайды немесе драйвер бірнеше қайшы әдіспен орнатылған.

NVIDIA Driver Installation Guide жай ғана репозиторийдегі ең жаңа тақырыптарды емес, uname -r нәтижесіне сәйкес тақырып және әзірлеу пакеттерін талап етеді. Нұсқаулықта ядро жаңарғаннан кейін кейде DKMS қолмен іске қосылып, түйін қайта жүктелуі керегі де жазылған. Бұл орынды кеңес, бірақ қолмен қайта құрастыру журнал оқылғаннан кейін ғана мағыналы. Бір сәтсіз пәрменді қайталау ештеңені жөндемейді.

Secure Boot осы көріністің басқа түрін жасайды. Модуль құрастырылып, дискіде тұр, бірақ ядро қолтаңбасы жоқ файлды қабылдамайды. Журналдан Lockdown, Required key not available немесе қолтаңбаны тексеру қатесін іздеңіз. Мәселені операциялық жүйе тәртібіне сай дұрыс қолтаңба қойып, кілтті тіркеу арқылы шешіңіз. Серверде Secure Boot мүмкіндігін тұрақты айналып өту үшін өшіру дұрыс емес.

Дистрибутивтің пакеттік драйверін .run орнатқышымен араластырмаңыз. NVIDIA қолдау көрсетілетін дистрибутивтерде пакеттік әдісті ұсынады, өйткені ол тәуелділіктерді, тармақтарды және ядро жаңартуларын ескереді. Файлдардың бір бөлігі пакет менеджеріне тиесілі болып, қалғанын тәуелсіз орнатқыш жазса, кәдімгі жаңартудан кейін модуль мен пайдаланушы кітапханасының нұсқалары ажырайды.

Тағы бір жиі болатын жағдай осылай өрбиді. Жаңарту жаңа ядро мен драйвер пакетін орнатады, бірақ сервер қайта жүктелмей, жадтағы ескі ядро және ескі модульмен жұмысын жалғастырады. Дискідегі пайдаланушы кітапханалары жаңа болып үлгерген. Ұзақ жұмыс істейтін кейбір процестер ескі кітапхана бейнелерін ұстайды, ал жаңа процестер жаңа файлдарды жүктейді. Қайта жүктелгенше түйінде бір пакет нұсқасымен дәл сипаттауға келмейтін бірнеше уақытша күй қатар тұрады.

Мұндай күйдегі бос емес есептеу түйінінде модульді жұмыс үстінде жаңартуға тырыспаңыз. Алдымен серверді жоспарлағыштан шығарып, тапсырмаларды аяқтап, құрылғыларды ұстап тұрған процестерді тексеріңіз. Белсенді клиенттер бар кезде nvidia, nvidia_uvm немесе amdgpu модулін түсіру әдетте орындалмайды, ал мәжбүрлі тәсілдер көрші тапсырмаларды бұзуы мүмкін. Сәтті құрастырғаннан кейін басқарылатын қайта жүктеу түсініктірек және қайталанатын нәтиже береді.

Қызметті тез қайтару қажет болса, алдын ала сақталған жұмыс ядросын оған сәйкес модульмен жүктеңіз. Ескі каталогтан тек бір .ko файлын көшірмеңіз: драйвер бірнеше модуль бөлігінен тұрады, ядро конфигурациясына тәуелді және өз тармағының пайдаланушы компоненттеріне сәйкес келуі керек. Қалпына келтіргеннен кейін сәтсіз DKMS журналын сақтаңыз, әйтпесе келесі автоматты орнату қатені қайталайды.

Бір жоғалған карта топологияны тексеруді талап етеді

Жүктелгеннен кейін сегіз картаның жетеуі жұмыс істесе, бүкіл драйверді қайта орнату көбіне тым ауқымды әрекет. Дұрыс және жоғалған картаның PCIe деңгейінен қызметтік утилитаға дейінгі жолын салыстырыңыз.

lspci -tv
lspci -s 0000:65:00.0 -vv
nvidia-smi topo -m
nvidia-smi -q -i GPU-UUID

lspci -vv ішінен желі күйі мен жылдамдығын, AER хабарларын, тағайындалған драйверді және IOMMU тобын қараңыз. Журналдан Xid немесе amdgpu қателерін іздеңіз. Бір Xid мәнін контекстсіз түсіндіруге болмайды: карта, уақыт, қайталану және қате алдындағы әрекет маңызды. Мысалы, қате тек нақты екі карта арасында дерек алмасқанда шығып, әр карта жеке сынақтан өтуі мүмкін. Онда CUDA нұсқасынан гөрі P2P жолы, PCIe коммутаторы, NVLink немесе фабриканы басқару қызметі күмәндірек.

NVSwitch жүйелерінде Fabric Manager нұсқасы драйвер тармағына сәйкес болуы керек. Бұл қызмет тоқтап тұрса немесе нұсқасы сәйкес келмесе, қолданба құрылғыларды көргенімен, ұжымдық алмасуды бастай алмауы мүмкін. Тапсырмаларды қайта іске қоспас бұрын қызмет күйі мен журналын тексеріңіз.

Әртүрлі буындағы үдеткіштер архитектура бойынша шектеу қосады. Жаңа драйвер көбіне ескі Toolkit арқылы құрастырылған кодты іске қосады, бірақ нақты Toolkit немесе фреймворк ескі compute capability қолдауын тоқтатуы мүмкін. Кері жағдай да кездеседі: бейне жаңа архитектура кодынсыз құрастырылып, ескі драйвер түсінбейтін PTX JIT компиляциясын қолданады. Модельдерді, compute capability және қолданбаны құрастыруда пайдаланылған архитектуралар тізімін жазып алыңыз.

Ұжымдық операцияларда алдымен жергілікті көрінуді картааралық байланыстан ажыратыңыз. Әр картадағы шағын есептеу процесс контекст жасай алатынын дәлелдейді. Ол NCCL, RCCL, P2P, ортақ жадты немесе желілік адаптер арқылы өтетін жолды тексермейді. Жеке сынақтар өтсе, алмасуды бір жұпта іске қосып, кейін жұптарды ауыстырыңыз. Осылай барлық картаға арналған жалпы сынаққа қарағанда топологияның ақаулы тармағы тез табылады.

Қате берген картаны физикалық орналасуымен байланыстырыңыз. UUID қолданба журналын құрылғымен, PCI мекенжайы құрылғыны слотпен, ал сервер сызбасы слотты процессор, PCIe коммутаторы және қуатпен байланыстырады. Осы үш байланыссыз «GPU 3 істемейді» деген сөздің пайдасы аз. Қайта жүктегеннен кейін бұл нөмір басқа картаға тиесілі болуы мүмкін.

AER қателеріне бөлек назар қажет. Түзетілетін хабарлар желі сапасының төмендеуін көрсетуі мүмкін, ал түзетілмейтін қателер құрылғыны шинадан алып тастай алады. Оларды бағдарламалық жинақты қайта орнатып өшірмеңіз. Есептегіштерді сақтап, картаның отыруын, райзерді, қуатты және платформа микробағдарламасын тексеріп, жүктемені қайталаңыз. Орын ауыстырғанда қате картамен бірге жүрсе, бір қорытынды шығады; слотта қалса, басқа қорытынды шығады.

Жеке картаны тек оны ұстап тұрған барлық процесс тоқтағаннан кейін және платформа осындай қалпына келтіруді қолдағанда ғана қайта бастаңыз. Linux ядросының ABI құжатында sysfs ішіндегі reset файлы функцияны жеке қалпына келтіруді қолдайтын құрылғыларда ғана болатыны жазылған. Оған 1 жазу нақты құрылғыға әсер етеді. Өндірістік серверде алдымен тапсырманы жоспарлағыштан босатып, көрші функцияларға ықпалын бағалаңыз. Жоспарсыз remove немесе rescan еншілес құрылғыларға әсер етуі мүмкін.

Карта нөмірі бойынша оқшаулау сенімсіз

CUDA_VISIBLE_DEVICES=2,3 процесс көретін карталарды шектейді, бірақ бұл пайдаланушы деңгейіндегі келісім ғана, /dev/nvidia* құрылғыларына қолжетімді процестен қорғамайды. Айнымалы көрінетін құрылғыларды қайта нөмірлейді: физикалық карта 2 процесс ішінде cuda:0 болады. Сол себепті қолданба мен түйін журналдары әртүрлі «нөлінші» картаны көрсетуі мүмкін.

CUDA Programming Guide құжаты CUDA_VISIBLE_DEVICES көрінуді де, құрылғыларды санау ретін де басқаратынын растайды. Өндірістік жоспарлағышта құрылғыларды UUID арқылы тағайындап, UUID, PCI мекенжайы және жергілікті нөмір сәйкестігін тапсырма метадеректерінде сақтаңыз.

export CUDA_DEVICE_ORDER=PCI_BUS_ID
export CUDA_VISIBLE_DEVICES=GPU-2f1...,GPU-a84...
nvidia-smi -q | grep -E 'GPU UUID|Bus Id'

Индекстер өзгермеген түйіндегі қолмен сынақ үшін ыңғайлы. Автоматты бөлуге олар әлсіз, өйткені қайта жүктегеннен кейін рет өзгеруі мүмкін. UUID мұндай өзгеріске төзеді, бірақ физикалық картаны ауыстырғанда жаңа UUID пайда болатыны түсінікті.

Оқшаулау екі деңгейде жасалуы керек. Жоспарлағыш тапсырмаға нақты үдеткіштерді бөледі, ал контейнер runtime ішке тек сәйкес құрылғылар мен кітапханаларды өткізеді. cgroup құқықтары және device nodes сол шешімді растауы керек. Пайдаланушы артықшылықты контейнерді іске қоса алса немесе барлық /dev/nvidia* құрылғысын қоса алса, орта айнымалысы еш кепілдік бермейді.

MIG бөлу бірлігін өзгертеді: жоспарлағыш ата-аналық картаны ғана емес, MIG данасының UUID мәнін тағайындауы керек. MPS басқа міндетті, процестерді қатар орындауды шешеді және өздігінен сенімсіз жалға алушылар арасында қауіпсіздік шекарасын құрмайды. Осы тетіктерді бір ғана «оқшаулау» атауына біріктіру ресурс ашылып қалуына немесе жад үшін болжамсыз бәсекеге әкеледі.

Жоспарлағыш тағайындаудың жалғыз көзі болуы керек. Kubernetes device plugin немесе Slurm картаны бөліп қойғаннан кейін оператор CUDA_VISIBLE_DEVICES мәнін қолмен берсе, екі тәуелсіз сәйкестік пайда болады. Қолданба іске қосу қабаты күткеннен басқа жергілікті нөмір алып, журнал қате UUID сақтауы мүмкін. Тағайындауды бір рет беріп, айнымалыларды содан автоматты жасаңыз.

Ұзақ тапсырмалар үшін іске қосу журналына тағайындауды сақтаңыз: тапсырма идентификаторы, түйін атауы, UUID немесе MIG UUID, PCI мекенжайы, жергілікті ordinal және контейнер digest мәні. Сонда cuda:0 failed хабарын бірнеше күннен кейін де физикалық құрылғыға байланыстыруға болады. Бұл жазбасыз қайта жүктеуден кейінгі тексеру жорамалға айналады.

Жадты оқшаулау деректі тазалаумен бірдей емес. Картаны басқа сенім аймағына бермес бұрын нақты платформаға арналған құжатталған мүмкіндік пен рәсімді қолданыңыз, оның ішінде өндіруші қолдаса, дана немесе құрылғыны қалпына келтіру бар. Процестің қалыпты аяқталуы оның контекстін босатады, бірақ әртүрлі жалға алушылар саясаты болжамға емес, құжатталған тетікке сүйенуі керек.

Тағайындағаннан кейін теріс тексеру жасаңыз. Процесс бөлінген құрылғыларды көріп, қалғанын көрмеуі керек. Бұл тек дұрыс жолды тексеруден пайдалырақ:

python3 - <<'PY'
import os, torch
print("visible_env=", os.getenv("CUDA_VISIBLE_DEVICES"))
print("device_count=", torch.cuda.device_count())
for i in range(torch.cuda.device_count()):
    print(i, torch.cuda.get_device_name(i))
PY

Контейнер ядро модулін өзімен бірге әкелмейді

Контейнер әдетте CUDA Runtime, есептеу кітапханалары мен қолданбаны қамтиды, бірақ хосттағы GPU драйвер модулін пайдаланады. Контейнер runtime драйвердің керекті пайдаланушы бөліктері мен құрылғыларын қосады. Сондықтан дұрыс бейне түйіндегі тым ескі немесе жүктелмеген модульдің орнын толтыра алмайды.

Бір сынақты үш жерде жүргізіңіз: хостта, үйлесімі белгілі ең аз бейнеде және қолданба бейнесінде. Сынақ хостта істемесе, контейнер кінәлі емес. Ең аз бейне жұмыс істеп, қолданба бейнесі істемесе, LD_LIBRARY_PATH, орнатылған кітапханалар және фреймворк құрастырылымын салыстырыңыз. Хост утилитасы карталарды көріп, екі контейнер де істемесе, runtime конфигурациясын, құрылғы құқықтарын және компонент нұсқаларын тексеріңіз.

«Сенімді болу үшін» libcuda.so файлын бейнеге көшіру өте қауіпті. Бұл кітапхана хост драйверімен байланысты және әдетте контейнер runtime тетігі арқылы келуі керек. /usr/local/lib ішіндегі ескі көшірме басым болып, жүйелік кітапхана дұрыс болса да API үйлесімсіздігін туғызуы мүмкін.

Контейнер ішіндегі диагностикалық жазба пакет нұсқаларын ғана көрсетпеуі керек:

env | grep -E 'CUDA|NVIDIA|ROCR|HIP|LD_LIBRARY_PATH'
ls -l /dev/nvidia* /dev/kfd /dev/dri/render* 2>/dev/null
ldconfig -p | grep -E 'libcuda|libcudart|libamdhip64'
python3 -c 'import torch; print(torch.__version__); print(torch.cuda.device_count())'

Хост кітапханаларының бүкіл каталогын бейне каталогының үстіне жалғамаңыз. Мұндай уақытша шешім бір бинарлық файлды түзеп, екіншісін бұзуы мүмкін. «Хост драйверінің тармағы және бейненің runtime нұсқасы» деген қолдау көрсетілетін жұпты таңдап, бейне digest мәнін жазып, қысқа есептеу сынағын қайталаңыз.

Артықшылықты режимдегі контейнер оқшаулауды тексеруге жарамайды. Ол жұмыс істеп, қалыпты контейнер істемесе, құқық жетіспейтінін ғана дәлелдедіңіз. Қосылған құрылғылар тізімін, cgroup және GPU runtime баптауларын салыстырыңыз. Толық қолжетімділікті тұрақты шешім етіп қалдырмай, нақты жетіспейтін рұқсатты қосыңыз.

Контейнерді дайындайтын түйін компонентін де тексеріңіз. Kubernetes ішінде бұл көбіне device plugin және GPU container runtime, Slurm ішінде GRES баптауы және контейнер іске қосқышы болады. Карта ауысқаннан немесе MIG өзгергеннен кейін олардың күйі ескіруі мүмкін. Конфигурацияны салыстырғаннан кейін компонентті қайта іске қосуға болады, бірақ алдымен оның журналы мен нақты UUID тізімін сақтаңыз.

Бейнені өзгеретін тегпен емес, digest арқылы тексерген дұрыс. Екі түйін бір тегпен әртүрлі қабат алып, кітапханалардың әртүрлі нұсқасын көрсетуі мүмкін. Сынақ нәтижесімен бірге digest жазу осы белгісіздікті жойып, дәл істемеген іске қосуды қайталауға мүмкіндік береді.

Қалпына келтіру түйіннен тапсырмаға қарай жүруі керек

Дұрыс қалпына келтіру реті бір уақытта өзгеретін айнымалылар санын азайтады. Алдымен жаңа тапсырма қабылдауды тоқтатып, диагностиканы сақтаңыз, содан кейін деңгейлерді бір-бірден қайтарыңыз.

1. Түйінді жоспарлағыштан босатып, GPU процестерін қалыпты аяқтаңыз және UUID, PCI мекенжайлары, нұсқалар, ядро журналы мен соңғы жұмыс конфигурациясын жазып алыңыз.
2. PCIe күтілетін құрылғы санын көрсетуіне қол жеткізіңіз. Көрсетпесе, пакеттерге өтпей тұрып платформа, қуат немесе картаның отыруын түзетіңіз.
3. Ағымдағы ядро модулін қалпына келтіріңіз: дәл тақырыптар, бір орнату тәсілі, дұрыс Secure Boot қолтаңбасы, сәтті DKMS және таза жүктелу.
4. Қызметтік утилитаны, әр картаны және топологияны тексеріңіз. Фабрикасы бар жүйеде сәйкес басқару қызметін тексеріңіз.
5. Пайдаланушы кітапханалары мен ең аз контейнерді өндіруші матрицасына сәйкестендіріп, содан кейін фреймворк пен көп карталы сынақты қайтарыңыз.

Алдыңғы ядро мен модуль сақталса және қауіпсіздік саясаты рұқсат етсе, ядроны кері қайтару қызметті тез қалпына келтіруге жарайды. Ол күшті диагностикалық белгі де береді: түйін алдыңғы ядрода жұмыс істеп, жаңасында істемейді. Бірақ серверді тіркелген ерекшеліксіз және түзету жоспарынсыз кездейсоқ ескі ядрода қалдыруға болмайды.

Пакет күйі аралас немесе бүлінген болса, драйверді толық қайта орнатуға болады. Бұған дейін орнатылған пакеттер мен файл көздерін жазып алыңыз. Атауында cuda бар барлық пакетті жоймаңыз: қолданба Toolkit дұрыс болуы және модуль ақауына қатысы болмауы мүмкін. Нақты қайшы орнату тәсілін жойып, таңдалған тармақты бір әдіспен орнатыңыз.

Жөндеуден кейін бір рет сәтті орындалған nvidia-smi жеткіліксіз. Төрт тексеру қажет: әр картадағы қысқа есептеу, жад бөлу және босату, рұқсат етілген жұптар арасындағы алмасу және өндірістегі жоспарлағыш пен контейнер түрі арқылы іске қосу. Содан кейін түйінді бақыланатын уақытта қайта жүктеп, сынақты қайталаңыз. Көптеген «жөнделген» қайшылық келесі жүктелгенде қайта шығады.

Қабылдау нәтижесін ішкі скрипт жасаған қарапайым JSON болса да, машина оқитын түрде сақтаңыз. Өрістерде уақыт, ядро, модуль нұсқасы, UUID, PCI мекенжайлары, бейне digest және әр сынақ нәтижесі болуы керек. Келесі оқиғада бұл файл нақты ненің өзгергенін көрсетеді. nvidia-smi скриншоты ортаны көрсетпейді және автоматты салыстыруға қолайсыз.

Көп карталы сынақ әлі істемесе, аумақты кішірейтіңіз: бір тапсырма, бір карта, содан кейін бір PCIe коммутаторының артындағы екі карта, кейін басқа root complex арқылы өтетін жұп. Әр іске қосуда бір ғана параметрді өзгертіңіз. Ядроны, драйверді, бейнені және NCCL баптауларын қатар ауыстыру жаңа сервер күйін жасайды, бірақ ескі ақауды түсіндірмейді.

Жүктемені біртіндеп қайтарыңыз. Алдымен бір басқарылатын тапсырма, содан кейін карталар үшін қалыпты бәсеке, тек одан кейін толық пул. Ядро журналынан Xid, AER немесе қалпына келтіру оқиғаларының қайта пайда болуын бақылаңыз. Жылу немесе қуат жүктемесінде шығатын қате бір минуттық сынақта көрінбеуі мүмкін.

Үйлесімділікті конфигурация ретінде сақтау керек

«Драйвер жеткілікті жаңа» деген тізім пайдалану үшін тым бұлыңғыр. Әр түйін класына тексерілген жинақты сақтаңыз: үдеткіш моделі мен ревизиясы, BIOS нұсқасы, ядро мен тақырыптар, драйвер тармағы, бар болса Fabric Manager, контейнер runtime, базалық бейне, CUDA немесе ROCm, фреймворк және жоспарлағыш баптаулары.

Бір пакетті шексіз қатырып қоймай, тармақты бекітіңіз. Қауіпсіздік жаңартулары қажет, бірақ олар дәл сондай топологиясы бар сынақ түйінінен өтуі керек. Сынақ міндетті түрде қайта жүктеуді қамтиды, өйткені дискідегі жаңарған пакет пен жадтағы ескі модуль алдамшы жұмыс күйін жасайды.

Жаңартуды қабылдаудың ең аз тексеруі мынадай:

• суық немесе қалыпты қайта жүктегеннен кейін UUID саны түйін паспортына сәйкес келеді;
• модуль мен пайдаланушы кітапханасы таңдалған тармаққа тиесілі;
• әр карта қысқа есептеу сынағынан өтеді;
• рұқсат етілген P2P немесе ұжымдық алмасу керекті жұптарда жұмыс істейді;
• қатар орындалған екі тапсырма бір-бірінің құрылғыларын көрмейді.

Нәтижені бейне нұсқасы және өзгеріс идентификаторымен бірге сақтаңыз. Сонда «бұрын жұмыс істеді» деген сөз салыстырылатын дерекке айналады. DKMS сәтсіздігіне, күтілетін UUID жоғалуына, фабрика қызметінің тоқтауына және қайталанатын аппараттық қатеге ескерту орнатыңыз. Температура мен жүктеме пайдалы, бірақ бағдарламалық жинақ тұтастығын бақылауды алмастырмайды.

Барлық GPU түйініндегі драйверді бірден жаңарту туралы кеңес пакет атауы бірдей болғандықтан тиімді көрінеді. Парк ішінде карта буындары, ядролар немесе фабрикалар әртүрлі болса, бұл кеңес қате. Үйлесімділік кластары бойынша жаңартып, әр класқа тексерілетін кері қайтару жолын қалдырыңыз.

Тексерілген жинақтың иесі және қайта қарау мерзімі болуы керек. Иесі болмаса, ерекшелік мәңгі қалады, ал жаңа базалық бейне ескі үдеткіш класында тексерілмей пайда болады. Матрица өзгерісін желі немесе сақтау конфигурациясы сияқты рәсімдеңіз: себеп, әсер ететін кластар, сынақ, уақыт аралығы, кері қайтару шарты және жиналған нәтиже.

Барлық компоненттің автоматты жаңаруын бұғаттау бір мәселені шешіп, екіншісін тудырады. Драйвер мен ядроны мәңгі қатыруға болмайды. Пакеттерді алуды өндіріске енгізуден бөліңіз: репозиторий түзетулерді қабылдайды, ал өндірістік класс оларды сынақтан кейін қолданады. Осылай қауіпсіздік пен қайталанатын пайдалану бір-біріне кедергі жасамайды.

Дұрыс бақылау айырманы пайдаланушы тапсырмасынан бұрын табады. Жүктелгеннен кейін түйін агенті күтілетін UUID, модуль тармағы, фабрика күйі мен қысқа сынақты тексере алады. Тексеру өтпесе, жоспарлағыш түйінді қабылдамауы керек. Жеті дұрыс картаны алып, сегізіншісінен құлаған үлкен тапсырмадан гөрі мұндай тексеру арзан.

Аппараттық және бағдарламалық контурды бірге талдау керек

Картаны ауыстырғаннан кейін қате бір PCIe слотында қайталанса, бағдарламаны қайта орнату негізгі күдік емес. Сол карта басқа слотта істемесе, күдік құрылғыға ауысады. Сервистік уақытта карталарды айқастырып ауыстыру, қуатты тексеру және AER салыстыру CUDA нұсқасын оныншы рет ауыстырудан көбірек ақпарат береді.

Жаңа серверді пайдалануға бермей тұрып базалық жазба жасаңыз: барлық UUID пен PCI мекенжайы, топология, микробағдарлама нұсқалары, әр карта сынағының нәтижесі, карталар арасындағы алмасу және қайта жүктегеннен кейінгі әрекет. Бұл паспорт тексеруді қысқартады, өйткені әкімші нақты түйіннің күтілетін күйін біледі.

GSE серверлік және AI инфрақұрылымын жобалап, біріктіреді, сондықтан үдеткіштерді, платформаны, бағдарламалық жинақты және кейінгі қолдауды алғашқы ақаудан кейін қайта құрастырмай, жеткізу кезінде-ақ үйлестіруге болады. Бұл пайдалану тәртібін жоймайды: жүйе иесі нұсқалар матрицасын, жаңартуларды және тапсырмаларды оқшаулауды бәрібір бақылауы керек.

Сервер ақау шыққан жолмен тексеруден өтпейінше, оны пулға қайтармаңыз. Мәселе тек қатар тұрған екі контейнерде пайда болса, хосттағы жеке сынақ ештеңені дәлелдемейді. Өндірістік сценарий жұмыс істеп, жаңа базалық жазба сақталып, келесі қайта жүктеу нәтижені өзгертпегенде ғана жөндеу аяқталды.