Self-hosting docs: the All-in-One scales out by adding containers, and has a timestamps build

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

@@ -20,12 +20,11 @@
 
 ## What it cannot do
 
 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.
+takes — see [Models](/developer-guide/self-hosting/models). A container does not scale
+itself: for more capacity, run more containers behind your own load balancer. To scale
+workers and vocoders separately, use the
+[Kubernetes chart](/developer-guide/self-hosting/kubernetes).
 
 ## What running it involves
 
@@ -33,7 +32,7 @@
 [requirements](/developer-guide/self-hosting/requirements).
 It needs:
 
 - **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.** Caches, reference voice archives, and — in the offline
@@ -45,9 +44,9 @@
 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 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.
 
 To upgrade, pull or load the new version's image and recreate the container against
@@ -60,7 +59,7 @@
 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
 

developer-guide/self-hosting/introduction.mdx

@@ -16,8 +16,8 @@
 
 | Reason                  | What it gives you                                                                                                                       |
 | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
 | Colocation              | Run inference in the same region, VPC, or rack as your application and remove public-internet round trips from time-to-first-audio.     |
 | Single-tenant isolation | Dedicated GPUs and queues. Capacity is not shared with other tenants, and you decide when the deployment is upgraded.                   |
 | Security posture        | Voice traffic never leaves your network. The offline modes need no outbound access at runtime and run on disconnected networks. |
 | Data sovereignty        | Input text, generated audio, and reference voices stay inside your boundary and under your own retention policy.                        |
 
@@ -26,17 +26,17 @@
 Each model ships on two platforms. Your agreement decides which ones your team gets,
 and in which modes; **Developer → Self Host** shows them.
 
-|            | Helm (Kubernetes)                                                 | All-in-One (Docker)                                              |
-| ---------- | ----------------------------------------------------------------- | ---------------------------------------------------------------- |
-| What it is | The model's chart, installed on your cluster                      | One container on a single machine                                |
-| Best for   | Production clusters and elastic capacity                          | Evaluation, fixed-size appliances, strict air gaps               |
-| Scaling    | Replicas across GPUs and nodes, with optional autoscaling         | None: one worker and one vocoder                                 |
-| Metrics    | Prometheus metrics from the speech services                       | API metrics only, at `/metrics`                                  |
-| Timestamps | Optional, where available                                         | Not included                                                     |
-| Guide      | [Kubernetes deployment](/developer-guide/self-hosting/kubernetes) | [All-in-One container](/developer-guide/self-hosting/all-in-one) |
+|            | Helm (Kubernetes)                                                 | All-in-One (Docker)                                                              |
+| ---------- | ----------------------------------------------------------------- | -------------------------------------------------------------------------------- |
+| What it is | The model's chart, installed on your cluster                      | One container on a single machine                                                |
+| Best for   | Production clusters and elastic capacity                          | Evaluation, fixed-size appliances, strict air gaps                               |
+| Scaling    | Replicas across GPUs and nodes, with optional autoscaling         | Add containers behind your own load balancer; each is one worker and one vocoder |
+| Metrics    | Prometheus metrics from the speech services                       | API metrics only, at `/metrics`                                                  |
+| Timestamps | Optional, where available                                         | A separate build, where available                                                |
+| Guide      | [Kubernetes deployment](/developer-guide/self-hosting/kubernetes) | [All-in-One container](/developer-guide/self-hosting/all-in-one)                 |
 
 The GPUs each model needs are on [Models](/developer-guide/self-hosting/models). On
 either platform, ingress, DNS, TLS, external load balancing, and network allowlists
 are yours to choose and configure.
 
 ## Billing

developer-guide/self-hosting/models.mdx

@@ -11,7 +11,7 @@
 
 ## At a glance
 
 | Model    | Request header    | GPU types                | GPUs per deployment                                               |
 | -------- | ----------------- | ------------------------ | ----------------------------------------------------------------- |
 | S2.1 Pro | `model: s2.1-pro` | H100, H200, or B300      | Two; one in the All-in-One's Single-GPU mode, at lower throughput |
 | Drama 3  | `model: drama-3`  | H200 or B300 recommended | At least two or three, depending on the GPU                       |
