Deepgram Release Notes

What GA Means for Your Workloads

Deepgram's global expansion began with Deepgram Dedicated and our EU endpoint. Australia is the next region. The Deepgram Australia endpoint is now generally available, giving teams a fully managed way to run voice AI with customer data processed and stored entirely within Australia.

Today, the Deepgram Australia endpoint is generally available to every customer. Any organization with Australian data-residency requirements, whether based in Australia or serving Australian users from abroad, can now run speech-to-text, text-to-speech, and Voice Agent workloads on Deepgram, with audio processed and stored inside Australia, using the same API, models, and SDKs available on our US and EU endpoints.

Australia has been among the most-requested regions from our customers, with demand concentrated in healthcare, financial services, legal technology, and government. This launch is a direct response to that demand.

For regulated industries, this removes a long-standing constraint. Under the Australian Privacy Principles (APP 8), an organization that discloses personal information overseas remains accountable for how that information is handled downstream. Health data carries a stricter obligation, as the My Health Records Act requires that it be processed within Australia. Government and critical-infrastructure work adds further onshore requirements under the Hosting Certification Framework and the Security of Critical Infrastructure Act. For these buyers, where voice data is processed and stored is a procurement requirement.

Until now, teams building on Deepgram in Australia could route audio to our Global or EU endpoints, which introduced cross-border exposure, or deploy Deepgram self-hosted within their own Australian infrastructure, which requires the engineering capacity to operate it in production. The Australia endpoint provides a third path. It is a fully managed, fully onshore option that uses the same Deepgram Voice AI API as our Global or EU endpoints.

What GA Means for Your Workloads

The Australia endpoint is production-ready and available to all customers, with no waitlist and no enterprise-only restriction. It runs in AWS’s ap-southeast-2 region (Sydney), and pricing matches our Global and EU rates at launch.

Adoption requires a single change. Point your integration at api.au.deepgram.com, and your existing API keys and SDK integrations continue to work. There is no separate account, no migration project, and no change to how you call the API.

Where Your Data Is Processed and Stored

Your audio, transcripts, and speech output are processed and stored in Australia, with both storage and inference in-country.

The residency commitment is specific. For speech-to-text and text-to-speech on Deepgram models, both storage and inference happen on Australian infrastructure (AWS ap-southeast-2, Sydney), not storage alone. Two boundaries are explicit, so compliance teams can review the full picture:

• Voice Agent LLM. If a Voice Agent uses a managed third-party LLM (the reasoning step), that provider processes the request outside Australia. Confirm the provider's residency and processing guarantees independently; Deepgram runs listen and speak in-country.
• Operational metadata and billing are processed in the US.

For the strictest frameworks (such as the My Health Records Act, where all processing activities, including access, must occur in Australia), opt out of model improvement (mip_opt_out=true). That keeps customer content out of any training workflow, so no content is accessed or processed across Australian borders for any purpose.

Supported APIs and Models

The Australia endpoint provides the same API surface as our Global and EU regions. Speech-to-text is available at /v1/listen and /v2/listen, text-to-speech at /v1/speak, Voice Agent at /v1/agent/converse, and text intelligence at /v1/read.

Deepgram model availability is at parity with our EU endpoint, so the speech-to-text and text-to-speech models teams already run on Deepgram are available in Australia without changes.

Voice Agent is the workload where residency matters most. A real-time, two-way voice agent streams customer audio continuously, which places the question of where that audio is processed at the center of any security review. Running the agent on the Australia endpoint keeps Deepgram's speech-to-text and text-to-speech onshore. The agent's LLM step runs on the model provider you select or provide, and that provider determines where the reasoning is processed. Confirm the provider's residency and processing guarantees independently.

How to Use the Australia Endpoint

Set the base URL to the Australia endpoint in your existing client. The rest of your code stays the same.

Voice Agent connections use agent.au.deepgram.com. Both endpoints route all customer payloads through Australian infrastructure.

Built for Regulated Industries

