September 2026 • Product

Dauguma išvadų (inference) paslaugų naudoja tik dalį GPU, o visa plokštė dažnai yra daugiau, nei reikia užrašų knygelei, paketiniam vertinimui ar nedideliam modeliui. Vienos plokštės dalijimasis tarp darbo krūvių skamba paprastai, tačiau Kubernetes to pagal numatytuosius nustatymus nedaro, o skirtingi būdai tai daryti žada labai skirtingus dalykus. Šiame straipsnyje paaiškiname tuos pažadus, ką bendra GPU dalis Kube-DC garantuoja ir ko negarantuoja, ir ką sužinojome paleidę tikrą LLM ant jos.

Kubernetes pagal numatytuosius nustatymus išdalija visus GPU

Standartinis Kubernetes įrenginių papildinių (device plugin) modelis praneša planuokliui apie GPU kaip apie sveikuosius skaičius. Užklausa nvidia.com/gpu: 1 reiškia visą plokštę, o visi kiti podai laukia. Planuoklis neturi atminties kvotos sąvokos, todėl plokštės dalijimuisi reikia papildomų mechanizmų, ir yra trys įprasti būdai.

Būdas Atminties riba Izoliacija Ar veikia su V100?
MIG (aparatinis skaidymas) Užtikrinama aparatūroje Atminties ir gedimų izoliacija aparatūros lygiu Ne: reikalinga Ampere ar naujesnė karta (A100, H100, A30, H200), o V100 yra senesnė, Volta kartos plokštė
Laiko dalijimas (time-slicing) Jokios: replikos dalijasi plokštės atmintimi Tarp replikų nėra atminties ir gedimų izoliacijos, pagal NVIDIA dokumentaciją Taip
Programinis skaidymas (HAMi) Užtikrinama programiškai: viršijančios dalį atminties užklausos atmetamos Programinė izoliacija perimant CUDA API; ne aparatinė izoliacija, o skaičiavimai ribojami geriausių pastangų principu Taip

HAMi, Cloud Native Computing Foundation projektas, veikia į kiekvieną konteinerį įkeldamas biblioteką, kuri perima CUDA iškvietimus. Konteineris mato tik savo atminties dalį, užklausa, kuri viršytų dalį, grąžina atminties trūkumo klaidą, o branduolių (kernel) paleidimai ribojami link užklausto skaičiavimo dalies. Pati HAMi dokumentacija atsargiai kalba apie ribas: programos, kurios apeina CUDA biblioteką, pavyzdžiui, Docker-in-Docker ar tiesioginiai tvarkyklės iškvietimai, neapimamos, o izoliacija, palyginti su MIG, yra geriausių pastangų.

Ką bendra dalis Kube-DC garantuoja

Kube-DC GPU paketuose naudojamas programinis skaidymas NVIDIA V100 plokštėse, o platformos dokumentacija garantijas nurodo tiksliai. Dalis yra fiksuota vieno GPU modelio dalis; užsakote produktą, o ne laisvai derinate atmintį ir skaičiavimą. 32 GB V100 mūsų paketai siūlo 25 % (8 GiB), 50 % (16 GiB) ir 100 % (32 GiB).

  • Atminties dalis užtikrinama griežtai. Konteinerio viduje nvidia-smi rodo dalies dydį, o ne fizinės plokštės, ir dalis yra griežta riba.
  • Skaičiavimo dalis yra kooperatyvi. Platforma nukreipia kiekvieną darbo krūvį link jo dalies nusistovėjusiu režimu, tačiau paleidimo metu ir kai kuriuose CUDA bibliotekų keliuose ją galima trumpam viršyti. Tai nėra garantuotas našumas.
  • Kvota yra teisė, o ne rezervacija. Kvotos turėjimas nerezervuoja fizinės dalies. Kai visi suderinami GPU užimti, tinkamas darbo krūvis laukia Pending būsenoje, kol atsilaisvins dalis.
  • Dalys skirtos konteineriams. Bendros galios negalima prijungti prie virtualios mašinos.
Bendra dalis yra planavimo ir apskaitos garantija su užtikrinimu vykdymo metu. Tai nėra saugumo riba. Darbo krūviui, kuris negali dalytis silicio su kitu nuomininku, reikia dedikuoto GPU.

