Skip to main content
The All-in-One image packages the whole speech stack — edge API, model API layer, inference router and worker, vocoder, text normalizer, and Redis — into one container, with every model weight baked in. Once the image is on the host it runs with no Kubernetes and no internet access, which makes it the turnkey option for single-node appliances and strict air gaps.
This page covers what the appliance is and what to plan for. The commands, tuning options, and troubleshooting are in the All-in-One guide, which ships in the documentation bundle for the image version you run — see Releases.

​
What it cannot do

The appliance runs one inference worker and one vocoder, a GPU each. It does not autoscale, does not shard across more GPUs or nodes, and does not ship the forced aligner, so it returns no word or segment timings. It is offline-only — there is no hosted-billing variant. For elastic or higher-throughput deployments, use the Kubernetes chart, which scales replicas across all GPUs and nodes.

​
What running it involves

One docker run on a host that meets the All-in-One host requirements. It needs:
  • Two GPUs. The first runs the inference worker, the second the vocoder.
  • One exposed port for the API.
  • One persistent volume. Compile caches, the vocoder’s built engine, reference voice archives, and the usage ledger all live there. Model weights are in the image, not on the volume.
Everything inside the container runs as a non-root user, so a reused volume or a host bind mount has to be writable by it. Plan for a slow first start. The worker compiles its inference graphs and the vocoder builds its engine before either serves, and the health endpoint verifies the speech backend end to end rather than reporting immediate liveness. Both artifacts are cached on the volume, so later starts take minutes. The vocoder engine is specific to the GPU model, so moving to different cards rebuilds it once.

​
Usage accounting and tenancy

This build records usage to a local, signed, append-only ledger on the volume instead of calling a billing service. Two consequences worth designing around:
  • Any non-empty bearer token is accepted; a missing or empty one is rejected. The appliance has nothing to validate a token against.
  • The token is recorded verbatim as the billing identity. Use a stable, distinct token per tenant — two tenants sharing a token are indistinguishable in the ledger.
See Offline usage accounting.

​
Capacity

The single worker admits a bounded number of in-flight requests; beyond that, requests queue and time-to-first-audio climbs. The ceiling is set by the worker’s key-value cache VRAM, so larger cards support a higher cap. It is adjustable at launch without rebuilding the image. Validate latency and error rate at any new value before committing to it. Reference-id requests resolve only from local archives placed on the volume, one zip per voice.

​
Next steps