MOSS-TTS-Local-Transformer-v1.5, 로컬 서빙에 최적화된 48kHz 스트리밍 TTS 모델 (feat. SGLang-Omni)

9bow · 6월 22, 2026, 7:30오전

MOSS-TTS-Local-Transformer-v1.5 소개

음성 합성(Text-to-Speech, TTS) 모델을 데모 스크립트로 한 번 돌려보는 것과, 그 모델을 여러 사용자의 요청이 동시에 쏟아지는 환경에서 안정적으로 서빙(serving) 하는 것은 전혀 다른 난이도의 문제입니다. OpenMOSS 팀과 MOSI.AI가 공개한 MOSS-TTS-Local-Transformer-v1.5는 48kHz 스테레오 음성을 생성하고, 제로샷 음성 복제(zero-shot voice cloning), 장문 합성, 다국어 생성, 길이 제어, 네이티브 스트리밍을 모두 지원하는 오픈 모델입니다. 모델 자체를 호출하는 것은 어렵지 않지만, 잘 서빙하는 것은 어렵습니다. 하나의 요청이 레퍼런스 오디오 인코딩, Qwen3-4B 자기회귀(Autoregressive, AR) 백본, 프레임마다 12개의 코드북을 순차적으로 샘플링하는 루프, 그리고 상태를 유지하는 코덱 디코더까지 여러 단계를 가로지르기 때문입니다.

이 글은 OpenMOSS, MOSI.AI, 그리고 SGLang-Omni 팀이 함께 작업한 MOSI.AI 기술 블로그를 정리한 것입니다. 핵심 메시지는 명확합니다. SGLang-Omni는 이 모델을 하나의 거대한 LLM 디코드 루프에 욱여넣는 대신, 전처리(preprocessing) → tts_engine → 보코더(vocoder) 의 3단계 파이프라인으로 매핑해서 서빙합니다. 글의 대부분은 바로 이 매핑에 관한 것입니다. 각 단계가 어디에 위치하는지, 어떤 부분이 모델 특화 훅(hook)을 필요로 했는지, 그리고 모델이 부하 상태로 돌아가기 시작했을 때 어떤 병목이 드러났는지를 다룹니다.

음성 모델 서빙의 어려움은 일반적인 텍스트 LLM 서빙과 결이 다릅니다. 일반 LLM 추론 엔진은 하나의 모델 루프를 반복하도록 설계되지만, TTS는 인코더와 백본, 보코더가 각기 다른 연산 특성과 메모리 패턴을 가지기 때문입니다. 같은 OpenMOSS 가족 중 CPU만으로 실시간 동작하는 초경량 모델은 MOSS-TTS-Nano: CPU만으로 실시간 동작하는 0.1B 파라미터 다국어 TTS 모델에서 다룬 바 있는데, 이번 v1.5는 정반대 지점, 즉 데이터센터급 GPU 서빙 효율 을 어떻게 끌어올리는지를 보여줍니다.

오디오 토크나이저와 LLM이 결합된 모델 구조

MOSS-TTS-Local-Transformer-v1.5는 MOSS-TTS v1.5 가족의 두 번째 플래그십 모델로, 오디오 토크나이저(Audio Tokenizer) + LLM 자기회귀 경로를 따릅니다. 더 무거운 오디오 코덱과 글로벌 트랜스포머(Global Transformer)와 로컬 트랜스포머(Local Transformer)를 잇는 생성 경로를 결합한 구조입니다. 직접 TTS, 이어 말하기(continuation), 제로샷 음성 복제, 길이 제어, [pause 3.2s] 같은 명시적 일시정지 마크업, 그리고 최대 10분 길이의 장문 생성을 지원합니다. 31개 주요 언어를 다루며(한국어 포함), 약 400만 시간의 다국어 음성으로 학습되었습니다.

