내 아파트에는 3개월 동안 약 190,000개의 팟캐스트 에피소드를 처리한 서버가 있습니다. 이는 대략 253,000시간 분량의 오디오입니다.

만약 이를 공개 전사 (Transcription) API를 통해 처리했다면, 제공업체에 따라 전사 비용만 해도 약 10,000달러에서 250,000달러 이상까지 나왔을 것입니다.

하지만 실제로 중요한 부분, 그리고 모두가 오해하고 있는 부분은 다음과 같습니다:

전사 (Transcription)는 결코 비용이 많이 드는 단계가 아니었습니다.

비용이 많이 드는 단계는 전사본이 생성된 '이후'에 일어나는 모든 일입니다. 로컬 AI (Local AI)를 단순한 인터넷 취미에서 이 프로젝트를 경제적으로 성립하게 만드는 유일한 방법으로 바꾼 깨달음이 바로 이것이었습니다.

저는 침실에서 챗봇 (Chatbot)을 실행하려던 것이 아니었습니다. 챗봇은 데모일 뿐입니다. 저는 파이프라인 (Pipeline)을 구축하고 있었고, 파이프라인은 하나의 기계입니다. 수십만 개의 파일을 기계에 투입하는 순간, 비용 구조는 더 이상 부수적인 요소가 아니라 제품 그 자체가 됩니다. 지루한 질문 하나가 모든 화려한 질문들을 묻어버립니다:

이것이 유용해질 수 있을 만큼 충분히 자주 실행할 여력이 있는가?

일반적인 API 접근 방식으로는, 솔직히 제 대답은 '편안하게는 불가능하다'였습니다. 그래서 저는 GPU를 구매했습니다.

전사본은 제품이 아니라 원재료입니다

저를 짜증 나게 했던 숫자부터 시작해 보죠. 백만 개의 에피소드가 아닙니다. 10만 개입니다.

팟캐스트 데이터에서 10만 개의 에피소드는 결승선이 아니라 '시작점'입니다. 작은 데이터셋은 일화(anecdotes)를 제공하지만, 대규모 데이터셋은 신호(signals)를 제공합니다. 언급, 브랜드, 반복되는 게스트, 스폰서, 문화적 급증, 시간에 따라 변화하는 주제 같은 것들 말이죠. 이를 확인하려면 볼륨(volume)이 필요합니다.

현재 제 데이터셋은 처리된 에피소드가 약 190,000개이며, 각 에피소드는 평균 약 80분입니다. 이는 1,520만 분의 오디오, 즉 약 253,333시간에 해당합니다.

이제 공개 전사 가격을 그 옆에 놓아보겠습니다. 일반적인 제공업체들을 통해 190,000개의 에피소드를 처리할 때 발생하는 비용은 다음과 같습니다:

• Groq Whisper Large v3 Turbo — 시간당 $0.04, 약 $10,133
• Groq Whisper V3 Large — 시간당 $0.111, 약 $28,120
• OpenAI gpt-4o-mini-transcribe — 분당 $0.003, 약 $45,600
• OpenAI gpt-4o-transcribe — 분당 $0.006, 약 $91,200
• OpenAI gpt-realtime-whisper — 분당 $0.017, 약 $258,400

여기서 사람들은 목록 중 가장 저렴한 항목을 두고 논쟁하기 시작합니다. 그리고 맞습니다, Groq는 자동 음성 인식 (ASR) 분야에서 진정으로 저렴합니다. 만약 전사 (transcription) 작업만이 필요하다면, 그 가격은 매우 인상적입니다.

하지만 가장 저렴한 전사 비용을 쫓는 것은 잘못된 수치를 최적화하는 것입니다. 왜냐하면 전사본은 원재료이기 때문입니다.