No other major voice AI provider offers a fully sovereign, managed endpoint in Australia. Some providers store data in-region but run inference elsewhere, so processing can still cross borders. Others offer an in-country option only through infrastructure the customer has to deploy and operate. Deepgram performs both processing and storage in-country, fully managed, with no infrastructure for the customer to run.

That distinction matters most in healthcare, financial services, legal technology, and government-adjacent sectors, where an onshore guarantee separates a deployment that passes review from one that stalls. Deepgram holds SOC 2 Type I and Type II certifications, and the Australia endpoint extends that compliance posture with in-country processing and storage.

Start Building in Australia Today

The Australia endpoint is live now and available to every Deepgram customer.

To move a workload to Australia, update your base URL to api.au.deepgram.com, or contact your account team to plan the transition.

The Australia endpoint is part of a broader expansion. Over the past year, Deepgram has extended where voice AI runs, from Dedicated deployments to our EU endpoint and now Australia, while continuing to expand the languages our models support. The goal is consistent: Deepgram should run where your business runs, in the language your customers speak. Australia is the next step, and more regions will follow.

UpdateListen: On-the-Fly Listen Configuration

You can now update the Listen configuration during a conversation without restarting the session. Send an UpdateListen message to tune:

• eot_threshold — end-of-turn confidence threshold
• eager_eot_threshold — eager end-of-turn confidence threshold
• eot_timeout_ms — hard timeout for turn completion
• keyterms — keyword boost list
• language_hints — language bias for multilingual models

The payload nests tunable fields under listen.provider, matching the shape used in the Settings message. The provider identity (type, version, model) is required and must match the current session.

UpdateListen is a partial update — omitted tunable fields keep their current value, except language_hints which resets to empty when omitted. Always re-send language_hints if you want to preserve language biasing.

The server responds with a ListenUpdated acknowledgement once the changes are applied.

Model changes (e.g., switching from flux-general-en to flux-general-multi) are not supported with UpdateListen — this is on our roadmap.

For details, see the UpdateListen documentation.

Deepgram Self-Hosted June 2026 Release (260611)

Container Images (release 260611)

quay.io/deepgram/self-hosted-api:release-260611

Equivalent image to:

quay.io/deepgram/self-hosted-api:1.191.0-1

quay.io/deepgram/self-hosted-engine:release-260611

Equivalent image to:

quay.io/deepgram/self-hosted-engine:3.118.0-1

Minimum required NVIDIA driver version: >=570.172.08

quay.io/deepgram/self-hosted-license-proxy:release-260611

Equivalent image to:

quay.io/deepgram/self-hosted-license-proxy:1.10.1-1

quay.io/deepgram/self-hosted-billing:release-260611

Equivalent image to:

quay.io/deepgram/self-hosted-billing:1.13.0

Action Required: Engine Container GPU Environment Variables

The Engine container change previewed in the May 28, 2026 release has shipped in this release. The Engine container now requires two environment variables to access the GPU:

NVIDIA_VISIBLE_DEVICES=all

NVIDIA_DRIVER_CAPABILITIES=compute,utility

If they are not set, the Engine container will fail to start after you upgrade to release-260611. Follow the step for your deployment method before pulling the release-260611 Engine image:

Official Helm chart (deepgram-self-hosted): Upgrade to chart version 0.37.0 or later. The chart sets both variables on the Engine pod automatically whenever a GPU is requested, so no manual change is needed. If you pin an older chart version, bump it as part of adopting this release.

Deepgram-provided Docker or Podman Compose files: Pull the latest files from deepgram/self-hosted-resources. They already set both variables on the Engine service.

Your own deployment manifests: Add both variables to the Engine container’s environment. For example, in a Docker or Podman Compose file:

services:
  engine:
    image: quay.io/deepgram/self-hosted-engine:release-260611
    runtime: nvidia
    environment:
      NVIDIA_VISIBLE_DEVICES: "all"
      NVIDIA_DRIVER_CAPABILITIES: "compute,utility"

Or, for a Kubernetes Engine container spec:

env:
- name: NVIDIA_VISIBLE_DEVICES
  value: "all"
- name: NVIDIA_DRIVER_CAPABILITIES
  value: "compute,utility"

