Insanely Fast Whisper: Whisper를 빠르게 동작하는 wrapper cli

AI 음성 전사는 이제 “된다”의 문제가 아니라 “얼마나 빨리, 얼마나 실용적으로, 얼마나 쉽게 붙일 수 있느냐”의 문제로 넘어왔습니다.
insanely-fast-whisper는 바로 그 지점을 찌르는 프로젝트입니다. Whisper를 단순히 잘 돌리는 수준이 아니라, GPU 배치 처리와 최신 attention 구현을 활용해 긴 오디오도 매우 빠르게 전사할 수 있는 형태로 밀어붙였습니다. README에서는 A100 80GB 기준으로 150분 오디오를 Whisper Large v3 + Flash Attention 2 조합으로 98초 안에 처리했다고 소개합니다. (GitHub)

이 프로젝트가 흥미로운 이유는 단순합니다.
많은 개발자가 Whisper를 좋아하지만, 실제 서비스나 내부 툴에 붙이려는 순간 설치, GPU 설정, 배치 처리, 타임스탬프, 화자 분리 같은 현실적인 문제가 쏟아집니다. insanely-fast-whisper는 그 복잡함을 꽤 과감하게 잘라내고, “빠르게 전사하는 데 필요한 기본 선택지”를 미리 정해 둔 opinionated CLI로 제공합니다. (GitHub)

https://github.com/Vaibhavs10/insanely-fast-whisper

GitHub - Vaibhavs10/insanely-fast-whisper

 

 

프로젝트 소개

insanely-fast-whisper는 Vaibhav Srivastav(VB)와 Patrick Arminio가 만든 오픈소스 CLI 패키지로, Whisper 계열 모델을 로컬 GPU에서 빠르게 실행하기 위한 도구입니다. 패키지 메타데이터 기준 현재 공개 버전은 0.0.15이며, Python 3.8 이상을 요구하고 transformers, accelerate, pyannote-audio, rich 등을 주요 의존성으로 사용합니다. 엔트리포인트는 insanely-fast-whisper = insanely_fast_whisper.cli:main으로 등록되어 있습니다. (GitHub)

이 프로젝트가 해결하려는 문제는 꽤 명확합니다.
Whisper는 정확도가 좋지만, 긴 오디오를 빠르게 처리하려면 모델 선택, dtype, attention 구현, chunking, batch size, 디바이스 설정 같은 옵션을 잘 조합해야 합니다. 이 저장소는 그 조합을 CLI로 감싸서, 사용자가 파일 경로만 넘겨도 실전형 전사 파이프라인을 빠르게 실행할 수 있게 합니다. README에서도 이 프로젝트가 처음에는 Transformers 성능 벤치마크를 보여주기 위한 저장소였지만, 이후 실제로 쓸 수 있는 경량 CLI로 발전했다고 설명합니다. (GitHub)

개발 환경 관점에서 보면 이 도구는 범용 음성 처리 프레임워크라기보다 NVIDIA CUDA GPU와 Apple Silicon MPS를 중심으로 한 고성능 전사용 런처에 가깝습니다. README는 CLI가 “highly opinionated”하며 NVIDIA GPU와 Mac에서 동작한다고 명시하고 있습니다. 반대로 말하면 CPU-only 환경이나 광범위한 하드웨어 호환성을 목표로 한 프로젝트는 아닙니다. 실제로 오픈 이슈에도 CPU 전용 지원 요청, MPS 안정성 문제, 오프라인 사용 요청 등이 남아 있습니다. (GitHub)

왜 이 프로젝트가 등장했을까

Whisper가 인기를 얻은 뒤 많은 팀이 공통으로 겪은 문제가 있습니다.

첫째, 정확한 모델을 빠르게 돌리는 것 자체가 생각보다 번거롭습니다.
기본 transformers 파이프라인만 써도 전사는 가능하지만, 긴 오디오를 실무에서 처리하려면 fp16, batching, 더 빠른 attention 구현 같은 최적화가 필요합니다. README의 벤치마크를 보면 같은 Whisper Large v3라도 fp32 Transformers 대비, fp16 + batching + Flash Attention 2 조합이 훨씬 빠릅니다. 이 저장소는 그런 최적화 조합을 일반 개발자도 바로 쓸 수 있게 포장한 결과물입니다. (GitHub)