오디오 경계에서 MOSS는 MOSS-Audio-Tokenizer-v2 를 사용합니다. 인코더와 디코더를 합쳐 약 20억(2B) 파라미터에 이르는 신경망 오디오 토크나이저로, 12.5Hz로 동작하며 0.125kbps에서 4kbps까지 가변 비트레이트 압축을 지원하고, 48kHz 스테레오 오디오를 복원하며, 잔차 벡터 양자화(Residual Vector Quantization, RVQ)로 음성을 표현합니다. RVQ는 SoundStream 계열의 뉴럴 코덱에서 널리 쓰이는 기법으로, 하나의 음성 프레임을 여러 단계(코드북)의 양자화 잔차로 점진적으로 표현해 적은 비트로도 높은 음질을 복원합니다.

생성 코어는 Qwen3-4B 백본 을 사용합니다(Qwen3 계열의 자기회귀 디코더로, 쿡북 기준 36개 레이어, hidden=2560, GQA 32/8 구성). 글로벌 트랜스포머가 프레임 단위로 시퀀스를 전진시키고, 각 프레임마다 한 개 레이어로 된 로컬 트랜스포머가 정지/계속(stop/continue) 결정을 내린 뒤 12개의 RVQ 코드북을 순서대로 샘플링합니다. 이때 샘플링한 코드를 다음 코드를 샘플링하기 전에 다시 피드백으로 넣어줍니다. 직전 버전인 MOSS-TTS-Local-Transformer-v1.0과 비교하면, 백본이 Qwen3-1.7B에서 Qwen3-4B로 커졌고 오디오 토크나이저가 v2로 교체되어 네이티브 48kHz 스테레오 출력이 가능해졌습니다.

서빙 관점에서 보이는 토큰 레이아웃은 [T, 13] 입니다. 하나의 텍스트/제어 채널과 12개의 오디오 코드북 채널로 이루어집니다. 텍스트 위치는 채널 0에 텍스트 토큰을, 나머지 채널에 오디오 패딩을 담습니다. 오디오 위치는 채널 0에 슬롯/제어 토큰을, 12개 오디오 코드북 각각에 RVQ 코드 하나씩을 담습니다. 바로 이 지점이 MOSS가 평범한 다음-토큰 예측 모델처럼 보이지 않는 첫 번째 자리입니다. 생성되는 모든 프레임이 스칼라 토큰 하나가 아니라 하나의 행(row) 이기 때문입니다. 이 "행 단위 생성"이라는 특성이 이후 모든 서빙 최적화의 출발점이 됩니다.

공개 모델 수준 평가셋에서의 성능은 다음과 같습니다. 이 수치는 오프라인 모델 지표이며, 뒤에 나오는 서빙 벤치마크와는 다른 평가 파이프라인을 사용했으므로 엔드투엔드 시스템 측정값으로 따로 읽어야 합니다.

벤치마크	WER (낮을수록 좋음)	SIM (높을수록 좋음)
Seed-TTS-Eval	5.10%	69.23%
CV3-Eval	7.48%	61.59%
MiniMax Multilingual	6.37%	75.31%
X Voice	20.48%	63.00%

참고로 MOSS-TTS-Local-Transformer-v1.5는 알리바바 클라우드의 PPU-ZW810 클러스터에서 수천 장 규모(thousand-card scale)로 학습되었습니다. 이 글은 학습이 아니라 서빙 측면에 집중합니다.

왜 MOSS는 다단계 서빙 런타임이 필요한가

표준 LLM 서빙 엔진은 하나의 반복되는 모델 루프를 중심으로 만들어집니다. 그런데 MOSS의 한 요청 안에는 성격이 전혀 다른 세 종류의 작업이 들어 있습니다.

