Self-hosting docs: a Models page with Drama 3, and a shorter overview

developer-guide/self-hosting/air-gapped.mdx

@@ -4,19 +4,17 @@
 icon: "shield-halved"
 ---
 
-Both offline modes make no outbound calls at runtime. Neither one, however,
-installs itself out of thin air: a Helm install pulls container images and the chart
-from a registry, and the appliance needs its image on the host. An air-gapped
-deployment is about getting those artifacts across the boundary. The license bundle
-has to cross it too, and unlike an image it expires — plan a recurring transfer, not
-a one-off. The reference voices you use have to cross too, copied in as archives:
-voice sync cannot reach Fish Audio from there.
+Both offline modes need no outbound access at runtime, but installing them still
+takes artifacts from Fish Audio: the images and, on Helm, the chart. An air-gapped
+deployment is about getting those across the boundary, together with the license
+bundle and the reference voices you use. The license expires, so plan a recurring
+transfer, not a one-off; voices are copied in as archives, since voice sync cannot
+reach Fish Audio from there.
 
 <Note>
   Fish Audio does this with you as part of an air-gapped delivery, and the step-by-step
-  procedure is in the deployment runbook for the version you install. See
-  [Releases](/developer-guide/self-hosting/enterprise-releases). This page is what to
-  expect and what to plan for.
+  procedure is in the deployment guide for the version you install. This page is
+  what to expect and what to plan for.
 </Note>
 
 ## Which one to choose
@@ -24,42 +22,28 @@
 **The air-gapped All-in-One appliance** is the straightforward answer to a strict air
 gap: one image, moved to the disconnected host as a file and loaded there. Beyond the
 image, the license bundle — and, in the external-weights modes, the weight
 fileset — has to be carried across. Its online counterpart cannot run air
-gapped: it authorises every request against Fish Audio.
+gapped: it authorizes every request against Fish Audio.
 
 **The Helm chart** is more work, because the release is many images rather than one.
 Every image has to be mirrored into a registry the cluster can reach and the release
 pointed at it, component by component. Plan for the whole
 set, and expect to do it with your account team rather than alone.
 
-**What you give up either way:** images are pinned to the exact content Fish Audio
-published, so a deployment cannot quietly run anything else. Copying an image into
-another registry drops that pin, so check what you mirrored while both sides are still
-there to compare.
-
 ## Offline usage accounting
 
-An offline deployment cannot call a billing service, so it records usage locally
-instead, in a signed ledger on persistent storage. It is durable data rather than
-cache: include it in your backups, and agree a reconciliation cadence with your account
-team. Usage is settled from the ledger files themselves, not from totals compiled off
-them.
-
-Because there is no service to validate a token against, any non-empty bearer token is
-accepted and recorded as the billing identity. Use a stable, distinct token per tenant.
+Offline billing records usage in a signed ledger on persistent storage. It is durable
+data, not cache: back it up, and agree with your account team how often to send it for
+reconciliation.
 
 ## Proving there is no egress
 
-Regulated deployments usually need evidence rather than a configuration review, and the
-runbook carries the exercise. Two things are worth knowing before you plan it.
-
-It answers two questions, and they need different methods: whether the deployment
-*needs* the internet, and whether it *calls out* when allowed to. The second is what a
-telemetry or data-residency review actually asks.
-
-It is also a cluster-level exercise rather than a namespace one. Confirm early that
-whoever runs your cluster can take part, because a namespace-scoped account cannot
-complete it.
+Regulated deployments usually need evidence rather than a configuration review, and
+your deployment guide carries the exercise. It shows both that the deployment works
+without the internet and that, with voice sync off, it makes no calls when the internet
+is available. On Helm
+it is a cluster-level exercise, so involve whoever runs your cluster early: a
+namespace-scoped account cannot complete it.
 
 ## Next steps
 

developer-guide/self-hosting/all-in-one.mdx

@@ -1,36 +1,31 @@
 ---
 title: "All-in-One container"
-description: "The single-container appliance: what it is, what it cannot do, and what running it involves"
+description: "Run a model's whole speech stack in one Docker container on a single machine"
 icon: "box"
 ---
 
-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 the model weights baked into the image, except in the external-weights modes. It runs as a turnkey single-node appliance, no Kubernetes.
+The All-in-One image packages the whole speech stack into one container and runs as a
+turnkey single-node appliance, no Kubernetes. The model weights are baked into the
+image, except in the external-weights modes, which mount them from your own
+storage at run time.
 
