PIES Studio · Operations Manual
Run PIES Ultra — the AI engine behind PIES Studio — entirely on your own GPU infrastructure. Your prompts, application definitions, and data never leave your network. This manual covers installation, connecting PIES Studio, day-to-day operation, and troubleshooting.
PIES Private AI is a single Docker container that serves the PIES Ultra v0.9 model — the single model this release ships (17B active / 400B total parameters) through an OpenAI-compatible API, plus an administration API that PIES Studio manages it through. It runs only with a valid PIES license and stores everything — model weights, your license, API keys — in one Docker volume on your server.
| Requirement | Detail |
|---|---|
| GPU | NVIDIA, 256 GB+ total VRAM — e.g. 4× A100 80GB, 2× H200, 2× B200. Weights are 216 GB; the rest is KV cache and headroom, so 256 GB is the floor, not the target. Verified on 2× H200 and 2× B200. (An Apple Silicon Mac with 256 GB+ unified memory also works for small teams — see section 3) |
| OS | Linux x86_64 |
| Software | Docker with the NVIDIA Container Toolkit |
| Disk | ~350 GB free — 216 GB of weights plus download temp space |
| Network | Outbound HTTPS for the one-time weights download; port 8000 reachable by PIES Studio |
| License | Your pies_studio.license file, provided by your PIES account manager |
No license, no inference. The service starts without a license but refuses all AI requests until a valid, unexpired license is installed. Health and administration endpoints stay available so you can always see why.
Any machine meeting the specification above works. Four setups worth naming, in the order most organisations consider them: a server you own, a GPU rented by the hour while you evaluate, a cloud VM inside your own subscription, and — for smaller teams — an Apple Silicon Mac.
PIES Private AI was built for this. The model runs on hardware you own, in a building you control, and nothing about a request — the prompt, your data, your application — leaves the room. It is the only option that can be made genuinely air-gapped, and the only one where the running cost is the electricity.
| What you need | Detail |
|---|---|
| A GPU server with 256 GB+ VRAM | 4× A100 80GB, 2× H200 or 2× B200 all clear it. An NVIDIA DGX or any vendor's equivalent works — nothing here is specific to a brand of chassis |
| Linux x86_64, ~350 GB free | 216 GB of weights plus room to download them. Local NVMe keeps load times short |
| NVIDIA drivers + Container Toolkit | The only host software required. Everything else ships inside the container |
| Reachable on port 8000 | From your PIES Studio hosts only. No inbound internet, no public address |
Internet access is needed once, to download the weights — and not even then if you bring them in on media, which is covered in section 7. After that the server can be disconnected entirely and the platform keeps working: the license is validated locally, not by calling home.
Buying advice, briefly. Fewer, larger cards beat more small ones: the weights are split across GPUs, so 2× 141 GB is simpler and faster than 8× 40 GB. Total VRAM is what matters, and 256 GB is the floor rather than the target — headroom above it becomes KV cache, which is what lets several people build at once.
The cheapest way to stand PIES Private AI up, and the one to use while you are evaluating. Providers such as RunPod, Lambda or Vast rent GPU machines by the hour and let you stop them when you are not using them.
| Choose | Why |
|---|---|
| 2× H200 or 2× B200 | 256 GB+ VRAM in the fewest cards. Both verified by PIES |
| A persistent network volume of 550 GB+ | This is the important one. Weights live on the volume, so stopping the machine keeps them — a restart takes minutes rather than re-downloading 216 GB |
| The container port 8000 exposed | PIES Studio talks to it here. Most providers give you a proxied HTTPS URL |
Install exactly as in section 4 — it is an ordinary Linux host with GPUs. What differs is the running cost: you pay per hour while it runs, and only for the volume while it is stopped. That makes it practical to run the AI during working hours and stop it overnight; the model reloads into VRAM in 10–20 minutes on the next start.
Check the machine you get back. After a stop/start some
providers reallocate hardware, and a machine that comes back with fewer GPUs
than it had will fail to load the model — with an out-of-memory error rather
than an obvious explanation. Confirm the GPU count after every start:
nvidia-smi -L.
What most organisations move to for production: the machine lives inside your tenancy, your network controls, and your compliance boundary. On Azure the relevant families are ND A100 v4 (8× A100 80 GB) and ND H100 v5 (8× H100 80 GB); AWS and Google have direct equivalents.
| Step | Detail |
|---|---|
| Size the VM | Any GPU VM totalling 256 GB+ VRAM. The 8-card families exceed it comfortably, leaving room for a large KV cache |
| Attach a data disk | 512 GB+ Premium SSD for the weights, mounted where the container's volume lives. Keep it separate from the OS disk so the VM can be resized or rebuilt without another download |
| Install GPU drivers | The provider's GPU driver extension, then the NVIDIA Container Toolkit so Docker can see the cards |
| Restrict the port | Allow 8000 only from your PIES Studio hosts, in the network security group. The service is licensed and key-protected, but it should not be open to the internet |
| Keep it private | No public IP is needed if Studio reaches it over your virtual network or a peering |
Reserved or committed-use pricing changes the economics substantially for a machine that runs continuously — worth pricing before choosing between hourly rental and a cloud VM.
On cost. GPU pricing moves quickly and differs by region and commitment, so we do not quote figures that would be stale by the time you read them. The shape holds, though: renting by the hour is far cheaper while you are evaluating and stopping the machine between sessions, and a committed cloud VM wins once the AI is in constant use. The one cost that persists either way is storage for the weights.
A Mac with Apple Silicon and enough unified memory runs PIES Ultra on the same llama.cpp engine as the Docker image, using Apple's Metal GPU. It serves one request at a time and answers more slowly than a multi-GPU server, which makes it a fit for a small team or an evaluation on hardware you may already own — not for many people building at once.
| What you need | Detail |
|---|---|
| An Apple Silicon Mac, 256 GB+ unified memory | 512 GB is comfortable and lets the machine do other work while the model is loaded; 256 GB is the floor and wants the model loaded first |
| ~250 GB free disk | The one-time weights download (~200 GB) plus headroom |
| macOS with Xcode Command Line Tools | xcode-select --install — needed once, to build the engine |
Install with one command in Terminal — it downloads PIES Private AI to
~/pies-private-ai:
curl -fsSL https://github.com/pies-io/pies-studio-releases/releases/download/private-ai-mac-v0.9/install-mac.sh | bash
Then, from that folder, three commands finish the job:
cd ~/pies-private-ai
./pies-llm.sh setup # one-time: engine + model download
./pies-llm.sh license /path/to/pies_studio.license
./pies-llm.sh start # loads the model, waits until ready
The same license rules apply as on a server: without a valid
pies_studio.license the service starts but refuses AI requests.
Lite option: add --lite to both commands to
run PIES Ultra Lite instead — a smaller model (~65 GB
download, 96 GB+ unified memory) that loads in about two minutes and
answers faster, at lower build quality. It suits evaluation and smaller Macs;
use full PIES Ultra for real work.
./pies-llm.sh setup --lite
./pies-llm.sh start --lite
All commands are safe to re-run — setup skips what is already done and a
stopped download resumes where it left off. ./pies-llm.sh status
shows health, and PIES Studio connects to port 8000 exactly as with the
Docker install (section 5).
On an Apple Silicon Mac, skip this section. Docker is not used
on a Mac — macOS gives containers no GPU access, so the
docker run commands below fail there by design. Use the Apple Silicon installer in section 3 instead; everything from
section 5 onward (connecting PIES Studio) applies to both.
Run everything below on the GPU server, as a user who can
run docker. Four steps; the installer does the checking.
pies-llm commandThe management CLI ships inside the container image — no separate download:
docker run --rm --entrypoint cat ghcr.io/pies-io/pies-llm:vllm /app/pies-llm-ctl.sh \
| sudo tee /usr/local/bin/pies-llm >/dev/null && sudo chmod +x /usr/local/bin/pies-llm
pies-llm install /path/to/pies_studio.license
It checks your GPUs, free disk and Docker GPU access, pulls the image, stores the license, generates your admin key and starts the service. If a prerequisite is missing it stops and says what to fix — nothing large is downloaded until the checks pass.
The installer prints your admin API key —
save it. It is also kept in ~/.pies-llm/config.
pies-llm logs -f
First start downloads 216 GB of model weights into the
pies-llm-models volume, then loads them into VRAM. The
service is deliberately quiet until the engine is ready — a port that
does not answer yet is normal, not a hang.
| Stage | Typical time |
|---|---|
| Weights download (once, cached on the volume) | 30–90 min |
| Engine load into VRAM (every start) | 10–20 min |
| Later starts (weights already present) | 10–20 min total |
pies-llm status reports model_loaded: false
until the engine finishes; then it shows backend: vllm and
your licence details.
pies-llm status # model_loaded: true, backend: vllm, license valid
Open port 8000 to PIES Studio, then in Studio go to
Administration → AI Settings →
PIES Private AI and enter:
http://<your-server>:8000Use Test connection, then check the
Private LLM tab shows the model Online. Run the CLI on
the server itself — it talks to the service on localhost.
| Command | What it does |
|---|---|
pies-llm status | Health, model state, license validity (with reason), GPUs |
pies-llm start / stop / restart | Control the service |
pies-llm logs -f | Follow live logs |
pies-llm debug | One diagnostic bundle to send to PIES support |
pies-llm license show | Organization, tier, expiry, days remaining |
pies-llm license install <file> | Install or renew the license (validated first, no restart) |
pies-llm key create <name> | Mint an inference-only API key (shown once) |
pies-llm key list / key delete <id> | List (masked) or revoke keys |
pies-llm uninstall | Remove the service; weights and license are kept |
The admin key (created at install) opens everything and is
what PIES Studio uses. Inference keys
(pies-llm key create) can only run AI requests — hand them to
individual apps or teams, and revoke any one of them at any time without
affecting the others.
PIES issues you a single file, pies_studio.license — either
attached to an email or downloaded from the setup link your account manager
sends. Copy it to the GPU server and point the installer at it. It is stored
on the pies-llm-models volume beside the model weights, so it
survives restarts, container recreation and upgrades; the copy you were sent
is not needed afterwards.
pies-llm license show # org, tier, expiry, days remaining
pies-llm license install ~/pies_studio.license # install or renew
Renewal needs no restart — the file is re-checked within a
minute. The new license is validated before it replaces the old one, so a
wrong or corrupt file is rejected and your running license is left untouched.
pies-llm license show warns when 30 days or fewer remain.
The license is checked continuously — signature, expiry, and status. When it expires or is removed, AI requests return HTTP 403 with the exact reason, while health and administration stay reachable so you can always see why.
The only step that needs the internet is the one-time weights download. Do it on any connected machine, carry the result across, and import it.
Get the weights (216 GB). This is a public Hugging Face repository — no
PIES account or token is involved. Either route must end with a folder named
exactly Llama-4-Maverick-17B-128E-Instruct-quantized.w4a16.
Option A — command line. Resumable, and strongly preferred at this size: an interrupted download continues where it left off, just run it again.
pip install huggingface_hub
huggingface-cli download RedHatAI/Llama-4-Maverick-17B-128E-Instruct-quantized.w4a16 \
--local-dir Llama-4-Maverick-17B-128E-Instruct-quantized.w4a16
Option B — manual browser download, if the machine has no
Python or your policy requires a human-reviewed download. Open the
repository
file list, create a folder named
Llama-4-Maverick-17B-128E-Instruct-quantized.w4a16, and save
every file into it:
| File(s) | Notes |
|---|---|
model-*.safetensors | ~50 shards — the bulk of the 216 GB |
model.safetensors.index.json | Lists the shards; the import check reads this |
config.json, generation_config.json | Model configuration |
tokenizer.json, tokenizer_config.json, special_tokens_map.json | Tokenizer |
Keep the structure flat — no sub-folders, no renaming. Browser downloads have no resume and no integrity check, which is why Option A is preferred.
Either way, copy the whole directory onto your approved
media — a missing shard is the usual air-gap failure, and
import-weights checks for exactly that on the other side before
it copies anything. Take the container image the same way:
docker pull ghcr.io/pies-io/pies-llm:vllm
docker save ghcr.io/pies-io/pies-llm:vllm | gzip > pies-llm-vllm.tar.gz
docker load < pies-llm-vllm.tar.gz
pies-llm import-weights /media/transfer/Llama-4-Maverick-17B-128E-Instruct-quantized.w4a16
pies-llm start # finds the weights on the volume — never touches the network
import-weights checks the directory is a complete snapshot
before copying 216 GB, and stores it on the
pies-llm-models volume under the exact name the service looks
for — so it works even if your media folder is named something else.
After this, nothing in the product requires egress — prompts, data, and license checks all stay on the server.
Out of the box the service speaks plain HTTP on port 8000 — appropriate on localhost, behind a TLS-terminating proxy (nginx, caddy, a cloud load balancer), or on an isolated network. If the API key crosses a network you don't fully trust, serve HTTPS directly by mounting a PEM certificate and key:
docker run ... \
-v /etc/pies-llm/certs:/certs:ro \
-e PIES_LLM_SSL_CERT=/certs/fullchain.pem \
-e PIES_LLM_SSL_KEY=/certs/privkey.pem \
ghcr.io/pies-io/pies-llm:vllm
Then use https://<server>:8000 in PIES Studio.
| Symptom | Cause & fix |
|---|---|
| Studio shows Offline right after install | The one-time weights download (216 GB) and the 10–20 minute engine load are still running — watch pies-llm logs -f. The service answers only once the engine is ready. |
| The port does not answer at all | Normal until the engine is ready. The boot log is captured even where container logs are unavailable — pies-llm debug includes it, or read it directly at /v1/admin/boot-log with your admin key. |
| A multi-GPU host loads onto one GPU | Set PIES_LLM_TP=<number of GPUs> in ~/.pies-llm/config and pies-llm restart. Auto-detection covers most hosts. |
| Every AI call returns 403 | License missing, expired, or inactive. pies-llm status shows the exact reason in the license block. Install a valid license (section 5). |
could not select device driver when starting |
NVIDIA Container Toolkit missing on the host — install it, then pies-llm start. |
| Model fails to load / out of memory | Total VRAM below 256 GB, or other processes holding GPU memory. Check nvidia-smi; free the GPUs and pies-llm restart. |
| Key rejected in Studio | Studio needs the admin key, not an inference key. Find it in ~/.pies-llm/config on the server. |
| Anything else | Run pies-llm debug and send the output to PIES support. |
Support: support@pies.io — include the output of
pies-llm debug and your organization name. Diagnostic output
contains no prompts or application data.