둘째, Whisper를 서비스 코드에 붙이기 전에 CLI가 먼저 필요합니다.
실제로 많은 팀은 “모델 서빙” 이전에 회의 녹음, 인터뷰 파일, 팟캐스트, 고객 통화 파일을 로컬이나 배치 환경에서 먼저 처리해 봅니다. 이때 필요한 것은 대규모 MLOps 시스템보다도, 파일 하나 넣으면 빠르게 결과 JSON을 뽑아주는 도구입니다. insanely-fast-whisper는 그 요구에 매우 잘 맞습니다. (GitHub)

셋째, 오디오 전사는 텍스트 생성보다 I/O와 후처리가 더 귀찮습니다.
단순히 텍스트만 나오면 끝이 아니라, chunk timestamp, word timestamp, 번역 task, 언어 지정, 화자 분리, 결과 JSON 저장까지 함께 다뤄야 합니다. 이 프로젝트는 그 흐름을 CLI 옵션으로 노출하고, 결과를 구조화된 JSON으로 저장하도록 만들어 실무 활용성을 높였습니다. (GitHub)

핵심 기능

1. Whisper 전사를 위한 초고속 CLI

가장 핵심은 단연 CLI입니다.
기본 모델은 openai/whisper-large-v3이고, transformers.pipeline("automatic-speech-recognition")를 사용해 전사를 수행합니다. 디바이스는 cuda:{id} 또는 mps를 선택하며, dtype은 torch.float16으로 고정되어 있습니다. 즉, 이 도구는 “정확한 범용 설정기”라기보다 고속 전사에 유리한 선택을 기본값으로 박아둔 CLI입니다. (GitHub)

insanely-fast-whisper --file-name meeting.mp3

이 한 줄만으로도 기본 전사는 가능하고, 결과는 기본적으로 output.json에 저장됩니다. 파일 경로뿐 아니라 URL도 받을 수 있도록 설계되어 있습니다. (GitHub)

2. Flash Attention 2와 SDPA를 활용한 가속

코드를 보면 --flash True일 때 model_kwargs={"attn_implementation": "flash_attention_2"}를 사용하고, 그렇지 않으면 {"attn_implementation": "sdpa"}를 사용합니다. 즉, 이 프로젝트의 속도 전략은 “Whisper를 새로 구현”한 것이 아니라, Hugging Face Transformers 파이프라인 위에서 최신 attention 백엔드를 적극 활용하는 방식입니다. (GitHub)

이 점이 중요합니다.
이 프로젝트는 완전히 새로운 추론 엔진이라기보다, Transformers 생태계의 최적화를 Whisper 워크로드에 맞게 실용적으로 엮어낸 래퍼입니다. 그래서 개발자 입장에서는 내부를 이해하기도 쉽고, 필요하면 나중에 Python 코드로 직접 옮겨 가기도 쉽습니다. README도 CLI 없이 같은 방식을 Python 코드로 사용할 수 있는 예제를 함께 제공합니다. (GitHub)

3. 배치 처리 중심 설계

CLI 옵션에서 --batch-size 기본값이 24로 설정되어 있고, 실제 파이프라인 호출에서도 batch_size=args.batch_size, chunk_length_s=30으로 실행됩니다. 긴 오디오를 30초 청크로 나누고, 이를 배치로 묶어 병렬 처리하는 구조라고 이해하면 됩니다. (GitHub)

이 구조는 왜 빠를까요?
Whisper 전사의 병목은 모델 추론뿐 아니라, 긴 오디오를 순차적으로 처리할 때 GPU 활용률이 낮아지는 데 있습니다. 이 프로젝트는 청크 단위 처리와 batch size 조절을 통해 GPU를 더 적극적으로 사용하도록 유도합니다. README의 여러 벤치마크 수치가 크게 차이 나는 이유도 사실상 이 지점에 있습니다. 다만 메모리 사용량과의 트레이드오프가 있고, README도 OOM이 나면 batch size를 줄이라고 안내합니다. (GitHub)

4. 화자 분리 지원

이 프로젝트는 단순 전사만 하는 것이 아니라, Hugging Face 토큰을 넘기면 pyannote 기반 화자 분리도 수행할 수 있습니다. 기본 화자 분리 모델은 pyannote/speaker-diarization-3.1이며, --num-speakers, --min-speakers, --max-speakers 옵션으로 화자 수를 제어할 수 있습니다. (GitHub)

구현을 보면 전사 결과의 chunk timestamp와 diarization segment를 후처리로 정렬해서, speaker 정보가 포함된 결과를 JSON에 합쳐 넣습니다. 즉, ASR과 diarization이 하나의 end-to-end 모델에서 동시에 나오는 것이 아니라, 후처리 결합 방식입니다. 이 구조는 단순하고 이해하기 쉽지만, 타임스탬프 경계가 애매한 파일에서는 정렬 오차가 생길 수 있습니다. 실제로 관련 이슈도 존재합니다. (GitHub)

