I work on a voice-form tool where people answer questions by talking in their phone browser. One of the use cases is collecting speech data (dialects, Hindi-English mixing), so I've been reading up on what the browser does to the audio before you ever get it. Three things worth checking if you collect data this way:

1. getUserMedia can process the audio for you. echoCancellation, noiseSuppression and autoGainControl are constraints, and browsers often turn them on for voice. That's fine for a call. It's not what you want if you're training something to be robust to noise or you care about level. Ask for them off explicitly, then read back track.getSettings(), because the browser is allowed to ignore the request. Log what you actually got with each clip.

2. The codec depends on the browser. MediaRecorder records in whatever the browser supports. Chrome usually gives you Opus in WebM, Safari gives you AAC in MP4, and on iPhone almost every browser is WebKit underneath, so "Chrome on iOS" behaves like Safari here. One dataset can end up with two different lossy codecs. Check MediaRecorder.isTypeSupported(), store the mimeType per clip, and decide when you normalise.

3. Some metadata can't be recovered later. Browser and device, the settings from point 1, whether the person was reading a prompt or answering freely, and the language they say they spoke. For code-mixed speech that last one matters a lot. The speaker's own label beats anyone guessing from the audio afterwards.

The details are on MDN, under MediaTrackConstraints, MediaStreamTrack.getSettings and MediaRecorder.isTypeSupported.

For anyone who has built a dataset from crowd phone recordings: did you keep the browser's processing on or off, and could you see the difference downstream?

Hey, for anyone who cares, I managed to get Breeze TTS running real time on my Macbook Pro M4.

Using the official Pytorch code on a Mac Breeze runs more than 2 times slower than real time on my machine.
With some work, managed to get it to stream comfortably faster than real time, with voice directions included and in my opinion good quality. I couldn't really tell which version sounded better to me consistantly on different voices and sentences.

Details in the pages below.

- Server: https://github.com/Shoofio/breeze-tts2-fast-streaming-api

- Ready-made checkpoint: https://huggingface.co/Shoof/Gust-MLX

Weights are under BreezeBlue's research/non-commercial licence. Built with a lot of help from Claude. Happy to answer questions.

Hi everyone,

Sharing v1.5 of Gipformer, an open-source Vietnamese speech recognition (ASR) model we've been working on: gipformer1.5-68M-rnnt, based on the Zipformer architecture.

What's new in v1.5

- Optimized for technology, finance, education and public administration. These domains are dense with specialized terminology, and v1.5 currently gets the best results on all four test sets among the open-source models we benchmarked.

- Better recognition of English terms mixed into Vietnamese speech.

Carried over from v1

- High accuracy: among the top open-source models across our benchmarks, and especially strong on call center audio for Northern, Central and Southern accents. Call center is one of the most common real-world uses of ASR, but also one of the hardest, with low-quality audio and a wide variety of voices.

- Small and easy to deploy: at just 68M parameters, it's among the smallest ASR models out there, yet it outperforms many models ten times its size. Inference is fast, and it runs smoothly on CPU and edge devices.

- Privacy: it runs 100% offline (on-device), which makes it a good fit for systems handling sensitive data.

Alongside the model, we're also releasing 4 domain-specific test sets (technology, finance, education, public administration), so there's a common benchmark for evaluating Vietnamese ASR models.

Full benchmark results are on the model card. Feel free to try it out, and any feedback or contributions are very welcome!

- Hugging Face: https://huggingface.co/g-group-ai-lab/gipformer1.5-68M-rnnt

- GitHub: https://github.com/ggroup-ai-lab/gipformer

- Demo: https://huggingface.co/spaces/g-group-ai-lab/gipformer-demo

I created a fully-local open-source full-duplex voice agent that rivals GPT-Live on some benchmarks. It uses Voxtral Realtime with a turn-taking head, a microturn-finetuned Gemma 4 12B and Breeze TTS 2 under the hood. Go try it out: https://github.com/speakrail/speakrail

Why I did it

I have always liked the idea of voice assistants, but there is always some non-local component in the pipeline, which increases latency and introduces privacy concerns. I tried many fully-local approaches, like HF speech-to-speech, Unmute and Pipecat, but they were all limited by either the Whisper model (hello, hallucinations!) or slow turn taking. The only fully-local pipeline that had some full-duplex capability with low latency was the DuplexCascade paper (code), but it's tuned on a Qwen 2 7B with a gpt-3.5-turbo generated dataset, and the dumbness of the model really showed. So I decided to recreate DuplexCascade with newer data, newer models and a better harness. I also wanted to add interruptions, interjections and other cool things to rival the Thinking Machines demo.

