Anbefalinger til ydeevne- og hukommelsesstyring for Ollama

  • Prioriteten er at sikre, at de anvendte modeller passer 100 % interaktivt ind i VRAM for at undgå betydelige ydelsesfald.
  • Kvantisering, kontekstlængde og modelvalg påvirker både kvalitet og hukommelsesforbrug.
  • Ollama forenkler styringen af ​​modeller og ressourcer sammenlignet med llama.cpp, på bekostning af en lidt mindre finkontrol.
  • En afbalanceret hardwareopsætning med hensyn til VRAM, RAM, CPU og disk muliggør et levedygtigt og problemfrit privat SaaS-tilbud af LLM'er.
Lorena Figueredo

15 minutter

Anbefalinger til ydeevne- og hukommelsesstyring for Ollama

Hvis du overvejer at oprette en Privat LLM-uddannelse hos OllamaUanset om det er din egen internetudbyder på landet, et lille datacenter eller en kraftfuld pc derhjemme, er det store spørgsmål altid det samme: hvordan får du mest muligt ud af din ydeevne uden at spilde penge på hardware, du ikke bruger?

I verden af ​​store sprogmodeller, VRAM, RAM, CPU, GPU, kvantisering og kontekst Dette er ikke bare teknisk jargon: det er de elementer, der afgør, om din klynge kører hurtigt eller hurtigt. Desuden administrerer Ollama og llama.cpp hukommelse og CPU/GPU-allokering forskelligt, og det er vigtigt at forstå dette for at afgøre, om en stor node med flere GPU'er eller flere mere beskedne 1:1-maskiner pr. klient er mere omkostningseffektiv.

Gruppering af GPU'er i en klynge eller dedikering af dem 1:1: hvad der er bedst for Ollama

Når du overvejer en privat SaaS med Ollama, er det første dilemma, om du skal oprette en centraliseret GPU-pulje eller tildel en maskine (eller GPU) pr. klient. Det er her, hvordan Ollama og llama.cpp bruger ressourcer, kommer i spil:

  • "Monster"-node med flere GPU'erIdeelt, hvis du ønsker delte anmodningskøer, for at udnytte GPU'en fuldt ud med mange samtidige brugere og for at konsolidere administration og vedligeholdelse.
  • 1:1 maskiner pr. kundeMere isolation, mindre besvær med flere lejere, forudsigeligt ressourceforbrug og meget bekvemt for kunder, der betaler for "deres" maskine.

Ollamama fokuserer i øjeblikket mere på udnytte en eller flere lokale GPU'er pr. instans end at orkestrere en distribueret Kubernetes-lignende klynge med finjusteret load balancing mellem maskiner. For en lille internetudbyder, der ønsker at betjene "superbrugere":

  • Hvis målet er operationel enkelhedEt par maskiner af god størrelse (16-24 GB VRAM hver) med Ollama pr. node og klientfordeling pr. server er normalt den mest fornuftige løsning.
  • Hvis du vil lege "mini-hyperscaler", kan du foreslå en stor server med flere GPU'er og en proxy (eller flere instanser af Ollama/llama.cpp) for hver klient, men kompleksiteten af ​​planlægning og isolering øges betydeligt.

Den afgørende faktor er ikke kun topologien, men Hvilke modeller vil du betjene, i hvilken kontekst, og hvor mange samtidige sessioner?Det bestemmer direkte, hvor meget VRAM du har brug for pr. bruger.

Sådan administrerer Ollama hukommelse, VRAM og CPU/GPU-deling

Ollama er internt afhængig af llama.cpp og andre backendsMen det tilføjer et lag af orkestrering, der i høj grad forenkler dit liv. Med hensyn til hukommelse og ydeevne er der flere vigtige punkter:

Modelkortlægning og hukommelsesindlæsning

llama.cpp usa mmap at knytte modellens GGUF-fil til adresserummet. Dette tillader Operativsystemet bestemmer, hvilke dele der rent faktisk er i RAM'en i hvert øjeblik, hvilket reducerer den indledende indlæsningstid sammenlignet med at dumpe hele filen i hukommelsen på én gang.