전사본이 생성되고 나면, 여전히 이를 정제하고, 저장하고, 청킹 (chunking)하고, 타임스탬프 (timestamp)를 보존하고, 검색을 실행하고, 주제를 추출하고, 브랜드를 감지하고, 인물을 식별하고, 요약을 생성하고, 엔티티 (entity)를 분류하고, 손상된 파일을 재시도하고, 스키마 (schema)를 변경하며, 첫 번째 추출 로직이 미흡했다는 것을 깨달았을 때 오래된 에피소드들을 다시 처리해야 합니다.

실제로 돈이 들어가는 곳은 바로 그 지점입니다. 모든 실패한 실행에는 비용이 따릅니다. 모든 스키마 오류에는 비용이 따릅니다. 모든 새로운 추출 아이디어는 전체 데이터셋에 곱해져 비용이 됩니다. 그리고 그 곱셈은 잔혹합니다. 190,000개의 에피소드 전체에 대해, 에피소드당 단 3센트의 추가 처리 비용만 발생해도 $5,700입니다. 10센트라면 $19,000입니다. 30센트라면 $57,000입니다. 1달러라면 $190,000입니다.

이 숫자들을 다시 보십시오. 에피소드당 30센트로 단 한 번의 재처리 (reprocessing)를 수행하는 데 $57,000가 듭니다. 가장 저렴한 전사 비용은 만 달러였습니다. 전사 비용은 결코 청구서의 전부가 아니었습니다. 워크플로 (workflow) 가 청구서였으며, 워크플로는 한 번 이상 실행됩니다.

이것이 제가 스택 (stack)을 소유하는 것이 실제로 돈을 아껴주었다고 말하는 이유입니다. 가장 저렴한 API가 첫 번째 실행에서 엄청난 비용을 발생시켰기 때문이 아닙니다. 그렇지 않을 것입니다. 절감액은 아무도 가격을 인용하지 않는 부분, 즉 두 번째 실행, 세 번째 실행, 그리고 첫 번째 버전이 잘못되었다는 것을 깨달은 후의 재처리 과정에서 나왔습니다.

왜냐하면 파이프라인의 첫 번째 버전은 항상 어딘가 잘못되어 있기 때문입니다. 유일한 질문은, 그 잘못됨이 계속 진행할 수 있을 만큼 충분히 저렴한가 하는 것입니다.

나는 실험할 권한을 빌리고 싶지 않았다

나는 API에 반대하는 것이 아닙니다. 대부분의 초기 제품에는 API가 정답입니다. 아이디어를 검증하거나, 한 번에 하나의 업로드를 처리하거나, 워크로드 (workload)가 적은 경우에는 API를 사용하십시오. 아무도 관심을 갖는지 알기도 전에 하드웨어를 구매한다고 해서 상을 주는 것은 아닙니다.

하지만 제품이 지저분한 데이터를 지속적으로 처리해야 할 때, 가장 비싼 반복 단계를 영원히 빌리는 것은 당신이 실제로 무엇을 빌리고 있는지를 생각하면 잘못된 것처럼 느껴지기 시작합니다.

당신은 실험할 권한을 빌리고 있는 것입니다.

API 청구서는 해당 실행이 유용했는지 여부에 신경 쓰지 않습니다. 사용자가 요청한 기능을 출시 중이었든, 중간에 중단된 작업을 복구 중이었든 똑같이 비용을 청구합니다. 그래서 당신은 보수주의가 당신을 망치는 바로 그 단계에서 보수적으로 변하게 됩니다.

초기에는 빠르게 틀려야 합니다. 데이터 형태 (data shape)를 바꾸십시오. 투박한 실험을 수행하십시오. 출력을 응시하며 당신의 가설 절반이 멍청했다는 사실을 받아들이십시오. 만약 모든 수정 작업이 비싸게 느껴진다면, 당신은 학습으로부터 자신을 보호하기 위해 조용히 방어 기제를 작동시키기 시작할 것입니다. 그것이 함정입니다.

나는 나의 핵심 병목 현상 (bottleneck)이 타인의 가격 페이지에 머물러 있는 것을 원하지 않았습니다. 그래서 나는 오디오 처리를 직접 소유하기로 결정했습니다.

