speakrs

# macOS (CoreML)
speakrs = { version = "0.7", features = ["coreml"] }

# NVIDIA GPU
speakrs = { version = "0.7", features = ["cuda"] }

# CPU
speakrs = { version = "0.7", features = ["cpu"] }

# AMD GPU
speakrs = { version = "0.7", features = ["migraphx"] }

The cpu, coreml and cuda features run native backends, so a build with only those features does not compile, link, or download ONNX Runtime.

Quick start

use speakrs::{ExecutionMode, OwnedDiarizationPipeline};

fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let mut pipeline = OwnedDiarizationPipeline::from_pretrained(ExecutionMode::CoreMl)?;

    let audio: Vec<f32> = load_your_mono_16khz_audio_here();
    let result = pipeline.run(&audio)?;

    print!("{}", result.rttm("my-audio"));
    Ok(())
}

Speaker turns

let result = pipeline.run(&audio)?;

for segment in result.discrete_diarization.to_segments() {
    println!("{:.3} - {:.3}  {}", segment.start, segment.end, segment.speaker);
}

Background queue

QueueSender and QueueReceiver run a background worker. Use QueueSender::try_push to submit audio without blocking. A full queue returns the request in QueueError::Full so the sender can retry it:

use std::time::Duration;

use speakrs::{ExecutionMode, OwnedDiarizationPipeline, QueueError, QueuedDiarizationRequest};

let pipeline = OwnedDiarizationPipeline::from_pretrained(ExecutionMode::CoreMl)?;
let (tx, rx) = pipeline.into_queued()?;

let sender = std::thread::spawn(move || -> Result<(), QueueError> {
    for (file_id, audio) in receive_files() {
        let mut request = QueuedDiarizationRequest::new(file_id, audio);
        loop {
            match tx.try_push(request) {
                Err(QueueError::Full(rejected)) => {
                    request = rejected;
                    std::thread::sleep(Duration::from_millis(10));
                }
                Ok(_) => break,
                Err(error) => return Err(error),
            }
        }
    }
    Ok(())
});

for result in rx {
    let result = result?;
    print!("{}", result.result?.rttm(&result.file_id));
}
sender.join().expect("sender thread panicked")?;

Local models

For offline or airgapped setups, load models from a local directory:

use std::path::Path;
use speakrs::{ExecutionMode, OwnedDiarizationPipeline};

let mut pipeline = OwnedDiarizationPipeline::from_dir(
    Path::new("/path/to/models"),
    ExecutionMode::Cpu,
)?;
let result = pipeline.run(&audio)?;

Python

pip install speakrs

import speakrs

pipeline = speakrs.Pipeline.from_pretrained("coreml")  # or "cpu", "cuda"
print(pipeline.diarize_file("meeting.wav").rttm())

For the speakrs diarize command line alone, uv tool install speakrs installs it in its own environment.

The macOS arm64 wheel includes CPU and CoreML, and the Linux x86_64 and Windows x86_64 wheels include CPU and CUDA. See the Python package and its API reference.

Command line

The speakrs command diarizes audio files and prints RTTM, with no Python. Each GitHub release has it for Linux x86_64 with CPU and CUDA, Linux arm64 with CPU, Apple silicon with CPU and CoreML, and Windows x86_64 with CPU and CUDA. On Linux and macOS, this installs the latest release into ~/.local/bin:

curl -LSfs https://github.com/avencera/speakrs/releases/latest/download/install.sh | sh
speakrs diarize meeting.wav > meeting.rttm

Add --mode coreml on a Mac or --mode cuda on an NVIDIA GPU.

It reads WAV, FLAC, MP3, Ogg and M4A, and downloads the mode's models into the Hugging Face cache on first use. It takes the same options as the Python package's speakrs diarize: --mode (default cpu), --model-dir, --cache-dir, --file-id and --exclusive. Several files run as one overlapped batch. Each file's RTTM id is its name without the extension, with whitespace replaced by _, since RTTM fields are separated by spaces. The Linux binaries need glibc 2.28 or newer, and the CUDA modes need an NVIDIA driver. To pick another release or install directory, end the first line with sh -s -- --tag vX.Y.Z --to DIR.

