Server and Hardware

Intric is delivered on Kubernetes from versioned Helm charts. If you do not already run Kubernetes (the charts require 1.29 or later; use a version that is still supported upstream), we install k3s, a lightweight Kubernetes distribution, on a Linux VM you provide. What that VM needs depends on which parts of the platform run in your environment and which parts you consume as hosted services.

Choose your scenario

Scenario	Runs in your environment	Consumed as a service	Hardware
1. Platform	Web app, API, databases, search index, object storage	Processing (PDF/OCR, document ingestion, transcription) and all AI models	One VM, 4–8 cores
2. Platform + processing	Scenario 1, plus the processing workers for PDF/OCR, document ingestion and audio transcription, which run on CPU	AI models that need a GPU: language models, embeddings, speech-to-text, image model	One VM, ~20–72 cores
3. Fully local	Scenario 2, plus all AI models on your own GPU servers: language models, embeddings, speech-to-text and image model	Nothing	VM from scenario 2, plus one or more GPU servers

Start with the scenario your data-handling requirements call for, not the largest one.

How these numbers were derived. CPU and memory figures are the reservations (Kubernetes requests) in our Helm charts, summed per scenario, plus headroom. They are not load-test results. GPU figures are marked measured where we run the configuration in production and estimated where they are calculated. Start at the suggested level, watch actual usage for the first weeks, and adjust (see Growing the installation).

Requirements for all scenarios

	Requirement
CPU architecture	x86-64 (amd64). A “core” on this page means one vCPU.
Operating system	Ubuntu 22.04 or later
Storage	SSD. Keep /var on the OS disk rather than a small separate partition.
Virtualization	Code sandboxes run as Firecracker microVMs and need hardware virtualization (KVM): install directly on the server, or enable nested virtualization for the VM.
Topology	Single node. There is no built-in high availability; see Availability and backup.

Scenario 1: Platform

	Minimum	Recommended
CPU	4 cores	8 cores
RAM	16 GB	32 GB
OS disk	100 GB	100 GB
Data disk	250 GB	500 GB

The platform’s services reserve about 2 cores and 6 GB and can burst to about 9 cores and 18 GB. The rest covers Kubernetes itself and any MCP servers you run on the same VM. At the minimum, a full burst does not fit in memory; memory is also the first limit you hit when adding MCP servers, so choose the recommended level if you plan to run several.

The data disk holds the database, search index and uploaded files, and grows with the amount of content you upload.

With hosted processing, Intric’s processing services fetch each uploaded file from your object storage and post the result back to your platform. Your API and object storage must therefore be reachable from Intric’s processing service over HTTPS with a valid certificate. Access can be limited to the source IP addresses we provide.

Scenario 2: Platform + processing

When a file is uploaded, it has to be turned into text before assistants can search it. That work is done by the processing services:

• PDF processing reads the layout, tables and text of PDF files, and recognises text on scanned pages (OCR).
• Document ingestion splits the text into passages and has an embedding model turn each one into a vector that search can find. If an image model is configured, ingestion also sends the pictures and diagrams in the documents to it for a description.
• Audio transcription prepares recordings and sends them to a speech-to-text model, which returns the text.

The workers themselves run on CPU. The models they call (embeddings, speech-to-text and the image model) need a GPU and do not run on the VM: in scenarios 1 and 2 the workers call models hosted by Intric over the network, and in scenario 3 they call models on your own GPU servers. Scenario 2 therefore needs no GPU.

A message queue hands each job to the right worker. In scenario 1 these services run at Intric as a hosted service; in scenario 2 they run on your VM. The workers scale automatically with the number of jobs waiting, and only use CPU while documents or recordings are being processed. PDF processing dominates the footprint: each PDF worker reserves 6 cores and 5 GB, because OCR on scanned pages runs AI models on the CPU. A single document is processed by one worker; more workers let more documents be processed in parallel.

Level	PDF workers	Document ingestion workers	Transcription workers	CPU	RAM
Entry	1	2	1	~20 cores	~40 GB
Standard	4	4	3	~40 cores	~60 GB
High throughput	9	9	5	~72 cores	~88 GB