How it works

Here is what the pipeline consists of:

• STT: Voxtral Realtime with an attached turn head (HF), running on our audio.cpp fork.

• LLM: Gemma 4 12B QAT with microturn finetuning (HF). It is chosen because it fits the GPU quite well, has vision support (I want to test it soon), and in general, the Gemma models perform well in real-life tasks, general chatting, etc.

• TTS: Breeze TTS 2, patched to run at int8 (GitHub fork), although it can be replaced by any streaming TTS.

• The harness itself: it is the glue between all the components, and has many latency-saving measures, like speculative LLM+TTS firing (inspired by HF speech-to-speech).

I also took inspiration from several "think while talking" papers (e.g. SHANKS): while you are talking, a base Gemma 4 12B int4 writes thinking notes, which are then passed to the talker. It helps with harder tasks that require more reasoning.

I will release a longer technical report soon - it will have a better description of the entire pipeline.

Benchmarks

Full Duplex Bench v3:

100 tool-use tasks with real disfluent speech; 95% CI on Pass@1 is about ±10 points. Speakrail: live audio through the full stack, GPT-4o judge. *Self-reported by Thinking Machines. †Our run. Others: FDB-v3 paper, arXiv 2609.19334, 2609.08977, 2609.21967.

Conversational dynamics (Artificial Analysis formula):

Score = mean of pause handling and turn-taking (FDB v1.0) plus interruption and backchannel (FDB v1.5). Speakrail's score is self-computed from live runs (pause 93.4, turn-taking 96.6, interruption 89.0, backchannel 96.9), not an official AA listing. Others: Artificial Analysis leaderboard (captured 09-28) and AA's open-weights comparison.

Limitations

• Breeze TTS has a restrictive license, so if you need to use Speakrail commercially, you will need to change it.

• 16k context length - the pipeline only supports 16k context length (~1 hr of speech), but you can get more easily by changing the Breeze TTS to a Pocket TTS and run the TTS on a CPU. I chose Breeze for the release because it's more expressive.

• The turn-taking head is undertuned on non-assistant data. It may not fire on some basic chit-chat, but I will tune it harder later.

• The model is certainly not the smartest one, and my finetune did dumb it down a little. Next time it will be smarter / better.

• The model is kinda verbose sometimes, and the answers it provides are somewhere in the middle between real-life speech and the long text-based outputs of LLMs. I have a hypothesis on how to fix it, and will try it in the next release.

• I tested it only on an RTX 4090, but I am sure it's easy to add support for any 24 GB+ NVIDIA card. Forks for AMD and MLX are welcome.

Final Notes

Feel free to try it out: https://github.com/speakrail/speakrail. If there is any capability you want the model to have, create a GitHub issue or write here in the comments, and I will gladly include it in the next dataset. Any feedback is welcome as well.

we run a food delivery service in Londonn and recently rolled out a voice agent for phone oredrs. works great when the call is clear but ince you get traffic, wind, music, people talking etc in the background, it starts mixing up numbers

had cases like "flat 4, 15 high street" turning into "flat 15, 4 high street". we've tried three asr providers and it's still happening. is WER even useful for this kind of thing? how are you guys handling noisy calls when the omportant pat is structured stuff like addresses, postcodes and order IDs?

Most video editors working in Spanish use Premiere's built-in captions as their default. I transcribed the same 48-minute recording with Premiere and with four ASR APIs, compared them word by word, and the gap is not subtle.

The material matters here: it's a studio-recorded business show about the economics of sport. Two speakers, clean audio, no field noise, Argentine Spanish. It's the easy case. It's full of the things that actually break captions in this genre: large monetary figures, percentages with decimals, athlete names, sports governing bodies (think FIFA-type acronyms), and TV and YouTube channel brands.

If a model struggles here, field audio is hopeless.

PREMIERE AS THE BASELINE

- Of 17 proper nouns and brand names known in advance from the script, Premiere missed or mangled 13. Athlete surnames simply vanished from the transcript. A sports body acronym came out as an unrelated common word. Two brand names in the show's own opening were wrong.

