Zanus AI vs building your own private AI server

What Zanus AI sells, as of September 2026

Zanus AI sells a private AI server for a business, and the question behind most searches for it is what the same private AI server costs to build yourself. The short version: the appliance is a no-code box, priced by quote, that arrives configured and can run with no internet connection at all. The do-it-yourself version is a rented GPU (graphics processing unit) server running open-weight LLMs (large language models) behind an inference server, a chat interface, a vector store and an agent framework, and it needs one person who can run Linux. Which path is right turns on four things: who does the engineering, where the data is allowed to live, whether you can feed a 6 kW machine, and how many tokens a day you really use.

Everything here about Zanus comes from zanusai.com as read in September 2026. The company describes itself as "a privately held American C-Corp specialized in high-tech AI solutions and engineering, headquartered in Pompano Beach, Florida", which its own page places in the greater Fort Lauderdale area. It says its hardware and software are "designed and assembled in the USA".

The product has three layers. Front Office AI is "the AI workforce your customers talk to": phone, web chat, quotes and bookings. Back Office AI is "the AI operating system your company runs on", described as "15+ modules. Zero coding. Built in." The modules named on the page include a vector store, AI chat, clients, suppliers, calendar, tasks, automations, web chatbots and an API (application programming interface). To the question "Do we need a developer?" the page answers "No." The third layer, Private On-Premises AI, is the same system on Zanus hardware inside your building. It runs "Zanus OS", it is sold as "fully owned: hardware + permanent software licenses", and it is "air-gap capable", taking updates by USB when you keep it off the internet.

On models, the server page says the box runs "the leading open-weight families", "chosen and sized with you at configuration", and that you can "swap or add models any time: new weights are a download". It does not name the families, the GPUs, the RAM or the storage size beyond "RAID 10 NVMe". On power, it needs a "standard 50A circuit @ 115/220V" and draws "6 kW max" at full load, and the page describes the unit as silent and office-friendly, with no server room needed. On price, the box is "by RFQ" (request for quotation), "sized on GPU memory (models), RAM/context, and tokens per day". There is no public price for the hardware. The hosted Front Office plans do list flat yearly prices, from $4,900 to $49,900 a year as of September 2026, but those are cloud tenants in the Zanus datacenter, not the appliance. Delivery is quoted at about three weeks, configured.

That is the public spec. Nothing below adds to it or guesses past it.

What the same private AI server looks like when you build it

The appliance bundles four things you can rent and assemble yourself: a GPU, an inference server that loads open-weight models, a chat interface for people, and a vector store with an automation layer that turns your documents into answers. The Linux part takes an afternoon. The business modules take weeks, and that gap is the real difference between the two paths.

Pick the box first. A CPU-only VPS (virtual private server) with 16 GB to 32 GB of RAM runs 7B and 8B models for one or two people at a time, at speeds you should measure in tokens per second before anyone depends on it. A rented GPU with 24 GB of VRAM (the memory on the graphics card) runs 8B models fast enough for a small team and fits models up to about 30B at 4-bit; 48 GB to 80 GB is the 70B class. Which models fit which card is worked through in what AI models you can self-host at each memory size.

Install the inference server. Ollama's Linux install is one line, and the full walkthrough lives in running Ollama on a VPS to self-host an LLM:

curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl status ollama
ollama -v

systemctl status ollama should read active (running). On a machine with no GPU the installer prints WARNING: No NVIDIA/AMD GPU detected. Ollama will run in CPU-only mode. and continues, which is fine for testing and slow for users.

Pull a model and talk to the API. The service listens on port 11434 on the loopback address only:

ollama pull qwen3:8b
curl http://127.0.0.1:11434/api/generate \
  -d '{"model":"qwen3:8b","prompt":"Reply with one word: ready","stream":false}'

A healthy reply is a JSON object with a response field and "done":true. A reply of {"error":"model requires more system memory (6.4 GiB) than is available (3.8 GiB)"}, with your own two figures, means the weights do not fit in RAM, so pick a smaller model or a smaller quantization.

Add the chat interface. Open WebUI is the usual choice, and its README gives one command for the case where Ollama runs on the same host:

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

Browse to port 3000 on the server's address, create the first account (it becomes the admin), and open the model list. If the list is empty, the cause is the loopback binding above: inside the container, host.docker.internal resolves to the host's Docker bridge address, and Ollama is listening on 127.0.0.1 only, so the connection is refused. docker logs open-webui shows Cannot connect to host host.docker.internal:11434. Fix it with a systemd override:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama

0.0.0.0 means every interface, including the public one. From this point the API is reachable from the internet unless the firewall blocks port 11434, and the API has no password of its own, so secure the Ollama API endpoint before you load a single company document. If Open WebUI is heavier than you want, there are lighter Open WebUI alternatives that talk to the same port.

Add the vector store. Qdrant runs as one container. Bind it to loopback, since only the applications on the box should reach it:

docker run -d --name qdrant --restart always \
  -p 127.0.0.1:6333:6333 -p 127.0.0.1:6334:6334 \
  -v qdrant_storage:/qdrant/storage \
  qdrant/qdrant