전처리 및 레퍼런스 인코딩 (Preprocessing and reference encoding): 텍스트를 토큰화하고, 레퍼런스 오디오를 불러와 그 파형을 RVQ 코드로 인코딩합니다. 음성 복제를 위한 준비 단계입니다.
자기회귀 TTS 엔진 (Autoregressive TTS engine): Qwen3 백본과 로컬 트랜스포머가 [1, 13] 형태의 프레임 행을 생성합니다. 일반적인 백본 디코드와, 작지만 엄격하게 순차적인 코드북 루프가 섞여 있습니다.
스트리밍 보코더 (Streaming vocoder): 생성된 RVQ 행을 상태를 유지하는 MOSS 코덱 디코더가 파형 청크(chunk)로 디코딩합니다.

각 단계의 병목은 서로 다릅니다. 레퍼런스 인코딩은 커다란 뉴럴 코덱 인코더를 돌립니다. AR 생성은 평범한 백본 디코드에, 작지만 반드시 순차적으로 돌아야 하는 로컬 코드북 루프가 더해집니다. 보코더는 청크 사이에 스트리밍 상태를 보존해야 하는 상태형 디코더입니다. 시스템은 이 셋 중 한 단계의 배칭(batching)이나 메모리 동작이 다른 단계를 망가뜨리지 않도록 모두를 관리해야 합니다. 하나의 모델 루프만 가정하는 일반 LLM 엔진으로는 이 구조를 깔끔하게 담아내기 어렵습니다.

SGLang-Omni의 3단계 파이프라인 서빙

SGLang-Omni는 MOSS-TTS Local Transformer v1.5를 다음과 같은 3단계 파이프라인으로 서빙합니다.

preprocessing -> tts_engine -> vocoder

전처리 단계는 OpenAI 호환 요청을 파싱하고, 멀티채널 프롬프트를 준비하며, 음성 복제를 위해 레퍼런스 오디오를 인코딩합니다. tts_engine 단계는 OmniScheduler 위에서 동작하므로, MOSS는 모델 특화된 [T, 13] 행을 다루면서도 SGLang의 요청 배칭과 KV 캐시(KV-cache) 머신을 그대로 재사용할 수 있습니다. 마지막 보코더 단계는 생성된 행을 스트림으로 소비하여, 지속되는 코덱 스트리밍 세션에서 오디오 청크를 반환합니다.

여기서 재사용되는 부분은 런타임의 "형태"입니다. 단계 생명주기, 스케줄러 인터페이스, 단계 간 라우팅, 스트리밍 출력, 프로세스 배치, 단계 단위 자원 회계가 그것입니다. 반면 MOSS 특화 부분은 더 작고 명시적입니다. 멀티채널 프롬프트를 어떻게 구성하는가, 프레임 단위의 로컬 코드북 루프를 어떻게 돌리는가, MOSS 코덱을 스트리밍 디코더로 어떻게 연결하는가입니다. 즉 "공통 인프라는 SGLang이 제공하고, 모델이 진짜로 특별한 부분만 따로 끼워 넣는다" 는 설계입니다. 이 SGLang-Omni의 다단계 생성 모델 재설계 철학은 SGLang-Omni: Redesigning the Inference Framework for Multi-Stage Generative Models 문서에 더 자세히 설명되어 있습니다.

같은 옴니모달(Omni-Modality) 서빙 흐름은 vLLM 진영에서도 진행 중입니다. MOSS-TTS 시리즈는 vLLM팀의 vLLM-Omni에서도 지원되며, SGLang 자체의 내부 동작이 궁금하다면 Mini-SGLang: SGLang의 핵심을 담은 경량화 고성능 LLM 추론 프레임워크가 좋은 출발점입니다.

단계별 최적화: 프로파일링이 가리킨 곳을 고친다

파이프라인이 기능적으로 완성된 뒤, 프로파일링에서 반복 작업이나 실행(launch) 오버헤드가 드러난 단계들을 최적화했습니다. 전체 변경 사항은 아래 표로 정리됩니다. 각 변경은 SGLang-Omni 저장소의 풀 리퀘스트(PR)로 추적할 수 있습니다.

