On-prem · 9 min lesing
Server og maskinvare
Hva miljøet ditt trenger i hvert on-prem-scenario: CPU, minne, disk, GPU-servere, brannmuråpninger, domene og sertifikat
Intric leverer plattformen på Kubernetes fra versjonerte Helm-charts. Kjører du ikke Kubernetes fra før (chartene krever 1.29 eller nyere; velg en versjon prosjektet fortsatt støtter), installerer vi k3s, en lett Kubernetes-distribusjon, på en Linux-VM som du stiller til rådighet. Hva VM-en trenger, avhenger av hvilke deler av plattformen du kjører i ditt eget miljø, og hvilke du bruker som tjeneste fra Intric.
Velg scenario
Section titled “Velg scenario”| Scenario | Kjører i miljøet ditt | Brukes som tjeneste | Maskinvare |
|---|---|---|---|
| 1. Plattform | Webapp, API, databaser, søkeindeks, objektlagring | Behandling (PDF/OCR, dokumentinnlesing, transkribering) og alle AI-modeller | Én VM, 4–8 kjerner |
| 2. Plattform + behandling | Scenario 1, pluss behandlingsworkerne for PDF/OCR, dokumentinnlesing og lydtranskribering, som kjører på CPU | AI-modeller som trenger GPU: språkmodeller, embeddings, tale-til-tekst, bildemodell | Én VM, ~20–72 kjerner |
| 3. Helt lokalt | Scenario 2, pluss alle AI-modeller på egne GPU-servere: språkmodeller, embeddings, tale-til-tekst og bildemodell | Ingenting | VM-en fra scenario 2, pluss én eller flere GPU-servere |
Velg scenarioet som kravene dine til datahåndtering faktisk krever, ikke det største.
Slik har vi kommet fram til tallene. CPU og minne er reservasjonene (Kubernetes requests) i Helm-chartene våre, summert per scenario, pluss margin. Det er ikke resultater fra lasttester. GPU-tallene er merket målt der vi kjører konfigurasjonen i produksjon, og estimert der vi har regnet dem ut. Start på det foreslåtte nivået, følg det faktiske forbruket de første ukene og juster deretter (se Utvide installasjonen).
Krav i alle scenarioer
Section titled “Krav i alle scenarioer”| Krav | |
|---|---|
| CPU-arkitektur | x86-64 (amd64). En «kjerne» på denne siden betyr én vCPU. |
| Operativsystem | Ubuntu 22.04 eller nyere |
| Lagring | SSD. Behold /var på systemdisken i stedet for på en liten, separat partisjon. |
| Topologi | Én node. Plattformen har ingen innebygd høy tilgjengelighet; se Tilgjengelighet og sikkerhetskopiering. |
Scenario 1: Plattform
Section titled “Scenario 1: Plattform”| Minimum | Anbefalt | |
|---|---|---|
| CPU | 4 kjerner | 8 kjerner |
| RAM | 16 GB | 32 GB |
| Systemdisk | 100 GB | 100 GB |
| Datadisk | 250 GB | 500 GB |
Tjenestene i plattformen reserverer omtrent 2 kjerner og 6 GB og kan i topper bruke opptil omtrent 9 kjerner og 18 GB. Resten går til Kubernetes og til MCP-serverne du kjører på samme VM. På minimumsnivået får ikke en full topp plass i minnet. Minnet er også den første grensen du møter når du legger til MCP-servere, så velg det anbefalte nivået hvis du planlegger å kjøre flere.
Datadisken rommer databasen, søkeindeksen og opplastede filer, og den vokser med mengden innhold du laster opp.
Når Intric står for behandlingen, henter behandlingstjenestene til Intric hver opplastede fil fra objektlagringen din og sender resultatet tilbake til plattformen din. API-et og objektlagringen din må derfor være tilgjengelige fra behandlingstjenesten til Intric over HTTPS med et gyldig sertifikat. Du kan begrense tilgangen til kildeadressene Intric oppgir.
Scenario 2: Plattform + behandling
Section titled “Scenario 2: Plattform + behandling”Når du laster opp en fil, må plattformen gjøre den om til tekst før assistentene kan søke i den. Den jobben gjør behandlingstjenestene:
- PDF-behandling leser layout, tabeller og tekst i PDF-filer og gjenkjenner tekst på skannede sider (OCR).
- Dokumentinnlesing deler teksten i avsnitt og lar en embeddingmodell gjøre hvert avsnitt om til en vektor som søket kan finne. Har du konfigurert en bildemodell, sender dokumentinnlesingen også bildene og diagrammene i dokumentene til den for en beskrivelse.
- Lydtranskribering forbereder opptak og sender dem til en tale-til-tekst-modell, som returnerer teksten.
Selve workerne kjører på CPU. Modellene de kaller (embeddings, tale-til-tekst og bildemodellen), trenger GPU og kjører ikke på VM-en: i scenario 1 og 2 kaller workerne modeller driftet av Intric over nettverket, og i scenario 3 kaller de modeller på egne GPU-servere. Scenario 2 trenger derfor ingen GPU.
En meldingskø gir hver jobb til riktig worker. I scenario 1 kjører Intric disse tjenestene for deg; i scenario 2 kjører du dem på din egen VM. Antallet workers følger automatisk antallet jobber som venter, og de bruker bare CPU mens de behandler dokumenter eller opptak. PDF-behandlingen står for mesteparten: hver PDF-worker reserverer 6 kjerner og 5 GB, fordi OCR på skannede sider kjører AI-modeller på CPU-en. Én enkelt worker tar seg av hvert dokument, så flere workers lar plattformen behandle flere dokumenter samtidig.
| Nivå | PDF-workers | Workers for dokumentinnlesing | Workers for transkribering | CPU | RAM |
|---|---|---|---|---|---|
| Grunnivå | 1 | 2 | 1 | ~20 kjerner | ~40 GB |
| Standard | 4 | 4 | 3 | ~40 kjerner | ~60 GB |
| Høy kapasitet | 9 | 9 | 5 | ~72 kjerner | ~88 GB |
Hver sum er minimumsnivået i scenario 1 (4 kjerner / 16 GB), pluss reservasjonene til behandlingstjenestene, pluss 8 kjerner / 16 GB margin for topper. Et eksempel for Standard: 4 PDF-workers (24 kjerner / 20 GB), 4 workers for dokumentinnlesing (1,2 kjerner / 2 GB), 3 workers for transkribering (0,6 kjerner / 2,3 GB) og meldingskøen, jobbkoordineringen, kodesandkassen og eksporttjenesten som alltid er i gang (1,4 kjerner / 1,9 GB) blir til sammen omtrent 27 kjerner / 26 GB. Med plattformen og marginen blir det omtrent 40 kjerner / 60 GB.
Grunnivå fungerer, men store opplastinger havner i kø, og et stort skannet dokument tar merkbart lengre tid. Standard er et godt utgangspunkt for de fleste organisasjoner.
Under belastning kan en PDF-worker bruke opptil det dobbelte av CPU-reservasjonen sin og opptil 8 GB minne. Når alle PDF-workers på nivået Høy kapasitet når toppen samtidig, kan minnebruken overstige summen over; legg til RAM hvis du ser tegn på minnemangel. Behandlingen står stille mesteparten av tiden, så på VMware og lignende plattformer er den ubrukte CPU-en fortsatt tilgjengelig for andre VM-er. Reserver derfor minne for VM-en, ikke CPU.
Disk: regn med omtrent 50 GB ekstra til containeravbildninger (avbildningen for PDF-behandling er alene omtrent 9 GB). Hver transkriberings-worker skriver opptil 2 GB midlertidige filer mens den arbeider, og kodesandkassen opptil 1 GB, på filsystemet som rommer /var/lib/kubelet. Blir /var full, begynner Kubernetes å kaste ut (evict) arbeidslaster på hele VM-en.
Helm-chartet har forsiktige tak for antallet workers fra start: consumers.pdfPreProcessing.scaling.maxReplicas er 2 som standard, og for dokumentinnlesing og lydtranskribering er taket 5. Hev hvert tak til minst antallet for nivået ditt, ellers skalerer ikke workers opp til kapasiteten du har satt av.
Scenario 3: Helt lokalt
Section titled “Scenario 3: Helt lokalt”Alle AI-modeller ligger på separate GPU-servere som VM-en når over nettverket: språkmodellen og støttemodellene som behandlingsworkerne kaller (embeddings, tale-til-tekst og bildemodellen). Dimensjoner VM-en som i scenario 2.
Språkmodell. Kapasiteten avhenger langt mer av hvor mange spørsmål som pågår samtidig, og hvor lange de vedlagte dokumentene er, enn av antallet brukere. Hos en av de større kommunale kundene våre ligger toppen i produksjon på rundt 10 samtidige forespørsler.
Anbefalingene endrer seg hele tiden. Modeller og GPU-generasjoner utvikler seg raskt, og det vi anbefaler i dag, kan være utdatert om noen måneder. Konfigurasjonene nedenfor viser vurderingen vår per oktober 2026. Vi reviderer dem etter hvert som vi måler nye modeller og ny maskinvare, og vi bekrefter dimensjoneringen med deg før du bestiller noe.
| Konfigurasjon | Modell | Egnet for | Status |
|---|---|---|---|
| 1× H200 (141 GB) | Gemma 4 31B | Chat og spørsmål om dokumenter | Målt i produksjon |
| 2× B200 | Inkling Small (276B parametere, 12B aktive) | Raskere svar, lange dokumenter, mer komplekse oppgaver i flere trinn | Estimert |
| 8× B200 (én node) | Inkling (omtrent 950B parametere, 40B aktive) | Mange samtidige brukere og de mest krevende oppgavene | Estimert |
1× H200 er konfigurasjonen vi kjører i produksjon i dag. Målt med Gemma 4 31B (4-biters vekter, vLLM): ~100 tokens/s per svar ved én enkelt forespørsel, og plass i GPU-minnet til omtrent 900 000 tokens samtalekontekst. Det holder til omtrent 9 samtidige samtaler med full kontekst på 100 000 tokens, eller langt flere ved vanlige promptstørrelser. Vi anslår at et ekstra kort med sin egen kopi av modellen gir like mye kapasitet til, og i tillegg redundans. H200 hører til NVIDIAs Hopper-generasjon (H100/H200), som Blackwell (B200 og senere) er i ferd med å erstatte. NVIDIA selger og støtter fortsatt Hopper-kortene, men har begynt å varsle end-of-life for deler av generasjonen. Før et nytt innkjøp anbefaler vi derfor at du sjekker tilgjengeligheten og vurderer Blackwell. Gemma 4 bør også få plass på ett enkelt B200-kort, som har mer minne og båndbredde enn H200, men det har vi ikke testet ennå.
Med Inkling Small anslår vi at 2× B200 gir ~150 tokens/s per svar og plass til 17–53 samtidige samtaler med full kontekst på 100 000 tokens. Hele Inkling-modellen får bare plass på en hel node, og der anslår vi at 8× B200 gir ~110 tokens/s per svar og plass til 44–142 slike samtaler. Den konfigurasjonen gir mer kapasitet og en større modell, ikke raskere svar per bruker. Inkling-modellene krever Blackwell-GPU-er og kjører ikke på H100/H200. Vi har regnet ut B200-tallene fra målingene våre på H200 og spesifikasjonene til maskinvaren, men har ennå ikke kjørt dem under reell last.
Støttemodeller. Embeddings (søk), tale-til-tekst og bildemodellen som tolker bilder og diagrammer i dokumenter, er mindre. I den største lokale installasjonen vår deler de ett GPU-kort på 94 GB og bruker omtrent 50 GB av minnet. Planlegg derfor for et kort med minst 80 GB hvis de skal kjøre sammen (for eksempel NVIDIA RTX PRO 6000 Blackwell Server Edition, 96 GB).
GPU-serverne trenger GPU-er for datasenter (passivt kjølte) i en server som er sertifisert for dem, med tilstrekkelig luftstrøm og strømforsyning.
Utvide installasjonen
Section titled “Utvide installasjonen”- Det tar lang tid før dokumenter blir søkbare: sjekk behandlingskøene. Har workers nådd taket sitt, hever du
maxReplicasog legger til CPU og RAM i VM-en. - Minnemangel eller utkastede poder: legg til RAM først. Minnet er den vanligste begrensningen på plattform-VM-en.
- Svarene kommer sent i gang under belastning (scenario 3): legg til et GPU-kort for språkmodellen.
Tilgjengelighet og sikkerhetskopiering
Section titled “Tilgjengelighet og sikkerhetskopiering”Alle scenarioene kjører på én enkelt VM. Hvis virtualiseringsplattformen din starter VM-en på nytt på en annen vert etter en maskinvarefeil (for eksempel vSphere HA), dekker det de fleste behov for tilgjengelighet, mot noen minutters nedetid. VM-snapshots er ikke en konsistent sikkerhetskopi av databasen. Vi setter opp regelmessige databasedumper, og dem må du lagre utenfor VM-en.
Nettverk og brannmur
Section titled “Nettverk og brannmur”Inngående trafikk (Porter)
Section titled “Inngående trafikk (Porter)”- Port 443: Webgrensesnittet (HTTPS), fra nettverkene til brukerne dine.
- Port 80: Automatisk omdirigering til HTTPS.
- Port 22: SSH, for installasjon og drift. Begrens porten til tilgangsveien til Intric (for eksempel VPN-en din); den skal ikke være åpen mot internett.
Utgående trafikk (Whitelist - Infrastruktur)
Section titled “Utgående trafikk (Whitelist - Infrastruktur)”I tillegg til språkmodellene (se avsnittet nedenfor) trenger serveren HTTPS-tilgang til:
get.k3s.io,github.com,objects.githubusercontent.com(installasjon av k3s)ghcr.io,pkg-containers.githubusercontent.com(containeravbildninger og Helm-charts fra Intric)registry-1.docker.io,auth.docker.io,production.cloudflare.docker.com(containeravbildninger fra tredjeparter)login.intric.ai(Intric bruker sin egen IdP til autentisering)
Hvis proxyen eller brannmuren din inspiserer TLS, må du unnta disse vertene. Installasjoner uten utgående tilgang er mulige hvis du speiler alle avbildningene til et privat register.
Språkmodeller for on-prem-drift
Section titled “Språkmodeller for on-prem-drift”I scenario 1 og 2 kaller plattformen og behandlingsworkerne språkmodeller, embeddings og tale-til-tekst over nettverket. Tillat utgående trafikk til:
Intric Hosted Models (EU):
Section titled “Intric Hosted Models (EU):”gpu6.intric.ai(språkmodell driftet av Intric)embedding-model.intric.ai(embeddings driftet av Intric)- Tale-til-tekst: adressen avhenger av hvilken transkriberingsleverandør installasjonen din bruker, og den får du fra oss
mcp.intric.ai/*(MCP-servere driftet av Intric)mcp-servers.intric.ai/*(MCP-servere driftet av Intric)
Det gjeldende utvalget av modeller finner du i administrasjonspanelet under Modeller.
Eksterne offentlige modeller (API-er):
Section titled “Eksterne offentlige modeller (API-er):”api.openai.com/v1api.anthropic.comapi.berget.ai/v1api.mistral.ai/v1
Domene og sertifikat
Section titled “Domene og sertifikat”-
DNS: Pek domenet du har valgt (f.eks.
app.company.com) mot IP-adressen til serveren med en A- eller AAAA-post. -
SSL/TLS-sertifikat: Du må stille gyldige sertifikater til rådighet:
- Sertifikatfil (.crt): Hele kjeden i PEM-format.
- Privat nøkkel (.key): Den private nøkkelen i PEM-format.
- Merk: Kunden er ansvarlig for å fornye sertifikatet.