On-prem · 9 min läsning

Server och hårdvara

Vad din miljö behöver i varje on-prem-scenario: CPU, minne, disk, GPU-servrar, brandväggsöppningar, domän och certifikat

Intric levereras på Kubernetes från versionerade Helm-charts. Kör du inte redan Kubernetes (chartsen kräver 1.29 eller senare; välj en version som projektet fortfarande stöder) installerar vi k3s, en lättviktig Kubernetes-distribution, på en Linux-VM som du tillhandahåller. Vad VM:en behöver beror på vilka delar av plattformen du kör i din egen miljö och vilka du använder som tjänst från Intric.

Välj scenario

Scenario	Körs i din miljö	Används som tjänst	Hårdvara
1. Plattform	Webbapp, API, databaser, sökindex, objektlagring	Bearbetning (PDF/OCR, dokumentinläsning, transkribering) och alla AI-modeller	En VM, 4–8 kärnor
2. Plattform + bearbetning	Scenario 1 samt bearbetningens workers för PDF/OCR, dokumentinläsning och ljudtranskribering, som kör på CPU	AI-modeller som kräver GPU: språkmodeller, embeddings, tal-till-text, bildmodell	En VM, ~20–72 kärnor
3. Helt lokalt	Scenario 2 samt alla AI-modeller på dina egna GPU-servrar: språkmodeller, embeddings, tal-till-text och bildmodell	Ingenting	VM:en från scenario 2 plus en eller flera GPU-servrar

Välj det scenario som dina krav på datahantering faktiskt kräver, inte det största.

Så har vi tagit fram siffrorna. CPU och minne är de reservationer (Kubernetes requests) som våra Helm-charts anger, summerade per scenario, plus marginal. Det är inte resultat från lasttester. GPU-siffrorna är märkta uppmätt där vi kör konfigurationen i produktion och uppskattat där vi har räknat fram dem. Börja på den föreslagna nivån, följ den faktiska förbrukningen under de första veckorna och justera sedan (se Utöka installationen).

Krav i alla scenarier

	Krav
CPU-arkitektur	x86-64 (amd64). En “kärna” på den här sidan betyder en vCPU.
Operativsystem	Ubuntu 22.04 eller senare
Lagring	SSD. Behåll `/var` på systemdisken i stället för på en liten separat partition.
Topologi	En nod. Plattformen har ingen inbyggd hög tillgänglighet; se Tillgänglighet och säkerhetskopiering.

Scenario 1: Plattform

	Minimum	Rekommenderat
CPU	4 kärnor	8 kärnor
RAM	16 GB	32 GB
Systemdisk	100 GB	100 GB
Datadisk	250 GB	500 GB

Plattformens tjänster reserverar ungefär 2 kärnor och 6 GB och kan under toppar använda upp till ungefär 9 kärnor och 18 GB. Resten går till Kubernetes och till de MCP-servrar du kör på samma VM. På miniminivån får en full topp inte plats i minnet. Minnet är också den första gränsen du når när du lägger till MCP-servrar, så välj den rekommenderade nivån om du planerar att köra flera.

Datadisken rymmer databasen, sökindexet och uppladdade filer, och den växer med mängden innehåll du laddar upp.

När Intric sköter bearbetningen hämtar Intrics bearbetningstjänster varje uppladdad fil från din objektlagring och skickar tillbaka resultatet till din plattform. Ditt API och din objektlagring måste därför vara nåbara från Intrics bearbetningstjänst över HTTPS med ett giltigt certifikat. Du kan begränsa åtkomsten till de källadresser som Intric anger.

Scenario 2: Plattform + bearbetning

När du laddar upp en fil måste den först bli text innan assistenterna kan söka i den. Det arbetet gör bearbetningstjänsterna:

PDF-bearbetning läser layout, tabeller och text i PDF-filer och känner igen text på inskannade sidor (OCR).
Dokumentinläsning delar upp texten i avsnitt och låter en embeddingmodell göra om varje avsnitt till en vektor som sökningen kan hitta. Har du konfigurerat en bildmodell skickar dokumentinläsningen också bilderna och diagrammen i dokumenten till den för en beskrivning.
Ljudtranskribering förbereder inspelningar och skickar dem till en tal-till-text-modell, som returnerar texten.

Själva workers kör på CPU. Modellerna de anropar (embeddings, tal-till-text och bildmodellen) kräver GPU och kör inte på VM:en: i scenario 1 och 2 anropar workers modeller som Intric driftar över nätverket, och i scenario 3 anropar de modeller på dina egna GPU-servrar. Scenario 2 kräver därför ingen GPU.