영역	변경	핵심 효과	출처
모델 서빙 베이스라인	MOSS Local 모델, 파이프라인, API 지원	3단계 서빙 경로 확립	#728
레퍼런스 인코딩	배치 인코딩, 콘텐츠 주소 기반 LRU 캐시, 단일 비행(single-flight) 중복 제거	재사용 화자에 대한 코덱 인코더 반복 작업 제거	#748, #778, #788
AR 엔진	디코드 상태 풀, 프레임 CUDA Graph 지원, GPU 네이티브 행 해시	디코드 상태를 안정된 GPU 주소에 유지, 프레임마다의 호스트 해싱 제거	#745
AR 엔진	프레임 실행 상태 풀링, 비동기 디코드 배관	실행 준비 오버헤드 감소, 디코드 스텝 소유권 문제 해결	#759, #758
AR 엔진	컴파일된 시드 샘플러	결정적 샘플링을 유지하면서 핫 샘플링 경로를 융합	#773
보코더	상태형 스트리밍 세션, 스트림 슬롯, 청크 합치기(coalesce) 스케줄링	요청 격리를 유지한 프레임 단위 오디오 스트리밍	#753
보코더	상태형 보코더 CUDA Graph	짧은 스트리밍 디코드 스텝 가속	#798
단계 간	명시적 코로케이션 메모리 예산	코덱과 AR 메모리 압박이 서로 간섭하지 않도록 방지	#810

레퍼런스 오디오 인코딩: 같은 화자를 두 번 인코딩하지 않기

음성 복제는 같은 화자를 여러 프롬프트에 걸쳐 재사용하는 경우가 많습니다. MOSS에서는 이것이 특히 중요합니다. AR 생성이 시작되기 전에 레퍼런스 인코딩이 커다란 코덱 인코더를 돌려야 하기 때문입니다.

SGLang-Omni는 배치 레퍼런스 인코딩과 콘텐츠 주소 기반 LRU 캐시를 결합합니다. 반복되는 레퍼런스는 파일 경로가 아니라 오디오 콘텐츠를 키로 삼으므로(xxHash 계열의 xxh3_64 해시 사용), 복사되거나 이름이 바뀐 파일이어도 같은 인코딩 결과를 재사용합니다. 단일 비행(single-flight) 경로는 같은 화자에 대한 동시 미스(miss)를 하나로 병합하여, 캐시가 비어 있을 때 동일한 코덱 인코드가 중복으로 실행되는 것을 막습니다.

2x H100, 동시성 16 환경의 SeedTTS 영어 평가에서 레퍼런스 캐시 용량을 256개에서 1024개로 늘리자 처리량(throughput)이 32.0% 향상되고 평균 지연 시간(latency)이 24.3% 감소했습니다. 인코딩된 코드 텐서는 매우 작아 메모리 비용은 크지 않았으며, 더 큰 캐시는 주로 활성 화자 작업 집합(working set)이 캐시에서 밀려나는 것을 막아 줍니다.

AR 엔진: 순차 루프를 CUDA Graph로 감싸기

MOSS의 AR 엔진은 두 단계의 연산을 가집니다. Qwen3 백본과, 로컬 트랜스포머의 프레임 디코드 루프입니다. SGLang-Omni는 둘 다 CUDA Graph로 캡처하지만, 구조와 소유권이 다르기 때문에 둘을 분리해서 둡니다.

백본 그래프는 인과적 LM 디코드(causal LM decode)를 위한 SGLang의 표준 CUDA Graph 경로를 사용합니다. MOSS 특화 프레임 그래프는 한 프레임 전체에 대한 로컬 트랜스포머 마이크로 루프, 즉 정지/계속 샘플링, 12개 코드북의 순차 프로젝션, 코드북 피드백, 다음 프레임을 위한 피드백 임베딩 조립까지를 캡처합니다. 이렇게 하면 작지만 매우 순차적인 루프에서 실행 오버헤드를 제거할 수 있습니다. 위 그림처럼 Eager 모드는 약 250 스텝에 걸쳐 CPU 커널 실행 간격(gap)이 누적되지만, CUDA Graph는 한 스텝 전체를 한 번의 호출로 재생(replay)합니다.