After setting the variables, upgrade your image tags to release-260611 and restart the Engine. Confirm it reaches a healthy state (for example, GET /v1/status returns 200) before routing production traffic.

This Release Contains The Following Changes

Persian Profanity Filtering — profanity_filter=true now masks recognized profanity in Persian (fa) transcripts. See Profanity Filtering for the supported language list and usage.

English Redaction on Flux Streaming — redact now applies to English transcripts on the Flux streaming endpoint (/v2/listen).

Streaming Diarization Model Selection — a new diarize_model parameter selects the diarization model on streaming requests; accepted values are v1 and latest, and setting it enables diarization (no separate diarize=true required). See Diarization for details.

Number Formatting Improvements — number formatting now covers Simplified Mandarin (zh), Cantonese (zh-HK), and Bulgarian (bg). Across languages, ordinals written as numerals format more consistently, and indefinite articles (“a”/“an”) format as digits in quantity contexts.

Text-to-Speech Output Transcoding — /v1/speak now supports optional output transcoding to additional audio formats.

Aura-2 Numeric Pronunciation Fix — corrects a pronunciation issue on all-numeric inputs.

Voice Agent Third-Party Provider Reliability — improves reliability of ElevenLabs streaming and Cartesia cancellation handling for self-hosted Voice Agent.

General Improvements — Keeps our software up-to-date.

Accurate speaker attribution is essential for turning conversations into usable data. Whether you're analyzing contact center calls, generating clinical documentation, or building voice AI applications, understanding who said what is just as important as understanding what was said.

Today, we're introducing Batch Diarization V2, a major upgrade to speaker labeling for pre-recorded audio. Diarization V2 improves speaker attribution accuracy, reduces the speaker labeling errors that make transcripts difficult to use, and was preferred 3.3X more often in side-by-side human evaluation.

TL;DR

• New batch diarization model available today
• Preferred 3.3X in human evaluation
• Improved speaker attribution accuracy across Voice Agent, Contact Center, and Medical audio and more
• Available via the new diarize_model parameter
• No breaking changes and no price changes

Why Speaker Attribution Matters

Diarization determines who spoke when in a conversation. When speaker labels are incorrect, downstream workflows break down.

In contact centers, inaccurate speaker attribution can impact QA review, coaching, and analytics. In healthcare, it can result in clinician comments being attributed to patients (or vice versa), creating errors in medical documentation.

In each case, the value of the transcript depends on accurately identifying the speaker behind every utterance.

Diarization V2 was built to improve speaker attribution across real-world audio and reduce the types of errors that matter most to customers.

What's New in Diarization V2

Diarization V2 introduces a new architecture that includes:

• Expanded training data
• A new speaker embedding model
• Improved segmentation and clustering

The result is more accurate speaker attribution, better turn boundaries, and fewer cases where speakers are incorrectly merged or split.

Performance Improvements Across Real-World Audio

We evaluated Diarization V2 against our existing V1 diarization model across multiple production-oriented workloads. Below are representative results from three common use cases: Voice Agent, Contact Center, and Medical audio.

We measure performance using Confusion Error Rate (CER), which represents the percentage of speech time attributed to the wrong speaker. Lower CER indicates more accurate speaker labeling.

Across all three use cases, Diarization V2 consistently reduces speaker attribution errors compared to V1, with particularly strong improvements on the most challenging audio. Similar improvements were observed across broader evaluations.

Human Evaluators Preferred Diarization V2

Benchmark metrics are important, but we also wanted to understand how the outputs were perceived in human testing.

We compared V1 and V2 outputs side by side and asked evaluators which they preferred.

Across 158 human evaluation votes:

• 63.3% preferred V2
• 19.0% preferred V1
• 17.7% reported no preference

Overall, evaluators preferred Diarization V2 more than 3.3X as often as V1.

How to Use Diarization V2

Diarization V2 is available through the new diarize_model parameter.

The new parameter gives customers explicit control over which diarization model version they use, while allowing existing integrations to continue using V1 unchanged.