curl http://127.0.0.1:6333/collections

The check returns {"result":{"collections":[]},"status":"ok"} plus a timing field on a fresh install. Open WebUI has a built-in document store that is enough for a small library; Qdrant is for when an agent framework needs to query embeddings directly.

If more than a handful of people will use it at once, swap Ollama for vLLM, which batches requests across users on the GPU. The official image is the whole install:

docker run -d --runtime nvidia --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 127.0.0.1:8000:8000 --ipc=host \
  vllm/vllm-openai:latest --model Qwen/Qwen3-8B

If Docker answers that it could not select device driver with GPU capabilities, the NVIDIA Container Toolkit is not installed, so Docker has no way to hand the card to the container. Install the toolkit and restart Docker, then run the command again. When to prefer each server is covered in Ollama versus vLLM.

The last layer is the one the appliance calls modules. On the rented path it is an agent framework that reads from the vector store, calls the model, takes actions against your other systems, and logs what it did. The candidates and what each is good at are compared in the best self-hosted AI agents, and if the agent needs to remember users across sessions, a self-hosted Mem0 memory server gives it that. None of this exists until you configure it, and that is the part of the appliance you are actually paying for.

Cost: a quote against a monthly bill

There is no Zanus number to put here, and inventing one would be worse than useless. What the site does say is how the quote is sized: on GPU memory for the models and RAM for the context, and on your tokens per day. Those are the same variables that set the price of the rented path, so you can at least build your side of the comparison honestly.

On the rented side the cost is a fixed monthly rent for the GPU plus the time of whoever runs it. The rent does not change whether the card sits idle or runs flat out. That makes the comparison against a pay-per-token API a break-even problem: divide the monthly rent by the blended price per million tokens of the API you would otherwise use, and the result is the number of tokens a month you must actually push through the box before owning the GPU is cheaper than renting tokens. Below that volume the API wins on money. The arithmetic, with the traps around idle time and batch size, is in GPU VPS versus API tokens: where the break-even sits.

On the appliance side the shape is different: a capital purchase, a permanent software license, electricity, and the same tokens-per-day sizing done for you at quote time. A quote sized for today's volume is also a ceiling. Growing past it means another quote, while a rented GPU is a plan change.

Who does the engineering

The appliance's pitch is that nobody does. "Zero coding. Built in." and "Do we need a developer? No." are the whole point. You still run a business process change, since staff must learn new tools and someone must upload the knowledge and write the phone menu, but no one has to know what a systemd unit is.

The rented path needs one person who can do all of the commands above without help, and then keep doing them. Concretely, that person owns the operating system updates, the Docker images, the firewall and TLS (transport layer security) certificates, the backups of the vector store and the chat history, the model updates, and the monitoring that tells them the GPU driver broke after a kernel update. Budget a day for the first install and a few hours a month after that. Then budget the real work: nothing on the rented path comes with a clients table, a supplier list, a calendar or a booking flow. Each of those is an integration you write against your existing systems, or an agent framework you configure and then defend when it does something odd. If nobody on staff wants that job, the "no developer" answer is worth more than any hardware spec.

Where the data lives

The appliance's strongest claim is physical. "Your data never leaves" and "keeps data physically inside your building" describe a machine you can unplug from the network and still use. For a clinic or a law firm with a contract that says data stays on premises, that is the axis that decides, and no VPS matches it.

Say this plainly for the rented path: a VPS is a computer in someone else's datacenter. Your prompts, your documents, the model's answers and the vector index are processed in RAM on a host the provider owns, and they sit on a disk the provider can physically reach. "Private AI" on a VPS means private from the model vendor and from the public internet, and nothing more. Your hosting provider can still reach it, and a customer or an auditor who asks where the data is will get the name of a city rather than the name of a room in your building. Encryption at rest protects the disk if it is pulled. It does not protect what is in memory while a model is answering.

The middle position is your own hardware in a rack you rent, or a dedicated server nobody else shares. That keeps the model freedom and the monthly bill of the rented path while closing most of the physical gap. It also brings back the part the appliance removes: someone has to build the machine.

Power and space

A 6 kW machine is not an office PC. A standard wall socket in the United States is a 15 A or 20 A circuit; the page asks for a 50 A circuit, which is what an electric range or a fast electric-vehicle charger uses, so an electrician is part of the install. The site says the box is silent and office-friendly and only draws its peak while working. The idle draw is not published.

Electricity is the one running cost you can put a number on, because it is arithmetic. At 6 kW, every hour at full load is 6 kWh:

[
  {
    "label": "1 h/day at full load",
    "kwh_per_month": 180,
    "cost_usd_month": 27
  },
  {
    "label": "4 h/day at full load",
    "kwh_per_month": 720,
    "cost_usd_month": 108
  },
  {
    "label": "8 h/day at full load",
    "kwh_per_month": 1440,
    "cost_usd_month": 216
  },
  {
    "label": "24 h/day at full load",
    "kwh_per_month": "4,320",
    "cost_usd_month": 648
  }
]