그래프 재생이 가능하려면 상태가 안정된 주소에 있어야 합니다. 그래서 MOSS는 요청별 디코드 상태를 지속되는 GPU 측 풀(pool)에 보관합니다. 피드백 임베딩, 샘플링 파라미터, 시드(seed), 카운터, 오디오 히스토리가 프레임을 가로질러 안정된 주소에 머뭅니다. SGLang-Omni는 또한 생성된 행의 radix 해시를 GPU로 옮겨, 프레임마다의 CPU 해싱과 D2H(Device-to-Host) 동기화를 피합니다.

프레임당 13개의 샘플링 연산은 시드 GPU 샘플러를 사용합니다. 여기서 백본이나 로컬 트랜스포머 전체가 아니라 오직 이 샘플링 경로만 컴파일합니다. 그 좁은 범위 덕분에, 더 큰 모델 실행 경로를 바꾸지 않으면서도 SeedTTS 영어, 동시성 16에서 처리량이 12.3% 향상되고 평균 지연이 11.1%, 평균 RTF가 10.5% 감소했습니다. 여기서 RTF(Real-Time Factor)는 다음과 같이 정의되는 실시간 대비 처리 속도 지표입니다.

\text{RTF} = \frac{\text{음성을 생성하는 데 걸린 시간}}{\text{생성된 음성의 길이}}

RTF가 1보다 작으면 실제 음성 길이보다 빠르게 생성한다는 뜻이며, 값이 낮을수록 좋습니다.

스트리밍 보코더: 첫 소리를 빨리, 이후는 묶어서

보코더 단계는 생성된 RVQ 프레임을 오디오 청크로 바꿉니다. MOSS-Audio-Tokenizer-v2가 상태형 스트리밍 디코드를 지원하므로, SGLang-Omni는 보코더 실행기 안에 지속되는 코덱 스트리밍 세션을 유지합니다.

스케줄러는 스트림 슬롯, 오프라인 폴백 슬롯, 청크 임계값, 그리고 합쳐진(coalesced) 디코드 스텝을 관리합니다. 첫 청크는 작은 임계값을 써서 첫 소리까지의 시간(time to first audio)을 줄이고, 이후 청크는 더 큰 윈도우를 써서 처리량을 높입니다. 여러 요청이 충분한 대기 프레임을 쌓아두면, 스케줄러는 이들을 한 번의 코덱 호출로 함께 디코딩합니다.

짧은 스트리밍 청크는 실행 비용이 큽니다. 그래서 SGLang-Omni는 자주 등장하는 보코더 프레임 수를 CUDA Graph로 캡처합니다. 코덱 상태 버퍼를 안정된 주소에 두고 제자리(in-place)에서 갱신하여, 스트리밍 스텝 사이에 그래프 재생이 가능하도록 합니다. 가속 효과는 짧은 청크일수록 큽니다.

스텝당 프레임 수	Eager	CUDA Graph	가속
4	66.3 ms	30.1 ms	2.20x
5	65.8 ms	30.7 ms	2.14x
8	65.6 ms	34.0 ms	1.93x
13	65.4 ms	40.4 ms	1.62x
25	74.8 ms	58.3 ms	1.28x
100	222.9 ms	215.3 ms	1.04x

캡처되지 않은 프레임 수이거나 메모리가 빠듯할 때는 그래프 경로가 Eager 디코드로 폴백합니다. 스트리밍과 비(非)스트리밍 사이의 일관성 검사도 이 경로를 함께 점검합니다.

메모리 예산: 한 GPU 위에서 서로를 방해하지 않게

