Ծրագրային ապահովման կառավարում¶

Այս հոդվածում

Իմ kernel-ը և դրայվերները չեն թարմացվում/տեղադրվում Ubuntu-ում

Ստանում եմ Docker Compose-ի սխալ

Բազմալեզու նեյրոնային մոդելներ, ինչպիսիք են DeepSeek R1-ը, պատասխանում են չինարեն, այլ ոչ թե անգլերեն

Նեյրոնային մոդելը OpenWebUI-ում կամ Ollama-ում երկար ժամանակ է պահանջում պատասխանելու համար

Ինչպես ամբողջությամբ հեռացնել Docker-ը տեղադրված Ubuntu օպերացիոն համակարգից

Իմ kernel-ը և դրայվերները չեն թարմացվում/տեղադրվում Ubuntu-ում¶

Նոր kernel-ի կամ դրայվերների (kernel մոդուլների) տեղադրման խնդիրը կարող է առաջանալ /boot բաժնի լցվածության պատճառով՝ համակարգի kernel-ի միաժամանակյա թարմացումների ընթացքում, ինչը կանխում է նոր սկզբնական RAM դիսկերի (initrd) ստեղծումը։ Դա ստուգելու համար կատարեք հետևյալ հրամանը.

sudo apt --fix-broken install

Եթե ելքային տվյալներում տեսնում եք սխալներ, ստուգեք /boot բաժնի լցվածության մակարդակը։ Դրա համար նայեք df -h /boot հրամանի ելքային տվյալներին.

/dev/sda2       739M  287M  398M  42% /boot

Initrd-ի հաջող վերակառուցման համար /boot բաժնի լցվածության տոկոսից առաջ գտնվող թիվը պետք է լինի 200M-ից ավելի։ Եթե ազատ տարածք չկա, կատարեք հետևյալ քայլերը.

Ստեղծեք բաժնի պահեստային պատճեն, որպեսզի կարողանաք արագ վերականգնել ֆայլերը, եթե պատահաբար ջնջեք անհրաժեշտները.
```
sudo rsync -av /boot/ /boot.old/
```

Նայեք /boot բաժնի պարունակությանը և գտեք բոլոր initrd պատկերները.

ls /boot | grep 'initrd.img-'

Դուք պետք է ստանաք նման ելքային տվյալներ.

initrd.img
initrd.img-6.8.0-57-generic
initrd.img-6.8.0-58-generic
initrd.img-6.8.0-59-generic
initrd.img-6.8.0-60-generic
initrd.img-initrd.img
initrd.img-initrd.img.old
initrd.img.old

Դուրս հանեք ավելորդ initrd պատկերները՝ թողնելով վերջին երկուսը։ Մեր դեպքում անհրաժեշտ է ջնջել initrd.img-6.8.0-57-generic և initrd.img-6.8.0-58-generic ֆայլերը։

Warning

Հետևյալ հրամանները կարող են հանգեցնել ձեր օպերացիոն համակարգի խափանման, ուստի ուշադրություն դարձրեք ջնջվող ֆայլերի տարբերակներին։ /boot բաժնում պետք է լինեն վերջին և նախավերջին kernel տարբերակների ֆայլեր։ Կարող եք ստուգել, թե որ kernel-ն եք օգտագործում uname -a հրամանով։ Եթե ինչ-որ բան սխալ լինի, կարող եք վերականգնել /boot բաժնի պարունակությունը առաջին քայլում կատարված պահեստային պատճենից՝ sudo rsync -av /boot.old/ /boot/ հրամանով։

Կատարեք դա հետևյալ հրամանով.
```
rm -f /boot/initrd.img-6.8.0-57-generic
```
Կրկնեք դա յուրաքանչյուր ֆայլի համար։

Կատարեք նույնը vmlinuz և System.map ֆայլերի համար (ըստ ցանկության).
```
rm -f /boot/vmlinuz-6.8.0-57-generic 
rm -f /boot/System.map-6.8.0-57-generic
```
Մաքրեք համակարգը հին kernel-ների հետ կապված փաթեթներից և կատարեք դրայվերների և kernel մոդուլների տեղադրումից հետո անհրաժեշտ գործողությունները հետևյալ հրամաններով.
```
sudo apt autoremove
sudo apt --fix-broken install
```
Կատարեք օպերացիոն համակարգի վերագործարկում.
```
reboot
```