5. word/chunk 타임스탬프와 번역 태스크

--timestamp는 chunk 또는 word를 지원하고, --task는 transcribe와 translate를 지원합니다. 언어는 지정하지 않으면 Whisper 자동 감지를 사용합니다. 코드에서는 영어 전용 모델일 경우 task를 제거하는 처리도 들어 있습니다. (GitHub)

이 기능이 실무에서 좋은 이유는 분명합니다.
짧은 자막 생성이라면 chunk timestamp면 충분하지만, 편집기 연동이나 하이라이트 추출, 검색 인덱싱까지 가려면 word timestamp가 훨씬 유용합니다. 반대로 word timestamp는 더 무겁기 때문에, 이 옵션을 노출한 설계는 꽤 실용적입니다. (GitHub)

프로젝트 아키텍처 분석

이 저장소의 내부 구조는 놀랄 만큼 단순합니다.
거대한 프레임워크가 아니라 “CLI → Transformers ASR 파이프라인 → optional diarization → JSON 결과 저장” 흐름으로 구성되어 있습니다. 핵심 로직 대부분이 cli.py, diarization_pipeline.py, diarize.py, result.py에 모여 있어 코드 추적도 어렵지 않습니다. (GitHub)

조금 더 자세히 뜯어보면 다음과 같습니다.

1) CLI 계층

argparse로 파일명, 디바이스, 저장 경로, 모델명, task, language, batch size, flash 사용 여부, timestamp 방식, diarization 옵션을 받습니다. 이 단계에서 speaker 관련 옵션의 상호 배타성도 검사합니다. 즉, 입력 검증은 매우 얇지만 실용적인 수준으로 들어 있습니다. (GitHub)

2) ASR 실행 계층

실제 전사는 transformers.pipeline("automatic-speech-recognition", ...)로 생성한 파이프라인이 맡습니다.
여기서 중요한 선택은 세 가지입니다.

• torch.float16
• cuda 또는 mps 디바이스 고정
• flash_attention_2 또는 sdpa 선택

이 프로젝트의 성능 정체성은 거의 이 한 블록에서 결정됩니다. (GitHub)

3) 오디오 입력 전처리 계층

diarize.py를 보면 입력은 로컬 파일, URL, bytes, NumPy 배열, 그리고 datasets 스타일 dict까지 받을 수 있습니다. bytes 입력은 ffmpeg_read로 16kHz 오디오로 변환하고, 샘플링 레이트가 16kHz가 아니면 resample합니다. diarization 쪽은 단일 채널(float32) waveform으로 맞춰 pyannote에 넘깁니다. (GitHub)

즉, 외형은 단순한 CLI지만 내부적으로는 입력 포맷을 꽤 유연하게 처리합니다. 이 덕분에 나중에 Python API로 재사용할 때도 확장성이 있습니다. (GitHub)

4) 화자 분리 후처리 계층

화자 분리 결과는 pyannote가 반환한 segment들을 기반으로, 연속된 동일 화자 구간을 합치고, 그 뒤 Whisper chunk timestamp와 가장 가까운 지점을 찾아 정렬합니다. 이 방식은 구현이 간단하고 CLI 도구에 잘 맞지만, 근본적으로는 근사 정렬입니다. 정밀한 강제 정렬이나 VAD 기반 세밀한 세그먼트 정합과는 다릅니다. (GitHub)

5) 결과 생성 계층

최종 결과는 매우 단순한 JSON입니다.

• speakers
• chunks
• text

이 세 필드로 구성됩니다. 즉, 사람이 읽기 좋은 plain text와, 기계가 쓰기 좋은 timestamp/chunk 구조를 동시에 제공합니다. 실무에서 후처리 파이프라인으로 넘기기 좋은 형태입니다. (GitHub)

코드로 보면 더 잘 보이는 사용 방식

가장 기본적인 사용은 아래와 같습니다.

pipx install insanely-fast-whisper
insanely-fast-whisper --file-name interview.mp3

macOS Apple Silicon에서는 MPS를 명시해야 합니다.

insanely-fast-whisper \
  --file-name interview.mp3 \
  --device-id mps \
  --batch-size 4

README는 MPS가 CUDA보다 메모리를 더 많이 쓰므로 보통 --batch-size 4 정도를 권장한다고 안내합니다. (GitHub)

Flash Attention 2를 켜서 더 빠르게 돌리고 싶다면 다음처럼 사용할 수 있습니다.