기본 MOSS Local 설정에서는 전처리, AR 생성, 보코더 실행을 하나의 GPU에 함께 올릴(colocate) 수 있습니다. 이 조밀한 배치는 편리하지만, AR 엔진과 코덱 런타임은 메모리 할당 패턴이 같지 않습니다. 그래서 SGLang-Omni는 AR 엔진에 명시적인 코로케이션 메모리 계약을 부여하고, 코덱 런타임 할당과 스트리밍 상태를 위한 여유 공간(headroom)을 따로 예약합니다.

단일 카드 코로케이션 구성, 동시성 8에서 명시적 코덱 메모리 예산은 처리량을 8.9% 향상시키고 평균 RTF를 8.4% 감소시켰습니다. 더 중요한 것은, 메모리 압박 상황에서 배포 동작을 예측 가능하게 만든다는 점입니다.

성능: 스트리밍과 비스트리밍의 트레이드오프

최적화된 서빙 경로를 SeedTTS 영어 세트(1088개 샘플)에서 평가했습니다. 아래 결과는 보코더 CUDA Graph가 켜진 뒤 전체 CI 평가에서 나온 것으로, 2x GPU와 클라이언트 동시성 16을 사용했습니다. ASR 채점에는 Qwen3-ASR-1.7B를, 화자 유사도(SIM)에는 WavLM-Large 파인튜닝 모델을 사용했습니다.

모드	완료 / 실패	처리량	오디오 처리량	평균 지연	평균 RTF	WER
비스트리밍	1088 / 0	5.976 req/s	26.303 audio s/s	2.669 s	0.644	1.75%
스트리밍	1088 / 0	2.909 req/s	12.804 audio s/s	5.474 s	1.322	2.14%

비스트리밍은 평균 RTF 0.644로 5.976 req/s의 처리량에 도달합니다. 스트리밍은 점진적으로 오디오 청크를 내보내는데, 동시성 16에서 평균 청크 간 간격(inter-chunk interval)은 0.109초 이고, 각 요청은 평균 8.82개 의 청크를 내보냅니다. 스트리밍의 처리량이 더 낮은 것은 예상된 결과입니다. 보코더가 더 작은 청크에 대해 더 자주 돌고, AR 엔진과 GPU 시간을 나눠 쓰기 때문입니다. 참고로 OpenMOSS 측은 v1.5가 이론적으로 100ms 미만의 첫 토큰 지연(TTFT)을 낼 수 있다고 밝힌 바 있습니다.

품질 수치는 모드 간에 가깝게 유지됩니다. 같은 CI 실행에서 비스트리밍은 1.75%, 스트리밍은 2.14% 의 WER을 기록했고, 스트리밍과 비스트리밍 산출물의 아티팩트 일관성 검사도 통과했습니다.

한 가지 주의할 점이 있습니다. 개별 최적화 측정값들은 하나의 대표 숫자로 더해서는 안 됩니다. 각각 다른 하드웨어와 동시성 설정에서 수집되었기 때문입니다. 이들은 합산 지표가 아니라, MOSS가 어디에 시간을 쓰는지를 보여주는 지도 로 읽는 편이 더 유용합니다. 레퍼런스 캐싱은 중복 인코더 작업을 없애고, 프레임 CUDA Graph는 로컬 루프의 실행 오버헤드를 없애며, 샘플러 컴파일은 핫 샘플링 경로를 개선하고, 보코더 CUDA Graph는 짧은 스트리밍 청크를 가속하며, 메모리 예산은 코로케이션 배포를 안정시킵니다.

직접 써보기

SGLang-Omni MOSS-TTS-Local 쿡북에 전체 설정, API 옵션, 스트리밍 예제가 정리되어 있습니다. 최소 경로는 다음과 같습니다. 먼저 sglang-omni를 설치한 뒤(공개 모델이라 토큰이 필요 없습니다) 모델을 내려받습니다.

hf download OpenMOSS-Team/MOSS-TTS-Local-Transformer-v1.5

프로세서는 체크포인트에 함께 들어 있어 별도의 TTS 패키지가 필요 없습니다. 기본 레이아웃은 AR 백본과 코덱/보코더를 하나의 GPU에 함께 올립니다. 명시적인 설정 파일은 examples/configs/moss_tts_local.yaml에 준비되어 있습니다.