Ollama er på sin side ansvarlig for:

  • Upload og download modeller af VRAM/RAM i henhold til aktivitet, under hensyntagen til tidspunktet for OLLAMA_KEEP_ALIVE.
  • Del modeller mellem sessioner af den samme instans for undgå unødvendige opladninger.
  • Vis dig selv med ollama ps hukommelsesforbrug, division CPU / GPU og hvis der er aflastning af lag til processoren.

I praksis, når man ser en model med f.eks. 18%/82% CPU/GPUDet betyder, at en del af lagene ikke passede i VRAM og bliver udført i system-RAM via CPU'en, med den deraf følgende indvirkning på hastigheden, som flere eksempler viser. latensanalyse i lokale netværk.

Hvad sker der, hvis modellen ikke passer i VRAM?

Her er et af de vigtigste spørgsmål: hvis en model går fuldt ud ind i VRAM, får du det forventede afkast på 100%Men når modellen overstiger den tilgængelige VRAM, fordeler Ollama lag mellem GPU'en og CPU'en. Forringes ydeevnen proportionalt med antallet af lag, der overføres til RAM, eller låser den dig fuldstændigt fast i RAM- og bushastigheden?

Praktiske data med en RTX 4080 16GB De er ødelæggende:

  • 100% GPU-modelleri størrelsesordenen 60 til 140 tokens/s (f.eks. når gpt-oss:20b med 14 GB brugt ~140 tok/s).
  • Modeller 70-80% GPU (hvile i CPU'en): falder til ~19-50 tok/s.
  • Modeller med ~20% GPU (mest på CPU'en): de holder sig på ~12 tok/s (gpt-oss-kabinet: 120b, 66 GB RAM+VRAM brugt).

Med andre ord er det ikke blot et spørgsmål om "jeg mister 30% af ydeevnen, fordi 30% er i CPU'en", men snarere Latensen ved at flytte data mellem RAM og VRAM og udføre lag på CPU'en multiplicerer flaskehalsen.En opsætning udelukkende baseret på 20B GPU kan være 10-11 gange hurtigere end en opsætning primært baseret på 120B CPU'er.

Så, for din klynge: Det primære mål er at integrere kritiske interaktive brugsmodeller fuldstændigt i VRAMAlt, der ikke passer ind, reserveres bedst til batch-, natlige eller lavprioriterede opgaver.

MoE (Mixture of Experts) modeller og CPU-aflastning

Typemodeller Blanding af eksperter (som GLM 4.7 Flash eller nogle Qwen- og DeepSeek-instanser) har mange samlede parametre, men aktiverer kun en brøkdel af eksperter pr. token. Dette kan i teorien hjælpe i scenarier med begrænset VRAM, fordi Ikke alle dele af modellen bruges på samme tid..

I praksis med Ollama:

  • En MoE på 30B-A3B (30B i alt, 3B aktiv) som glm-4.7-flash Den bevæger sig omkring 30-35 tok/s med delvis CPU-offload, hvilket er ret respektabelt for sin størrelse.
  • MoE-fordelen kompenserer ikke, hvis modellen fortsætter med at overskride VRAM og tvinger mange lag til at blive flyttet på tværs af bussen.
  • Ollama "forstår" ikke MoE som noget særligt på scheduler-niveau; den ser blot lag og hukommelse. Magien ved MoE ligger i modellens arkitektur, ikke i Ollama.

Praktisk konklusion: MoE hjælper, men det gør ikke mirakler.Hvis du overskrider VRAM-grænsen betydeligt, vil du fortsætte med at betale prisen for RAM- og CPU-forbrug. Det er bedre at bruge MoE til at presse grænserne lidt længere, ikke for altid at retfærdiggøre at arbejde uden for VRAM.

Llama.cpp vs. Ollama sammenligning for at få mest muligt ud af din hardware

Mange diskussioner starter med det typiske spørgsmål: "Hvorfor bruge Ollama og ikke llama.cpp direkte?" Med hensyn til ydeevne og hukommelsesstyring er det værd at skelne tydeligt mellem hver enkelts roller.

llama.cpp: tensorernes operationsstue

llama.cpp er den højtydende C++-motorDens mål er at presse den mindste bid af ydeevne ud af CPU'en og GPU'en, med særlig fokus på x86 CPU'er med AVX, Apple Silicon og NVIDIA/AMD GPU'er. Den er designet til dem, der ønsker at:

  • Justere kvantisering i detaljer (Q4_K_M, Q5_0, Q8_0, Q2_K…).
  • kontrol antal lag i GPU'en med --n-gpu-layers.
  • håndtere sammenhæng, batch, antal tråde, GBNF-grammatikker og andre fine parametre.

Lavt niveau, ja, men meget kraftfuldt. Med hensyn til hukommelse:

  • Brug mmap at indlæse modellen og lade kernen bestemme, hvad der gemmes i RAM'en.
  • Det giver dig mulighed for præcist at vælge, hvilke lag der sendes til GPU'en med -ngl, justering af VRAM-forbruget til millimeteren.
  • Integra K-kvanter at reducere størrelsen med mindst mulig påvirkning af kvaliteten.

Kort sagt: llama.cpp er perfekt, hvis du vil Byg din egen superoptimerede tjeneste hvor du styrer alle parametre og ikke har noget imod at få beskidte hænder med kommandolinjeindstillinger og avanceret konfiguration.

Ollama: backend-orkestratoren

Ollama er skrevet i Go og bruger llama.cpp (og andre motorer som vLLM i nogle scenarier) som backend. Formålet er at give dig en Oplevelsen er af typen "Docker til modeller":

  • simpel CLI: ollama pull, ollama run, ollama list, ollama ps.
  • REST API en 127.0.0.1:11434 Som standard er den klar til at forbinde GUI'er som Open WebUI eller dine egne applikationer.
  • ModelstyringDownload fra din registreringsdatabase, opdatering, lokal lagring, kopiering og udsendelse af dine egne modeller.
  • Automatisk hardwaredetektionAnalyserer GPU, RAM og kontekst for at justere GPU/CPU-lag uden at du behøver at røre ved dem. --n-gpu-layers.

Den virkelige forskel er abstraktionsniveaullama.cpp er den rå motor, Ollama er den komplette, køreklare bil. Til gengæld for lidt mindre ekstrem kontrol får du:

  • Start modeller med en enkelt kommando.
  • Anmodningskøer og automatisk download efter inaktivitet (OLLAMA_KEEP_ALIVE).
  • Direkte integration med GUI'er og frameworks.

For en slutbruger eller for at yde generel service til internetudbyderkunder, Ollama er normalt det klare valgFor meget stramme XXL-modeller eller for at få mest muligt ud af en specifik GPU, kan llama.cpp have en lille fordel, hvis du ved, hvordan du finjusterer den godt.

Hardwareanbefalinger: VRAM, RAM, CPU og disk til Ollama

Anbefalinger til ydeevne- og hukommelsesstyring for Ollama

For at dimensionere din klynge er det ikke nok bare at se på GPU'en. Balancen mellem VRAM, RAM, CPU, disk og kontekst Han har mere magt, end det ser ud til.

VRAM: den kritiske ressource

VRAM er den største flaskehals. Kun til vejledning:

  • 8 GB VRAMtilstrækkelig til små/mellemstore kvantiserede modeller (7B, nogle 13B i Q4_K_M med beskeden kontekst).
  • 16 GB VRAM: nuværende sweet spot til seriøs brug: 14B, 20B, 24B i Q4_K_M fuldt på GPU med ~16-32K kontekster.
  • 24 GB eller mereNødvendigt, hvis du ønsker 30B-35B med bred GPU-kontekst eller for at håndtere flere samtidige sessioner af mellemstore modeller uden at begynde at aflaste lag.

Nogle praktiske værdier på et RTX 4080 16 GB med en ~19K kontekst og Q4_K_M kvantisering:

  • gpt-oss:20b (20B): ~14 GB, 100 % GPU, ~140 tok/s.
  • qwen3:14b: ~12 GB, 100 % GPU, ~62 tok/s.
  • mistral-3:14b: ~13 GB, 100 % GPU, ~70 tok/s.

Enhver model, der overskrider disse grænser, ender med at blande CPU/GPU. Hvis du i dit projekt vil give en stor kontekst, f.eks. 80-100K, til flere brugere, Hvert spring i kontekst øger også det effektive forbrug af VRAMfordi KV-cachen vokser.

System-RAM og CPU'er: vigtigere end de ser ud til

Når Ollama aflaster lag til CPU'en, vil din processoren bliver en del af inferensmotorenI test med en i7-14700 (8P+12E) og 64 GB DDR5-6000:

  • Modeller med 20-30% CPU-lag er stadig brugbare (~30-50 tok/s).
  • Når CPU-forbrugsprocenten stiger til over 50 %, begynder chatoplevelsen at føles træg, især hvis konteksten er stor.

Fornuftige anbefalinger til en servicenode:

  • Minimum RAM 16 GBkun til at lege med lys 7B og 13B.
  • Anbefalet RAM 32-64 GBTil seriøs flerbrugerbrug med 14-24B-modeller og bred kontekst.
  • CPU med mindst 8 kerner (eller moderne P+E-kombination) for at dæmpe lagaflastning uden knudekollaps, og også overveje hvordan konfigurere ydeevneprofiler i Windows-systemer, hvis det er relevant.

Album: Den tavse elefant

Modelfilerne er utroligt store. Kvantisering hjælper, men alligevel:

  • Små kvantiserede modeller~2 GB.
  • Kvantiserede medianmodeller: 5-20 GB.
  • Store modellernemt 40-200 GB eller mere; der er kontrolpunkter, der overstiger 1 TB.

Som en hurtig regel, reserver altid en margin på mindst 2-3 gange størrelsen af ​​hver model mellem basisfil, varianter, cacher og logfiler, og evaluerer muligheder for lokal lagring versus hybrid cloudOg brug NVMe SSDmmaps indlæsningstider og paginering drager stor fordel af dette.

Kvantificering, kontekst og modelvalg: direkte indflydelse på præstation

Selvom det nogle gange overses, kvantisering som du vælger, og kontekstlængde De gør en kæmpe forskel i hukommelsesforbrug og hastighed.

Kvantiseringens "Rosettasten"

Forenklet set kan man tænke på disse variationer:

  • FP16Model med næsten ingen komprimering, maksimal kvalitet, massiv størrelse. Kræver meget VRAM/RAM.
  • Q8_0: blid kompression, kvalitet næsten identisk med FP16, men stadig stor i størrelse.
  • Q4_K_Mden "afbalancerede" standard til lokal brug. Reducer størrelsen med halvdelen med kun et gennemsnitligt nøjagtighedstab på ~1-2%. Det er den anbefalede mulighed for de fleste implementeringer.
  • Q2_Kekstrem kompression, minimal størrelse, men modellen bliver tydeligt mindre pålidelig med flere hallucinationer.

I praksis, for en lokal SaaS med flere klienter, Vælg Q4_K_M-modellerne Den tilbyder det bedste forhold mellem kvalitet/ydelse/VRAM-forbrug. Q8_0 er nyttig, hvis du har meget VRAM og ønsker at presse lidt mere kvalitet ud af en lille/mellemstor model.

Kontekstlængde (num_ctx) og dens skjulte omkostninger

Parameter num_ctx Ollama/llama.cpp definerer, hvor mange tokens modellen kan "se" på én gang: system, chathistorik, aktuel prompt og svar. På et konceptuelt niveau:

  • Små vinduer (2K-4K): mindre hukommelse, mere hastighed, men du mister kontekst i lange samtaler eller store dokumenter.
  • Mellemstore vinduer (8K-32K): et rimeligt mellempunkt til de fleste professionelle anvendelser.
  • Gigantiske vinduer (64K-128K+): spektakulære på papiret, men bruger meget mere VRAM og forringer ydeevnen, hvis hardwaren allerede er på sit grænse.

Desuden, hvis du tvinger en num_ctx højere end den kontekst, som modellen blev trænet medDu kan opleve usædvanlig opførsel og et fald i kvaliteten. Det er ikke nok blot at øge værdien i indstillingerne; der er en arkitektonisk begrænsning.

I dit scenarie er det fornuftige at gøre følgende:

  • tilbud "Normale" planer med 8K-16K kontekstsom passer godt ind i VRAM.
  • Book 64K-100K kontekster kun for premium-maskiner eller GPU'er, og accepter drop-in tokens/s.

Bedste fremgangsmåder til ydeevne- og hukommelsesstyring med Ollama

Ud over hardwaren er der adskillige konfigurations- og arkitekturbeslutninger, der kan gøre hele forskellen for at sikre, at din klynge kører problemfrit.

Sørg for, at kritiske modeller kører 100% på GPU'en

Før en model gives til en klient, er det tilrådeligt at teste og kontrollere den med ollama ps at PROCESSOR-feltet angiver 100% GPU når den er i brug. Hvis du ser 60/40 CPU/GPU-forskelle eller værre, skal du trykke på:

  • Skift til en mere aggressiv kvantisering (for eksempel fra Q8_0 til Q4_K_M).
  • Brug en mindre model (for eksempel 20B i stedet for 35B).
  • reducere num_ctx hvis klienten kan leve med en noget mindre kontekst.

En velafstemt 20B med 140 tok/s er at foretrække frem for en 120B, der kravler med 12 tok/s til interaktiv chat. Brugere værdsætter sidstnævnte meget mere. oplevelsens flydendehed at en hypotetisk kvalitetsforbedring ville være vanskelig at opfatte.

Juster OLLAMA_KEEP_ALIVE og den indlæste modelstrategi

Parameter OLLAMA_KEEP_ALIVE Definerer hvor længe Ollama gemmer en model i hukommelsen efter den sidste anmodning. Mulige værdier:

  • 0Den downloades umiddelbart efter svaret er fuldført. Dette sparer hukommelse, men resulterer i længere indlæsningstider.
  • X m (f.eks. 5m, 15m): Balancerer RAM/VRAM og agilitet. Ideel til tjenester med lejlighedsvise stigninger.
  • -1Modellen forbliver indlæst, mens tjenesten er aktiv. Meget nyttigt til dine flagskibs SaaS-modeller.

I et flerbrugerscenarie fungerer det normalt godt at vedligeholde en eller to basismodeller er altid indlæst (for eksempel en generalist 14B og en kode en) og download resten efter et par minutters inaktivitet.

Kontrol af miljøvariabler og modelstier

Ollama giver dig mulighed for at justere dens opførsel med forskellige miljøvariabler, der påvirker, hvordan ressourcer og adgang administreres:

  • OVNMODELLER: sti hvor modellerne er gemt. Nyttig til at sende dem til en dedikeret harddisk/SSD med højere kapacitet.
  • OLLAMA_HOSTAPI-grænseflade og port (standard 127.0.0.1:11434). Hvis du eksponerer den for LAN'et, skal du begrænse adgangen med firewallen.
  • OLLAMA_ORIGINSCORS til eksterne web-GUI'er (Åben WebUI, brugerdefinerede paneler osv.).
  • OLLAMA_DEBUGDebug-tilstand til at se detaljerede logfiler over modelindlæsning, GPU-detektion, CUDA/ROCm-fejl osv.

I Linux konfigureres disse parametre normalt vha. systemd (med systemctl edit ollama.service), mens de i Windows og macOS er indstillet som system- eller brugermiljøvariabler.

Overvågning og logfiler

I en klynge skal du have en klar forståelse af, hvad der sker på hver node. Sådan gør du:

  • På Linux, brug journalctl -u ollama at overvåge serviceloggene. Med -f Du ser det i realtid.
  • Suppler med nvidia-smi eller tilsvarende i AMD for at se VRAM, GPU-belastning og strømforbrug.
  • Integrer metrikker (tokens/s, køer, fejl) i din observerbarhedsstak, hvis du er seriøs omkring SaaS.

Tidlig opdagelse af, at en model primært kører på CPU'en, eller at køer sidder fast, sparer dig for en masse problemer med klienter; og værktøjer til find IP-adressen på dit lokale netværk De kan hjælpe med nodeopgørelsen.

Udvalg af modeller og typiske anvendelsesscenarier i Ollama

Med alt ovenstående er den anden søjle for præstation vælg den rigtige model til hver opgaveikke kun for at "gå i fuld fart", men også for at kontrollere forbrug og latenstid.

Skabeloner til generel chat og assistenter

Til samtaler, support, e-mailskrivning, resuméer og generelle opgaver, skabeloner som f.eks.:

  • Qwen3 14BFremragende instruktionssporing og god hastighed ved 100% GPU-brug.
  • Mistral 3 14Bmeget afbalanceret i sproglig kvalitet og præstation.
  • Gemma og Llama 3.x I 7-14B-konfigurationer: gode generalistmuligheder for mindre krævende brugere eller mere grundlæggende hardware.

Med disse familier i Q4_K_M og 8K-16K kontekst har du et solidt fundament for langt de fleste professionelle brugere uden at overbelaste VRAM'en.

Modeller til kodning og udvikling

Til kodegenerering, gennemgang og udviklingsopgaver anbefales det at vælge specifikke modeller:

  • qwen3-koder:30bStærk inden for programmering og værktøjer, selvom en del af modellen ender med en CPU med 16 GB VRAM.
  • DeepSeek-koder, CodeLlama og andre kodevarianter til mindre størrelser, hvis du ønsker mere lethed.

Hvis du vil tilbyde "udviklerplaner", så overvej en node med mere end 16 GB VRAM for at imødekomme disse modeller uden at forårsage for stor CPU-belastning.

Multimodale modeller og vision

For opgaver, der kombinerer tekst og billede (screenshot-analyse, scannede dokumenter osv.), er de mærkede modeller Vision (llava, moondream, bakllava, qwen-vl…) er dem, du skal samle. Her:

  • VRAM-forbruget stiger, og tokenhastigheden er normalt lavere.
  • Det er tilrådeligt at begrænse dem til specifikke opgaver og ikke blande dem med intensiv chat, der involverer mange brugere.

Hvis du har en blandet GPU-pool (for eksempel 5070 + 5060 + 4060, 48 GB VRAM i alt), kan det være interessant at dedikere et af kortene til visionsmodeller og et andet til ren tekst, så du undgår at overbelaste en enkelt enhed med alt.

Installations-, implementerings- og udførelsesvarianter (native, Docker, containere)

På et operationelt niveau kan Ollama installeres på flere måder: native på Windows, macOS eller Linux, eller i containere (Podman, Docker…).

På Linux kan du for eksempel implementere llama.cpp i en GPU-optimeret container:


Description=llama
After=network-online.target


Image=ghcr.io/ggml-org/llama.cpp:server-cuda
ContainerName=llama
PublishPort=8000:8000
AddDevice=nvidia.com/gpu=all
Environment=NVIDIA_DRIVER_CAPABILITIES=all
Environment=NVIDIA_VISIBLE_DEVICES=all

Exec=--host 0.0.0.0 \
     --port ${PORT} \
     -m ${MODEL_PATH} \
     -ngl ${NGL} \
     -c ${CONTEXT_SIZE} \
     --flash-attn on \
     --batch-size ${BATCH}

Volume=/data/models:/models:Z
Network=llama.network


Restart=always
Environment=PORT=8000
Environment=MODEL_PATH=/models/gemma-4-E4B-it-Q8_0.gguf
Environment=NGL=99
Environment=CONTEXT_SIZE=128000
Environment=BATCH=512


WantedBy=default.target

Denne type implementering giver dig mulighed for separate Ollama, llama.cpp og andre værktøjer i containere, kontrollere versioner og isolere ressourcer efter tjeneste (og, hvis du vil, efter klient).

For at administrere Hugging Face-modeller i GGUF eller Safetensors kan du bruge værktøjer som rust-hf-downloader og importer dem derefter til Ollama ved hjælp af Modelfilerhvor du definerer FROM, TEMPLATE, standardparametre og promptsystem, udover at vedligeholde synkronisering og lokale sikkerhedskopier af artefakterne, hvis du arbejder med flere noder.

Når du har samlet brikkerne, er resten styringsbeslutninger: hvilke modeller du tilbyder til hvilke klienter, med hvilke kontekstbegrænsninger, og hvad politikken er for opdateringer og kvantificeringer for ikke at forstyrre kompatibilitet eller forventet ydeevne.

Hvis du er klar over, at prioriteten er, at modellerne passer fuldstændigt ind i VRAM, at kvantiseringen forbliver på en rimelig balance (Q4_K_M), og at konteksten ikke overstiger, hvad din hardware kan håndtere, så opsætter du en Ollamas private SaaS på en mellemstor klynge Det holder op med at være science fiction og bliver en fornuftig investering: du betaler for GPU'er, hvor de virkelig bidrager, du tager dig af RAM'en til at understøtte lejlighedsvise downloads, og du bruger orkestreringsværktøjer (Ollama, llama.cpp, containere, Open WebUI) til at give dine klienter oplevelsen af ​​en "privat ChatGPT", men med dine egne regler og uden at være afhængig af skyen.

Årlig kontrol af en hjemme-pc
relateret artikel:
Lokalt PC-telemetri-dashboard uden cloud: en komplet guide