insanely-fast-whisper \
  --file-name long_podcast.mp3 \
  --flash True

distil-whisper 계열로 더 빠른 처리량을 노릴 수도 있습니다.

insanely-fast-whisper \
  --model-name distil-whisper/large-v2 \
  --file-name long_podcast.mp3 \
  --flash True

이 조합은 정확도와 속도 중 속도 쪽에 더 무게를 싣는 선택으로 이해하면 됩니다. README 벤치마크에서도 distil-large-v2가 매우 빠른 축에 속합니다. (GitHub)

화자 분리까지 함께 쓰려면 다음 흐름이 됩니다.

insanely-fast-whisper \
  --file-name panel_discussion.mp3 \
  --hf-token YOUR_HF_TOKEN \
  --timestamp word \
  --min-speakers 2 \
  --max-speakers 4

이 경우 결과 JSON에는 화자 정보와 timestamp가 함께 들어갑니다. (GitHub)

CLI 없이 Python으로 직접 쓰는 방법

이 저장소를 보고 가장 좋은 점 중 하나는, 내부 구현이 너무 복잡하지 않아서 Python 코드로 쉽게 흡수할 수 있다는 점입니다. README에도 거의 같은 방식의 예제가 실려 있습니다. (GitHub)

import torch
from transformers import pipeline
from transformers.utils import is_flash_attn_2_available

pipe = pipeline(
    "automatic-speech-recognition",
    model="openai/whisper-large-v3",
    torch_dtype=torch.float16,
    device="cuda:0",
    model_kwargs=(
        {"attn_implementation": "flash_attention_2"}
        if is_flash_attn_2_available()
        else {"attn_implementation": "sdpa"}
    ),
)

outputs = pipe(
    "meeting.mp3",
    chunk_length_s=30,
    batch_size=24,
    return_timestamps=True,
)

print(outputs["text"])

실제 서비스에서는 이 코드를 기반으로 다음처럼 발전시키면 됩니다.

• 업로드된 파일을 S3나 Blob Storage에서 읽기
• 결과를 JSON 대신 DB에 저장
• word timestamp 기반으로 검색 인덱스 생성
• diarization 결과와 합쳐 화자별 회의록 생성

즉, insanely-fast-whisper는 “그 자체가 완성형 서비스”라기보다, 프로덕션용 음성 처리 파이프라인의 출발점으로 보는 편이 더 정확합니다. (GitHub)

이 프로젝트의 강점

가장 큰 강점은 단순함 대비 효율이 높다는 점입니다.
직접 Whisper 최적화 실험을 해본 개발자라면 알겠지만, 대부분의 성능 개선은 새 알고리즘보다도 좋은 기본값, 배치 전략, attention 구현, 디바이스 설정에서 나옵니다. 이 프로젝트는 바로 그 “귀찮은 최적화 조합”을 미리 제공해 줍니다. (GitHub)

두 번째 강점은 Transformers 생태계와의 정렬입니다.
별도 추론 엔진에 종속되지 않고 Hugging Face 파이프라인을 중심으로 구성되어 있어서, 모델 교체나 Python 코드 이관이 쉽습니다. openai/whisper-large-v3뿐 아니라 distil-whisper/large-v2 같은 모델도 바로 CLI에서 바꿔 쓸 수 있습니다. (GitHub)

세 번째 강점은 화자 분리까지 한 번에 갈 수 있다는 점입니다.
회의록, 인터뷰, 팟캐스트 편집, 고객센터 통화 분석처럼 “누가 말했는지”가 중요한 경우, 단순 텍스트 전사만으로는 가치가 반쪽입니다. 이 프로젝트는 pyannote 통합으로 그 간극을 꽤 현실적으로 메웁니다. (GitHub)

아쉬운 점과 현실적인 한계

반대로 한계도 분명합니다.

첫째, 정말로 opinionated 합니다.
CPU 환경을 넓게 지원하거나, 모든 OS/하드웨어에서 부드럽게 돌아가는 범용 도구로 보기는 어렵습니다. README도 NVIDIA GPU와 Mac 중심임을 밝히고 있고, 오픈 이슈에는 CPU 전용 지원 요청과 macOS/MPS 관련 문제가 계속 남아 있습니다. (GitHub)

둘째, 성능 수치는 강력하지만 항상 apples-to-apples 비교는 아닐 수 있습니다.
오픈 이슈 중에는 벤치마크가 batch size나 beam size 차이의 영향을 받는 것 아니냐는 문제 제기도 있습니다. 즉, README 수치는 충분히 인상적이지만, 실서비스 도입 전에는 본인 워크로드에서 직접 재측정하는 것이 맞습니다. (GitHub)

