How Deepgram optimized voice AI at scale with AWS Trainium

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Deepgram은 Nova-3를 AWS Trainium2로 이식하고 커널과 Rust 런타임을 최적화해, 오프라인 배치 추론에서 기존 컴퓨팅 옵션보다 달러당 오디오 처리량을 11~70% 높였다.

📌 핵심 요약

• Deepgram은 음성 인식·음성 합성·음성 에이전트 모델로 개발자 200,000명 이상과 조직 1,400곳에 서비스를 제공하며, 연간 1,000조 단위의 오디오 토큰을 처리한다. 대규모 배치 처리의 비용 효율을 높이기 위해 AWS FDE 팀과 Nova-3 음성 인식 모델을 Trainium2로 이식했다.
• 표준 PyTorch 코드에서 TorchNeuron과 torch.compile을 사용해 인코더·디코더를 별도의 정적 형태 그래프로 컴파일했다. 컴파일 경로에서는 CPU 폴백이 발견되지 않았으며, CPU 대비 계층별 출력 일관성과 종단 간 단어 오류율(WER)이 Deepgram의 기준값·목표를 유지하는지 확인했다.
• NKILib 커널을 적용한 뒤 Neuron Explorer와 Neuron Agentic Development(NAD)로 병목을 분석하고 커널을 조정했다. 배치 크기 96에서 FFN 지연 시간은 참조 커널의 절반으로 줄고 depthwise conv1d는 1.5배 빨라졌으며, 새 conv2d 커널은 배치 크기 32 초과의 컴파일 제약을 해소하고 32 이하에서 합성곱 모듈을 최대 50배 가속했다.
• Trainium2의 논리 코어 구성을 LNC1으로 바꿔 장치당 모델 복제본 8개를 실행하고, Rust와 C 계층으로 Python·PyTorch가 없는 서빙 경로를 구축했다. 테스트한 모든 배치 크기에서 참조 토큰 시퀀스를 정확히 재현했으며, 처리량이 최대인 배치 크기에서도 Python 다중 프로세스 기준보다 처리량이 7.5% 높았다.
• 단일 Trainium2 장치를 사용하는 Amazon EC2 trn2.3xlarge 구성은 오프라인·처리량 중심 배치 작업에서 기존 컴퓨팅 옵션보다 달러당 오디오를 11~70% 더 처리했다. 비교에는 평가 당시의 인스턴스 가격을 사용했으며, 처리량은 절대값 대신 기준 구성 대비 상대 향상으로 제시했다. 이러한 이점은 Amazon SageMaker AI의 자체 VPC에서 Deepgram 모델을 운영하는 고객에게도 확장될 수 있다.

🧩 주요 포인트

1. 네이티브 PyTorch 이식과 정확도 검증 → Trainium2에서 전체 모델 연산을 실행하면서 Nova-3의 출력 품질을 유지하는 최적화 기반 확보.
2. 커널별 메모리 접근·연산 엔진·컴파일 제약 개선과 Rust 호출 경로 최적화 → 가속기 내부와 호스트 양쪽의 병목을 줄여 배치 추론 처리량 향상.
3. 오프라인 배치에서 달러당 처리량 11~70% 향상 → 동일한 인프라 예산으로 더 많은 오디오를 처리할 가능성을 보여주지만, 결과 해석에는 평가 당시 가격과 워크로드 조건 반영 필요.

🧠 상세 정리

1. 대규모 음성 AI 서비스에서 추론 효율이 중요한 이유

Deepgram의 모델은 음성 인식, 음성 합성, 음성 에이전트에 걸쳐 있으며, 개발자 200,000명 이상과 조직 1,400곳을 위해 연간 1,000조 단위의 오디오 토큰을 처리한다. 고객은 Deepgram API를 이용하거나 Amazon SageMaker AI를 포함한 자체 환경에서 모델을 실행한다. 이 규모에서는 가속기 사용 시간을 얼마나 효율적으로 활용하느냐가 주어진 인프라 예산으로 처리할 수 있는 오디오 양을 결정하며, 특히 대용량 배치 작업이 예산에 큰 부담을 준다. Deepgram은 추론 효율을 개선하기 위해 AWS와 협력해 Nova-3 음성 인식 모델을 AWS Trainium2로 이식했다. 대상은 컨택 센터 분석과 의료 전사 같은 오프라인 배치 작업으로, 최적화의 중심은 처리량과 비용 효율이었다.

2. 표준 PyTorch에서 시작한 이식과 정확도 검증