Kaip atrodo naudojimas

Nuo Kubernetes 1.34 Dynamic Resource Allocation (DRA) API, esančios resource.k8s.io/v1, yra bendrai prieinamos, ir Kube-DC jas naudoja: darbo krūvis nurodo ResourceClaimTemplate, kuris rodo į jūsų produkto DeviceClass, o platforma užklausą patikrina ją pritaikius. Jūsų projekto kvota rodo, kiek kiekvieno produkto dalių galite turėti vienu metu:

kubectl get resourcequota -n <project-namespace> -o yaml | grep deviceclass

Kai jūsų podas veikia, patikrinkite dalį konteinerio viduje. 8 GiB produkte bendra atmintis yra 8192 MiB, nors plokštė turi 32 GB:

nvidia-smi --query-gpu=name,memory.total --format=csv,noheader
# Tesla V100-PCIE-32GB, 8192 MiB

Pilnas nukopijuojamas ir pritaikomas manifestas yra Kube-DC dokumentacijoje, ir sąmoningai jo čia neatkartojame, nes jis turi tiksliai atitikti platformos paskelbtą sutartį. Mūsų pačių bandyme dvi pastangos dėl šios priežasties nepavyko, kol trečioji pavyko:

  • Paprasta nvidia.com/gpu užklausa žaliame pode buvo atmesta priėmimo politikos, nes bendra GPU galia siūloma tik per claim (užklausų) šabloną.
  • Ranka parašytas DRA užklausos šablonas buvo atmestas antros priėmimo politikos, nes etiketės, pavadinimai ir fiksuotos talpos reikšmės turi atitikti dokumentuotą formą.
  • Dokumentuotas manifestas buvo priimtas, tada podas nepasileido dėl nesusijusios priežasties: bendra projekto CPU kvota beveik visiškai buvo išnaudota valdomo klasterio ir virtualios mašinos. GPU podui vis tiek reikia CPU ir atminties iš jūsų paketo, todėl prieš diegdami patikrinkite šį rezervą.

LLM paleidimas ant dalies: ką sužinojome

Mūsų 2026 m. rugpjūčio pilname bandyme paleidome Ollama ant 8 GiB dalies ir aptarnavome llama3.2:3b, tada prijungėme DI agentą, pirmiausia iš to paties projekto virtualios mašinos, o vėliau iš serverio už duomenų centro ribų. Ollama žurnaluose plokštė matėsi kaip Tesla V100 su skaičiavimo galimybe 7.0 ir 8,0 GiB iš viso, lygiai tiek, kiek dalis. Keturios smulkmenos kainavo mums laiko, ir kiekviena aktuali visiems, kas paleidžia modelį ant dalies.

1. Patikrinkite, ar jūsų programinė įranga vis dar palaiko GPU kartą

V100 yra Volta kartos plokštė, o dabartinė GPU programinė įranga pradėjo eiti toliau. Mūsų bandyme naujausias Ollama atvaizdas praleido GPU, nes jo CUDA versijoje nebuvo skaičiavimo galimybės 7.0. Užfiksavus ollama/ollama:0.24.0 problema išsisprendė. Tai atitinka upstream pranešimus: Ollama pranešime aprašoma, kad v0.30.0 neveikia su Tesla V100 su klaida „device kernel image is invalid“, o v0.24.0 ir ankstesnės versijos veikė, o prižiūrėtojas vėliau vieną tokį gedimą priskyrė suspaustiems CUDA branduoliams, kuriems reikia NVIDIA tvarkyklės 550 ar naujesnės. Užfiksuokite atvaizdo versiją ir atnaujinimus išbandykite sąmoningai.

2. Podo atminties riba yra atskira nuo GPU dalies

Mūsų pirmas modelio įkėlimas buvo nutrauktas su išėjimo kodu 137 (OOMKilled). Priežastis buvo paties konteinerio 512 MiB atminties riba, kuri per maža Ollama pagrindinio kompiuterio pusės pridėtinėms sąnaudoms ir neturėjo nieko bendra su GPU atmintimi. Konteinerio RAM užklausą ir ribą nustatykite nepriklausomai nuo fiksuotos dalies. Mes naudojome 2 GiB ir 4 GiB:

containers:
- name: ollama
  image: ollama/ollama:0.24.0
  env:
  - name: OLLAMA_CONTEXT_LENGTH
    value: "16384"
  resources:
    requests:
      memory: 2Gi
    limits:
      memory: 4Gi

3. Numatytasis konteksto langas gali tyliai apkarpyti agento užklausą

Mūsų prijungtas agentas siunčia sistemos užklausą ir įrankių apibrėžimus, kurių dydis apie 14 700 žetonų. Ollama serverio žurnale matėsi, kaip įvestis apkarpoma iki 4 096 žetonų ribos, o tai sukėlė sumaišytus, nepatikimus atsakymus, kurie atrodė kaip modelio kokybės problema. Konteksto ilgio padidinimas aukščiau nurodytu kintamuoju pašalino priežastį. Atminkite, kad ilgesnis kontekstas naudoja daugiau jūsų dalies atminties, todėl modelio ir konteksto dydį parinkite kartu.

4. Modeliai gyvena pode, nebent suteikiate jiems tomą

Su numatytąja laikinąja saugykla kiekvienas podo paleidimas iš naujo, įskaitant sukeltą aplinkos kintamojo pakeitimo, ištrindavo atsisiųstus modelius. Viskam, kas daugiau nei demonstracija, modelių katalogą padėkite ant nuolatinio tomo. Taip pat atkreipkite dėmesį, kad nuomininko vaidmenys Kube-DC negali naudoti kubectl exec, todėl modelius atsisiuntėme vienkartiniais Job, kurie kreipiasi į Ollama HTTP API.

Kada bendra dalis yra tinkamas įrankis

Kube-DC dokumentacija įvardija tinkamumą: modelių išvados (inference), užrašų knygelės, nedideli mokymai ir paketinis vertinimas, kai užduočiai reikia GPU spartinimo, bet ne visos plokštės. Ji prastai tinka, kai reikia griežtos izoliacijos ribos, garantuoto pralaidumo ar didesnio už dalį modelio, o visos plokštės darbai priklauso dedikuotai aparatūrai. Kadangi dalys stovi eilėje, kai plokštė užimta, ji taip pat labiau tinka darbo krūviams, kurie gali palaukti galios, nei delsai jautrioms paslaugoms su griežtais terminais.

Kaip įvertinti bet kokį bendro GPU pasiūlymą

  • Ar atminties riba užtikrinama, ar tai tik pasiūlymas? Laiko dalijimas neužtikrina jokios.
  • Ar skaičiavimo dalis garantuota, kooperatyvi ar neribota, ir kas nutinka esant konkurencijai?
  • Ar kvota yra rezervacija, ar jūsų darbo krūvis gali laukti Pending būsenoje, kai plokštė užimta?
  • Koks tai GPU modelis ir ar programinė įranga, kurią planuojate paleisti, vis dar palaiko tą kartą?
  • Ar galite gauti visą plokštę ar dedikuotą VM, jei dalies nebepakanka, ir kaip ten atrodo izoliacija?
  • Kokį CPU, atmintį ir saugyklą gaunate kartu su GPU ir ar jie bendri su likusiais jūsų darbo krūviais?

Šaltiniai

Susiję skaitiniai

Išbandykite Kube-DC

Mūsų GPU paketai prie Kube-DC telkinio prideda bendro NVIDIA V100 dalį: 25 %, 50 % arba 100 % plokštės, su užtikrinama atminties dalimi. Kartu gaunate dedikuotus vCPU, Ceph pagrįstą NVMe saugyklą, dedikuotą viešąjį IPv4, su S3 suderinamą objektų saugyklą ir savo nuomininko valdomus Kubernetes klasterius, su 24/7 pagalba el. paštu ir per užklausas bei 4 valandų sprendimo tikslu. Ant jo pilnai paleidome tikrą LLM ir DI agentą, ir kiekvieną šio straipsnio žingsnį galite pakartoti.

Susipažinkite su Kube-DC Kubernetes