A local LLM, embedding or multimodal model can exceed the resource footprint of the entire RAG platform.
Users moving from remote APIs to fully local AI.WeKnora Hardware Requirements: RAM, CPU, Storage & Local AI
Plan WeKnora hardware for RAM, CPU, document storage, RAG services and optional Ollama models, with practical ZimaOS one-click deployment sizing.
WeKnora requirements at a glance
WeKnora is a multi-service RAG and knowledge platform. Upstream requires Docker, Docker Compose and Git but does not publish one numerical hardware minimum; optional local models through Ollama must be sized separately.
- RAM
- No numerical official minimum published. Core services, document parsing, Redis/database/vector storage and optional integrations share host memory.
- CPU
- No numerical official core minimum published. Parsing, embedding ingestion, reranking and concurrent RAG requests can increase CPU demand.
- Storage
- No numerical official minimum. Source documents, parsed content, vector indexes, databases, logs and optional object storage determine capacity.
- AI models
- Remote APIs avoid local model memory. Local Ollama chat/embedding/rerank models have separate RAM/VRAM requirements based on the selected models.
- GPU
- Not required for WeKnora when AI models are remote. A GPU may materially improve local LLM/VLM workloads, but it is a model requirement rather than a core WeKnora requirement.
- Best Zima starting point
- ZimaBoard 2 1664 is the safer compact choice for WeKnora with remote AI APIs; use ZimaCube 2 Creator Pack only when a local GPU model workload actually justifies it.
From official requirements to the right setup
Size WeKnora in two layers: the RAG platform itself and the AI models it calls.
-
Official requirements
Start with the upstream prerequisites: Docker, Docker Compose and Git. WeKnora does not publish a universal CPU/RAM/disk hardware table.
-
Confirm your needs
Decide whether chat, embedding, reranking and multimodal models use remote APIs or local Ollama. Remote APIs keep model memory off the Zima host; local models do not.
-
Leave room to grow
Estimate document ingestion and index growth. Parsing, vector stores, Redis, database services, optional MinIO/Neo4j/Qdrant/OpenSearch and observability profiles can add significant resource demand.
-
Run it on ZimaOS
Install WeKnora from the ZimaOS App Store, start with the core service set, then enable local models or optional profiles only after verifying RAM, storage and model-specific acceleration requirements.
Check every playback client
- Remote API or local Ollama models
- Selected local model sizes
- Document volume and formats
- Embedding/index growth
- Optional vector/search services
- Object storage requirements
- Concurrent RAG users
- Other ZimaOS apps
Official minimum requirements
The current WeKnora repository documents container prerequisites and deployment profiles but does not publish a universal hardware minimum.
Do not turn a practical 8 GB or 16 GB recommendation into an official WeKnora minimum. Separate the core platform from local model inference: the latter can require far more RAM/VRAM than the RAG application itself.
| Requirement | Official minimum | What this supports |
|---|---|---|
| RAM minimum | No numerical official minimum published | Resource use depends on enabled services, ingestion and model deployment. |
| CPU minimum | No numerical official minimum published | Document parsing and RAG concurrency can increase CPU demand. |
| Storage minimum | No numerical official minimum published | Documents, indexes, databases and object storage drive growth. |
| Core prerequisites | Docker, Docker Compose and Git | Current upstream Getting Started requirements. |
| Local AI | Ollama is optional | The repository explicitly allows local Ollama models but does not require them for the platform. |
| Optional services | Redis plus optional MinIO, Qdrant, Neo4j, OpenSearch and others | Enabling additional profiles materially changes the whole-host resource budget. |
When to upgrade your hardware
WeKnora should scale when document ingestion, vector/search services or local model inference becomes the bottleneck.
Local Ollama models consume most host memory
Document ingestion and indexing queues grow
Optional search/graph/observability services accumulate
Large PDF/document batches increase parsing, embedding, vector-write and storage activity.
Knowledge bases importing large document collections.Qdrant, Neo4j, OpenSearch, MinIO or Langfuse add separate memory and disk requirements.
Advanced RAG deployments enabling full profiles.Plan hardware growth with confidence
Scale WeKnora by separating model inference from platform storage and search services.
Use remote AI APIs for the lightest server footprint
Remote chat, embedding and rerank APIs keep model RAM/VRAM off the Zima host.
ZimaBoard 2 1664 is a practical compact RAG-platform host.Move indexes and document storage to SSD
Parsing outputs, databases and vector indexes benefit from reliable low-latency persistent storage.
Use SATA/NVMe with ZimaBoard 2 or SSD tiers on ZimaCube 2.Use stronger CPU/RAM for larger RAG service stacks
More concurrent ingestion, search and optional database services increase whole-host resource demand.
ZimaCube 2 Pro provides stronger CPU plus 16 GB RAM and larger storage expansion.Choose GPU hardware only for local model inference
A dedicated GPU is useful when the chosen local LLM/VLM supports and benefits from it; it is not required for remote-API WeKnora.
ZimaCube 2 Creator Pack is appropriate only when its RTX Pro 2000 matches the selected model workload.Can it run on ZimaOS?
WeKnora currently has a public official ZimaOS App Store page, so the normal deployment can use the one-click path.
Install WeKnora from the ZimaOS App Store
Use the official WeKnora listing for the packaged deployment, then configure model providers, persistence and optional integrations based on your workload.
Open WeKnora in the ZimaOS App Store ↗Follow the upstream Docker deployment model
WeKnora's repository documents Docker Compose as the standard start path and supports remote model APIs or optional local Ollama.
Review WeKnora deployment ↗Enable optional services selectively
The Compose files expose optional MinIO, Qdrant, Neo4j, OpenSearch and observability profiles; enabling all of them changes the hardware profile substantially.
Review WeKnora Compose services ↗Choose Zima hardware for WeKnora
WeKnora can be a moderate RAG application or a much heavier local-AI stack depending on whether model inference is remote or local.
Will WeKnora use remote AI APIs or run local Ollama models on the same server?
Remote chat/embedding/rerank APIs
Prioritize 16 GB RAM and SSD-backed platform/index storage rather than GPU hardware.
- Best compact choiceZimaBoard 2 1664
- More CPU/storage headroomZimaCube 2 Pro
Local GPU-assisted LLM/VLM workload
Size from the exact models first; use GPU hardware only when the selected model fits the available VRAM/RAM.
- GPU-capable Zima optionZimaCube 2 Creator Pack
These are workload recommendations, not model-throughput guarantees. Local model size, quantization, context length, parsing, vector stores and enabled optional services can change requirements dramatically.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 1664 | WeKnora with remote model APIs and a moderate document collection. | Core RAG services, parsing, Redis/database/index workloads and remote AI providers. |
|
16 GB is a practical recommendation, not an upstream minimum; optional services can still push beyond it. | Get Now |
| ZimaCube 2 Pro | Larger WeKnora deployments with more documents, concurrency and optional search services. | Heavier parsing/indexing, larger persistent datasets and multiple optional containers. |
|
No dedicated GPU is included; local models must still fit system RAM or use another inference host. | Get Now |
| ZimaCube 2 Creator Pack | WeKnora with local GPU-assisted AI models that fit the available RTX Pro 2000 VRAM. | RAG platform plus local Ollama-compatible model workloads and larger storage/memory headroom. |
|
The GPU is unnecessary when using remote APIs, and model fit must be checked individually before choosing this configuration. | Get Now |
What the Press Says
Highlights from trusted reviewers worldwide.
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”Read full review
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”Read full review
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”Read full review
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”Read full review
Loved by the Community
Stories and reviews from people who build with Zima every day.
★★★★★
Zima Blade Little yet Powerful
Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.
★★★★★
Very good!!
I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.
★★★★★
Great innovation for mini server!
It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.
★★★★★
Avaliação ZimaBoard 2
Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.
Frequently asked questions
These answers cover WeKnora RAM, CPU, local AI, GPU, document storage and ZimaOS deployment.
How much RAM does WeKnora need?
WeKnora does not publish a universal official RAM minimum. Core services and document indexing need far less memory than some local LLMs, so model deployment must be sized separately.
How many CPU cores does WeKnora need?
There is no numerical official core minimum. Parsing, embedding ingestion, vector search and concurrent RAG requests determine practical CPU demand.
Does WeKnora require a GPU?
No. WeKnora can use remote AI APIs without a local GPU. GPU requirements only arise when you choose local models that benefit from acceleration.
Can WeKnora use Ollama?
Yes. The official repository documents optional local Ollama support for local model configurations.
How much storage does WeKnora need?
There is no universal upstream disk minimum. Source documents, parsing outputs, vector indexes, databases and optional object storage determine capacity.
Can ZimaBoard 2 run WeKnora?
Yes for a practical remote-API deployment. The 16 GB model gives more headroom for RAG services, indexing and optional containers than the 8 GB model.
When does WeKnora need ZimaCube 2 Creator Pack?
Only when you intentionally run local GPU-assisted AI models whose memory/acceleration requirements fit the RTX Pro 2000 configuration. Remote-API WeKnora does not need it.
Is WeKnora available in the ZimaOS App Store?
Yes. WeKnora currently has a public official ZimaOS App Store page and supports the normal one-click installation path.
What sources informed this WeKnora hardware guide?
The guide uses Tencent's current WeKnora repository and Compose files plus the official ZimaOS listing and current Zima hardware pages.
