B2 Reference Architectures for Voice and Speech AI
Reference architectures for storing, versioning and delivering voice and speech AI data on Backblaze B2: training datasets, generated and dubbed audio, and voice agent session recordings. Each architecture has a data flow, an object layout, security and retention rules, B2 configuration templates, and the places where B2 does not belong. The repository also includes three example applications in Python.
Built for: ML engineers, data engineers, speech and audio researchers, and platform engineers who keep voice data on Backblaze B2 or are deciding whether B2 belongs in a voice AI design.
What it's built with
Each piece of the stack, and the job it does in this project.
- Backblaze B2 S3-compatible API
- Object storage for recordings, dataset releases, candidates, deliveries and manifests
- Python 3.10+ with boto3
- Examples, catalog tooling and the three example applications
- TypeScript with the AWS SDK for JavaScript
- Presigned URLs, multipart upload with resume, object versions and Event Notifications verification
- JSON Schema
- Contracts for session, generation job, consent, dataset line, release and delivery manifests
- moto
- Emulated S3 server used by the tests, so they need no B2 account
- LiveKit Egress
- Output template that records voice agent sessions to B2
Core capabilities
What the project does out of the box, before you write any code of your own.
Voice training data lifecycle
Collect speech with consent, validate it on signed Event Notifications, review transcripts and publish immutable dataset releases that NeMo, Lhotse, WebDataset, Hugging Face Datasets and MosaicML Streaming can read.
Batch voice generation and dubbing
Give dubbing, synthesis and transcription providers presigned GET URLs, keep every output as an expiring candidate, and promote reviewed outputs to immutable deliveries with lineage.
Voice agent session archive
Archive finished sessions from LiveKit Egress or a session adapter, record an evaluation result per session, and retain each session by class under Object Lock.
B2 configuration as templates
CORS, lifecycle, Event Notifications, Object Lock, replication and encryption ship as templates, with scoped application key commands and a provisioning plan that prints commands and runs nothing by default.
Explicit boundaries
Each architecture lists where B2 does not fit: real-time audio transport, low-latency session state, queues, models, orchestration and training caches stay in the systems built for them.
Three example applications
Python command-line tools for dataset ingest, generation artifacts and session archives implement the architectures and run their tests against an emulated S3 server.
Choose it for the right job
B2 Reference Architectures for Voice and Speech AI is a head start for a specific shape of project, not a supported, general-purpose product.
Use it when
- You keep finished voice data such as recordings, datasets, generated audio and transcripts that must outlive the systems that produced it.
- You need consent records tied to each clip or session, retention per class, and versioned releases that training or delivery can cite exactly.
- Your voice platform or providers run elsewhere and you want one storage layer they read from or that your application copies into.
- You want schemas, configuration templates and tested examples to adapt for your own deployment.
Choose another path when
- You need B2 in the real-time audio path of a live conversation; the architectures keep it out of that path.
- You need a supported product or a service-level agreement.
- You need isolation between tenants; the layouts assume a single organization and do not define per-tenant buckets or keys.
- You need per-object retention, bucket configuration, Event Notification delivery or a provider integration to be proven against a live account: the opt-in live checks cover storage operations only, and those parts are checked against documentation or an emulator, or for shape.
- You expect a ready-to-run service: the example applications are small command-line tools, and the generation example uses synthetic placeholder audio with no provider adapter.
Project status and support
All three architectures are marked source-reviewed-and-automated-tests in the catalog: provider and platform behavior was checked against documentation or source on the dates stated in each one, and the tests run in CI against an emulated S3 server. Each application also has an opt-in live check, not part of CI, that was run once on 2026-10-16 against a real B2 test bucket. It confirmed authentication and the endpoint derived from the region, put, get, head and list, presigned PUT and GET, server-side copy, manifest write order, delete, a multipart upload resumed after an interruption, and presigned URL expiry. Not validated live: per-object retention and release, bucket configuration (lifecycle, CORS, Event Notification, replication and encryption templates are checked for shape only), Event Notification delivery, LiveKit Egress, the named providers and platforms, and isolation between tenants. This is open source with no service-level agreement; open an issue on the repository for questions.