Deepgram은 Nova-3를 표준 PyTorch 코드로 제공했고, AWS Forward Deployed Engineering(FDE) 팀과 수개월에 걸쳐 Trainium2에 맞게 이식하고 조정했다. 개발팀은 Neuron Compiler의 네이티브 PyTorch 통합인 TorchNeuron을 사용했으며, 먼저 즉시 실행 모드에서 어떤 연산이 CPU로 폴백하는지 확인한 뒤 torch.compile로 컴파일했다. 컴파일된 실행 경로에서는 모든 모델 연산이 Trainium2에서 실행됐고 CPU 폴백은 발견되지 않았다. 인코더와 디코더는 각각 별도의 정적 형태 그래프로 컴파일했으며, 최적화 전반에서 CPU 대비 계층별 출력 일관성과 종단 간 단어 오류율(WER)을 함께 점검했다. WER은 Deepgram의 참조값과 목표에 부합해야 했고, 이후 성능 개선도 이 정확도 조건을 유지하는 범위에서 진행됐다.

3. NKILib 적용과 프로파일링 중심의 반복 최적화

정상 동작하는 기준 구성을 확보한 뒤, 개발팀은 여러 계층을 공개 NKI Library(NKILib)의 융합 커널로 교체하며 최적화를 시작했다. 이 라이브러리는 Neuron Kernel Interface(NKI)로 작성된 참조 커널 모음이며, 적용 대상에는 QKV 투영, 순방향 신경망(FFN), depthwise 1D 합성곱 등이 포함됐다. 작업은 커널 적용, 워크로드 프로파일링, 기존 커널 조정 또는 새 커널 작성의 순환 구조로 진행됐다. Neuron Explorer가 실행 프로파일을 제공하고, Neuron Agentic Development(NAD)의 프로파일링·커널 작성 기능이 원인 분석과 대체 커널 개발을 도왔다. 성능 평가는 오프라인 추론의 처리량을 중심으로 진행했으며, 배치 크기 1~128을 탐색해 처리량이 최대가 되는 크기를 찾고 결과는 기준 구성 대비 상대 향상으로 제시했다.

4. FFN과 depthwise conv1d의 서로 다른 병목 해소

FFN 참조 커널은 토큰 타일마다 전체 투영 가중치를 오프칩 메모리에서 다시 읽어, 토큰 수가 늘수록 메모리 대역폭이 처리량을 제한했다. 직접 조정한 커널은 각 가중치 타일을 한 번 읽어 여러 토큰 타일에서 재사용하고, 가중치 읽기와 온칩 연산을 겹쳐 수행하도록 바꿨다. 그 결과 배치 크기 96에서 FFN 지연 시간은 참조 커널의 절반으로 줄었다. 반면 실험 단계의 NKILib depthwise conv1d 커널은 연산을 암묵적 일반 행렬곱(GEMM)으로 구성해 Tensor Engine 활용률이 낮았다. 이를 Vector Engine의 브로드캐스트 곱셈·누산 루프로 다시 작성하자 엔진 활용률이 최대에 도달했고, 더 낮은 이론상 최대 처리량을 상쇄해 같은 배치 크기에서 참조 커널보다 1.5배 빨라졌다.

5. conv2d 커널로 컴파일 제약과 연산 성능 개선

Nova-3의 conv2d 계층은 배치 크기가 32를 넘으면 모델을 하나의 그래프로 컴파일하지 못하게 하는 병목을 만들었다. 이는 개별 연산 속도뿐 아니라 더 큰 배치를 사용할 수 있는지에도 영향을 주는 제약이었다. NKILib에는 해당 conv2d 커널이 없었기 때문에 개발팀은 NKI로 커널을 처음부터 작성하고, 프로파일 결과를 반영해 여러 차례 수정했다. 이 작업으로 배치 크기 32를 초과하는 구성을 사용할 수 있게 됐고, 배치 크기 32 이하에서는 합성곱 모듈에서 최대 50배의 속도 향상을 얻었다. 이 수치는 전체 Nova-3 모델의 가속률이 아니라 합성곱 모듈의 결과이며, 전체 워크로드의 처리량·비용 효율 결과와 구분해 해석해야 한다.

6. 장치당 복제본 8개를 활용하는 데이터 병렬 구성

Trainium2 장치 하나에는 물리 NeuronCore 8개가 있으며, 기본 LNC2 구성에서는 물리 코어 두 개를 묶은 논리 NeuronCore 4개로 노출된다. Nova-3 모델 인스턴스 하나는 물리 코어 하나에 충분히 들어가기 때문에, 개발팀은 논리 코어당 물리 코어 수를 하나로 줄인 LNC1 구성을 선택했다. 이를 통해 장치당 모델 복제본 8개를 배치하는 DP8 데이터 병렬 구성이 가능해졌고, 입력을 동시에 처리해 장치당 처리량을 높였다. 각 복제본에는 스레드 하나가 배정되며, 런타임은 공유 작업 훔치기 큐를 통해 작업을 분배한다. 최종 구성은 단일 Trainium2 장치를 사용하는 Amazon EC2 trn2.3xlarge 인스턴스에서 복제본 8개를 실행하며, Deepgram의 오프라인 배치 처리량을 높이는 기반이 됐다.