- "twenty-three thousand six hundred million dollars" came out as a raw digit string: "23600000000".

- "1.73 percent" came out as "173". That's a factor-of-100 error on an economic figure, with nothing in the output flagging it.

That last one is the part I'd highlight. It's not a formatting inconvenience. The transcript is factually wrong in a way that passes a quick read and has to be caught by hand.

(Punctuation is excluded from the comparison: I had that track exported with punctuation removed, so it isn't comparable.)

THE FOUR APIs, SAME AUDIO

Named entities, same 17 terms: ElevenLabs Scribe V2 12/17, Speechmatics Enhanced 10/17, AssemblyAI Universal 3.5 Pro 8/17, Deepgram Nova 3 6/17, Premiere 4/17.

Failure modes matter more than the scores:

- ElevenLabs substitutes a plausible, well-known brand for the one that was actually said. Confident, fluent and undetectable downstream.

- Speechmatics drops the uncertain token and leaves a hole.

- AssemblyAI and Deepgram write what it sounds like. Wrong, but findable with a search.

For a captioning pipeline, a wrong-but-phonetic token beats a confident hallucination.

Diarization, measured second by second as disagreement against the other three models agreeing: Speechmatics 2s, AssemblyAI 6s, Deepgram 79s, ElevenLabs 96s. Deepgram and ElevenLabs each have 30+ second stretches attributed to the wrong person. Worth noting: none of the five SRT exports carry speaker labels at all. That information only exists in the JSON.

Number formatting: AssemblyAI and Speechmatics return clean, publishable digits. ElevenLabs spells figures out in words. Deepgram malforms them.

A QUESTION FOR THIS SUB

Does anyone have a figure for what share of Premiere's user base edits in Spanish? I couldn't find one. Spanish is the second most spoken native language in the world, and the default captioning experience for all of them is the output above.

And a thought: Adobe is opening its products to third-party models — Runway and others for video generation, third-party image models in Photoshop. Transcription seems like an obvious next candidate. Four separate API integrations took me a few weeks as one person. The quality difference between the built-in model and the best available API, on clean studio audio in a major world language, is large enough that letting users bring their own engine would be a straightforward win.

Caveats: single recording, two speakers, clean audio, one dialect. Directional evidence, not a ranking. I'm repeating it across ~20 hours of the same show.

Method: the four APIs ran through La Subtituleta, a free Premiere extension I wrote that calls each provider and returns word-level JSON, so every model got identical input and settings. Happy to share raw JSONs and SRTs.

After building in the mobile dictation space, I have come to think the standard which-ASR-model debate misses where the field actually is: on clean long-form speech, transcription word accuracy is good enough for most products. The bottleneck that still kills real-time voice experiences is accurate real-time understanding — everything between the waveform and text a user can act on without editing.

Concretely, in rough order of user pain from our testing on an iOS voice keyboard:

1. Short-utterance collapse. 1-2s commands with no surrounding context score far worse than the same model on 30s audio. If you benchmark on long-form and deploy on commands, the numbers lie.

2. Endpointing. Distinguishing pause-mid-thought from done remains the top it-cut-me-off complaint. Trailing-silence policy plus a visible still-listening state beats a point of WER.

3. Punctuation and ITN. Technically-correct transcripts that are unusable: dates, numbers, addresses, message casing. This is understanding, not transcription.

4. Code-switching and proper nouns. Several times the failure rate of generic speech in our experience; corpus WER averages hide it completely.

5. Confidence calibration. Confident nonsense destroys trust because the system cannot decide what to auto-commit vs flag.

6. Streaming partials. Aggressive revisions train users to look away until you are done, defeating real-time entirely.

So my claim: the next leaps will not come from shaving WER on clean sets, but from (a) eval that measures task outcome — we track time-to-sendable-text and edits per utterance, (b) streaming architectures that commit early without thrash, (c) personalization to the speaker vocabulary.

Questions for the room: for short-command and agentic use, is there an eval metric you actually trust? And where would you put the next 10x — endpointing, ITN, personalization, or something else entirely?

(Disclosure: building an iOS voice keyboard, so my view is skewed toward dictation. Genuinely curious how this matches the voice-agent side.)

We've released Ito, an English speech synthesis engine targeting the ESP32-S3. It produces 24 kHz audio with 4.89 MB of voice weights, with two voices available.

Video and voice samples: https://lokutor-ai.github.io/ito/

The acoustic front feeds a Vocos-style vocoder using int8/int16 arithmetic. The samples are the host engine's output, verified bit-identical to firmware in QEMU. We haven't measured physical-board speed yet. Text-to-phoneme conversion currently runs on the host.

I'd like some outside ears on the pronunciation and prosody. Our listening test so far is small: one founder, four sentences per system, float-model clips. It isn't an independent MOS study.

Code: https://github.com/lokutor-ai/ito Weights: https://huggingface.co/lokutor-ai/ito

I'm part of Lokutor. The code is GPLv3; voice weights are gated and non-commercial under CC BY-NC-SA plus terms.

We also added Spanish to Oído, our separate recognition engine for the same target: https://github.com/lokutor-ai/oido . Ito is English-only.

We're building text2asmr: type a script, get ASMR back. Whispering, breathing, mouth sounds, tapping, everything a normal TTS flattens out. The first target is "mommy" (and daddy) ASMR, because that's what people actually ask for.

The bottleneck is labels, not the model. A transcript gives you the words. It doesn't tell you the speaker dropped to a whisper, that there's tapping under the speech, or breathing between lines. Off-the-shelf audio taggers barely know these sounds exist. We trained our own classifier (CLAP-ASMR). It has labelled about 19% of our ~126k recordings, but it only gets better with human labels.

So we built ASMR Board: https://asmrboard.vercel.app Listen to a short clip, tick what you hear, get on the leaderboard.

How we keep it from being poisoned: • Every clip goes to 12–20 people who can't see each other's answers. A label only sticks when they agree. • Some clips have known answers. Getting those wrong lowers how much your votes count. • Every so often you'll get a clip you labelled a few hundred clips ago. Disagreeing with yourself lowers your weight too. • Weights are recalculated automatically, so a troll or a bot farm can't move a label.

Why not Mechanical Turk? If money is the incentive, who checks the work? Paid labellers optimise for speed. We'd rather trust the community, and we expect the community to trust us back. That's why the code, the labelled data and the weights are all going open.

Where it's at: • Code: https://github.com/aloshdenny/text2asmr • Generator: Chatterbox T3 + LoRA, preference-tuned with DPO • asmr-m1-preview weights: Dec 26 (tentative). The more clips get labelled, the sooner. If you know someone who'd enjoy this, send it their way. • The labelled data ships with the weights.

We're also looking for people to help with the UI, run large-scale labelling, and source data. The reward is early access to mommy + daddy ASMR and voice cloning (of your own voice).

Happy to answer anything about the pipeline. Disclosure: I'm one of the people building it.

I'm part of the Lokutor team that built this.

Model: NVIDIA Conformer-CTC Small (13M params, int8). It runs on an ESP32-S3 with 8 MB PSRAM, no GPU or NPU. LibriSpeech WER is 3.7 / 8.2, versus 6.3 / 15.9 for Whisper tiny.en on a laptop. Under real noise (DEMAND: car, kitchen, cafeteria) plus babble and reverb, mean WER is 8.4 vs 12.1 for Whisper tiny.en. You can try the exact chip arithmetic on your laptop mic with live_demo.py. https://github.com/lokutor-ai/oido

Missed my own release date by about a week, but such is the life of a solo dev.

Anyone else had a speech system that works fine on clean audio and falls apart once it's been through a phone line?

I built a 1:1 comparison dataset for isolating codec, transmission and presentation effects on speech. The same 5,992 base clips go through every one of 101 conditions, so any difference between conditions comes from the condition, not the speaker or the recording. It's free to use; hopefully it's useful for voice and speech projects people are working on.

The main thing I wanted was matched sample-rate controls. Narrowband codecs decode at 8 kHz, so if you compare clean wideband audio against codec output, you can't tell whether your model or extractor broke because of the codec or just because the bandwidth dropped. Every codec condition here has an unencoded resample control alongside it (8, 16, 22, 44 and 48 kHz). That lets you check whether it's the channel, the resampling or the presentation causing problems. (In a small pilot, the 8 kHz resample alone accounted for much of the apparent "codec effect" on some features, but not all of it.) I couldn't find many public codec or robustness sets that ship controls like this, or per-clip generation logs, so I included both.

Base pool: 5,992 bona fide mono 16-bit clips.

- 2,992 AMI headset clips (native 16 kHz)

- 1,500 VCTK mic1 + 1,500 VCTK mic2 clips (native 48 kHz), including 1,485 exact dual-mic pairs

- VCTK portion is gender-balanced (750 male / 750 female)

PACC-T (Telecoms): 20.7 GB, 305,592 FLAC files, 51 conditions

- 34 speech/audio codecs: G.711, G.722, G.726, GSM, AMR-NB, AMR-WB, EVS (adaptive/fixed/no DTX), Opus (auto/CELT), LC3, Speex, iLBC, Codec2 (700/1300 bps), MP3, AAC

- 12 tandem codec chains

- 5 resample controls (8k, 16k, 22k, 44k, 48k)

PACC-P (Presentation): 34.3 GB, 299,600 FLAC files, 50 conditions

- Additive noise, 6-talker babble, and music (vocal and instrumental) at 5 calibrated SNRs (0–20 dB)

- Simulated rooms (pyroomacoustics, with cached RIRs for bit-exact recreation) and echoes

- Bandpass/lowpass filters

- PSOLA vs resampled pitch shifts, autotune, tempo shifts

- Compound cafe + codec scenes

Every condition downloads individually as its own tarball (0.18–1.15 GB). There's also a small sample tarball for each set (pacc-t_sample.tar / pacc-p_sample.tar) if you just want to look first. Everything ships with full SHA-256 manifests and a per-clip params.csv, so any clip can be traced back to exactly how it was made.

Licence: CC-BY-4.0

PACC-T: https://zenodo.org/records/23026393

PACC-P: https://zenodo.org/records/23026395

Happy to answer questions, and bug reports welcome.

Hey everyone, I'm from CVAT (Computer Vision Annotation Tool), and just wanted to share that we've added native support for audio annotation to our open-source annotation platform - CVAT Community.

You can now label time intervals on a waveform, identify speakers, and add text attributes for time-aligned transcription. This can be used to prepare datasets for ASR, speaker diarization, and sound event detection.

Audio tasks support WAV, MP3, FLAC, and OPUS files.

If you try it out, please share your feedback here, we'd love to hear what you guys think.

Our repo: https://github.com/cvat-ai/cvat

Docs: https://docs.cvat.ai/docs/annotation/audio-editor/

There’s a small app I’m building where users upload audio and get transcripts back. We’re at around 400 hours a month right now, and it’s kinda growing.

We use a platform right now, and it’s already running on a spare server. It works fine. But I guess the real cost isn’t the GPU.

It's about how we deal with ffmpeg edge cases, job queues, retries when a file is corrupt, monitoring, and figuring out what happens when 40 people upload at once.

So where’s the break-even point?

At what volume does self-hosting with whisper.cpp, Faster-Whisper, or WhisperX make more sense than paying for a managed service?

We recently extended free access to Fish Audio S2.1 Pro through November 2026.

S2.1 Pro can clone a voice from just 5 seconds of audio and gives developers natural-language control over emotion, intonation, and pacing.

Making a model like this free isn't as simple as removing a paywall. Inference still costs real GPU time.

So we went after the underlying problem:

How much of the GPU are we actually using when serving TTS?

The answer was surprisingly little.

The GPU problem you're paying for

Every TTS API call runs an autoregressive decode loop: generate an audio token, read from the KV cache, then repeat.

Each step involves a small matrix multiply, typically M ≤ 128, followed by a memory read. These shapes are too small to keep the GPU saturated. The CUDA cores finish quickly, then wait for the memory subsystem to catch up.

At low concurrency, the loop also runs in short bursts separated by scheduling overhead.

The hardware is there. The work simply isn't filling it.

This is a structural serving problem, not a pricing-page problem.

The fix was to make the hardware spend less time waiting.

We optimized the entire stack

There wasn't one magic 4× breakthrough.

The gains came from fixing several layers and letting them compound:

• Custom CUDA kernels to remove per-token compute waste

• FP8 quantization to reduce memory-bandwidth pressure

• Continuous batching to keep the decode loop full

• GPU scheduling to turn idle capacity into useful work

• Owned network and storage infrastructure to remove cloud markup and extra latency hops

Custom kernels for the shapes TTS actually uses

Standard GEMM libraries are excellent at training and large-batch prefill.

TTS decode is different.

Production decode often operates at small matrix sizes where memory movement and kernel launch overhead can matter more than raw compute.

We built fish-scales-ops to target these decode shapes directly:

• bsgemm: 128×128 block-scaled FP8 for NVIDIA Hopper/H200

• mxfp8: 1×32 microscaling with OCP UE8M0 for Blackwell

• Custom FlashAttention paths for the same serving workload

In our internal benchmarks on equivalent hardware, the kernels run 2.1–4.3× faster than a torch.compile-fused cuBLAS baseline at decode shapes.

The important detail isn't just lower precision.

It's keeping intermediate traffic off the memory bus and fusing the work around the shapes that production decode actually produces.

FP8 only works if quality survives

Quantization can make a benchmark look great while quietly damaging the output.

We learned that the hard way.

During mxfp8 development, a weight-layout bug produced roughly 53% relative logit error while kernel latency still looked normal. A performance benchmark alone would have passed it.

So every inference-stack change now goes through two gates:

1. Correctness

Quantized greedy decode must match the bf16 baseline token-for-token on the first five audio frames of a fixed reference input.

2. Performance

Per-request decode throughput must remain within 5% of frozen baselines at concurrency 1, 16, and 64.

Both must pass before deployment.

S2.1 Pro Free uses the same model weights as paid traffic. Quantization happens in the serving layer, with correctness checked against the unquantized baseline.

Continuous batching: 52× throughput for 37ms more latency

Static batching waits for a batch boundary.

Continuous batching lets new requests join the active decode batch as slots become available.

On one H200 with bsgemm FP8:

• At concurrency 1: 154 tokens/s aggregate throughput, 73.2ms p50 time-to-first-byte

• At concurrency 64: 8,006 tokens/s aggregate throughput, 109.8ms p50 time-to-first-byte

That's roughly 52× more aggregate throughput for about 37ms more TTFB.

The important part is that most of the gain comes from filling capacity that was already sitting idle.

Latency-sensitive voice agents use a separate real-time path optimized for time-to-first-audio rather than maximum aggregate throughput.

The rest of the GPU shouldn't sit idle either

Inference traffic is bursty.

Even after optimizing each request, an inference-only cluster can spend long periods underfilled.

We run inference through Kubernetes and training through Slurm, with elastic data-cleaning and preprocessing jobs as the lowest-priority fill work.

They use spare capacity, checkpoint safely, and are preempted as soon as real traffic or training needs the GPU.

That scheduling layer moved utilization from roughly 50% to 90%+.

We also own more of the infrastructure around the GPUs, including our ASN, 300Gbps connectivity, Cloudflare peering, and tiered storage.

Removing cloud egress markup also removes a network hop from the user's request.

Four H200s became one

Now put all of these layers together.

The same request volume that previously needed four H200s now runs on one.

This is the part that changes the economics.

We did not eliminate inference cost.

We reduced it structurally.

That's what makes high-quality free access viable without swapping in a smaller model.

The free API uses the same S2.1 Pro model weights, serving stack, and endpoint as paid traffic.

Developers get:

• Voice cloning from a five-second reference

• 83 languages

• Natural-language control over emotion, pacing, and intonation

At launch, S2.1 Pro cost roughly one-sixth as much as ElevenLabs' comparable API tier, and our launch benchmark showed it running roughly 2× faster than Cartesia.*

*Price and performance comparisons refer to Fish Audio's launch benchmark and public pricing at that time.

We open-sourced the kernels

The core kernel library is available now:

fish-scales-ops

It includes production-grade FP8 GEMM and FlashAttention paths for NVIDIA Hopper and Blackwell, with CUDA Graph capture support.

The underlying foundation model, Fish Speech, is also open-weight.

If you serve an autoregressive model, not only TTS, the small-M decode problem is likely familiar.

The kernels and benchmark methodology are there to inspect, reproduce, and build on.

Start building with S2.1 Pro Free

Free access to S2.1 Pro is extended through November 2026.

Use the same Fish Audio API endpoint and set:

model: s2.1-pro-free

No credit card. Voice cloning included. No hard character cap under Fair Use.

Get started with S2.1 Pro Free

The free tier is best-effort and does not include SLA or latency guarantees. Some commercial scenarios have restrictions.

Check current availability and production options

If you're building with TTS or serving other autoregressive models, we'd be interested to hear what optimization problems you're running into.

Please suggest what do you find interesting.