Audio8 TTS 0.6B: the compact multilingual speech model as an API
Audio8 TTS is a 0.6B-parameter multilingual text to speech model with zero-shot voice cloning, released under Apache 2.0 by the project behind audio8.ai. It drew attention for one reason. Speech quality holds up against models many times its size. The package is small enough to run on a laptop CPU. On this platform it sits behind an OpenAI-compatible speech endpoint. Calls are metered per character from a prepaid wallet, served from the project's own ONNX INT4 CPU build.
This page covers what the model is, what it is good at, and exactly how to call it here. It also shows what our own measurements on the hosted lane found. The same weights also run free on your own hardware. So the local-versus-hosted comparison gets its own section, with numbers on both sides.
Last verified: 2026-09-25
What it is
The model's full name is Audio8 TTS Preview 0.6B, and the "Preview" carries weight. The official model card limits the recommended set to eleven languages (Cantonese, Chinese, Dutch, English, French, German, Italian, Japanese, Korean, Polish, Spanish). It treats broader coverage and Chinese dialects as future work. Within that set, the claim to care about is size-adjusted quality. At 601,159,424 parameters excluding its bundled codec, it posts the best English WER of every system in the card's evaluation. The systems it beats run up to fourteen times its size. The architecture is two small transformers in sequence, a design the project calls DualAR. A slow one predicts a semantic token for each audio frame. A fast one predicts the frame's codec codebooks. A bundled neural codec running at 44.1 kHz turns the result into waveform. No separate vocoder step is needed.
Four facts from the official card and repository matter to an API buyer:
- Open weights, permissive license. Apache 2.0 on code and weights, including the ONNX export. Nobody can take this model away from you.
- Zero-shot cloning is built in. A reference recording plus its exact transcript is all the model needs to speak in a new voice. The hosted surface here starts narrower; the FAQ covers the split honestly.
- A CPU build exists and is first-class. The ONNX INT4 export runs the whole model on ONNX Runtime's CPU provider in about 1 GiB. This platform's lane serves that build, which is why the model can run on modest edge hardware instead of a GPU farm.
- Short inputs are the design center. The project's inference guidance asks for inputs within 150 characters for best quality, and longer text may degrade generation. Our request cap (below) is sized around the same reality.
One naming note, so nothing surprises you. The project has lived under more than one organization name (Audio8, Edge0). Older links still resolve to the current official repository. The model card on Hugging Face is the canonical document. The company's own cloud, audio8.ai, was still a placeholder page on our last check. A first-party hosted API from them is announced-but-absent, not something to plan around.
On this platform, the model answers the audio8-tts alias on the speech route. The route follows the OpenAI /v1/audio/speech shape, meters by input characters, and serves wav at 44.1 kHz. The model answers calls today, measured 2026-09-09, metered per character from a prepaid wallet. The models index shows the catalog as it stands.
Use cases
The model is small and multilingual. The lane is single-flight, and each request carries up to 250 characters. That profile points at short-form, quality-sensitive, multi-language speech rather than bulk narration in one call.
- Multilingual product speech. The model's recommended set spans eleven languages, including Cantonese, Korean, Polish, and Dutch, coverage most small TTS models skip. The hosted lane serves the model as shipped, so run the per-language check described in Benchmarks before shipping any language at volume.
- Localization prototypes. Hearing a product's copy in five languages before committing to voice work is exactly a sentence-at-a-time job. The per-character wallet means the experiment costs what the characters cost, and nothing recurring.
- Voice-feature prototyping without a GPU. The local route needs Python 3.11 or newer, a git clone, and about 1 GiB for the ONNX build. The API route needs one HTTP call. For deciding whether voice belongs in your product at all, that difference is the whole argument.
- Agents and assistants that speak. Short spoken confirmations and summaries fit the cap naturally. The wallet makes the cost of a chatty agent bounded and visible, and key revocation makes stopping one immediate.
- Narration in chunks. Longer scripts split at sentence boundaries into cap-sized requests and concatenate at playback. The chunking arithmetic is in the API section.
- Paired with a throughput model. When a project outgrows this lane, the same wallet and metering carry Kokoro on a lane measured at 7.0M characters per day against this lane's 0.37M, with fixed voice packs instead of cloning.
Run it locally or call the API
Google's own results for this model frame the choice as local versus cloud. The frame is fair. This is one of the few current TTS models where both roads are genuinely open. Here is the decision rule, argued both ways:
Run it yourself when the local-only capabilities are the point. Per-request cloning from your own reference audio is local-only today. The registration pipeline takes recordings of half a second to 30 seconds with their exact transcripts. Offline or on-device operation and per-language voice registration all point the same way. So does volume high enough that per-character billing would dominate your costs. The ONNX Runtime guide documents the whole local path. That path includes a service on port 8024 that itself speaks the OpenAI route shape. Streaming PCM and voice registration come with it.
Call the API when you want the boring parts handled. The OpenAI-compatible shape means existing client libraries work as-is. The wallet bounds spend by construction. A request arriving after the balance hits zero is turned away with a named error. Refused work bills nothing. Someone else owns the update cadence and the runtime quirks. And there are quirks worth owning. The project's own troubleshooting notes that transformers 5.x can silently emit all-zero codes for this model. That is a bad afternoon to debug in production. The local build is also, by its own documentation, a serialized low-concurrency design. Multiplying it into throughput is your problem on the local road. On the hosted road it is ours.
Both roads can coexist in one product. Prototype and localize over the API. Keep the ONNX build for offline and cloning work, and let the same model serve both.
Audio8 vs Kokoro: which one
The head-to-head query for these two is contested space. On our September 2026 read, one third-party benchmark owns the comparison slot. No host page answers it. The measured answer follows, from this platform's own fence work on both lanes.
Position first. Audio8 is the reach pick: 0.6B parameters, a zero-shot cloning architecture, and eleven card-recommended languages. Cantonese, Korean, and Polish sit inside that set. Per-request cloning works on the local path, and the hosted surface offers one registered default voice. A bundled 44.1 kHz codec rounds it out. Kokoro is the depth pick: 82M parameters, fixed voice packs, and all 28 official English voices on its hosted catalog. Its 24 kHz output is built for English volume.
Then the numbers, both sides from the task-17 window of 2026-09-09. This lane's clean curve is about 1.4 s plus 0.131 s per character, single-flight. Its cap is 250 characters and its ceiling 0.37M chars/day. Kokoro's lane measured roughly 0.8 s plus 0.0149 s per character, batching to concurrency 8. It has a 3,500-character cap and a 7.0M chars/day ceiling. Per character synthesized, Kokoro's lane spends roughly a ninth of the time. That is the volume engine doing its job.
Third-party reads point where the design does. A CPU benchmark published on a developer blog on 14 August 2026 named Audio8 the intelligibility and CPU-latency winner among the voice-cloning models it compared. One blog's run is a pointer, not a verdict. The class placement is the part that holds. Kokoro sits that class out by design.
The working rule: prototype, localize, and clone with Audio8; run English volume through Kokoro's page. Both routes sit behind one wallet, and both answer calls today.
API usage
The route is POST /v1/audio/speech with a Bearer key from the console. The body takes three required fields: model (audio8-tts), input (the text), and voice (default, the one registered voice on this model). Optional fields response_format and speed are accepted. There is no stream parameter. Audio arrives by chunked transfer, and the route emits wav.
Four route rules that save debugging time:
- 250 characters per request. The gateway refuses longer input with a 400 before anything synthesizes, and refused requests are not billed. The project's quality guidance (~150 characters per input) is stricter than the cap, so sentence-boundary splitting serves both.
- First audio is not instant. The lane buffers the whole synthesis before the first byte. Our clean measured curve is about 1.4 s plus 0.131 s per character, so a full-cap request is roughly 34 seconds to first audio. The conservative cross-day envelope we size the cap against says 56. Set client read timeouts to 120 seconds or more, and use
curl --no-bufferfor live consumption. If a generation dies mid-stream, the bytes already delivered stand and the turn is not billed. - Retries re-bill. The Idempotency-Key header is accepted on this route but carries no replay semantics: audio does not fit the replay budget, so a retried request executes and bills again. Check your client's retry defaults before pointing a production loop here.
- The voice catalog is a free read.
GET /v1/audio/voices?model=audio8-ttsreturns the valid voice ids for this model (default). It needs auth and meters nothing.
A 700-character script becomes three requests split at sentence boundaries. The wav files concatenate in order, and the wallet sees exactly the characters sent.
curl
curl -X POST "https://api.ironstratum.com/v1/audio/speech" \
-H "Authorization: Bearer $KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "audio8-tts",
"input": "Audio8 fits a cloning-capable voice in 0.6B parameters, and this endpoint meters it by the character.",
"voice": "default"
}' \
--no-buffer \
--output speech.wav
python
import os
import requests
resp = requests.post(
"https://api.ironstratum.com/v1/audio/speech",
headers={"Authorization": "Bearer " + os.environ["KEY"]},
json={
"model": "audio8-tts",
"input": "Audio8 fits a cloning-capable voice in 0.6B parameters.",
"voice": "default",
},
timeout=120, # first byte can take ~34-56 s at the cap
)
resp.raise_for_status()
with open("speech.wav", "wb") as f:
for chunk in resp.iter_content(chunk_size=65536):
f.write(chunk)
openai-sdk
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.ironstratum.com/v1",
api_key=os.environ["KEY"],
)
with client.audio.speech.with_streaming_response.create(
model="audio8-tts",
voice="default",
input="Audio8 fits a cloning-capable voice in 0.6B parameters.",
) as response:
response.stream_to_file("speech.wav")
An existing OpenAI SDK integration therefore changes in exactly two places. Point the base URL here and swap the model id.
Benchmarks
Two dated evidence layers follow. The first is what we measured on the hosted lane. The second is what the project publishes about the model itself.
Our hosted lane. Measured 2026-09-09 on this platform's lane during the task-17 verification window. The records are the platform launch catalog, section D, and the E5b grid and F-3 measurement curves it cites. The same numbers live in the measurement comments beside the model's row. The lane runs the official ONNX INT4 CPU build.
| Metric | Value | Basis |
|---|---|---|
| Throughput ceiling | 0.37M chars/day | E5b solo grid, single-flight |
| Synthesis time | ~1.4 s + 0.131 s per char | F-3 clean measurement curve |
| Conservative envelope | ~0.22 s per char | cross-day basis, 205 chars ~46 s |
| Full-cap request (250 chars) | ~34 s measured shape, ~56 s envelope | derived from both slopes |
| Real-time factor | 0.315 at the true 44.1 kHz rate | E5b corrected grid |
| Cold start | ~4 s | per-process startup check |
Treat the ceiling as a planning bound for sustained load. The lane synthesizes one request at a time. That is the CPU runtime's own design for bounding memory. Send requests sequentially. Plan daily volume against the ceiling, not against parallelism that is not there. For contrast, look at what the checkpoint does with datacenter hardware. The project's SGLang Omni adapter reports a warm p50 of 0.691 s and an RTF of 0.116 on one H20 GPU. Our lane trades that speed class for edge economics and one metering plan.
The model itself. From the official model card, Seed-TTS evaluation. Lower WER/CER is better, higher SIM is better, similarity shown as percentages.
| Model | Params | EN WER / SIM | ZH CER / SIM | Hard ZH CER / SIM |
|---|---|---|---|---|
| Audio8 TTS Preview | 0.6B | 1.506 / 63.2 | 0.950 / 73.1 | 11.510 / 68.7 |
| Fish S2 Pro | 4.6B | 1.607 / 64.6 | 1.038 / 73.8 | 10.149 / 70.1 |
| Higgs Audio v2 | 4.7B | 1.524 / 66.4 | 0.806 / 72.1 | 10.622 / 69.3 |
| CosyVoice3-1.5B | 1.5B | 2.22 / 72.0 | 1.12 / 78.1 | 5.83 / 75.8 |
| MOSS-TTS | 8.5B | 1.85 / 73.4 | 1.20 / 78.8 | - |
| VoxCPM2 | 2.3B | 1.84 / 75.3 | 0.97 / 79.5 | 8.13 / 75.3 |
The line that matters: the smallest model in the table posts the best English WER (1.506). It also posts the second-best Chinese CER (0.950). The larger systems win on speaker similarity and hard Chinese. There Audio8's 11.510 is the weakest row it owns. On the CV3 multilingual grid the pattern repeats. It posts the lowest zh (3.205) and en (3.128) error rates among the compared systems. The card itself adds the right caveat. Different normalizers and evaluators make these reference comparisons, not a strictly matched ranking. Evaluation coverage does not expand the eleven-language claim.
One honesty note specific to our lane: INT4 quantization can change sampled token sequences relative to the source checkpoint. The ONNX model card asks that quality be evaluated for each language, voice, and deployment rather than assumed bit-for-bit. We serve the INT4 build, and the hosted surface exposes exactly one registered voice. The practical version of that advice is simple. Synthesize short samples in each language you care about before committing a volume pipeline to them. The numbers above describe the model family. Your own ears are the acceptance test.
Getting started
- Create an account through the console's invite flow. The beta console is invite-only; it is where the wallet, keys, and spend history live.
- Create an API key. A key can be revoked the moment its project changes, and requests on a revoked key fail immediately.
- Fund for the work, not the month. Metering is per input character from a prepaid wallet: when the balance reaches zero, a new call is refused with a named error, which is the whole point. The pricing page publishes the per-character rate.
- Make the first call. Copy the curl tab, substitute your key, and synthesize one sentence. If it plays, every longer case is chunking, and the numbers above tell you what to expect while it renders.
From here, the speech catalog holds the other TTS models on the same metering. The models index maps the whole catalog.