Each total is the scenario 1 minimum (4 cores / 16 GB), plus the processing reservations, plus 8 cores / 16 GB burst headroom. For example, Standard: 4 PDF workers (24 cores / 20 GB), 4 document ingestion workers (1.2 cores / 2 GB), 3 transcription workers (0.6 cores / 2.3 GB) and the message queue, job coordination, code sandbox and export worker that always run (1.4 cores / 1.9 GB) add up to about 27 cores / 26 GB; with the platform and headroom that is about 40 cores / 60 GB.

Code sandboxes. Code runs in sandboxes, each a Firecracker microVM. Add the following to each level for its concurrent sandboxes:

Level	Concurrent sandboxes	Add
Entry	4	+3 cores, +3 GB RAM, +18 GB disk
Standard	5	+4 cores, +4 GB RAM, +24 GB disk
High throughput	7	No extra CPU or RAM (reduce the PDF workers from 9 to 7), +42 GB disk

Entry works, but large uploads queue up and a big scanned document takes noticeably longer. Standard is a good starting point for most organisations.

Under load a PDF worker can use up to twice its CPU reservation and up to 8 GB of memory. If every PDF worker at High throughput bursts at once, memory use can exceed the total above; add RAM if you see memory pressure. Because processing is idle most of the time, on VMware or similar the unused CPU remains available to other VMs: reserve memory for the VM, not CPU.

Disk: add about 50 GB for container images (the PDF processing image alone is about 9 GB). Each transcription worker writes up to 2 GB of temporary files while running, and the code sandbox up to 1 GB, on the filesystem that holds /var/lib/kubelet. A full /var makes Kubernetes evict workloads across the whole VM.

The Helm chart ships conservative worker ceilings: consumers.pdfPreProcessing.scaling.maxReplicas defaults to 2, and document ingestion and audio transcription to 5. Raise each ceiling to at least the count for your level, or the workers will not scale into the capacity you have provided.

Scenario 3: Fully local

All AI models run on GPUs in your own data centre: the language model, and the supporting models that the processing workers call (embeddings, speech-to-text and the image model). The GPU server can be the same server as the platform: one server with GPUs runs the whole installation. That is the setup we recommend, because one server needs less RAM and fewer CPU cores in total than two: the operating system, headroom and memory are shared instead of duplicated. The GPUs can also sit in one or more separate GPU servers that the platform reaches over the network. Either way, the platform part is sized as in scenario 2, and the GPUs add their own CPU and memory (see GPU servers below).

Language model. Capacity depends far more on how many questions run at the same moment, and how long the attached documents are, than on the number of users. At one of our larger municipal customers, peak concurrency in production is around 10 simultaneous requests.

These recommendations change continuously. Models and GPU generations move quickly, and what we recommend today may be replaced within months. The configurations below reflect our assessment as of October 2026; we revise them as we measure new models and hardware, and we confirm the sizing with you before you order anything.

Configuration	Recommended EU/US model (Intelligence Index)	Recommended global model (Intelligence Index)	Suited for	Status
1× H200 (141 GB)	Nemotron 3.5 Super VL (26, documented)	Qwen3.8-Flash-Next (40, estimated)	Chat and questions over documents	Measured in production, with Gemma 4 31B
2× B200	Inkling Small (26, documented)	Qwen3.8-Flash-Next (40, estimated)	Faster responses, long documents, more complex multi-step tasks	Estimated
8× B200 (one node)	Muse Spark Open (39, documented)	DeepSeek V4.1 Flash 1017 (45, estimated)	Many concurrent users and the most demanding tasks	Estimated
1–2× RTX PRO 6000 (96 GB), plus 1 for the supporting models	Nemotron 3.5 Super VL (26, estimated)	Qwen3.8-Flash-Next (40, estimated)	Smaller installations on one standard rack server	Estimated

The Intelligence Index is Artificial Analysis’s general score for reasoning, coding and agent tasks (v4.3.2, read 23 October 2026). Documented means a vendor document or an official serving recipe shows the model running on that configuration; estimated means community reports or our own calculation. We do not recommend a model that scored below 80 on our Swedish language test. The global column includes models from Chinese developers; the EU/US column does not.