Ստանում եմ Docker Compose-ի սխալ¶

Եթե Docker Compose-ի գործարկման ժամանակ ստանում եք docker: 'compose' is not a docker command կամ docker-compose: command not found սխալ, դա կարող է նշանակել, որ ձեր օպերացիոն համակարգի տարբերակը հին է, որտեղ Docker Compose-ը չի տեղադրվել որպես հավելված կամ չի ավելացվել PATH-ին։ Այս խնդիրը լուծելու համար կատարեք հետևյալ քայլերը.

Տեղադրեք Docker Compose-ը (եթե չի տեղադրված).

mkdir -p ~/.docker/cli-plugins/
curl -SL https://github.com/docker/compose/releases/latest/download/docker-compose-linux-x86_64 -o ~/.docker/cli-plugins/docker-compose
chmod +x ~/.docker/cli-plugins/docker-compose

Անհրաժեշտության դեպքում փոխարինեք latest-ը պաշտոնական պահոցի ընթացիկ տարբերակով։

Ստուգեք տեղադրումը.
```
docker-compose --version
```
Եթե հրամանը հաջողությամբ կատարվում է, Docker Compose-ը տեղադրված է։
Եթե հրամանը դեռևս չի գտնվում, համոզվեք, որ ~/.docker/cli-plugins/-ը ավելացված է PATH միջավայրի փոփոխականին։ Ավելացրեք դա ~/.bashrc կամ ~/.zshrc ֆայլերում.
```
export PATH=$PATH:~/.docker/cli-plugins/
```
Այնուհետև կատարեք.
```
source ~/.bashrc  # կամ source ~/.zshrc
```
Կրկին ստուգեք տեղադրումը.
```
docker-compose --version
```

Բազմալեզու նեյրոնային մոդելներ, ինչպիսիք են DeepSeek R1-ը, պատասխանում են չինարեն, այլ ոչ թե անգլերեն¶

Բազմալեզու մոդելների մեծ մասը, ինչպիսիք են DeepSeek-ը, երբեմն կարող են անցնել հիմնական ուսուցման լեզվին (օրինակ՝ չինարեն), նույնիսկ եթե հարցումը կատարվել է անգլերեն։ Դա տեղի է ունենում մոդելի դիստիլյացիայի, սեղմման կամ մեկ հիմնական լեզվով պատասխանների առկայության պատճառով։

Այս վարքագիծը նվազեցնելու համար խորհուրդ է տրվում հստակ նշել պատասխանի լեզուն՝ prompt հարցման վերջում ավելացնելով "Respond only in English" և այս տողը ներառելով համակարգի prompt-ում։ Խորհուրդ է տրվում նաև օգտագործել Qwen3 կամ Gemma3 մոդելներ, որոնք ցուցաբերում են ավելի մեծ կայունություն քիչ պարամետրերով տարբերակներում՝ համեմատած DeepSeek-ի հետ։

Բացի այդ, կարող եք ձեռքով ստուգել անգլերեն պատասխանները OpenWebUI գործիքների կամ ձեր չատի backend-ի միջոցով, եթե աշխատում եք API-ի միջոցով։

Նեյրոնային մոդելը OpenWebUI-ում կամ Ollama-ում երկար ժամանակ է պահանջում պատասխանելու համար¶

Եթե մոդելը երկար ժամանակ է պահանջում պատասխանելու համար, դա կարող է պայմանավորված լինել դրա չափսերով և ձեր սերվերի հզորությամբ։

Առաջին հերթին, համոզվեք, որ ձեր մոդելը ամբողջությամբ տեղավորվում է GPU-ի վիդեո հիշողության մեջ։ Օրինակ, qwen3-next:80b մոդելը 67 ԳԲ է սեղմված վիճակում (q4) և պահանջում է 80–90 ԳԲ վիդեո հիշողություն ամբողջությամբ անսեղմված վիճակում։ Եթե ձեր GPU-ն NVIDIA A5000 կամ RTX 4090 է՝ 24 ԳԲ վիդեո հիշողությամբ, Ollama-ն մոդելի շերտերի մասերը կտեղափոխի սերվերի CPU-ին, ինչը կհանգեցնի VM-ի գերբեռնվածության, միջուկների հատկացման նվազման և պատասխանների երկար ուշացումների։