-The two billing modes, **Offline All-in-One** and **Online All-in-One**, differ only in how
-usage is accounted for. The offline mode records usage to a local
-ledger and needs no network once the image is on the host. The online mode authorises
-each request against Fish Audio and charges the key that made it, so it needs outbound
-access and a key with credit. The accounting is compiled in, so an image is one or the
-other; the container logs which at startup.
+Each image is built for one [billing mode](/developer-guide/self-hosting/introduction#billing),
+online or offline; the container logs which at startup.
 
 <Note>
   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
-  deployment guide download for the image version you run. See
-  [Releases](/developer-guide/self-hosting/enterprise-releases).
+  options, and troubleshooting are in the **All-in-One guide**, which you download from
+  **Developer → Self Host** with the image version you run.
 </Note>
 
 ## What it cannot do
 
-The appliance runs one inference worker and one vocoder — a GPU each; the
-Single-GPU special case shares one H100-class 80 GB card, with lower throughput.
-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. For elastic or higher-throughput
+The appliance runs one inference worker and one vocoder, on the cards its model
+takes — see [Models](/developer-guide/self-hosting/models). It does not
+autoscale or add workers on more GPUs or nodes, and it does not include timestamp
+alignment, so it returns no word or segment timings. For elastic or higher-throughput
 deployments, use the [Kubernetes chart](/developer-guide/self-hosting/kubernetes), which
 scales replicas across all GPUs and nodes.
 
 ## What running it involves
 
@@ -38,61 +33,40 @@
 [requirements](/developer-guide/self-hosting/requirements).
 It needs:
 
-- **Two GPUs** — one for the inference worker, one for the vocoder. The Single-GPU
-  mode is a special case: one H100-class 80 GB card shared by both, with lower
-  throughput.
+- **The GPUs its model takes** — usually two; a Single-GPU mode, where the model offers
+  one, shares one card at lower throughput.
 - **One exposed port** for the API.
-- **One persistent volume.** Compile caches, the vocoder's built engine, reference
-  voice archives, and — in the offline mode — the usage ledger all live there. Model
-  weights are in the image, not on the volume; the external-weights modes mount
-  them at run time instead — the delivered guide covers that mount.
-- **The license bundle.** A host directory holding the certificate and key pair from
-  **Developer → Self Host**, mounted read-only. Without it the API never comes up; once
-  the certificate expires the container starts but refuses requests. Renewing is
-  replacing those files in place; only a bundle that carries a new key needs the
-  container restarted.
+- **One persistent volume.** Caches, reference voice archives, and — in the offline
+  mode — the [usage ledger](/developer-guide/self-hosting/air-gapped#offline-usage-accounting)
+  all live there; the model weights do not.
+- **The license bundle** from **Developer → Self Host**, mounted read-only. See
+  [The license](/developer-guide/self-hosting/registry-access#the-license).
 
 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.
+**Plan for a slow first start.** The worker and the vocoder prepare for your GPU type
+before either serves, and the health endpoint verifies the speech backend end to end
+rather than reporting immediate liveness. Every start takes minutes; the first can take
+much longer.
 
-## Usage accounting and tenancy
+To upgrade, pull or load the new version's image and recreate the container against
+the same volume.
 
-The billing mode determines how usage is accounted for and what the bearer token has to be.
+## Tokens and tenancy
 
-**Offline.** Usage goes to a local, signed, append-only ledger on the volume. 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.
-
-Backups and reconciliation: [Offline usage accounting](/developer-guide/self-hosting/air-gapped#offline-usage-accounting).
-
-**Online.** Each request is authorised against Fish Audio and charged to the key that
-made it. The token must be a [Fish Audio API key](/developer-guide/getting-started/api-key)
-with credit — not the deploy token used to pull the image — and anything else is
-rejected. No ledger is written; usage appears in your Fish Audio account instead.
-
-Authorisation happens on every request, not only at startup, and the appliance has no
-local fallback. Treat outbound reachability as a production dependency.
+Offline, any non-empty bearer token is accepted and recorded as the billing identity:
+give each tenant a stable token of its own, and control access in front of the
+appliance. Online, each request must carry a
+[Fish Audio API key](/developer-guide/getting-started/api-key) with credit, not the
+deploy token. It is authorized against Fish Audio with no local fallback, so treat
+outbound reachability as a production dependency.
 
 ## 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 on the volume, one zip per
-voice, placed by you or by the optional voice sync.
+The worker admits a bounded number of requests at once; beyond that, requests queue and
+time-to-first-audio climbs. Your deployment guide gives the cap for your model; validate
+latency and error rate before changing it.
 
 ## Next steps