pyannoteAI is now on Baseten Distribution Platform

Starting July 29th, 2026, pyannoteAI is part of the Baseten Distribution Platform, launched as part of Baseten for Labs. Community-1 and Precision-2 are available directly from Baseten's model library, running on infrastructure Baseten already operates and optimizes. No serving stack to stand up. You pick a model, deploy it, and start turning raw audio into speaker-attributed metadata.

That is the point of Baseten for Labs. Specialist model labs publish directly into the library developers already deploy from, so the newest models land where products actually run instead of behind another vendor integration. Baseten brings the inference infrastructure and the scale it operates at. We bring twelve years of speaker diarization research and the models that a large part of the Voice AI ecosystem already builds on.

Whether that upgrade is worth it depends on how much the speaker labels you have today are actually costing you. That is worth being precise about, because most teams underestimate it.

Why word-derived speaker labels have a ceiling effect

When speaker labels emerge from an STT system, they are usually a product of the transcript, rather than the audio itself. The ASR produces a word sequence with timestamps, and speakers are assigned to those words after the fact. That design has a structural consequence that no amount of model scaling fixes.

Overlap has nowhere to go. Two people talk at once. Both voices are in the audio, but the ASR emits a single word sequence, because that is what a transcript is. One speaker's words are dropped or folded into the other's turn. There is no way to express "two people spoke here."
The errors cluster in the components that matter. Diarization Error Rate splits into three parts: missed detection, false alarm, and speaker confusion. Word-derived pipelines score well on false alarm, because the ASR already separates speech from silence. They lose on the other two.
Word timestamps are alignment, not acoustics. ASR timestamps come from an alignment step and drift by tens to hundreds of milliseconds at turn boundaries. Fine for highlighting a word in a player. Not fine if you are computing talk-time ratios, gaps between turns, or interruption rates, because then you are measuring your alignment error as much as the conversation. Acoustic diarization gives you boundaries at centisecond resolution.

Our published benchmark puts numbers on the gap: up to 52% lower transcription error rate than leading alternatives, and 28% more accurate than pyannote's own open-source Community-1 baseline with Precision-2. These models are diarization-first, built from acoustics instead of inheriting the transcript's structure.

What is available at launch

Two models ship today:

Community-1 is our open-source model, the current iteration of the pyannote.audio line. It is the right starting point for benchmarking, prototyping, and any workload where transparency into weights and code paths matters. It is backed by 1B+ downloads on Hugging Face and 300k+ developers building on pyannote.audio worldwide, which in practice means that when you hit a problem, someone has already written about it.

Precision-2 is our commercial model, built for production: 28% more accurate than the open-source 3.1 baseline, and up to 52% lower transcription error rate than leading alternatives on our published benchmark. It is also meaningfully faster to run, which matters when you are paying for GPU time by the hour of audio.

Both are built on 12 years of dedicated Speaker Diarization research, most of it done in the open at CNRS, France's national research centre, before it became a product.

Switching between them is a parameter change. Same request shape, same output schema. That is deliberate: you validate on Community-1, then move to Precision-2 when accuracy on your production audio justifies it, without touching the code around it.

Why we joined the Baseten Distribution Platform

We host our own API, and we will continue to. Publishing on Baseten is about meeting developer teams where their inference already runs.

Baseten handles GPU procurement, autoscaling, billing, and the compliance posture (GDPR, HIPAA, SOC) that healthcare and financial services buyers require before they will look at a pipeline at all. Publishing Community-1 and Precision-2 there means that a team already deploying transcription or LLM models on Baseten can add speaker intelligence in a couple of clicks and see the difference in their pipeline within minutes.

You configure the model rather than integrate it. Benchmark two diarization models against your own audio in an afternoon, on the hardware you will actually run on, and promote the winner without changing how anything deploys. When volume arrives, you scale it the way you already scale everything else.

What does this change for developers

Adding speaker attribution to a pipeline stops being an infrastructure project and becomes a model selection. Open the Baseten model library, pick community-1 or precision-2, deploy to an endpoint, and call it like anything else you run there.

That matters more than it sounds, because diarization does not serve like the rest of your stack. The clustering step is global to the recording, so a three-hour meeting and a forty-second voice note are both "one request" to your autoscaler while differing by two orders of magnitude in GPU time. Running it yourself means writing a clustering-aware autoscaling policy, provisioning GPUs, and keeping serving code alive through the next CUDA upgrade. On Baseten, none of that is yours to maintain.

This is not a hypothetical path. Descript runs transcription workloads, that incluse pyannote’s speaker diarization on Baseten, and Abridge runs its clinical speech models there as well. These are teams operating at production scale in domains where speaker attribution is not a nice-to-have: a clinical note attributed to the wrong participant is a correctness failure, not a formatting one.

What is next

Live-1, our streaming diarization model is coming to the marketplace next. It brings real-time speaker attribution to the same deployment path, for voice agents, live captioning, and any pipeline where you cannot wait for the recording to finish before you know who is speaking. You can read about how we built it and what it does today at pyannote.ai/streaming.