En meddelandekö lämnar varje jobb till rätt worker. I scenario 1 kör Intric de här tjänsterna åt dig; i scenario 2 kör du dem på din egen VM. Antalet workers följer automatiskt antalet jobb som väntar, och de använder bara CPU medan de bearbetar dokument eller inspelningar. PDF-bearbetningen står för den största delen: varje PDF-worker reserverar 6 kärnor och 5 GB, eftersom OCR på inskannade sidor kör AI-modeller på CPU:n. En enda worker tar hand om varje dokument, så fler workers gör att plattformen kan bearbeta fler dokument samtidigt.

Nivå	PDF-workers	Workers för dokumentinläsning	Workers för transkribering	CPU	RAM
Grund	1	2	1	~20 kärnor	~40 GB
Standard	4	4	3	~40 kärnor	~60 GB
Hög kapacitet	9	9	5	~72 kärnor	~88 GB

Varje summa är miniminivån i scenario 1 (4 kärnor / 16 GB) plus bearbetningstjänsternas reservationer plus 8 kärnor / 16 GB marginal för toppar. Ett exempel för Standard: 4 PDF-workers (24 kärnor / 20 GB), 4 workers för dokumentinläsning (1,2 kärnor / 2 GB), 3 workers för transkribering (0,6 kärnor / 2,3 GB) samt meddelandekön, jobbkoordineringen, kodsandlådan och exporttjänsten som alltid är igång (1,4 kärnor / 1,9 GB) blir tillsammans ungefär 27 kärnor / 26 GB. Med plattformen och marginalen blir det ungefär 40 kärnor / 60 GB.

Grund fungerar, men stora uppladdningar hamnar i kö och ett stort inskannat dokument tar märkbart längre tid. Standard är en bra utgångspunkt för de flesta organisationer.

Under belastning kan en PDF-worker använda upp till dubbla sin CPU-reservation och upp till 8 GB minne. Om alla PDF-workers på nivån Hög kapacitet når sin topp samtidigt kan minnesanvändningen bli högre än summan ovan; lägg till RAM om du ser tecken på minnesbrist. Bearbetningen står stilla större delen av tiden, så på VMware och liknande plattformar finns den oanvända CPU:n kvar för andra VM:ar. Reservera därför minne för VM:en, inte CPU.

Disk: räkna med ungefär 50 GB extra för containeravbilder (avbilden för PDF-bearbetning är ensam ungefär 9 GB). Varje transkriberingsworker skriver upp till 2 GB temporära filer medan den arbetar, och kodsandlådan upp till 1 GB, på det filsystem som rymmer /var/lib/kubelet. Blir /var full börjar Kubernetes vräka (evict) arbetslaster på hela VM:en.

Helm-chartet har försiktiga tak för antalet workers från start: consumers.pdfPreProcessing.scaling.maxReplicas är 2 som standard, och för dokumentinläsning och ljudtranskribering är taket 5. Höj varje tak till minst antalet för din nivå, annars skalar workers inte upp till den kapacitet du har avsatt.

Scenario 3: Helt lokalt

Alla AI-modeller ligger på separata GPU-servrar som VM:en når över nätverket: språkmodellen och de stödmodeller som bearbetningens workers anropar (embeddings, tal-till-text och bildmodellen). Dimensionera VM:en som i scenario 2.

Språkmodell. Kapaciteten beror mycket mer på hur många frågor som pågår samtidigt, och hur långa de bifogade dokumenten är, än på antalet användare. Hos en av våra större kommunala kunder ligger toppen i produktion på ungefär 10 samtidiga anrop.

Rekommendationerna ändras hela tiden. Modeller och GPU-generationer utvecklas snabbt, och det vi rekommenderar i dag kan vara inaktuellt om några månader. Konfigurationerna nedan speglar vår bedömning i oktober 2026. Vi reviderar dem när vi mäter nya modeller och ny hårdvara, och vi bekräftar dimensioneringen med dig innan du beställer något.

Konfiguration	Modell	Passar för	Status
1× H200 (141 GB)	Gemma 4 31B	Chatt och frågor om dokument	Uppmätt i produktion
2× B200	Inkling Small (276B parametrar, 12B aktiva)	Snabbare svar, långa dokument, mer komplexa uppgifter i flera steg	Uppskattat
8× B200 (en nod)	Inkling (ungefär 950B parametrar, 40B aktiva)	Många samtidiga användare och de mest krävande uppgifterna	Uppskattat

1× H200 är konfigurationen vi kör i produktion i dag. Uppmätt med Gemma 4 31B (4-bitarsvikter, vLLM): ~100 tokens/s per svar vid ett enskilt anrop, och plats i GPU-minnet för ungefär 900 000 tokens konversationskontext. Det räcker till ungefär 9 samtidiga konversationer med full kontext på 100 000 tokens, eller betydligt fler vid vanliga promptstorlekar. Vi bedömer att ett extra kort med en egen kopia av modellen ger lika mycket kapacitet till, och dessutom redundans. H200 tillhör NVIDIAs Hopper-generation (H100/H200), som Blackwell (B200 och senare) håller på att ersätta. NVIDIA säljer och stöder fortfarande Hopper-korten, men har börjat meddela end-of-life för delar av generationen. Inför ett nytt inköp rekommenderar vi därför att du kontrollerar tillgängligheten och överväger Blackwell. Gemma 4 bör också rymmas på ett enda B200-kort, som har mer minne och bandbredd än H200, men det har vi inte testat ännu.

