Mule Agent Deployment & Hardware Requirements (By Team Size)

Mule Agent is not "a single Java service" — it's a full stack. Beyond the Agent core, it includes a database, knowledge graph, vector search, object storage, document parsing, and more. These are what actually consume most of your RAM and disk.

Below are reference configurations by team size. Key principles:

Choose a Configuration by Team Size

Under 10 · All services on one machine

One 8-core 32G server + cloud LLM is enough

ItemReference config
Server8-core 32G minimum (Agent + database + knowledge graph + vector search + object storage + text embedding all on one machine. 32G is the floor; go 64G if you have many users or documents)
Disk512G minimum (knowledge base, chat history, vector index, and media files all accumulate locally)
GPUNot needed (text embedding runs on CPU; the model uses a cloud API)
ModelCloud LLM API (DeepSeek, etc.), pay per use
Best forSmall team trials, cross-border e-commerce support, getting started fast
10–50 people

16-core 64G minimum; GPU depends on compliance

ItemReference config
Server16-core 64G minimum, stable under concurrent load; consider separating the database and vector search or adding cache
Disk512G minimum, knowledge base + vector index + media grow quickly
GPUNot needed by default (cloud API); add a GPU host for SGLang if data is sensitive
ModelCloud API primarily; add a GPU to run open-source models if compliance requires
Best forMost office and R&D teams; private deployment for finance/healthcare when compliance demands it

This size is the dividing line: no strict compliance, cloud API is cheapest; with hard compliance requirements, add a GPU host and go private.

50–500 people

Separate machines recommended: database, vector store, object storage independent

ItemReference config
Agent server8-core 32G (dedicated to the Agent core, no other services mixed in)
Database / vector storeDatabase + vector search + knowledge graph on one separate 16-core 64G machine
Object storageSeparate 4-core 8G + large disk (when media/documents are heavy)
Disk1T minimum total, grows with knowledge base and media
GPUNot needed on cloud; if private, size the GPU host by model
Best forMulti-subsidiary groups, chain retail, cross-border trade — many users, many departments

At high volume: if you make many calls per day, private SGLang's marginal cost (power + depreciation) can beat pay-per-token API — worth running the numbers at this scale.

500+ people

Private deployment + dedicated GPU cluster; split all services

ItemReference config
Agent clusterHorizontal scale across nodes, 16-core 64G per node; database deployed separately
Database / vector storeDatabase + vector search + knowledge graph on separate HA nodes
Object storageDistributed object storage cluster (multi-node redundancy)
GPUPrivate SGLang cluster (single/multi GPU, depending on concurrency and model size)
DiskTB-scale to start, grows with knowledge base and audit trails
Best forState-owned enterprises, finance, healthcare, government — strict compliance + large scale

This size usually has an IT team; we provide onboarding support for deployment and operations (initial implementation + 1–3 months of co-piloting).

GPU Memory Reference for Private Local Models (SGLang)

If you go private, GPU memory determines how large a model you can run. The table below assumes 4-bit quantization, ~8K context, and a single user:

Model sizeVRAM needed (ref)Typical GPUBest for
7B~8B (e.g. Qwen 7B)~6–8 GBRTX 4060 Ti 16G / 4070 classPolicy lookup, Q&A — light tasks, good enough
14B class~10–16 GBRTX 4070 Ti S / 4080 classDocument writing, spreadsheet cleanup — everyday office
32B class~20–32 GBRTX 4090 24G (quantized) or dual GPUClose to mid-tier cloud model quality
70B+ class48 GB+Dual 4090 / A100 classPlenty of budget, highest demands

VRAM figures are references and vary with model version. The table is a general industry reference — before deployment we'll produce a config list based on your actual document volume and the model you want to run.

Two factors that significantly increase VRAM — consider them before buying:

FactorImpact (reference)
Long documents / contextProcessing contracts or bids needs 32K-class context. Small models (7B) add only 1~2G — manageable; 32B-class may add 8G or more — the "runs on one 4090" conclusion no longer holds, and you'll need dual GPUs or more VRAM.
Concurrent usersWhen multiple employees ask questions at once, each takes a context-cache slice, stacking VRAM usage. Serving engines like SGLang optimize batching, but total VRAM remains the hard limit.

So treat the table as a starting point only: one person occasionally looking up policies — pick by the table; dozens of daily users plus long documents — raise the budget a tier, or send us your real scenario — we'll produce a config list based on your document lengths and concurrent users before deployment. Getting this wrong is the most expensive mistake.

Cloud vs Private, at a Glance

Cloud LLM APIPrivate Local Model (SGLang)
Initial hardware costOne 8-core 32G + 512G disk to startPlus a GPU host (thousands to tens of thousands, depending on model size)
Long-term model costPay per token to the API provider, only what you usePower + hardware depreciation, cheaper at high volume
Model qualityCloud flagship models directly, best qualityOpen-source is weaker than cloud flagship; 32B covers most office tasks
Data leaves your network?Query content leaves the network (sessions and knowledge base stay local)Never
Works offline?No (cloud API)Yes
Best forCross-border e-commerce support, general office, teams that want to try firstFinance, healthcare, government, state-owned enterprises, R&D code-sensitive teams

Our recommendation

If unsure, start with a cloud API trial: a single 8-core 32G + 512G server/NAS is enough to get running. Let the team use it for two weeks to see real usage and answer quality. Once it proves out, or if compliance demands it, add a GPU host and switch to private — both routes use the same Mule Agent; switching only changes the model endpoint, and your data and skills are fully preserved. No need to start over.

An honest note on the private route: local open-source models are genuinely weaker than cloud flagship models at complex reasoning and long-document understanding. If your use case is mostly policy lookup, process questions, and formatted documents, a 32B local model is enough; if you need GPT-level writing and reasoning, either accept the API route or budget for a bigger GPU. We'll recommend a config based on your real scenario before deployment — we won't oversell hardware.

Not sure which config fits you?

Tell us your team size, main use cases, and data compliance requirements, and we'll give you a deployment config recommendation (with a full hardware list) — free.

Get a free deployment config →