상태: 초안 (2026-10-06), 실측 글입니다. 아래 숫자는 필자가 직접 잰 값입니다. 한 턴의 첫 소리까지의 시간은 부품별 실측에서 계산한 추정이며 처음부터 끝까지 이어서 재지는 않았습니다. 대부분의 측정은 합성 음성과 한 가지 대화 프롬프트로 했으므로 실제 사용자 환경과 다를 수 있습니다. 4-3절은 사람이 읽은 음성(공개 음성 말뭉치)으로 음성인식을 다시 잰 값이고, 비원어민 영어도 포함합니다. 작성 규칙: 실측 데이터가 기본이고, 못 잰 것은 「미실측」으로 표시합니다.
1. 무엇을 왜 쟀는가
19편에서 오픈소스 후보를 조사했지만 값은 모두 문서 기준이었습니다. 외국어 말하기 연습에 「말로 주고받는」 기능을 넣으려면 다음 세 부품의 지연을 직접 알아야 합니다.
- 음성인식(ASR): 학습자의 말을 글자로 바꿉니다.
- 대화 LLM: 받아 적은 말에 답을 만듭니다.
- 음성합성(TTS): 답을 소리로 읽습니다.
세 부품을 모두 한국어, 일본어, 중국어, 영어로 쟀고, 오픈 모델 두 쌍(Qwen3-ASR 과 Nemotron 3.5 ASR, VoxCPM2 와 Magpie TTS)을 같은 입력으로 비교했습니다.
2. 환경과 방법
| 항목 | 값 |
|---|---|
| 서버 | GPU 서버 두 대. 24GB급 소비자용 GPU(드라이버 570 계열)와 8GB급 노트북 GPU(드라이버 595 계열) |
| 음성합성 | VoxCPM2(24GB급 GPU), Magpie TTS Multilingual 357M(8GB급 GPU) |
| 음성인식 | Qwen3-ASR-1.7B 와 단어 시각 정렬기(24GB급 GPU), Nemotron 3.5 ASR Streaming 0.6B(8GB급 GPU) |
| 대화 LLM | Gemma 4 12B 구글 공식 QAT 4비트(GGUF 7.0GB), llama.cpp 서버(--parallel 2, 문맥 4096), 생각 모드 끔(24GB급 GPU) |
| 방법 | 서버를 임시 컨테이너에 띄우고 문장 3종(짧음, 중간, 김) × 4개 언어를 3회씩(LLM 은 5회) 요청해 중앙값을 냄 |
| 안전장치 | 컨테이너 메모리 한도, 호스트 가용 메모리가 기준 아래로 내려가면 측정 중단 |
두 모델 쌍을 서로 다른 GPU 에서 쟀기 때문에 속도의 직접 비교는 신중해야 합니다(메모리 사용량과 정확도는 GPU 와 무관하게 비교할 수 있습니다). 음성합성은 서버가 알려 주는 합성 시간과 오디오 길이로 실시간 계수(합성 시간 ÷ 오디오 길이) 를 계산했고, 1 보다 작으면 재생보다 빨리 만든다는 뜻입니다.
3. 음성합성(TTS) 결과
3-1. VoxCPM2
따뜻한 상태(모델이 실려 있고 목소리가 이미 설계된 상태)에서 3회 중앙값입니다.
| 언어 | 글자 수 | 오디오(초) | 합성 시간(초) | 실시간 계수 |
|---|---|---|---|---|
| 영어 | 39 / 80 / 179 | 2.08 / 4.00 / 9.60 | 1.21 / 2.11 / 4.77 | 0.572 / 0.526 / 0.496 |
| 일본어 | 17 / 36 / 67 | 3.04 / 5.28 / 9.12 | 1.69 / 2.78 / 4.56 | 0.556 / 0.519 / 0.500 |
| 중국어 | 18 / 23 / 54 | 3.84 / 4.96 / 10.72 | 2.05 / 2.59 / 5.31 | 0.531 / 0.522 / 0.496 |
| 한국어 | 20 / 38 / 67 | 3.84 / 6.88 / 12.64 | 2.06 / 3.50 / 6.25 | 0.536 / 0.509 / 0.494 |
- 언어와 상관없이 합성 시간은 오디오 길이의 약 절반입니다. 열두 조합 전체의 실시간 계수가 0.494~0.582(중앙값 0.521)였고, 같은 조합 3회의 흩어짐은 0.02 이내였습니다.
- 짧은 문장일수록 계수가 조금 큽니다. 언어별로 세 점에 직선을 맞추면 합성 시간은 오디오 길이 × 약 0.47 + 약 0.23초(전체 열두 점 기준 0.475 × 길이 + 0.23초)로 네 언어가 거의 같은 식입니다. 문장마다 드는 약 0.23초의 고정 비용이 짧은 문장에서 비율을 키우는 것으로 해석할 수 있으나, 그 비용이 무엇인지는 확인하지 못했습니다.
- 서버가 문장 전체를 합성한 뒤 한 번에 돌려주는 방식입니다. 첫 소리까지의 시간이 곧 문장의 합성 시간이며, 2~4초 분량의 짧은 문장이면 1.2~2.1초입니다. 대화에서는 이 값이 첫 소리를 늦추는 가장 큰 요인입니다.
- 목소리를 처음 만드는 호출은 3~3.5초가 더 듭니다. 서버는 목소리를 한 번 설계해 저장하고 이후에는 복제하므로 처음 한 번만 해당합니다.
- GPU 메모리를 약 6,600~6,900MiB 씁니다. 모델 적재는 첫 기동에서 가중치 내려받기를 포함해 385초가 걸렸습니다.
3-2. Magpie TTS Multilingual 357M
같은 문장으로 쟀습니다(8GB급 노트북 GPU, 3회 중앙값).
| 언어 | 합성 시간(초) | 오디오(초) | 실시간 계수 | 음성인식 되받기 글자 오류율 |
|---|---|---|---|---|
| 영어 | 1.23 / 2.10 / 4.59 | 2.69 / 4.55 / 9.33 | 0.458 / 0.462 / 0.495 | 0% / 0% / 0% |
| 일본어 | 1.41 / 2.71 / 4.80 | 3.11 / 5.76 / 9.66 | 0.448 / 0.471 / 0.496 | 13% / 12% / 0%(표기 차이) |
| 중국어 | 1.87 / 2.29 / 5.09 | 3.85 / 4.92 / 10.26 | 0.452 / 0.465 / 0.499 | 0% / 10% / 6% |
| 한국어 | 0.27 / 0.37 / 0.99 | 0.51 / 0.65 / 2.18(비정상) | 0.455~0.588 | 100%(결과 없음) |
- GPU 메모리를 약 750MiB 만 더 씁니다. 모델 두 개를 올린 뒤의 사용량 5,832MiB 에서 음성인식 모델만 올린 5,078MiB 를 뺀 값입니다. VoxCPM2 의 약 9분의 1 입니다.
- 정상 동작하는 세 언어의 실시간 계수는 중앙값 0.466(0.447~0.541)입니다. VoxCPM2 와 비슷하거나 약간 낮은 값이지만 서로 다른 GPU 에서 쟀습니다.
- 한국어는 이 구성에서 그대로는 쓸 수 없었습니다(원인과 우회는 아래). 20~67자 문장이 0.4~4.3초짜리 소리로 끝났고(정상이면 4~13초), 음성인식에 넣으면 빈 결과가 나왔습니다. 모델 카드는 한국어를 지원한다고 적고 있고, 같은 호출 방식이 영어, 일본어, 중국어에서는 정상이었습니다. 체크포인트 버전은 원인이 아니었습니다. 모델 카드에서 한국어가 추가됐다고 적은 v2607 을 포함해 main, v2607, v2602 세 체크포인트를 같은 환경에서 모두 시험했는데 한국어 문장 3개가 모두 0.4~2.1초(v2602 는 0.7~1.3초)짜리 소리로 끝났고 되받아 적으면 글자 오류율이 1.00 이었으며, 텍스트 정규화를 켜도 같았습니다. 같은 호출로 영어는 세 버전 모두 정상이었습니다(글자 오류율 0.00~0.07). 정규화를 처음 켠 호출은 4.5~4.7초가 걸렸습니다. 원인은 언어 코드에서 토크나이저를 고르는 코드였습니다. v2607 체크포인트는
korean_chartokenizer를 포함한 토크나이저 15개를 갖고 있지만(한국어 문장을 이것으로 토큰화하면 40토큰), NeMo 3.0.0 의get_tokenizer_for_language는 언어 코드를 내부 표(LANGUAGE_TOKENIZER_MAP)에서 찾고 없으면english_phoneme으로 떨어지는데, 이 표에 한국어가 없어ko,ko-KR,korean이 모두 영어 음소 토크나이저로 갔습니다. 한국어 문장이 영어 음소 토크나이저를 거치면 5토큰만 남아(대부분 알 수 없는 글자) 모델이 0.4~0.8초 만에 끝낸 것입니다(영어, 일본어, 중국어는 각자의 토크나이저로 매핑되어 정상). 한국어에korean_chartokenizer를 쓰도록 이 함수만 바꾸면(우회) 세 문장이 3.5, 5.8, 3.8초의 소리로 나왔고 음성인식으로 되받아 쓴 글자 오류율이 0.00, 0.00, 0.05 였습니다. 합성은 1.6, 2.7, 1.7초(실시간 계수 약 0.46~0.47)로 다른 언어와 같은 수준이었습니다. 즉 모델과 체크포인트는 한국어를 지원하고, 이 NeMo 코드 버전이 한국어를 연결하지 않은 것입니다. 더 새로운 NeMo 에서 이 매핑이 추가됐는지는 확인하지 못했습니다(미확인). 이 시험은 문장 3개이고, 목소리 품질은 평가하지 않았습니다. - 되받기 오류율은 합성 음성을 다른 음성인식 모델(Nemotron 3.5 ASR)에 넣어 원문과 비교한 값으로, 합성 품질의 대략적인 지표일 뿐입니다.
4. 음성인식(ASR) 결과
앞의 합성이 만든 12개 음성(2~13초)을 언어를 지정해 받아 적게 했습니다.
4-1. Qwen3-ASR-1.7B
| 언어 | 오디오(초) | 추론 시간(초) | 실시간 계수 | 글자 오류율 |
|---|---|---|---|---|
| 영어 | 2.1 / 3.8 / 9.6 | 0.16 / 0.26 / 0.52 | 0.054~0.077 | 0% / 0% / 0% |
| 일본어 | 3.0 / 5.3 / 8.6 | 0.15 / 0.31 / 0.51 | 0.049~0.059 | 0% / 15% / 0% |
| 중국어 | 3.8 / 4.8 / 10.7 | 0.16 / 0.25 / 0.49 | 0.042~0.052 | 0% / 0% / 0% |
| 한국어 | 4.2 / 7.4 / 12.6 | 0.22 / 0.42 / 0.62 | 0.049~0.057 | 0% / 0% / 0% |
- 받아 적는 데 0.15~0.6초, 실시간 계수 0.04~0.08 입니다. 합성(약 0.5)보다 약 10배 빨라서 병목이 아닙니다.
- 언어를 지정하지 않고 자동 감지로 돌려도 12개 모두 맞았습니다.
- GPU 메모리는 모델을 올리면 약 5,756MiB 늘었습니다. 첫 요청은 174초(가중치 내려받기와 적재 포함)가 걸렸고 추론만으로는 6초였습니다.
4-2. Nemotron 3.5 ASR Streaming 0.6B
같은 12개 음성(8GB급 노트북 GPU, 언어를 로케일로 지정, 파일 전체를 한 번에 받아 적는 방식)입니다.
| 항목 | 값 |
|---|---|
| 추론 시간 | 파일당 0.23~0.30초(실시간 계수 0.023~0.112, 중앙값 0.050) |
| 평균 글자 오류율 | 3.9% (Qwen3-ASR 은 일본어 표기 차이를 빼면 0%) |
| 자동 감지 | 12개 모두 맞음(결과에 <ko-KR> 같은 언어 표지가 붙음) |
| GPU 메모리 | 모델 적재 후 약 5,078MiB(모델 외에 실행 환경 몫이 포함된 값) |
| 적재 시간 | 가중치가 내려받아진 뒤 약 31초 |
- 받아 적은 오류의 예는
How was를How is,三明治를三名制,집 근처에를집근처에로 적은 것입니다. 이 12개에서는 Qwen3-ASR 이 더 정확했고, Nemotron 은 더 작고 스트리밍을 위해 만든 모델입니다. - 청크 크기별 정확도. 모델은 한 번에 처리하는 청크를 80, 160, 320, 560, 1,120ms 중에서 고를 수 있습니다. 같은 12개로 평균 오류율을 재면 80ms 4.3%, 160ms 4.0%, 320ms 3.9%, 560ms 3.9% 로 거의 같았고, 1,120ms 에서만 11.3% 로 튀었습니다. 한 개 음성이 빈 결과로 나온 탓인데(두 번 재도 같음) 사람 음성으로 다시 재니 한국어에서는 청크 크기와 관계없이 빈 결과가 0개였습니다(4-3절). 이 12개 합성 표본에서만 나타난 현상으로 보입니다. 이 값은 파일 전체에 해당 설정을 적용한 근사이고 실제 스트리밍 지연은 재지 않았습니다.
4-3. 사람 음성으로 다시 잰 값: 원어민 읽기와 비원어민 영어
위 12개는 합성 음성이라 사람의 발음과 억양이 들어 있지 않습니다. 공개 음성 말뭉치로 Nemotron 3.5 ASR 을 다시 재었습니다. FLEURS(사람이 읽은 문장)에서 언어마다 30문장, speechocean762(중국어 화자가 읽은 영어에 발음 평가 점수가 붙은 말뭉치)에서 100문장이고, 파일 전체를 한 번에 받아 적는 방식, 기본 청크 1,120ms, 8GB급 노트북 GPU 입니다.
| 데이터 | 지표 | 평균 | 중앙값 | 빈 결과 | 중앙 추론 시간 |
|---|---|---|---|---|---|
| FLEURS 한국어 | 글자 오류율 | 5.8% | 3.6% | 0 | 0.296초 |
| FLEURS 일본어 | 글자 오류율 | 14.7% | 14.7% | 0 | 0.296초 |
| FLEURS 중국어 | 글자 오류율 | 18.2% | 14.6% | 0 | 0.305초 |
| FLEURS 영어 | 단어 오류율 | 10.0% | 5.7% | 0 | 0.291초 |
| speechocean762 비원어민 영어 | 단어 오류율 | 38.8% | 25.0% | 12/100 | 0.248초 |
비원어민 영어를 발음 평가 총점(0~10)으로 나누면 오류율이 크게 갈렸습니다.
| 총점 구간 | 문장 수 | 단어 오류율(평균) | 중앙값 |
|---|---|---|---|
| 6 미만 | 15 | 80.4% | 100.0% |
| 6 이상 8 미만 | 31 | 54.0% | 60.0% |
| 8 이상 | 54 | 18.4% | 11.8% |
- 한국어 글자 오류율 5.8%는 모델 카드의 FLEURS 값(7.12%, 1.12초 청크)과 같은 수준입니다. 표본이 30문장이라 작지만 카드와 어긋나지 않았습니다. 위 합성 음성 12개의 평균 3.9%(네 언어 평균)는 사람 음성의 값(한국어 5.8%, 일본어 14.7%, 중국어 18.2%)보다 낮아 낙관적이었음이 확인됩니다.
- **비원어민 영어에서는 오류율이 원어민 읽기(10.0%)의 약 4배(38.8%)**였고, 발음 점수가 낮을수록 급격히 나빠졌습니다. 총점 6 미만에서는 중앙값이 100%, 즉 대부분 받아 적지 못했습니다. 언어 학습 앱에서 초급 학습자의 말은 인식이 가장 어렵고 그만큼 피드백이 필요한 말이라는 뜻입니다. 사람이 평가한 점수는 말뭉치가 준 것입니다.
- 청크가 작을수록 정확도가 떨어지지만 한국어에서는 거의 같았습니다.
| 청크 | 한국어 CER | 영어 WER | 비원어민 영어 WER (빈 결과) |
|---|---|---|---|
| 1,120ms | 5.8% | 10.0% | 38.8% (12) |
| 560ms | 5.9% | 10.5% | 39.7% (7) |
| 320ms | 5.6% | 12.6% | 42.1% (9) |
| 160ms | 6.2% | 13.3% | 44.8% (10) |
| 80ms | 6.1% | 13.5% | 44.7% (8) |
영어와 비원어민 영어는 1,120ms 에서 80ms 로 줄이면 오류율이 3~6%p 늘었습니다. 한국어는 5.6~6.2% 로 차이가 거의 없었고, 모델 카드의 한국어 값(7.12~7.70%)도 평평합니다. 빈 결과는 1,120ms 에서만 나오지 않았고(비원어민 영어는 오히려 1,120ms 에서 12개로 가장 많음), 위 합성 표본의 1,120ms 이상 현상은 재현되지 않았습니다.
- 한계. 한국어, 일본어, 중국어, 영어 각 30문장과 비원어민 영어 100문장의 읽기 음성입니다. 대화체나 잡음, 한국인 학습자의 영어와 다른 모국어 화자의 한국어는 재지 않았습니다(미실측). 파일 전체에 청크 설정을 적용한 근사이며 실제 스트리밍 확정 지연이 아닙니다.
5. 대화 LLM 결과: Gemma 4 12B 4비트
학습자 수준(CEFR A2)에 맞춰 「한두 문장으로 답하고 쉬운 질문 하나로 끝내라」는 지시와 「어제 카페에서 책을 읽었다」는 사용자 발화를 네 언어로 보내고, 언어마다 5회 스트리밍으로 받았습니다. 첫 토큰은 요청을 보낸 뒤 첫 글자가 올 때까지, 첫 문장은 첫 문장 부호가 나올 때까지(음성합성을 시작할 수 있는 시점)입니다.
| 언어 | 첫 토큰(초, 중앙값 / 범위) | 첫 문장 끝(초) | 답변 토큰 | 생성 속도(tok/s) |
|---|---|---|---|---|
| 영어 | 0.074 / 0.068~0.080 | 0.203 | 21 | 85.7 |
| 일본어 | 0.074 / 0.067~0.119 | 0.100 | 23 | 85.6 |
| 중국어 | 0.067 / 0.054~0.127 | 0.129 | 13 | 84.2 |
| 한국어 | 0.076 / 0.074~0.129 | 0.160 | 27 | 85.6 |
- 첫 토큰이 0.07초 안팎, 생성은 약 85 tok/s 입니다. 서버 자체 계측과도 일치했습니다(입력 67토큰 처리 95.7ms, 즉 700 tok/s, 생성 토큰당 11.6ms).
- 첫 문장이 끝나는 데 0.1~0.2초입니다. 영어가 가장 오래 걸린 이유는 첫 문장이 길어서입니다.
- 지시를 지켰습니다. 20회 모두 한두 문장으로 답하고 끝에 질문을 붙였습니다. 한국어 예:
와, 정말 좋았겠네요! 카페에서 책 읽는 건 정말 행복한 일이에요. 어떤 책을 읽었어요?품질(교정, 수준 맞춤)은 사람이 평가해야 하며 이 측정은 속도만 객관적입니다. - 동시 요청이 늘면 첫 토큰이 늦어집니다. 일본어 프롬프트를 동시에 보냈을 때 2개는 0.206초, 4개는 중앙값 0.352초, 최대 0.552초였습니다(서버가 동시 2개만 처리하도록 두었으므로 나머지는 대기).
- GPU 메모리는 약 8,450MiB 를 썼습니다. 모델 적재는 가중치 내려받기를 포함해 145초였습니다.
생각 모드가 응답을 통째로 비웠습니다. 처음 측정에서 20회 모두 답이 비어 있었습니다. 원응답을 보니 content 는 빈 문자열이고 reasoning_content 에 Role: Friendly conversation partner for a Japanese learner... Constraint 1: ... 같은 영어 분석이 쌓이다가, 80토큰 예산이 생각만으로 끝난 것이었습니다. 이 모델이 llama.cpp 의 대화 템플릿에서 기본으로 생각부터 하기 때문이며, 서버 옵션(--reasoning-budget 0)과 요청 옵션(chat_template_kwargs: {enable_thinking: false})으로 끄자 정상이 되었습니다. 음성 대화에서는 생각 모드를 반드시 꺼야 합니다. 켜 두면 첫 소리가 몇 초씩 늦어지고, 예산이 짧으면 답이 아예 나오지 않습니다.
6. 측정에서 발견한 문제
6-1. 일본어: 소리는 맞는데 표기가 달라 점수가 깎인다
일본어 중간 문장에서 오류율 15% 가 나왔는데, 소리를 틀린 것이 아니었습니다.
| 문장 | |
|---|---|
| 원문 | 私はたいてい七時に起きて**、簡単な朝ご飯を食べて、**地下鉄で会社に行きます。 |
| 인식 | 私は大抵7時に起きて簡単な朝ご飯を食べて地下鉄で会社に行きます。 |
たいてい 대 大抵, 七 대 7, 쉼표 유무는 같은 말의 다른 표기입니다. 발음 연습 서비스가 인식 결과를 목표 문장과 문자 유사도로 견주면, 학습자가 완벽하게 말해도 이런 표기 차이로 점수가 깎일 수 있습니다. 중국어의 숫자(七 대 7)도 같은 문제가 예상됩니다. 고치는 방법은 비교 전에 숫자와 표기를 정규화하거나, 글자가 아니라 발음(읽기) 기준으로 비교하는 것입니다.
6-2. 배포된 서버가 최신 코드보다 낡을 수 있다
한 환경에서 중국어 합성이 404 Not Found 로 실패했습니다. 서버 코드의 중국어 목소리 프리셋이 새 코드에는 있지만 배포된 이미지에는 없었기 때문입니다. 새 기능이 동작하지 않을 때는 코드가 아니라 배포된 이미지의 버전을 먼저 확인해야 합니다.
6-3. GPU 서버마다 드라이버 버전이 다르면 이미지가 안 뜬다
CUDA 13 용으로 빌드된 vLLM 이미지가 드라이버 570 계열(CUDA 12.8 까지)에서 Error 804: forward compatibility was attempted on non supported HW 로 기동하지 못했습니다. 같은 이미지가 드라이버 595 계열에서는 돌아갑니다. CUDA 13.x 는 드라이버 580 이상을 요구합니다. 여러 서버를 함께 쓸 때는 드라이버 버전을 서버마다 확인하고 이미지의 CUDA 버전과 맞추어야 합니다. 이 글의 LLM 측정은 CUDA 12 용 이미지(llama.cpp)로 구성했습니다.
6-4. 측정 도구에서 부딪힌 함정
| 증상 | 원인 | 해결 |
|---|---|---|
| 측정 스크립트가 실행되지 않고 서버만 떠 있음 | kubectl run --overrides 가 명령줄의 --command 를 덮어씀 |
서버는 기본 명령에 맡기고 측정 코드는 kubectl exec 로 실행 |
합성 시간이 nan |
응답 헤더 이름이 소문자인데 대소문자를 구분해 읽음 | 헤더 키를 소문자로 정규화 |
컨테이너가 OOMKilled |
모델을 적재하는 순간의 최대 메모리가 한도보다 큼 | 한도를 올림. 한도가 컨테이너 안에서만 작동해 서버는 영향 없음 |
컨테이너가 Pending |
노드의 메모리 요청 합이 이미 높아 요청 6Gi 인 컨테이너 둘이 함께 못 뜸 | 측정을 순서대로 실행 |
kubectl run -i 가 1분 만에 포기 |
이미지를 받는 시간이 기본 대기(1분)를 넘음 | --pod-running-timeout 을 늘림 |
| LLM 응답이 전부 비어 있음 | 생각 모드가 기본으로 켜져 80토큰을 생각에 다 씀 | 서버와 요청 양쪽에서 생각을 끔 |
| 되받기 오류율이 1 보다 큼 | 22,050Hz 를 16,000Hz 로 바꾸는 비율을 잘못 써서(8,000Hz) 음성이 2배속이 됨 | 비율을 320/441 로 수정. 도구가 아니라 시험 코드의 버그였음 |
라이브러리가 언어를 받지 못함(Unknown prompt key: 'None') |
파일 경로로 부르면 임시 입력 목록에 언어 필드가 없는 버전 문제 | 임시 목록에 언어를 써 넣는 우회 코드를 덧씌움(임시 방편) |
여기서 가장 큰 교훈은 되받기 오류율의 사례입니다. 측정 코드의 버그가 모델의 결함처럼 보일 수 있습니다. 오류율이 1 을 넘는 값이 나오면 모델이 아니라 입력(표본 추출 비율, 길이, 언어 지정)을 먼저 의심해야 합니다.
7. 한 턴의 지연은 얼마인가
사용자가 말을 마친 시점부터 첫 소리가 나기까지는 이런 합입니다.
(말 끝 판단) + ASR + LLM 첫 문장 + TTS 첫 문장 + 전송
부품별 실측을 문장 길이로 이어 붙인 계산한 추정입니다(처음부터 끝까지 이어서 재지는 않았습니다). LLM 의 첫 문장은 위 측정에서 실제로 나온 문장이고, TTS 시간은 3-1 의 식(합성 ≈ 0.475 × 오디오 길이 + 0.23초)에 그 문장의 읽는 길이를 넣었습니다.
| 언어 | ASR(3~7초 발화) | LLM 첫 문장 끝 | 첫 문장 예 | TTS(계산) | 합계 |
|---|---|---|---|---|---|
| 일본어 | 0.15~0.3 | 0.10 | いいですね！(약 1.1초 분량) |
약 0.75 | 약 1.0~1.2초 |
| 중국어 | 0.16~0.25 | 0.13 | 听起来很舒服！(약 1.5초) |
약 0.94 | 약 1.2~1.3초 |
| 한국어 | 0.22~0.4 | 0.16 | 와, 정말 좋았겠네요!(약 2.1초) |
약 1.2 | 약 1.6~1.8초 |
| 영어 | 0.16~0.26 | 0.20 | That sounds like a very relaxing way…!(약 3.2초) |
약 1.75 | 약 2.1~2.2초 |
이 표에는 말 끝 판단(VAD)과 네트워크 전송이 들어 있지 않습니다. 말 끝을 0.3~0.5초에 판단한다고 가정하면 그만큼 더해집니다(가정값, 미실측). 공개된 값의 범위는 NVIDIA 블루프린트 권고 200~500ms, Pipecat 기본 0.2초, LiveKit 0.5초(스트리밍 턴 감지기 0.3초), OpenAI 예시 500ms 이므로 가정은 이 범위 안에 있습니다. 같은 문서의 목표 지연(발화 종료부터 응답 시작)은 600~1,500ms 이고, 대형 GPU 와 스트리밍 TTS 를 쓴 블루프린트의 서버 종단 지연은 0.86~0.93초(벤더 수치)입니다. 이 글의 한국어 합계에 말 끝 판단을 더한 약 1.9~2.3초가 더 큰 것은 이 글의 TTS 가 스트리밍이 아니기 때문으로 읽힙니다(공개 사례의 TTS 첫 소리까지는 0.07~0.37초). 학습자는 머뭇거림이 많아 짧은 판단이 말을 자를 수 있는데, 이를 다룬 연구는 열 수 있는 자료에서 찾지 못했습니다(미확인).
- 병목은 음성합성입니다. 한 턴의 시간 중 약 60~85% 가 TTS 이고, ASR(0.2초)과 LLM(0.1~0.2초)은 합쳐도 0.5초 안팎입니다.
- 첫 문장을 짧게 끊으면 첫 소리가 빨라집니다. 일본어와 중국어의 답이 짧은 맞장구로 시작하면 합계가 1초 남짓으로 내려갑니다. 영어는 첫 문장이 길어서 가장 느렸습니다. 대화 지시문에서 「짧은 맞장구로 시작하라」고 하면 같은 효과를 얻을 수 있다고 생각하지만 시험하지 않았습니다.
- ChatGPT 수준(말이 끝나고 1초 안팎)에 근접합니다. 일본어와 중국어는 이미 그 범위이고, 영어와 한국어는 첫 문장을 더 쪼개거나 스트리밍 합성(이 서버는 쓰지 않음)을 쓰면 줄일 수 있습니다. 이것은 추론이고 시험하지 않았습니다.
8. 면접에서 나올 만한 질문
- 실시간 음성 대화의 지연은 어떻게 분해하는가? 말 끝 판단, ASR, LLM 첫 문장, TTS 첫 소리, 전송으로 나눠 단계마다 잰다. 여기서는 ASR 이 0.2초, LLM 첫 문장이 0.1~0.2초, TTS 가 0.7~1.8초여서 TTS 가 병목이었다.
- 실시간 계수가 0.5 면 충분한가? 재생보다 빠르다는 뜻이라 긴 답변을 이어 붙일 때는 충분하지만, 첫 소리까지의 시간은 별개다. 비스트리밍 서버는 문장을 다 합성해야 첫 소리가 난다.
- 음성인식 결과로 학습자를 채점할 때 주의할 점은? 소리가 맞아도 표기가 다르게 나온다(
たいてい대大抵). 비교 전에 정규화하거나 읽기 기준으로 비교한다. - GPU 하나를 모델 둘이 나눠 쓸 때 무엇을 보는가? VRAM 여유(TTS 약 6,900MiB, ASR 약 5,800MiB 를 각각 더함)와 호스트 RAM, 서버의 드라이버 버전(이미지의 CUDA 버전과 맞는가).
- 측정값이 상식에 어긋날 때(오류율 > 1) 어떻게 하는가? 모델보다 측정 코드를 먼저 의심한다. 입력 변환(표본 추출 비율)의 오류가 흔한 원인이다.
확인하지 못한 것
- 대화 품질. 속도는 쟀지만, 학습자 수준 맞춤, 오류 교정, 자연스러움 같은 품질은 사람이 평가해야 하고 하지 않았습니다. 프롬프트도 한 가지(어제 카페에서 책을 읽었다)만 시험했습니다.
- 한국인 학습자의 영어와 다른 모국어 화자의 한국어 음성, 잡음 환경에서의 인식 정확도. 비원어민 영어는 중국어 화자가 읽은 영어 말뭉치로만 쟀습니다(4-3절).
- 부품을 이어 붙인 실제 종단 지연. 7절은 계산한 추정입니다.
- 서로 다른 GPU 에서 잰 값의 직접 비교. 두 모델 쌍을 다른 GPU 에서 쟀습니다.
- Magpie TTS 한국어 소리의 품질(원인은 NeMo 코드의 토크나이저 매핑 누락으로 확인, 4절. 우회하면 문장 3개가 되받기 글자 오류율 0~5%). Nemotron ASR 의 1.12초 청크 빈 결과는 사람 음성에서 재현되지 않았습니다.
- 동시 대화 수(TTS, ASR). 한 번에 하나만 재었습니다(LLM 은 동시 2~4개를 쟀음). TTS 서버는 요청을 하나씩 처리하는 잠금을 쥐고 있어 동시에 두 대화를 받으면 줄을 서는 것으로 보이지만 재지 않았습니다. 이 TTS 서버는 실제로 서비스 중인 것이라 부하 시험을 걸지 않았고, 공개 수치로 방향만 확인했습니다. NVIDIA 블로그(벤더 수치, NIM 서빙)의 Magpie TTS 값은 동시 스트림을 1개에서 64개로 늘릴 때 첫 소리까지 시간이 B200 에서 32에서 239ms, H100 에서 47에서 275ms, A100 에서 79에서 395ms, 소형 시스템(DGX Spark)에서 53에서 962ms 로 늘었다고 적습니다(각각 약 7.5배, 5.9배, 5.0배, 18배). 같은 부하에서 작은 하드웨어일수록 동시성이 지연을 더 크게 키운다는 방향의 근거이며, 이 글의 환경으로 옮길 수 있는 값은 아닙니다.
- 스트리밍 합성의 첫 소리 지연과 스트리밍 음성인식의 실제 확정 지연. 이 측정은 스트리밍 경로를 쓰지 않았습니다.
- 말 끝 판단(VAD)과 끼어들기. 위 7절의 공개 범위만 확인했고 직접 재지 않았습니다.
참고 자료
- 19편(오픈소스 조사), 21편(원리), 17편(DCGM 지표, 드라이버 버전)
확인한 버전과 날짜
2026-10-06 기준. voxcpm 2.0.3, Qwen3-ASR-1.7B, Qwen3-ForcedAligner-0.6B, Nemotron 3.5 ASR Streaming 0.6B, Magpie TTS Multilingual 357M, NeMo 3.0.0, Gemma 4 12B QAT q4_0, llama.cpp b11429.