Ինչպես տեղակայել լոկալ LLM Strix Halo-ի վրա (Ryzen AI Max+ 395). llama.cpp՝ զրոյից մինչև առաջին պատասխան

Սա այն տեղակայման ուղին է, որ մենք վարում ենք մեր սեփական Ryzen AI Max+ 395 մեքենաների վրա — նույն տուփերը, որ կանգնած են մեր հրապարակած թվերի հետևում։ Ոչ տեսություն, ոչ տարբերակների կատալոգ. մեկ աշխատող ուղի՝ թակարդները նշված այնտեղ, որտեղ դրանք բռնել են մեզ։ Արագության սպասումներ այստեղ միտումնավոր չկան — դրանք ապրում են հաշվետվություններում՝ չափված կարգին։

Ձեզ պետք է. Strix Halo տուփ (ցանկացած վաճառողից), Linux՝ թարմ միջուկով, Docker և սկավառակի տեղ ընտրած մոդելի համար։

Քայլ 1 — նախ բարձրացրեք հիշողության առաստաղը

Linux-ի վրա ձեր մոդելներն ապրելու են GTT-ում, ոչ թե BIOS-ում հատկացված VRAM կտորում, իսկ առաստաղը միջուկի պարամետր է։ Այս քայլը բաց թողնելը ամենատարածված պատճառն է, որ մեծ մոդելը հրաժարվում է բեռնվել այս սարքաշարի վրա։ Ստուգեք ընթացիկ սահմանը.

cat /sys/module/ttm/parameters/pages_limit

Բազմապատկեք 4 KiB-ով՝ բայթեր ստանալու համար։ Եթե ստացվածը ձեր RAM-ի ընդամենը մի մասնաբաժինն է, բարձրացրեք միջուկի հրամանային տողով (ttm.pages_limit=...) և վերաբեռնեք։ Ամբողջական բացատրությունը, թե ինչու է BIOS-ի սահիկը սխալ լծակ — մեր սերվինգ հանգույցի ցուցմունքներով — հիշողության հաշվետվությունում է։ BIOS-ի կտորը թողեք փոքր։

Քայլ 2 — վերցրեք մոդել

Ընտրեք GGUF արտեֆակտ և գրանցեք դրա ճշգրիտ ռևիզիան։ 35B դասի MoE-ն Q4_K_M-ով այն ոսկե միջինն է, որ մենք ամեն օր սպասարկում ենք այս սարքաշարի վրա. տեղ է մնում կոնտեքստի և երկրորդ մոդելի համար։ Որ քվանտն ընտրել՝ չափված հարց է; կարճ տարբերակը. սկսեք Q4_K_M-ից, ոչ թե ամենամեծ ֆայլից, որ տեղավորվում է։

mkdir -p /var/lib/llm/models
# ներբեռնեք ընտրած .gguf-ը այստեղ և գրանցեք, ՈՐՏԵՂԻՑ է այն եկել —
# պահոցը և ռևիզիան։ "main"-ը շարժվում է; ձեր գրառումները՝ ոչ։

Քայլ 3 — գործարկեք սերվերը և ամրագրեք այն

llama.cpp սերվերի Vulkan build-ն այս iGPU-ի վրա աշխատում է անմիջապես.

docker run -d --name llm-server \
  --device /dev/dri --device /dev/kfd \
  -v /var/lib/llm/models:/models \
  -p 8080:8080 \
  ghcr.io/ggml-org/llama.cpp:server-vulkan \
  -m /models/YOUR-MODEL.gguf \
  -ngl 999 -fa on -c 32768 \
  --host 0.0.0.0 --port 8080 --jinja

