Phonon turns text into speech on the device running an application. Gradium’s November 9 release of version 0.7.0 in gradium-ai/xn-ptts gives its browser package a GPU engine built around this particular speech model. WebGPU—the browser interface to graphics hardware—already powered Phonon. The change is a specialized plan for running its calculations and returning a small first piece of sound. For local narration or a reading assistant, execution software is another way to improve a model’s delivery.
The division of labor is straightforward. Rust compiled to WebAssembly prepares text and voices. On the GPU, one model component generates compact representations of speech; a decoder turns them into playable audio. The replacement changes how that GPU work is organized and how soon the first piece is returned to the application. The engine documents this boundary.
Inside Phonon’s optional WebGPU path
A prepared GPU plan.
A worker still in charge.
Browser worker
Prepares text and voice in Rust/Wasm. Submits work; handles cancellation.
Submit work
Audio + state
back to worker
GPU engine
Language + codec dispatch lists, prepared at load, with fused operations.
GPU sampling, end-of-speech state and audio decoding.
Nominal decode chunks, shown separately
- 1 frameFirst decode
- 2 frames
- 4 frames
- 8 frames
Each frame holds 80 ms of audio. That is sound duration, not compute latency.
At most 8 frames per submit; up to 3 submits in flight. End of speech or the frame budget can shorten this progression.
The previous GPU path already kept latents on-device, warmed pipelines and batched four frames. The prepared lists still need host command recording and submission.
An execution plan for this model
Our October 22 report followed Phonon’s downloadable local speech kit. This release advances its execution. The earlier browser engine already kept speech representations on the GPU, decoded four-frame batches and overlapped work with results coming back. It also warmed GPU programs before the real utterance. The previous implementation shows that baseline.
The new engine builds reusable lists of GPU operations when the model loads. It prepares the programs, buffer connections and parameters before generation, then issues the prepared operations repeatedly. Specialized kernels also combine calculations that otherwise require separate operations. This reduces repeated setup around the model’s arithmetic; it is an optimization of the execution path. The dispatch builder makes the arrangement inspectable.
Sampling and the state that determines when speech ends now advance on the GPU. The browser’s host code still submits work, collects audio and a small state block, and handles cancellation. This is a coordinated host-and-GPU engine; the page still has a job. Its submission and readback loop shows those responsibilities.
A small start, then larger deliveries
The decoder starts with one frame, then grows to two, four and eight, with up to three submissions in flight. The frame budget or end of speech can shorten that sequence. Each frame contains 80 milliseconds of audio. That is the duration a listener can hear, not a promise that generation takes 80 milliseconds. The first delivery needs only one frame; later batches let the engine do more work between deliveries. The frame constants and batch progression specify the tradeoff.
The contributor’s updated Apple measurements report faster generation and earlier first audio with the final kernels on M5 Chrome, M5 Safari and iPhone 16 Pro Safari. Those were warm, eleven-phrase tests; the iPhone used a WebGPU flag. We have not reproduced their performance. Several optimizations changed together, so the gains cannot be assigned solely to the prepared operation lists. The dated measurement comment gives the conditions.
The specialization has boundaries. The GPU engine checks the model configuration and requires q8_0 transformer weights and its supported decoder architecture. CPU remains the default. Explicit webgpu rejects unsupported configurations; auto can fall back to CPU. Compatibility checks and device policy make that choice explicit.
We downloaded phonon-tts 0.7.0 and matched six engine and worker files to the merged source. That verifies shipped code, not listening quality or browser speed. The useful next test is your application’s first audible playback on target hardware: include cold downloads, interruption and intelligibility. For a reading assistant, the meaningful gain is intelligible speech the listener can actually hear sooner.