Այդպիսի մոդելի հետ աշխատելու համար անհրաժեշտ են ավելի հզոր GPU-ներ, ինչպիսիք են Nvidia H100-ը՝ 80 ԳԲ վիդեո հիշողությամբ, կամ չորս RTX 4090-ների համադրությունը։ RAM-ը կարևոր է միայն RAG խնդիրների համար (աշխատելը գիտելիքների բազաների և բեռնված ֆայլերի հետ) և սովորաբար պահանջում է առնվազն 32 ԳԲ։

Կարող եք գնահատել մոդելի չափսը վիդեո հիշողության մեջ՝ բազմապատկելով դրա չափսը 2-ով, եթե մոդելը սեղմված է q4-ով, կամ 1.5-ով, եթե մոդելը սեղմված է q8-ով։ Յուրաքանչյուր լրացուցիչ 1000 token-ի համար 8000-ից ավելի համատեքստային պատուհանում ավելացրեք 1 ԳԲ անհրաժեշտ վիդեո հիշողություն։

Ձեր GPU-ի բեռնվածությունը ստուգելու համար մուտք գործեք սերվեր SSH-ի միջոցով և կատարեք ollama ps հրամանը հրամանների տողում.

[ root ]$ ollama ps 
NAME                                  ID              SIZE      PROCESSOR    UNTIL
yxchia/multilingual-e5-base:latest    f5248cae7e12    1.1 GB    100% GPU     14 minutes from now
qwen3:14b                             bdbd181c33f2    14 GB     100% GPU     14 minutes from now

Ելքային տվյալները կցուցադրեն, թե որքան տարածք է զբաղեցնում ձեր մոդելը և արդյոք այն ամբողջությամբ տեղավորվում է GPU-ում։

!!! "Note" 24 ԳԲ վիդեո հիշողությամբ GPU-ների համար խորհուրդ չի տրվում օգտագործել 14B-ից մեծ կամ q8-ից ավելի սեղմված մոդելներ։ Որքան մեծ է մոդելի պարամետրերի քանակը (ծավալը) և համատեքստային պատուհանի չափսը, այնքան երկար կտևի պատասխանման գործընթացը։

Information

Հաշվարկային արդյունավետությունը 14B մոդելների համար Nvidia A5000-ում.

Սառը մեկնարկը տևում է մոտ 30-40 վայրկյան պատասխանից առաջ։
Պատասխանման ժամանակը 10–15 վայրկյան է (առանց տրամաբանության)։
Պատասխանման ժամանակը 20-30 վայրկյան է (տրամաբանությամբ)։

Եթե օգտագործվում է RAG (Retrieval-Augmented Generation) կամ MCP, պատասխանման ժամանակը մեծանում է 5–10 վայրկյանով (տվյալների բազայի որոնման և գործիքների հարցումների համար)։

Token-ների գեներացման արագությունը ~40–45 token/վայրկյան է։ Կարող եք ստուգել դա՝ սեղմելով նշանի վրա OpenWebUI-ում չատի պատասխանի տողի ներքևում և ստուգելով response_token/s պարամետրը։

Ինչպես ամբողջությամբ հեռացնել Docker-ը տեղադրված Ubuntu օպերացիոն համակարգից¶

Մեր Ubuntu օպերացիոն համակարգի պատկերները գալիս են նախապես տեղադրված Docker-ով՝ հարմարավետության համար։ Եթե դուք դրա կարիքը չունեք կամ ցանկանում եք տեղադրել այլ տարբերակ, օգտագործեք հետևյալ հրամանները.

sudo apt remove docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo apt autoremove
sudo rm -rf /var/lib/docker
sudo rm -rf /var/lib/containerd

Համոզվեք, որ Docker-ը հեռացված է՝ կատարելով docker --version հրամանը։