셋째, 정확도와 WER보다 속도 이야기가 더 전면에 나와 있습니다.
최근 오픈 이슈에도 “속도는 보이는데 WER는 어떤가?”라는 질문이 올라와 있습니다. 이 프로젝트는 이름 그대로 speed-first 도구에 가깝기 때문에, 법률 녹취나 의료 기록처럼 정확도 검증이 중요한 도메인에서는 별도 평가가 필수입니다. (GitHub)

넷째, 화자 분리는 후처리 결합 방식이라 경계 정렬이 아주 정교하지는 않습니다.
코드상으로도 diarization segment 끝점과 ASR chunk timestamp를 가장 가까운 값으로 맞추는 구조입니다. 빠르고 단순하다는 장점은 있지만, 정교한 forced alignment가 필요한 시나리오에서는 한계를 느낄 수 있습니다. (GitHub)

언제 사용하면 좋은가

이 프로젝트는 특히 아래 상황에서 빛납니다.

1. 내부 배치 전사 파이프라인이 필요할 때

회의 녹음, 강의, 인터뷰, 팟캐스트 파일을 한꺼번에 처리해 JSON으로 쌓아야 한다면 아주 적합합니다. 파일 하나당 API 호출을 날리는 방식보다, 로컬 GPU에서 배치 전사하는 편이 비용과 처리량 면에서 유리할 수 있습니다. (GitHub)

2. Whisper 실험을 빨리 시작하고 싶을 때

모델 최적화나 attention 백엔드 설정까지 직접 건드리기 전에, “현재 GPU에서 Whisper를 얼마나 빠르게 돌릴 수 있나?”를 확인하는 출발점으로 좋습니다. 애초에 이 프로젝트 자체가 Transformers 기반 Whisper 최적화 벤치마크에서 출발했기 때문입니다. (GitHub)

3. 프로덕션 전 단계의 MVP를 만들 때

정식 서빙 인프라를 구축하기 전에, 파일 업로드 → 전사 → 화자 분리 → JSON 저장까지 묶인 프로토타입을 빠르게 만들 수 있습니다. README의 커뮤니티 쇼케이스에도 이 도구 위에 CLI 앱, Next.js + Modal 기반 앱, Python 패키지 형태의 확장 사례가 소개되어 있습니다. (GitHub)

반대로 아래 상황이라면 다른 선택지가 더 나을 수 있습니다.

• CPU-only 환경이 반드시 필요할 때
• 정확도/재현성 검증이 최우선일 때
• 아주 정교한 diarization/alignment가 필요할 때
• 설치 안정성과 하드웨어 호환성이 더 중요할 때 (GitHub)

개발자 관점에서 본 핵심 해석

insanely-fast-whisper의 본질은 새로운 음성 인식 모델이 아닙니다.
이 프로젝트의 핵심은 Whisper를 실전에서 “빨리 쓸 수 있는 형태”로 만든 패키징에 있습니다. transformers 파이프라인, fp16, Flash Attention 2/SDPA, chunking, batching, diarization 후처리를 얇고 날카롭게 조합해 놓았습니다. 그래서 코드베이스는 작지만, 체감 가치는 큽니다. (GitHub)

좋은 오픈소스는 꼭 거대할 필요가 없습니다.
이 저장소는 “왜 이 정도 조합을 공식 예제로 바로 제공하지 않았지?” 싶은 부분을 커뮤니티 친화적인 CLI로 잘 끌어냈습니다. 그래서 개발자에게는 두 가지 의미가 있습니다.

하나는 당장 써먹을 수 있는 도구라는 점,
다른 하나는 Whisper 고속화 아키텍처를 이해하는 좋은 레퍼런스라는 점입니다. (GitHub)

마무리

Whisper 생태계에는 이미 좋은 프로젝트가 많습니다.
그런데 insanely-fast-whisper는 그중에서도 꽤 실용적인 위치를 차지합니다. 모델을 새로 발명하지도 않았고, 거대한 플랫폼을 만들지도 않았지만, 개발자가 실제로 부딪히는 “긴 오디오를 빨리 전사하고 싶다”는 요구를 아주 직접적으로 해결합니다. (GitHub)

한 줄로 요약하면 이렇습니다.

insanely-fast-whisper는 Whisper를 가장 화려하게 확장한 프로젝트라기보다, Whisper를 가장 빨리 실무에 데려오는 프로젝트에 가깝습니다. (GitHub)