1× H200 is the configuration we run in production today. Measured with our current production model, Gemma 4 31B (4-bit weights, vLLM): ~100 tokens/s per response for a single request, and room in GPU memory for about 900,000 tokens of conversation context, which is roughly 9 conversations at a full 100,000-token context at once, or far more at typical prompt sizes. Adding a card running its own copy of the model is estimated to add the same capacity again and gives redundancy. The H200 belongs to NVIDIA’s Hopper generation (H100/H200), which is being succeeded by Blackwell (B200 and later). Hopper cards are still sold and supported, but NVIDIA has started announcing end-of-life for parts of the generation, so for a new purchase we recommend checking availability and considering Blackwell. Gemma 4 should also fit on a single B200, which has more memory and bandwidth than the H200, but we have not yet tested it there.

2× B200 with Inkling Small is estimated at ~150 tokens/s per response and room for 17–53 conversations at a full 100,000-token context. 8× B200 with the full Inkling model, which only fits on a whole node, is estimated at ~110 tokens/s per response and room for 44–142 such conversations; it buys capacity and model size rather than faster responses per user. Some models, the Inkling family among them, require Blackwell GPUs and do not run on H100/H200. The B200 figures are calculated from our H200 measurements and the hardware specifications; we have not yet run them under real load.

1–2× RTX PRO 6000 fits smaller installations: the platform and all models share one standard rack server with a single CPU socket, and cards can be added later. Which models run best on it changes quickly; we confirm the current choice with you before you order.

Supporting models. Embeddings (search), speech-to-text and the image model that interprets pictures and diagrams in documents are smaller. In our largest local installation they share one 94 GB GPU and use about 50 GB of its memory, so plan for a card with at least 80 GB if they are to run together (for example an NVIDIA RTX PRO 6000 Blackwell Server Edition, 96 GB).

GPU servers. Each GPU needs at least 7 physical CPU cores and 128 GB of system memory in its server, because models are loaded through system memory. These are physical cores: elsewhere on this page a core means one vCPU, and a physical core runs two. Fill every memory channel, use redundant power supplies, and plan power and cooling for up to 600 W per GPU. Use data-centre (passively cooled) GPUs in a server certified for them, with adequate airflow and power.

Growing the installation

• Documents take long to become searchable: check the processing queues. If workers are at their ceiling, raise maxReplicas and add CPU/RAM to the VM.
• Memory pressure or evicted pods: add RAM first; this is the most common limit on the platform VM.
• Answers slow to start under load (scenario 3): add a GPU for the language model.

Availability and backup

All scenarios run on a single VM. If your virtualisation platform restarts a VM on another host after a hardware failure (for example vSphere HA), that covers most availability needs, at the cost of a few minutes of downtime. VM snapshots are not a consistent database backup; we set up regular database dumps, which should be stored outside the VM.

Network and Firewall

Incoming traffic (Ports)

• Port 443: Web interface (HTTPS), from your users’ networks.
• Port 80: Automatic redirect to HTTPS.
• Port 22: SSH, for installation and operation. Restrict it to Intric’s access path (for example your VPN); it should not be open to the internet.

Outgoing traffic (Whitelist - Infrastructure)

In addition to language models (see section below), the server needs HTTPS access to:

• get.k3s.io, github.com, objects.githubusercontent.com (k3s installation)
• ghcr.io, pkg-containers.githubusercontent.com (Intric container images and Helm charts)
• registry-1.docker.io, auth.docker.io, production.cloudflare.docker.com (third-party container images)
• login.intric.ai (Intric’s IdP is used for authentication)

If your proxy or firewall inspects TLS, exclude these hosts. Installations without outbound access are possible by mirroring all images to a private registry.

Language models for on-prem operation

In scenarios 1 and 2, the platform and the processing workers call language models, embeddings and speech-to-text over the network. Allow outbound traffic to:

Intric Hosted Models (EU):

• gpu6.intric.ai (Intric-hosted language model)
• embedding-model.intric.ai (Intric-hosted embeddings)
• Speech-to-text: the endpoint depends on the transcription provider configured for your installation; we provide it
• mcp.intric.ai/* (Intric hosted MCP servers)
• mcp-servers.intric.ai/* (Intric hosted MCP servers)

The current model line-up is listed in the admin panel under Models.

External Public Models (APIs):

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

Domain and Certificate

1. DNS: Point your chosen domain (e.g. app.company.com) to the server’s IP with an A or AAAA record.

2. SSL/TLS certificate: You need to provide valid certificates:

   • Certificate file (.crt): Full chain in PEM format.
   • Private key (.key): Private key in PEM format.
   • Note: The customer is responsible for certificate renewal.