En lokal sprogmodel er hurtig at afprøve. En fælles AI-assistent kræver også reguleret adgang, tydelige dataveje og nogen, der har ansvaret for driften. Ollama og Open WebUI kan arbejde sammen: den ene komponent kører modeller, den anden leverer grænsefladen til det daglige arbejde.
I en virksomhed starter planlægningen med en konkret opgave: tekstudkast fra godkendte stikord, bearbejdning af interne noter eller hjælp til tekniske spørgsmål. Før valg af hardware fastlægges tilladte input, kontrol af resultater og passende svartider.
To komponenter med forskellige opgaver
Ollama leverer kørselsmiljø og en API til sprogmodeller. Open WebUI tilføjer en administrerbar webgrænseflade. En lokalt installeret grænseflade fortæller dog ikke, hvor hver tilsluttet model behandler forespørgsler. Cloudmodeller, websøgning og ekstra værktøjer kan bruge andre dataveje.
I dette driftskoncept når medarbejderne grænsefladen via en godkendt adgang. Open WebUI forbinder internt til Ollama. Model-API’en begrænses til tjenester, der faktisk behøver den. Forbindelser mellem separate containere eller servere skal planlægges udtrykkeligt: localhost henviser til hver komponents eget netværksmiljø.
Fra enkeltarbejdsplads til fælles tjeneste
Forskellen er især, hvad der sker efter den første vellykkede chat. Sammenligningen beskriver en mulig udbygning for en mindre virksomhed; den er en planlægningshjælp og ikke et dokumenteret kundeprojekt.
| Område | Individuel test | Fælles brug |
|---|---|---|
| Adgang | En person tester på sin egen computer. | Personlige konti, fastlagte roller og reguleret inddragelse af adgang. |
| Data | Ikke-følsomme eksempeldata. | Godkendte datatyper, opbevaring og dokumenterbare kilderettigheder. |
| Tilgængelighed | Computeren er tændt under testen. | Aftalte brugstider og dokumenteret genetablering. |
| Kapacitet | En forespørgsel giver et brugbart svar. | Samtidige opgaver, ventetider og længere input måles. |
| Ændringer | Model og software afprøves. | Testede versioner, backup før ændringer og en pålidelig vej tilbage. |
Beskyt adgang og model-API særskilt
Ifølge producenten kræver Ollamas lokale API ikke egen autentificering. Netværksadgang erstatter derfor ikke adgangskontrol. Til en virksomhedstjeneste bør model-API’en kun kunne nås via nødvendige interne forbindelser. En port, der er åben for alle arbejdspladser eller internettet, er ikke et egnet udgangspunkt. Ollama: autentificering (eksternt link).
Konfigurér login, brugergodkendelse og administrationsrettigheder bevidst. En eksisterende identitetstjeneste kan være en nyttig integration; den rette tilslutning afhænger af miljøet. En proxy må kun videregive en godkendt identitet via betroede oplysninger, som den selv sætter. Open WebUI: adgang og rettigheder (eksternt link).
HTTPS beskytter forbindelsen fra browser til adgangspunkt. Ved flere systemer krypteres og begrænses den videre vej til backend også efter beskyttelsesbehov. Certifikater, omdirigeringer og nødvendige forbindelser testes samlet. Open WebUI: HTTPS og reverse proxy (eksternt link).
Kontrollér “lokal” gennem den faktiske datavej
Til udelukkende lokale modelkald tilbyder Ollama en tilstand uden sine cloudfunktioner. Det erstatter ikke kontrollen af andre forbindelser i Open WebUI eller tilføjede værktøjer. Modeldownloads og softwareopdateringer kræver også en planlagt leveringsvej. Ollama: lokal brug og cloudfunktioner (eksternt link).
- Model: Hvilken præcis version behandler forespørgslen, og hvor kører den?
- Dokumenter: Hvor gemmes uploads, udtrukne tekster, søgeindekser og backups?
- Ekstra tjenester: Kontaktes andre udbydere til søgning, tekstgenkendelse, tale eller embeddings?
- Værktøjer: Hvilken forbindelse må læse data eller udløse handlinger, og med hvis rettigheder?
Cloud og hybrid kan være egnede supplementer. Fastlæg da udbydere, datatyper og godkendelser udtrykkeligt. Et skift til en ekstern tjeneste bør ikke ske ubemærket, blot fordi den lokale model er optaget.
Virksomhedsviden kræver konkrete rettigheder
Et login fastslår først, hvem der bruger grænsefladen. Det giver ikke automatisk ret til alle uploadede dokumenter. I eksemplet kan en godkendt vejledning være tilgængelig for alle pilotbrugere, mens personaleakter holdes helt uden for piloten.
Ved senere tilslutning af flere kilder kontrolleres rettigheder pr. samling, dokument og bruger. Søgeresultater, citater, delte chats og gemte svar kan også afsløre oplysninger. Ændringer i grupper eller kilderettigheder skal slå igennem i vidensløsningen. Læs mere på fagsiderne Virksomhedsviden og RAG og AI-sikkerhed og rettigheder.
Backup og opdateringer hører til konceptet
Sikr de faktisk anvendte data: database, uploads og konfiguration samt nøgler nødvendige for gendannelse. Dokumentér modelnavn og præcis version, også tilpassede modeller og egne udvidelser. Backup opbevares adgangsbeskyttet adskilt fra det kørende system.
Før en opdatering kræves en gendannelig backup, gennemgang af versionsnoter og en test uden for produktionsdriften. Efter en databasemigration genskaber et gammelt container-image ikke nødvendigvis den tidligere tilstand alene. Open WebUI: opdateringer, backup og vej tilbage (eksternt link).
En meningsfuld gendannelsestest starter i et separat miljø. Her kontrolleres login, modelforbindelse, en ikke-følsom testopgave og de forventede rettigheder. Først da kan varigheden af en reel afbrydelse vurderes. En kørende VM eller en eksisterende backupmappe dokumenterer det ikke alene.
En kørende grænseflade er ikke bevis på en fungerende model
Overvågningen bør skelne mellem tilgængelig grænseflade, en klar valgt model og en fuld forespørgsel, der virker. Open WebUI-dokumentationen adskiller også disse niveauer. Open WebUI: funktionsovervågning (eksternt link).
Til den aftalte drift overvåges desuden lagerforbrug, ledig kapacitet, fejlprocenter og ventetider. Testforespørgsler indeholder intet fortroligt. Logfiler skal være tilstrækkelige til fejlsøgning uden rutinemæssigt at kopiere alle samtaler. Fastlæg før bredere brug, hvem der reagerer på fejl og godkender opdateringer.
En overskuelig godkendelse før start
- Kontrollér adgang: En godkendt bruger kommer ind; en ikke-godkendt bruger og et ulovligt netværksområde holdes ude.
- Kontrollér dataveje: Model, grænseflade og alle ekstra tjenester bruger kun de aftalte forbindelser.
- Kontrollér rettigheder: To testroller får kun deres godkendte indhold. Inddraget adgang virker også efter en tidligere vellykket søgning.
- Kontrollér belastning: Typiske opgaver kører enkeltvis og samtidig; acceptable ventetider og grænser dokumenteres.
- Kontrollér genetablering: En backup kan gendannes separat; ansvar og vej tilbage er dokumenteret.
Den nødvendige hardware afhænger af model, kontekstlængde, samtidig brug og kvalitetsmål. Arkitekturen giver derfor ikke et universelt antal brugere, som kan betjenes samtidig. Den eksisterende artikel Test lokal AI: en pilot med retvisende belastning uddyber denne kapacitetsvurdering.
Begynd fornuftigt med en afgrænset opgave
DAXS kan vurdere eksisterende infrastruktur, planlægge dataveje og adgang og integrere løsningen i den aftalte drift. En afgrænset anvendelse med efterprøvbar nytte er et godt første skridt. Det viser, om en lokal tjeneste, cloudtilslutning eller kombination passer økonomisk og organisatorisk.
Lokale LLM’er og infrastruktur · MCP og grænseflader · Forespørg om AI-rådgivning og automatisering
Kilder: eksemplet beskriver en mulig arkitektur og kontrolproces, ikke en universel installationsvejledning. Produktfunktioner, modellicenser og konkret systemkompatibilitet kontrolleres for de anvendte versioner.
