스레드보다 자원: Mac GPU(MPS)로 3.5배 빠르게 - Resource First AI

GitHub - chessire/shelter-puppy

파이프라인을 빠르게 만드는 첫 질문은
"스레드를 몇 개 띄울까?"가 아니라
"어떤 자원이 어디서 놀고 있나?"입니다.

 

"느리면 그냥 멀티스레딩 돌리면 되는 거 아냐?"

 

이번 함정은 그 직관이 절반만 맞다는 데 있습니다. 스레드를 늘려도 공유 자원 앞에서는 줄만 서기 때문에 안 빨라지는 구간이 있습니다. 스레드와 무관하게 놀고 있던 자원(GPU)도 있습니다. 심지어 빨라졌는지 판정하는 것조차 같은 코드 실행에도 실행 속도가 2배 차이가 될 수 있는 함정이 있습니다. 이번 최적화로 자동 영상 편집에 8분 걸리던 파이프라인을 4분으로 줄였는데 결론부터 말하면 가장 큰 배수는 멀티스레딩이 아닌 한 줄 수정에서 나왔습니다.

 

스레드보다 먼저 자원의 지도를 그린다.
겹칠 수 있는 것만 겹치고,
결과는 완전히 동일해야 한다.

 

이번 편은 실사용 병목 3구간(전처리+검출, 관찰 프로필, 동작 판정)의 속도 최적화 기록입니다. 원칙은 하나로 요약됩니다. 단계 간 직렬은 유지하고, 단계 안에서만 병렬화한다. 파이프라인의 순서와 게이트 구조는 건드리지 않았습니다.

 

Multi-Threading vs Resources

---

16. 스레드보단 자원을 살펴보자 - 다섯 개의 자원

병렬화를 시작하기 전에 파이프라인이 쓰는 자원부터 그렸습니다. 다섯입니다. Ollama(Gemma, GPU), MLX(TTS, GPU), MPS(YOLO, GPU), ffmpeg(CPU 서브프로세스), OpenCV / Torch(CPU). 지도를 그리고 나니 제일 중요한 사실이 보였습니다. Ollama는 서버가 요청을 직렬로 처리하는 공유 자원입니다. 클라이언트에서 스레드를 아무리 늘려도 서버 앞에서 줄만 섭니다.

 

그래서 이번 최적화의 이득은 전부 한 곳에서 나왔습니다. Ollama 작업과 비-Ollama 작업을 겹치는 것. LLM이 크롭 하나를 판정하는 동안 CPU는 다음 영상의 모션 곡선을 계산하고, ffmpeg는 다음 영상을 정규화합니다. LLM을 빠르게 만든 게 아니라, LLM이 일하는 동안 다른 자원이 놀지 않게 만든 겁니다.

 

병렬화에도 안전을 위한 규칙을 먼저 세웠습니다. 병렬 구간은 meta파일을 만지지 않고 쓰기는 오케스트레이터가 루프 밖에서 한 번, 판정 로직은 입력이 전부 모인 뒤의 직렬 흐름 그대로 두고, 완료 순서는 비결정이어도 조립은 인덱스로 고정합니다. 그리고 합격 기준은 속도가 아니라 결과 동일성입니다. 빨라졌는데 결과가 달라졌다면 그건 최적화가 아니라 버그니까요.

---

17. 최대 병목은 병렬화가 아니었다 - 놀고 있는 GPU

전처리(ffmpeg)와 검출(YOLO)을 파이프라이닝했습니다. 영상 i를 검출하는 동안 영상 i+1을 정규화하는 구조는 교과서적인 이종 자원 오버랩입니다. 그런데 체감이 없다는 피드백이 왔습니다.

 

구간별 비중을 실측해 보니 범인은 따로 있었습니다. 검출 모델이 내내 CPU로 돌고 있었습니다. Mac에서 이 라이브러리의 디바이스 자동 선택은 GPU가 아니라 CPU였습니다. Apple GPU(MPS)를 쓰려면 명시해야 했습니다. 그래서 한 줄을 고쳤습니다. 157.9초 → 45.4초, 3.5배. 이번 최적화 전체에서 가장 큰 배수가 스레드 하나 없이 나왔습니다.

 

물론 검증은 시리즈의 규칙대로입니다. 골든셋 5영상을 GPU로 재검출해 재채점하여 박스 수, 트랙 수, miss/IDF1을 포함한 모든 지표가 소수 4자리까지 완전 동일했고, 게이트 판정도 그대로였습니다(예외 처리된 나쁜 footage의 FAIL까지 똑같이). 디바이스가 바뀌어도 자는 휘지 않았다는 확인입니다.

 

비슷한 사례가 하나 더 있었습니다. 모션 곡선이 프레임마다 랜덤 시크로 영상을 읽고 있었는데 랜덤 시크는 매번 키프레임부터 다시 디코드했습니다. 순차 읽기로 바꾸자 영상별로 4.6 -> 0.8초, 11.9 -> 1.7초, 약 6배. 이것도 병렬화가 아니라 직렬 최적화입니다. 교훈을 한 문장으로 정리하자면, [구조를 바꾸기 전에, 자원이 제대로 쓰이고 있는지부터 확인하라.] 였습니다.