sgl-omni serve \
  --model-path OpenMOSS-Team/MOSS-TTS-Local-Transformer-v1.5 \
  --port 8000

서버가 뜨면, 기본 합성 요청은 WAV 파일을 반환합니다.

curl -X POST http://localhost:8000/v1/audio/speech \
  -H "Content-Type: application/json" \
  -d '{"input": "SGLang-Omni is a great project!"}' \
  --output output.wav

음성 복제는 references 필드에 audio_path(로컬 경로, HTTP URL, 또는 base64 데이터 URI)와 그 클립의 전사(text)를 함께 넘기면 됩니다. 전사를 함께 주면 복제 품질이 눈에 띄게 좋아집니다. 스트리밍은 "stream": true, "response_format": "pcm", "stream_format": "audio"를 설정하면 실시간으로 raw 48kHz PCM 청크를 받을 수 있습니다. 이 밖에 길이 제어(${token:N} 또는 token_count), [pause Xs] 일시정지 마크업, 발음 힌트(Pinyin/IPA), 언어 힌트(language), 샘플링 파라미터, 벤치마크 명령은 모두 쿡북에 정리되어 있습니다.

웹에서 바로 체험해 보고 싶다면 MOSI Platform Playground에서 모델을 직접 테스트할 수 있고, llama.cpp 기반의 PyTorch 없는(torch-free) 경량 추론이나 ModelScope 가중치 같은 다른 배포 경로도 제공됩니다.

로드맵

현재 경로는 엔드투엔드로 동작하지만, OpenMOSS와 SGLang-Omni 팀은 여전히 개선할 부분들을 제시합니다.

풀 네이티브 프레임 CUDA Graph (Pool-native frame CUDA Graph): 현재 프레임 디코드 그래프는 지속 상태 풀을 쓰지만, 샘플링 파라미터와 생성 행 주변에 일부 스테이징이 남아 있습니다. 더 네이티브한 풀-투-풀 그래프 경로로 실행/해석 경계를 단순화할 수 있습니다.
적응형 스트리밍 스케줄링 (Adaptive streaming scheduling): 스트리밍 TTS에는 실제 지연-처리량 트레이드오프가 존재합니다. 부하 인식 청크 크기 조절, 우선순위 인식 슬롯 스케줄링, 더 나은 합치기(coalescing) 정책을 탐구하여, 저부하 요청은 빠른 첫 소리를 받고 고부하 배포는 더 많은 처리량을 회복하도록 만들려 합니다.
컴파일 적용 범위 확대 (Broader compilation coverage): 코덱 인코더와 Qwen3 백본은 아직 표적 컴파일 실험의 여지가 있습니다. 콜드 스타트 회귀와 출력 변화를 피하기 위해 컴파일 범위는 좁게 유지할 계획입니다.
더 넓은 벤치마크 커버리지 (Wider benchmark coverage): 현재 측정은 CI의 SeedTTS 영어에 집중되어 있습니다. 중국어, 다국어 평가, 장문 생성, 다양한 화자 풀, 서로 다른 레퍼런스 길이, 운영 환경에 가까운 트래픽 혼합으로 커버리지를 넓힐 예정입니다.

라이선스

MOSS-TTS 가족의 모델들은 Apache License 2.0으로 배포되고 있어, 연구 목적은 물론 상업적 용도로도 자유롭게 사용 및 수정이 가능합니다.

커뮤니티 참여

TTS, 옴니 모델, 스트리밍 추론, CUDA Graph, 스케줄링, 통신, 모델 온보딩, 벤치마킹, 운영 서빙에 관심이 있다면 MOSI 팀이 함께할 동료를 찾고 있습니다.

MOSS-TTS-Local on SGLang-Omni 소개 블로그

MOSS-TTS-Local-Transformer-v1.5 모델

MOSS-TTS GitHub 저장소

