Toolspublished

Heidi Cuts ASR GPUs From 16 to 4 With CUDA MPS, Holding Sub-Second Latency

The production design turns spare capacity in small speech-inference requests into concurrency, but it depends on workload-specific scheduling and protections against MPS failure modes.

By 3 min read
Heidi Cuts ASR GPUs From 16 to 4 With CUDA MPS, Holding Sub-Second Latency

Listen to this story

The audio brief

About 1:32
0:001:32
Read transcript
Heidi Health, AWS, and NVIDIA say they cut the GPU footprint for production speech recognition from 16 instances to four, while keeping transcription under one second. The key was not a new model, but better use of capacity that was already sitting idle. Their automatic speech recognition workload runs Parakeet TDT zero point six B V2 on L40S GPUs. Each request typically uses only 15 to 20 percent of a GPU. Under default CUDA time-slicing, requests take turns, so the spare capacity cannot be used efficiently. With CUDA MPS, multiple model processes share a GPU context and run concurrently. The team reports 92.1 requests per second per GPU, compared with about 62 under time-slicing at acceptable latency. The serving path batches transcription requests for up to 50 milliseconds, with preferred batches of four, eight, or 16. A FastAPI gateway sends audio over gRPC to Triton Inference Server. The encoder uses ONNX Runtime with TensorRT, while the decoder stays in PyTorch CUDA; calling the model directly removes about 50 milliseconds of framework overhead per request. But this is a tuned production recipe, not a universal guarantee. Unseen CUDA-graph shapes can crash sibling MPS instances, so the system pre-warms expected shapes, falls back to eager execution, and serializes startup. The constraint to watch is whether those workload-specific protections hold as traffic and model shapes vary.

Story brief

3 key points

A production ASR deployment from Heidi Health, AWS, and NVIDIA shows how GPU sharing can improve accelerator economics without changing the model. CUDA MPS raised reported throughput on L40S hardware to 92.1 requests per second per GPU, while keeping transcription below one second and reducing the required instances from 16 to four. The result depends on Parakeet TDT 0.6B V2, carefully tuned batching, pre-warmed...

  1. 01

    Each ASR request uses roughly 15%–20% of an L40S, leaving capacity that default sequential time-slicing cannot share efficiently.

  2. 02

    Triton batches transcription requests for up to 50 milliseconds, with preferred batch sizes of four, eight, or 16.

  3. 03

    The stack combines TensorRT-optimized ONNX Runtime for the Conformer encoder with PyTorch CUDA for the TDT decoder.

AWS, Nvidia and Heidi Health have published a speech-recognition serving design that cut Heidi’s required GPU instances from 16 to four while maintaining sub-second transcription latency. The collaborators report 92.1 requests per second per GPU, up from roughly 62 under default time-slicing at acceptable latency.

The target is automatic speech recognition, or ASR, where strict latency targets can strand capacity on expensive accelerators. A request for the Parakeet TDT 0.6B V2 model typically consumes only about 15% to 20% of an Nvidia L40S GPU’s compute capacity. Default CUDA time-slicing gives processes sequential access, leaving that unused capacity unavailable to another request.

One GPU context, several active requests

The deployment uses Amazon EC2 g6e.4xlarge and g7e.4xlarge instances with 48 GB Nvidia L40S GPUs. A FastAPI gateway decodes audio and sends it over gRPC to Triton Inference Server, which dispatches requests across MPS-partitioned model instances.

For transcription, Triton can hold requests for up to 50 milliseconds to assemble preferred batches of four, eight or 16. For diarization, sequence batching preserves each recording’s state as clients send 15-second audio chunks. Each Triton instance maps to an MPS partition, connecting request batching with GPU sharing.

Diagram comparing sequential GPU time-slicing across 16 GPU instances with CUDA MPS running four concurrent 25% partitions across four instances.
The published architecture contrasts idle capacity under time-slicing with concurrent MPS execution. Source: aws.amazon.com.

The stack also splits model execution: the compute-heavy Conformer encoder uses ONNX Runtime with TensorRT, while the TDT decoder remains in PyTorch CUDA. The collaborators say directly calling the model’s forward method, instead of its higher-level transcription method, removes about 50 milliseconds of framework overhead per request.

MPS introduces a specific operational risk. The collaborators say a decoder trying to recapture a CUDA graph for an unseen tensor shape can be corrupted by sibling MPS instances and crash. Their implementation pre-warms expected shapes, uses eager execution outside that range, and serializes loading so several 600-million-parameter processes do not exhaust GPU memory at startup.

Heidi says it processes more than 2.4 million clinical consultations weekly across 190 countries, placing the configuration in a production setting. The reported result is built around Parakeet TDT 0.6B V2, L40S GPUs and a sub-second target. MPS trades the hard physical isolation of MIG for shared-context concurrent execution, so deployments with different models or isolation needs face a distinct choice.

The accompanying open-source repository supports either an all-in-one container or a two-container Docker Compose deployment, separating GPU inference from the CPU gateway. Its value is a reproducible serving recipe, not a universal capacity promise.

Sources

  1. aws.amazon.comReduce ASR inference costs by 75% with NVIDIA MPS on Amazon EC2 | Amazon Web Services