On Windows, download speakrs-<tag>-x86_64-pc-windows-msvc.zip and its .sha256 from the latest release, and put the speakrs.exe inside in a directory on PATH. It needs no Visual C++ redistributable. The Windows build passes CI but hasn't run on a GPU yet.

To build it from source with the backends you want:

cargo install --git https://github.com/avencera/speakrs speakrs-cli --features coreml

Choosing a mode

Each mode needs its Cargo feature: cpu, coreml for both CoreML modes, cuda for both CUDA modes, or migraphx. Requesting a mode whose feature is off returns ModelLoadError::UnsupportedExecutionMode.

The *-fast modes move the segmentation window every 2 seconds instead of every 1 second. That gives the pipeline fewer windows to score, so it can be much faster, but speaker changes may land a little farther from the exact word or pause where they happened.

Use the 1 second modes when you care about exactly when each speaker starts and stops, short clips, interviews with quick back-and-forth, or audio you plan to subtitle or edit. The 2 second modes are usually worth trying for long recordings where speed matters more than exact speaker-change times, such as meetings, lectures, podcasts, or bulk archives.

Benchmarks

On VoxConverse dev on an RTX 4090, speakrs cuda is about 60 times faster than an earlier pyannote CUDA run, with 7.0% versus 7.2% DER. cuda-fast is about 115 times faster, with 7.4% DER. On an RTX 4090, an hour of audio takes about 1.9 seconds with cuda and 1.0 second with cuda-fast. On an RTX 5090 it takes about 1.2 seconds with cuda and 0.6 seconds with cuda-fast. On an Apple M4 Pro with CoreML it takes about 7 seconds.

VoxConverse dev, collar=0ms:

SpeakerKit was measured on the same M4 Pro in March 2026 with the version available then, and it has shipped releases since.

