Ollama announced support for speech models on October 24, 2026, starting with Gradium’s Phonon text-to-speech family. The dated announcement is an Ollama availability milestone, not evidence that Gradium first released the underlying models that day. It describes speech generation on Apple Silicon Macs, with Windows and Linux support still forthcoming.
Small speech models with different permissions
The Ollama library lists a default 31M-parameter English checkpoint and 40M variants for English, French, German, Spanish, Portuguese and multilingual use. Its reported loaded memory on an M5 Max is 121 MB for the default and 141 MB for the 40M models. Those are model allocations on a particular system, not the total memory required by an application.
The license split is more consequential than the size difference. The English 31M checkpoint uses Apache 2.0; the listed 40M checkpoints use CC BY-NC 4.0, which limits them to noncommercial use. A team cannot infer permission for a multilingual commercial deployment from the default English model’s license.
Gradium also publishes a voice catalogue with embeddings and samples. A voice’s availability is a separate question from whether a selected checkpoint, language and runtime support the intended application. Keep those choices explicit when comparing outputs or documenting a product configuration.
Streaming changes the listening experience
Ollama’s announcement describes audio generation as text arrives, so a local assistant can begin speaking before its entire reply is finished. It exposes an OpenAI-compatible speech endpoint and returns 24 kHz mono audio. That compatibility is an interface choice; it does not require sending the speech request to OpenAI.
The company reports an Apple Silicon throughput advantage over Gradium’s own runtime under its stated M5 Max test conditions. This is a vendor benchmark, not a Nerova measurement. Bulk generation speed also differs from the delay a listener hears before the first useful words.
Our assessment is that the most valuable local use cases may be modest: reading a status message, narrating instructions or adding spoken feedback to an application. A small model footprint can help, but the quality requirement depends on the content. A pleasant sample sentence says little about an address, a medication name or an unfamiliar surname.
The application still owns what gets spoken
Ollama’s speech documentation separates speech from conversation: the model speaks supplied text. The documented API accepts up to 4,096 characters per request, and unsupported options produce errors. Teams should use the speech-specific API and check errors instead of assuming a generic chat example proves audio support.
For an assistant, consider separating approved spoken text from internal tool output. An error trace, a private record or a provisional answer should not automatically reach the speaker. Audio can disclose information to people nearby even when inference stays on the device.
Streaming also creates a correction problem. If an assistant starts reading a statement and later discovers it is wrong, the words already heard cannot be withdrawn. A confirmation or financial total may warrant waiting for the underlying operation to complete, while a harmless progress update can be spoken earlier.
What would make a useful local evaluation
A focused evaluation should include short replies, long instructions, punctuation, dates and domain-specific names. Record time to first audio, intelligibility and interruptions. Test what happens when the user cancels playback and when the next reply arrives before the current one finishes. These are proposed measures, not firsthand results.
The October announcement gives developers a concrete local speech route. Its usefulness depends on matching the checkpoint’s language and license to the workload, then designing playback around what a person should hear and when. The speech model provides a voice; the surrounding application still determines whether that voice is accurate, timely and appropriate.