서버

이것은 아름다운 엔터프라이즈 장비가 아닙니다. 시간이 흐르면서 서서히 저주가 풀려가고 있는, 실무용 박스입니다. 사양은 다음과 같습니다: TRX40 Aorus Master 메인보드, Threadripper 3960X, 64GB RAM, 2TB 스토리지, 그리고 GPU — 세 개의 RTX 4060 Ti 16GB 카드와 한 개의 NVIDIA A30 24GB 카드입니다. 대략적인 하드웨어 비용은 €3,000에서 €4,000 사이입니다.

A30이 특이한 녀석입니다. 나는 2024년에 아무도 원하지 않고 로컬 AI (local AI)가 아직 열풍이 아니었을 때 eBay에서 약 €1,000에 그것을 샀습니다. 내가 했던 최고의 하드웨어 구매였습니다.

€3,000에서 €4,000가 아무것도 아니라고 거짓말하지는 않겠습니다. 개인 개발자(solo builder)에게 그것은 정말 중대한 결정입니다. 하지만 이는 매달 GPU를 대여하는 것과는 근본적으로 다른 결정입니다. 대여하는 GPU는 시간당으로는 저렴해 보이지만, 연간으로 따지면 가혹하기 때문입니다.

RunPod의 온디맨드(on-demand) 가격을 예로 들어보겠습니다. A40를 시간당 $0.44에 사용하면 24시간 7일 가동 시 한 달에 약 $321, 일 년에 $3,854가 듭니다. RTX A6000를 시간당 $0.49에 사용하면 한 달에 약 $358, 일 년에 $4,292가 듭니다. RTX 4090를 시간당 $0.69에 사용하면 한 달에 약 $504, 일 년에 $6,044가 듭니다. A100 SXM을 시간당 $1.49에 사용하면 한 달에 약 $1,088, 일 년에 $13,052가 듭니다.

GPU 한 대를 1년 동안 사용하는 비용은 대략 제 4-GPU 박스 전체 비용과 맞먹습니다. 그리고 대여한 GPU 한 대는 계측기를 신경 쓰지 않고 마음껏 몰아붙일 수 있는 로컬 머신(local machine)과는 다릅니다. 스토리지(storage), 유휴 시간(idle time), 오케스트레이션(orchestration), 그리고 실수들을 더하면 그 격차는 더욱 벌어집니다.

로컬 서버는 초기에 고통이 집중됩니다. 대여는 결코 멈추지 않는 계측기입니다. 실험을 위해서라면, 저는 기꺼이 그 고통을 감수하겠습니다.