7. Rust 런타임으로 호스트 측 호출 병목 완화

Deepgram의 운영 서빙 스택은 Rust로 작성돼 있어, 모델을 컴파일하는 것에 더해 Python이나 PyTorch 없이 실행 경로를 구성해야 했다. 개발팀은 Rust가 공유 작업 훔치기 큐로 복제본을 조율하고, C 계층이 사전 컴파일된 Neuron Executable File Format(NEFF) 파일을 Neuron Runtime API인 libnrt로 직접 불러와 실행하는 경량 런타임을 만들었다. 이 런타임은 기존 서빙 구조에 통합됐고, 테스트한 모든 배치 크기에서 참조 토큰 시퀀스를 정확히 재현했다. Python 다중 프로세스 방식과 비교하면 인터프리터 오버헤드를 제거하며, 다중 스레드 방식과 비교하면 전역 인터프리터 잠금(GIL)에 따른 호출 직렬화도 완화한다. Nova-3는 오디오 청크마다 작은 디코더 호출을 연속 수행하므로 작은 배치에서 효과가 가장 컸으며, 처리량이 최대인 배치에서도 Python 다중 프로세스 기준보다 7.5% 높은 처리량을 기록했다.

8. 비용 효율 결과와 적용 범위

최종 가격 대비 성능은 달러당 처리한 오디오 양으로 측정했으며, 단일 장치 Trainium2 구성은 Deepgram이 기존에 사용하던 컴퓨팅 옵션보다 11~70% 더 많은 오디오를 처리했다. 이 비교는 평가 당시의 인스턴스 가격과 오프라인·처리량 중심 배치 워크로드를 기준으로 하며, 원문은 절대 오디오 처리량이나 비교 대상별 상세 수치를 제시하지 않는다. 글은 이 효율 개선이 Deepgram의 확장과 모델 개선, 고객 가격 인하를 뒷받침하고, Amazon SageMaker AI의 자체 VPC에서 모델을 운영하는 고객에게도 이점이 확장될 수 있다고 설명한다. Deepgram과 AWS는 해당 환경의 설치 편의성, 안정성, 관측 가능성도 계속 개선하고 있다. 유사한 이식을 위한 자료로는 AWS Neuron 문서, NKI 가이드와 샘플 저장소, Neuron 개발 도구 문서, EC2 Trn2 인스턴스 정보가 안내되며, 이식 범위 검토를 위한 AWS FDE 문의도 제시된다.

🧾 핵심 주장 / 시사점

• 이번 성과는 Trainium2로의 모델 이식에 더해 커널의 메모리 재사용, 연산 엔진 선택, 컴파일 제약, 호스트 호출 비용을 함께 개선한 결과다. 각 계층의 개선 수치를 전체 모델의 성능 향상으로 그대로 해석해서는 안 된다.
• Nova-3처럼 작은 디코더 호출을 반복하는 모델에서는 가속기 연산 외에 호스트의 작업 전달도 처리량을 제한한다. Rust 런타임의 효과가 작은 배치에서 가장 크고 최적 배치에서도 남았다는 결과가 이를 보여준다.
• 달러당 오디오 처리량 11~70% 향상은 오프라인 배치 추론에서의 경제성을 보여준다. 평가 당시 가격과 워크로드에 따른 결과이므로, 원문만으로 다른 실행 조건에서 같은 개선 폭을 확정할 수는 없다.

✅ 액션 아이템

• Nova-3의 Trainium2 이식 검토에 계층별 출력 일관성과 WER 기준 유지 조건을 반영.
• 배치 추론 최적화에서 커널의 메모리 접근·연산 엔진·컴파일 제약과 Rust 런타임의 호스트 호출 비용을 함께 검토.
• 달러당 오디오 처리량 11~70% 향상을 평가 당시 인스턴스 가격과 오프라인 배치 조건에 맞춰 해석.

❓ 열린 질문

• 달러당 오디오 처리량 11~70% 향상의 비교 대상인 기존 컴퓨팅 옵션은 구체적으로 무엇이며, 옵션별 개선 폭은 얼마인가?
• Nova-3의 정확도 검증에 사용한 WER 기준값·목표와 최종 측정값은 각각 얼마인가?
• Amazon SageMaker AI의 자체 VPC에서 Deepgram 모델을 운영할 때도 달러당 오디오 처리량 11~70% 향상이 재현되는가?