A box that works one hour a day costs about 27 USD a month at 0.15 USD per kWh. One that runs flat out around the clock uses 4,320 kWh and costs about 648 USD. The vendor's own figure is "roughly $1/hour" at full load, which implies a somewhat higher tariff than the chart assumes, so use your own rate. All of that energy leaves the machine as heat, roughly 20,000 BTU (British thermal units) per hour at peak, which the room's air conditioning has to remove.

On the rented path, power and cooling are inside the rent, and the provider's datacenter carries the circuit. The trade is that you cannot see the meter: a GPU plan costs the same whether it works one hour a day or 24.

Model choice

The appliance ships with models chosen with you at configuration, from "the leading open-weight families", and the page says new weights are a download. Which families, how a swap is done inside Zanus OS, whether a model outside the vendor's list can be loaded, and who performs the swap are not documented publicly, so ask before you sign.

The rented path runs anything with published weights and enough memory to hold them. A new open-weight release is an ollama pull or a Hugging Face repository name passed to vLLM on the day it appears, and if you want a specific quantization or a fine-tune of your own, you import the GGUF file into Ollama yourself. The catch runs the other way too: you also own the evaluation. Nobody sized the model to your documents or your tokens per day, so the first month is spent finding out which model is good enough at which speed, and which quantization your memory can afford.

The private AI answering service: a module against a project

A lot of the traffic to "private AI server" is really looking for a phone receptionist, so treat that case on its own.

On the Zanus side, the phone agent is Front Office AI. The page says it "answers every call on your menu, in your chosen voices, 24/7 in up to 40 languages", with an IVR (interactive voice response) menu you write, and it is sold as a hosted tenant with an on-premises path on the top plan. Which speech models it uses and what its reply latency is are not published.

On the rented path, a voice agent is a separate project from the chat stack above, and a harder one. It needs four extra pieces: a telephony entry point (a SIP trunk, where SIP is the session initiation protocol, or a telephony API that hands you the audio), speech-to-text (STT), the LLM, and text-to-speech (TTS), all chained so that a caller hears a reply within about a second of finishing a sentence. Every link adds delay, so the models have to be small and the GPU has to be close. The STT and TTS halves, with the engines that run locally and how fast each one is, are in self-hosted speech-to-text and text-to-speech on a VPS. Expect the phone agent to take longer than the whole chat stack above, and expect the first version to interrupt callers. If the receptionist is the only thing you want, the appliance's module or a hosted voice product is the shorter road, and the chat server is a distraction.

The decision rule

Buy the box when all four are true: a contract or a regulator says the data stays in the building, nobody on staff will run Linux, you have or will fit a 50 A circuit, and the modules on the page match the work you actually do. The quote is the price of not having an engineer. Get the model list and the swap procedure in writing before you sign.

Rent and build when one person can own the server, the data may live at a hosting provider you have vetted, you want to choose the model yourself, and your usage is steady enough that a monthly GPU beats the token bill at the break-even above. You get every open-weight model on the day it ships and a bill you can change next month. You also get every integration as homework.

Use an API when usage is bursty or small, the data is not sensitive, nobody wants to run anything, and you need it working this week. Below the break-even volume it is cheaper, and it is always faster to start. Add a self-hosted layer later if the token bill or the data policy pushes you there.

FAQ

What does Zanus AI actually sell?

As of September 2026 zanusai.com describes three layers. Front Office AI handles phone, web chat, quotes and bookings. Back Office AI is "15+ modules. Zero coding. Built in." Private On-Premises AI is the same software on Zanus hardware running "Zanus OS" inside your building, sold as fully owned and air-gap capable. The hardware is priced by RFQ. It needs a 50 A circuit and draws up to 6 kW. The company is headquartered in Pompano Beach, Florida.

How much does a Zanus AI private server cost?

There is no public price for the hardware. The server page says "Price by RFQ", sized on GPU memory and RAM, and on your tokens per day. The hosted Front Office plans list flat yearly prices as of September 2026, but those run in the Zanus datacenter and are a subscription, so they do not price the box. To compare, price the rented path with the same variables and work out the break-even against API tokens.

Can I build a private AI server on a VPS without a GPU?

Yes, for a small number of users and small models. A CPU-only VPS with 16 GB to 32 GB of RAM runs 7B and 8B models through Ollama at a few tokens per second, which is enough to test a document assistant. It is not enough for a team using it at once or for a voice agent, where reply time matters. Measure tokens per second on your plan before anyone depends on it.

Is a self-hosted LLM on a VPS really private?

It is private from the model vendor and from the public internet, provided the firewall blocks port 11434 and the chat interface sits behind TLS. The hosting provider is the exception: its staff can reach the disk, and its host runs the model in memory. If a contract says the data must stay in your building, a VPS does not meet it. Your own hardware, in your office or in a rented rack, does.

Does the do-it-yourself path include a phone receptionist?

Not out of the box. A voice agent is a separate project: a telephony entry point, speech-to-text, the LLM, and text-to-speech, chained tightly enough that a caller hears a reply in about a second. It is the hardest piece of the rented path and the one where the appliance's module or a hosted voice product saves the most time.