@@ -21,12 +21,9 @@
 - **The first start compiles for your GPU.** The result is cached on shared storage on
   Helm, and on the volume on the All-in-One, so later starts are quicker. Moving to a
   different GPU type compiles once more.
-- **Timestamps offline.** A Helm install without internet access copies the timestamp
-  model onto shared storage before turning timestamps on; the deployment runbook has the
-  step.
 
 ## Drama 3
 
 [Drama 3](/features/text-to-speech/drama-3) is a much larger model than S2.1 Pro and
 needs more resources, GPUs above all; your deployment guide has the sizing. For a GPU
 other than H200 or B300, check with Fish Audio before you plan around it.

developer-guide/self-hosting/requirements.mdx

@@ -14,7 +14,7 @@
 | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | Hosts         | Linux x86-64 on every machine, CPU-only Kubernetes nodes included.                                                                                                                                                              |
 | GPU type      | NVIDIA. The types, and the GPU count, depend on the model: see [Models](/developer-guide/self-hosting/models). Contact Fish Audio before standardizing on a GPU not listed there.                                                |
-| GPU count     | **Two** in most deployments: one for the inference worker, one for the vocoder.<br />**One more**: timestamp alignment, where available.<br />**More**: scales throughput on Kubernetes; size it with your account team. |
+| GPU count     | **Two** in most deployments: one for the inference worker, one for the vocoder.<br />**One more**: timestamp alignment, where available.<br />**More**: adds throughput as more replicas or containers; size it with your account team. |
 | MIG           | Disable MIG unless the configuration has been validated with Fish Audio.                                                                                                                                                        |
 | NVIDIA driver | Must support CUDA 13.x and your card's compute capability.                                                                                                                                                                      |
 
@@ -23,7 +23,7 @@
 | Traffic    | Requirement                                                                                                                                                                  |
 | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | Install    | Access to the Fish Audio registry to pull the images and, on Helm, the chart. For a site with no outbound access, see [Air-gapped deployments](/developer-guide/self-hosting/air-gapped). |
 | Billing    | With online billing, every request is authorized over HTTPS against the Fish Audio billing endpoint; ask your account team for the hostname to allowlist. Offline billing needs no outbound access. |
 | Voice sync | Optional. When turned on, the deployment downloads voices from Fish Audio over HTTPS.                                                                                       |
 | Inbound    | Your own ingress, load balancer, or private endpoint, with DNS and TLS in place before production traffic.                                                                  |
 
@@ -34,12 +34,12 @@
 | Requirement     | Detail                                                                                                                                                       |
 | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | Control plane   | 3 CPU-only nodes, roughly 4 vCPU and 16 GB RAM each, for the control plane or, on managed Kubernetes, the system node group.                                 |
 | CPU workloads   | Roughly 28 vCPU and 125 GiB of memory requests for the non-GPU services, beyond the control plane. Provide a CPU node group, or leave GPU nodes schedulable for them.                  |
 | Shared storage  | At least 1 TB of EFS, NFS, or equivalent, mounted at the same path on every node (`/mnt/shared` by default). The chart mounts it with hostPath and creates no PersistentVolumeClaims. |
 | Node-local disk | Redis keeps its data on node-local ephemeral storage. Leave room for it on the nodes that host it, plus headroom for rewrites.                                 |
 | Kubernetes      | A currently supported minor version and a maintained Helm release.                                                                                          |
 | GPU runtime     | NVIDIA GPU Operator, or the provider's driver and device plugin, with GPU nodes exposing `nvidia.com/gpu`.                                                  |
 | Pod Security    | The namespace must permit `hostPath` volumes for every service on shared storage, and `hostPID` and `hostIPC` for the inference workers.                     |
 
 <Warning>
   The shared mount is created with `DirectoryOrCreate`. A node that is missing it