[

Server with 3x 4060TI's (16GB) and 1x A30 (24GB)]

낭만적이지 않은 부분

A30에는 액티브 쿨링(active cooling) 기능이 없습니다. 일반적인 케이스 안에서 카드가 스스로를 익히기 시작하기 전까지는 별것 아닌 디테일처럼 들릴 것입니다. 저는 덕트 송풍 팬(duct blower fans)을 카드에 직접 연결해야 했습니다. 보기 좋지는 않았습니다. 그 당시의 실제 질문은 이것이었습니다: '이제 GPU가 살아남을 수 있는가?' '예?' 그렇다면 계속 진행합니다.

이것이 실제 로컬 AI(local AI)의 모습입니다. 벤치마크(benchmarks)나 깔끔한 홈랩(homelab) 사진 같은 것이 아닙니다. 공기 흐름(airflow), CUDA 버전, NVIDIA 드라이버, 큐(queue) 동작, 끊긴 다운로드, 청킹(chunking)이 필요한 3시간짜리 에피소드, 그리고 죽은 작업을 영원히 재시도해서는 안 되는 워커(workers)들이 존재하는 현실입니다.

원격 접속(remote access) 또한 선택 사항이 아닙니다. Tailscale은 제가 머신에서 떨어져 있을 때 여러 번 저를 구해주었습니다. VPN을 구축하든, 원격 전원 스위치를 추가하든, 모니터링을 설정하든, 무엇이든 적합한 것을 사용하되, 문제가 발생했을 때 당신이 머신 옆에 서 있지 않을 상황에 대비한 계획을 세워두어야 합니다.

깔끔한 버전을 원한다면 API를 사용하세요. 레버리지(leverage)를 원한다면, 이 난장판을 직접 감당해야 합니다.

그 결과로 탄생한 파이프라인 (pipeline)

이제 이 파이프라인은 지루할 정도로 평범해졌는데, 이것이 바로 제가 원했던 모습입니다.

RSS 피드에서 에피소드가 도착합니다. 오디오가 다운로드되고, FFmpeg를 통해 정규화(normalized)된 후 RabbitMQ에 큐(queue)로 쌓입니다. Go 워커(workers)들이 작업을 가져와 비어 있는 GPU로 전송합니다. WhisperX가 타임스탬프가 포함된 출력값과 함께 전사(transcription)를 처리합니다. 전사된 텍스트는 저장되고, 정제(cleaned) 및 청킹(chunked)된 후 Postgres 전문 검색(full-text search)을 위해 인덱싱(indexed)됩니다. 그 다음 클라우드 LLM 추론(inference)이 구조화된 추출(structured extraction) 레이어를 처리합니다: 주제(topics), 엔티티(entities), 브랜드 언급, 질문, 요약 및 예측 가능한 형태로 저장되어야 하는 기타 필드들입니다.

그 예측 가능한 형태가 핵심입니다. 귀여운 AI 요약은 한 번 보기에는 좋지만, 이를 기반으로 무언가를 구축하는 것은 불가능합니다. 저는 테이블, 타임스탬프, 슬러그(slugs), 엔티티를 원합니다. 검색, 알림, 내보내기, 그리고 다음에 어떤 기능이 추가되더라도 이를 뒷받침할 수 있는 필드들을 원합니다.

이것이 텍스트를 생성하기 위해 AI를 사용하는 것과, 인프라를 구축하기 위해 AI를 사용하는 것 사이의 경계입니다.

또한 시맨틱 검색(semantic search)을 위해 Pinecone을 사용한 임베딩(embeddings)과 리랭킹(reranking)을 위한 Cohere를 테스트해 보았는데, 결과는 좋았습니다. 하지만 저는 그 작업을 중단했습니다. 사용자들이 처음부터 우아한 버전을 요구하지 않았기 때문입니다. 그들은 유용한 버전을 원했습니다: 이 내용이 어디서 언급되었는지, 그들이 무엇을 말했는지, 어떤 에피소드인지, 내보낼 수 있는지, 시간이 지남에 따라 추적할 수 있는지와 같은 것들 말입니다. 개발자들은 아름다운 아키텍처를 사랑하지만, 사용자는 문제가 사라지는 것을 사랑합니다.

현재 이 박스(box)는 길이나 오디오 품질에 따라 30분마다 대략 50개에서 120개의 에피소드를 처리합니다. 좋은 점은 확장(scaling) 방식이 명확하다는 것입니다. 유사한 서버를 하나 더 추가하면 처리량(throughput)이 대략 두 배가 됩니다. 마법도 아니고 공짜도 아니지만, 예측 가능합니다. 그 예측 가능성은 제가 예상했던 것보다 더 중요했습니다.

Telegram sentry report which runs every 30 mins, providing critical insights about the applications status such as processed episodes

여전히 클라우드에 비용을 지불하는 부분과 그 비용

모든 것을 로컬에서 실행하는 것은 아닙니다. 초기에는 제가 똑똑하게 행동하고 있다고 생각해서 로컬 LLM (Large Language Models)을 시도해 보았지만, 제가 편하게 실행할 수 있는 더 작은 모델들은 구조화된 출력 (structured output)을 생성할 때 너무 많은 쓰레기 데이터를 만들어냈습니다. 잘못된 구조화된 출력은 아예 없는 것보다 더 나쁩니다. 왜냐하면 데이터베이스를 조용히 오염시키기 때문입니다.

그래서 저는 한 가지 질문을 기준으로 스택을 나누었습니다: 어떤 부분이 소유하는 것이 경제성을 변화시킬 만큼 충분히 비싸지는가?

로컬 서버는 볼륨(volume)이 비용을 폭증시키는 부분, 즉 전사 (transcription) 및 반복적인 오디오 처리를 담당합니다. 클라우드 추론 (inference)은 소유보다 품질이 중요한 부분, 즉 더 강력한 모델을 사용한 구조화된 추출 (structured extraction)을 담당합니다. 저는 이를 위해 Qwen 모델이 탑재된 Nebius AI를 사용하며, 그 외에는 평범하고 지루한 클라우드 요소들인 AWS, Postgres, 앱 호스팅을 사용합니다.

이것이 대부분의 분석(teardowns)에서 생략하는 비용의 경계선입니다. 명확히 말씀드리자면, 클라우드 추출은 제가 여전히 실행당 비용을 지불하는 단계이며, 이를 실행당 비용으로 유지하는 것은 의도적인 선택입니다. 로컬 장비가 이미 원시 볼륨에 따라 확장되는 부분을 흡수했기 때문에, 남은 클라우드 비용은 모든 재시도와 재처리 과정이 아니라, 더 나은 모델로부터 진정으로 이득을 얻는 작업에만 한정되어 유지됩니다. 이 분할이 하나의 결정에 담긴 경제적 논거의 전부입니다.

로컬 AI가 순수주의자처럼 책상 아래에서 모든 것을 실행하는 것을 의미하지는 않습니다. 그것은 너드(nerd)들의 종교입니다. 실용적인 버전은 외과 수술처럼 정교합니다: 병목 현상 (bottleneck)이 발생하는 지점은 소유하고, 나머지는 빌려 쓰는 것입니다.

해자(Moat)는 단지 틀릴 비용을 감당할 수 있는 능력일 뿐이다

사람들은 해자를 신비로운 것처럼 말합니다. 때때로 해자는 단순히 다른 사람들이 계속하기에는 감당할 수 없는 비용을 지불할 능력이 있는 것일 뿐입니다.

데이터 집약적인 동일한 문제에 직면한 두 명의 빌더(builders)가 있다고 가정해 봅시다. 한 명은 모든 처리 단계마다 소매가(retail price)를 지불합니다. 다른 한 명은 비싼 병목 지점을 소유하고 있습니다. 이들은 같은 게임을 하고 있는 것이 아닙니다. 한 명은 매 실험을 하기 전에 인보이스(invoice)에 허락을 구하지만, 다른 한 명은 그냥 작업을 실행합니다.

그러한 차이는 행동 양식으로 축적됩니다. 당신은 더 많은 시도를 하게 됩니다. 바보가 된 것 같은 기분 없이 데이터를 재처리(reprocess)할 수 있습니다. 첫 번째 스키마(schema)가 틀렸더라도 괜찮습니다. 추출 필드(extraction field)를 추가하고 실제 데이터 볼륨(volume)에 걸쳐 테스트할 수 있습니다. 데이터셋이 이미 존재하기 때문에 데이터셋에서 직접 기능을 구축할 수 있습니다.

서버는 단순히 처리 비용을 낮춰준 것이 아닙니다. 틀리는 비용을 낮춰주었습니다. 초기 제품들은 끊임없이 틀립니다. 잘못된 기능, 잘못된 스키마, 잘못된 쿼리(query), 잘못된 가설 등 말입니다. 모든 수정 작업이 비용이 많이 든다면, 당신은 더 느리게 배우게 됩니다. 틀리는 비용을 낮추면 두려움 없이 움직일 수 있습니다. 그것이 진정한 레버리지(leverage)이며, 제가 하드웨어를 구매한 유일한 이유입니다.

이것이 어떻게 제품이 되었는가