OpenAI 내장 검색 기능 해부: 스토리지 제약, 성능 격차, 비용 우려 사항 파헤치기
OpenAI의 최신 발표 이후, 저는 OpenAI Assistants가 특히 20개 파일 제한과 하루 GB당 $0.2 가격이라는 한계로 인해 프로덕션 수준 애플리케이션에 적합한지 의문을 갖기 시작했습니다. 이를 염두에 두고, 저는 세 가지 주제에 초점을 맞춘 글을 작성했습니다.
OpenAI Assistants의 지식 베이스에 대한 $0.2/GB/일은 비싼가?
공개된 정보를 바탕으로 OpenAI의 내부 솔루션을 파헤쳐 보기.
AI Assistants의 지식 베이스 인프라는 어떤 방향으로 발전해야 하는가?
참고: 다음 내용에는 일부 계산이 포함되어 있습니다. 이러한 상세한 계산을 살펴보셔도 좋고, 빠른 개요를 위해 강조된 결론에 집중하셔도 됩니다.
OpenAI Assistants의 지식 베이스 비용
간단한 계산을 해봅시다:
Office 365는 월 TB당 $6의 데이터 요금을 부과합니다. Google Workspace는 월 TB당 $8의 데이터 요금을 부과합니다.
OpenAI Assistants의 경우 비용은 0.2 ($) x 30 (일) x 1024 (GB) = 월 TB당 $6,144입니다.
따라서 OpenAI Assistants를 사용해 제 오피스 문서에 AI assistant를 추가하면 기존 문서 서비스보다 세 자릿수 더 많은 비용이 듭니다($6 vs. $6,144). 이것이 비쌀까요? 저는 "그렇다!"고 말하겠습니다. 지나치게 높아 보입니다.
| 서비스 | 가격 |
|---|---|
| 기존 문서 서비스 | $6 /TB |
| OpenAI Assistants | $6,144/TB |
OpenAI 측의 운영 비용도 간단히 계산해 보겠습니다. 다음 분석은 약간 복잡하지만 결론은 간단합니다: 1 GB의 문서를 서비스하려면 1.5 GB의 벡터를 생성해야 하며, 이러한 벡터를 서비스하기 위한 서버 비용은 하루 약 $0.30입니다. 비쌀까요? $0.20/GB라는 가격표와 비교하면 아주 저렴합니다. 흥미롭군요!
| 가격 | |
|---|---|
| OpenAI의 비용 | 하루 $0.3/GB |
| OpenAI의 가격 | 하루 $0.2/GB |
추정은 다음과 같습니다:
검색용 벡터를 생성하기 위해 OpenAI의 text-embedding-ada-002 모델을 사용해 1 GB의 텍스트를 처리한다고 가정해 봅시다. 텍스트 1 KB마다 이 모델은 1536차원 임베딩을 생성합니다. 각 벡터 차원은 하나의 float32에 해당하므로(따라서 벡터당 6KB), 입력 텍스트와 출력 벡터의 크기 비율은 1:6이 됩니다. 즉, 1 GB의 텍스트는 6 GB의 벡터에 해당합니다. 양자화를 통해 벡터를 압축하면 4:1 압축률을 달성할 수 있으며, 이는 1 GB의 텍스트가 1.5 GB의 벡터에 해당함을 의미합니다.
1.5 GB의 벡터를 서비스하기 위한 서버 비용을 고려해 봅시다. 경제적인 AWS EC2 인스턴스를 선택하면 메모리 1.5 GB당 하루 약 $0.30의 비용이 듭니다. 이 시나리오는 벡터 저장 및 검색만 가정하기 때문에 충분히 공정한 편입니다. 여기에는 메타데이터, 모니터링, 로그, 인덱스 파일, 그리고 프로덕션 환경에 필요한 다중 복제본 기반 고가용성 비용과 같은 다른 요소는 포함되지 않습니다.
비용 분석 결론
OpenAI의 새로운 Assistants 기능은 하루 $0.2/GB의 가격과 비교해 높은 서버 비용인 하루 $0.3/GB 때문에 회사가 벌어들이는 것보다 더 많은 비용을 발생시키고 있습니다. 그러나 Assistants를 사용하려는 개발자는 기존 문서 서비스보다 1,000배 이상 많은 비용을 지불해야 합니다. 따라서 비용을 정당화하려면 기존 문서 서비스보다 세 자릿수 더 높은 비즈니스 가치를 창출해야 합니다.
이 가격 모델은 B2C 비즈니스에는 정당화될 수 있습니다. 개인 사용자에게는 월 수십 달러가 드는 몇 GB의 데이터가 큰 문제가 될 가능성이 낮기 때문입니다. 그러나 대규모 데이터를 다루는 B2B 비즈니스의 경우, 이 비용은 비즈니스 매출을 크게 잠식하거나 심지어 비즈니스의 가치를 넘어설 수도 있습니다. 예를 들어, 개인화된 고객 서비스나 특허 및 법률 문서를 위한 지능형 검색 시스템을 만드는 것은 감당하기 어려울 정도로 비싸질 수 있습니다.
OpenAI의 솔루션 파헤치기
OpenAI Assistants의 현재 방식을 자세히 살펴보겠습니다. 다음은 공개적으로 이용 가능한 정보입니다:
어시스턴트당 최대 20개 파일
파일당 512MB 제한
테스트 중 발견한 파일당 200만 토큰이라는 숨겨진 제한
텍스트만 지원됩니다.
OpenAI DevDay 이후 서버 트래픽이 크게 증가했습니다. 체험 사용자 수와 그에 따라 생성된 어시스턴트 수는 공개되지 않았지만, 상당했을 것입니다.
OpenAI의 검색 서비스 분석
위의 공개 정보를 바탕으로 계산을 해보겠습니다.
- 사용자는 20개 파일로 제한되며, 각 파일은 200만 토큰으로 제한됩니다. 청크당 200토큰(벡터 하나에 해당)이라고 가정하면, 사용자당 200,000개 벡터의 제한이 있습니다.
| 사용자당 파일 제한 | 토큰 수 | 벡터 수 |
|---|---|---|
| / | 200 | 1 |
| 1개 파일 | 2,000,000 (상한) | 10,000 |
| 20개 파일 | 40,000,000 (상한) | 200,000 |
- 대부분의 사용자는 파일당 200만 토큰 제한에 도달하지 않을 것이므로, 각 사용자의 파일에는 평균 400,000토큰이 포함될 것으로 추정할 수 있으며, 이는 2,000개 벡터로 변환됩니다. 사용자당 200,000개 벡터라는 상한과 사용자당 평균 2,000개 벡터를 고려하면, 1000:1의 오버셀링 비율을 달성하는 것이 가능합니다.
| 사용자당 파일 제한 | 토큰 수 | 벡터 수 |
|---|---|---|
| / | 200 | 1 |
| 20개 파일 | 400,000 (평균) | 2,000 |
또한 OpenAI는 상당한 사용자 기반을 보유하고 있어, 안정적인 시스템을 유지하고 재해의 영향을 효과적으로 관리해야 합니다. 따라서 OpenAI Assistants 개발 초기 단계에서 초대형 클러스터 솔루션을 선택할 가능성은 낮습니다. 대신 OpenAI는 더 나은 안정성을 위해 각 사용자 그룹이 소규모 vector database 인스턴스를 공유할 수 있는 시스템(아래 표시)을 만들 가능성이 높습니다.
OpenAI Assistants의 Retrieval 기능의 단순화된 아키텍처
각 물리 노드에 32 GB의 메모리가 있고 네 개의 Pod로 나뉜다고 가정해 보겠습니다. 각 Pod는 별도의 vector database 인스턴스를 호스팅하며, Pod에는 8 GB의 메모리가 할당됩니다. 3 GB는 vector database 시스템에 전용으로 사용되고, 5 GB는 사용자 벡터 데이터를 서비스하기 위해 예약됩니다.
사용자당 200,000개 벡터 제한이 있는 경우, 양자화된 벡터와 해당 인덱스에는 약 500 MB의 메모리가 필요합니다. 따라서 각 Pod는 오버셀링 없이 10명의 사용자를 수용할 수 있습니다. 그러나 오버셀링 비율이 1000:1이면, 단일 Pod는 최대 10,000명의 사용자(최소 수백 명의 활성 사용자 포함)를 서비스할 수 있습니다. 결과적으로 네 개의 Pod로 구성된 단일 서버는 40,000명의 사용자를 수용할 수 있습니다.
이 아키텍처는 체험 사용자를 지원하기에 적절해 보입니다. 그러나 각 물리 노드는 유료 고객을 위해 최대 20 GB의 벡터와 인덱스를 저장할 잠재력이 있으며, 이는 대략 8 GB의 원본 텍스트에 해당합니다. 전체 용량을 기준으로 할 때, 일일 매출 잠재력은 1.6달러로 modest하며, 이는 현저히 낮은 수준입니다.
참고: 대용량 파일을 가진 여러 사용자가 단일 Pod를 공유하는 극단적인 경우, 스케줄링을 통해 잠재적인 문제를 완화할 수 있습니다. 예를 들어, 새 Pod를 배포하면 이러한 대규모 사용자의 부하를 효율적으로 마이그레이션할 수 있습니다.
빠른 요약
OpenAI의 검색 서비스 아키텍처는 체험판 사용자에게는 잘 작동할 수 있지만, 더 광범위한 데이터 요구 사항을 가진 대규모 비즈니스를 지원할 만큼 충분히 확장되지 않을 수 있습니다.
현재 아키텍처는 사용자 데이터에 저장소 제한을 부과하여 잠재적 수익을 줄이고 비용을 증가시킵니다.
또한 일부 고객은 각 클라이언트마다 별도의 어시스턴트를 필요로 할 수 있으므로, 이 아키텍처는 애플리케이션 계층 멀티테넌시에 부적합합니다. 자세한 논의는 OpenAI forum을 참조하세요.
OpenAI Assistants의 지식 베이스가 충분히 좋지 않은 이유
이전에 OpenAI Assistants와 그 아키텍처의 한계에 대해 논의했습니다. 그렇다면 이 문제를 어떻게 해결하고 비용을 줄일 수 있을까요? 가장 효과적인 솔루션은 서비스 아키텍처를 최적화하는 것입니다.
솔루션을 자세히 살펴보기 전에, 최적화된 시스템 아키텍처로 나아가는 길을 마련하는 중요한 요소를 고려해 보세요.
개선된 벡터 데이터베이스 솔루션: 하이브리드 디스크/메모리 벡터 스토리지
벡터 데이터베이스는 일반적으로 쿼리 응답 속도를 높이기 위해 벡터와 인덱스를 메모리에 로드합니다. 그러나 Assistant 애플리케이션은 전형적인 검색 증강 생성(Retrieval Augmented Generation, RAG) 사용 사례이므로, 성능 병목은 벡터 데이터베이스 쿼리 프로세스가 아니라 대규모 언어 모델(LLM)의 추론에 있습니다. 이러한 경우 초고속 벡터 검색 응답은 필요하지 않습니다. 벡터 데이터베이스 성능을 LLM에 맞춰 의도적으로 낮춤으로써, 비용 효율성과 확장된 저장 기능 사이의 균형을 달성할 수 있습니다. 유망한 방법 중 하나는 디스크 기반 벡터 데이터베이스 솔루션을 탐색하는 것으로, 여기서는 핫 데이터만 메모리에 로드됩니다. 이 접근 방식은 하드웨어 비용을 크게 줄일 뿐만 아니라 시스템의 전체 저장 용량도 증대합니다.
재해 복구 간소화: 시스템 데이터 풀링
현재 OpenAI Assistant는 재해 복구를 위해 다소 무차별적인 접근 방식을 사용하여, 각 Pod에 별도의 벡터 데이터베이스 인스턴스를 할당하고 각 Pod 메모리의 1/3 이상을 시스템 용도로 할당합니다. 그러나 사용자 데이터만 분리가 필요하다는 점을 고려하면, 더 세밀한 전략은 시스템 구성 요소를 함께 풀링하는 것입니다. 이 접근 방식은 고가용성을 향상시켜, 이러한 구성 요소가 개별 Pod에 얽매이지 않고 독립적으로 작동할 수 있게 합니다.
다양한 사용자 기반을 위한 멀티테넌시 지원
아키텍처 프레임워크는 수많은 소규모 사용자와 대규모 데이터를 보유한 대기업 모두를 원활하게 지원해야 합니다. 애플리케이션 계층의 멀티테넌시 지원은 Agent 애플리케이션, 특히 상당한 사용자 기반을 가진 애플리케이션의 기본 요구 사항입니다.
이러한 사고 흐름에 따라 아키텍처 다이어그램을 간단히 그려 보겠습니다.
OpenAI Assistants의 검색 기능에 대한 최적화된 아키텍처
몇 가지 주요 수정 사항을 집중적으로 살펴보겠습니다.
시스템 및 쿼리 구성 요소의 분리. 이전에는 각 Pod 내에 함께 배치되었지만, 시스템 구성 요소는 이제 독립적으로 풀링되어 이전 방식과 비교해 리소스 사용량을 1/3에서 1/10 미만으로 줄입니다.
쿼리 컴포넌트의 유연성 향상: 이제 쿼리 컴포넌트를 서로 다른 Pod 수에 따라 동적으로 할당할 수 있으며, 독립적인 확장성을 위한 물리적 격리를 누릴 수 있습니다. 블래스트 반경에 대한 제어는 쿼리 컴포넌트의 세분성 수준에서 정밀하게 관리됩니다. 단순화된 구조는 더 복잡한 시스템 컴포넌트에 비해 안정성을 향상합니다.
하이브리드 메모리/디스크 아키텍처: 메모리가 핫 데이터만 독점적으로 로드하는 하이브리드 메모리/디스크 아키텍처의 도입은 또 다른 중요한 변경 사항입니다. 이 개선을 통해 동일한 양의 메모리로 이전 솔루션에 비해 원본 텍스트의 5~10배를 처리할 수 있습니다.
멀티 테넌시를 위한 멀티 파티션 지원: 멀티 파티션 지원을 추가하면 애플리케이션 계층에서 멀티 테넌시를 충족할 수 있습니다. 이제 각 상위 수준 사용자는 독립적인 데이터 파티션을 할당받을 수 있어 애플리케이션 계층에서 저비용 솔루션을 제공합니다. 사용자 그룹당 하나의 쿼리 컴포넌트를 할당함으로써 물리적 격리가 달성됩니다.
이 아키텍처로 데이터 지원을 다시 계산하면, 디스크 공간이 보강된 32 GB 메모리의 쿼리 노드는 이제 320 GB의 벡터와 인덱스를 효율적으로 지원할 수 있으며, 이는 사용자의 원본 텍스트 128 GB에 해당합니다. 이러한 쿼리 노드에 할당된 풀링된 시스템 컴포넌트 리소스는 3 GB이며, 쿼리 노드와 물리적으로 구분됩니다. 총 35 GB의 메모리로 128 GB의 사용자 데이터를 수용할 수 있으며, 이는 메모리 1 GB당 약 3.6 GB의 사용자 데이터에 해당합니다. 반면 이전 설계에서는 32 GB의 메모리로 8 GB의 사용자 데이터를 지원할 수 있어, 메모리 1 GB당 평균 250 MB의 사용자 데이터에 그쳤습니다. 이는 효율성이 무려 15배 증가했음을 보여줍니다.
인기 있는 벡터 데이터베이스 개요: Milvus, Chroma, Qdrant
벡터 데이터베이스는 OpenAI Assistants의 아키텍처를 최적화하는 데 핵심적인 역할을 하므로, 가장 강력한 옵션을 선택하는 것이 매우 중요합니다. 여기서는 OpenAI Assistants 아키텍처를 향상하는 데 있어 세 가지 주요 오픈소스 벡터 데이터베이스인 Milvus, Chroma, Qdrant의 강점과 한계를 살펴봅니다.
Milvus
장점: Milvus는 가장 성숙한 오픈소스 벡터 데이터베이스로, 대규모 분산 시스템에서 널리 채택되고 있습니다. 주요 기능으로는 시스템 컴포넌트와 쿼리 컴포넌트의 효과적인 분리, Resource Group 기능을 통한 쿼리 컴포넌트의 격리, 하이브리드 메모리/디스크 아키텍처, RBAC 및 Partition 기능을 통해 구현되는 애플리케이션 수준의 멀티 테넌시가 있습니다.
단점: 이러한 강점에도 불구하고 Milvus는 Resource Group 기반의 쿼리 컴포넌트 격리를 통해 완전한 이상 현상 격리를 달성하는 데는 부족합니다. 또한 Etcd 및 MinIO와 같은 일부 서드파티 의존성을 도입하여 배포 및 운영 비용이 증가합니다.
Chroma
장점: Chroma는 새롭고 사용자 친화적인 프로젝트로 부상했으며, 단순성으로 호평받고 있습니다. 빠른 프로토타이핑과 신속한 AI 애플리케이션 반복 개발에 적합하여 개인 개발자들 사이에서 인기를 얻고 있습니다.
단점: Chroma는 소규모 시나리오에서는 뛰어나지만, 대규모 엔터프라이즈 애플리케이션을 위해 설계되지는 않았습니다. 분산 배포, 컴포넌트 분리, 하이브리드 메모리/디스크 아키텍처, 애플리케이션 수준의 멀티 테넌시와 같은 핵심 기능이 부족합니다.
Qdrant
장점: Qdrant는 신규 진입자로서 간소화된 설정 프로세스와 함께 소규모 분산 배포를 지원합니다. 또한 하이브리드 메모리/디스크 아키텍처를 자랑하여 현대적인 데이터베이스 요구 사항에 부합합니다.
단점: 현재 Qdrant는 컴포넌트 분리나 애플리케이션 수준의 멀티 테넌시와 같은 중요한 기능을 지원하지 않아 특정 사용 사례에서 적용 가능성이 제한됩니다.
이러한 벡터 데이터베이스들을 평가해 보면, 각 솔루션이 고유한 강점과 트레이드오프를 제공한다는 점이 분명해지며, 따라서 선택은 OpenAI Assistants의 아키텍처를 최적화하는 맥락에서 특정 요구사항과 우선순위에 따라 달라집니다.
요약
이 블로그 게시물에서는 OpenAI Assistants의 복잡한 세부 사항을 살펴보며, 가격, 아키텍처, 비용 효율성 및 향상된 저장 기능을 위한 잠재적 최적화를 탐구했습니다. 핵심적인 발견은 벡터 데이터베이스 인프라의 비용이 지식 베이스와 Agent 애플리케이션의 배포에 상당한 영향을 미친다는 점이었습니다.
Assistants와 관련된 OpenAI의 비용과 수익을 분석한 결과, 지출이 잠재적 수익을 초과하는 주목할 만한 불균형을 발견했습니다. 이는 체험 단계에서 신규 고객과 커뮤니티 확장을 수용하기 위해 정당화될 수 있지만, 보다 지속 가능한 균형이 필수적입니다.
이 블로그 게시물은 아키텍처를 최적화하기 위한 솔루션을 제안하며, 기존 솔루션과 비교해 이러한 애플리케이션 유형의 비용을 10배 절감할 수 있는 가능성을 제시합니다. 이 최적화 과정에서 벡터 데이터베이스의 핵심적인 역할이 강조되며, 사용 가능한 대안 중 Milvus가 특히 적합한 옵션으로 부상합니다.
그럼에도 불구하고, 기존 벡터 데이터베이스의 본질적인 한계를 인정하면서, 이 게시물은 어떤 단일 벡터 데이터베이스 솔루션도 임박한 인프라 개발을 위한 모든 과제를 포괄적으로 해결하고 모든 설계 요구사항을 충족할 수는 없다는 점을 강조합니다. OpenAI Assistants의 아키텍처 최적화의 복잡성을 효과적으로 헤쳐 나가기 위해서는 벡터 데이터베이스의 선택이 특정 요구사항에 맞게 조정되어야 합니다.
계속 읽기
Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)
Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
Zilliz Cloud BYOC Upgrades: Bring Enterprise-Grade Security, Networking Isolation, and More
Discover how Zilliz Cloud BYOC brings enterprise-grade security, networking isolation, and infrastructure automation to vector database deployments in AWS