Local CPU speech has more than one installation route
Pocket TTS can generate speech locally, but its model size does not tell you how much disk space your deployment will need. Our September developer environment measured 5,543 MB. The current README documents both a Python package and standalone binaries, so that older measurement should not become a minimum requirement for every installation.
Kyutai documents streaming audio, voice cloning, a CLI, Python API and local HTTP server. A WAV file can supply the voice prompt. Exported safetensors voice states avoid repeating reference-audio processing, and the README recommends keeping the model and voice states in memory because loading them is relatively slow. Configurations can use local YAML paths, HTTPS URLs or Hugging Face paths. Plan and cache those assets if the application needs to operate without network access.
The README prohibits voice cloning without explicit, lawful consent. Local execution also leaves application logging, asset downloads and access controls for the integrator to assess; we did not perform a privacy or security review.
What our September 27 run establishes
Our recorded run used commit d299fb6588f0243d29e10d479135d3ef30ccfec3, abbreviated d299fb6. The checkout contained 136 files, approximately 12,305 lines of source and 1.7 MB. The record reports 90 dependencies and a 5,543 MB installed footprint.
The install step exited 0 in 72 seconds; the build step exited 0 in 9 seconds. The supplied record does not expose their command lines or a separate installed-binary check. These results establish successful recorded steps, rather than a verified end-to-end CLI installation or synthesis workload.
The sandbox configuration lists 3 CPUs, 8 GB of memory and ghcr.io/astral-sh/uv:python3.12-bookworm. The install output says Using Python 3.10.21 environment at: /work/home/venv, and the test paths also reference Python 3.10. The image label therefore must not be reported as the runtime version.
The test step exited 1 after approximately 120 seconds, without a recorded timeout. Pytest's tail reports 1 failed, 118 passed, 1 skipped, 111 warnings, 5 errors in 104.94s (0:01:44). The outer step duration and pytest duration measure different scopes. The parser also records a total of 124, but exhaustive unique test coverage has not been verified. We do not describe this as 118 passing tests out of 124.
The failed case was tests/test_audio.py::test_audio_read_uses_soundfile_for_8_bit_wav. Its ImportError says soundfile is required to read non-WAV or non-16-bit WAV audio. The tail does not establish why that requirement was unavailable. Five error entries name modules under training/tests: dataloader, evaluation naming, loader signals, smoke and units. Their underlying exceptions are absent from the supplied tail. This command did not pass; it does not prove that Pocket TTS synthesis is broken.
The audit record lists pip-audit with an advisory total of 0 and a packages field of 0. Audited package coverage is unknown. This is not evidence that all 90 dependencies were scanned or that the software is safe.
No measured speech workload, listening evaluation, cloning-accuracy assessment or latency benchmark accompanies this run.
Separate the measured checkout from current options
The measured checkout's README describes a 100M-parameter model and training code announced in August 2026. Release v3.3.0 lists retrained Spanish, Italian, Portuguese and German models plus new Dutch support.
The current README additionally lists English models with 18.2M, 6.9M and 1.9M parameters, including the decoder. Kyutai advertises speeds up to 25 times real time on one CPU thread for the small models. That is an upstream claim, not our benchmark, and our September run does not evaluate these October models.
The current README also documents standalone binaries for Linux and macOS on x86 and ARM, and Windows on x86. It says they require neither Python nor PyTorch, use a Rust implementation built on xn-ptts and run only on CPU. They cannot load training checkpoints through --checkpoint, and their audio is not bit-identical to the Python package's because sampling noise differs. We have not downloaded or tested those binaries. Their existence makes the measured Python developer footprint an unsuitable blanket objection to Pocket TTS.
For Python deployments, the documented requirements remain Python 3.10 through 3.14 and PyTorch 2.5+. The README warns that Linux installation from PyPI can download CUDA runtime wheels and supplies a PyTorch CPU-index route. Our record does not establish which packages account for the measured footprint, nor how much a different installation route would save.
Pause control and number handling need different conclusions
The current README explicitly lists adding silence through text input as unsupported. Issue 6 contains external silence-splicing examples and a contributor's proposed implementation. Those discussion examples do not establish that built-in pause markup has shipped. If exact pauses are required, verify the selected release or provide application-level audio assembly.
Issue 162 reports decimal splitting, including 98.6 and 3.14. Its activity also records an August 27, 2026 commit titled "Fix decimal splitting in sentence chunker (#217)". An open issue label alone therefore cannot establish that the original defect persists at d299fb6 or in current releases. The supplied evidence does not include an implementation review or a matching regression run. Test representative numbers in the selected model and language before relying on their spoken output.
GPU support remains qualified
The README describes GPU use as unofficial. The generate command has a device option, while the Python serve command and Docker image always run on CPU. Dynamic int8 quantization is also CPU-only. These are documented boundaries, not results from our sandbox.
For a resident CPU service, keeping the model and voice state loaded follows Kyutai's guidance. For a GPU deployment, confirm the supported execution path before adopting it. Neither choice substitutes for checking whether generated speech says what the application intended.
How to read the scores
These are editorial ratings of the supplied evidence, not benchmark results. The scale is 1 for a documented major obstacle, 2 for limited evidence or substantial unresolved questions, 3 for a usable documented path with material caveats, 4 for broad supporting documentation or demonstrated coverage, and 5 for broad independent validation. Missing evidence does not prove poor product quality.
Setup scores 3/5 because the recorded install and build steps succeeded, but the environment was large and installed-CLI operation was not established. Documentation scores 4/5 because the README covers requirements, interfaces, installation choices, asset handling and execution limits. Community scores 2/5 because the supplied contributor activity does not establish adoption, support responsiveness or maintainer capacity. Maturity scores 3/5 because release and training documentation exist, while our test command did not pass and production speech behavior remains unmeasured.
Start with the route your application needs: Python integration or a standalone CLI. Check that route on the target machine, record the model revision and assets, then evaluate representative speech, including numbers and required pauses. Our September developer run is useful setup evidence for one commit, not a verdict on every current deployment.