SGLang-Omni GitHub 저장소

MOSS-TTS-Local 더 알아보기

SGLang-Omni 공식 문서 - 설치, 사용법, 쿡북

MOSS-TTS-Local 쿡북 - 전체 API 옵션과 스트리밍 예제

SGLang-Omni 최적화 로드맵 - 모델 온보딩과 최적화 추적 이슈

github.com/sgl-project/sglang-omni

MOSS TTS Performance Optimization Roadmap

열림 03:33AM - 01 Jun 26 UTC

gaoyang07

## Goal Low latency and high throughput with no model performance reduction We… maintain two MOSS-TTS architecture tracks under the same tokenizer and pretraining recipe to study the impact of token modeling patterns in discrete speech modeling: - **Delay Pattern**: the primary scalable architecture, using a simpler single-backbone multi-head design. It is better suited for large model scaling, long-context generation, duration/pronunciation control, and optimized inference backends. - Model arch and weights: https://huggingface.co/OpenMOSS-Team/MOSS-TTS-v1.5 - **Local Transformer**: a quality-oriented variant with an extra frame-local AR module. It adds architectural complexity but improves modeling efficiency, showing lower token losses and stronger speaker similarity at smaller model scale. - Model arch and weights: https://huggingface.co/OpenMOSS-Team/MOSS-TTS-Local-Transformer <img width="949" height="580" alt="Image" src="https://github.com/user-attachments/assets/4fba155f-3015-4842-94d2-983834fd1583" /> Help wanted: https://github.com/sgl-project/sglang-omni/issues/607 ## Done - [x] Delay-pattern model support with radix cache #609 @GaokaiZhang @0xjeffro - Earlier attempts: #608 @sjmshsh - [x] AR CUDA Graph + torch.compile - [x] Doc implementation - [x] Cookbook - [x] benchmark performance in H200 ### Optimization Baseline: require RTF < 1 for concurrency 16 on H100 **Model support** - [x] MOSS-TTS-Local-Transformer-v1.5 #728 @GaokaiZhang - legacy 1.0: Local-transformer arch model with radix cache #716 @draftbk - [ ] Playgroud - [ ] Cookbook #792 @MelodyyyYin - [ ] Doc implementation - [ ] benchmark performance in H100/H200 **Pipeline** - [x] decouple preprocessing and ref audio encoding #730 @sjmshsh V1 pr: #699 @AkazaAkane - [x] preprocessing, AR, and vocoder in the default single-GPU pipeline #810 @Ratish1 **Encoder** - [x] reference audio cache #731 @JiaxinD #812 @AkazaAkane previous attempt for v1 #648 @AkazaAkane - [x] batched audio encode #732 @SandyLuXY previous attempt for v1 #649 @AkazaAkane - [x] encoder torch compile #733. @SandyLuXY V1 pr: #653 @nagisa-kunhah **AR Step** - [x] validate/optimize async decode path #734 @JiaxinD. V1 pr: #695 @guozhihao-224 - [x] state-pool refactor #735 @JiaxinD. previous pr: #719 @guozhihao-224 - [x] native multi-channel CUDA graph capture for audio-code sampling path #736 @nagisa-kunhah - [x] torch.compile for AR backbone #737 @xinlij - [x] MOSS-TTS Local v1.5 #757 : vectorize per-frame launch orchestration into [P] pool tensors **Vocoder** - [x] Batched vocoder decode #738. @yijiangt V1 pr: #651 @yijiangt - [ ] vocoder cuda graph #801 @JiaxinD **Streaming** - [x] AR stream chunk + streaming vocoder #739. @edwingao28 pr: #753 V1 pr: #674 @BruceLoveDecimal **CI support** - [ ] Expand TTS CI to MOSS-TTS #726 @MelodyyyYin #727 @yijiangt **Refactor with Higgs** - [ ] Refactor reusable optimization templates #802 @Hayden727

MOSS-TTS 기술 보고서 - arXiv

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~