---

18. 겹치기의 산수 - 비용을 서로의 뒤에 숨긴다

자원 지도가 그려지고 GPU를 활용한 뒤에야 오버랩이 값을 하기 시작했습니다. 세 구간입니다.

• 전처리 || 검출 — ffmpeg(CPU)가 다음 영상을 정규화하는 동안 YOLO(GPU)로 현재 영상을 검출했습니다. 전처리 비용이 검출 뒤에 숨어, 준비 구간이 50.7초에서 17.1초(3배)로 줄었습니다.
• 관찰 프로필 — 영상마다 캡션(Ollama, 직렬)과 센서 4축(오디오, 배경, 장소, 휘도, CPU)을 뽑는데 센서를 영상 간 병렬로 팬아웃시켰고 총시간이 캡션 합 + 센서 합에서 max(캡션 합, 센서 합)으로 바뀌면서 센서 비용을 통째로 은닉시켰습니다.
• 동작 판정 — 모션 계산(CPU)을 팬아웃하고 LLM 판정만 직렬로 했습니다. 모션의 비용이 판정 뒤로 숨었습니다.

스레드가 들어오면서 따라오는 숙제도 처리했습니다. 모델 지연 로딩 3곳에 이중 확인 락(같은 모델을 두 번 로드해 메모리가 2배가 되는 사고 방지), 병렬 워커는 영상별 산출물 파일만 쓰기, 임시파일명에 인덱스 포함. 기존 테스트 102개는 전부 그대로 통과하였고 CLI와 같은 인터페이스는 하나도 안 바뀌었습니다. 병렬화는 전부 내부 구조입니다.

---

19. 단순 측정을 믿지 마라 - 분산부터 통제

마지막 함정은 측정 그 자체였습니다. 동작 판정 구간을 같은 입력으로 세 번 돌렸더니 28.1초, 22.9초, 14.3초. 같은 코드가 2배 차이 났습니다. Ollama 응답 시간의 분산이 구간 전체를 지배해서 한 번씩 재는 A / B 비교가 무의미해졌습니다.

 

실제로 두 번 속았습니다. 새 코드의 첫 실행이 옛 코드보다 느리게 나왔는데(9.7초 vs 10.7초) 첫 실행에 모델 로드와 Ollama 웜업이 섞여 있었습니다. 웜 상태로 다시 재니 7.8초(−20%)가 나왔습니다. 또 한 번은 22.9초(구코드)에서 28.1초(신코드)로 느려졌나 싶었는데 재실행에서 14.3초. 실행할 때마다 측정 결과가 달랐습니다.

 

그래서 판정 방법을 갈랐습니다. 결정론 구간(모션 곡선, 검출)은 조건을 맞춘 단발 A / B로 숫자를 재고, LLM이 섞인 구간은 단순 측정 대신 출력 동일성과 구조적 은닉(직렬 합이 max로 바뀌었다는 산수)으로만 판단합니다. 시리즈 첫 편에서 "자가 휘어 있으면 측정이 무의미하다"고 했는데, 마지막 편에서 하나 더 보탭니다. 분산을 통제하지 않은 단순 측정도 휜 자입니다.

---

맺음말

자동 영상 편집 1회 라이프사이클 기준, 총 8분이 4분이 됐습니다.

• 자원 지도를 먼저 그려 공유 자원(Ollama)과 겹칠 수 있는 자원을 가르고,
• 최대 배수(3.5배)는 스레드가 아니라 놀고 있던 GPU를 깨운 한 줄에서 얻고,
• 오버랩으로 전처리, 센서, 모션의 비용을 LLM 작업 뒤에 숨기고,
• 단순 측정의 분산을 통제해, 빨라졌다는 느낌 자체를 측정답게 만들었습니다.

그리고 이 모든 변경의 합격 기준은 속도가 아니라 결과 동일성이었습니다. 골든셋 지표 소수 4자리까지.

 

남은 부분도 있습니다. Ollama 서버 자체의 동시성, TTS와 렌더의 파이프라이닝. 하지만 raw 폰 영상 아홉 개와 요청 한 문단이 4분 만에 내레이션 붙은 숏폼이 되는 지금, 개발기로서의 이야기는 여기서 일단락하려 합니다. 골든셋으로 채점하고, 측정할 수 있는 것은 측정에게 맡기고, 소리도 채점하고, 구조의 주인을 하나로 세우고, 빠르게 만들 때조차 자부터 검증한다. 이 시리즈가 남긴 문장들입니다.

---

이 글에서 다룬 고정 함수 분류층은 ProjectDavid의 일부입니다.

전체를 바닥부터 만드는 과정은 강의 3부작으로 정리하고 있고, 10월에 오픈 예정입니다.

→ 오픈 알림 받기

---

이전글

LLM은 지시만: 프롬프트 오염을 막는 설계 - Ownership First AI

관련글

오픈소스 LLM vs 빅테크 LLM API: AI 사업의 비용과 리스크