우리가 텍스트 음성 변환(TTS) API를 무료로 만든 방법: S2.1 Pro 이면의 추론 엔지니어링
요약 (TL;DR)
- Fish Audio S2.1 Pro를 이제 무료 텍스트 음성 변환(TTS) API로 사용할 수 있습니다: 83개 언어 지원, 엄격한 사용량 제한 없음, 모델 문자열
s2.1-pro-free. 무료 액세스는 초기 기간 동안 제공되며, 변경 사항이 있을 경우 사전에 안내해 드립니다. 자세한 내용은 여기에서 확인하세요.- 엔드투엔드 추론 최적화를 통해 GPU당 요청 처리 용량을 4배 향상했습니다. 이전에는 4개의 H200이 필요했던 작업을 이제 단 한 개의 H200에서 실행할 수 있습니다.
- 핵심 동인: 커스텀 CUDA 커널(디코드 셰이프에서 cuBLAS 대비 2.1–4.3배 향상), 연속 배칭(c=1→64에서 처리량 52배 확장), GPU 이용률 약 50%에서 90% 이상으로 향상
- 동일한 스택이 우리의 음성 클로닝 API에도 적용됩니다. 동일한 모델 가중치와 인프라를 사용하며 무료 티어가 포함되어 있습니다. S2.1 Pro는 우리의 오픈 가중치 파운데이션 모델인 Fish Speech를 기반으로 구축되었습니다.
- 핵심 커널 라이브러리인 fish-scales-ops는 오픈 소스로 공개되어 있습니다.
왜 개발자들이 다른 플랫폼에서 우리로 전환하는지 확인해 보세요 → 무료로 빌드 시작하기
2026년 7월 | Fish Audio는 추론 스택을 재구축하여 모든 개발자를 위해 S2.1 Pro를 무료로 공개했습니다.
음성 AI에 비용이 드는 진짜 이유
음성 AI 추론에는 가격 페이지에서 설명하지 않는 구조적인 문제가 있습니다: 자기회귀(autoregressive) 디코드는 기본적으로 GPU 이용률에 매우 적대적입니다.
모든 TTS API 호출은 오디오 토큰을 한 번에 하나씩 생성하는 디코드 루프를 구동합니다. 각 단계는 실제로는 M ≤ 128인 작은 행렬 곱셈이며, 그 뒤를 해당 시퀀스에 대한 KV 캐시의 메모리 읽기가 따릅니다. 메모리 하위 시스템이 따라잡는 동안 CUDA 코어는 대부분 유휴 상태로 대기합니다. 30,000달러짜리 H200에서 여러분은 연산 비용을 지불하고 있지만, 정작 메모리 지연(stall)으로 그 성능을 낭비하고 있는 셈입니다.
동시성이 낮을 때는 상황이 더 나빠집니다. 단일 요청 디코드 루프는 스케줄링 오버헤드로 구분된 10–20μs의 짧은 버스트로 GPU를 점유합니다. 나이브하게 서빙되는 TTS 엔드포인트의 GPU 이용률은 c=1일 때 10% 미만일 수 있습니다. 하드웨어는 준비되어 있지만, 작업이 하드웨어를 채우지 못하고 있는 것입니다.
업계의 대답은 글자 수당 과금을 통해 그 비용을 개발자에게 전가하는 것이었습니다. 우리의 답은 인프라 계층에서 이용률 문제를 해결하는 것이었습니다. 단일 GPU가 이전의 4대 분량의 작업을 수행할 수 있게 되면, 무료 티어의 경제성이 확보됩니다.
이를 위해 필요한 사항은 다음과 같습니다.
엔드투엔드 최적화: 전체 스택
단 하나의 변화로 4배의 효율성 향상을 얻을 수는 없습니다. 이러한 이득은 모든 레이어를 동시에 최적화하고 그 효과를 결합함으로써 얻어졌습니다.
- 커스텀 CUDA 커널 — 토큰당 연산 낭비 제거
- FP8 양자화 — 메모리 대역폭 압박을 절반으로 감소
- 연속 배칭 (Continuous batching) — 동시 요청 전체에서 GPU를 채움
- GPU 스케줄링 — 작업 사이의 유휴 용량 제거
- 자체 네트워크 및 스토리지 소유 — 클라우드 인프라 마진 제거
각 레이어는 아래에 자세히 설명되어 있습니다. 마지막에 제시된 처리량과 비용 수치는 이 모든 요소가 결합된 결과입니다.
커스텀 CUDA 커널: fish-scales-ops
왜 cuBLAS로는 부족했는가
TTS 서빙에서의 디코드 셰이프(M ≤ 128)는 cuBLAS, PyTorch의 GEMM 커널, 또는 심지어 torch.compile이 최적화된 형태가 아닙니다. 이러한 라이브러리들은 학습이나 M이 수천 단위인 대규모 배치 프리필(prefill)을 타겟으로 합니다. 작은 M에서는 메모리 대역폭을 낭비하고 디코드 배치 사이즈에서만 존재하는 퓨전(fusion) 기회를 놓치게 됩니다.
구체적인 차이점: M=1(단일 요청 디코드)에서의 SwiGLU MLP 포워드의 경우, cuBLAS scaled_mm은 활성화(activation), 게이트 곱셈(gate multiply), 다운 프로젝션(down projection)이라는 세 개의 개별 커널 런치를 실행하며, 각 단계 사이의 중간 결과를 HBM에 쓰고 다시 읽어옵니다. M=1에서는 연산이 아니라 이 데이터의 왕복이 병목 현상이 됩니다.
우리는 이 간극을 메우기 위해 fish-scales-ops를 개발했습니다. 이는 NVIDIA Hopper (H200, sm_90a) 및 Blackwell (sm_120a) 아키텍처를 타겟으로 하는 상용 수준의 오픈 소스 FP8 GEMM 및 FlashAttention 라이브러리입니다.
FP8 양자화 전략
우리는 서로 다른 하드웨어 세대를 위해 두 가지 양자화 스킴을 구현했습니다.
bsgemm (128×128 블록 스케일링 FP8): H200/Hopper용. 128×128 단위의 블록 스케일링은 텐서별(per-tensor) 양자화의 정확도 위험 없이 우수한 수치적 안정성을 제공합니다.
mxfp8 (1×32, OCP UE8M0 포맷): Blackwell (RTX 5090, RTX 6000 PRO)용. 32개 요소 공유 지수를 사용하는 마이크로스케일링(OCP MX 표준)은 오디오 토큰 생성에 중요한 스케일에서 더 세밀한 수치적 정밀도를 제공합니다.
mxfp8 경로에서 발생한 한 가지 까다로운 버그는 상당한 디버깅이 필요했습니다. quantize_blockscale.py가 safetensors 호환성을 위해 .contiguous()로 weight_scale 텐서를 구체화했지만, linear_mxfp8_raw는 K-major 스트라이드 (1, N)으로 스케일을 읽었습니다. 행-메이저(row-major) 연속 [N, K/128]을 로드하자 모든 GEMM이 최대 커널 속도에서 잘못된 로짓을 생성했습니다. 이로 인해 다운스트림 샘플링이 하나의 반복되는 시맨틱 토큰으로 모드 붕괴(mode-collapsed)되었습니다. 이는 모델 품질 문제처럼 보이지만 실제로는 메모리 레이아웃 버그였습니다. 해결책은 MXFP8LinearMethod.process_weights_after_loading에서 스트라이드를 다시 조정하는 것이었습니다. 수정 후, 그리디 디코드는 처음 5개의 오디오 프레임에서 bf16과 토큰 단위로 정확히 일치했습니다.
커널 벤치마크 결과
디코드 셰이프(M ≤ 128)에 대한 동일 하드웨어 내 벤치마크 결과는 다음과 같습니다(상세 방법론은 fish-scales-ops 저장소 참조):
- MXFP8 경로는 1024³에서 16384³ 사이의 10개 정사각 셰이프 중 8개에서
torch.nn.functional.scaled_mm을 능가하며 최대 21% 향상 - 엔드투엔드 Qwen3-4B SwiGLU MLP 포워드: 1에서 4096 사이의 모든 M에서 순수 cuBLAS
scaled_mm대비 1.7–6.2배 향상 - 디코드 셰이프에서
torch.compile이 퓨즈된 cuBLAS 대비: 2.1–4.3배 빠름 - sm_120a에서의 MXFP8 FlashAttention: PyTorch SDPA 디코드 대비 7–19배, FlashInfer BF16 대비 1.2–2.7배 향상
이러한 이득을 주도하는 두 가지 퓨즈드 커널: 하나는 활성화 양자화 + UE8M0 스케일 팩을 단일 호출로 퓨징합니다. 다른 하나는 SwiGLU 프롤로그를 다운-GEMM 활성화 양자화에 직접 퓨징하여, PyTorch가 두 연산 사이에서 구체화하는 전체 BF16 중간 쓰기+읽기 과정을 제거합니다.
배치 추론 아키텍처: 지연 시간과 처리량의 트레이드오프
자기회귀 TTS를 위한 연속 배칭 (Continuous Batching)
커널 효율성은 토큰당 비용을 개선합니다. 배칭(Batching)은 이 토큰당 효율성을 요청 스트림 전체의 GPU 이용률로 전환하는 역할을 합니다.
정적 배칭(Static batching) — 모든 시퀀스를 동일한 길이로 패딩하여 고정된 배치로 실행 — 은 패딩에 연산을 낭비하고 배치의 가장 느린 시퀀스가 끝날 때까지 새로운 요청을 차단합니다. 출력 길이가 가변적인 TTS의 경우 꼬리 지연 시간(tail latency) 페널티가 큽니다.
우리는 sglang에서 영감을 얻은 연속 배칭을 사용합니다. 새로운 요청은 배치 경계를 기다리지 않고 슬롯이 비는 대로 활성 디코드 배치에 합류합니다. GPU 디코드 루프는 느린 요청 때문에 지연되지 않습니다.
DualAR: S2 전용 배칭 제약 사항
S2.1 Pro의 DualAR 아키텍처는 오디오 토큰을 두 단계(Coarse 코드북 뒤의 Fine 코드북)로 생성하며, 각 단계를 조건화하는 슬라이딩 previous_tokens 윈도우를 가집니다. 이는 표준 LLM 배칭에는 없는 정확성 제약을 만듭니다: prev_tokens_shift_inplace 커널은 엄격한 셰이프/데이터 타입 계약(prev int32 [bs, W, cw], next_tokens int32 [bs, cw])을 요구합니다. 호출자의 모든 셰이프 조작(.unsqueeze(), 암시적 데이터 타입 프로모션 등)은 윈도우를 손상시키고 모델 품질 저하와 구별하기 어려운 열화된 오디오를 생성합니다.
음성 클로닝 작업의 경우 이 제약이 특히 중요합니다. 화자 조건화가 동일한 디코드 경로를 통해 흐르기 때문에, 윈도우 손상은 명확한 오디오 아티팩트보다는 긴 출력 전체에서 화자 정체성이 틀어지는 현상으로 나타납니다.
처리량 결과
H200, bsgemm FP8, 동시성 스윕:
| 동시성 | 총합 처리량 | TTFB p50 |
|---|---|---|
| 1 | 154 tok/s | 73.2 ms |
| 4 | 595 tok/s | 75.5 ms |
| 8 | 1,206 tok/s | 81.2 ms |
| 16 | 2,373 tok/s | 79.6 ms |
| 32 | 4,099 tok/s | 96.9 ms |
| 64 | 8,006 tok/s | 109.8 ms |
처리량은 c=1에서 c=64까지 약 52배 확장되는 동안, TTFB는 36.6ms(73ms에서 110ms) 증가하는 데 그쳤습니다. GPU는 대부분의 프로덕션 워크로드에서 인지할 수 없는 수준의 지연 시간 페널티만으로 52배 더 많은 작업을 수행합니다.
c=64에서 단일 H200은 8,006 tok/s를 유지합니다. 이 수치가 바로 무료 티어를 가능하게 하는 직접적인 메커니즘입니다. GPU당 처리량이 높을수록 요청당 비용이 낮아집니다.
이 수치들은 모든 무료 API 호출 이면에서 작동하고 있습니다. 빌드 시작하기 →
실시간 모드: 저지연 워크로드를 위한 아키텍처적 접근
보이스 에이전트 및 턴제 애플리케이션을 위해, 우리는 총합 처리량보다는 첫 오디오 출력 시간(TTFA)에 최적화된 별도의 실시간 엔드포인트를 노출합니다.
핵심 아키텍처 결정: 프리필(Prefill)은 연결이 열릴 때 발생하여 지연 시간이 중요한 경로에서 완전히 제외됩니다. 스트리밍 지연 시간의 시계는 연결 수립 시점이 아니라 첫 번째 오디오 청크 전송 시점부터 시작됩니다. 즉, 프롬프트 길이에 따라 확장되는 프리필 비용이 TTFA 수치에 전혀 나타나지 않습니다.
스케줄러 수준에서는 핑퐁(pingpong) 설계가 사이클별 호스트 배리어 없이 별도의 스레드에서 디코드와 프리필을 실행합니다. 배리어 제거는 c≥4에서 TTFA를 개선하는 핵심 요소입니다. 나이브한 구현에서는 각 디코드 단계 후의 호스트 측 동기화가 병렬로 처리되어야 할 작업을 직렬화합니다. 파이프라인된 디코드 루프와 핀드(pinned) H2D 메모리 전송은 높은 동시성 환경에서 TTFB와 지터(jitter) 문제를 해결합니다.
전체 설계 및 지연 시간 분석은 arXiv:2603.08823에서 확인할 수 있습니다.
품질 검증: 최적화가 오디오를 저하시키지 않았음을 확인한 방법
양자화와 배칭은 처리량 벤치마크만으로는 감지하기 어려운 품질 저하를 유발할 수 있습니다. GPU가 최대 속도로 작동하더라도 잘못된 출력을 생성할 수 있기 때문입니다.
우리는 mxfp8 개발 중에 이러한 사례를 발견했습니다. 위에서 언급한 웨이트 레이아웃 버그는 커널 지연 시간이 완전히 정상임에도 불구하고 약 53%의 상대적 로짓 오류를 발생시켰습니다. 이러한 저하는 성능 지표가 아닌 출력 토큰 분석에서만 나타났습니다.
우리의 검증 파이프라인에는 두 가지 게이트가 있습니다:
정확성 게이트(Correctness gate): 양자화 후 그리디 디코드는 고정된 참조 입력에 대해 처음 5개의 오디오 프레임에서 bf16과 토큰 단위로 정확히 일치해야 합니다. 첫 프레임에서의 토큰 단위 일치는 시스템적인 로짓 손상을 포착합니다. 양자화된 모델이 다른 확률 분포를 생성한다면 결정론적 입력에 대해 즉시 bf16과 달라질 것입니다.
성능 저하 게이트(Performance regression gate): 요청당 decode_tps는 모든 동시성 지점에서 고정된 베이스라인 수치의 5% 이내를 유지해야 합니다. 어떤 동시성 지점(c=1, c=16, c=64)에서든 처리량을 5% 이상 저하시키는 변경 사항은 병합 전 명시적인 정당화가 필요합니다. 이 게이트는 디코드 루프에 무분별하게 동기화 과정을 추가하여 정확성 문제를 해결하려는 시도를 방지합니다.
두 게이트는 추론 스택의 모든 변경 사항에 대해 실행됩니다. 그 결과, S2.1 Pro 무료 모델 가중치는 유료 티어와 동일하며, 양자화된 서빙 경로는 모든 배포 시 비양자화 베이스라인에 대해 검증됩니다.
대규모 음성 클로닝: 추론 효율성이 중요한 이유
Fish Audio의 음성 클로닝은 항상 무료였으며, 우리의 자체 평가와 개발자 피드백에 따르면 여전히 동급 최강의 성능을 자랑합니다. 83개 언어에 걸친 화자 일관성, 자연스러운 운율, 악센트 전반의 안정적인 성능은 유료 티어에만 추가된 기능이 아닙니다. 그것이 우리의 기본값입니다. S2.1 Pro는 올해 초 출시된 오픈 가중치 파운데이션 모델인 Fish Speech S2 Pro를 기반으로 합니다.
추론 최적화가 바꾸는 것은 이러한 약속을 대규모로 유지할 수 있게 하는 경제성입니다. 음성 클로닝 워크로드는 표준 TTS보다 요청당 비용이 더 높습니다. 모든 호출은 참조 화자 임베딩을 조건화하고, 가변 길이 출력 전체에서 화자 정체성을 유지하며, 이를 여러 언어에서 일관되게 수행해야 합니다. 이 포스팅에서 설명한 효율성 이득이 없었다면, 대규모 프로덕션 환경에서의 무료 음성 클로닝은 구조적으로 값비싼 워크로드를 보조하는 격이었을 것입니다. 하지만 최적화 덕분에 더 이상 그렇지 않습니다.
특히 음성 클로닝에 중요한 세 가지 최적화:
FP8은 화자 조건화를 보존합니다. 로짓 수준의 손상을 포착하는 토큰 단위 정확성 검증은 양자화가 화자 임베딩 신호를 저하시키지 않음을 직접적으로 입증합니다. 클로닝된 출력의 화자 일관성은 bf16 베이스라인과 일치합니다.
연속 배칭은 혼합 요청 유형을 처리합니다. 프로덕션 음성 클로닝 트래픽은 참조 조건부 요청과 비조건부 요청, 다양한 출력 길이, 다양한 언어가 섞여 있습니다. 연속 배칭은 요청 유형에 관계없이 디코드 배치를 채우므로 워크로드의 이질성에 따른 페널티가 없습니다.
52배 처리량 확장은 대량 생성을 가능하게 합니다. 단일 H200에서 8,006 tok/s의 속도로 오디오북, 게임 다이얼로그, 현지화된 콘텐츠 등 대규모 음성 클로닝 라이브러리를 생성하는 것이 무료 티어 내에서도 경제적으로 가능해집니다.
무료 티어에 음성 클로닝이 포함된 것은 단순히 우리가 비용을 감당할 수 있게 최적화했기 때문만은 아닙니다. 그것이 항상 우리의 제품이었기 때문이며, 여기에서 설명한 엔지니어링 작업은 사용량이 늘어나더라도 그 약속을 지킬 수 있게 해주는 기반입니다. 음성 클로닝을 에이전트 워크플로우에 통합하려면 MCP 및 에이전트 스킬 지원을 참조하세요.
60초 이내에 음성 클로닝하기 → 무료 체험
GPU 인프라: 스택 소유하기
하드웨어 및 조달
우리의 GPU 클러스터는 여러 데이터 센터에 걸쳐 약 500개의 카드를 운영합니다. 멀티 DC 토폴로지는 신뢰성 이전에 조달 측면의 결정이었습니다. GPU 공급과 가격은 변동성이 크며, 단일 벤더에 종속되는 것은 그 변동성을 직접 흡수해야 함을 의미합니다. 멀티 벤더, 멀티 DC 소싱은 운영상의 복잡성을 대가로 가격 리스크와 공급 제약을 동시에 헤징합니다.
추론을 위해 우리는 혼합 플릿(mixed fleet)을 운영합니다. H200 SXM5는 bsgemm FP8 총합 처리량이 지배적인 고동시성 프로덕션 서빙을 담당합니다. RTX 5090 및 RTX 6000 PRO (sm_120a)는 에지 엔드포인트를 서빙합니다. c=64에서 5090 mxfp8은 5,869 tok/s를 달성하며, 이는 카드당 훨씬 낮은 하드웨어 비용으로 H200 bsgemm 처리량의 약 71%에 해당합니다.
sm_120a 배포에는 한 가지 까다로운 수정이 필요했습니다: 32GB GPU에 대한 원래의 cuda_graph_max_bs = 24 캡이 높은 동시성에서 심각한 처리량 절벽을 만들었습니다(c=32에서 ~31 tok/s/req, c=64에서 ~35 tok/s/req). 이 캡을 min(max_running_requests, 64)로 높임으로써 전체 처리량 곡선을 회복했습니다. 근본적인 원인은 bs=24에서의 CUDA 그래프 캡처가 실제 c=32 이상에서 나타나는 디코드 배치 사이즈에서 GPU를 과소 이용하게 만들었기 때문입니다.
GPU 스케줄링: 유휴 용량 제거
추론 전용 클러스터의 베이스라인 GPU 이용률은 약 50%입니다. 추론 트래픽은 본질적으로 변동이 심하며, GPU는 피크 타임이 아닐 때, 학습 실행 사이, 데이터셋 로딩 단계 동안 유휴 상태로 방치됩니다.
우리는 두 개의 병렬 스케줄링 시스템(추론용 Kubernetes, 학습용 Slurm)을 운영하며 하나의 공유 원칙을 따릅니다: 데이터 클리닝 및 전처리 작업은 두 클러스터 모두에서 최하위 우선순위 티어의 탄력적인 채우기 작업(elastic fill work)으로 실행됩니다. 클리닝 작업은 추론이나 학습이 사용하지 않을 때마다 유휴 GPU 용량을 점유합니다. 이 작업들은 체크포인트 설정이 가능하고 즉시 선점(preemptible)될 수 있으므로, 실제 작업이 들어오면 정확성 손실 없이 즉시 사라집니다.
우선순위 순서: K8s 클러스터에서는 추론 > 클리닝, Slurm에서는 학습 > 클리닝입니다. 추론 측의 오토스케일러는 시간 기반 휴리스틱이 아닌 실시간 트래픽 신호를 사용하므로 부하가 증가하는 즉시 클리닝 작업이 퇴거됩니다.
결과: GPU 이용률이 약 50%에서 90% 이상으로 향상되었습니다. 클러스터 규모에서 이 차이는 추론 요청당 유효 비용을 대략 절반으로 줄여줍니다. 하드웨어 예산은 고정되어 있지만, 동일한 예산으로 두 배 더 많은 요청을 처리할 수 있기 때문입니다.
네트워크 인프라
우리는 직접 ISP 대역폭 조달, ASN, 300Gbps 연결, Cloudflare 피어링을 포함한 자체 네트워크를 운영합니다. 특히 TTS의 경우 두 가지 비용적 시사점이 있습니다.
TTS 규모에서 전송 비용(Egress)은 무시할 수 없습니다. 클라우드 제공업체의 전송 비용 책정은 구조적으로 마진이 높습니다. 네트워크 계층을 소유하면 이 마진을 완전히 제거할 수 있습니다.
두 번째 이유는 지연 시간입니다. 네트워크 왕복의 매 밀리초는 사용자가 체감하는 TTFB에 그대로 반영됩니다. Cloudflare 피어링을 통해 Fish Audio 엔드포인트를 Cloudflare 네트워크를 통해 라우팅되는 사용자(글로벌 API 트래픽의 상당 부분)와 가깝게 배치합니다. 멀티 DC 배포는 대부분의 요청이 공용 인터넷 전체를 가로지르지 않고 근처의 추론 노드에 도달함을 의미합니다.
스토리지: 계층화된 아키텍처
학습 데이터, 모델 체크포인트, 추론 캐시는 서로 다른 액세스 패턴과 비용 요구 사항을 가집니다. 우리는 3계층 아키텍처를 사용합니다:
- Hot (NVMe 플래시): 활성 학습 데이터, 서빙용 모델 가중치
- Warm (혼합 플래시/HDD): 최근 체크포인트, 전처리된 데이터셋
- Cold (자체 호스팅 Ceph HDD 클러스터): 과거 학습 데이터, 장기 보관
대량 데이터를 위해 서드파티 오브젝트 스토리지를 Cold 계층으로 교체했습니다. Cold 스토리지 앞단의 로컬 캐시 계층은 학습 데이터 파이프라인에서 흔히 발생하는 반복 읽기 작업을 Cold HDD가 아닌 NVMe에서 처리하도록 합니다.
결과: 스택이 만들어낸 성과
모든 레이어에 걸쳐:
- 커스텀 FP8 커널: 디코드 셰이프에서 표준 cuBLAS 대비 2.1–4.3배 빠름
- 연속 배칭: c=1에서 c=64까지 52배 처리량 확장, 지연 시간은 37ms 증가에 그침
- GPU 스케줄링: 이용률 약 50% → 90% 이상, 요청당 비용 대략 절반으로 감소
- 자체 인프라 소유: 컴퓨팅, 네트워크, 스토리지에서 클라우드 마진 제거
종합적으로, 이전에는 4대의 H200이 필요했던 동일한 요청량을 이제 1대에서 처리할 수 있습니다. 4배의 효율성 향상이 무료 티어를 경제적으로 가능하게 만든 것입니다. 이는 보조금이 아닌 구조적인 비용 절감의 결과입니다. 무료 액세스 기간은 이러한 단위 경제성이 작동함을 반영합니다. 현재 가용성에 대해서는 요금제를 확인하세요.
Fish Audio의 추론 스택 비교
인프라 데이터는 2026년 6월 기준 공개 문서, GitHub 저장소 및 엔지니어링 블로그를 바탕으로 함.
| Fish Audio S2.1 Pro | ElevenLabs | OpenAI TTS | Google Cloud TTS | |
|---|---|---|---|---|
| 추론 아키텍처 | 연속 배칭 (sglang 기반) | 미공개 | 미공개 | 미공개 |
| 커스텀 추론 커널 | ✅ fish-scales-ops (오픈 소스) | 미공개 | 미공개 | 미공개 |
| FP8 양자화 | ✅ bsgemm + mxfp8 | 미공개 | 미공개 | 미공개 |
| GPU 인프라 | 자체 소유, 약 500개 카드, 멀티 DC | 클라우드 호스팅 | 자체 소유 (Azure) | 자체 소유 (TPU) |
| 오픈 소스 서빙 스택 | ✅ 부분적 (fish-scales-ops) | ✗ | ✗ | ✗ |
| 공개된 처리량 벤치마크 | ✅ 8,006 tok/s (c=64, H200 기준) | 미공개 | 미공개 | 미공개 |
패턴은 일관됩니다: Fish Audio는 추론 아키텍처를 공개적으로 문서화하고, 커널 라이브러리를 오픈 소스로 제공하며, 구체적인 처리량 수치를 발표한 유일한 주요 TTS 제공업체입니다. "미공개"는 비판이 아니라 검증 가능한 정보에 대한 관찰입니다. 제공업체별 음성 품질에 대한 독립적인 평가는 우리의 블라인드 TTS 제공업체 비교를 참조하세요.
오픈 소스 항목
fish-scales-ops를 지금 바로 사용할 수 있습니다: Hopper 및 Blackwell용 FP8 GEMM 및 FlashAttention, 상용 수준, CUDA Graph 캡처 안전 보장.
H200 또는 RTX 5090/6000 PRO에서 자기회귀 모델을 위한 추론 인프라를 구축하고 있다면, 표준 라이브러리와의 디코드 셰이프 성능 격차는 실재하며 이 커널들이 그 격차를 메워줄 것입니다.
라이브러리 포함 사항:
- FP8 GEMM: Hopper용 bsgemm (1×128 act × 128×128 wgt), Blackwell용 MXFP8 1×32 (OCP UE8M0)
- sm_120a용 MXFP8 FlashAttention: 연속 프리필, 페이지드 프리필(extend), 스트라이드-0 K/V 브로드캐스트를 통한 네이티브 GQA 페이지드 디코드
- 전체 과정에서 CUDA Graph 캡처 안전 보장
향후 계획
B300 지원이 로드맵에 있습니다. Blackwell의 네이티브 FP8 텐서 코어와 NVLink 5 대역폭은 처리량 곡선을 더욱 끌어올릴 것입니다.
추론 최적화는 계속됩니다. 고정된 벤치마크 수치는 목표가 아닌 저하 방지를 위한 게이트일 뿐입니다. 각 동시성 지점은 계속해서 경신해야 할 대상입니다.
더 많은 서빙 스택이 안정화됨에 따라 오픈 소스화를 검토 중입니다 — sglang_lite 수정 사항, DualAR 전용 배칭 로직, sm_120a CUDA 그래프 처리 등. 무료 티어를 지속 가능하게 만드는 인프라가 바로 커뮤니티가 그 위에서 무언가를 구축하기를 바라는 인프라이기 때문입니다.
무료 TTS API 시작하기
모델 문자열: s2.1-pro-free. 기존 Fish Audio API 호출에서 헤더 하나만 변경하면 됩니다.
python
import httpx
body = {
"text": "Hello, world!",
"reference_id": "your_model_id",
"format": "mp3",
}
with httpx.Client() as client:
res = client.post(
"https://api.fish.audio/v1/tts",
headers={
"Authorization": "Bearer <YOUR_API_KEY>",
"Content-Type": "application/json",
"model": "s2.1-pro-free",
},
json=body,
)
res.raise_for_status()
with open("output.mp3", "wb") as f:
f.write(res.content)
JavaScript
import { writeFile } from "fs/promises";
const body = {
text: "Hello, world!",
reference_id: "your_model_id",
format: "mp3",
};
const res = await fetch("https://api.fish.audio/v1/tts", {
method: "POST",
headers: {
Authorization: "Bearer <YOUR_API_KEY>",
"Content-Type": "application/json",
model: "s2.1-pro-free",
},
body: JSON.stringify(body),
});
if (!res.ok) {
throw new Error(`TTS request failed: ${res.status} ${await res.text()}`);
}
const buffer = Buffer.from(await res.arrayBuffer());
await writeFile("output.mp3", buffer);
83개 언어. 엄격한 사용량 제한 없음. 신용카드 필요 없음. 음성 클로닝 포함.
다른 모든 최첨단 TTS API는 첫 토큰부터 비용을 청구하지만, S2.1 Pro는 그렇지 않습니다.