Med Inkling Small uppskattar vi att 2× B200 ger ~150 tokens/s per svar och plats för 17–53 samtidiga konversationer med full kontext på 100 000 tokens. Hela Inkling-modellen får bara plats på en hel nod, och där uppskattar vi att 8× B200 ger ~110 tokens/s per svar och plats för 44–142 sådana konversationer. Den konfigurationen ger mer kapacitet och en större modell, inte snabbare svar per användare. Inkling-modellerna kräver Blackwell-GPU:er och kör inte på H100/H200. Vi har räknat fram B200-siffrorna från våra mätningar på H200 och hårdvarans specifikationer, men har ännu inte kört dem under verklig last.

Stödmodeller. Embeddings (sökning), tal-till-text och bildmodellen som tolkar bilder och diagram i dokument är mindre. I vår största lokala installation delar de på ett GPU-kort med 94 GB och använder ungefär 50 GB av minnet. Planera därför för ett kort med minst 80 GB om de ska köra tillsammans (till exempel NVIDIA RTX PRO 6000 Blackwell Server Edition, 96 GB).

GPU-servrarna behöver GPU:er för datacenter (passivt kylda) i en server som är certifierad för dem, med tillräckligt luftflöde och tillräcklig strömförsörjning.

Utöka installationen

Det tar lång tid innan dokument blir sökbara: kontrollera bearbetningsköerna. Har workers nått sitt tak höjer du maxReplicas och lägger till CPU och RAM i VM:en.
Minnesbrist eller vräkta poddar: lägg till RAM först. Minnet är den vanligaste begränsningen på plattformens VM.
Svaren dröjer under belastning (scenario 3): lägg till ett GPU-kort för språkmodellen.

Tillgänglighet och säkerhetskopiering

Alla scenarier kör på en enda VM. Om din virtualiseringsplattform startar om en VM på en annan värd efter ett hårdvarufel (till exempel vSphere HA) täcker det de flesta behov av tillgänglighet, till priset av några minuters avbrott. VM-snapshots är ingen konsekvent säkerhetskopia av databasen. Vi sätter upp regelbundna databasdumpar, och dem ska du lagra utanför VM:en.

Nätverk och brandvägg

Inkommande trafik (portar)

Port 443: Webbgränssnittet (HTTPS), från dina användares nätverk.
Port 80: Automatisk omdirigering till HTTPS.
Port 22: SSH, för installation och drift. Begränsa porten till Intrics åtkomstväg (till exempel din VPN); den ska inte vara öppen mot internet.

Utgående trafik (Whitelist - Infrastruktur)

Utöver språkmodellerna (se avsnittet nedan) behöver servern HTTPS-åtkomst till:

get.k3s.io, github.com, objects.githubusercontent.com (installation av k3s)
ghcr.io, pkg-containers.githubusercontent.com (Intrics containeravbilder och Helm-charts)
registry-1.docker.io, auth.docker.io, production.cloudflare.docker.com (containeravbilder från tredje part)
login.intric.ai (Intric använder sin IdP för autentisering)

Om din proxy eller brandvägg inspekterar TLS undantar du de här värdarna. Installationer utan utgående åtkomst är möjliga om du speglar alla avbilder till ett privat register.

Språkmodeller vid on-prem-drift

I scenario 1 och 2 anropar plattformen och bearbetningens workers språkmodeller, embeddings och tal-till-text över nätverket. Tillåt utgående trafik till:

Intric Hosted Models (EU):

gpu6.intric.ai (språkmodell som Intric driftar)
embedding-model.intric.ai (embeddings som Intric driftar)
Tal-till-text: adressen beror på vilken transkriberingsleverantör din installation använder, och den får du av oss
mcp.intric.ai/* (MCP-servrar som Intric driftar)
mcp-servers.intric.ai/* (MCP-servrar som Intric driftar)

Det aktuella utbudet av modeller finns i adminpanelen under Modeller.

Externa publika modeller (API:er):

api.openai.com/v1
api.anthropic.com
api.berget.ai/v1
api.mistral.ai/v1

Domän och certifikat

DNS: Peka den domän du har valt (t.ex. app.company.com) mot serverns IP-adress med en A- eller AAAA-post.
SSL/TLS-certifikat: Du behöver tillhandahålla giltiga certifikat:
- Certifikatfil (.crt): Hela kedjan i PEM-format.
- Privat nyckel (.key): Den privata nyckeln i PEM-format.
- Obs: Kunden ansvarar för att förnya certifikatet.