Use diarize_model=latest to automatically receive the newest generally available diarization model. You can also explicitly select a version: diarize_model=v2 or diarize_model=v1.

Version Options

• latest — Always uses the newest GA diarization model
• v2 — Diarization V2
• v1 — Existing diarization model

Existing customers using diarize=true will continue using V1 with no behavior changes.

To enable V2, update your requests to use diarize_model=latest or diarize_model=v2.

Availability and Compatibility

Diarization V2 is available today across Deepgram's batch Speech-to-Text offerings, including:

• Nova-1
• Nova-2
• Nova-3
• Base and Enhanced models
• Supports all languages including multilingual audio

Supported in:

• Self-hosted deployments
• Deepgram SDKs
• US and EU deployments

All existing batch features continue to work unchanged, including smart formatting, redaction, word-level timestamps, keyterm prompting, language detection, and Audio Intelligence.

There are no pricing changes.

Get Started Today

• Read the documentation
• Try it in the Playground
• Sign up for a free account

Have feedback or questions? Reach us in GitHub discussions or contact our team.

Deepgram Self-Hosted May 2026 Release (260528)

Container Images (release 260528)

quay.io/deepgram/self-hosted-api:release-260528

Equivalent image to:

quay.io/deepgram/self-hosted-api:1.188.1

quay.io/deepgram/self-hosted-engine:release-260528

Equivalent image to:

quay.io/deepgram/self-hosted-engine:3.117.0

Minimum required NVIDIA driver version:

=570.172.08

quay.io/deepgram/self-hosted-license-proxy:release-260528

Equivalent image to:

quay.io/deepgram/self-hosted-license-proxy:1.10.1

quay.io/deepgram/self-hosted-billing:release-260528

Equivalent image to:

quay.io/deepgram/self-hosted-billing:1.13.0

Preparation for a future Engine container change

The official Helm chart (0.37.0 and later) and the Docker and Podman compose files in deepgram/self-hosted-resources now set NVIDIA_VISIBLE_DEVICES=all and NVIDIA_DRIVER_CAPABILITIES=compute,utility on the Engine container. These env vars are no-ops with the release-260528 Engine image but are required for an upcoming Engine container refactor; deployments that adopt them now will not need a configuration change when that refactor ships. If you maintain your own deployment manifests, adding these env vars to the Engine container is safe to do at any time.

This Release Contains The Following Changes

Profanity Filtering for STT Multilingual — profanity_filter=true now masks recognized profanity in STT multilingual transcripts (language=multi). See Profanity Filtering for the supported language list and usage.

Improved Nova-3 Korean Word Spacing — Fixes an issue where Nova-3 Korean transcripts (ko, ko-KR) were sometimes missing spaces between words. Transcripts now better reflect proper Korean spacing.

General Improvements — Keeps our software up-to-date.

How Deepgram Voice Agent API and NVIDIA Nemotron deliver a sub-700 ms median end-to-end voice agent that can run inside your VPC or on-prem.

Architecture, measured latency, and a 60-second playground walkthrough.

Deepgram Voice Agent API powered by NVIDIA Nemotron.
This post covers the architecture, the latency numbers we measured, and how to try the stack in under a minute.

The most valuable voice agent use cases live inside environments that often cannot send conversations to a public API. Hospitals running patient intake agents, banks deploying wealth advisors, and federal agencies processing claims all share the same constraint: audio and language-model reasoning have to stay inside their on-prem network, private clouds, or VPCs. For a decade, the most regulated industries have been the ones with the most to gain from voice AI but the least able to adopt it. This post is about the stack that addresses the challenge.

For these teams, the bottleneck has been the deployment pattern rather than the quality of the models. Deepgram solves that. Deepgram provides a voice agent stack where all layers can run on a single infrastructure inside the customer environment. The layers include speech-to-text (STT) or Automatic Speech Recognition (ASR), LLM, text-to-speech (TTS), and the orchestration that connects them into a unified pipeline.

