your container will show unhealthy while serving perfectly

Ինչ եք տեսնում

docker ps-ն աշխատող llama.cpp server կոնտեյները նշում է որպես unhealthy, մինչդեռ դրա հետևում կանգնած սերվերը պատասխանում է ամեն իրական հարցման։ Կոնտեյների վերագործարկումը ոչինչ չի փոխում։ docker inspect-ը ցույց է տալիս, որ ներկառուցված healthcheck-ը զոնդում է localhost:8080/health-ը, իսկ սերվերը գործարկվել է --port-ով, որին ուրիշ արժեք է տրված։

Որտեղ ենք հանդիպել

Լաբորատորիայի տուփերից մեկի վրա, 2026-ի օգոստոսի կեսերին. երկու նոր տեղակայված թեստային մոդել, գործարկված 8090 և 8091 պորտերի վրա։ Երկու կոնտեյներն էլ սպասարկելիս unhealthy էին երևում։ Տեղակայման ուղեցույցն իր սեփական Strix Halo ուղում այդ դեպքին հղում է որպես թակարդ, որտեղ ghcr.io/ggml-org/llama.cpp:server-vulkan-ն աշխատում է Ryzen AI Max+ 395 տուփի վրա։ Երկու էջերից ոչ մեկը image-ի build-ի համարը չի գրանցում; ուղեցույցն այն քաշում է tag-ով և ասում է նորից քաշել digest-ով, երբ ամեն ինչ աշխատի։

Պատճառ

Image-ը բերում է լռելյայն healthcheck, որը կոնտեյների ներսում զոնդում է localhost:8080/health-ը։ Տվեք ուրիշ --port, և սերվերը լսում է այնտեղ, իսկ զոնդը շարունակում է հարցնել 8080-ին։ Ոչ ոք չի պատասխանում, Docker-ը ստատուսի սյունակում դրոշմում է unhealthy, իսկ սյունակը «զոնդը սխալ է կարգավորված»-ի համար գույն չունի, միայն «մեռած»-ի համար։ Վերագործարկված կոնտեյները ժառանգում է նույն զոնդը, ուստի նույն կերպ էլ ձախողվում է։

Լուծում

Ուղեցույցից երկու տարբերակ. ներքին պորտը պահել 8080-ի վրա կամ վերասահմանել healthcheck-ը։ Ուղեցույցի սերվինգի հրամանն անում է առաջինը՝ --port 8080 կոնտեյների ներսում, հրապարակված որպես -p 8080:8080.

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

Եթե --port-ն այնուամենայնիվ պետք է տեղափոխել, healthcheck-ը վերասահմանեք դրան համապատասխան; ուղեցույցն այդ վերասահմանումը չի բերում։ Ապա հարցրեք պրոցեսին, ոչ թե ձեր հրամանի տողին, հոսթի այն պորտի վրա, որը հրապարակել եք (8080՝ ուղեցույցի -p 8080:8080-ի դեպքում).

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

Դա ցույց է տալիս, թե ինչ է աշխատեցնում պրոցեսը. n_ctx-ը, մոդելի ուղին, slot-երի քանակը։ Թե արդյոք այն պատասխանում է, ուղեցույցի հաջորդ քայլն է՝ իրական chat completion, որում ստուգվում են ոչ դատարկ content-ը և stop finish reason-ը։

Լաբորատորիայի harness-ի ներսում կանոնը դարձավ սա. healthcheck-երը թիրախավորում են հենց այն endpoint-ն ու պորտը, որոնց համար բջիջը կարգավորված է, և արագ ձախողվում են, երբ այն չի պատասխանում։

Բա՞ց է դեռ upstream-ում

Մենք չենք հետևում։ Աղբյուր էջերից ոչ մեկը upstream issue չի նշում։

Ապացույցներ

• Տեղակայել լոկալ LLM Strix Halo-ի վրա, Քայլ 3, պորտի նշումը սերվինգի հրամանի կողքին։
• Դաշբորդը մեկ օրում ստեց երկու անգամ՝ հակառակ ուղղություններով, «Կարմիր, բայց առողջ», դեպքն այնպես, ինչպես տեղի ունեցավ։