LangChain, LlamaIndex, Haystack의 비동기 성능 테스트 결과: 기대 이하의 성능
I tested async performance across LangChain, LlamaIndex, and Haystack under concurrent load. The results were worse than I expected — here's what I found.
핵심 요약
주요 LLM 프레임워크의 비동기 지원이 실제로는 동기식 IO를 스레드 풀로 감싼 형태라 성능 저하가 심각하다는 분석.
- 비동기 성능 문제 — 주요 프레임워크의 비동기 지원이 실제로는 스레드 풀 기반의 동기식 IO로 작동함.
- 성능 저하 원인 — 이벤트 루프와 스레드 풀 오버헤드가 동시에 발생하여 실제 비동기 처리의 이점을 얻지 못함.
- 프레임워크 비교 — LangChain이 가장 비효율적이며, LlamaIndex와 Haystack도 일관성 없는 성능을 보임.
- 대안 제시 — 완전한 비동기 네이티브 구조를 가진 SynapseKit을 통해 성능 문제를 해결하고자 함.
한동안 프로덕션 환경에서 LLM 파이프라인을 운영해 왔음. "비동기" 코드라고 하기엔 처리량 수치가 말이 안 된다는 걸 계속 느꼈음. 그래서 주요 프레임워크로 구축된 RAG 파이프라인에 동시 요청을 보낼 때 내부적으로 무슨 일이 일어나는지 직접 파헤쳐 보기로 했음.
요약하자면: 비동기 지원이라고 광고하는 대부분의 기능은 사실 ThreadPoolExecutor로 감싼 동기식 IO임. 기능적으로는 스레드처럼 동작함. 즉, 이벤트 루프와 스레드 풀의 오버헤드를 둘 다 겪으면서도, 정작 진정한 비동기 처리의 처리량 이점은 하나도 못 누리는 거임.
구체적으로 다음 사항들을 살펴봤음:
- 50개의 동시 요청 하에서 검색 계층에 무슨 일이 일어나는가
- LLM 호출이 진정으로 비차단(non-blocking) 방식인가, 아니면 실행자(executor)로 감싸져 있는가
- 동시성이 증가함에 따라 파이프라인 지연 시간이 어떻게 악화되는가
LangChain이 가장 심각했음. LlamaIndex는 부분적으로는 낫지만 일관성이 없음. Haystack은 동기 우선 설계라는 점을 더 솔직하게 밝히고 있음.
광고하는 비동기 성능과 실제 비동기 성능 사이의 격차는 FastAPI나 실제 동시성 서비스 내에서 이 프레임워크들을 실행할 때 매우 중요함.
혹시 다른 사람들도 이거 파본 적 있음? 다들 우회 방법을 찾았는지, 아니면 그냥 오버헤드를 감수하고 있는지 궁금함.
참고로, 비교를 위해 완전한 비동기 네이티브 베이스라인을 테스트하는 작은 프레임워크를 만들었음: https://github.com/AmitoVrito/synapsekit — 지금까지 PyPI 다운로드 약 1만 건 정도인데, 다른 사람들도 이걸 찾고 있다는 증거겠지. 유용하다면 벤치마크 방법론도 공유하겠음.