The Deepgram Voice Agent API connects all the layers supported by STT, LLM, and TTS models from multiple providers. For LLM reasoning, Voice Agent API supports both frontier APIs and leading open-source models including NVIDIA Nemotron, as the featured LLM option. Nemotron is NVIDIA's family of open models spanning speech, reasoning, and other modalities. This post focuses on the reasoning models (Nemotron 3 Nano and Nemotron 3 Super), delivered as NVIDIA NIM and optimized for NVIDIA GPUs. NVIDIA Nemotron enables the flexible deployment of Deepgram Voice Agent APIs, on cloud, customer VPCs, on-premise, or on a hybrid configuration. The rest of this post covers what we built, what we measured, and how a developer can try the stack in under a minute.

What it previously took to build a voice agent

Building from raw APIs requires integrating separate components and building conversational logic from scratch.

Voice agent pipelines commonly start with audio coming in from a telephony provider, flowing through a streaming STT model, and passing to an LLM API for reasoning and response generation before the response is converted back to audio via a TTS provider. Between each model, teams must maintain their own application layer (with websocket setup, audio capture, UI state, authentication, connection health, and user management) and middleware layer (with database management, request routing, streaming coordination, prompt assembly, interruption detection, and concurrency handling). Each component is a code path that the team must write, test, and maintain before a single customer conversation can occur.

This pattern has kept production voice agents expensive to build and brittle to operate, and it is the pattern that the Deepgram Voice Agent API is built to replace.

The Voice Agent API lets developers define agent behavior once and manage a single connection. Audio goes in, audio comes out, and the API automatically handles turn-taking, barge-in, LLM streaming, and the BYO-LLM orchestration layer for you.

One example of implementation

With the Voice Agent API absorbing the orchestration layer, the Deepgram stack puts three models in a single pipeline. Voice Agent API supports multiple STT, TTS, and LLM providers. Below is one viable combination of STT, LLM, and TTS models.

• Deepgram Nova 3 (STT) handles streaming speech-to-text. It is tuned for real-world audio at scale, including telephony, short conversational turns, and the low-latency streaming that voice agents need for good interruption handling. In our self-hosted measurements, and inside a customer VPC environment, Nova 3 delivered P50 first-token latency of 198 ms on NVIDIA GPUs inside an AWS VPC.
• NVIDIA Nemotron LLM models handle the reasoning. Nemotron 3 Nano is already live in the Deepgram playground, and Nemotron 3 Super (120B total, 12B active via LatentMoE) is the production reasoning model we benchmarked for this post. Both models are packaged as NVIDIA NIM, GPU-optimized containers that make deploying Nemotron repeatable across environments. For our current cloud deployment, we access Nemotron 3 Super through Amazon Bedrock (fully managed serverless endpoints) via the InvokeModel and Converse APIs.
• Deepgram Aura 2 closes the loop with text-to-speech, delivering natural prosody and streaming audio so the first words reach the user before the LLM has even finished composing its response.
• The Deepgram Voice Agent API sits across all three models. It owns turn-taking, barge-in and interruption, LLM streaming, and a BYO-LLM architecture that currently supports more than 20 providers. It is the layer that replaces the application and middleware layers in the DIY picture above.

Latency: what we measured

A voice agent only feels conversational when the gap between the user finishing their turn and the agent beginning its response is minimal.

The latency metrics below were measured with Deepgram Voice Agent components running in an AWS VPC and NVIDIA Nemotron 3 Super served through Amazon Bedrock (serverless) using the nvidia.nemotron-super-3-120b model ID. The agent delivered a median end-to-end latency under 700 ms and 90th percentile latency less than one second, with audio and application logic all running inside the customer VPC.

Metrics:

• P50 (median): STT 198 ms, LLM 322 ms, TTS 89 ms, End-to-End Latency 660 ms (Natural conversational range)
• P90: STT 235 ms, LLM 427 ms, TTS 411 ms, End-to-End Latency 979 ms (Sub-1s latency at 90th percentile)
• P95: STT 294 ms, LLM 481 ms, TTS 662 ms, End-to-End Latency 1,282 ms (Bedrock cold-start variance)

Details:

• Nova 3 delivered less than 200 ms median latency, with P95 staying under 300 ms. The steady tail latency is key for natural interruption handling in live conversations.
• End-to-end median latency was under 700 ms, with P90 under one second. Both numbers sit inside the range for natural conversations.
• Tail variance comes from the current Bedrock-served configuration. We expect customer-managed NIM deployment inside the customer's own cluster will shorten the P95 meaningfully once that path is generally available.
• Effective latency should be less than the end-to-end latency. The Voice Agent API streams LLM output directly into TTS, so the user hears speech starting well before the LLM has finished generating the full response.

Deepgram is continuing to push the boundaries of Voice Agent performance with NVIDIA Nemotron, with a focus on reducing latency while preserving the accuracy and consistency that production deployments demand.

Try it online

Open playground.deepgram.com, select Voice Agent, and pick Nemotron 3 Nano from the Think model dropdown. You will be on the stack in less than 60 seconds. The playground is free to use and requires no onboarding or credit card.

Pay attention to a few things while you talk to the agent:

• How fast the agent responds to your first word.
• What happens when you interrupt the agent mid-sentence (barge-in).
• How natural the Aura 2 TTS voice of the agent sounds over a long reply.
• How the agent handles context across a multi-turn conversation.

For more details, check out Deepgram's Voice Agent Getting Started guide and the open-source Voice Agent template apps. The templates include working reference clients that plug directly into the snippet above.

The deployment paths

Most customers ask for local deployment of Deepgram for latency, data security, and governance reasons. Two paths are or will be available for customers to leverage Nemotron and the Voice Agent stack.

Path 1 (Available today).

Deepgram Voice Agent components run inside the customer's AWS VPC and call Nemotron 3 Super through Amazon Bedrock (serverless). This is a deployable pattern for any AWS-native team today. It keeps audio and application logic inside the customer network, while inference runs on a Bedrock-managed endpoint that Amazon operates.

Path 2 (Coming soon).

Customer-managed NIM, where Deepgram Voice Agent components run alongside a customer-operated NIM microservice inside the customer's own Kubernetes cluster, bare metal, or datacenter, without a dependency on any cloud marketplace or APIs. This pattern is technically possible but not yet customer-ready, and it is the direction we are building toward together with NVIDIA and with enterprise infrastructure partners.

Deploy it yourself

For teams ready to ship, Deepgram's self-hosted documentation covers the full deployment pattern: Voice Agent components running inside a VPC alongside Bedrock serverless with manifest examples, container image sources, environment variables, GPU sizing notes, and NIM model identifiers for Nemotron 3 Nano and Nemotron 3 Super.

What is next: fine-tuning Nemotron for voice

Voice agent workloads have distinctive characteristics. Turns are short, interruption sensitivity is high, and latency budgets are tight.

Deepgram has started exploratory fine-tuning work on Nemotron reasoning models to produce voice-agent-optimized variants using NVIDIA NeMo. Early experiments have been promising. This complements NVIDIA's existing voice-domain models in the Nemotron family, like Nemotron ASR and Magpie TTS, extending the family's coverage of conversational voice workloads end-to-end. Deepgram's goal is to customize Nemotron LLM for conversational voice: smaller, faster, and cheaper than general-purpose reasoning models, with quality held to what enterprise deployments need.

Three doors, one stack

For enterprise teams with data residency or compliance requirements, the Deepgram solutions team will run a full architecture review covering architecture, compliance, and data residency requirements. Start at deepgram.com/contact-us.

1. Try it in a minute.
   Visit playground.deepgram.com and look for Nemotron 3 Nano in the Think model dropdown.

2. Read the self-hosted documentation.
   It covers the full setup for running the joint stack inside your own VPC, datacenter, or Kubernetes cluster.

3. Plan an enterprise rollout.
   The Deepgram solutions team can walk enterprise customers through the self-hosted architecture and the NIM deployment pattern end to end.

No longer do you need to struggle between cloud convenience and on-prem control for voice agents. With Deepgram and NVIDIA Nemotron models, enterprise teams can have both with best-in-class latency.