Lokale LLM.
Dimensioneret efter behov.
Fra den rette model til en AI-tjeneste med løbende support: DAXS planlægger lokal LLM-infrastruktur, tester hardware under reel belastning og integrerer løsningen i jeres eksisterende IT.
En AI-server begynder med belastningsprofilen.
En lokal sprogmodel kan bearbejde interne tekster, hjælpe med kodeudkast eller indgå i videnssøgning. En brugbar løsning kræver, at modelkvalitet, tilladte dataforløb og forventet brug passer sammen. DAXS kortlægger kravene, planlægger infrastrukturen og varetager installation, integration og den aftalte drift – sammen med jeres IT eller som en afgrænset ydelse.
Opgave og kvalitet
Hvilke spørgsmål, sprog, dokumenter eller kodeopgaver skal løsningen håndtere? En kort chat og analyse af lange dokumenter stiller forskellige krav til modeller og kontekst.
Brug og ventetid
Hvor mange forespørgsler kommer samtidig? Hvor hurtigt skal den første reaktion begynde, og hvor lang tid må et fuldt svar tage? Lejlighedsvise enkeltforespørgsler og en tjeneste, som et team bruger løbende, kræver forskellige reserver.
Data og drift
Hvilke kilder og funktioner er godkendt? Hvor må model, søgeindeks, logfiler og sikkerhedskopier placeres? Hvem håndterer opdateringer og fejl, og hvilken tilbagerulningsmulighed er nødvendig?
Forbind applikation, inferens og drift ordentligt.
Brugergrænsefladen er kun én del. Foran den ligger identitets- og adgangskontrol; bagved arbejder inferenstjeneste, modellager og eventuelt videnssøgning eller virksomhedsgrænseflader. Overvågning, opdateringer og gendannelse hører med i samme plan.
Tegningen viser en mulig arkitektur, ikke et faktisk kundenetværk. En reverse proxy kan sikre TLS og indgangen. Applikationen skal stadig håndhæve brugerrettigheder. Model-API'er begrænses til de nødvendige netværk og funktioner; en tilgængelig inferensport er endnu ikke en færdig virksomhedstjeneste.
Mere end modelfilens størrelse.
Ved valget ser vi på vægte, runtimebehov, kontekst, parallelitet og hele dataforløbet. En GPU kan have tilstrækkelig hukommelse og alligevel være uegnet til den ønskede svartid. Omvendt kan en mindre, velvalgt model løse opgaven mere økonomisk.
| Byggesten | Det undersøger vi | Derfor er det relevant |
|---|---|---|
| GPU og VRAM | Arkitektur, drivere, inferensbackend, understøttede beregningsformater, hukommelsesstørrelse og båndbredde. | Vægte og KV-cache kræver plads. Beregningskraft og hukommelsesoverførsler påvirker forskellige arbejdsfaser; en markedsført TOPS-værdi beskriver ikke i sig selv applikationen. |
| En eller flere GPU'er | Opdeling af modellen, forbindelse mellem GPU'er, PCIe-tilslutning, strøm og køling. | VRAM bliver ikke automatisk til fælles hukommelse, der frit kan bruges. Opdeling og synkronisering skal understøttes af den valgte softwarestack; yderligere GPU'er kan skabe nye flaskehalse. |
| CPU og system-RAM | Runtime, tokenisering, databearbejdning, parallelle processer og eventuelt CPU-inferens eller offloading. | Offloading kan gøre det muligt at køre en model, men ændrer ydelsesprofilen. Overførsler mellem RAM og GPU kan forlænge svartiden. Også en GPU-server skal have passende CPU- og RAM-reserver. |
| NVMe og lager | Modelversioner, indlæsningstider, søgeindeks, importdata, logfiler, ledig kapacitet og sikkerhedskopier. | Hurtige NVMe-SSD'er hjælper med modelindlæsning og visse dataoperationer. Tokengenerering for en model, der ligger helt i GPU-hukommelsen, bestemmes især af beregnings-, hukommelses- og runtimefaktorer. |
| Netværk og forsyning | Forbindelse, tilladte dataforløb, plads, strømforbrug, varmeafgivelse og serviceadgang. | Den bedste enkelte beregningskomponent hjælper kun lidt, hvis tjenesten under reel belastning begrænses af varme, organisering eller dataadgang. |
En beregningshjælp – ingen købsanbefaling.
Den rene nedre grænse for vægtene kan groft anslås med Antal parametre × bit pr. vægt ÷ 8 . En hypotetisk model med otte milliarder parametre og fire bit pr. vægt giver beregningsmæssigt fire gigabyte, svarende til cirka 3,73 GiB.
Dertil kommer kvantiseringsmetadata, eventuelt modeldele med højere præcision, KV-cache, arbejdsområder og runtime. Værdien siger derfor udtrykkeligt ikke, hvilken VRAM-kapacitet jeres applikation behøver. Ved modeller med ekspertarkitektur skal man desuden skelne mellem aktive beregningsdele og den samlede mængde vægte, der skal være til rådighed.
Et kort svar er en anden test end en tjeneste til et team.
Kontekstvinduet omfatter den information, som en model kan tage hensyn til i en forespørgsel. Afhængigt af applikationen omfatter det instruktioner, samtalehistorik, hentede dokumentdele og det planlagte output. Et nominelt stort kontekstvindue garanterer hverken passende hardware eller pålidelig udnyttelse af informationen.
KV-cache
Key-value-cachen gemmer mellemtilstande for attention-beregningen. Behovet afhænger blandt andet af modelarkitektur, datatype, faktisk anvendt kontekst og samtidige aktive sekvenser. Mere kontekst og mere parallelitet øger ofte hukommelsesbehovet betydeligt.
Prefill og decode
Under prefill behandler modellen inputkonteksten; under decode genereres yderligere tokens. De to faser belaster hardwaren forskelligt. Lange dokumenter kan øge tiden til første token, selv om det efterfølgende output virker flydende.
Batching og kø
Fælles behandling kan øge den samlede gennemløbshastighed. Samtidig kan enkelte brugere komme til at vente længere. Reserveret kapacitet, køer, grænser og passende planlægning af parallelitet hører derfor med i designet.
Vi måler den faktiske anvendelse.
Et pilotprojekt omfatter typiske korte og lange forespørgsler samt samtidige adgange. Vi ser på Time to First Token, samlet svartid, outputhastighed, kø, fejlrate og hukommelsesforbrug. Tokens pr. sekund kan kun sammenlignes meningsfuldt sammen med modelversion, kvantisering, kontekst, belastning og målebetingelser.
Softwarestacken følger modellen og brugen.
Ollama, llama.cpp og vLLM er mulige byggesten. Valg og konfiguration afhænger af modelunderstøttelse, hardware, ønsket parallelitet, drift og integration. Vi undersøger den konkrete version; en generel installationskommando udgør ikke i sig selv en produktionsarkitektur.
Ollama
En mulig indgang til modeladministration og lokal tilgængeliggørelse. Modellager, godkendte modeller, kontekst, parallelitet og sikring af tjenesten skal passe til miljøet.
llama.cpp
En fleksibel byggesten til egnede modeller på forskellige CPU-/GPU-backends med kvantiserede formater og serverdrift. Hardwareunderstøttelse, opdeling og de faktisk nødvendige API-funktioner afprøves i praksis.
vLLM
En mulighed for egnede serverbaserede inferens- og belastningsprofiler. Scheduling, KV-cache, batching og eventuelt flere GPU'er afstemmes samlet. Højere samlet gennemløbshastighed er ikke ensbetydende med kortere ventetid for hver enkelt forespørgsel.
Container, virtuel maskine eller egen vært?
Containere kan samle softwareversioner reproducerbart. En virtuel maskine kan desuden afgrænse miljøet organisatorisk og teknisk. Den egnede løsning afhænger af enhedsgennemføring, drivere, vedligeholdelse og eksisterende driftsprocedurer. En kompatibel API letter integrationen, men erstatter ikke en funktionstest med jeres applikation.
Hvornår passer Proxmox med GPU-passthrough?
GPU-passthrough tildeler en egnet fysisk GPU til en virtuel maskine. Det kræver blandt andet passende platform og firmware, IOMMU-grupper, værts- og gæstedrivere samt korrekt adfærd ved nulstilling af enheden. Vi afprøver den konkrete kombination, før vi giver et tilsagn.
En tildelt GPU kan ikke automatisk deles fleksibelt mellem flere VM'er. vGPU og direkte gennemføring er forskellige koncepter med egne forudsætninger og eventuelle licensvilkår. Vedligeholdelse, backup og et muligt værtsskifte kræver også et passende forløb; et generelt løfte om live-migration ville være misvisende.
Den rette model skal kunne løse opgaven.
Vi sammenligner modeller med godkendte eksempler fra den senere anvendelse: eksempelvis tysksprogede fagspørgsmål, dokumentuddrag, flersprogede forespørgsler eller en konkret scriptopgave. En kodemodel og en embeddingmodel har forskellige opgaver. Ved videnssøgning skal søgning, embeddings og svarmodel passe sammen.
Kvantisering reducerer ofte hukommelsesbehovet. Virkningen på svarkvalitet, værktøjskald og hastighed afprøves med det valgte format. En større model er ikke automatisk bedre eller mere økonomisk. En lang maksimal kontekst dokumenterer heller ikke, at modellen pålideligt bruger al information i den.
- Licens: undersøg de valgte modelvægte, kommerciel brug, videredistribution og nødvendige oplysninger konkret; en enkel download erstatter ikke denne gennemgang.
- Version: dokumenter model, kvantisering, tokenizer og runtime, så de kan spores.
- Godkendelse: afprøv faglig egnethed, uønskede svar, sprogkvalitet og fejltilfælde med et genanvendeligt sæt spørgsmål.
- Ændringer: test nye modelversioner først, bevar en brugbar tilbagerulningsmulighed, og genopbyg søgeindekser ved ændrede embeddings.
Lokalt, eksternt eller i en passende kombination.
Egen hardware kan give mening ved passende udnyttelse, tydelige datakrav og et eksisterende driftsgrundlag. En ekstern tjeneste kan være bedre ved svingende brug, særlige modelegenskaber eller begrænset egen driftskapacitet. Hybrid kombinerer målrettet afgrænsede opgaver og dataforløb.
Sammenligningen omfatter anskaffelse eller forbrug, strøm og køling, licenser, integration, opdateringer, support, reserver og følger af nedbrud. Lokal behandling er ingen automatisk sikkerheds- eller GDPR-garanti: modeller, embeddings, telemetri, opdateringer, eksterne værktøjer og logfiler skal også passe til det aftalte datakoncept.
Vi planlægger først et afgrænset pilotprojekt med målbare krav. Resultatet danner grundlag for at vælge udbygning, tilpasning eller et enklere alternativ. Yderligere grundlag findes under Cloud og SaaS.
En tjeneste med løbende support kræver tydeligt ansvar.
DAXS kan planlægge og installere hardware og software, forbinde dem med eksisterende identiteter og applikationer og varetage den aftalte løbende drift. Det omfatter tilgængeligheds- og ressourceovervågning, versionsvedligeholdelse, fejlhåndtering og dokumentation. Den nødvendige tilgængelighed og reaktionsform aftales konkret.
Vi fastlægger, hvilke konfigurationer, applikationskomponenter, indeksdata og eventuelt tilpassede modeller der skal sikkerhedskopieres. Modelvægte, som kan hentes igen, og beskyttelseskrævende virksomhedsdata stiller forskellige krav til backup. En gendannelsestest hører med i et passende driftskoncept.
Kravkortlægning, arkitekturforslag, model-/belastningstest, dokumenterede dataforløb og en begrundet anbefaling af hardware, driftsmodel og næste integrationsskridt.
Det afklarer vi i samtalen.
Hvor meget VRAM behøver en lokal LLM?
Det afhænger af model og kvantisering, runtime, kontekst og samtidige forespørgsler. Modelfilen er ikke tilstrækkelig som grundlag. Vi tester den ønskede opgave med lange forespørgsler og belastningsspidser, før vi anbefaler en konkret konfiguration.
Er en ekstra GPU automatisk hurtigere?
Nej. Den valgte softwarestack skal understøtte opdelingen. Forbindelser mellem GPU'er, synkronisering og modelarkitektur påvirker resultatet. Mere hukommelse kan gøre det muligt at køre modellen uden at forkorte hver enkelt svartid.
Kan en eksisterende Proxmox-server bruges?
Det kan passe, hvis hardware, IOMMU-grupper, drivere og GPU-gennemføring er egnede. Der skal også være reserver til andre tjenester og passende forløb for vedligeholdelse, backup og gendannelse. Vi undersøger den eksisterende platform konkret.
Trænes interne dokumenter ind i modellen?
Det er ofte ikke nødvendigt ved videnssøgning. RAG søger efter egnede, tilladte dokumentdele og giver dem til modellen som kontekst. Tilpasning af modelvægtene er en anden foranstaltning og begrundes særskilt.
Hvornår er en ekstern tjeneste mere økonomisk?
Ved lav eller stærkt svingende brug, særlige modelkrav eller manglende driftskapacitet kan en ekstern tjeneste være bedre. Vi sammenligner omkostninger, dataforløb, kvalitet og drift over den planlagte brugsperiode.
Følg modeller, belastning og omkostninger samlet.
Ud over GPU-belastning og svartid ser vi på omkostningen pr. brugbar opgave. En modelopdatering sammenlignes med det godkendte testsæt før brug. Fejlrater, køer, hukommelsesgrænser og nedbrud kræver navngivne ansvarlige og en tilbagerulningsmulighed. En ekstern reservetjeneste kommer kun på tale, hvis dataklasse og godkendelse tillader det.
Lad os tale om jeres anvendelse.
Hvad skal blive lettere, hvilke data indgår, og hvilke systemer findes allerede? Ud fra det udvikler vi en meningsfuld indgang og et overskueligt næste skridt.