Երկու սովորություն, որոնք հետո ձեզ կփրկեն։ Առաջին. երբ ամեն ինչ աշխատի, image-ը նորից քաշեք digest-ով (ghcr.io/ggml-org/llama.cpp@sha256:...), ոչ թե tag-ով — tag-երը շարժվում են, և երբ ապագա թարմացումը փոխի ձեր վարքը, դուք կուզենաք ճշգրիտ իմանալ, թե որ build-ի վրա էիք։ Երկրորդ. եթե փոխում եք --port-ը, իմացեք, որ image-ի ներկառուցված healthcheck-ը ամեն դեպքում հարցնում է 8080-ին. ձեր կոնտեյները ցույց կտա unhealthy՝ միաժամանակ անթերի սպասարկելով։ Հենց այդ թակարդը մենք գրի առանք այն բանից հետո, երբ այն կծեց մեզ — կա՛մ ներքին պորտը պահեք 8080, կա՛մ վերասահմանեք healthcheck-ը։

Քայլ 4 — հարցրեք սերվերին, թե ինչ է իրականում աշխատեցնում

Մի վստահեք ձեր հրամանի տողին; վստահեք պրոցեսին.

curl -s localhost:8080/props | python3 -m json.tool | head -40

Կարդացեք n_ctx-ը, մոդելի ուղին և slot-երի քանակը։ Լռելյայն արժեքները llama.cpp-ի տարբերակների միջև փոխվում են, իսկ դրոշը, որը դուք չեք դրել, միևնույն է ձեր կոնֆիգուրացիայի մասն է — մենք դա սովորեցինք թանկ գնով։

Քայլ 5 — smoke-թեստ, որն իրոք ինչ-որ բան ապացուցում է

HTTP 200-ը դեռ ոչինչ չի ապացուցում։ Ուղարկեք իրական հարցում և ստուգեք երեք բան.

curl -s localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"Reply with one short sentence: what is inference?"}],
       "max_tokens":400,"temperature":0}' \
  | python3 -c "import json,sys; d=json.load(sys.stdin); m=d['choices'][0]['message']; \
    print('content:', repr(m.get('content','')[:120])); \
    print('finish:', d['choices'][0].get('finish_reason')); \
    print('tokens:', d.get('usage',{}).get('completion_tokens'))"

Ստուգում մեկ. content-ը դատարկ չէ։ Reasoning-մոդելը կարող է թոքենների ամբողջ բյուջեն այրել մտածելու վրա և անթերի HTTP 200-ի տակ վերադարձնել դատարկ պատասխան — մենք չափել ենք, թե որքան հաճախ; եթե դա տեսնում եք, բարձրացրեք max_tokens-ը կամ անջատեք մտածողությունը։ Ստուգում երկու. finish-ը stop է, ոչ թե length։ Ստուգում երեք. եթե երբևէ որևէ բան չափելու եք, թոքենները հաշվեք usage.completion_tokens-ից — երբեք streaming-իրադարձությունների քանակից։

Քայլ 6 — որոշեք reasoning-ռեժիմի հարցը

Եթե ձեր մոդելն ունի մտածողության ռեժիմ, գիտակցաբար որոշեք՝ այն միացված մնո՞ւմ է։ Ամենօրյա չատի և կառուցվածքային ավտոմատացման համար այս սարքաշարի վրա մենք չափել ենք, ինչ է այն արժենում և ինչ է տալիս — կարդացեք դա, նախքան լռելյայնը ձեր օգտատերերին հանձնելը։

Հաջորդ քայլերը

• Backend-ի ընտրություն. Vulkan-ը մեր սերվինգ լռելյայնն է այս սարքաշարի վրա; ROCm համեմատությունը ցույց է տալիս, թե ինչ է տալիս ամեն մեկը։
• Ավելի շատ օգտատերեր. նախքան տուփը թիմին խոստանալը, կարդացեք զուգահեռության սանդուղքը։
• Ստուգեք ձեր սեփական թվերը. մեր հաշվետվությունների հետևում կանգնած workload-ները բաց են — գործարկեք դրանք ձեր թարմ սերվերի վրա և համեմատեք մեր claim-երի հետ։