The two speakrs RTX 4090 rows ran in the same container, with 16 CPU cores (the cloud host doesn't report the CPU model), 8 GiB of RAM and NVIDIA driver 580.126.18. Their times are the median of 3 runs. The pyannote row ran earlier in a container with the same GPU, CPU count, RAM and driver, so the speedups compare separate runs. The RTX 5090 rows ran on an Intel Core Ultra 7 270K Plus with 24 CPU cores, 57 GiB of RAM and driver 595.99.02, also the median of 3 runs. The speakrs CUDA timings use the batch API, OwnedDiarizationPipeline::run_batch_stream, with WAV files decoded on worker threads ahead of it; it clusters each finished file while the GPU runs the next.

All datasets on an RTX 4090 and RTX 5090

Both GPUs score the same DER on every dataset.

That's about 229 hours of audio in under 8 minutes with cuda on the RTX 4090, or under 4 minutes with cuda-fast. The RTX 5090 takes under 5 minutes with cuda and under 2.5 minutes with cuda-fast. The VoxConverse dev rows come from the runs above; the other rows are single runs of the same version, on RTX 4090 containers with 16 CPU cores and 8 GiB of RAM, and on the RTX 5090 machine. On VoxConverse test, cuda and pyannote CUDA both score 11.1% DER; pyannote ran at 25x in an earlier container, about 75 times slower than cuda. On AMI IHM and Earnings-21, cuda matches the earlier pyannote runs at 17.0% and 9.7% DER, where pyannote ran at 15x and 18x. On macOS, coreml runs these datasets at 450x to 644x, with DER within 1.6 points of pyannote's. See benchmarks/ for every table, the hardware used and the timing method.

CoreML, CUDA and ONNX Runtime can differ slightly even in FP32, because floating-point reduction order changes rounding.

Why not pyannote-rs?

Despite its name, pyannote-rs is not a Rust port of the full pyannote diarization pipeline. It provides useful building blocks for a much simpler, lightweight diarizer.

In the end-to-end pattern shown by its examples, pyannote-rs:

1. runs the pyannote segmentation model on non-overlapping 10-second windows;
2. reduces every frame to speech or non-speech, emitting one segment for each uninterrupted region of speech;
3. computes one speaker embedding for that entire segment; and
4. assigns the segment online by comparing its embedding with previously seen speakers using a fixed cosine-similarity threshold.

That is closer to voice activity detection followed by online speaker matching than to pyannote community-1.

These differences explain the accuracy gap. A speech region can contain several turns with no silence between them. pyannote-rs treats that region as one segment, mixes all voices into one embedding, and gives it one speaker label. It also discards the segmentation model's separate local speaker tracks, so it cannot represent overlapping speakers. Its online assignments are not reconsidered using evidence from the rest of the recording.

speakrs keeps the per-speaker frame activity, extracts speaker-conditioned embeddings, combines evidence from overlapping windows, and clusters all usable embeddings together. PLDA makes the embeddings more discriminative for speaker identity, while VBx uses the recording's temporal and global evidence to refine speaker assignments. The final reconstruction can therefore preserve rapid speaker changes and overlapping speech instead of reducing a whole speech region to one voice.

The benchmark reflects that architectural difference. With pyannote-rs v0.3 on VoxConverse dev, it returned no RTTM segments for 183 of 216 files. On the remaining 33 files where it produced at least five segments (186 minutes, collar=0ms), the result was:

Lower DER is better. The 80.2% figure is the subset-only comparison; it does not count the 183 files for which pyannote-rs produced no output.

Models

With the default online feature, models download on first use from avencera/speakrs-models. Set SPEAKRS_MODELS_DIR if you want to force a local bundle instead.

Native CPU inference loads segmentation-3.0.safetensors and wespeaker-multimask-tail.safetensors, plus the PLDA files and wespeaker-voxceleb-resnet34.min_num_samples.txt. The online model manager downloads these files for CPU mode, not ONNX graphs.

The CPU model constructors accept the canonical segmentation-3.0.onnx and wespeaker-voxceleb-resnet34.onnx paths as family selectors. Those files do not need to exist; the native weights must be in the same directory. The known native safetensors paths are also accepted. Arbitrary ONNX models are not supported by native CPU inference. MIGraphX continues to load ONNX graphs.

Features and build notes

Enable the backend feature for your platform. The build fails with a clear error if none is enabled.

The default online feature downloads models with ModelManager. load-dynamic loads ONNX Runtime at run time for migraphx or the external ONNX session helper. The native CPU backend doesn't need it. The ONNX Runtime dependency (ort 2.0.0-rc.15) is still a pre-release.

NVIDIA GPUs

The CUDA backend runs speakrs's own GPU kernels on Linux and Windows (x86_64). It works on any NVIDIA GPU from the RTX 20 series and T4 onward, and you don't need the CUDA toolkit to build or run it.

Not sure which GPU you'll run on? Use cuda. It includes kernels for every supported GPU generation. It can also fall back to cuDNN 9 and cuBLAS 12 for a layer without a speakrs kernel, and loads them only then. On the GPUs listed below every layer has a kernel, so the libraries aren't loaded.

speakrs = { version = "0.7", features = ["cuda"] }

Know your GPU? Use its feature for fewer dependencies and a smaller install. A GPU-specific build needs only the NVIDIA driver and never loads cuDNN or cuBLAS, so you can leave about 2 GB of libraries out of every machine or container image (cuDNN 9 is about 1.2 GB and cuBLAS 12 about 0.8 GB as NVIDIA ships them). On the GPUs we tested, these builds run within about 1% of cuda.

speakrs = { version = "0.7", features = ["cuda-rtx40"] }

On Windows the driver is nvcuda.dll from System32, and the cuda fallback opens cudnn64_9.dll, cublas64_12.dll (with cublasLt64_12.dll beside it) and nvrtc64_120_0.dll. It looks for them beside the executable, in System32, in each absolute PATH entry and in %CUDA_PATH%\bin, where a CUDA 12 toolkit keeps cuBLAS and NVRTC, but never in the current directory. Put cuDNN's directory on PATH, or use the Python package, whose cuda extra brings its own. CUDA on Windows builds and passes its host-only tests in CI, but it hasn't run on a GPU yet.

Tested NVIDIA GPUs

Real-time factor (RTFx) is audio length divided by processing time, so 1453x means an hour of audio takes about 2.5 seconds. These runs used a 10-file VoxConverse subset, and their times include process start-up and model loading:

Every run had 16 CPU cores, and each value is the median of 3 runs. The RTX 5090 row comes from a later version than the others. The RTX 4060 Ti and RTX 5060 Ti also have tuned kernel profiles. In an earlier version, on the same subset, speakrs's own kernels were 1.4x to 2.0x faster than cuDNN and cuBLAS on the RTX 4090, L4, A10 and H100. See benchmarks/ for full results across all datasets.

Getting the most out of other GPUs

GPUs without a built-in profile use good defaults. To get the best speed on yours, run the tuner once. It measures the kernels on your GPU and saves the fastest choices, which later runs load automatically. A tune file only applies to the speakrs version and CUDA feature that wrote it. For an application built with cuda, use the Linux x86_64 or Windows x86_64 speakrs command from the matching GitHub release, which is built with cuda:

speakrs cuda tune

Without --models-dir, it tunes with the CUDA models from the download cache, downloading them first if needed. For a GPU-specific build, build the command with the same feature as your application:

cargo build --release -p speakrs-cli --no-default-features --features cuda-rtx40
./target/release/speakrs cuda tune --models-dir /path/to/models

The CUDA backend details cover kernel selection, built-in profiles, tuning options and debugging settings.

Public API

Start here:

• OwnedDiarizationPipeline: pipeline entry point
• QueueSender and QueueReceiver: background worker interface
• QueueConfig: in-process queue capacity
• DiarizationResult: frame-level activations, segments, clusters, embeddings, RTTM
• PipelineConfig and RuntimeConfig: tuning knobs
• ModelManager: model download when online is enabled
• Segment: a single speaker turn

Model downloads use hf-fetch, a small blocking client with rustls and the shared Python Hugging Face cache. The online feature enables downloads; local model loading works without it.

Releases

A v* tag publishes the Python wheels to PyPI and creates a GitHub release; CI doesn't publish the crates to crates.io. The release holds the speakrs command for Linux x86_64, Linux arm64, Apple silicon and Windows x86_64, each archive with a SHA-256 checksum, and the install.sh that installs it on Linux and macOS. To cut one:

1. Bump version in Cargo.toml (the [package] and [workspace.package] versions, and the exact speakrs-ptx-* pins), then run cargo check to update Cargo.lock.

2. Move the CHANGELOG.md entries under ## Unreleased to a ## [X.Y.Z] - YYYY-MM-DD heading, which becomes the release notes.

3. Merge to master, then tag that commit and push the tag:

   git tag vX.Y.Z
   git push origin vX.Y.Z
   

The Release workflow fails before building if the tag doesn't match the crate version or CHANGELOG.md has no entry for it. Each archive's binary must diarize a test file before it uploads. The release stays a draft until every archive and install.sh upload, then it's published as the latest release.

Contributing

See CONTRIBUTING.md for local setup, model downloads, fixture generation, and the standard check commands used in this repo.

References

• pyannote-audio - Python reference implementation
• pyannote community-1 - VBx + PLDA pipeline
• SpeakerKit - Swift reference (same VBx architecture)