저는 사이드 프로젝트를 위해 밤마다 실행되는 작업을 운영하고 있습니다. 이 작업은 수천 개의 사용자 제출 항목 배치에 카테고리를 태그하는 것입니다. 깊은 추론이 필요한 것은 아니며, 일관된 분류만 필요합니다. 저는 원래 더 무거운 DeepSeek 모델을 사용하여 순차적으로, 요청 하나씩 처리하도록 구축했었고, 작동하기는 했지만 느렸습니다. 밤마다 약 40분이 걸렸는데, 이 시간은 제가 잠든 동안 실행되었기 때문에 크게 신경 쓰지 않았습니다.

항목 볼륨이 늘어나면서 시간이 한 시간에 가까워지기 시작하자, 최적화할 가치가 있는지 궁금해졌습니다. 저는 실제로 어떤 것이 중요한지 알 수 있도록 두 가지 변경 사항을 개별적으로 테스트했습니다:

변경 1 — 태그 지정 작업을 위해 DeepSeek-V4-Flash로 전환했습니다 (더 무거운 모델은 더 신중한 추론의 이점을 얻는 파이프라인의 작은 부분에는 유지했습니다). 기존 테스트 세트를 두 모델 모두에 통과시켜 태그 정확도가 떨어지지 않는지 확인했는데, 이 특정 단순 분류 작업에서는 그렇지 않았습니다.

변경 2 — 순차적 요청에서 동시(concurrent) 요청으로 전환했습니다. 사실 어떤 모델을 사용하든 상관없이 제가 했어야 할 일이었지만 미뤄왔던 것이었습니다.

개별적으로 각 변경 사항은 도움이 되었습니다. 하지만 함께 적용하자: 작업 시간이 약 40분에서 약 6분으로 단축되었습니다. 두 변경 사항이 이루어진 시기가 가까워서 어느 쪽의 기여도를 명확하게 할 수는 없지만, 둘 다 개별적으로만 하는 것보다 훨씬 가치가 있었습니다.

이 특정 작업에 국한되지 않고 일반화할 수 있는 교훈은 다음과 같습니다: 무언가가 느리게 느껴진다면, 실제로 작업 복잡도에 맞는 모델 티어를 사용하고 있는지 확인하고, 별도로 요청을 할 필요가 없을 때 하나씩 처리하고 있지는 않은지 확인해야 합니다. 저는 'API가 느리다'라는 것을 하나의 문제로 취급해 왔지만, 실제로는 두 가지 문제였으며, 오직 모델 선택에만 집중했을 뿐 요청 패턴은 고려하지 않았습니다.

요약 (TL;DR): 단순 태깅 (tagging) 작업을 위해 DeepSeek-V4-Flash로 모델을 교체하고, 순차적 (sequential) 요청에서 병렬적 (concurrent) 요청으로 전환함으로써 매일 밤 실행되는 배치 분류 (batch classification) 작업 시간을 약 40분에서 약 6분으로 단축했습니다. 두 가지 변경 사항 모두 중요했습니다. 만약 여러분의 배치 작업이 예상보다 느리다고 느껴진다면 두 가지 모두 확인해 볼 가치가 있습니다.
fastrouteai.com